<aw->
it looks like you didn't push the changes or new tarball
<aw->
last update is:
<aw->
Broken optimization for 'rand'
<aw->
25mar20
<aw->
{src64,pilos/src}/big.l
<Regenaxer>
Hi aw-! Yes, that's right, I did not release it cause it were only cosmetic changes
<Regenaxer>
Mainly docs, so I pushed doc/ to software-lab
alexshendi has joined #picolisp
<alexshendi>
Hi!
<Regenaxer>
Cheers alexshendi!
<alexshendi>
Hi, Regenaxer, how is life?
<Regenaxer>
Thanks, good! Just came back from a short bicycle tour
<Regenaxer>
Quite sunny, but windy
<aw->
Regenaxer: ok thanks!
<Regenaxer>
(Langweid / Augsburg)
<alexshendi>
Good. I took a short walk myself today.
<Regenaxer>
aw, not a big problem, is it?
<Regenaxer>
alexshendi, good plan :)
<alexshendi>
Regenaxer: I hate to ask, but the picolisp user's meeting is probably canceled?
<Regenaxer>
Good question in fact. I was not sure, but indeed it looks impossible
<Regenaxer>
Concerning all those travel restrictions
<Regenaxer>
I wanted to write to the list about end of this month
<Regenaxer>
aw- already said he wont come. How do you think alexshendi?
<aw->
Regenaxer: no i just thought the script which pushes to GitHub was broken because the commits didn't match the ChangeLog on the site.. turns out it's not broken, no problem.
<alexshendi>
I would come, depending on how the restrictions on travel within Germany are. I haven't booked anything though...
<Regenaxer>
aw-, good
<Regenaxer>
Yeah, for us it is easy
<Regenaxer>
And the room is reserved in Kulturbahnhof
<Regenaxer>
So let's see what laws we get
<alexshendi>
The plan9 conference I wanted to go to is canceled anyway.
<Regenaxer>
Things might worsen again as they want to release restrictions
<Regenaxer>
ok
<alexshendi>
Of course it is harder for those outside of Germany because of travel restrictions.
<Regenaxer>
T
<Regenaxer>
and the planning, flights etc
aw- has quit [Quit: Leaving.]
freemint__ has quit [Quit: Leaving]
freemint has joined #picolisp
<freemint>
Regenaxer, would pil21 work any cpu architecture that runs something unix like and is a supported by LLVM
<Regenaxer>
freemint, thanks for your support :)
<Regenaxer>
(mailings)
<Regenaxer>
To the question: yes
<Regenaxer>
posix
<freemint>
What part would need to be torn out/replaced for it to run on bare metal?
<Regenaxer>
Without POSIX? Then something like PIlOS
<freemint>
Do you see a pil21 embedded comming or is pil32 the thing you would still recommend for use on some non posix embedded OS/no OS.
<Regenaxer>
Well, pil32 also needs posix, but mini is fine
<Regenaxer>
Some people use it in embedded systems, did it too
<Regenaxer>
STM-32
<freemint>
sorry mini
<Regenaxer>
But by throwing out all posix stuff like pilOS did pil21 is also a possibility
<freemint>
Will pilOS be upgraded to pil21?
<Regenaxer>
But: pil21 needs 64 bits
<Regenaxer>
Not sure
<Regenaxer>
Geo is investigating
<Regenaxer>
PilMCU to be exact
<freemint>
Cool to see Geo is more active again. I had a great dinner with him
<Regenaxer>
PilOS is a modification of the original PilMCU Geo and I made
<Regenaxer>
:)
<freemint>
Am i correct that all Pil meet up plans are on ice due to CoVID?
<Regenaxer>
Yes, we also shortly talked about it a few minutes ago
<Regenaxer>
Looks like it is not possible in the indended size
<freemint>
Well maybe we can do a digital "PicoCon" :-)
<Regenaxer>
Yes, using Jitsi (also discussed here a few times)
<freemint>
My student clubd hosts an Jitsi instance ;-)
<Regenaxer>
Cool
<Regenaxer>
beneroth too
<Regenaxer>
I used his a lot recently
<freemint>
I am bit annoyed about FireFox due to Jitsi
miskatonic has joined #picolisp
<freemint>
but they are working on it
<Regenaxer>
Are there problems with FF?
<Regenaxer>
I used the app mostly, and FF/Debian for screen sharing
<Regenaxer>
worked fine
<freemint>
Yes, FireFox can not handle multi streams efficently (they miss some part of the standard) and it makes the experience for everyone in the confernce worse.
<Regenaxer>
oh, I see
<freemint>
chromium/brave are fine but i am positive that that will be fixed soon as FireFox tweeted out recently they ade it a priority
<Regenaxer>
great
<miskatonic>
so the pilcon will require multistreams?
freemint has quit [Ping timeout: 256 seconds]
alexshendi has quit [Read error: Connection reset by peer]
freemint has joined #picolisp
alexshendi has joined #picolisp
freemint has quit [Ping timeout: 265 seconds]
<beneroth>
hey all
<beneroth>
miskatonic, multiple audio streams, but not necessarily video streams, I think
<beneroth>
Regenaxer, interesting discussions on ML
<Regenaxer>
Yeah, but rather pointless
<Regenaxer>
as freemint put it, "paranoid"
<beneroth>
well not without a basis, as Tomas Hlavaty rightly pointed out
<beneroth>
But the tone is childish, bad "I demand" attitude.
<beneroth>
we can just use pil64 instead of the llvm version.
<beneroth>
s/we/he
<Regenaxer>
yes, but it also calls libc and other libs
<Regenaxer>
There is *no* system you can trust
<beneroth>
yeah, as I say, we have to put pilOS further ;-)
freemint has joined #picolisp
<beneroth>
Hardware is also turtles all the way down :/
<beneroth>
and it is very ironic to write this stuff from a gmail account xD
<Regenaxer>
hehe
<Regenaxer>
Anyway I stay with LLVM. I also don't like the bulk, but it solves many problems, and the bulk is out of the way for me
<Regenaxer>
I hope pil21 can soon self-bootstrap
<Regenaxer>
Maybe still in May. Depends how much spare time I find
<beneroth>
:-)
<beneroth>
I'm looking forward to pil21, I would have several use cases for native applications on MacOS
<beneroth>
I hope we can keep pil64 alive, mainly for the performance (green IT) benefits etc.
<beneroth>
Maybe I can learn to maintain it eventually.
<beneroth>
I understand aw- and some others are already further in that field than me :)
<Regenaxer>
My hope is that pil21 will only a few percent less efficient (size and speed) than pil64
<Regenaxer>
Lots of optimization features in llvm
<miskatonic>
why is the step from pil64 to pil21 necessary?
<Regenaxer>
portability
<Regenaxer>
pilAsm does not fit iOS and also not RISC-V
<Regenaxer>
and MacOS
<Regenaxer>
the latter could be done, but I don't want to ;)
<beneroth>
and nobody else takes the time :/
<Regenaxer>
T
<beneroth>
the person who does it, decides
<beneroth>
it's that easy
<Regenaxer>
ok
<beneroth>
you've done enough for world improvement by putting it on MIT license
<miskatonic>
and pil21 uses what instead of asm64? The Jave VM?
<beneroth>
that allows everyone to produce more implementation
<Regenaxer>
miskatonic, no, that would be fatal
<Regenaxer>
it is LLVM-IR
<beneroth>
what is the Jave VM?
<beneroth>
typo for java, right?
<beneroth>
can't find anything for Jave
<miskatonic>
yeah, a typo, as usual
<beneroth>
no offense
<beneroth>
who knows, Jave VM might exist
<beneroth>
software naming goes from horrible to worse in recent years :)
<Regenaxer>
T
<miskatonic>
has llvm already been used with dynamic scoping?
<Regenaxer>
In which sense?
<Regenaxer>
What is "dynamic scoping"?
<Regenaxer>
PicoLisp has dynamic *binding*
<Regenaxer>
The scope in PicoLisp is global, except for transient symbols which have a file-local scope
miskatonic has quit [Quit: miskatonic]
freemint has quit [Ping timeout: 246 seconds]
freemint has joined #picolisp
freemint has quit [Read error: Connection reset by peer]
freeemint has joined #picolisp
<Nistur>
mornin'
<beneroth>
Ahoy Nistur
<Nistur>
hullo beneroth
<Nistur>
I am making slooooooooow progress with my project. I only get, at most, 2h per evening, but most days it's 1h, and that is broken up because MiniNisturette wakes up. I seem to take 20m to catch back up with where I was, do 20m of development, and then debug and test for 20m
<Nistur>
HOWEVER, I now have a REST-like interface stubbed out, with a test client (just fires off the requests I've written) and they encrypt the communications with RSA, provided by libssl.so. I split the API into three services, which run independantly (and could be on separate hosts) and the auth server provides URLs to the other 2. No clever lookup at the moment, just that it works out all the addresses
<Nistur>
before it forks off the servers. No cross authentication yet either
<Nistur>
I feel like I might actually be getting somewhere
alexshendi has quit [Ping timeout: 272 seconds]
<Nistur>
hmmm, one thing I haven't looked into yet... how does the C interop memory management work. I assume anything other than basic C types has to be heap allocated. Do I have to do anything special to free it after it's passed back, or is it automagically handled? (c strings most specifically, but arrays or structs also)
<Regenaxer>
Hi Nistur
<Regenaxer>
Good to hear
<beneroth>
afaik you pass it in pre-allocated, so in picolisp it is automatically handled
<Regenaxer>
Some memory is automagically handled
<Regenaxer>
Allocated by 'native', then 'free'd
<Regenaxer>
I'd have to check myself
<Regenaxer>
IIRC it behaves *naturally* (whatever that means ;)
<Regenaxer>
for example string data
<Regenaxer>
also structures
<Nistur>
right now I have 5 C functions... rsa-{encrypt,decrypt,sign,verify,generate)
<Nistur>
the first 3 will just return char* which is malloc'd within the function I call
<Nistur>
verify just returns an int, 0 or 1 in fact but meh. I'll make sure it's T or NIL when it's in pil...
<beneroth>
*naturally* the one allocating the pointer is owning it, imho
<beneroth>
but thats just principles, every docu has to be checked
<Regenaxer>
If you pass pointers, you are in control
<Regenaxer>
If you pass structures as lists, it is done by 'native'
<Nistur>
I'm passing those back as S
<Regenaxer>
But don't ask me in the evening
<Regenaxer>
I'm absolutely useless
<Nistur>
which I assume means it'll convert it into a different interpretation
<Nistur>
Regenaxer: sorry :D
<beneroth>
Nistur, wellw hat does the libssl docu say?
<Regenaxer>
Have some wine intus, and in the process of going to bed
<Regenaxer>
:)
<beneroth>
rightly so, Regenaxer :)
<Regenaxer>
:)
<Nistur>
beneroth: nah, I'm writing my own wrapper functions, because you need to do about 5 steps to do any one logical thing... and half of the things require passing the output through as parameters... it was just easier to write a short C func I'd call from pil, rather than wrap evry library func with native
<Regenaxer>
Some problems I spent hours with at evenings solved by themselves within minutes next morning
<Nistur>
so it has nothing to do with libssl :P the allocations are my own
<Nistur>
Regenaxer: This is true, but sometimes also the inverse, because I can spend hours trying to get into the same headspace in the morning while I could have just quickly continuted my work in the evening
<Regenaxer>
right
<Regenaxer>
though usually I sleep badly with usolved problems
<Nistur>
but yeah, I should have been explicit, I'm using gcc from native.l to compile a C function in which I am malloc'ing a char*, and passing back as 'S. I wouldn't know how I could free that if it doesn't already
<Regenaxer>
ok, so if you allocate it, you also need to free it
<Nistur>
the only other case is, I've got struct { char* keys[2]; }* rsa_generate(int len) which I'm calling with '(S . 2) I think
<Nistur>
Regenaxer: is the original C ptr maintained across the interface? Can I pass it back to something to free?
<Regenaxer>
yes, of course, 'native' cannot know about iy
<Nistur>
the former is my test file, the latter the output
<Nistur>
so my assumption that it converts it to a pil representation of a string seems to be correct, and I lose the original ptr
<Nistur>
I guess if I pass back 'N then I would mainain the ptr but I wouldn't be able to use it as text. Time to extend my test to a struct of strings, but I'm assuming the same deal probably
<Nistur>
if I change the return type of test-malloc to '(S . 2) a struct containing char* s[2], and I malloc the struct, and malloc the two strings, then change test-free to take a struct ptr, then it refuses to even call it, saying No Memory
<beneroth>
Nistur, good thing with your wrapper
<beneroth>
would probably try the same approach
<Nistur>
for now I'm going to assume it 'just works'... I might be leaking memory, which would be baaaaaaaaad but during development, I don't much care, I wouldn't be leaking so much that I'd notice it for a long, long time
<Nistur>
if it is leaking I'll figure it out and fix it later
<Nistur>
beneroth: :)
<beneroth>
aye
<beneroth>
:-)
<beneroth>
first make it run, then make it nice
<beneroth>
not to mix up with "move fast and break things", that is mad max
<Nistur>
indeed :P
<Nistur>
I was mostly just asking, not because it was blocking me, but because I thought it was worth knowing, and I didn't recall seeing it being mentioned when I was reading about the C interface
<beneroth>
yo all right
<beneroth>
this is also one of the less well documented territories
<beneroth>
did you read aw-s stuff on github about it?
<beneroth>
but I guess you already advanced beyond this level :)
<Nistur>
I did not see that. I shall read it
<Nistur>
ok, skim read that (I'll have to be more awake to absorb it more) and it seemed very helpful... but yeah, didn't answer this specific problem :P
<Nistur>
anyway, my coding time today has let me: whine at you lot about my problem, test it, and also finish my rsa_generate function. I now can generate any length RSA keys from pil, and use them in encryption, and signing
<Nistur>
\o/
<Nistur>
I need to go back and check that everything apart from the return values is freed properly, and document it all, as hopefully I won't have to touch it again now :P then I can get back to pure pil code :P
<Nistur>
http://ix.io/2iJo not sure what the bit after the pubkey is... I've probably got the length wrong and I didn't terminate it properly
<Nistur>
I guess I should also try to namespace things properly, as 'generate' is too generic a name