<Hunar>
I didn't understand the conversation about LLVM and the new PilBox update .. can I have a quick summary :)
<abu[m]>
These two issues are not related
<abu[m]>
LLVM made some trouble with version 16
<Hunar>
Ah, I thought you were experimenting with some LLVM features
<abu[m]>
yes, kind of. The intermediate llvm language changed, in that pointers have no type any more
<abu[m]>
and some trouble with C include files
<Hunar>
just tested the new PilBox from play store, camera still works.
<abu[m]>
great :)
calle has joined #picolisp
chexum has quit [Quit: No Ping reply in 180 seconds.]
chexum has joined #picolisp
<beneroth>
abu[m], when building potentially big strings, what do you recommend (besides not doing it and printing directly): iteratively packing into a variable and returning it at the end, or building a list (with make) and 'pack it in one go at the end?
<beneroth>
I would suspect the first being safer (space/performance consumption) the bigger the string gets, while the second approach might be faster for shorter strings/lists ?
<beneroth>
depends on the implementation of (pack).. I guess it copies memory around always? :/ is there a destructive variant of it?
<beneroth>
hmm, I could do a combination. using list, and use (at) to pack it from time to time (and then reuse it as first element. that might be good?
<abu[m]>
The overhead is not memory but the positioning of all the characters in the name (i.e. a bignum)
<beneroth>
yeah of course
<beneroth>
and I guess this involves copying memory in each case, I don't think we can extend a symbol name destructively right?
<abu[m]>
In any case the difference is perhaps not big
<abu[m]>
right
<beneroth>
ok
<beneroth>
so you recommend going with make approach and only change that when actual memory problems might occur?
<abu[m]>
The listing does not copy, but conses new cells and thus causes garbage collections (but pack too)
<beneroth>
probably better for performance, memory is cheap, and performance matters more for such use cases than memory I'd think
<abu[m]>
Yeah, make is also easier. And I never saw memory problems here
<beneroth>
thanks for confirming my intuitions and the discussion
<beneroth>
I will go with listing approach. whenever its a performance problem, an initial (gc 'ct) will probably solve it.
<abu[m]>
What kind of memory problems might happen? Starting to swap?
<beneroth>
well more like performance hit because of many memory allocations
<beneroth>
when it goes so big that swapping becomes a topic, then better print, maybe in a file or whatever :D
<abu[m]>
indeed
<beneroth>
I don't expect it to be a problem, I just like to think about potential cases to make the implementation robust
<beneroth>
the use case at hand is JSON :)
<abu[m]>
true
<beneroth>
I figured 3 pil implementations are not enough I do another one xD
<abu[m]>
ok
calle has quit [Ping timeout: 268 seconds]
<beneroth>
well different use cases.
<beneroth>
but also a bit of NIH
<abu[m]>
As you said, 'make' is the most efficient way, as the data are not copied again and again
<beneroth>
T
<beneroth>
and in generating such stuff its anyway getting allocated or is already allocated
<beneroth>
so actually might go much better in most practical cases than stuffing a string all the time
<abu[m]>
yes
<abu[m]>
The nice thing is that the final 'pack' can also handle nested lists
<abu[m]>
So no need to 'append' the individual sublists, just list them on the top level
<beneroth>
T
<beneroth>
nice point, that's an optimization I can actually do
<beneroth>
when calling recursively, detect that we're already in recursion and continue linking without doing a final pack'ing until we're back on top level
<beneroth>
excellent, I've overlooked that
<beneroth>
aw-, did you take your stuff on github offline or just moved it? talking about http://aw.github.io/picolisp/
<beneroth>
picolisp.com has dead links to it
<beneroth>
aw-, nvm. https://github.com/aw works, so it's simply the picolisp.com which is wrong