xkapastel has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 268 seconds]
rob_w has joined #picolisp
xkapastel has joined #picolisp
orivej has joined #picolisp
ubLIX has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
ubLIX has quit [Quit: ubLIX]
razzy has quit [Ping timeout: 260 seconds]
rob_w has quit [Quit: Leaving]
razzy has joined #picolisp
ubLIX has joined #picolisp
alexshendi has joined #picolisp
alexshendi has quit [Ping timeout: 244 seconds]
groovy2shoes has quit [Quit: moritura te salutat]
groovy2shoes has joined #picolisp
shpx has joined #picolisp
alexshendi2 has joined #picolisp
alexshendi2 has quit [Client Quit]
alexshendi has joined #picolisp
shpx has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexshendi has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 268 seconds]
grp has joined #picolisp
<grp>
Regenaxer: hi there! I've found some strange behavior: when running picolisp a script interpreter (with hashbang), (fd) return 3, which is allright, but that means I should be able to read FD 0, so if I do (in 0 (until (eof) (line T))) (msg "rest of the code"), it works if I do echo test | ./script.l (I see "rest of the code"), but not when I run it directly and feed it some text, then hit C-d
<grp>
s/picolisp a/picolisp as a
<Regenaxer>
Hi grp!
<Regenaxer>
What do you mean with "run it directly"?
Regenaxer has left #picolisp [#picolisp]
<grp>
lol
Regenaxer has joined #picolisp
<Regenaxer>
oops
<Regenaxer>
sorry
<grp>
let me paste here a few lines:
<Regenaxer>
You mean typing in the console?
<grp>
yeah
<grp>
like when using cat directly
<grp>
if you do:
<Regenaxer>
(in NIL or (in 0 is fine
<grp>
# cat
<grp>
type
<grp>
some
<grp>
input
<grp>
C-d
<grp>
it will end input there
<Regenaxer>
yes, same in pil
<grp>
not really, here's why:
<Regenaxer>
unless you do +
<Regenaxer>
which sets to raw mode
<grp>
#!/usr/bin/pil
<grp>
<grp>
(de slurp ()
<grp>
(make
<grp>
(until (eof)
<grp>
(link (line T)) ) ) )
<grp>
<grp>
(setq *Contents (in 0 (slurp)))
<grp>
<grp>
(msg "should reach here")
<grp>
<grp>
take that script
<grp>
then, if you do:
<grp>
echo test | ./script.l
<grp>
it will print "should reach here"
<grp>
if you do just:
<grp>
./script.l
<grp>
type
<grp>
some
<grp>
input
<grp>
C-d
<grp>
it will quit right there
<grp>
ignoring the (msg ...)
<Regenaxer>
hmm, yeah
<Regenaxer>
(in 0 ..) does not close stdin, so should be fine
<Regenaxer>
Perhaps the newlines?
<Regenaxer>
terminating a repl?
<Regenaxer>
What if you delete the empty lines
<Regenaxer>
hmm
<grp>
no difference
<Regenaxer>
(until (eof)
<grp>
I tried
<Regenaxer>
this is problematic
<Regenaxer>
what does (eof) mean for stdin?
<Regenaxer>
it will not terminate!
<grp>
when running the script, the code is in FD 3, but as soon as FD 0 reaches eof, pil quits
<Regenaxer>
Ctrl-D does *not* necessarily mean EOF
<Regenaxer>
it is an issue of the tty
<Regenaxer>
translatinng C-D to EOF
<Regenaxer>
So this explains it
<grp>
well, yes, but the problem is not about C-d (you can pipe C-d just fine anywhere)
<grp>
take grep for example
<grp>
grep '[A-Z]'
<grp>
type
<grp>
some
<grp>
Input
<grp>
etc
<Regenaxer>
pil needs to handle the console
<grp>
C-d
<Regenaxer>
it is different from pure stdin tools
<Regenaxer>
like cat or grep
<Regenaxer>
when on tty and stdin is gone, it can't work
<Regenaxer>
There are checks for isatty() and EOF of stdin in pil
<Regenaxer>
also error handling differs then
<Regenaxer>
So you should not wait for (eof)
<Regenaxer>
just process Stdin
<Regenaxer>
and terminate upon EOF
<Regenaxer>
This works fine, I have lots of scripts here
<grp>
but there could be stuff left to do after stdin is closed
<grp>
hmm
<Regenaxer>
Then (finally ... ?
<grp>
problem is it breaks flow
<Regenaxer>
see eg bin/pilIndent
<grp>
any read at any point finds EOF and bam! you are out
<Regenaxer>
it processes stdin
<Regenaxer>
not bam
<Regenaxer>
just do (while (char) or (while (line)
<grp>
I can manage... but still, it surprised me since it's atypical
<grp>
for example, take this ruby snippet I just wrote
<grp>
#!/usr/bin/ruby
<grp>
lines = STDIN.read
<grp>
puts "-- start --"
<grp>
puts lines.upcase
<grp>
puts "--- end ---"
<grp>
<Regenaxer>
I know what you mean
alexshendi has joined #picolisp
<Regenaxer>
It is implemented this way
<Regenaxer>
On the lowest level there may be EoF
<Regenaxer>
So what can the interpreter do?
alexshendi has quit [Read error: Connection reset by peer]
<Regenaxer>
it is deep inside the reader of the REPL
<Regenaxer>
perhaps only part of an expression read
<Regenaxer>
So the interpreter decides there is nothing to do ;)
alexshendi has joined #picolisp
<Regenaxer>
End of stdin on a tty means end of the world ;)
<Regenaxer>
The fundamental assumption is that you are in a REPL
<Regenaxer>
using stdin in this way is a second thought
<Regenaxer>
such a script way
<Regenaxer>
PicoLisp was originally not meant for such kind of scripts
<Regenaxer>
It works for "clean" scripts
<Regenaxer>
getting input from a pipe or a file
<Regenaxer>
But the tty is meant for user input (interaction, debugging)
<Regenaxer>
and EOF from user input means "end of the world"
<Regenaxer>
sorry
* grp
would have implemented it as (when (in *CodeSource (eof)) (bye))
<grp>
anyway
<grp>
not a game killer
<Regenaxer>
Why not 'finally'?
<Regenaxer>
What is *CodeSource ?
<grp>
the file descriptor where the code is being read from
<Regenaxer>
There is no such thing
<Regenaxer>
it is !isatty()
<Regenaxer>
isatty(STDIN_FILENO)
<Regenaxer>
but this is *always* the case
<Regenaxer>
I think conceptually you can't say "in code source"
<grp>
well, when you run a pil repl, (fd) returns 0, but inside a script it's most likely 3
<Regenaxer>
There is also no distinction between reading code and data
<Regenaxer>
In (in NIL it is also always 0
<Regenaxer>
like in (in 0
<beneroth>
grp, while picolisp reader is reading a script/source code file, the file is STDIN
<Regenaxer>
beneroth, not really
<grp>
nope
<Regenaxer>
it is the file descriptor
<Regenaxer>
Unix opens the file and passes it to the script
<beneroth>
hm, T
<Regenaxer>
#! mechanism
<Regenaxer>
just like picolisp script.l
<Regenaxer>
Whe hashbang means only just that the Unix kernel starts the processdirectly
<Regenaxer>
without first starting a shell
orivej has joined #picolisp
<Regenaxer>
grp, I wonder why I never felt this behavior as a problem
<Regenaxer>
Perhaps cause I have only scripts of either this or the other way?
<Regenaxer>
vip uses only keyboard input, and other only an input stream (file or pipe)
<Regenaxer>
I never felt the need to mix them
<grp>
well, I was scripting some stuff and trying to slurp stdin I found that it behaved strangely when I ran it
<grp>
I confirmed it working fine with pipes
<grp>
so it could still work for what I wanted (filter stuff)
<grp>
but still, it stroke me as strange
<Regenaxer>
T
<Regenaxer>
understandable
<grp>
so I tested it with ruby and found out it was indeed strange
<grp>
s/stuff and trying/stuff and when trying
<razzy>
btw, picochess. i have tested several cost functions agains standard picochess cost function. and complicated cost function increase time of evaluation. (no surprise). but when i adjusted depth of search in a way that time of evaluation is roughly same. my new cost function seem to be winning when being black and with less depth. which is interesting
<Regenaxer>
Yeah, interesting indeed!
<Regenaxer>
There is lot of room to optimize
<razzy>
further investigation needed
<Regenaxer>
Ideal would be both
<Regenaxer>
better cost at same speed ;)
<razzy>
but i always seem to ran into repeating and draw :]
<razzy>
so i never finished simulated game yet :]
<razzy>
i would need to disect the code more to implement same speed cost function
<razzy>
in my understanding battles are not done on empty fields.
<razzy>
i standard picochess
Regenaxer has quit [Ping timeout: 264 seconds]
<razzy>
stadard picochess cost function undervalue control over empty fields.
<razzy>
i would like to do "battle" simulation over empty fields also, so picochess value them. but i run out of time and enthusiasm.
<razzy>
btw, cannot find, where picochess value middle
<beneroth>
as far as I know, nobody here is looking as much and as deep into picochess as you did and do razzy, so you are our picochess expert :-) I'm confident you will solve this riddle too!