<abu[7]>
I always try to find a state where I can reproduce
<tankf33der>
right
<abu[7]>
-O2 is easier to crash usually
<tankf33der>
I will try without O today later
<abu[7]>
Don't waste too much time, I think the Os give no info
<abu[7]>
The stack is overwritten
<abu[7]>
but I cannot grasp it
<abu[7]>
Have a meeting now for at least 3 hours
rob_w has joined #picolisp
fuxoft has joined #picolisp
<fuxoft>
Hello. I stumble with what's probably a very basic problem:
<abu[7]>
I'm in a meeting, hope it is OK to postpon
<abu[7]>
e
<fuxoft>
I've got my own function defined, let's call it "execute". I call it with a prog, e.g.: (execute (println "Line1") (println "Line2") (println "Line3))
<tankf33der>
Hi
<tankf33der>
and?
<fuxoft>
The function is defined as (de execute Prog...) so the whole prog ends as a list in Prog
<fuxoft>
Now, how do I actually execute it inside my function?
<tankf33der>
Show full code somewhere
<fuxoft>
OK
<tankf33der>
i am from phone
<fuxoft>
In other words, I have a list of statements that I want to execute, e.g. (list ('(print 1) '(print2) '(print 3)). How do I do that?
<fuxoft>
Sorry typo
<tankf33der>
:)
<fuxoft>
In other words, I have a list of statements that I want to execute, e.g. (list '(print 1) '(print2) '(print 3)). How do I do that?
<tankf33der>
Start from mappings first
<tankf33der>
map and mapcar
<fuxoft>
What was the address of that pastebin alternative you prefer?
<fuxoft>
What is the first line to put in my PicoLisp bash script to be executed in debug mode?
<fuxoft>
Currently I have '#!/usr/bin/picolisp /usr/lib/picolisp/lib.l' which does not start in debug mode so (bench) is unavailable
<fuxoft>
Or do I just load "debug.l" manually?
<tankf33der>
just add + in cli
<tankf33der>
or
<tankf33der>
(on *Dbg)
<fuxoft>
Curiously, (on *Dbg) as a second line of the script has no effect, (bench) is still undefined.
<fuxoft>
As for your script from 11:32:50, I didn't want to print results of all the funs, I just wanted to exexute them, e.g. just (de mike Progs (exe Progs))
<fuxoft>
The difference between (queue) and (fifo) is that (queue) uses standard (non circular) list to hold the queue but (fifo) is much faster with big queues?
<beneroth_>
why should it be faster?
<tankf33der>
Queue adds to tail, always slower
<beneroth_>
T, while adding
<beneroth_>
but popping from circular list should be slower than popping from a simple list, as an additional reference needs to be updated, no?
<beneroth_>
a comparison between fifo and make environment could be interesting
<fuxoft>
Popping, yes. But adding to a tail of list with length 100000 is sooo much slower...
<fuxoft>
So for implementing a very long queue, (fifo) is many orders of magnitude faster than (queue).
<fuxoft>
And, on a completely different note, I am still struggling with understanding the key difference between (set) and (def) - They appear to be used interchangeably in the tutorials.
<tankf33der>
Set -> stores
<tankf33der>
def -> defines
<tankf33der>
easy
<fuxoft>
For basic two-argument usage with no debug, the definitions in the docs seem almost identical
<fuxoft>
It's just the matter of the "redefined" warning then?
<tankf33der>
redefine is warning, yeah
<fuxoft>
Any simple example where (def) and (set) do something entirely different?
<tankf33der>
Check second form of def
<tankf33der>
in first form they are identical
<abu[7]>
To make a very long list, 'make' and 'link' etc, are very efficient
<abu[7]>
(meeting done)
<tankf33der>
(set 'var 'any ..)
<fuxoft>
For setting properties, OK.
<abu[7]>
def is set plus source info, and returns sym instead of value
<tankf33der>
(def 'sym 'any)
<tankf33der>
Requires any right, but var and sym are different, i was wrong
<tankf33der>
about first form
<fuxoft>
Does that mean than I am discouraged from CHANGING the property values once I define them? Because I can only change them using (def) and that produces the warning
<abu[7]>
Why not 'put'?
<abu[7]>
or '=:'
<fuxoft>
(12:11:14) Oh, that's probably what I was missing. It returns different result...
<abu[7]>
set and def, yes
<fuxoft>
You are right. I am still struggling with the practical usage of symbol properties. I have to study the library sources more...
<abu[7]>
(with (def 'sym ...
<abu[7]>
(with (def 'sym ... (=: x 1)
<fuxoft>
Oooh, now I understand the difference. I'd appreciate more short advanced examples like these with explanations :)
<abu[7]>
:)
<fuxoft>
There are PicoLisp functions where I understand what they do (from the docs) but have no idea "In which situation would I need that during my programming?" :)
<abu[7]>
T
<fuxoft>
Thanks again and bye.
fuxoft has quit [Quit: Client closed]
beneroth_ has quit [Quit: Leaving]
<tankf33der>
with Os 11-18 ok on freebsd
<tankf33der>
*without* Os 11-18 ok on freebsd
<abu[7]>
OK
<abu[7]>
Could it be an alignment issue?
beneroth has joined #picolisp
<abu[7]>
I could trace down to a 'memcpy'
<tankf33der>
addrs are ok?
<tankf33der>
calculated correctly ?
<abu[7]>
Still checking
<abu[7]>
seems ok
<abu[7]>
In a current dbg setup where I can reproduce the crash, it is the 'memcpy' in 'llvm~loadCoEnv' which definitely messes up something
<abu[7]>
But I don't understand it
<tankf33der>
close
<abu[7]>
Perhaps
<abu[7]>
It is not alignment
<abu[7]>
inspecting the asm in src/picolisp.s
* beneroth
drückt die Daumen und feuert abu[7] leise an... abu.. abu.. :)
<beneroth>
patience and abu[7] will find it, I'm sure :)
<abu[7]>
☺
<abu[7]>
Should take a walk, but it is still too hot
<beneroth>
yeah
<beneroth>
damn climate change, it's slows down picolisp development
<abu[7]>
T
rob_w has quit [Remote host closed the connection]
<abu[7]>
The arguments passed io memcpy (source pointer, destination pointer and size) are correct, but *sometimes* the destination does not have the value of the source
<abu[7]>
How can that be dependent on some env?
<abu[7]>
like optim
<abu[7]>
or program layout
<abu[7]>
Alignment is ok
<abu[7]>
all to 8 bytes
<abu[7]>
Most oft the time it works, but sometimes it fails reproducably
<abu[7]>
What other factors are conceivable where such symptoms may come from?
<abu[7]>
Any ideas anybody?
<abu[7]>
I get it to crash with a *really* minimal coroutine: (co 'a (msg 'OK))
<beneroth>
ASLR artefact? but that would be a bug, I believe ASLR should not be visible for the program itself. and probably would be random and not consistent.
<abu[7]>
T
<abu[7]>
For one given binary it is reproducible
<abu[7]>
bin/picolisp
<abu[7]>
But changing just a little in the source makes it disappear, so it looks like some memory overwrite
<tankf33der>
what if whole pil21 is broken ?
<abu[7]>
It isn't, because immediately before the memcpy data are ok
<abu[7]>
tankf33der, good question
<abu[7]>
What if I
<abu[7]>
I
<abu[7]>
What if I put the bin somewhere?
<abu[7]>
Any tools to do a static analysis?
<tankf33der>
(co 'a (msg 'OK)) - freebsd llvm16 O2 is ok
<tankf33der>
not for llvm ir as i googled correctly