alexshendi has quit [Read error: Connection reset by peer]
aw- has joined #picolisp
reich has quit [Ping timeout: 260 seconds]
<aw->
cess11_: the link to your asciinema post from your dev.to page is broken
<aw->
as well as your Patreon and Youtube links, all broken
reich has joined #picolisp
f8l has quit [Ping timeout: 256 seconds]
reich has quit [Ping timeout: 240 seconds]
dtornabene has joined #picolisp
reich has joined #picolisp
<Regenaxer>
Good morning
<Regenaxer>
Nistur, are you using pil64? 'native' is available only there
f8l has joined #picolisp
reich has quit [Quit: WeeChat 1.6]
<Regenaxer>
Nistur, there is no hard rule for naming gue functions to 'native'. You can do iy like in @lib/openGl.l (glue functions) or in @lib/vip.l (call 'native' directly inline; this is what I do usually)
aw- has quit [Quit: Leaving.]
<Nistur>
Regenaxer: I was using x86 and arm... so yah... not supported... that sucks :(
<Regenaxer>
pil32 ?
<Nistur>
yup
<Regenaxer>
arm is Pi as you said. yes
<Regenaxer>
Sucks, yes :) pil32 is limited in other regards too
<Regenaxer>
no namespaces or coroutines
<Regenaxer>
emu works, but is slow
<Nistur>
the taptop I am using at the moment, despite having an x64 CPU, has x86 OS on it, because it's a pain in the neck to get anything sane installed on it
<Regenaxer>
:(
<Nistur>
it has 32 bit EFI, which means most isntall media don't work out of the box
<Nistur>
and on top of that, it's weird hw
<Regenaxer>
You can get native calls on pil32 by writing a .so
<Nistur>
most peripherals (wifi etc) are not on PCI or USB, but on SDIO
<Regenaxer>
see misc/fibo.l or misc/crc.l
<Nistur>
I intend to get arch (x64) running on it, but I haven't yet had the time to
<Regenaxer>
even inline-C works
<Regenaxer>
ok
<Nistur>
ok, I'll try that
<Regenaxer>
Inline C is fine if you have gcc at runtime
<Nistur>
this should just be for my dev machine. Testing and target should be x64
<Regenaxer>
I was wrong about misc/fibo.l, no inline
<Regenaxer>
anyway
<Nistur>
as I'm attempting to use imagemagick, I _COULD_ just call the executables, but it'd be nice to not do that, and have more direct hooks into the libraries, I think
<Nistur>
but I've always got a fallback, if I need it :P
<Regenaxer>
yes, but I would not worry to call the executables
<Regenaxer>
not so much more slow I think
<Nistur>
I think in my case it might make a difference because of what I'm doing
<Nistur>
if I use the executables, I need to write temporary files, I cannot do it all in one operation
<Nistur>
if I use the libraries, I can pass around the internal image formats and do what I want with them before outputting them
<Regenaxer>
ok, then a .so is the best
<Nistur>
I might end up writing out the temporary files for debugging but y'know
<Regenaxer>
Examples are the ht and ext libs made by src/Makefile
<Nistur>
ok, I'll try it today
<Nistur>
I'm in the process of eating breakfast, so it's difficult to talk, let alone code while eating :P
<Regenaxer>
if you build a su named "im", you can call the functions as im:foo
<Regenaxer>
no overhead at runtime
<Nistur>
nice. That works great
<Regenaxer>
hehe, take time! :)
<Nistur>
I was going to just do im_foo for the naming :P
<Nistur>
but : makes it easier :)
rob_w has joined #picolisp
<Regenaxer>
yes, and it uses the built-in dlopen()/dlsym() mechanism
<Regenaxer>
im:foo is a normal symbol then, defined as a new built-in
<Regenaxer>
ie a C function pointer
<Regenaxer>
The tedious thing (as compared to pil64 native) is that the C functions have to evaluate the arguments themselves
<Regenaxer>
I can assist
<Nistur>
I will let you know how I get along later :)
<Regenaxer>
great :)
<Nistur>
right now, I need to trundle off to work
<Regenaxer>
:)
<Nistur>
I'll give it a poke while compiling this morning :P
<Nistur>
because of the lack of swords in the office
Regenaxer has quit [Remote host closed the connection]
Regenaxer has joined #picolisp
orivej has joined #picolisp
<Nistur>
Regenaxer: ok, I will admit that I don't REALLY know what's going on in crc.l... but I'm going to try and make something like void hello() { printf{"Hello World
<Nistur>
... the enter key on this keyboard is in the wrong place
<Nistur>
*printf("Hello World\n"); }
<Nistur>
and call it from within pil
<Nistur>
if I can do that, I'll be happy for now :P
<Regenaxer>
yes, good start
<Regenaxer>
The C function must be written just as the other built-in in pil32
<Nistur>
yup
<Regenaxer>
The first step is probably to make a script to compile the source to a shared object file
<Regenaxer>
A Makefile is overkill, I would write a one-line script
<Nistur>
hmm?
<Regenaxer>
Calls to compiler and linker with the proper flags
<Regenaxer>
as in src/Makefile for the $(lib)/ext$(dll) target
<Regenaxer>
With the variables substituted with the proper values for the platform
<Regenaxer>
and perhaps 'strip' too
<Regenaxer>
So just a 3-liner
<Nistur>
I'm probably still a bit tired here, so apologies if I'm being dumb... but crc.l you mentioned previously had some inline C, which it uses gcc.l to compile (I assume)... could I not do that? I already have a .so from imagemagick...
<Regenaxer>
yes, inline C is easier. No script needed
<Regenaxer>
But you need gcc on the target
<Regenaxer>
With a build script you can make a DLL as lib/ht and lib/ext
<Nistur>
ahh ok, so there are 3 options, inline C, making a .so, and then native call...
<Regenaxer>
yes, but the last option only pil64
<Nistur>
I think I think I think... rarely, but I do on occasion, I will use the inline C for now because all my machines _do_ have gcc... and it will let me get started. The .so and native calls are things I can wrap and replace the inline stuff with down the line once I have this working.
<Regenaxer>
and for pil64 the second option must be assembly
<Regenaxer>
yes, good
<Regenaxer>
inline C is the most flexible
<Regenaxer>
Just takes a moment on startup to compile
<Nistur>
Regenaxer: random unrelated question to my project, just curious... are there examples for using picolisp embedded in other applications? I have another thing in mind (for if/when I ever complete this) which might be "fun" to add lispy scripting support to
<Regenaxer>
I have no such example, except for calling pil from bash
<Nistur>
hmmm, would it be possible to (and I realise I'm hugely over simplifying things here) comment out main() and build as .so or .a? Or are there... insurmountable architectural hurdles?
<Regenaxer>
main() is needed for initialization
<Regenaxer>
And I don't see how it makes sense to call isolated pil functions
<Nistur>
obviously the initialisation {c,w}ould be done in the calling code
<Regenaxer>
yes
<Regenaxer>
but you must pass in Lisp structures
<Regenaxer>
Much better to call pil as an external process
<Regenaxer>
It could be running permanently, and you pass in RPC commands
<Regenaxer>
But still I think this is not useful
<Regenaxer>
Better just call pil with command line args
<Nistur>
well, if it were hooked up to a game engine for example, then you could set up an environment and it would then stay persistant throughout the lifetime of the executable, but you could call into it when you wanted, if you call pil with command line args, you will need to reconstruct the environment every time
<Regenaxer>
right
<Regenaxer>
So then you let it run as a separate process
<Regenaxer>
Just like pil lets Java run as a separate process in @java/ or on Android
<Regenaxer>
There is a very powerful RPC in pil
<Regenaxer>
ie. the PLIO stream format
<Regenaxer>
PLIO libs for C/C++, Java and (one-way only) JavaScript
<Nistur>
hmm ok
<Regenaxer>
Calling Lisp functions in an isolated way won't work I think
<Regenaxer>
it assumes Lisp cell pointer structures, nearly impossible to build and maintain in other processes
<Nistur>
ok
<Regenaxer>
Imagine calling bash internals from the outside. Also impossible
<Regenaxer>
It just makes no sense I think
<Nistur>
well, I can give a lot of examples of languages that are used for scripting things like that, game engines specifically
<Regenaxer>
For example, which pil function would you call?
<Regenaxer>
At the moment I cannot imagine a single one that could be called by itself
<Regenaxer>
They *all* expect to be embedded in a list (fun 'arg1 'arg2 ...)
<Regenaxer>
How to call that from outside?
<Regenaxer>
(fun 'arg1 'arg2 ...) is a pointer into the heap, to a linked list of poiter cells
<Nistur>
simple example, I could have a game_update in a game.l which could contain some game logic (and might then obviously call back into C/C++/whatever)
<Regenaxer>
yes, so you send a RPC command to the Lisp process
<Regenaxer>
that's trivial
<Nistur>
sure. An RPC works :) I didn't mean to suggest it didn't
<Regenaxer>
But to *call* into it, you need all the env
<Regenaxer>
the stack for example
<Regenaxer>
The pil stack contains linked lists of structures which may be traversed backwards
<Nistur>
I was just saying that most scripting systems I've seen, in gamedev at least, don't spin up a process for the environment, you just have... well, take lua for example, you have the entire lua environment in a lua_State* and you do something like lua_getglobal( state, "foo"); lua_pcall( state, 0, 0, 0 ); // calls foo()
<Nistur>
I'm not saying that pil {c,w,sh}ould work this way
<Regenaxer>
In fact, pil64 has a lisp() callback from C
<Nistur>
I was just curious if it were possible, as it's how I've seen a lot of other scripting systems being used
<Regenaxer>
But pil is expected to be the outer part, the main
<Regenaxer>
you can call from C: long lisp(char*, long, long, long, long, long);
<Regenaxer>
the first arg is the name of a pil function
<Regenaxer>
see (doc 'native)
<Regenaxer>
But lisp() is limited to 5 numbers as arguments
<Regenaxer>
simply because C cannot pass non-numeric data
<Regenaxer>
there are no symbols or lists
<cess11_>
Disguised assembler.
<Regenaxer>
yep
<Regenaxer>
generic assembler
<cess11_>
A pil process is a very, very cheap procecss. I would say it is fine to use one of those for scripting another process.
<cess11_>
s/procecss/process
<Regenaxer>
T
<cess11_>
If the game engine or somesuch crashes or otherwise gets messed up it doesn
<cess11_>
't mess up the scripting environment.
<Nistur>
well, if there's a crash, you don't normally need the scripting environment to stay running
<cess11_>
You can inspect it to determine if it was the cause of the crash.
<Nistur>
I will certainly admit that is a serious plus point, but then you also have the possibility that the crashing game will leave an orphan pil process. Need to maintain that you don't keep spinning up new ones when there's old ones, or that you clean them up properly... and that you wouldn't accidentally clean up a non-orphaned process (ie one started by another instance, or a test pil instance or...)
<cess11_>
killall pil
<cess11_>
ls | grep pil
<Nistur>
but that would kill ALL pil's and not just the ones which were orphaned
<cess11_>
Yes. You could also just keep track of the PID:s.
<Regenaxer>
or use pkill with proper arguments
<Regenaxer>
Normally those pil processes terminate when the opposing pipe is closed
<Regenaxer>
you can always program it that way
<cess11_>
Having some orphans hanging around is OK in my opinion. I litter with REPL:s lying around where I've done stuff and then went on to do something else, having some from crashes wouldn't be much different.
<Regenaxer>
yeah
<cess11_>
And it is easy to parse out PID:s and probe them by pipes or RPC to see if they are important.
<Regenaxer>
I have (retire) in all gui processes, so they clean up after some time
<cess11_>
One could also write little logging functions that output PID and some data about what they are for and how it goes.
<cess11_>
I think I ought to use 'retire more but it is usually fine in my environment to just kill them off or reboot the machine.
abel-normand has joined #picolisp
abel-normand has quit [Remote host closed the connection]
<Nistur>
Regenaxer: how would one use the inline'd func? I have it compiling void hello() { printf("Hello World from C\n"); } and I can see the 'hello' object in my tmp, but i'm not sure how I'm expected to call it... (hello) doesn't seem to work
<Nistur>
(gcc "hello" NIL 'hello) is copied/modified from the crc example
<Regenaxer>
If you make a separate dll, it is (lib:hello)
<Regenaxer>
otherwise just (hello) iirc
abel-normand has joined #picolisp
<Nistur>
Hmmm, it wasn't a dll, and I'm getting "/users/nistur/.pil/tmp/87216/hello:hello" -- Undefined
<Regenaxer>
No, just (hello)
<Nistur>
yes
<Regenaxer>
like (crc 1 2 3)
<Nistur>
I just called (hello)
<Nistur>
I _think_ this might be because gcc != gcc
<Nistur>
gcc throws a gcc warning about function declaration not being a prototype
<Nistur>
redundancy in that sentence
<Nistur>
but anyway
<Regenaxer>
{ printf("Hello World from C\n"); } is not enough
<Regenaxer>
You must return a Lisp item
<Regenaxer>
eg Nil
<Regenaxer>
or TSym
<Regenaxer>
otherwise the REPL might crash when it tries to print the -> result
<Nistur>
ok, I just had this in a script with (bye) right after
<Nistur>
but I shall change it to do so
<Regenaxer>
ok
<Regenaxer>
or, try the opposite and do "return 0" to surely crash it in the REPL ;)
<Nistur>
is the return type just 'any'
<Regenaxer>
yes
<Nistur>
ok, that works then :)
<Regenaxer>
:)
<Nistur>
and, of course, adding (void) fixes the gcc warning :)
<Regenaxer>
yep, but not the crash :D
<Nistur>
any hello(void) printf("Hello world from C\n"); return Nil; }
<Regenaxer>
Perfect
<Nistur>
can I only compie one function at a time like that, or can I put a bunch of functions in there? I don't REALLY understand the syntax of the gcc function
<Regenaxer>
you can put many at once
<Regenaxer>
Just declare (gcc "myLib" NIL 'foo 'bar 'mumble)
<Nistur>
what is the "myLib" bit?
<Regenaxer>
The name of the library file
<Regenaxer>
(tmp S ".c") ... (tmp S ': (arg))
<Nistur>
ok, so that can be anything... Hmmm... can I scope the functions to be myLib:foo myLib:bar etc?
<Regenaxer>
they are internally, but 'set' into 'foo'
<Regenaxer>
I recommend to make a pre-built lib
<Regenaxer>
then you call myLib:foo
<Nistur>
fair enough. I will probably do that sooner rather than later then :)
<Regenaxer>
It is like in
<Regenaxer>
: (ht:Fmt 'abc 123)
<Regenaxer>
-> "$abc&+123"
<Regenaxer>
The pre-built lib is also not much more work
<Regenaxer>
Same C functions, just a make script or Makefile
<Regenaxer>
In any case pil64 would be preferrable in the long run
<Regenaxer>
If possible, try to get it up
<Nistur>
pil64 only runs on one of my myriad of computers :P And the one I have on least frequenly
<Regenaxer>
Not to have to write these libs again later
<Regenaxer>
Then go with emu for these experiments
<Regenaxer>
if not very time critical
<Regenaxer>
You can call 'native' also in emu, but only for C functs with max 6 args
<Regenaxer>
Not sure if and how emu builds on MacOS though ... (?)
<Regenaxer>
Somebody tried, but I forgot what happened
<Regenaxer>
You could do in another directory (cd src64; make emu)
<Regenaxer>
needs a running pil however (pil32 is fine)
<Regenaxer>
So better in the same dir, after doing (cd src; make) to get pil32 first
<Nistur>
Well, I have options :P I think that's the main thing
<Regenaxer>
T
<Nistur>
make emu in src64 doesn't appear to work straight off on macOS... complains about not having emu.symtab
<Regenaxer>
hmm, should be built in the process
<Regenaxer>
IIRC emu.symtab is needed after bin/picolisp is done, to build lib/ext and lib/ht
<Nistur>
I will look into it more a bit later... but right now, it's food time (I've actually made more progress in my work than on most days, prodding picolisp makes me more efficient...?)
<Regenaxer>
good :)
<Nistur>
also, I kind of want to get started with actually working on my project, now that I have picolisp set up and working... otherwise I'll be fiddling with setup ad infinitum... If it all works but it's jyst a bit grotty... I can rewrite that bit in future potentially
<Regenaxer>
true, just cause pil32 is not well supported in the future
<Regenaxer>
And the native stuff is not portable pil32 -> pil64
<Regenaxer>
So pil64 is more on the safe side
<Regenaxer>
I do use emu even in production code if necessary (currently for users with old Android phones)
<Nistur>
so you make them slower? :P
abel-normand has quit [Ping timeout: 264 seconds]
<Regenaxer>
yes, usually not noticeable
<Nistur>
but yes, I understand what you mean
<Regenaxer>
It depends on the app, on Android most happens in the Java toolbox anyway
<Regenaxer>
In general however emu is 10 to 20 times slower than pil64
<Nistur>
the point right now is though that I have pil32 running on all my machines, so I can work with that. I can get the core functionality running, and I'll put the native glue in a separate file. When I have the script doing what I want, I can coax pil64 into working, and rewrite the glue... it should be a relatively minimal rewrite
<Regenaxer>
right
<Nistur>
Regenaxer: just curious, do you still have old versions? I have a couple of old Macintoshes which would be fun to get it running on... if old versions are still floating around :)
<Nistur>
... I just got from the wikipedia page that it was written for macs initially
<Nistur>
I assumed they were 68k macs
<Regenaxer>
yes, all released versions are still on the download page, but I don't see why they should be useful except for historical reasons
<Nistur>
the Y is upside down on purpose... an invader comes on, takes it off, then returns with it the right way around :P
<Nistur>
buuuuuuut I think the thing I'm most "proud" of with 'tlvm' is this: https://github.com/nistur/8080bf because I actually wrote a non-trivial bit of 8080 code there :P
<Regenaxer>
hehe, brainfuck :)
<Nistur>
:D
<Regenaxer>
tough
<Nistur>
it doesn't do input, because I couldn't do blocking input in raw 8080 in the space
<Nistur>
beneroth: I said something interesting? When?
<Regenaxer>
Hi beneroth!
<beneroth>
Hi Regenaxer!
<beneroth>
Nistur, a whole bunch, at least for me :)
<beneroth>
welcome to our little community :)
<beneroth>
I got into programming through hobby gamedev, but ended up developing business stuff for the moment
<Nistur>
part of me wishes I'd gone down the hobby/homebrew/indie route, because professional gamedev is quite... disillusioning :P and stressful... and underpaid...
<Nistur>
but at the same time, I have actually had a good time, and I've got my name on some big titles
<Nistur>
and learned a lot
<Nistur>
I think if I tried the hobby stuff now, I could actually make _something_ whereas before I'd probably flounder and fail a lot
<grp>
tankf33der: nice! must be blazing fast :¬)
<grp>
tankf33der: if you wish to benchmark it right, I suggest using a ramdisk, maybe loop the check a few times for that (all this so you won't put fs caches into the equation)
<tankf33der>
ok
<beneroth>
good point grp
<grp>
;¬)
libertas has joined #picolisp
karswell_ has quit [Remote host closed the connection]
karswell_ has joined #picolisp
<Nistur>
Ok, I'm home so I don't have work to do, and my wife is busy with her stuff. Time to get some lisping going!
alexshendi has joined #picolisp
<Nistur>
Regenaxer: I cannot get my lib to load :(
<Nistur>
I was going to use inline gcc because it would have been easier for me, but I realised that passing flags to gcc would have been a bit of a pain, so I thought I'd make the lib now
<Nistur>
I am not sure if I'm building it right, I'm not sure if I'm linking it right, I'm not sure if I'm loading it right :P
<Nistur>
but I always get Undefined
<Nistur>
I've copied the makefile for ext pretty much verbatim, so I think that should be ok. It's successfully making a shared object, which claims to be a shared object with file
<Nistur>
I've named it 'libpicoim" (pico ImageMagick... I think it may be renamed becaus picoim is a little silly)
<Nistur>
and I have started pil + in the directory that it's in
<Nistur>
and done (load "./libpicoim")
<Nistur>
-> NIL
<Nistur>
: (libpicoim:genesis)
<Nistur>
!? (libpicoim:genesis)
<Nistur>
libpicoim:genesis -- Undefined
<Regenaxer>
Hmm, undefined means that either dlopen() or dlsym() fail
<Regenaxer>
It must be the wrong file format
<Regenaxer>
Compare the output of the 'file' command of your lib with other libs in the system
<Nistur>
only difference is that I haven't stripped it... surely it canot require stripping...
<Regenaxer>
here "ELF 64-bit LSB shared object" and "dynamically linked"
<Nistur>
nm gives me undefined symbols for Nil and puts, but I guess that's right
<Nistur>
right now genesis is just my previously working Hello World
<Nistur>
it WILL call MagickWandGenesis
<Nistur>
but I've not linked in that, or done anything else yet
<Nistur>
Regenaxer: (load "@lib/ext") appears to give me the same thing...
<Nistur>
can pil32 on ARM not load .so?
<Nistur>
maybe I should have stuck with inlining, and figured out the compile flags :P
<Nistur>
y'know what... I think I'll copy gcc.l into my project and tweak it to my needs for now :P
<Regenaxer>
undefined symbols for Nil and puts is all right, yes
<Regenaxer>
(load "@lib/ext") cannot be done
<Regenaxer>
'load' is for Lisp source
<Nistur>
-_- is that where I've been going wrong?
<Regenaxer>
Just calling (ext:Snx ...) etc
<Regenaxer>
: (ext:Snx "Alex")
<Regenaxer>
-> "ALS"
<Regenaxer>
'ext:Snx' is a symbol, initially undefined
<Nistur>
hmm, ok that works, but (libpicoim:genesis) still doesn't work
<Regenaxer>
So the error handler sees the ':', opens "lib/ext" with dlopen()
<Regenaxer>
loads the pointer to 'Snx' into the symbol 'ext:Snx'
<Regenaxer>
After that it *is* defined :)
<Nistur>
am I right that libpicoim is in the same directory that I'm currently in?
<Nistur>
I don't need to put it in somewhere specific?
<Regenaxer>
no, it is in the tmp dir
<Regenaxer>
and called with absolute path
* Nistur
blinks
<Regenaxer>
see "/users/nistur/.pil/tmp/87216/hello:hello" above
<Regenaxer>
"/users/nistur/.pil/tmp/87216/hello" was the file
<Regenaxer>
if not absolute, dlopen() searches LDLIBRARYPATH
<Regenaxer>
So I believe it is the internal file format is wrong somehow
<Regenaxer>
dlopen() fails
<Nistur>
LDLIBRARYPATH generally doesn't contain .
<Regenaxer>
Perhaps look with 'ltrace' ?
<Regenaxer>
dlopen() returns some error
<Regenaxer>
of dlsym()
<Nistur>
1hmmmmm
<Nistur>
ltrace just hangs
<Regenaxer>
oh
<Nistur>
I've manually hacked in some extra CFLAGS into the inline gcc and that will do for now... when I'm a little bit more comfortable with picolisp, I'll see if I can pass them through, but this is the first proper lisping I'm doing. I really don't think that my emacs configuration counts for much
<Regenaxer>
So with these extra CFLAGS it worked?
<Nistur>
inline C always worked
<Nistur>
the issue was just that I needed to link to non-standard libs, libMagickWand.so in this case
<Regenaxer>
ok
<Nistur>
what is the NIL parameter of the gcc call?
<Regenaxer>
An optional list of libraries
<Regenaxer>
Looks exactly what you need
<Nistur>
woo!
<Regenaxer>
:)
<Nistur>
I thought so :P
m_mans2 has joined #picolisp
m_mans has quit [*.net *.split]
<Nistur>
uuuuuummm... I'm not sure how I'm meant to be passing it
<cess11_>
'(library.so), perhaps.
<Nistur>
if that's the case, it's not quite what I need... there's more than just that to pass, include dirs and some -D'fines
<Regenaxer>
yes, or '("library1.so" "library2.so")
<Regenaxer>
ie transient symbols are enough
<Regenaxer>
such args could be passed here too
<Regenaxer>
(de gcc (S L . @)
<Regenaxer>
....
<Regenaxer>
(apply call L "gcc" ...
<Regenaxer>
all is prepended
<Nistur>
huh. I don't know what I did wrong before, but it works now... I tried it before and it just froze
<Nistur>
... usually I _do_ try and figure it out for myself before I come and ask in here
<Regenaxer>
Good anyway :)
<Nistur>
my next task is to figure out how to pass data between the languages, then I can actually write things!
<Regenaxer>
ok :)
<Nistur>
Well, I can pass strings back from C to lisp, that's a start :P
<Nistur>
I have discovered mkStr :P
<Nistur>
I haven't yet found a function that looks like I can give it a void* or something to pass the bits I need for imagemagick internally
<Nistur>
like a 'wand'
<Regenaxer>
yep, mkStr()
<Regenaxer>
or boxCnt() for numbers
<Nistur>
any genesis(any x) { return boxCnt( unBox( x ) + 27 ); }... (genesis 15) -> 969300863
<Nistur>
looks like unBox isn't doing what I was expecting
<Regenaxer>
evCnt(x)
<Regenaxer>
same as unBox(EVAL(car(x)))
<Regenaxer>
plus check for number
<Regenaxer>
This is what I meant that in pil each function controls the evaluation of each arg
<Regenaxer>
evCnt(ex,cdr(x)));
<Regenaxer>
any genesis(any ex) { return evCnt(ex,cdr(ex))) ...