<jemc>
I see - can you open a PR to remove that? It's one of sylvan's personal repos so I can't merge your PR directly, but I can try to convince him if necessary that the syntax plugin shouldn't be overriding users' preferred tab settings
<M4GNV5>
alright, next problem: linking a problem fails for me on both the git version and 0.11 from the deb files. I'm on Debian 9 stretch with Linux 4.9 and GNU ld 2.28. Heres the output: https://i.m4gnus.de/2ddoor.txt
<M4GNV5>
s/a problem/a hello world
<M4GNV5>
s/heres/here is
<SeanTAllen>
there's a note for that in the README M4GNV5
<SeanTAllen>
its in the Arch section at the moment
<SeanTAllen>
probably not the best place
<SeanTAllen>
pass --pic to ponyc
<jemc>
right - ideally, you wouldn't have to do that, but currently you do
<jemc>
(on some platforms)
<jemc>
if you build ponyc from source on you own machine, you wouldn't have that problem (I believe... SeanTAllen's been following this more closely than I have)
<M4GNV5>
on all broken ones like amd64 that have 4 byte relocations even though its a 8byte cpu i assume? ^^
<M4GNV5>
alright thanks
<M4GNV5>
i did build it from source actually
<M4GNV5>
the git version only reported the problem for my code, not the stdlib
<M4GNV5>
kinda strange
<jemc>
oh, odd...
<SeanTAllen>
the Makefile for ponyc will build libponyrt-pic and link that on linux
<SeanTAllen>
that would be why
<SeanTAllen>
perhaps, we should default to --pic as being on for any ponyc built on linux.
<SeanTAllen>
then it wouldnt have to be passed by the user
<SeanTAllen>
otoh, ive not had this issue when i build on linux and then build my code
<SeanTAllen>
so...
<SeanTAllen>
hmmm
<SeanTAllen>
how about you jemc? i assume you aren't having to do ponyc --pic every time.
<jemc>
sorry folks - that was some unintentional keyboard action, there
<jemc>
note to self - change windows before carrying the laptop between rooms
amclain has joined #ponylang
<SeanTAllen>
ha
<SeanTAllen>
normally when that happens to me, its a cat or a dog
<SeanTAllen>
i was screen sharing just now doing a presentation and the dog tried to climb on me and stepped on the itunes control on my apple headphones and itunes opened during the presentation
<jemc>
:D
chemist69 has quit [Ping timeout: 240 seconds]
chemist69 has joined #ponylang
graaff has quit [Quit: Leaving]
Xyliton has joined #ponylang
<Xyliton>
it appears that calling Reader.block(some_size) is "breaking" when calling it with a large number. Any fix for this?
<SeanTAllen>
Can you clarify "breaking" Xyliton?
<Xyliton>
It either locks, or raises an exception. I'm not sure because it's happening inside a try block
<Xyliton>
it just won't execute code after the .block call in some cases
<SeanTAllen>
That not really anything I can say about that. Its very vague and lacking in context.
<SeanTAllen>
What does "locks" look like exactly?
<SeanTAllen>
What is a "large number"?
<SeanTAllen>
In order to be able to say much of anything, would need a simple reproduceable example that could be played around with.
<SeanTAllen>
Reader.block copies memory, doesn't do much more.
<jemc>
Xyliton: raising an error when the requested number of bytes aren't yet in the buffer
<jemc>
is expected behaviour
<jemc>
the docstring could probably be clearer about this, but I think it was assumed to be obvious
<jemc>
if that's what you're referring to, then its expected behaviour
<jemc>
in other words, it can't give you a 100-byte block if there are only 90 bytes in the buffer, so it raises an error
<jemc>
indicating that you need to try again later after more bytes have come into the buffer
<Xyliton>
it's extracting the size of the packet as expected (270069890573023778) and I'm not sure why received would give me some unfinished data
<Xyliton>
so I would have to put into into some semi-infinite while loop which breaks once it successfully extracted the data?
<jemc>
for whatever it's worth, looking at your code, you should consider refactoring to not have such a large `try` block - that's probably part of what's making it difficult to figure out what's going on
<jemc>
possible errors should be isolated to as small an area as possible, and explicitly handled in some way
<SeanTAllen>
@Xyliton are you using expect to control the flow of data into the received method?
<jemc>
> it's extracting the size of the packet as expected (270069890573023778) and I'm not sure why received would give me some unfinished data
<jemc>
you shouldn't expect to get all 270069890573023778 bytes in the same `received` request
<Xyliton>
oh, sorry for the bad wording. that's just the size the websocket header contains
<SeanTAllen>
jemc i meant using "expect" the call on socket
<Xyliton>
I'm never calling expect AFAIK, unless I'm calling it with 0 as argument
<SeanTAllen>
Xyliton: if i said to you that TCP is stream oriented rather than message oriented, would that make sense to you?
<SeanTAllen>
right
<SeanTAllen>
ok
<SeanTAllen>
so i can explain what is happening to you
<jemc>
in general, you should assume that the received bytes will be in sequential chunks of arbitrary unknown length, unless you're using the `expect` API that SeanTAllen mentions
<SeanTAllen>
i just want to get a bit of background
<SeanTAllen>
so, TCP is stream oriented, does that make sense and do you understand the implications?
<Xyliton>
I do
<SeanTAllen>
ok
<SeanTAllen>
right
<SeanTAllen>
so
<SeanTAllen>
if i send you 100 bytes
<Xyliton>
but I'm not really sure how I should implement "packet-oriented" stuff through tcp then
<SeanTAllen>
you might only get the first 20
<SeanTAllen>
then you get 80 a moment later
<SeanTAllen>
at received
<SeanTAllen>
you will get
<SeanTAllen>
received called with 20
<SeanTAllen>
then with 80
<Xyliton>
will they be in order, at least?
<SeanTAllen>
yes
<SeanTAllen>
if you want to only have received called when you get 100
<SeanTAllen>
then you can call
<SeanTAllen>
expect(100)
<Xyliton>
ohh
<SeanTAllen>
and the tcp connection wont call received until there are 100 bytes ready
<Xyliton>
so I could make it expect 2 bytes, extract the data from this header (the ws frame header is 2 bytes, most of the time) and from there on expect the exact payload size?
<SeanTAllen>
yes
<Xyliton>
ohhh
<SeanTAllen>
we do this all the time
<SeanTAllen>
with our framed protocols
<SeanTAllen>
in your "accept" body
<SeanTAllen>
set the initial expect to whatever you protocol header size is
<SeanTAllen>
you wont have received called until get you the header
<SeanTAllen>
and you will get only the header in that received call
<SeanTAllen>
you can take your 2 bytes apart
<SeanTAllen>
get the size from that
<SeanTAllen>
then call expect(payload_size)
<Xyliton>
makes sense
<SeanTAllen>
and set a flag like "no longer in header"
<jemc>
Xyliton: note that using `expect` isn't 100% necessary - if you don't use it, you can always buffer in your notify object, and only process the packet as a packet once you've finally received all the bytes
<SeanTAllen>
do you want me to gist an example from our codebase?
<jemc>
pony-zmq was written before we had the `expect` API, so I used this strategy
<Xyliton>
what if the header can have different sizes?
<SeanTAllen>
ah
<SeanTAllen>
well
<SeanTAllen>
that's a problem
<SeanTAllen>
and you can't use expect
<SeanTAllen>
you'd need to handle the buffering yourself
<Xyliton>
like 2's the minimum, but if the second byte is a specific byte, it will receive another 4 bytes indicating the payload length?
<Xyliton>
could I just add more flags and another expect?
<SeanTAllen>
yes
<SeanTAllen>
all expect does is control how many bytes are in the next call to received
Xyliton has quit [Remote host closed the connection]
staticassert has quit [Quit: Page closed]
Matthias247 has joined #ponylang
aav has quit [Ping timeout: 240 seconds]
_andre has quit [Quit: leaving]
kr1shnak has joined #ponylang
chemist69 has quit [Ping timeout: 258 seconds]
gmcabrita has quit [Quit: Connection closed for inactivity]