beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
ShannonB has quit [Quit: The Lounge - https://thelounge.chat]
f[x] has joined #picolisp
ygrek has quit [Ping timeout: 264 seconds]
f[x] has quit [Remote host closed the connection]
corecheckno has joined #picolisp
<tankf33der> Morning
<tankf33der> busy
<tankf33der> bbl
<abu[7]> ok
z4k4ri4 has quit [Ping timeout: 252 seconds]
z4k4ri4 has joined #picolisp
mario-goulart has quit [Ping timeout: 244 seconds]
f[x] has joined #picolisp
azynheira has joined #picolisp
<azynheira> Hello again
<azynheira> I tried with LLVM/CLANG 21 and compilation works
<abu[7]> Great! 👍
<azynheira> 15 DId not seem to make any difference, so I updated to the last version.
<abu[7]> ok
<azynheira> If you want I can try to figure out whats the lastest version thast actually works
<abu[7]> Thanks, but not necessary. Older versions will soon disappear :)
<azynheira> Ok. Let me know if you need help.
<abu[7]> Great, thanks
z4k4ri4 has quit [Ping timeout: 272 seconds]
z4k4ri4 has joined #picolisp
mario-goulart has joined #picolisp
<azynheira> A question: Should there not be a list of requirements to compile pil21 ? Then there should be a minimum version of LLVM correct ?
<abu[7]> True
<abu[7]> This changed over time
<azynheira> Fair enough
<abu[7]> The requirements are described in the INSTALL file
<abu[7]> ie. packages
<azynheira> But not versions of LLVM
<azynheira> Thats what I meant, just to avoid these problems
<abu[7]> ah, yes
<abu[7]> tankf33der managed the llvm versions. He was here today for a moment but was busy
<abu[7]> I think he could say more about this
<azynheira> Thats fine :-) I was just making a comment ...
<abu[7]> right, this is always welcome
<tankf33der> here.
<abu[7]> o/
<azynheira> :-)
<tankf33der> pil21 tested on llvm11-21 and all compiles out of box.
<abu[7]> oh
<azynheira> Thats what I came to the conclusion
<azynheira> I was using 14 still
<abu[7]> azynheira had problems with 14
<azynheira> and from the 27th Feb version it no longer works
<azynheira> If this is confirmed, that all makes sense
<azynheira> I dont think 15 works either... I briefly tested it
<abu[7]> 27th Feb I made a change to src/sym.l and src/io.l
<abu[7]> but nothing critical I thought
<azynheira> Does it have to do with the special pointers you were mentioning before ?
<abu[7]> I don't think so
<abu[7]> this is a general pointer thing
<tankf33der> installing llvm15
<abu[7]> let me chech your error position in base.ll
<azynheira> This is what I faced with 14 and I think 15:pil21/doc/Tracks
<azynheira> opt: base.ll:56590:9: error: stored value and pointer type do not match
<azynheira>   store i64 %91, i64** bitcast (i8* getelementptr (i8, i8* bitcast ([25 x i64]* @env to i8*), i32 96) to i64**)
<azynheira>         ^
<azynheira> make: *** [Makefile:44: base.bc] Error 1
<abu[7]> line base.ll:56590
<azynheira> And this with a clean install with the genenrated base.ll from the distro
<azynheira> So I would assume everybody is using 21 correct ?
<tankf33der> no :)
<abu[7]> I have 19
<tankf33der> only llvm's in distroes
<azynheira> But thats far enough from 14/15
<abu[7]> but 56590 is indeed that change
<azynheira> yes
<abu[7]> in the 'repl' function
<abu[7]> src/io.l
<abu[7]> (set $NsLink (val $Link))
<abu[7]> hmm
<abu[7]> looks innocent ;)
<azynheira> base.ll is intermediate syntax right?
<abu[7]> yes
<abu[7]> your error was "stored value and pointer type do not match"
<abu[7]> I dig into it
<tankf33der> lambda:~/pil21/bin$ strings picolisp | grep clang
<tankf33der> Alpine clang version 15.0.7
<tankf33der> lambda:~/pil21/bin$
<tankf33der> no problem
<azynheira> Maybe my instalation of 15 was not correct :(
<tankf33der> ubuntu, right?
<azynheira> Yes
<azynheira> But at leasr we have a minimum version that we can state pil21 compiles with
<abu[7]> (set $NsLink (val $Link))
<abu[7]> involves indeed different types
<abu[7]> azynheira, can you still reproduce the situation of the error?
<azynheira> I will need to install llvm-14
<azynheira> give me a moment
<abu[7]> If so, let's test a change
<abu[7]> in src/glob.l line 651 is ($NsLink i64* null)
<abu[7]> Can you change to ($NsLink 0) and try again?
<azynheira> with 14 right?
<abu[7]> yes
<abu[7]> any version which gave the error
<azynheira> give me a second
<abu[7]> no hurry
<azynheira> Reproduced ..
<azynheira> opt: base.ll:56590:9: error: stored value and pointer type do not match
<azynheira>   store i64 %91, i64** bitcast (i8* getelementptr (i8, i8* bitcast ([25 x i64]* @env to i8*), i32 96) to i64**)
<azynheira>         ^
<azynheira> make: *** [Makefile:44: base.bc] Error 1
<azynheira> making the change now
<abu[7]> good
<azynheira> Changed line
<azynheira>   ($NsLink 0) # Namespace list link
<azynheira> Compiling now
<abu[7]> correct
<azynheira> This works!
<abu[7]> Cool!
<azynheira> ❯ pil -version -bye ─╯
<azynheira> 25.2.27
<abu[7]> So it was indeed not perfect
<abu[7]> I will change here too
<azynheira> Why could you not detect the inconsistency on the LISP level ?
<abu[7]> Thanks a lot for finding!!
<azynheira> No problem :-)
<abu[7]> The Lisp level has no checks here
<azynheira> Makes sense
<abu[7]> Both types are pointers
<abu[7]> but to 64 bit values
<azynheira> But then,why does LLVM 21 work then ? Is it more flexible on the type check ?
<azynheira> permissive ?
<abu[7]> I think the chec(
<abu[7]> k
<abu[7]> is a bit too picky
<azynheira> too restrictive ... maybe
<abu[7]> yeah
<abu[7]> OK, must go. bbl
<beneroth> thanks abu[7] and azynheira for improving this :)
<abu[7]> :)
<azynheira> :-)
azynheira has quit [Quit: Client closed]
azynheira has joined #picolisp
f[x] has quit [Remote host closed the connection]
f[x] has joined #picolisp
azynheira has quit [Quit: Client closed]
f[x] has quit [Remote host closed the connection]