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
rob_w has joined #picolisp
Guest63 has joined #picolisp
<Guest63> Hello, I trying to compile picolisp on macos 14.1.1 for M2, but there is alot of error
<Guest63> Here is there error lib.c:120:4: error: use of undeclared identifier 'rl_catch_signals'
<Guest63>   120 | rl_catch_signals = 0;
<Guest63>       | ^
<Guest63> lib.c:122:4: error: use of undeclared identifier 'rl_input_available_hook'
<Guest63>   122 | rl_input_available_hook = rlAvail;
<Guest63>       | ^
<Guest63> lib.c:123:33: error: incompatible function pointer types assigning to 'Function *' (aka 'int (*)(const char *, int)') from 'char *(const char *, int)' [-Wincompatible-function-pointer-types]
<Guest63>   123 | rl_completion_entry_function = tabEntry;
<Guest63>       | ^ ~~~~~~~~
<Guest63> lib.c:125:4: error: use of undeclared identifier 'rl_basic_quote_characters'
<Guest63>   125 | rl_basic_quote_characters = NULL;
<Guest63>       | ^
<Guest63> lib.c:137:56: error: use of undeclared identifier 'rl_readline_state'
<Guest63>   137 | if (rl_readline_state & RL_STATE_INITIALIZED && !(rl_readline_state & RL_STATE_DONE)) {
<Guest63>       | ^
<Guest63> lib.c:137:76: error: use of undeclared identifier 'RL_STATE_DONE'
<Guest63>   137 | if (rl_readline_state & RL_STATE_INITIALIZED && !(rl_readline_state & RL_STATE_DONE)) {
<Guest63>       | ^
<Guest63> lib.c:149:8: error: use of undeclared identifier 'rl_readline_state'
<Guest63>   149 | if (rl_readline_state & RL_STATE_INITIALIZED) {
<Guest63>       | ^
<Guest63> lib.c:149:28: error: use of undeclared identifier 'RL_STATE_INITIALIZED'
<abu[7]> Hi, I think tankf33der can tell you more
<Guest63>   149 | if (rl_readline_state & RL_STATE_INITIALIZED) {
<Guest63>       | ^
<Guest63> lib.c:150:7: error: call to undeclared function 'rl_save_prompt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
<Guest63>   150 | rl_save_prompt();
<Guest63>       | ^
<Guest63> lib.c:150:7: note: did you mean 'rl_set_prompt'?
<Guest63>   204 | int rl_set_prompt(const char *);
<Guest63>       | ^
<Guest63> lib.c:157:8: error: use of undeclared identifier 'rl_readline_state'
<Guest63>   157 | if (rl_readline_state & RL_STATE_SIGHANDLER) {
<Guest63>       | ^
<Guest63> lib.c:157:28: error: use of undeclared identifier 'RL_STATE_SIGHANDLER'
<Guest63>   157 | if (rl_readline_state & RL_STATE_SIGHANDLER) {
<Guest63>       | ^
<abu[7]> Ooooo, stop!!!!
<Guest63> ?
<abu[7]> Don't flood IRC
<Guest63> Oh sorry
<abu[7]> Better pastebin somewhere
<abu[7]> Anyway :)
<Guest63> Thanks You, so i'm going to asking tankf33der right
<abu[7]> tankf33der here?
<abu[7]> I think he will notice
<Guest63> Ok
<abu[7]> Just wait a little here, or look later in https://libera.irclog.whitequark.org/picolisp
<Guest63> Hmm, it look like tankf33der is not here.
<abu[7]> He'll probably show up after a while
<abu[7]> I think there are notes about MacOS on picolisp.com, have you seen those?
<abu[7]> (sorry, I have no Mac)
<Guest63> let me try
<Guest63> Same error
<Guest63> Oh we need to modify the makefile
Guest63 has quit [Quit: Client closed]
<tankf33der> hi all
<abu[7]> Hi tankf33der
<abu[7]> People are too impatient
<tankf33der> pil21 requires precise adherence to the requirement to compile, just like any software on Unix.
<abu[7]> I see! So you wrote to nikic
<abu[7]> However I think optim is not relevant
<abu[7]> I had it crash also with -O1
<abu[7]> But anyway, let's see
<tankf33der> give me an code
<abu[7]> Just yesterday's version I think
<abu[7]> yes, crashes with -O1
<tankf33der> (co 'a 123) ?
<abu[7]> T
<abu[7]> Same crash as -O2
<abu[7]> I dig more with gdb
<abu[7]> Stran
<abu[7]> Strange code
<abu[7]> loadCoEnv is never called
<abu[7]> instead, it is expanded inline in _Co
<abu[7]> And all dbg call are in turn expanded
<tankf33der> is my email and question is ok and correct in general?
<abu[7]> Yes
<tankf33der> good
<abu[7]> except for the optim assumption
<tankf33der> His opinion will help us be confident.
<abu[7]> ok
<abu[7]> Nikita answered
<abu[7]> I think the main point is setjmp
<abu[7]> It seems that %rbp is not correct after longjmp
<abu[7]> I find out more (with gdb)
<abu[7]> I'm wrong. %rbp is correct.
<tankf33der> i am reading
<tankf33der> something new
<abu[7]> What does he mean with "transform"?
<tankf33der> transform llvm-ir lines by opt
<tankf33der> imho
<abu[7]> Let me first find out more
<abu[7]> why the pointer is destroyed
<abu[7]> at the moment of memcpy
<abu[7]> (memcpy (env) (Crt: (env)) (env T) T)
<abu[7]> (Crt: (env)) is garbage
<abu[7]> it is at -48 from %rbp
<abu[7]> %rbp did not change over set/longjmp
<abu[7]> so -0x30(%rbp) must have changed
<abu[7]> Yes, I can see it is changed when setjmp returned
<tankf33der> what do it means ?
<abu[7]> All local variables are relative to %rbp in x86 ABI
<abu[7]> I try to find out *where* it changed
<abu[7]> gdb is horrible and tedious, but at least I can inspect memory without permanently changing behavior
<beneroth> the issue is specific to x86? same LLVM code is all fine for other platforms?
<abu[7]> We cannot prove if it is correct anywhere
<abu[7]> just if it is wrong ;)
<tankf33der> (co 'a (* 3 4)) are crashing on sparc, big endian
<abu[7]> Oh, now I see something! The problem is not that %rbp is somehow wrong after the longjmp. The problem is that %rbp is not set at all in the coroutine!!!
<abu[7]> It still points to the stack area of "main"
<tankf33der> Make sense
<abu[7]> So data are overwritten there
<abu[7]> The coroutine sets its own stack pointer
<abu[7]> But the buffer pointer %rbp is not set sometimes
<abu[7]> I try to find out why
<abu[7]> LLVM-IR has no concept of the buf ptr
<abu[7]> Shall I answer Nikita? And explain the issue how I understand it?
<tankf33der> sure
<abu[7]> L
<abu[7]> LLVM has a frame-pointer attribute
<abu[7]> Hmm, looks not helpful
<abu[7]> I think the backend code generator produces code that may set the frame pointer when not all local variables fit into registers
<abu[7]> Then it fails
<tankf33der> Sad
<tankf33der> it is easy to fix, right?
<abu[7]> No idea yet
<abu[7]> I have no control over the frame pointer
<abu[7]> (it seems to me)
<abu[7]> Perhaps the whole code which runs in the coroutine (now inline in _Co) must be put into a separate function
<abu[7]> Then it will get its own frame pointer
<abu[7]> In any case, the situation is clear to me now
<abu[7]> When inserting test code, new local vars were needed and a frame pointer produced, and we get no crash
<abu[7]> I ask Nikita how he sees this
<beneroth> wow
<beneroth> congratulations on the grokking
<abu[7]> \☺/
rob_w has quit [Remote host closed the connection]
<abu[7]> tankf33der: I still hope that Nikita has another idea, but to have a fix I went with a separate fÜnction
<abu[7]> I did not release to software-lab yet
<abu[7]> but it is on https;//picolisp.com/pub/pil21.tgz
<abu[7]> Can you check if it is OK now?
<tankf33der> I believe that even if Nikita responds, the response will be passive or ambiguous.
<tankf33der> I should test only co, right?
<abu[7]> ok
<abu[7]> Best to test all
<abu[7]> I make a release then
<tankf33der> It will take more time because i will check table of llvm vs. optim
<abu[7]> Cool, yes
<abu[7]> We want to be sure
<tankf33der> Today i will test archlinux llvm's
<abu[7]> Especially for the Debian release end of ths month
<abu[7]> Good
<tankf33der> debian and free tomorrow
<abu[7]> Δ
<abu[7]> 👍
<abu[7]> If your first tests pass, I will release to software-lab to have a more stable version there
beneroth has quit [Read error: Connection reset by peer]
beneroth has joined #picolisp
<abu[7]> I released anyway :)
<tankf33der> testing
<abu[7]> 😎
<tankf33der> so
<tankf33der> archlinux, 14,16,17 - opt 1-3 - ok
<abu[7]> Great
<tankf33der> freebsd, 16,18 - opt 1-3 - ok
<tankf33der> i believe issue closed
<tankf33der> i feel safe and should too
<tankf33der> afk
<abu[7]> Very reliewing
<abu[7]> Thanks!
<tankf33der> bahn works
<tankf33der> It is either a bug or a feature that when the speed reaches 32k, it cannot be reduced.
<abu[7]> really?
<tankf33der> 16k works
<abu[7]> I can increase and decrease without limit it seems
<tankf33der> on debian ?
<abu[7]> Indeed! 32 *k*
<tankf33der> i wrote about 32k
<abu[7]> T
<tankf33der> afk
<abu[7]> Strange, there is no logical limit
<tankf33der> The key does not register.
<abu[7]> Probably some timing
<abu[7]> millisecs
<abu[7]> 'Dly' delay calculation in 'des'
<abu[7]> The delay to sleep in 'key'
<abu[7]> Yes, the delay becomes zero probably, depending on the 'pause' call
<abu[7]> (until (key 1)) accepts a key
<abu[7]> (until (key O)) doesn't
<abu[7]> I could put some handling into 'des'
<abu[7]> Done
<beneroth> thank the both of you! awesome!
<beneroth> that was a tough issue.
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp