<fbytez>
Is it expected for `(char)` and `(peek)` to return NIL when encountering a NULL-byte? It's not documented and doesn't throw an error.
<fbytez>
Ignore that. My data was corrupt.
clacke has joined #picolisp
<fbytez>
Seems to depend where the NULL-bytes are. But yeah, no errors; just returns NIL as if EOF.
<abu[m]>
Good morning! Yes, this is correct, it returns NIL
<abu[m]>
No, I'm wrong. The null byte is skipped.
<abu[m]>
$ hd a
<abu[m]>
00000000 61 62 00 64 65 0A ab.de.
<abu[m]>
: (in "a" (do 6 (printsp (char))))
<abu[m]>
"a" "b" "d" "e" "^J" NIL -> NIL
<fbytez>
I see.
<fbytez>
But, it's returning NIL without error when there's more than one NULL.
<fbytez>
What's the reason for skipping?
<abu[m]>
Yeah, a second null might indeed return NIL
<abu[m]>
There is no special reason, it is an effect of the implementation
<fbytez>
I've been playing around with `(state)` to try more idiomatic code, if you're interested: http://pb1n.de/?5333a5
<abu[m]>
yes, thanks
<fbytez>
Is it only NULL bytes this behaviour applies to?
<abu[m]>
You might also try 'state' for a direct state handling
<fbytez>
I'm not sure what you mean.
<abu[m]>
Yes, the reason is that $Chr (the next byte) is zero for "uninitialized"
<abu[m]>
It causes a fetch to get the first "real" byte
<abu[m]>
$Chr is -1 for EOF iirc
<abu[m]>
I meant the 'state' function
<abu[m]>
oops, sorry! You are using it :)
<fbytez>
Which I am using in that example. Do you mean to use it differently?
<fbytez>
Right.
<abu[m]>
I looked at the wrong place
<abu[m]>
No, looks good at the first glance
<abu[m]>
I was a bit mislead by the indentation
<fbytez>
Hmm... So, why do consecutive NULLs cause the NIL return?
<fbytez>
Should it not, in theory, just keep skipping?
<abu[m]>
The first one causes a single fetch. But if that is NULL again, it returns a symbol as ever, but a single null byte is "no name" so it gives NIL
<abu[m]>
It could keep skipping, yes, but a null byte is considered illegal
<fbytez>
Would it not be better to signal an error then?
<abu[m]>
The behavior is just a result of the implementation, i.e. 0 being uninitialized
<abu[m]>
I would not signal an error
<abu[m]>
Needs a lot of bookkeeping
<fbytez>
I just think it follows from "considered illegal".
<fbytez>
Maybe some extra info in the documentation?
<abu[m]>
Correct, but the PicoLisp philosophy is "be pragmatical" and not "be pedantic"
<abu[m]>
You can create lots of other illegal inputs
<abu[m]>
For example, non-UTF-8 is also not checked I think
<abu[m]>
It gives rather garbage
<abu[m]>
I see it often if I edit a binary file with vip
<fbytez>
I think it would be useful to have this information in the documentation for `(peek)` and `(char)`.
<abu[m]>
(not that you *can* edit binary files with vip, but it happens if I open an encrypted file)
<abu[m]>
The information that illegal data give garbage?
<abu[m]>
Perhaps "illegal" is the wrong word
<fbytez>
Not that, as such. Because one would expect "garbage in = garbage out", but NULL bytes being skipped or inferred as EOF is more surprising.
<fbytez>
Otherwise one can assume it really is EOF.
<abu[m]>
It is not only 'char' or 'peek', but all reading like 'read', 'line' etc. Would need a whole chapter in general
<fbytez>
Right. Actually simpler in that case. It could be more like a paragraph than a chapter.
<abu[m]>
This EOF could also be a feature :) Like 'load'ing NIL also behaves as eof
<fbytez>
Yeah, just that it's undocumented; therefore surprising.
<abu[m]>
Hmm, I think it is at least indirectly documented
<fbytez>
Any idea where?
<abu[m]>
For 'read' it says "NIL is returned upon end of file". As 'load' is read-eval, it follows that 'load' stops on NIL
<fbytez>
Yeah, we're talking about NULL-bytes, though.
<abu[m]>
When I called this a possible "feature" it was more meant as a joke. I see no real practical use case.
<fbytez>
I understood.
clacke has quit [Read error: Connection reset by peer]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #picolisp
seninha has joined #picolisp
clacke has joined #picolisp
m_mans has joined #picolisp
<m_mans>
Hi all!
<aw->
hey m_mans, thanks for keeping github.com/picolisp/pil21 up-to-date
<m_mans>
Hi aw-, you're always welcome ). How are you?
<abu[m]>
Hi m_mans!
<aw->
i'm good, thanks!
<aw->
disconnecting now, cheers!
<m_mans>
abu[m]: hi, how are things?
<m_mans>
Is it possible to copy whole paragraph/expression in Vip?
<abu[m]>
Yes, like Vi "y}"
<m_mans>
hm, it doesn't work for me, maybe I'm doing it wrong
<m_mans>
e.g. "yw" is ok, but "y]" just beeps
<m_mans>
oops, moment
<m_mans>
oh, stupid me, just need to press Shift
<abu[m]>
yes, } ☺
<abu[m]>
btw "yw" behaves a little different from VI. Instead we have "yTAB"
<m_mans>
Got it. Another question: is there any simple way to copy test from remote vip to local clipboard?
<m_mans>
text
<m_mans>
MacOS -> SSH to remote Linux server -> tmux+vip
<abu[m]>
When I'm in Vip on a remote machine via SSH, I use Termux Touch+Copy
<abu[m]>
Perhaps some custom command?
<abu[m]>
We have :cp but this copies to *local* clipboard only
<abu[m]>
I do e.g. "y}:cp"
<m_mans>
Ah, just selecting text with touchpad and Cmd-C seems OK
<abu[m]>
That's the easiest :)
<m_mans>
T
<m_mans>
thanks!
<abu[m]>
☺
<abu[m]>
On Termux I call termux-clipboard-set via :cp in Vip
<m_mans>
what do you think, adding scrolling support via touchpad/mouse needs much work?
<abu[m]>
Not sure, here in Termux it works
<abu[m]>
Termux generates Arrow-Keys when swiping I think
<abu[m]>
Do you use Tmux on the remote side? (I do)
<abu[m]>
I think Tmux can also be configured to send Arrow-Keys
<m_mans>
yes, also tmux
<m_mans>
interesting that scrolling with touchpad works in vim, but I don't know what I need to achieve the same in vip
<m_mans>
I mean ssh+tmux of course
<abu[m]>
Perhaps some other escape sequence?
<abu[m]>
I always view with this: (make (link (key)) (while (key 80) (link @)))
<abu[m]>
For example, UpArrow gives -> ("^[" "[" "A")
<abu[m]>
Same if swiping up in Termux
<m_mans>
same here for UpArrow. But using touchpad shows nothing. OK, np, I want too much for beginning ), just need to learn step by step
<abu[m]>
Good :)
<abu[m]>
There is surely a way
<abu[m]>
Do you have in your .tmux.conf "set -g mouse on"?
<m_mans>
now I have, but no luck )
<abu[m]>
Yeah, probably it scrolls Tmux itself, not the application
<abu[m]>
I have "mouse off" here
<m_mans>
T, it seems to scroll Tmux itsels
<abu[m]>
So it is just Termux here which gives this nice behavior
<abu[m]>
Seems you need to configure your local terminal somehow. XTerm?
<m_mans>
ITerm2
<m_mans>
ah, nice, I've tried in another terminal application, scrolling works there
<abu[m]>
Very good! )
clacke has quit [Remote host closed the connection]
<m_mans>
funny, after printing this (prinl "ESC [?1003h") "key" function starts to receive mouse events as well
<abu[m]>
👍👍
<m_mans>
I've replaced escape char with ESC (don't want to make bad things to someone's terminal
<abu[m]>
right
<abu[m]>
Also for the records: Vip does not use [N]Curses
m_mans has quit []
<fbytez>
Is there anything in the library that provides `stat()`-like information, more than `(info)` does?
<abu[m]>
Unfortunately not
<abu[m]>
I also missed it occasionally
<fbytez>
Does the "web app library" accommodate typical HTML forms that use "GET"? Like, if the server receives a request like "GET /this/path?name=value HTTP/1.0", where would 'name' and 'value' be?
<fbytez>
It was this type of thing that actually led me down most of the rabbit holes I've been down.
<abu[m]>
In this case "value" would be stored under the 'http' property of the symbol 'name'
<abu[m]>
('name' needs to be 'allow'ed though)
<abu[m]>
More typical is ..?*Name=value
<abu[m]>
if '*Name' is allowed, its value is 'set'
<abu[m]>
i.e. a global
<fbytez>
Yes, right. I think it was the '*Name' format that gave me troube in w3m when I initally tried it, which was rather a long time ago.
<abu[m]>
But you can also support a syntax ?foo&+123&-A7
<fbytez>
But it would also work as 'name' if allowed?
<abu[m]>
Then you get 3 arguments
<abu[m]>
with a string "foo", a number 123 and a n external symbol {A7}
<fbytez>
And also `?a=1&b=2&c=3` ?
<abu[m]>
Yes
<abu[m]>
always stored under the 'http' property
<abu[m]>
if a, b and c are allowed
<abu[m]>
I think I never used it
<abu[m]>
or perhaps once or twice, if some external URL syntax was mandatory
<fbytez>
So, like `(get 'a 'http)` -> 1 ?
<abu[m]>
exactly
<abu[m]>
well, -> "1" to be exact
<abu[m]>
transient symbol
<fbytez>
Yes, right, sorry.
<abu[m]>
?a=+1 would give a number
<fbytez>
Ah, OK, so there it would "break" as '+' would "normally" be a space.
<abu[m]>
Good question, I don't remember
<abu[m]>
: (ht:Fmt 1 "a c" 7)
<abu[m]>
-> "+1&a%20c&+7"
<abu[m]>
So if encoding, pil uses hex notation for spaces
<fbytez>
Yeah, I'm sure it's correct from the pil side, just doesn't work with what a browser would send from the form.
<abu[m]>
I'm not sure atm if these rules also apply to the 'http' property case
<fbytez>
Oh, OK.
<abu[m]>
But it is so for ?*Var=val
<abu[m]>
The http thing is for "foreign" clients kind of
<fbytez>
When using the global form as you just did above, there's no 'http' property, right?
<abu[m]>
right
<abu[m]>
directly into the value
<abu[m]>
Looking at the source, I think it applies to http properties too
<abu[m]>
It is the 'htArg' function in @lib/http.l
<abu[m]>
(cond (setq A (split A "=")))
<abu[m]>
... (_htSet (car A) (htArg (cadr A))))
<abu[m]>
So *Var= and var= are handled the same way
<fbytez>
That's unfortunate, as it seems that '+' is the only "problem" character.
<abu[m]>
Might be, but only if it is the very first character of the value
<abu[m]>
i.e. a leading blank
<fbytez>
I don't really know anything about namespaces in pil; could I simply redefine `(htArg)` before calling `(server)`?
<abu[m]>
Yes. No need for a namespace even
<fbytez>
I didn't know if it was somehow "protected" by a namespace or something.
<abu[m]>
No problem
<abu[m]>
Just (de htArg ...
<abu[m]>
Put (undef 'htArg) before that to avoid a warning message
<fbytez>
Would also work during a `(let (htArg '((...]`, right?
<abu[m]>
Yes
<abu[m]>
for a local redefine
<abu[m]>
(let htArg '((Lst) ...
<abu[m]>
Another way is 'patch' (global change)
<fbytez>
Ooo, yeah...
<abu[m]>
Do you have such a use case?
<abu[m]>
I mean, where such URLs are requested
<abu[m]>
I think they are seldom, because usually the server decides the URL format
<fbytez>
Yes. As I say, it's this type of thing that led me down most of the rabbit holes I've been down.
<fbytez>
It's basically to do with integrating with other existing / standard things.
<abu[m]>
Which client would request a problematic URL?
<fbytez>
Like, when I reported `(hex)`s behaviour.
<abu[m]>
(hex) also was not a problem
<fbytez>
Well, you changed it.
<abu[m]>
Only because it was important for you
<abu[m]>
(hex) was never used for arbitrary input. It was always guaranteed to be legal hex chars, so a runtime overhead is useless
<fbytez>
Right. That's fair enough. It wasn't documented behaviour though, which was why I reported it.
<abu[m]>
Yes, so in the end 'hex' is improved :)
<abu[m]>
But which client is concievable generating problematic URs?
<abu[m]>
Also, Pil apps normally use the 'form' gui
<abu[m]>
There the variables are abstracted away
<fbytez>
Like I said, "It's basically to do with integrating with other existing / standard things."
<abu[m]>
OK
<fbytez>
So, a normal 'GET' form could be an issue; albeit in few cases.
<abu[m]>
Right. My focus was mainly on web applications
<fbytez>
I like to know edge cases so I am able to code accordingly.