<Regenaxer>
Good morning Nistur! Yes, your above 'native' calls are on the right way
<aw->
Regenaxer: hi
<aw->
will Fuschia replace Android OS ?
<aw->
it would be nice if they didn't break all existing Android apps ;)
<aw->
hmm.. i'm looking at logs, why is Nistur so stuck on pil32 ???
<Regenaxer>
Hi aw-
<Regenaxer>
yeah
<aw->
if anything, rather than trying to port 'native' to pil32, it would probably be more valuable to port all of pil64 (the pilAsm code) to 32-bits
<aw->
src64/arch/x86.l
<Regenaxer>
yes, that would be optimal. I tried initially, but x86-32 does not have enough registers so it gets rather inefficient
<aw->
oh
<aw->
how many registers required for x86-64 ?
<aw->
oh i see it
<aw->
i don't know the x86 arch, i'm guessing it doesn't have R12, R13, R14, R15 ?
<Regenaxer>
Well, at least those in doc64/asm
<cess11_>
Good morning.
<Regenaxer>
8 registers of 64 bits each
<Regenaxer>
plus some temporaries
<cess11_>
aw-: Thanks for pointing out the broken links.
<Regenaxer>
Hi cess11_!
<aw->
cess11_: np, I wrote something similar to dev.to in PicoLisp, without knowing about dev.to ahaha
<Regenaxer>
So some "registers" (or most of them) end up as global memory variables
<Nistur>
aw-: I have this issue where I have an idea for a project and then spend far too much time writing systems to solve it, or fiddling with them, and not solving the issues themselves... so when i got pil32 working on all my machines, but pil64 was being annoying, I was wanting to stick with it so I Could actually work on the project. The native stuff in pil64 I needed was fairly thin glue, so I don't mind
<Nistur>
rewriting that multiple times
rob_w has joined #picolisp
<aw->
Nistur: interesting.. but your machines are all/mostly 64-bit?
<Nistur>
2012 MacBook Pro - x64
<Nistur>
Banana Pi - ARM 32
<Nistur>
ASUS Transformer T100TA - x64 running x86 OS because of hw weirdness
<Nistur>
PC - Linux x64
<aw->
interesting
<Nistur>
various other pi's which make up my 'PC setup' (I rarely use the PC itself) - ARM 32
<aw->
well you can replace Banana Pi with a cheap alternative, like rock64 ;)
<aw->
rock64 is arm64 - i'm using it now as I type this
<aw->
for the ASUS you can just use pil in a 64-bit chroot, assuming you have the correct libc6
<Nistur>
my actual setup is 3 RPi0W's and the Banana Pi. The Banana Pi has been running pretty much non-stop for... 7 years I think. It's probably the computer I have most stuff on and would take most time to backup and replace
<aw->
Regenaxer: thanks, i'm looking at doc now.. i always forget to the read the docs haha
<Regenaxer>
:)
<aw->
Nistur: 7 years is great! I would be happy to upgrade to a 64-bit arch after 7 years of service, particularly since it's so inexpensive and you can probably keep all your external devices
<Nistur>
anyway, my projects have a natural lifetime, not measured in decades like picolisp... there's always something which gets in the way and it's difficult to restart development in full afterwards, so I would prefer to actually work on my project, and not argue with setup as much as possible :P
<aw->
I think the time investment to backup/replace would be worth it
<aw->
Nistur: ah yes, haha i understand
<Nistur>
The banana pi is likely to stay a bit longer, I'm considering replacing the RPi0W's which run my monitors, because the wifi on them is a bit pants, so I want copper cable running to something. Probably just a Pi2
<Nistur>
replacing 4 Pi's, while not on the order of cost of one new x64 PC, will still cause my wife to grumble :P
<aw->
haha
<aw->
well, i'm hoping to get 7 years out of my 64-bit arm64. It's nice that I can use pil64 and 'native' without hassle
<cess11_>
The ROCK64 boards look nice.
<Nistur>
I'm using pil64 now, because I am using emulated pil64 on my pi so my inline C didn't compile and I figured it was easier to quickly rewrite the wrapper than repeatedly recoompile pil32/64
<aw->
emu? java?\
<Nistur>
I may massage the makefiles though, so it builds seperate 32- and 64 bit executables, and links pil and picolisp to the latest one built
<aw->
i don't think i've used emu, I think Regenaxer always says it's slow so i just stayed away
<Regenaxer>
Nistur, you could build pil32 in a separate directory, and plant the global links to it
<Regenaxer>
aw-, yes, slow
<Regenaxer>
but still usable
<Regenaxer>
I used emu in a small netbook for years to replicate 64-bit DBs for a few years
<aw->
well you're the author, i assume you use the code you write
<Regenaxer>
T, for many purposes speed is not critical
<Regenaxer>
eg in PilBox emu seems OK too
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
<Nistur>
Regenaxer: also an option, yes :P
<Nistur>
I just like the idea of being able to call either without having to dig out a full path for it, I would probably not actually symlink `pil` to the latest one, but put a script that would run `pil64` if it exists, and `pil32` otherwise, and then I could specify `pil32` or `pil64` (or `picolisp32` or `picolisp64`) in scripts and command line if I have stuff which needs one or the other
<Regenaxer>
Sounds complicated
<Regenaxer>
I do usually have on each machine a global and several local installations
<Regenaxer>
Global is from the distro
<Regenaxer>
And apps call the local ones
<Regenaxer>
usually as ./pil ... or ../pil ...
<Nistur>
not particularly, change the target of each makefile to, rather than output picolisp, to create picolisp{32,64} and then write a script which sits in bin/ alongside them which does the selecting
<Regenaxer>
I do not like separate installs like /opt/...
<Regenaxer>
No change to anything, only unpacked picoLisp.tgz versions
<Nistur>
I could either install to /opt/ or to /usr/local/ on macOS, /usr/ is unwritable unfortunately
<Regenaxer>
I keep the path /foo/bar/picoLisp/
<Regenaxer>
I don't install in /usr
<Regenaxer>
only in the user's home
<Regenaxer>
or /tmp for a quick test
<Nistur>
INSTALL suggests to install in /usr and the shebang in pil has /usr in it :P
<Regenaxer>
yes, but as I said I don't do that if it is in the distro
<Regenaxer>
The distro version only for bootstrapping or some simple scripts
alexshendi has joined #picolisp
<Regenaxer>
Applications use their private picoLisp/pil
<Regenaxer>
at some relative path
<Regenaxer>
no conflicts anywhere
<Regenaxer>
apps call "@lib/xxx.l"
<Nistur>
Hrmmm, I will probably do that for mine, as the intention is to make a packagable tool for non-techy windows users
<Regenaxer>
You can use pil64, pil32, emu, ersatz or mini on the same machine
<Regenaxer>
and I usually do
<Regenaxer>
s/usually/sometimes
<Regenaxer>
a packagable tool can also just contain its local path
<Regenaxer>
the installation is so small
<Regenaxer>
and they don't conflict
<Nistur>
I think for my setup, I prefer the idea of having a relatively complete global install of it where possible... I will certainly also have a project-specific copy at some point down the line, but for simple setup it makes sense to have a global one to me
mtsd has joined #picolisp
<Regenaxer>
yes
<Nistur>
that way I can just run `pil` to try things out, instead of finding one in a project to use
<Regenaxer>
My default is ./pil +
<Regenaxer>
in each dir
<Regenaxer>
On Android an app has access to its home *only* anyway
<Nistur>
yup
<Regenaxer>
There is even no /usr or /opt
<Nistur>
they've made that more strict recently :( I was using the SD card to output performance data for the game I was working on
<Nistur>
and then all of a sudden I couldn't write to it any more
<Nistur>
and retrieving the data was a lot more painful
<Regenaxer>
For example when I tested the buil for 'emu' yesterday, I did
<Regenaxer>
$ cd /tmp
<Regenaxer>
$ tar xfz /home/abu/picoLisp.tgz
<Regenaxer>
$ cd picoLisp
<Regenaxer>
$ (cd src64; make emu)
<Regenaxer>
$ ./pil +
<Regenaxer>
Then I could unpack some apps there and test them ./pil ...
<Nistur>
that's 4 more commands than just running `pil +`
<Nistur>
:P
<Nistur>
I understand why you do it how you do
<Nistur>
I think for my purposes though, it makes less sense
<Regenaxer>
to get a certain version
<Regenaxer>
no care about which is global
<Regenaxer>
I still can do pil +
<Regenaxer>
But it is an old version from Debian
<Regenaxer>
My shell tools use #!/usr/bin/picolisp
<Regenaxer>
there the version is not critical
<Nistur>
I was actually considering writing a pil-update script which will hg pull (or download .tgz) on the global install, and then re-make it
<Nistur>
but yeah, I don't think much of what I'll do for a loooong time would be version-critical
<Nistur>
as I said, I will probably add a local version to my project, and if I make more, I will do so with those too, but to get started at least, I'd use the global version
<Regenaxer>
yeah
<Regenaxer>
The problem with Debian (and thus Ubuntu etc.) is that the version is *very* outdated
<Regenaxer>
Usually not usable for me for production
<Nistur>
yup. As I said, it makes perfect sense to me why you do it in that way, I just don't think it fits my requirements quite like that
<Regenaxer>
Anyway, it is one of the nice features of PicoLisp that you *can* have many local installations with almost no overhead and without conflict
<Regenaxer>
Which requirements are in the way?
<Regenaxer>
I mean /opt/ is fine, it is one more local
<Regenaxer>
just does not have to be the only one
<Regenaxer>
Starting apps as /opt/picoLisp/pil ...
aw- has quit [Quit: Leaving.]
<Regenaxer>
(note the upper case "L", with that you just untar the TGZ)
<Nistur>
for you, I assume you work almost entirely in, or on picolisp. I am currently working in... C, C++, C#, lua, Bash, (now picolisp) and probably a few more languages. I am using a home rolled game engine, I am using Unity3D, I am working on a couple of standalone project. I am always working on some helper scripts and utils for my systems. It may be in your muscle memory to copy pil into each project, or
<Nistur>
create a tmp copy, but for me if I am to use it it kind of needs to be immediately accessible, otherwise context switching takes too long... basically I try and set things up so I can test and switch between systems quickly and, hopefully painlessly (not quite the case whenever Unity is involved) so for this it makes sense to have a globally accessible version which is (at least mostly) up to date
<Regenaxer>
ok
abel-normand has quit [Ping timeout: 240 seconds]
<tankf33der>
ive implement signify
<tankf33der>
writing documentation
<Nistur>
Regenaxer: I totally forgot. I really REALLY want to thank you... despite the issues I have with macOS... pil is the cleanest compiling project I have ever seen :P I have seen very few projects at all that have zero compile time warnings
<Regenaxer>
Welcome! :)
<Regenaxer>
Thanks!
<Nistur>
compared to this project I've inherited at work which has a huge amount of errors at compile and runtime, and even throws exceptions and carries on... and no-one apart from me seems to care about this :'(
<Nistur>
only in Unity can you have code which seems to throw errors at compile time and still "work"
<Nistur>
if there are true compilation errors, of course it won't work
<Nistur>
but you can output to the unity equivalent of stderr and continue
<Regenaxer>
horrible ;)
<Nistur>
tell me about it :(
<Nistur>
in previous projects, at previous companies, I wrote a 'BSOD' which caught all errors and exceptions at runtime and displayed a simulation of the Windows Blue Screen o' Death, with stack trace etc. My last project had a similar 'stop everything and display a popup' system, but you could dismiss them... I prefer it so it actually impedes the running of the game as it forces people to fix things rather
<Nistur>
than just dismiss it to be fixed by someone else, or later...
<Nistur>
just in development/testing versions of course. In distribution builds it would attempt to continue as well as possible
<Nistur>
which is usually a lot more smoothly after you have fixed all the exceptions and errors -_-
<Nistur>
Regenaxer: regarding the macOS sigaction size, I was taking a look, the struct is... here: http://ix.io/17FA with the union just being between two function pointers and sigset_t I haven't tracked down yet
<Regenaxer>
Hmm, this could probably fit into 16 bytes. Depends on how big sigset_t is
<Nistur>
yeah, found it in _types.h
<Regenaxer>
sysdefs.c uses sizeof() so it should be correct
<Nistur>
it is uint32_t
<Nistur>
yup, I wasn't saying it wasn't correct
<Regenaxer>
all depends on *which* include file the build uses
<Nistur>
it was just that you were surprised it was so small
<Regenaxer>
it must match the runtime lib
<Regenaxer>
yeah, the others were a little bigger
<Nistur>
you seemed to think it may have been the size which caused the segfault?
<Nistur>
or was that just if the size was incorrect?
<Regenaxer>
If the runtime size is bigger than the 16 bytes then it surely will crash upon 'ret'
<Regenaxer>
ie. when the lib writes more bytes
<Nistur>
so at the beginning of main I put in printf( "%d\n", sizeof( sigaction_t ) );? :P
<Regenaxer>
We must be sure that libc uses the same size
<Nistur>
in fact, I can just return straight away so it'd just do that
<Regenaxer>
sizeof() returns the size the *compiler* believes
<Regenaxer>
Normally they should be the same
<Regenaxer>
you built sysdefs and emu in the same env
<Nistur>
I wonder if it's a padding thing
<Regenaxer>
I thought about that too. Alignment
<Regenaxer>
But then sizeof() would be bigger
<Regenaxer>
ltrace() or strace() might show something (?)
<Nistur>
apparently dtrace is what I should use on macOS, but I've never used *trace before so I have no idea what to do
<Regenaxer>
hmm, yeah. I never heard of dtrace
<Regenaxer>
Idea: Change 16 to something bigger
<Nistur>
will that cause any issues?
<Regenaxer>
no, just allocate more stack space for a moment
<Nistur>
sizeof(act) * 2 in sysdefs.c it is.
<Regenaxer>
yes, or hard-code 256 or so
<Nistur>
well, I made it 64 (or, rather * 2) and picolisp now no longer crashes. I wonder if the tests pass
<Regenaxer>
Good. Still I wonder what went wrong
<Regenaxer>
Why the sizes don't match
<Nistur>
If it _is_ allignment then it might be a gcc/clang thing... on a previous project we had a similar thing were gcc padded to 4 bytes and clang to 8 (or was it vice versa?)... the SDK we used was compiled with clang and the game used gcc, so one struct and only one, we were getting a weird overlap
<Regenaxer>
I see
<Regenaxer>
makes sense
<Nistur>
the tests are still running
<Nistur>
precisely _how_ slow is the emu again? :P
<Regenaxer>
depends on the code. Factor between 5 and 20
<Regenaxer>
or even 1 if mainly system calls
<Regenaxer>
The tests should pass in a few seconds
<Nistur>
something's still broken then
<Nistur>
because they're still running
<Regenaxer>
The time of the tests is mainly sleeps / waits
<Regenaxer>
Too long it seems
<Nistur>
my manual sanity check is to start picolisp and do (+ 1 2) (bye)
<Nistur>
and that ran fine :P
<Regenaxer>
ok
<Nistur>
and running `pil` rather than `picolisp` works fine too
<Regenaxer>
pil + too? It loads more stuff
<Nistur>
uummmm... yes
<Regenaxer>
So probably some syscalls wrong
<Regenaxer>
Similar problem
<Nistur>
yay :P
<Regenaxer>
Can't emu be built with clang?
<Regenaxer>
It does not need dynamic arrays
<Nistur>
let me have a look
<Nistur>
I thought when I first tried it didn't like it
<Nistur>
but maybe with the changes we've made, it'll work now, I cannot recall why it didn't like it before
<Regenaxer>
:)
<Nistur>
it compiled with a LOT of warnings
<Nistur>
clang is warning-happy
<Regenaxer>
It believes the programmer is an idiot
<Nistur>
most of them are ;)
<Regenaxer>
sadly yes
<Nistur>
tests still don't run
<Nistur>
so that isn't the issue then
<Regenaxer>
It built with clang?
<Nistur>
I see no errors, just a tonne of warnings
<tankf33der>
now it always returns -1 as should, its ok
<tankf33der>
if comment close function it returns 0
<Nistur>
now, I need to figure out how to tansform 'filename.ext' to 'filename-something.ext'... string manipulation is something I've not done at all in lisp yet
<Nistur>
Regenaxer: :D Thanks! I had got partway there by searching through the reference docs
<Regenaxer>
ok :)
<Regenaxer>
There is not much specialized string manipulation in pil
<Regenaxer>
Usually just list processing
<Nistur>
Boom. Proof of concept, I have a simple program which goes through a bunch of image files and, using imagemagick, resizes them to thumbnails... I am doing it inefficiently for now (creating a "wand" per image) but... it works! Mwahaha
<Regenaxer>
Congrats! :)
<Regenaxer>
I usually just do (call "convert" "-geometry" "32x35" "foo.png" ...
<Regenaxer>
Do you think this is so much slower?
<Regenaxer>
Considering the overhad it has anyway?
<Regenaxer>
At least this is the reason I did not build many DLLs in pil32
<Nistur>
I am going to be doing a lot of operations on the images
<Nistur>
so if I can use the libraries, then I can keep them resident in memory, rather than writing out the files every time
<Nistur>
sec
<Regenaxer>
I see, you keep the image data in memory instead of files?
<Nistur>
yup
<Nistur>
Images have a transparent background (so I can theme the final instructions with scripts, rather than re-do renders which take 20-45 minutes each)... so first step is to generate the background, and also stick a number for the step on it: https://github.com/nistur/lips/blob/master/lips#L51-L53
<Nistur>
there's also a convoluted step for generating a cover page, and I have more bits I need to add for some introduction pages and also sub-model steps, but yes... there are a lot of things it needs to do
<Regenaxer>
makes a lot of sense then
<Nistur>
that's what I thought :P I'm hoping it doesn't need _too_ much memory :P
<Regenaxer>
right :)
<Regenaxer>
Must go, bbl
<Regenaxer>
afp
<Nistur>
see ya
heowbert has joined #picolisp
<heowbert>
Hey, anyone have tips on using PicoLisp for shell scripting? ... particularly using pipes and stdin/out? Feel free to point me to the RTFM, I may have missed it.
<Nistur>
heowbert: you can (call "cmd" "param1") etc so you should be able to do it quite easily
<Nistur>
I'm currently in the process of replacing some shell scripts I wrote, so I may end up doing this to get some of the functionality working and I keep a 'working' system, while I replace bits in lisp
<heowbert>
What happens if I pipe in the output of 'ls', do I get a list of filenames or an IO handle?
<Nistur>
list of filenames
<heowbert>
BTW, Im looking at your exact usecase
<heowbert>
Great! Thansk
<Nistur>
heowbert: I think, anyway, let me check
<Nistur>
heowbert: I think you're probably using "exact" too loosely here :P
<Nistur>
so you can, you just have to invoke picolisp with - before your parameters
<Nistur>
Regenaxer: wb
<Regenaxer>
Nistur, heo
<Regenaxer>
'call' is not the right way, rather 'in'
grp has quit [Ping timeout: 240 seconds]
<Regenaxer>
and 'pipe'
<Regenaxer>
"ls" is actually easier with (dir)
<Nistur>
oh, that reminds me, Regenaxer, I setup qemu with pilOS :D
<Nistur>
I REALLY want to get this running on bare metal and to actually try to use it... but I don't have a spare x64 laptop
<Regenaxer>
ok :)
<Regenaxer>
On qemu no problems?
<Nistur>
yeah :)
<Regenaxer>
ok
<Nistur>
Hrmmm, I wonder if it'd boot on my awkward Asus Transformer... I have grubia32.efi running so I can boot Ubuntu... but maybe if I can dig out an SD card I can install it on that..
<Nistur>
grub should be able to boot it
<Regenaxer>
PilOS in the current version depends on a fully supported BIOS
<heowbert>
That's it, unsurprisingly named argv, thanks!
<Regenaxer>
It ran well on my old Asus notebook
<Regenaxer>
heowbert, yep :)
<Nistur>
Regenaxer: well, if it depends on BIOS, then I'm probably out of luck, this has UEFI, and a particularly awkward one at that :(
<Nistur>
also... is there a way to change the background colour from blue? :P
<Regenaxer>
I have a more involved pipe example here: software-lab.de/pipes.l
<Regenaxer>
Yes, it is hardcoded somewhere
<Nistur>
ahh, so it needs a rebuild then
<Nistur>
that's a shame
<Nistur>
no (setq background_colour 'black)
<Nistur>
:P
<Regenaxer>
nope, it is on x86 assembly
<Regenaxer>
Probably in "x86-64/beg.l"
<Regenaxer>
in clearScreen
<Regenaxer>
mov $0x1F201F201F201F20, %rax # Blue background, white foreground, blank spac
<Regenaxer>
: en
<Regenaxer>
:)
<Nistur>
:P
<Nistur>
I will not change that now, as I didn't download the source, just the image
<Regenaxer>
So we are very far below a 'setq' here ;)
<Nistur>
well, it could be in a location that could be retrieved from here, and set from a setq
<Nistur>
:P
<Nistur>
The whole system should be fully customisable! :P
<Regenaxer>
It is simply a (cd pilos; make; make clean)
<Nistur>
:P
<Regenaxer>
Builds pilos/x86-64.img
<Nistur>
shame it's not x86, I have plenty of spare x86 machines :P
<Regenaxer>
(I also don't remember. I'm seaching .bash_history ;)
<Nistur>
I have a few laptops spare, none newer than 12 years I think (one mid-late '90s)
<Regenaxer>
well, it needs x86-64 cause it is built from pil64
<Nistur>
yeah, I gathered :P
grp has joined #picolisp
<rick42>
hello lispy peeps
<rick42>
i hope everyone is well
<Regenaxer>
Hi rick42! Yep, all well! :)
<rick42>
wonderful!
<Nistur>
Regenaxer: all it means is that I need to source more x64 devices from somewhere ;)
<Regenaxer>
haha, I was afraid that you have too many
<Nistur>
(actually, it's a PC-7100, but the page for that is less descriptive, and it's more or less the same)
<Nistur>
too much to ask to get pil working on an 8086, I guess? :P
<Regenaxer>
Well, I did have a MS-DOS version of pil running in 640 KiB
<Nistur>
:D
<Regenaxer>
I think it is also somewhere in the museum we looked at these days
<Nistur>
you realise that if I'm given the chance, I'm going to try and get it running on all my things... All of them.
<Nistur>
I think I still have the homebrew Nintendo DS toolchain set up, that's always fun, I like getting things running on that because it's relatively easy to do (it's just an ARM9 CPU with ARM7 coprocessor) with a gcc based toolchain, and it's nice to get things running on a(n otherwise closed) platform
<Nistur>
s/platform/handheld platform/
<heowbert>
Whats the status of running it on a microcontroller?
<Nistur>
again, like getting it running on the PS2, there's little actual point in doing so, it'd just be fun :)
<Regenaxer>
heowbert, miniPicoLisp runs on embedded, but is limited in functionality
<Nistur>
if I still worked at my previous job, I'd get it working on PS4 and that might _actually_ be useful :P
<Nistur>
but I don't have a PS4 devkit here
<Nistur>
Regenaxer: I somehow need about a month off work, paid, so I can spend/waste the time getting picolisp running on every computer/console/toaster I own.
<Regenaxer>
You need, and also get it?
<Nistur>
hmmm?
<Regenaxer>
Your employer agrees?
<Nistur>
I don't think I'd get a month holiday approved, and I don't think I have that many days left this year :P
<Nistur>
no
<Nistur>
this was a dream :P
<Regenaxer>
:(
<Regenaxer>
You can explain that the time is not wasted :)
<Nistur>
apart from things you already have it working on, I think I can easily get it working on Nintendo DS and PS2... PS3 requires me to install Linux onto it, which is fine, but I don't want to do that with my current PS3, so I'll need to source another one :P These will all be homebrew because I don't have official devkits at home... those things are _expensive_ (and also technically illegal to own)
<Nistur>
I was thinking that I _should_ also be able to get it running on Atari Jaguar... the main CPU is an M68k... but it also has two 32 bit coprocessors (custom silicon)... and I'm actually relatively familiar with the hardware, because I've been researching it for another project
<Nistur>
but if you have a mac m68k version, I could maybe pull out the mac specific bits and make it work on the Jaguar... not sure
<Nistur>
you've never had it running on 8 bit CPUs, so that rules out a bunch of my devices (Psion Organiser, Amstrad NC-100, Game Boy...)
<Nistur>
ooh, Game Boy Advance has an ARM7 CPU
<Nistur>
that might work
<Nistur>
I have a GBA toolchain set up too :P
<Nistur>
screen text logging exists in most of the homebrew toolchains, and I've set up scrolling output, so I could get it to output stuff to prove it was working
<cess11_>
Slightly off-topic, someone figured out a way to exfiltrate data from air gapped box by modulating CPU and feeling it out through the power cables, https://arxiv.org/pdf/1804.04014.pdf .
<cess11_>
10 bit/sec isn't much but might be enough. And there will be gadgets for doing this just around the corner.
<Nistur>
I also have a Wii toolchain set up... or used to... I never did anything with that...
<Nistur>
not of the others I've at least made a "Hello World" to check the toolchain worked :P
<Nistur>
hrmmm
<Nistur>
I have some SPARC machines, but I'm not sure how interesting they'd be to get it running on
<Regenaxer>
tankf33der has pil running on some Sparcs
<Nistur>
cess11_: I'm sure I saw something at some point with people... listening to fluctuations in CPU audio output or something?
<Nistur>
tankf33der: want some more SPARCs? I have some I need a good home for :P
<tankf33der>
solaris 10 and 11, x64
<tankf33der>
Nistur: i dont want, solaris is dead :)
<Nistur>
tankf33der: I have solaris 8 and 9 I believe...
<Nistur>
I would love an SGI machine of any kind for my collection to be honest
<Nistur>
but I haven't sourced one yet :P
<cess11_>
Nistur: That paper is about doing it covertly with malware through the electricity net.
<cess11_>
As in datacenters with high profile customers now need to separate electricity nets in their premises, not just the machines, networks, storage.
<Nistur>
ahh
<Nistur>
but yes, Regenaxer: something I enjoy doing is making things run on all kinds of hardware for fun, and I would love to make picolisp do so; it seems the perfect kind of project for it :P I would just need to carve out enough time, and maybe buy the odd machine or four to make it a bit easier :
<Nistur>
:P
<Regenaxer>
great :)
<Nistur>
I doubt it would add anything to anything. It's not like being able to say that some random guy ported it to PS2 in 2018 would make it any more awesome than you having maintained and used it for 30 years :P
heowbert has quit [Quit: heowbert]
<Nistur>
I have almost all of tomorrow "off" (no work, and my wife's going to London... although she's already tasked me with some gardening work that I don't really want to do)
heowbert has joined #picolisp
<Nistur>
I'll definitely be working on my current project a bit, but I maaaaaaay see what toolchains I have set up, and just throw pil32 at it, see what happens :P
<Nistur>
there are a few things which _obviously_ won't work (input and output most notably)
<Nistur>
it should work on PS2 easily enough because that knows what a keyboard and terminal is, at least when building with the linux devkit
<Regenaxer>
And go down to miniPil if everything else fails
<Nistur>
but other things not so much
<Nistur>
yeah
<Nistur>
most (homebrew) console devkits assume a single binary containing all the data, so I may have to add an archive to the end of the executable which contains scripts
heowbert0 has quit [Read error: Connection reset by peer]
<Nistur>
Regenaxer: it has become apparent that an imagemagick wrapper won't just be single line wrapper calls... there are named values, like enums for example, which I'm going to add so the code reads nicer
<Regenaxer>
ok
<beneroth>
fun read :)
<beneroth>
go Nistur go :D
<Regenaxer>
:)
<beneroth>
tankf33der, thx to you for the efforts with signify
<Nistur>
beneroth: go me go what?
<beneroth>
I'm cheering you for wanting to port pil everywhere & getting pilOS further
<beneroth>
:)
<Nistur>
ahh ok :P
<Nistur>
my current main project is to wrap imagemagick though and use it to create pretty Lego instructions :P
<beneroth>
yeah I read all your essays here :P
<Nistur>
http://ix.io/17Hp <-- that's my current proof of concept for it. It takes the renders and creates thumbnails
<beneroth>
yep, I have now a folder named "nistur" in my picolisp folder
<beneroth>
:P
<Nistur>
I don't like it much because it reads backwards, and it's generating a new 'wand' for each image, which it doesn't need to
<Nistur>
beneroth: hmm?
<Nistur>
why am I in a folder?
* beneroth
downloaded the file and put it in a folder with your name so he knows who to thank
<Nistur>
hah
<Nistur>
very shortly I will be putting the imagemagick code on github so I don't lose it :P
<beneroth>
my ongoing big project is building an additional layer on the pilDB for flexibility/schema migrations/data change logging and building a web app platform on top of that
<beneroth>
end goal is kinda an engine for apps and browser games. it's not feasible for me to create a game (too much of a resource cost / gamble) so I build the tooling for it and try to make business products/services out of the fitting parts along the way
<beneroth>
or something like that
<beneroth>
no thumbnail generation in it yet :P
<Nistur>
heh, well the thumbnail generation was just the first MagickWand tutorial
<Nistur>
I don't ACTUALLY want to create thumbnails
<beneroth>
I know
<beneroth>
I will want to do thumbnail generating, and other pic editing stuff. I strongly believe more pre-processing should be done on the server side than offloaded to client devices running huge JS stuff.
<Nistur>
What kind of games do you want to make btw?
<beneroth>
nothing specific planned for any foreseeable time.
<beneroth>
I got a notebook with some ideas, especially concepts for a game as a a mix of RPG and 4X strategy.
<beneroth>
for now its more about business web apps
<Nistur>
beneroth: I was going to suggest a game
<beneroth>
ah?
<Nistur>
Neptune's Pride
<Nistur>
that's the name
<Nistur>
sort of a stripped down Master of Orion
<beneroth>
sounds nice. never heard of.
<beneroth>
ah
<Nistur>
multiplayer
<Nistur>
played over weeks
<Nistur>
lots of backstabbing
<beneroth>
nice
<beneroth>
I liked Darkfall Online, if that tells you something.
<beneroth>
I'm currently playing "Birth of Empires" on the tablet. it's mainly single player, though
<beneroth>
FOSS
<beneroth>
looks like I have to try this Neptune's Pride. thanks for the hint, Nistur !
<Nistur>
:)
<Nistur>
it was lots of fun
<beneroth>
I somehow missed it completely
<beneroth>
how do they finance themselves?
<Nistur>
you can play for free in random games
<Nistur>
or to play in games with people, you buy tokens
<Nistur>
if I recall correctly
<beneroth>
ah, interesting model
<Nistur>
I cannot recall if they do it, but I'd also gift people with a token for winning a game
<beneroth>
T
<beneroth>
(= agreed)
<Nistur>
because you want to keep people playing, and if they can earn ways to play with friends, they're more likely to get invested long term, and eventually also put money in
<beneroth>
well that most of the game market is turning into generating addiction with the item shop model is horrible.
<Nistur>
yeah
<Nistur>
I am very well aware of that :(
<Nistur>
most of us devs are against it, but the suits push for it because it makes money
<beneroth>
even Nintendo is trying it out. they warned about it 10 years ago or so, but its just the most lucrative model
<beneroth>
aye
<Nistur>
and if the person who signs your paycheque asks for something...
<beneroth>
another reason to stay in business. by selecting the clients a bit, you can actually do something which might be a net good indirectly ;)
<Nistur>
I'm happy staying in games, but I'd like to get out of the free to play stuff if I can
<beneroth>
so I want a powerful flexible database / app engine, so I can realise game mechanics which are hard to copy :P
<Nistur>
I enjoyed it much more when I was doing premium games
<beneroth>
I guess the highs are higher, but the so are the investment costs / barriers to entry
<beneroth>
the flow of cheap shit / spam / discorability issue is also a big problem. will only get worse, I guess
<beneroth>
serious gaming is rising though, that's good I think :)
<beneroth>
you are in UK?
<Nistur>
yup
<Nistur>
I need to win the lottery so I can make the games I want to make :P
<beneroth>
Switzerland. so not much of a game industry here, though there is an education path around now for 10 years
<beneroth>
yeah. problem is, likelihood of dying on the way to participate in the lottery is higher than winning it.
<Nistur>
I think they changed the rules here a few years ago
<Nistur>
I don't know what the chances are now
<Nistur>
but it used to be 1:13,983,815
<Nistur>
and I have no idea why I remember that number
<beneroth>
so I gamble on doing some good SMB software products.
<beneroth>
haha
<Nistur>
that was the chances of winning the jackpot I think
<beneroth>
winning alone as a single winner? that is also be taken into account
<Nistur>
no, that is not taken into account
<beneroth>
I guess the odds changes with the size of the pot and the general economic situation, too
<Nistur>
that is just getting all the correct numbers
<beneroth>
yeah
<beneroth>
better start a lottery company :)
<beneroth>
national lotteries were mainly founded to get the money for warfare. somehow people like it more than taxes :)
<Nistur>
a former colleague used to call it a tax on people who can't do maths
<beneroth>
haha, T
<beneroth>
as in animal training/conditioning, it works better when the outcome has some randomization
<beneroth>
hope is a great motivator
<Nistur>
heh yes
tankf33der has quit [Quit: Connection closed for inactivity]