chexum has quit [Quit: No Ping reply in 180 seconds.]
chexum has joined #picolisp
z4k4ri4 has joined #picolisp
Iacob has quit [Ping timeout: 260 seconds]
clacke has quit [Read error: Connection reset by peer]
seninha has joined #picolisp
Iacob has joined #picolisp
seninha has quit [Ping timeout: 255 seconds]
seninha has joined #picolisp
beneroth has joined #picolisp
rob_w has quit [Quit: Leaving]
<DKordic>
abu[san]: FORTH is missing ""Pattern Matching"", in Haskell speak. [ 1E0 to ( float64 bits ) ] , a Casting Operation, could be a Zero-Cost Abstractions!
<abu[m]>
Hi DKordic! I don't grasp the connection Pattern Matching to Floats to Casting ...
<DKordic>
Yes, I was wrong it would not be Casting... Values but Interpretation of bits. The simplest example of PM would be [ defn ( car ( cons First Rest ) ) First ] . [ defn ( .bits ( float32 bits ) ) bits ] .
<DKordic>
Hi abu[san]
hrberg has joined #picolisp
<abu[m]>
OK, so casting is not wrong
beneroth has quit [Remote host closed the connection]
beneroth has joined #picolisp
seninha has quit [Ping timeout: 276 seconds]
fbytez has joined #picolisp
<DKordic>
fbytez: Welcome.
<fbytez>
Cheers.
<abu[m]>
Hi fbytez!
<fbytez>
Hello.
<beneroth>
hi all
<abu[m]>
Servus beneroth!
<beneroth>
in the mood for some socket handling and server architecture questions? or better another time.. not urgent :)
<abu[m]>
Not so good at the moment. Family meeting :)
<beneroth>
that's alright :)
<abu[m]>
☺
<beneroth>
greetings to whoever has heard of me ;)
<abu[m]>
Sure!
<abu[m]>
It is Mia and her boyfriend
<fbytez>
Evening, beneroth.
<beneroth>
nice, say hi from me. I just recently visited her website about picolisp again, it's awesome.
<beneroth>
evening fbytez :)
<abu[m]>
Greetings back from her
<beneroth>
did you read the IRC log? we discussed a bit further after you left and figured out why your code got stuck in (char)
<beneroth>
abu[m], thanks :D
<fbytez>
I know why it stuck; it was abu[m] that didn't seem to get it.
<beneroth>
he did get it
<beneroth>
as often in such case, it was not a bug in picolisp, but a misunderstanding
<fbytez>
Well, the whole discussion stemmed from him keep telling me that I could just use (char) to achieve what I was trying to do.
<beneroth>
yes. and that was not wrong
<fbytez>
I never suggested there was a bug.
<beneroth>
your problem was the double use of (char)
<abu[m]>
yes, I did not see that there is another level of buffering because of 'input'
<fbytez>
No, nothing to do with 'input'.
<abu[m]>
'input' buffers one char look ahead
<beneroth>
certainly it was because of input.
<fbytez>
I shouldn't have come back.
<abu[m]>
So you did not get the final newline/return
<beneroth>
fbytez, :(
<beneroth>
fbytez, why not? we can solve it in a friendly manner. But I'm very sure abu[m] and me understood it right
seninha has joined #picolisp
<beneroth>
of course, if you think its wrong that (char) buffers a look ahead, that's an opinion, no point arguing about that. but the issue was, that because if (input) you had in fact two layers of look-ahead buffers. so whenever you read one (char) on the top layer, the (char) within (input) did an additional look ahead. that's how it got stuck one char after end of message.
<beneroth>
fbytez, did I write it in an understandable way?
<beneroth>
yes (input) it was in the more complex example we discussed. it was not obvious to both abu and me that input causes the double buffering, but of course its correct. input is not faulty.
<beneroth>
the normal buffering of (char) was obvious to us, and we thought also to you
<beneroth>
but (input) works correctly as designed and so does (char).
<beneroth>
we can of course argue about the trade-offs for the current design of these functions.
<beneroth>
but (char) can hardly be changed now, with 30 years of software based on the current way of working :)
<fbytez>
It wasn't obvious to abu[m] .
<beneroth>
you are aware that abu[m] is the creator of whole picolisp, yeah?
<fbytez>
I was being told I could use (char) to do that; I can't. Simple as that.
<beneroth>
yeah. obviously you both misunderstood each other about what "that" was referring too, agreed?
<fbytez>
I didn't misunderstand.
<beneroth>
or you want to claim that abu[m] gave you wrong advice in bad faith?
<fbytez>
Nothing to do with "bad faith". He was just incorrect.
<abu[m]>
What exactly did I misunderstand?
<beneroth>
he assumed the sender to send EOF / close the pipe. he wrote that.
<fbytez>
So, misunderstood.
<fbytez>
I clearly stated that was not the case.
<fbytez>
Multiple times at this stage.
<abu[m]>
I did forget that 'input' does another level of buffering. But this is not ther problem in your example without 'input'
<beneroth>
aye
<abu[m]>
What was not the case?
<abu[m]>
It is all very simple
<fbytez>
Going round in circles... You were telling me that I could use `(char)` for this, which I clearly can't. It's that simple.
<abu[m]>
The stream is read, always with one char ahead
<abu[m]>
It is your problem what you do with it
<fbytez>
Yeah, but it doesn't change that you were mistaken.
<abu[m]>
Mistaken in which regard? Sorry, I'm lost, we discussed many variations
<beneroth>
abu[m] was mistaken about the use case of fbytez
<abu[m]>
I just know that the stream works correctly and as expected
<beneroth>
T
<fbytez>
What an ego.
<beneroth>
hahaha, yes indeed, I wonder about your ego too.
<fbytez>
I have said nothing incorrect.
<beneroth>
nobody claimed so.
<abu[m]>
right
<fbytez>
You implied it with your " hahaha, yes indeed, I wonder about your ego too."
<fbytez>
What is the ego you're laughing about if not that?
<beneroth>
no. I imply that it looks to me as you are a person with a big ego.
<fbytez>
Because?
<fbytez>
I have been trying to discuss 'facts' and nothing else.
<beneroth>
yes, but you got heated up and rage quitted over communication issues.
<beneroth>
not a sign of humility and zen calmness exactly, right?
<fbytez>
"rage quitted" is a presumption anyway. I saw the futility of discussing anything further.
<fbytez>
Which is being proven again, despite providing nothing but black and white, clear, simple facts.
<beneroth>
hahaha
<fbytez>
Hence my comment about abu[m]'s ego, as he seems to be unwilling to accept it.
<beneroth>
what to accept? that he misunderstand you?
<fbytez>
That what he kept telling me about using `(char)` in this way was wrong.
<beneroth>
he already proved himself. your here on his territory. critic and arguing is okay, but in a friendly manner and not passive aggressive bullshiting. behave or leave. thank you.
<fbytez>
Passive aggressive bullshiting? Critc and arguing clearly isn't OK, hence your defensiveness and rudeness towards me.
<beneroth>
learn to communicate your questions better and you get better responses. simple as that.
<fbytez>
I didn't have a question. I was told to do something that doesn't work.
<abu[m]>
My fault was that I was not really interested in your problem, because I found the whole idea nonsense. Sorry for that. But I fully understand how Pil input streams work.
<abu[m]>
So I did not care to dig too deeply into your handling of the termination probably
<fbytez>
Yeah, and so gave me incorrect information.
<abu[m]>
No
<fbytez>
You don't care. Fine.
<beneroth>
why should he care? you don't pay him.
<abu[m]>
Incorrect was the 'input' example
<fbytez>
I didn't say he should.
<fbytez>
You are both so personal and defensive.
<abu[m]>
You send a stream without eof or proper separation and then wonder why it hangs
<fbytez>
Again, you're going down the wrong path.
<abu[m]>
this is all I can say
<beneroth>
yeah its pointless
<abu[m]>
Perhaps, but I don't want to debug your code now
<fbytez>
"You send a stream without eof or proper separation and then wonder why it hangs" -- is what shows you don't understand.
<abu[m]>
I have guests
<fbytez>
I don't need any debugging.
<beneroth>
you need to close the pipe :)
<beneroth>
hihi
<fbytez>
No, it stays open for the response.
<beneroth>
yes, but then you must not use (char) for reading the last byte. you know that know. you learned something and can say thank you for the help.
<fbytez>
No, I wasn't helped.
<beneroth>
still not?
<fbytez>
No, what help do you think I've received by being told the wrong thing?
<abu[m]>
Normal http transactions in Pil work fine, also several ones over a single connection
<fbytez>
Pil doesn't use '(char)' it uses (line).
<beneroth>
what help do you think you get when you don't manage to explain your problem?
<abu[m]>
Is it because you insist to read \r after \n with (char) where a (peek) would suffice?
<fbytez>
The only thing I originally asked was if there were a function like (line) that would accept something like a byte-limit.
<beneroth>
yeah, and on that you got the response: there is (rd 'cnt) but that is for binary, not for text. which lead to the whole topic with (input).
<fbytez>
(peek) wouldn't suffice because then the final character if of course not discarded.