chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
BitPuffin has joined #picolisp
rob_w has joined #picolisp
BitPuffin has quit [Remote host closed the connection]
BitPuffin has joined #picolisp
BitPuffin has quit [Remote host closed the connection]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
f8l has quit [Remote host closed the connection]
f8l has joined #picolisp
mario-goulart has quit [Remote host closed the connection]
mario-goulart has joined #picolisp
brettgilio has quit [*.net *.split]
brettgilio has joined #picolisp
Wanderer40 has joined #picolisp
Wanderer40 has quit [Client Quit]
zaWanderer has joined #picolisp
<zaWanderer>
Hello folks. Is this the place to ask for some picolisp questions for beginners?
<abu[m]>
Hi zaWanderer, sure!
<zaWanderer>
great :)
<zaWanderer>
I am using WSL mainly, but I also have linux VM and I see the following issue
<zaWanderer>
when I run a server the baseref in the head of the html on the webpage will be "http:localhost:MACHINENAME", this makes css path not found
<zaWanderer>
on linux VM, the <base href ...> is correct "http://localhost:8080" and CSS renders correctly
<abu[m]>
Hmm, strange, I have not tried WSL
<zaWanderer>
I am a beginner, I wish I know how to trace this thing live or know how to fix it
<abu[m]>
The baseHRef gets this from the *Host global
<abu[m]>
*Host is set from the "host:" header
<abu[m]>
(sent by the browser)
<abu[m]>
It might work if you manipulate the *Host global on top of each page, but this is ugly
<abu[m]>
Normally you have:
<abu[m]>
: *Host
<abu[m]>
-> ("l" "o" "c" "a" "l" "h" "o" "s" "t")
<zaWanderer>
when I load "@lib/http.l" "@lib/xhtml.l" "@lib/form.l" printing *Host evaluates to -> NIL
<abu[m]>
You need to access a page
<abu[m]>
*Host is set on each HTTP transaction
<zaWanderer>
ok, I will run a page and print *Host and see
<zaWanderer>
Thanks. I will try when I land. I am very novice in Linux. This will save me a lot of time.
<abu[m]>
$ NAME= pil @lib/http.l ...
<zaWanderer>
Is there a reason behind this behavior?
<abu[m]>
This temporarily unsets the NAME env
<abu[m]>
Yes, NAME is set by @bin/httpGate
<zaWanderer>
Oh I see. So this won't be an issue when I go to production
<abu[m]>
I have the same application run under different names sometimes
<zaWanderer>
HttpGate will take care of it?
<abu[m]>
Yes
<abu[m]>
But in the beginning you won't need it
<abu[m]>
it is to run several applications on the same server
<zaWanderer>
Great. I wish I asked earlier 😄
<abu[m]>
The problem here is that WSL sets NAME
<zaWanderer>
Taking off now. Have a great evening
<abu[m]>
You too! ☺
zaWanderer has quit [Client Quit]
<beneroth>
always nice to see new faces :)
<abu[m]>
yess :)
seninha has quit [Ping timeout: 256 seconds]
beneroth has quit [Remote host closed the connection]
beneroth has joined #picolisp
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
rob_w has quit [Quit: Leaving]
seninha has quit [Ping timeout: 264 seconds]
fbytez has joined #picolisp
<fbytez>
Overall, I find the simplicity of this lisp's implementation very attractive, I'm wondering about how much of a hassle it would be to process, for instances, bytes of a binary file without arrays. What is the idiomatic way to do so?
<abu[m]>
It depends what to do with the bytes. Why should an array help?
<abu[m]>
I mean, bytes from files are processed all the time
<fbytez>
Mainly just what seems to be a massive overhead in memory usage, I guess.
<abu[m]>
I think so too
<abu[m]>
Usually a file is not read into memory in one piece
<abu[m]>
Though you *can* do (in "file" (till))). It will give a list of all chars
<abu[m]>
Not really useful
seninha has joined #picolisp
<fbytez>
What would be the usual method to update the raw bytes (not characters / runes) of a string?
<fbytez>
Like, decoding a URL-encoded string.
<abu[m]>
A string consists of UTF-8 chars. Accessing the bytes is tricky. Each char consists of 1 - 4 bytes
<fbytez>
Indeed, that's my point.
<abu[m]>
You can do it with (struct ...)
<abu[m]>
It is easier to manipulate the chars numerically
<abu[m]>
(mapca char (chop String))
<abu[m]>
gives a list of unicode numbers
<abu[m]>
Manipulating bytes in a string is a nightmare due to the varying lengthes
<fbytez>
I think that way round is perhaps a little less hassle. I'm thinking like, I decode a URL-encoded string; I now have a list of bytes; some of these bytes might represent a unicode character; how do I now use these bytes as a string without calling out to C or something?
<fbytez>
I feel a couple of functions in the standard library for going between strings and raw bytes would be very useful.
<abu[m]>
As I said, you can do it with 'struct'. But where would it be usful?
<fbytez>
I don't know the language very well, so if you're able to give an example, it might be the kind of answer I'm looking for.
<fbytez>
It would be useful in the kind of situation I've been describing. I often work with strings on a byte level for encoding.
<abu[m]>
I'm in the process of going to sleep. But OK, wait a minute
<fbytez>
I was just reading the 'struct' documention. I see what you mean. Write the bytes out to raw memory then read them back in.
<fbytez>
I guess the implementation is just more tied to C than I hoped.
<fbytez>
I appreciate the help, but don't let me keep you up.
<abu[m]>
No problem. Sorry, was interrupted
<abu[m]>
(setq P (%@ "malloc" 'P 9))
<abu[m]>
(byte P 66)
<abu[m]>
(byte (inc P) 0)
<abu[m]>
(struct P 'S)
<abu[m]>
-> "B"
<abu[m]>
Instead of "malloc" better use 'buf'
<abu[m]>
(buf P 200 (byte B 66) ... (struct P 'S]
<abu[m]>
Let's continue tomorrow ... ☺
<fbytez>
Right. Many thanks. Sleep well.
<abu[m]>
Thanks! Good night! ☺
<beneroth>
fbytez, you can work with raw bytes, e.g I've implemented binary protocols/file formats using picolisp.
<beneroth>
but in most practical cases you either work with complete raw bytes (and then the content is not of much interest to you), or with structured data
<beneroth>
if you work with entirely raw bytes, you're usually interested in their numeric values, maybe including shifting around etc. that can be well done and very safely in picolisp, as the picolisp number type is an integer of arbitrary length. so much less hazzle to care about buffer sizes or different int sizes.
<beneroth>
if you're interested in UTF-8, well the picolisp way would be to read them directly as UTF-8 from the input and not read them as raw bytes and then convert around.
<beneroth>
if you really do a lot low level binary processing, than yes, picolisp is not the most optimal choice. But its a great choice to manage the metadata and processing you do maybe in another executable or library.
<beneroth>
the main focus and usage of picolisp is for A) scripting (like e.g. bash, but simpler and easier to keep a database around) and B) business applications. so small to big web applications with database, where picolisp shines with its very powerful multi-paradigm database and with the simplicity of changing and extending the application when the business requirements change (which they kinda always do)
<beneroth>
gn8
<fbytez>
Indeed. When it comes to scripting, it has a very quick startup, the quickest of lisps I've tried, and calls out to other processes easily.
<beneroth>
yeah see (call) (in) (out) (pipe) and (exec)
<beneroth>
decorating or managing other cli processes with picolisp is very nice
<beneroth>
(in) and (out) can take the first argument as list, this is then interpreted similar to a call
<fbytez>
I agree; very nice.
<beneroth>
and of course you can build this list on the fly, depending on other factors
<beneroth>
it is explicitly picolisp philosophy to not re-implement stuff just for the NIH-factor, if there is a good unix/C/python tool - well use it.
<beneroth>
the goal must be less software, not more :)
seninha has quit [Read error: Connection reset by peer]