<tankf33der>
it doesnt work and i dont see 'done message on screen.
<mtsd>
Yes, it's ok. Winter is coming, we have a beautiful morning. Sunny and a little cold
<Regenaxer>
:)
<mtsd>
How is Bayern now?
<Regenaxer>
cloudy
<Regenaxer>
yeah, seems wrong
<Regenaxer>
Perhaps (cons 'Lst (cons (8 . B) OldList)) ?
<tankf33der>
i got only one item back.
<tankf33der>
not array :)
<Regenaxer>
looking doc native
freeemint has joined #picolisp
<Regenaxer>
below "structures, passed as lists with"
<Regenaxer>
hmm
<Regenaxer>
(cons 'Lst (cons (8 B . 8) OldList)) ?
<Regenaxer>
I forgot :)
<Regenaxer>
"size and result specification in the CADR"
<Regenaxer>
So size is 8
<Regenaxer>
and (B . 8) means 8 byte array
<Regenaxer>
So (8 . (B . 8)) which is (8 B . 8)
<tankf33der>
yea, works now. thanks a lot.
<Regenaxer>
:)
freeemint has quit [Ping timeout: 245 seconds]
beneroth has joined #picolisp
freeemint has joined #picolisp
freeemint has quit [Remote host closed the connection]
freeemint has joined #picolisp
<Regenaxer>
Hmm, what to do? Give up pil21/32 ?
<Regenaxer>
Is 32 still important?
<beneroth>
Good morning
<Regenaxer>
Hi beneroth!
<beneroth>
is emu without pil32 possible?
<Regenaxer>
emu is pil64
<beneroth>
so: yes :)
<beneroth>
hmm
<Regenaxer>
I want to abandon pil32, pil64 and ersatz
<Regenaxer>
only pil21 :)
<beneroth>
uh
<beneroth>
why? is pil21 so awesome?
<beneroth>
is database format changing, same as in pil32 to pil64 switch?
<Regenaxer>
no, same as pil64
<Regenaxer>
No changes
<Regenaxer>
only minor
freeemint has quit [Ping timeout: 246 seconds]
<Regenaxer>
eg (arg) will not work
<beneroth>
how are libraries like ht implemented in pil21, is pilASM still a thing?
<beneroth>
uh
<aw->
hey beneroth!
<beneroth>
hey aw- !
<Regenaxer>
no pilAsm needed. All PicoLisp (kind of)
<Regenaxer>
Hi aw-
<beneroth>
I don't know enough about pil21 to have an opinion. is there a write-up somewhere? or all just chat history?
<Regenaxer>
ht will be the same, but also in mock-Pil of course
<Regenaxer>
Yeah, no write up yet :)
<Regenaxer>
All too much changing
<aw->
hi Regenaxer
<Regenaxer>
Reference is the source, pil21.tgz
<Regenaxer>
:)
<beneroth>
all I know about pil21: new pil edition, supposedly based in LLVM. no idea what this means in practical terms.
<Regenaxer>
yes
<Regenaxer>
The point is LLVM, I expect more portability
<Regenaxer>
iOS, MacOS
<Regenaxer>
The initial reason was RISC-V
<beneroth>
I see
<beneroth>
good spirit, though I don't know if there are even any RISC-V hardware around yet
<Regenaxer>
The pil64 VM does not fit RISC-V
<Regenaxer>
thats true
<Regenaxer>
But LLVM is everywhere now
<beneroth>
android? windows?
<Regenaxer>
Android yes
<Regenaxer>
Windows too, but Pil won't run
<Regenaxer>
LLVM promises a lot of optimizability, but I have not investigated yet
<beneroth>
ok
<Regenaxer>
I make only frontend
<Regenaxer>
Still I suspect it will be a *little* slower than pil64
<beneroth>
I'm skeptical that those optimizations apply to pilVM, often such optimizations are for "classical" C/C++ applications..
<Regenaxer>
Very true
<beneroth>
Wikipedia says LLVM supports x86
<Regenaxer>
But LLVM-IR is suitable for that
<Regenaxer>
I mean, LLVM-IR is oriented for C etc
<Regenaxer>
statically compiled langs
<Regenaxer>
But then the backend is general
<Regenaxer>
It has some good points, which are tedious to implement in the frontend, but once there should be very optimizable
<beneroth>
I see
<Regenaxer>
I see it now already by inspecting the generated machine cude
<Regenaxer>
arm64 and x86-64
<beneroth>
brb
<Regenaxer>
I was hoping that we *could* also support 32 bit
<Regenaxer>
not efficient anyway, but *maybe* useful
<Regenaxer>
But now I tend to give up 32 bit support
<beneroth>
you mean the current pil32 edition?
<Regenaxer>
Seems it needs ugly constructs
<Regenaxer>
no
<beneroth>
or you mean LLVM on x86 ?
<Regenaxer>
no
<Regenaxer>
:)
<Regenaxer>
Generate LLVM-IR that runs on 32 bits
<Regenaxer>
despite the Pil VM is 64 bit
<Regenaxer>
pil32 is a completely different beast
<Regenaxer>
and Ersats again
<Regenaxer>
Ersatz
<Regenaxer>
I want to map pil64 to LLVM
<Regenaxer>
(and thought we might get something analog to pil64's emu running on 32 bits)
<Regenaxer>
A cludge anyway
<Regenaxer>
The question is how much 32-bit support for Pil is really needed in the future?
<Regenaxer>
I use emu on Android
<Regenaxer>
but the few users I have gradually got 64 bit mobiles meanxhile
<Regenaxer>
aw- uses pil on 32 bit, right?
<Regenaxer>
But how about the future?
<Regenaxer>
pil32 and mini will stay around, just no longer maintained
<Regenaxer>
PilMCU and PilOS not sure yet
<Regenaxer>
I expect LLVM-IR can be translated to Verilog too, but have not investigated yet
<beneroth>
so... you mean in pil21 code would all be kinda pil64, technically the VM running on 64bit, though it will run on 32bit systems (hardware, OS) too ?
<beneroth>
are we talking about source code compatibility or hardware/platform compatibility.. or both?
<beneroth>
What will be lost?
<Regenaxer>
"kinda pil64" yes, but 32 bit hardware no
<Regenaxer>
Lisp source is the same
<beneroth>
ok, so pil21 will not be running on 32bit hardware (even when LLVM should support it) ?
<Regenaxer>
implementation pilAsm -> Mock-Pil
<beneroth>
Mock-Pil + pil + LLVM = building pil21 ?
<Regenaxer>
It is not LLVM not supporting it
<Regenaxer>
I dont find a way to generate LLVM that runs on both
<Regenaxer>
MockPil is the source in pil21.tgz
<Regenaxer>
PilAsm:
<beneroth>
so.. two LLVM frontends would be needed, to produce 64bit and 32bit binaries?
<Regenaxer>
# (car 'var) -> any(code 'doCar 2) push X ld X E ld E ((E CDR)) # Get arg eval num E # Need variable jnz varErrEX ld E (E) # Take CAR pop X ret
<Regenaxer>
oops
<Regenaxer>
cant paste here
<beneroth>
nvm
<Regenaxer>
no
<Regenaxer>
no 32 binaries
<Regenaxer>
like current pil64
<beneroth>
yes, I understand that is the roadmap now
<Regenaxer>
Pil64 and pil21 use 64 bit words
<Regenaxer>
in cells
<Regenaxer>
32 bit machines have 32 bit pointers
<beneroth>
so the question is: to have 32bit binaries, an additional pil implemention (could be on LLVM) would be required, yes?
<Regenaxer>
I dont find a clean way to express this in LLVM-IR
<beneroth>
yeah I understand
<beneroth>
thought so :)
<Regenaxer>
Then we dont need llvm, just use current pil32
<beneroth>
T
<Regenaxer>
It makes only sense if the pil21 implementation compiles and runs also on 32 bit
<beneroth>
though maybe the differences between two such implementations in MockPil would maybe be more similar and easier to maintain than current C-version and pil21...
<beneroth>
just theorizing here
<Regenaxer>
no, it is a nightmare
<Regenaxer>
very different
<beneroth>
ok
<mtsd>
Hello beneroth
<Regenaxer>
as new pil32 and pil64
<beneroth>
hi mtsd :)
<Regenaxer>
s/new/now
<beneroth>
the pointer size makes a bigger difference than the compiler
<Regenaxer>
emu now maps the 64 bit arch to C
<mtsd>
Maybe we could ask the mailing list, and here in IRC, to see how many are really using 32 bit?
<Regenaxer>
yes
<Regenaxer>
mtsd, right
<beneroth>
I don't have pil32 in use anywhere, afaik.
freeemint has joined #picolisp
<Regenaxer>
and how the future will be
<beneroth>
I have unused 32bit hardware lying around though ^^
<mtsd>
As for myself, I no longer have any 32 bit hardware around
<Regenaxer>
same here
<Regenaxer>
I have one old ThinkPad
<Regenaxer>
from 2005
<Regenaxer>
but tough to install new os on it
<Regenaxer>
I think I will never use it again
<mtsd>
Oh, come to think of it, I do have an old, 32-bit, netbook..
<beneroth>
what about the mobile front? a few years ago you had issues with client company using 32bit androids, no?
<beneroth>
though yeah, iOS compatibility would be a advantage probably worth that cost
<Regenaxer>
yes, as I said above, most have new devices meanwhile
<beneroth>
(if Apple allows pil VM in store.. well possible that they will not)
<beneroth>
ok
<Regenaxer>
thats another problem ;)
<mtsd>
I could probably fit 32-bit Debian on the netbook, if you need help testing something
<Regenaxer>
thanks!
<mtsd>
Anytime! :)
<Regenaxer>
tankf33der has any conceivable system it seems :)
<beneroth>
:D
<mtsd>
More and more Linux distributions are dropping 32-bit, apparently
<Regenaxer>
yeah
<Regenaxer>
Apple too
<Regenaxer>
So, OK, lets forget 32 bit for now
<Regenaxer>
If *really* necessary, we can re-consider
<mtsd>
Maybe time to take the plunge with Pil too, if it means easier maintenance?
<Regenaxer>
Lets first see how pil21 works out
<Regenaxer>
exactly
<Regenaxer>
much more clean in 64-only
<Regenaxer>
If *really* necessary, we can re-consideri
<Regenaxer>
oops
<mtsd>
I would love to be able to help out with the low level, implementation stuff. But I would need too much guidance and hand-holding to do so, and that would steal too much of your time, I'm afraid
<Regenaxer>
Welcome!
<Regenaxer>
Most issues are not pil but llvm
<Regenaxer>
The optimization has to be investigated
<mtsd>
I guess I could start by reading the llvm docs, and see if I can wrap my head around that
<Regenaxer>
:)
<mtsd>
I have to apologize in advance for all the stupid questions I will ask.. ;)
<Regenaxer>
What I want to achieve is have a LLVM-IR base system in the distro, so that bootstrapping is easier than ow
<Regenaxer>
No worry!
<mtsd>
Application level type programmer trying to understand how things really work. That's me :)
<Regenaxer>
Always good to learn such things
<mtsd>
Yes, and that is something I would really like to learn. Maybe a good opportunity to start now
<Regenaxer>
T, probably llvm has a future
<Regenaxer>
as a general architecture
<Regenaxer>
Not because it is so good, but because so many jumpen onto the waggon
<mtsd>
Yes, it pops up everywhere these days.
<Regenaxer>
T
<beneroth>
so it achieves the old Java dream... all programming happening on that VM
<mtsd>
And focusing on 64-bit, trying to understand llvm, is more than enough for me. I have my work cut out just trying to get into that..
<Regenaxer>
OK :)
<Regenaxer>
You don't need to study all those C++ libs in llvm
<Regenaxer>
Pil won't need them
<mtsd>
But it would be really nice to understand the inner workings. I have been using Pil for some time now, and it feels like the next step to take. Good project for me, on a personal level as well.
<Regenaxer>
But llvm-ir and the 'opt' tool later
<Regenaxer>
yeah, good thing
<beneroth>
pil inner workings and glueing them to LLVM are different things :)
<beneroth>
T
<Regenaxer>
yeah
<mtsd>
If I don't try, I could just keep using Python or Perl or some other language without really understanding what they do. Stuck in application land forever :)
<beneroth>
both is good to understand
<beneroth>
but pil inner workings are surely way easier xD
<beneroth>
you ever programmed C with some pointer arithmetic?
<Regenaxer>
What I do at the moment is rewriting the pilAsm stuff in MockPil
<mtsd>
Yes, in the past
<beneroth>
pil VM is all just pointers after the parsing step
<beneroth>
Regenaxer, I see
<beneroth>
Regenaxer, what does interpret the MockPil ? the LLVM-frontend ?
<Regenaxer>
I would say no interpretation
<Regenaxer>
MockPil is compiled to LLVM-IR
<Regenaxer>
LLVM-IR replaces pilAsm
<Regenaxer>
instead of A, C, E, X etc
<Regenaxer>
we have SSA
<Regenaxer>
Static single assignment
<Regenaxer>
You can think we have an unlimited set of registers
<beneroth>
ok
<beneroth>
oh
<beneroth>
interesting
<Regenaxer>
Every one is assigned only *once*
<Regenaxer>
and never changed
<beneroth>
so LLVM tries to optimally map the used registers to the hardware ones?
<Regenaxer>
Kind of sick, but useful
<beneroth>
and emulates the rest?
<Regenaxer>
exactly
<beneroth>
oh
<Regenaxer>
can and must be optimized, but I dont have to care
<Regenaxer>
What is tedious for implementing pil is that it is statically typed
<Regenaxer>
and pil data have no clear type
<Regenaxer>
all is "any" :)
<Regenaxer>
So I must de a lot of fuzz to get that straight
<Regenaxer>
But that's all solved
<mtsd>
All has the potential to be anything. Almost like quantum mechanics ;)
<Regenaxer>
I understand that such strongly typed llvm code can be much better optimized
<Regenaxer>
yeah, kind of :)
<Regenaxer>
s/must de a lot/mus do a lom
<Regenaxer>
penti o <-> e ;)
<mtsd>
So, PilAsm was turned into assembler via gcc before. Now MockPil is turned into LLVM-IR? Is that how it works?
<Regenaxer>
No, PilAsm was turned into assembler by PicuLisp
<Regenaxer>
gcc then assembled it into machine code
<mtsd>
Ok
<Regenaxer>
And yes, MockPil is turned into LLVM-IR
<Regenaxer>
It looks like normal pil almost
<Regenaxer>
but isn't
<mtsd>
I got that right at least, haha
<Regenaxer>
:)
<mtsd>
It is dangerously comfortable to just igore these things and only use a language to write applications :)
<mtsd>
But less satisfying in the long run
<Regenaxer>
T, better tu understand the internals
<beneroth>
good to understand internals, but better for sanity to work on application level instead having to deal with eccentric hardware and compilers
<mtsd>
haha, problaby true, beneroth.
<Regenaxer>
needs good abstractions
* beneroth
learned from Regenaxer that the only (long-term) good abstractions are the ones which don't add restrictions other than what is absolutely necessary to make it meaningful
<beneroth>
"unintended" restrictions happen so quickly... though unintended often just means "dev doesn't care, who would ever use it THAT way anyway..:"
<beneroth>
then some time later you find then the clever use case for THAT way
<Regenaxer>
yes, eg 32 bit support ;)
<beneroth>
haha, didn't mean to relate to that ;-)
<Regenaxer>
:)
<Regenaxer>
Lets see
<mtsd>
Well, 64-bit and llvm seems to be where large parts of the world if going. Pil has evolved through many different generations of technology already.
<mtsd>
So the abstractions in Pil seem to be quite well chosen :)
<Regenaxer>
:)
orivej has quit [Ping timeout: 276 seconds]
<beneroth>
MockPil looks really very picolispy, even more than pilASM :)
<Regenaxer>
yes, pilAsm is not Lisp syntax
<Regenaxer>
In my mind MockPil maps to LLVM-IR
<Regenaxer>
But looking at the generated LLVM-IR is a culture shock for a PicoLisper I think
<mtsd>
Can I download the current, work-in-progress, version of Pil21 anywhere? To look at MockPil etc
<mtsd>
Thank you, I will have a go at reading the docs, for a start
<beneroth>
:)
<beneroth>
bbl
beneroth has quit [Quit: Leaving]
<Regenaxer>
tankf33der, how does it come you can test on so many systems? Do you own a computer-museum?
<tankf33der>
:)
<Nistur>
mornin'
<Regenaxer>
Hi Nistur!
<Nistur>
hello :)
rob_w has quit [Quit: Leaving]
mtsd has quit [Quit: Leaving]
freeemint has quit [Remote host closed the connection]
freeemint has joined #picolisp
beneroth has joined #picolisp
freemint has joined #picolisp
freeemint has quit [Read error: Connection reset by peer]
orivej has joined #picolisp
<beneroth>
Regenaxer, are you here?
<beneroth>
Regenaxer, nevermind
<beneroth>
afk
vikid has joined #picolisp
vikid has quit [Ping timeout: 240 seconds]
<Regenaxer>
Hi beneroth, yes
vikid has joined #picolisp
<Regenaxer>
Hi vikid! Been a long time o/
vikid has quit [Ping timeout: 240 seconds]
Seteeri has joined #picolisp
<beneroth>
back
<Regenaxer>
Hi beneroth
<beneroth>
hi Regenaxer :)
<beneroth>
I pondered about a way to look out for symbol name clashes. e.g. having everything using transient names in a library, and then after loading (while still in the transient scope, so in in the file) check for clashes and then intern
<beneroth>
but yeah.. I realized (import) is for that :)
<beneroth>
(independent of namespaces)
<Regenaxer>
Indeed, import from transient
<beneroth>
yep, exactly
<beneroth>
Regenaxer, or even better, using (name) with two args?
<beneroth>
e.g. (name "foo" 'bar) =
<beneroth>
hmm..
<beneroth>
the ref has an example: (intern (name (zap 'car) "xxx") T)...
<Regenaxer>
renaming
<Regenaxer>
Not sure if a good idea
<Regenaxer>
I'm more and more into namespaces, I think it is best
<Regenaxer>
Very heavy use in pil21 build
<beneroth>
use case (might be bad idea): 1) definitions, e.g. functions and globales 2) rename, still using transient names 3) import some/all transient names
<Regenaxer>
src/lib/llvm.l
<beneroth>
T
<beneroth>
I saw
<Regenaxer>
It redefines part of Pil so that it compiles
<Regenaxer>
Namespaces are also hard sometimes
<Regenaxer>
I had to be very careful when to override what
<beneroth>
yeah
<Regenaxer>
(with local mainly)
<Regenaxer>
:)
<beneroth>
I have two issues with namespaces for my use case: A) namespace ordering has to be strict. difficult to handle later additions of additional namespaces, no?
<Regenaxer>
Why?
<beneroth>
because the same earlier order has to be ensured
<beneroth>
no?
<Regenaxer>
I even change the order usually
<Regenaxer>
When defining it is the first namespace
<Regenaxer>
at runtime more in the back usually
<beneroth>
T, got that
<beneroth>
yeah, I mean at runtime
<beneroth>
might not be a real issue
<beneroth>
the other point is: B) limits for use with DB
<Regenaxer>
I use it with DB in PilBox a lot
<beneroth>
technically because parsing vs. limited reversal of parsing
<Regenaxer>
I think DB is not special here
<Regenaxer>
It is always necessary to be careful :)
<beneroth>
T
<beneroth>
well storing code in DB as +List +Any is a problem, but storing code that way is probably a dumb idea anyway
<Regenaxer>
not easy, unfortunately
<beneroth>
then the storing happens after parsing, so its already pointers. and written into db will be symbol names, but with no regard for namespaces
<Regenaxer>
You must just take care that the order is the same at reading and at writing
<beneroth>
probably better to store code as files
<beneroth>
exactly
<beneroth>
and in my use cases I want to change this orders and number of namespaces over the lifetime of a db/application
<Regenaxer>
Transients will not share when reading from PLIO
<Regenaxer>
Changing is perhaps good
<beneroth>
the point is, I want the references
<Regenaxer>
we must develop our strategies
<beneroth>
T
<beneroth>
specific to use case
<Regenaxer>
Which references?
<beneroth>
reference of an Entity or function or method in code. I want to store that code, load it, but also figure out "Entity X is used there, there and over there"
<Regenaxer>
ok
<beneroth>
so.. either save in structures made for that - complex.
<beneroth>
or very simple: files.. and grep, or a pil script which like (lint) understands the pil source code :)
<beneroth>
and on top of that I would like to have modularization.. could be done with namespaces, but tricky to get it always right
<beneroth>
could be done with symbol naming conventions. could lead to overly long symbol names, but otherwise ok.
<beneroth>
and other ways are possible.
<Regenaxer>
Probably
<beneroth>
you agree so far with my view?
<beneroth>
it's no critic on your general system, it is great ;-)
<Regenaxer>
:)
<beneroth>
I just have to figure out the best way for my special needs
<beneroth>
best = flexible and maintainable. the law of picolisp states: KISS
<Regenaxer>
yeah, you are entering new realms
<beneroth>
yeah there is some essential complexity to it (in the No Silver Bullet sense)