ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Picolisp latest found at http://www.software-lab.de/down.html | check also http://www.picolisp.com for more information
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Client Quit]
orivej has joined #picolisp
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #picolisp
aw- has joined #picolisp
<rick42> sup aw-!
<rick42> oh wow this looks very useful:
<rick42> : (1 2 #{ 3 }# 4)
<rick42> -> (1 2 4)
<rick42> gonna have to remember that
<rick42> gnite peeps
<aw-> hello
<aw-> yes i never use #{ }# since i only found it recently.. could be useful
<m_mans> Hi all
<m_mans> Regenaxer: possibly there is a bug with getting exit code from 'call
<m_mans> : (prog (call "curl" "aaa") (prinl "exit code=" @@))
<m_mans> curl: (6) Could not resolve host: aaa
<m_mans> -> 1536
<m_mans> exit code=1536
<aw-> hmmm
<aw-> hi m_mans, interesting observation
<aw-> works for me
<aw-> ohhhh
<aw-> oops
<aw-> exit code is 6
<aw-> not 1536
<m_mans> pil32 return the same
<m_mans> returns
<aw-> if you just do: (call 'curl "aaa")
<aw-> then (prinl @@)
<aw-> i get NIL
<m_mans> don't do it in REPL
<m_mans> do it with prog
<m_mans> @ @@ etc, they all are used by REPL
<aw-> seems fine if i use the provided example: (cons (call "sh" "-c" "kill -SEGV $$") @@ (hex @@))
<m_mans> aw-: do you get 1536 with curl?
<aw-> yes
<aw-> why does the provided example do (hex @@) ?
<aw-> well anyways.. something definitely strange
<aw-> exit code should be 6
<Regenaxer> Good morning m_mans, aw-
<Regenaxer> Note that the exit call in Unix is only a single byte
<Regenaxer> : (hex 1536)
<Regenaxer> -> "600"
<Regenaxer> The other byte has different meaning
<aw-> hi Regenaxer
<aw-> sorry if i'm hitting your server so much today
<aw-> was testing some things with travis-ci
<Regenaxer> no problem
<aw-> well.. PicoLisp is (for now) less than 1MB download, i doubt it would impact your bandwidth very much
<Regenaxer> Ah, you mean real bandwidth :)
<Regenaxer> I thought you mean questions here ;)
<Regenaxer> np anyway
aw- has quit [Ping timeout: 256 seconds]
aw- has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #picolisp
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #picolisp
<aw-> Regenaxer: i need your brain for a minute ;)
<Regenaxer> good :)
<aw-> i have a program which reads/writes directly to/from /dev/tty*
<aw-> having difficulty using (call) in pil with that program
<Regenaxer> What happens?
<aw-> as soon as I type one character, the program quits
<aw-> instead of reading what i typed
<aw-> from cmdline, it reads and waits until i press Enter
<aw-> but with (call 'extprogram) it exits after just 1 char
<Regenaxer> Hmm, tricky things
<Regenaxer> Depends how the programs meddle with the console mode
<aw-> in bash you can do echo something >&3
<aw-> goes straight to the tty
<Regenaxer> raw vs. cooked
<aw-> ah yes that makes sense
<aw-> if I do (call 'extprogram) (raw)
<aw-> it outputs T in the REPL
<Regenaxer> Can you try (raw NIL) ?
<Regenaxer> in the program
<aw-> hmmm
<aw-> how?
<aw-> i didn't create it
<Regenaxer> ah, I thought it is a pil script
<Regenaxer> then before you call it?
<aw-> yes i tried, same issue
<Regenaxer> :(
<aw-> i don't think there's a way to prevent it from using /dev/tty
<aw-> but can I make my pil code write to that?
<aw-> maybe that would work
<Regenaxer> You mean it explicitly opens /dev/tty ?
<aw-> (out '/dev/tty (call 'xtprog)) ?
<aw-> yes
<Regenaxer> not stdin?
<aw-> exactly
<Regenaxer> ok
<Regenaxer> Programs like vim or vip work fine via 'call' though
<cess11> tmux too
<cess11> sometimes I run extra tmux sessions from within pil
<Regenaxer> interesting
<Regenaxer> What if you change the tty of the pil process then?
<Regenaxer> With 'ctty'?
<Regenaxer> just temporarily
<cess11> never tried, I'll take a look.
<Regenaxer> It is a strange mechanism, I don't remember the details atm
<Regenaxer> I use it in 'psh' iirc
<aw-> (ctty) ! sounds promising
<Regenaxer> Perhaps experiment around a little
<aw-> yes i've tried so many things
<aw-> (ctty) doesn't work either
<Regenaxer> hmm
<aw-> with strace, i can see it opening /dev/tty
<aw-> then writing directly to it
<aw-> i can't interact with it from pil
<Regenaxer> I would expect if you revert the tty to cooked with (raw NIL) before calling it, it should be fine
<aw-> hmmmm
<Regenaxer> What else might go wrong?
<aw-> i think picolisp can't solve this
<aw-> i tried running strace extprog
<aw-> as soon as I type 1 character, it sends that PLUS \n
<Regenaxer> and if you call it from bash it doesn't?
<aw-> exactly
<Regenaxer> What if you call it via (pipe (exec 'extprog instead of 'call'?
<Regenaxer> pipe redirects the streams
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
<aw-> (pipe (exec 'extprog .. ?
<aw-> then what?
<Regenaxer> It returns an FD, 'close' it when done
<Regenaxer> (in case it works this way)
<Regenaxer> Another idea: (call "sh" "-c" "extprog")
<Regenaxer> not sure ;)
<aw-> oh haha nice.. doesn't work
<aw-> but that gave me another idea
<Regenaxer> This Unix tty legacy stuff is a real mess!
<aw-> argh
<Regenaxer> same with [n]curses
<aw-> i know
<Regenaxer> :)
<Regenaxer> termcaps and terminfo etc.
<aw-> hmmm
<aw-> it's strange that typing "a" would be read as "a" then "\n"
<aw-> seems like an encoding issue
<Regenaxer> I think the "\n" is not read, but added by the program when input is done
<Regenaxer> in cooked mode it gets only input when a line is sent
<aw-> yes you're right
<aw-> what does this mean from strace:
<aw-> read(0, "t", 512)
<Regenaxer> "t" is just the buffer
<Regenaxer> holds garbage
<aw-> i typed t
<Regenaxer> ok
<Regenaxer> it reads a buffer of 512 bytes, but 'read' returns immediately
<Regenaxer> cause of raw mode
<Regenaxer> so this is correct
<Regenaxer> The problem is the console mode
<aw-> interesting..
<aw-> reading from fd 0
<Regenaxer> stdin, yes
<Regenaxer> So it did a reopen
<Regenaxer> freopen() perhaps
<aw-> in pil, how can i read/write to/from /dev/tty ?
<aw-> (in (out '/dev/tty ... ?
<Regenaxer> yes
miskatonic has joined #picolisp
<m_mans> hi Regenaxer! So, there is no bug with exit code (as often :)? I just should take high byte, right?
<Regenaxer> yes
<m_mans> hehe, I was not aware of that. Need more Unix (or Linux) knowledge
<m_mans> thank you for the explaining!
<Regenaxer> :)
<m_mans> maybe we need to indicate it in the documentation? What do you think?
<Regenaxer> Well, it is a matter of each program what it returns
<Regenaxer> it is a 16-bit int
<m_mans> for me it's strange that bash sees just that byte, but picolisp sees something other
<m_mans> trying to google anything about all this
<m_mans> np in general, I just learning more :)
<aw-> Regenaxer: another strange thing, if I run extprog from within a bash script, it works fine
<Regenaxer> m_mans, cool, perhaps you can tell us your insights then
<Regenaxer> aw-: the bash does not change the console mode - does the pil script set raw mode at all?
<Regenaxer> ie. debug mode + line edit?
<aw-> hmmm not sure
<Regenaxer> Start pil without +
<m_mans> I've found something in https://en.wikipedia.org/wiki/Exit_status
<m_mans> it seems that *older* interfaces return only first byte, but in modern systems exit status is 32bit. Got it now
<Regenaxer> ah, 32, ok
<Regenaxer> yes
<Regenaxer> ld4 (S) # Result?
<Regenaxer> line 3352 in src64/flow.l
<Regenaxer> ld4 gets 4 bytes, 32 bits
alexshendi has joined #picolisp
<aw-> Regenaxer: i got it!
<Regenaxer> Works without '+'?
<aw-> no
<aw-> you were right all along
<Regenaxer> :(
<aw-> cooked/raw
<aw-> i did (raw NIL)
<aw-> and then use (exec 'extprogram)
<Regenaxer> ah! :)
<aw-> works fine
<Regenaxer> good
<aw-> all my tests were with (call 'extprogram)
<m_mans> I didn't know before that curl can easily send emails :)
<Regenaxer> cool, didn't know either
<aw-> probably better to do (unless (fork) (exec ...)
<aw-> so my code keeps running ;)
<Regenaxer> true
<aw-> hmmm... no.. i need it to wait for the (exec) to end
<Regenaxer> then call is fine
rob_w has joined #picolisp
<aw-> no
<aw-> doesn't work with (call)
<aw-> i'm not sure what's different between (call) and (exec).. but (exec) seems to work fine with the extprogram... (call) doesn't
<Regenaxer> 'call' does cc setpgid(0 0) # Set process group
<Regenaxer> this must be the reason
<Regenaxer> It is needed so that ^Z (SIGSTP) is passed through iirc
<aw-> hmmm
<Regenaxer> a mess ;)
<Regenaxer> Without it, (call 'vi) does not behave well in such cases (iirc)
<aw-> haha
<aw-> ok question
<aw-> how do I (exec) and wait for it to complete?
<aw-> (unless (fork) (exec ..) (wait) ?
<Regenaxer> no
<Regenaxer> that's another wait
<Regenaxer> exec does not even return
<Regenaxer> Only 'call' and 'in/out' wait for the child
<Regenaxer> You could use 'in'
<Regenaxer> (in '("extprog" ..)
<Regenaxer> but then your main process waits just as in 'call'
<aw-> yes i want the main process to wait
<Regenaxer> ok, then 'in' or 'out'
<Regenaxer> better 'in' I would say
<Regenaxer> without any reading from the process's stdout
<aw-> (in does the same thing as (call
<aw-> doesn't work
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
orivej has quit [Ping timeout: 256 seconds]
<aw-> Regenaxer: what does this mean: "the current process is replaced with a new process image. " ?
<aw-> what is a process image?
orivej has joined #picolisp
<beneroth> aw-, the executable which is running
<beneroth> I would think
<beneroth> "the current process is replaced with a new process image. " -> the newly started process takes over the Pid from the current process. the current process ceases to exist kinda.
<beneroth> this is my understanding. not sure it this helps you :)
<aw-> hmmm
<aw-> why does it do that?
<beneroth> probably it is inspired by the linux exec. man exec.
<beneroth> "original process identifier (PID) does not change, but the machine code, data, heap, and stack of the process are replaced by those of the new program."
<aw-> beneroth: thanks
<beneroth> apparently everything gets replaced by the new program, except for file descriptors. so the new program can inherit stdin/stdout/stderr. and probably other open file descriptors?
<beneroth> dunno if this is the same for the picolisp exec
<Regenaxer> yes, correct
<Regenaxer> it calls directly the exexXXX() system call
<aw-> hmmm... ok so in that case i will do (exec 'somebashscript), and that script will simply call 'extprogram, and then continue processing as i wish
<aw-> it's the only way
<beneroth> aw-, apparently, in the past exec was used to save memory (as the memory of the calling process gets freed just before / right when the new process starts)
<Regenaxer> call is fork + exec basically
<beneroth> Regenaxer, so all open file descriptors get inherited by new process? (including e.g. an opened pilDB) ?
<Regenaxer> yes, but pil sets closeonexec on such FDs
<Regenaxer> io.l:(code 'closeOnExecAX)
orivej has quit [Ping timeout: 256 seconds]
<beneroth> oh ok
<Regenaxer> What is usually interesting is stdio
<beneroth> maybe also useful to share a common log file between serially running processes
<Regenaxer> This is the really brilliant feature of Unix
<Regenaxer> fork and exec are separate
<Regenaxer> Windows has just spawn()
<Regenaxer> for a new process
<Regenaxer> yes, log files too, but I use stdout and stderr for that
<beneroth> btw I heard in unix it is possible to hand over a file descriptor (e.g. a socket) to another process. would this also possible with pil, e.g. handing a socket via (tell)-pipe to a child ?
<Regenaxer> Not sure, haven't looked at that
<beneroth> this would be interesting for a non-forking server architecture
<beneroth> ok
<Regenaxer> yes
<Regenaxer> Probably with 'native'
<aw-> thanks for the help Regenaxer and others
<Regenaxer> :)
<aw-> you're all awesome
<aw-> and Linux tty stuff is a mess
<Regenaxer> sadly yes
<Regenaxer> Not Linux' fault though
<Regenaxer> bbl
<Regenaxer> ret
alexshendi has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Client Quit]
orivej has joined #picolisp
<cess11> I've generated bash scripts and run them from pil sometimes
<cess11> not often but it happens that this is the easiest way
<cess11> as for living through the mess of unixlike, https://en.wikipedia.org/wiki/Advanced_Programming_in_the_Unix_Environment is a great friend to have
beneroth is now known as bene|off
<Regenaxer> T
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
chuckJ has joined #picolisp
Regenaxer has joined #picolisp
chuckJ has quit [Ping timeout: 256 seconds]
aw- has quit [Quit: Leaving.]
orivej_ has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej_ has quit [Ping timeout: 260 seconds]
orivej_ has joined #picolisp
orivej has quit [Ping timeout: 276 seconds]
chuckJ has joined #picolisp
chuckJ has quit [Ping timeout: 256 seconds]
<rick42> hi all
<rick42> insteresting convos with aw and m_mans
<rick42> i agree with this --> <aw-> you're all awesome
<rick42> "<Regenaxer> better 'in' I would say"
<rick42> this disagrees with Shrek who famously said: "Better out than in, I always say." ;-)
<rick42> bbl
rob_w has quit [Read error: Connection reset by peer]