<tankf33der>
Try to use hints from openbsd section
<abu[7]>
Thanks! I'm always confused with all this BSD zoo.
<tankf33der>
pablo_escoberg: ping
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
<beneroth>
thanks tankf33der o/
<pablo_escoberg>
Thanks much, tankf33der. I'll go through that doc and ask here if there are any issues.
avocadoist has quit [Ping timeout: 255 seconds]
<pablo_escoberg>
OK, so I followed the instructions and had several errors: I had to change `opt` to `opt-16` and `llc` to `llc-16` and `llvm-link` to `llvm-16-link` but it finally compiled. Now my issue is the error `ld.so: picolisp: can't load library 'libffi.so.2.0'` when I run `pil +`. I modified the `MAIN` line as instrcuted, and libffi.so.2.0 is in
<pablo_escoberg>
/usr/local/lib as expected and as specified in the modified Makefile. I suspect I'm missing one edit to the makefile, but I have no idea what it is. Suggestions?
<pablo_escoberg>
oops, that was `llvm-link-16` rather than `llvm-16-link`
<beneroth>
the error sounds more like you are missing libffi.so.2.0 on your system?
<tankf33der>
Or can not be find
<tankf33der>
maybe already 3.0
<tankf33der>
Afk.
<pablo_escoberg>
Well, not sure exactly why, but putting links in `/usr/lib/` to `libffi.so.2.0` and `libreadline.so.8.2` did the trick. I would have thought that changing the makefile would make the binary look for the libs in the right place, but apparently not. I'd be happy to help modify the doc if need be.
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
<tankf33der>
There is no openbsd community, no one cares.
<tankf33der>
Openbsd is not fully usable, you should stay on linux to get every feature picolisp have.
<pablo_escoberg>
wow, ok, I'll bear that in mind. Thanks.
<pablo_escoberg>
What about FreeBSD? I'm getting really sick of all the systemd crap in Linux and seriously exploring alternatives. But if picolisp doesn't run properly, I'll either have to ssh into a linux box, or find an alternative...
<abu[7]>
I recommend Termux on Android
<beneroth>
why not run devuan? or take a debian and replace systemd
<pablo_escoberg>
yeah, I may end up going that route, but the way things are going, it looks like those may not be options for too much longer. Systemd is eating Linux and I'm not terribly confident I'll be able to run the latter without the former in 5 years, so I'm trying to get ahead of things by moving to something more stable like a BSD.
<abu[7]>
I checked with GDB. It is indeed readline() which outputs that newline.
<abu[7]>
Hmm, I wonder what is actually the correct or intended behavior?
<abu[7]>
Maybe they changed readline() intentionally*
<abu[7]>
In any case, it makes things in Pil ugly
<abu[7]>
e.g. (more (1 2 3))
<abu[7]>
It now shows empty lines in between printed lines
<abu[7]>
But if I fix 'more' by removing (prinl), it breaks on systems which don't have that readline version :(
<abu[7]>
Same with 'bt'
<abu[7]>
or the Pilog stuff
<abu[7]>
: (? (append @X @Y (a b c)))
<abu[7]>
gives ugly empty lines
<tankf33der>
Ugly issue
<abu[7]>
yeah
<abu[7]>
a dilemma
<abu[7]>
And I don't find any info about this in the net
<tankf33der>
Does another software in the world affected?
<abu[7]>
Perhaps only a PicoLisp problem
<abu[7]>
I don't know
chexum has quit [Remote host closed the connection]
chexum_ has joined #picolisp
<abu[7]>
PicoLisp *relied* on the fact that an empty line did not echo anything
<abu[7]>
I should try on other terminals, as Linux console or xterm
<tankf33der>
Maybe ask in mailing list of readline? Write indentical C code for this case
<abu[7]>
Currently I have only Termux
<abu[7]>
It is not a problem which can be demonstrated by code
<abu[7]>
It is a philosophy
<tankf33der>
i can imagine that
<abu[7]>
i.e. what do we expect from readline?
<abu[7]>
The "new" behavior is kind of more consistent
<abu[7]>
i.e. *always* echoes the line
<abu[7]>
The "old" version did not echo anything if enter is typed on an empty line
<abu[7]>
So PicoLisp explicitly called (prinl) if (line) returned NIL
<abu[7]>
Now this (prinl) is too much
<abu[7]>
But if I remove it, the above functions are unusable, because they overwrite themselves upon each line
<tankf33der>
detect in sysdef?
<tankf33der>
detect via sysdef?
<abu[7]>
No idea
<tankf33der>
btw
<tankf33der>
more issue and w3m issue are different
<abu[7]>
yes
<tankf33der>
ok
<abu[7]>
w3m history something
<tankf33der>
what is your readline version?
<tankf33der>
If readline is called with no prompt, it should display a newline if return
<tankf33der>
is typed on an empty line. It should still suppress the final newline if
<tankf33der>
return is typed on the last (empty) line of a multi-line command.
<abu[7]>
On Termux readline/stable,now 8.2.1, on Debian libreadline-dev/testing,unstable,now 8.2-3
<tankf33der>
some distrs uses different readline forks
<tankf33der>
so mess
<abu[7]>
indeed
<tankf33der>
a lot of pain
<tankf33der>
the only hope they revert patch in the future
<tankf33der>
but your detect system will handle it anyway
<abu[7]>
Do you think this is possible? revert
<abu[7]>
if they regard it as a bug, it will not be reverted
<abu[7]>
And I don't know how to detect this
<abu[7]>
the version
<abu[7]>
I must live with it for now
<abu[7]>
Removing (prinl) makes it unusaunusable
<abu[7]>
unusable
<abu[7]>
(sorry, lost network while typing)
<tankf33der>
is possible detect this in cli mode?
<tankf33der>
i know nothing about readline&Co
<abu[7]>
cll ?
<tankf33der>
inside C code? and insert it to sysdef.c
<tankf33der>
?
<abu[7]>
Perhaps
<abu[7]>
Let's keep it for now and live with ugly empty lines
<tankf33der>
sure
<tankf33der>
afk
isaneran has joined #picolisp
_whitelogger has joined #picolisp
<beneroth>
readline is just a mess. picolisp was better without it. the supposed compatibility is nice, but obviously they don't value backwards-compatibility much.
<beneroth>
it just feels to me as if all issues which ever happened with pil21 were either 1) bugs in co-routines (now fixed) or 2) readline issues (new ones coming up from time to time...)
<beneroth>
just my feelings :/
<abu[7]>
Yeah, it is a mess
<abu[7]>
The main reason though is not compatibility, but configurability (via ~/.inputrc)
<abu[7]>
uniform across all cli applications
<abu[7]>
Another stupid thing is that readline depends on n
<abu[7]>
... on ncurses - what an overkill for editing single lines!
<abu[7]>
The whole Vip editor does not need ncurses ;)
<abu[7]>
tankf33der, your link above to the patch indeed explain it all