<Regenaxer>
trim is needed only for input garbage where the indentation is to preserve
<aw->
ok i will test your theory
<Regenaxer>
Not really a theory :)
<Regenaxer>
rather practical observation
<aw->
ok thanks!
<aw->
i should get back to code
<Regenaxer>
Me too :)
alexshendi has quit [Read error: Connection reset by peer]
clacke[m] has quit [Ping timeout: 256 seconds]
rick42 has quit [Ping timeout: 260 seconds]
rick42 has joined #picolisp
clacke[m] has joined #picolisp
alexshendi has joined #picolisp
alexshendi has quit [Ping timeout: 240 seconds]
aw- has quit [Quit: Leaving.]
<beneroth>
you're stubborn Regenaxer ;)
<beneroth>
though most times rightly so
<beneroth>
:)
<Regenaxer>
agree, but which stubbornness do you refer to?
<beneroth>
I'm not sure, haha
<Regenaxer>
The 'clip' issue?
<beneroth>
it's an example, yes. though I guess I think you are right
<Regenaxer>
Thanks! :)
<beneroth>
it's hard to draw the line: when should something be standard, and when should it be a use-case/app-specific DSL ? its difficult. especially when the core language of lisp is arguably just a few functions.
<Regenaxer>
yep
<beneroth>
important point is to try to explain the reasoning.
<beneroth>
and not losing patience.
<Regenaxer>
T
<beneroth>
everyone believes he/she has the best reasons for their arguments. and I would say, in most cases in this group people try to argue quite some against themselves before bringing the issue to the table
<Regenaxer>
Good to discuss such things here
<beneroth>
you're strategy is to focus on the 90% (or maybe 99%) use cases from a radical practical point of view
<Regenaxer>
yes, and practical means use cases, but sometimes also efficiency
<beneroth>
T
<Regenaxer>
ie. a seldom used function may be impossible or inefficient when written in Lisp
<beneroth>
another approach is logical elegance. aw argued from that perspective in this case. (as I see it) you love logical elegance, but it takes second priority after practicability.
<beneroth>
the elegance approach can lead to nice mental masturbation models with no real life use. e.g. XML, UML, etc.
<Regenaxer>
hehe, yes
<beneroth>
(I mainly mean about the fact that there people even built a theory where the thing itselfs fits into its own theory.. more or less completely.. more likely less, gödel etc)
<beneroth>
though the too-practical approach can lead to very domain-specific idiosyncratic design, hard to understand or reuse when not coming from the same background/use cases
<beneroth>
example.. hm.. maybe perl? :D
<beneroth>
the fact that picolisp text IO cannot handle NULL in input I still find extremely inelegant... but I see your technical reasoning (haha, took me a while), no point to sacrifice efficiency in general case for a pretty unusual case
<beneroth>
problem is one has to be aware of all this edgy use cases
<Regenaxer>
Hmm, it can handle
<Regenaxer>
it is not an IO problem
<Regenaxer>
it is symbol internal implementation
<Regenaxer>
symbols names
<Regenaxer>
They *can* have a null byte, but it terminates the name
<beneroth>
not with (till)
<Regenaxer>
Exactly the same as in C
<beneroth>
T
<Regenaxer>
no as till returns symbols
<beneroth>
hm. ok. you are right.
<Regenaxer>
Zero is binary, so it must be handled with (rd)
<beneroth>
one could argue the same should be valid for TAB and the other special whitespaces
<Regenaxer>
No, all other chars can be part of symbol names
<Regenaxer>
Remember, just as in C
<beneroth>
I don't want to discuss that specific case, I don't think we missed any insights there (except me not formulating it technically correct)
<Regenaxer>
The null byte is needed to terminate symbol names
<Regenaxer>
Like in C ;)
<beneroth>
just another example of your stubbornness. and.. I think your stubbornness was well placed in that case. arguably, if it is purposeful you can be convinced after a while :D
<beneroth>
aye
<beneroth>
and it makes sense. only other solution would be storing lengths everywhere.
<Regenaxer>
It is not stubbornness in this case, there is simply no other way technically
<beneroth>
and its a better solution than FORTRAN strings (fixed length à la C, but end is always padded with whitespaces)
<Regenaxer>
Not a question of wanting or not wanting to implement
<beneroth>
T
<Regenaxer>
Yes, fixed length is the other design decision, also eg. in Pascal
<Regenaxer>
This limit the max length
<beneroth>
hm
<Regenaxer>
in org. Pascal it was 1 byte count
<beneroth>
you are right
<beneroth>
I can't find even an infeasible alternative :D
<Regenaxer>
So I decided against it. "Unlimiteness"
<Regenaxer>
Well, a count of 8 bytes would do, but is a huge waste
<Regenaxer>
2 bytes limit to 65535 bytes
<Regenaxer>
Oops, sorry, being called
<Regenaxer>
Some duties :)
<Regenaxer>
afp
<beneroth>
bbl :)
alexshendi has joined #picolisp
orivej has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
jibanes has quit [Ping timeout: 240 seconds]
jibanes has joined #picolisp
<Regenaxer>
ret
jibanes has quit [Ping timeout: 240 seconds]
jibanes has joined #picolisp
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #picolisp
alexshendi has joined #picolisp
mario-goulart has quit [Remote host closed the connection]
mario-goulart has joined #picolisp
alexshendi has quit [Ping timeout: 250 seconds]
dtornabene has joined #picolisp
dtornabene_ has joined #picolisp
dtornabene has quit [Read error: Connection reset by peer]
dtornabene_ has quit [Ping timeout: 264 seconds]
sriram_ has quit [Ping timeout: 260 seconds]
reed has joined #picolisp
<reed>
Hi all, is there a standard way to do Unix sockets on PicoLisp? I see that there's some documentation on websockets, but I'm looking for the local version. I.e. as if it were created with the "AF_LOCAL" keyword in C
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
reed has quit [Quit: Page closed]
mario-goulart has quit [Remote host closed the connection]