Matthias247 has quit [Read error: Connection reset by peer]
jemc has quit [Quit: WeeChat 1.4]
jemc has joined #ponylang
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #ponylang
jemc has quit [Ping timeout: 268 seconds]
chemist69 has quit [Ping timeout: 256 seconds]
chemist69 has joined #ponylang
jemc has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
gmcabrita has quit [Quit: Connection closed for inactivity]
amclain has quit [Quit: Leaving]
shadow_ has joined #ponylang
shadow_ is now known as Guest89667
obadz has quit [Ping timeout: 246 seconds]
jemc has joined #ponylang
obadz has joined #ponylang
jemc has quit [Client Quit]
jemc has joined #ponylang
chemist69 has quit [Ping timeout: 258 seconds]
chemist69 has joined #ponylang
Guest89667 has quit [Ping timeout: 260 seconds]
_whitelogger has joined #ponylang
shadowfeindx has joined #ponylang
<shadowfeindx>
Err hello?
<jemc>
shadowfeindx: yes, welcome
<shadowfeindx>
Hi
<shadowfeindx>
I can't seem to run ponyc on windows
<shadowfeindx>
Linker error
<shadowfeindx>
WOuld you be able to help me out?
<jemc>
unfortunately, probably not - I'm not one of the team members who has expertise in windows
<shadowfeindx>
Ah, alright then
<jemc>
but there's an off chance that I might be able to recognize an issue we've seen before, if you describe your situation and symptoms
<shadowfeindx>
Ok well
<shadowfeindx>
I just downloaded ponyc from bintray
<shadowfeindx>
And when I tried to compile hello world it says unable to locate Visual Studio 14.0
<shadowfeindx>
And then unable to line: no vcvars
<shadowfeindx>
*link
<shadowfeindx>
But I'm quite sure I have visual studio installed since I'm using it
<shadowfeindx>
As well as the windows 10 sdk and visual syudio 15 build tools
<jemc>
okay, I'm noticing that we just got a PR in about 2 hours ago that says it fixes detection of Visual Build Tools C++ 2015: https://github.com/ponylang/ponyc/pull/1794
<jemc>
looking at the mentioned commit that broke detection, it looks like it was broken just before 0.12.1 was released
<jemc>
can you try downloading 0.12.0 from bintray, and see if that works? (or alternatively, upgrade to visual studio 2017)
<jemc>
this PR that fixes the issue will be merged in the next day or so, and we can get a 0.12.3 release, but for now, doing a slightly older release is your best bet
<shadowfeindx>
I saw that there was a pretty serious windows issue that was fixed in 0.12.2
<shadowfeindx>
Is that going to be an issue?
<jemc>
the only issue you might notice is higher-than-normal CPU usage when you run your program
<jemc>
we'll be sure to get 0.12.3 out soon, so you can have both fixes
<jemc>
but if you're itching to get started tonight, 0.12.0 is probably your best shot
<shadowfeindx>
Will using vs2017 fix the issue? I can upgrade if that would work
<jemc>
theoretically, yes it would
<shadowfeindx>
Anything specific that I need to install with it?
<jemc>
not that I know of (sorry I can't be more helpful than that)
<shadowfeindx>
Alright well I suppose I'll just install the lot of it. Thanks for your help!
_whitelogger has joined #ponylang
graaff has joined #ponylang
obadz has quit [Ping timeout: 256 seconds]
jemc has quit [Ping timeout: 260 seconds]
shadowfeindx has quit [Ping timeout: 260 seconds]
obadz has joined #ponylang
chemist69 has quit [Ping timeout: 240 seconds]
chemist69 has joined #ponylang
gmcabrita has joined #ponylang
Matthias247 has joined #ponylang
Xyliton has joined #ponylang
<Xyliton>
I'm now trying to use .expect in my websocket lib and for some reason some of the payload data is cut. I'm 75% sure that I'm expecting the correct sizes though
<Xyliton>
also, I found the header of one message as part of another one, which shouldn't happen either
aav has joined #ponylang
<SeanTAllen>
there are so many things that could be an issue there Xyliton, that i'm not in a position to help
<SeanTAllen>
you'll need to start debugging your logic and figure out where you've gone wrong
<Xyliton>
oh, okay
<Xyliton>
damn
<SeanTAllen>
that said i can see a problem right off the bat
<SeanTAllen>
or a possible problem
<Xyliton>
yes?
<SeanTAllen>
how much data are you receiving the first time received is called?
<Xyliton>
I'm not sure. It's a HTTP header and I don'T know if it's fixed size or not
<Xyliton>
do I have to .expect that too?
<SeanTAllen>
well you have to deal with that
<SeanTAllen>
right now it appears
<SeanTAllen>
that the first time you get received called you say, "i can throw all this data away, and say expect(2)"
<SeanTAllen>
whats going on with that?
<SeanTAllen>
logically it doesnt make a lot of sense
<SeanTAllen>
whats the intent there?
<SeanTAllen>
i'm not sure what this is supposed to be doing
<SeanTAllen>
```
<SeanTAllen>
if(not _connected) then
<SeanTAllen>
_base_header = true
<SeanTAllen>
_in_header = true
<SeanTAllen>
conn.expect(2)
<SeanTAllen>
_connected = true
<SeanTAllen>
```
<Xyliton>
I only get a http header there, which I don't need. It only tells me that the server accepted my handshake
<Xyliton>
and communicates through the ws protocol now
<SeanTAllen>
thats not what your code is doing
<SeanTAllen>
you could get 1 byte of the header
<SeanTAllen>
not the entire thing
<SeanTAllen>
and then
<Xyliton>
oh
<SeanTAllen>
nothing is going to work after that
<SeanTAllen>
TCP is stream oriented
<SeanTAllen>
not message oriented
<Xyliton>
so I have to .expect the header too
<SeanTAllen>
i dont want to say yes to that
<SeanTAllen>
expect is way to chunk TCP which is stream oriented into messages
<SeanTAllen>
assuming you can know the size ahead of time
<SeanTAllen>
you are saying "i dont know the header size ahead of time"
<SeanTAllen>
so no, expect wouldnt work for htat
<Xyliton>
I'm not sure if I know the size ahead of time
<SeanTAllen>
what you are writing is a state machine
<SeanTAllen>
so your first state is apparently the header
<Xyliton>
I have to check the RFC for that
<SeanTAllen>
or rather the initial header
<SeanTAllen>
you need to deal with that
<SeanTAllen>
remember TCP Is stream oriented not message oriented
<SeanTAllen>
so if a 100 byte message is sent
<SeanTAllen>
you might get it 1 byte at a time
<SeanTAllen>
_connected is a confusing variable name for how you are using it
<SeanTAllen>
you are already connected
<SeanTAllen>
i think what you mean is something like _handshake_completed
<Xyliton>
yea, true
<Xyliton>
I think I got it working now. It "skips" the handshake header and I receive the first frame as expected. But somewhere midway through to receiving other payloads it "breaks", giving me data missing the first few bytes (2-3) from the beginning
Matthias247 has quit [Read error: Connection reset by peer]
<Xyliton>
nevermind. I had messed up some comparision in my code
<Xyliton>
everything is working now!
<Xyliton>
thanks <3
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #ponylang
Xyliton has quit [Ping timeout: 260 seconds]
Xyliton has joined #ponylang
Xyliton has quit [Remote host closed the connection]
chemist69 has quit [Ping timeout: 246 seconds]
<SeanTAllen>
awesome
chemist69 has joined #ponylang
jemc has joined #ponylang
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
staticassert has joined #ponylang
<staticassert>
With the HTTP auth I see "auth: (AmbientAuth val | NetAuth val | TCPAuth val | TCPListenAuth val)" - does that mean it will work with any of these, with TCPListenAuth being the least privileged?
<staticassert>
Also, I remember in a conference talk on pony hearing that the queue implementation is really simple. Where could I find the implementation?
<Xyliton>
is it possible that a behaviour doesn't execute at all?
Xe is now known as dQw4w9WgXcQ
dQw4w9WgXcQ is now known as Xe
vaninwagen has quit [Ping timeout: 240 seconds]
<aav>
is there a reason that F64._inf and F64._nan are private?
Praetonus has joined #ponylang
<Praetonus>
aav: No particular reason. I added these to help fix a few bugs in implementation details and I didn't bother with making an RFC to include them in the public interface
<Praetonus>
I'm not opposed to making these functions public, and I'm not sure if it really requires an RFC or if it should be considered a "principle of least surprise" case. If you'd like to make the functions public, I think you can open an issue on the Github repo or send an email to the dev list to see what folks think about making an RFC for that
<Praetonus>
Xyliton: If you send a message to an actor, it will always execute the associated behaviour after some unbounded amount of time
<Praetonus>
If you generate a lot of messages and the schedulers can't keep up with that, pending messages will accumulate and possibly take a really long time before being processed
Praetonus has quit [Quit: Leaving]
<Xyliton>
I have an actor with a beahaviour being called in a timer. Interestingly, said behaviour isn't called when the timer interval is high (I tested this by having a debug in the timer and the behaviour), but it executes fine when the delay is small
<Xyliton>
this kinda breaks my discord lib because I have to route data from a websocket notify to an actor
mrkishi has joined #ponylang
<SeanTAllen>
Xyliton: the behavior will be called, if it isnt because the timer is high, then the timer hasnt run and fired off the messafe
<Xyliton>
the timer ran though. I checked that by having a Debug in the timer's apply
<Xyliton>
also, the websocket notify receives all the messages, but sometimes it decides that the call to the actor, notifying it of the message, doesn't have to run either
<SeanTAllen>
ive used pony every day for over a year for work Xyliton, ive never seen any indication of messages getting lost