Camelia, the Perl 6 bug

IRC log for #mojo, 2013-01-11

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 Averna joined #mojo
00:07 davehorner joined #mojo
00:11 Molaf__ joined #mojo
00:21 tempire yeah but and looks cooler
00:21 tempire I also like perl -Mojo -E '$_->static->paths(["."]) and $_->start for a' daemon
00:22 * tempire forgets about tap
00:30 rem_lex joined #mojo
00:40 esskar joined #mojo
00:41 Adura joined #mojo
00:58 laouji joined #mojo
01:11 Mike-PerlRecruiter_ joined #mojo
01:11 ka2u joined #mojo
01:14 hlin joined #mojo
01:15 GabrielVieira joined #mojo
01:32 Adura joined #mojo
01:36 mattastrophe joined #mojo
01:43 d4rkie joined #mojo
01:44 d4rkie joined #mojo
01:57 vervain joined #mojo
02:04 memowe_ joined #mojo
02:04 atz__ joined #mojo
02:06 ilbot2 joined #mojo
02:06 Topic for #mojo is now Mojolicious real-time web framework 3.0 ūüĆą http://mojolicio.us ūüĆą http://irclog.perlgeek.de/mojo/today ūüĆą Now with 50% more refracted light!
02:06 noganex_ joined #mojo
02:06 augensalat joined #mojo
02:06 Averna joined #mojo
02:06 tardisx joined #mojo
02:06 t[R]oll joined #mojo
02:06 xxtjaxx joined #mojo
02:09 bc547 joined #mojo
02:09 Grrrr joined #mojo
02:10 jzawodn joined #mojo
02:28 duncanthrax joined #mojo
02:31 egopro joined #mojo
02:31 esskar_ joined #mojo
02:31 esskar__ joined #mojo
02:32 esskar joined #mojo
02:33 Adurah joined #mojo
02:48 xaka joined #mojo
02:48 esskar_ joined #mojo
02:49 esskar__ joined #mojo
03:04 esskar joined #mojo
03:09 egopro joined #mojo
03:15 noganex_ joined #mojo
03:25 _xaka_ joined #mojo
03:26 Adurah_ joined #mojo
03:40 GabrielVieira joined #mojo
04:04 phillipadsmith joined #mojo
04:14 LlamaRider joined #mojo
04:18 LlamaRider Hello. Just upgraded from 3.58 to 3.76 and there's a weird regression that puzzles me in my webapp. Maybe it is simple enough to ask here? Or should I open a GitHub issue?
04:19 rem_lex|pivo joined #mojo
04:23 rem_lex| joined #mojo
04:38 LlamaRider Ended up reporting on the mailing list. *fingers crossed* Good night
04:39 jbnewman joined #mojo
05:03 ka2u joined #mojo
05:33 davehorner joined #mojo
06:25 egopro joined #mojo
06:41 egopro joined #mojo
07:06 dpetrov_ joined #mojo
07:08 Foxcool joined #mojo
07:36 Vandal joined #mojo
07:57 arthas joined #mojo
08:05 ObseLeTe joined #mojo
08:11 dod joined #mojo
08:28 dod joined #mojo
08:53 ver joined #mojo
09:04 D4RK-PH0ENiX joined #mojo
09:31 yakubori joined #mojo
09:47 d4rkie joined #mojo
09:50 Fuzzy joined #mojo
09:54 cosmincx joined #mojo
10:28 ka2u joined #mojo
10:37 dhg joined #mojo
10:39 Foxcool_ joined #mojo
10:40 el_bandido joined #mojo
10:49 ryozi joined #mojo
11:22 yakubori joined #mojo
12:02 yakudza joined #mojo
12:09 marcus hmm oops
12:09 marcus https://groups.google.com/forum/?fromg‚Äčroups=#!topic/mojolicious/LUI8f3Hy0aE
12:14 sri o/
12:15 sri marcus: any test cases yet?
12:29 marcus sri: nop.
12:29 good_news_everyone joined #mojo
12:29 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/5fgG2w
12:29 good_news_everyone mojo/master a7f4185 Sebastian Riedel: fixed localization bug in Mojo::EventEmitter
12:29 good_news_everyone left #mojo
12:30 sri that seems to do it
12:30 sri it's arguable if it really is a bug, but with so many people stumbling over it...
12:35 mire_ joined #mojo
12:37 nicomen localization bug sounded like something with l10n to do ;)
12:39 yakubori localezation? :P
12:40 nicomen hehe
12:40 nicomen locality?
12:40 nicomen actually it's an aliasing bug
12:49 navi joined #mojo
13:06 GabrielVieira joined #mojo
13:06 dod Hello. If I interpret correctly http://tools.ietf.org/html/rfc6455#page-53 I should be able to use session cookies to authenticate a web socket open request. Unfortunately this does not work: looks like Mojo::UserAgent does not provide cookie when opening a websocket. Is there a bug or did I miss something ?
13:11 Mike-PerlRecruiter_ joined #mojo
13:21 bc547 joined #mojo
13:23 yakubori dod: did you take a look at Dumper data on the Mojo::UserAgent?
13:24 yakubori my test application is busted right now, but i'm pretty sure I can check session data on a websocket handler
13:26 nicomen I think this blog post applies here:
13:31 nicomen blah can't find it
13:31 nicomen someone wrote about how sending test cases is better than both bug reports or patches
13:31 nicomen dod: so if you can reproduce in a test case that would help ;)
13:31 good_news_everyone joined #mojo
13:31 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/z4gyMQ
13:31 good_news_everyone mojo/master 8e13768 Sebastian Riedel: fixed WebSocket cookie bug in Mojo::UserAgent
13:31 good_news_everyone left #mojo
13:32 nicomen sri: hehe, I saw that! ;)
13:33 sri this bug is unrelated to what dod said though
13:33 nicomen (I meant the aliasing thingy)
13:33 sri aliasing is the better term in this case
13:37 sri and so much for slower releases... the aliasing fix needs to hit cpan soon
13:39 dhg joined #mojo
13:40 vervain Could 4 make the switch to 4.001?
13:44 Foxcool_ joined #mojo
14:01 jberger joined #mojo
14:01 jbnewman joined #mojo
14:01 jberger tempire, thats a nice one-liner you got there
14:02 jberger still needs a '/' route
14:03 jberger but good to keep in mind :D
14:08 jberger sri: does that patch mean I can set cookies (or really set session keys) via a websocket? as in no-reload logins?
14:12 dod nicomen: sorry, I was distracted by paid work
14:13 dod yes, I'll write a test case using basic http authentication, but not right now
14:18 sri jberger: you can set cookies with the handshake response
14:19 sri but not via websocket
14:19 jberger ok, that was my expectation
14:19 jberger just checking :-)
14:22 * sri still would like to add $self->send({json => {foo => 'bar'}}) but is unsure if it should send a text or binary frame
14:24 sri of course the question of how to receive json messages is also still open
14:24 labrown joined #mojo
14:24 sri jberger: that might actually be an argument for your j() function :D
14:25 sri $self->send({text => j({foo => 'bar'})});
14:25 jberger nice
14:54 ryozi joined #mojo
14:55 good_news_everyone joined #mojo
14:55 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/PrKXcg
14:55 good_news_everyone mojo/master 44dbf65 Sebastian Riedel: added j function to Mojo::JSON
14:55 good_news_everyone left #mojo
14:57 gryphon joined #mojo
14:57 davehorner joined #mojo
15:03 stephan48 joined #mojo
15:03 good_news_everyone joined #mojo
15:03 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/c8CpDg
15:03 good_news_everyone mojo/master 7f0f5b1 Sebastian Riedel: documentation tweaks
15:03 good_news_everyone left #mojo
15:09 stephan48 joined #mojo
15:12 suy joined #mojo
15:14 good_news_everyone joined #mojo
15:14 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/ceYVfg
15:14 good_news_everyone mojo/master fceaa39 Sebastian Riedel: better descriptions for Mojo::JSON methods
15:14 good_news_everyone left #mojo
15:16 Britzel_ joined #mojo
15:17 jberger yay
15:18 good_news_everyone joined #mojo
15:18 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/WKkyRA
15:18 good_news_everyone mojo/master 1d0ab87 Sebastian Riedel: more Mojo::JSON examples
15:18 good_news_everyone left #mojo
15:18 jberger oh and now ojo is beautiful!
15:18 d4rkie joined #mojo
15:18 sri indeed \o/
15:21 jberger sri: I may have asked this before, but I really like the JSON.xs way of doing true/false with \1 and \0
15:22 jberger is there any thought of supporting that?
15:22 sri we support that already
15:22 sri ;p
15:22 jberger really?
15:22 * jberger looks
15:22 kitt_vl joined #mojo
15:22 sri any scalar reference will work actually
15:23 sri not sure if JSON::XS goes that far
15:23 jberger https://github.com/kraih/mojo/blob/44dbf650d0f5c7‚Äčffb96cb7dae55c5de55369ff82/lib/Mojo/JSON.pm#L303
15:24 sri jberger: https://github.com/kraih/mojo/blob/44dbf650d0f5c7‚Äčffb96cb7dae55c5de55369ff82/lib/Mojo/JSON.pm#L291
15:24 sri it's not a number, it's a reference
15:24 jberger oh ok
15:25 sri we check any scalar reference for true/false
15:25 jberger yeah
15:25 jberger don't know how I missed that
15:25 jberger what is all the B:: business later?
15:25 sri checking flags is the value was assigned as a number
15:26 sri s/s/f/
15:26 sri my $foo = 23; vs my $foo = "23";
15:26 jberger oh ok
15:26 sri same way JSON::XS detects it
15:26 jberger well very cool
15:27 jberger I'm glad that mechanism is supported
15:27 sri it's surprisingly reliable
15:27 * jberger thinks I have some code that can be modified
15:27 mattastrophe joined #mojo
15:27 sri i tried to do the same for booleans... but failed miserably https://gist.github.com/3948157
15:29 bluescreen joined #mojo
15:29 jberger you sunk my AEGIS cruiser
15:32 jberger last night at Chicago.pm Peter Rabbitson gave a lightning talk about his pure-perl implementation of Sub::Name
15:32 jberger https://github.com/ribasushi/snpp
15:32 jberger crazy stuff in there!
15:32 sri punch peter rabbitson on the nose from me!
15:33 * jberger ?
15:33 sri he's the one that derailed the subroutine signatures discussion
15:33 jberger IS HE
15:33 jberger shoot
15:34 jberger I need to talk about that with him (in a stern tone)
15:34 sri !
15:34 jberger he doesn't come to Chicago.pm very often
15:34 jberger I'm not sure when I will get my next chance
15:34 jberger (and I need to reread the p5p thread aparently)
15:35 * sri hopes LeoNerd will soon add sub_name to Scalar::Util
15:37 jberger anyway the cool thing was how he found the location of the gv within the cv in a perl-version independent manner
15:37 jberger since that moves all the time
15:37 jberger but now I feel less willing to tout that coolness given recent developments
15:42 sri jberger: http://www.nntp.perl.org/group/perl.‚Äčperl5.porters/2012/10/msg194641.html
15:42 sri he's pretty much anti anything new in core
15:43 sri one of the most destructive forces on p5p these days for sure
15:43 jberger hmmmmmmmmmm
15:44 jberger drat, that was a missed opportunity on my part
15:44 jberger and yes I did read that post back a while ago, but as I still don't know all these people too well, it slipped from my mind who the author was
15:47 jberger I still think adding the new keywords "function" and "method" to the core (lexically scoped by feature.pm) and leaving sub alone lets everyone win
15:47 jberger aaargh!
15:47 sri it wasn't even supposed to be a feature
15:47 sri just an experimental feature in the new experimental system
15:48 jberger sure, yeah, but you know what I mean
15:48 sri absolutely
15:48 jberger he's arguing let Perl stay Perl, and it can, just don't turn that one
15:48 jberger on
15:49 sri in the case of subroutine signatures it's a feature planned since the 90s
15:49 jberger right and one that CPAN modules have hashed out rather thoroughly except for the few things that only core features have to worry about
15:50 jberger like arity and @_
15:50 sri ye
15:50 jberger so bleeeping pick one and do it already!
15:50 jberger ihsapihgpgpdiufdiughsigjs\
15:51 jberger and I still say, with a lack of a compelling argument, behave like sub does and set up @_, now there's no arity problem either
15:51 jberger done
15:51 jberger ship
15:51 jberger welcome to Perl 7
15:52 jberger drat, now how am I supposed to concentrate on $work
15:52 jberger ok, time to get back to it
15:52 jberger :D
16:04 mire_ joined #mojo
16:27 jberger sri: is there any reason where when sending j({ status => <<status>>}) that I would want to send 1 or 0 vs \1 or \0?
16:28 jberger my code seems to work sending the numbers (not true/false) and then in the js testing if ( response.status )
16:28 jberger I fear that I'm viewing javascript from Perl-colored glasses
16:29 jberger why should I use true/false vs 1/0
16:29 sri to be more precise
16:29 sri perhaps the consumer of your service is a language that differentiates
16:30 jberger but if I am the only consumer, then it doesn't matter
16:31 sri if you can guarantee it will only be perl and javascript, i guess it doesn't matter much
16:31 jberger this isn't for a public api, where I can see the difference being important
16:31 jberger just for websocket responses to the web client
16:32 sri a 0 === false check would be false i believe
16:32 jberger like "did the page get added/removed correctly?"
16:33 jberger I will probably change to use \0 when I get to it, as it's more semantically what I mean
16:33 jberger I was just wondering (since I'm learning javascript as I go along)
16:33 jberger thanks for the pointers (and the pointers, hehe)
16:35 * sri should practice javascript more too
16:46 jberger sri: one more thing
16:46 jberger will json_has work on a websocket message test?
16:47 sri no
16:48 jberger is there something like it? so far i have been message_like testing them for elements of the json response
16:48 sri no
16:49 sri it's tricky
16:49 jberger message_json_has ?
16:50 sri i don't think that's a good idea for now
16:50 sri and t would be json_message_has ;p
16:53 el_bandido left #mojo
16:54 sri there are encoding issues
16:54 sri for binary messages we get bytes, and for text messages we get characters
16:55 sri so there can't really be a generic json_message_* api
16:55 sri same problem i mentioned above for ->send
16:57 bpmedley_ joined #mojo
17:05 sri we would have to change the api to make it work
17:06 xaka joined #mojo
17:07 sri like wrapping all messages in an object or adding another argument to the message event
17:07 sri my ($self, $message, $is_binary) = @_
17:12 sri or add more events
17:12 sri like text and binary events that get emitted for their types only
17:13 sri message event would be a subscriber to both i guess
17:14 sri basically frame -> binary/text -> message event chain
17:24 jberger ok
17:25 jberger but now in the meantime, I don't think I can even get the message out?
17:25 jberger at least not via the public api?
17:25 jberger $t->_message gives it to me, but thats naughty
17:27 sri that's true
17:27 sri the blocking websocket test api is a little special
17:27 sri nothing like it in the useragent api
17:28 xaka joined #mojo
17:29 jberger http://pastie.org/5669291
17:30 sri ewww
17:30 jberger thats what I got
17:31 sri i think you might be able to subscribe to the event though
17:32 jberger that sounds promising
17:32 sri $t->tx->on(message => sub { Mojo::IOLoop->stop }); Mojo::IOLoop->start;
17:32 sri it's not pretty either though
17:32 jberger would I have to do that each time?
17:33 sri ye
17:33 jberger or is that something I could setup once?
17:33 jberger drat
17:33 sri help me find a better solution ;p
17:33 jberger ok, proposal: what about something like $t->store_message( \$json )
17:34 jberger its not a test exactly, but it avoids the tap, and it avoids the user api dipping into the non-public one
17:35 jberger it could even be a test in that it could fail if no message was received (though send_ok already does that right?)
17:35 jberger or send_ok could take a second argument for storage? (hmmm I don't like that as much)
17:36 sri send_ok is basically a lie :)
17:36 sri $t->message_ok(\$json) doesn't look good
17:36 jberger then what about ->receive_ok which tests that something is received and can optionally take a scalar reference to store the message
17:37 jberger I don't know how else to get the message out in a chainable way
17:38 jberger ->recieve_ok( sub { ... } )
17:38 jberger ei
17:38 jberger personally I like \$message better
17:38 jberger (I guess it wouldn't be $json if its just the message)
17:38 sri marcus, tempire, crab: CAN HAZ OPINIONZ?!
17:39 tempire jberger: if you're only serving static files, it needs no route
17:39 jberger does mojo know how to handle / to index.html?
17:42 sri ok, different approach
17:42 sri what about $t->message_ok and $t->last_message
17:44 jberger so I cal $t->last_message after the chain (after $t->finish_ok)
17:44 sri no
17:44 sri you interrupt the chain
17:45 sri $t->websocket_ok(...); is $t->message_ok->last_message, '...'; $t->send_ok(...)...
17:45 sri after the chain if you only receive one message
17:45 jberger well send_ok would have to have come first
17:46 sri maybe, maybe not
17:46 jberger you're right, maybe not
17:46 sri websockets are async, everything is possible
17:46 jberger I do
17:46 jberger but thats not everyone
17:46 jberger and I only receive one message
17:46 * jberger needs to think bigger picture
17:47 * sri nods
17:47 jberger so why not have message_ok just return the last message?
17:47 sri hmm
17:48 jberger then you don't need an internal holder either
17:48 sri would be the first test method to do so
17:48 jberger (which is why I was proposing the scalar ref)
17:49 jberger the scalar ref would be optional, so you can keep the chain going and only test that a message was received if you dont care what it says
17:49 sri that would suck for custom descriptions
17:49 * jberger doesn't follow
17:50 sri ->message_ok(\$message, 'JSON message received')->...
17:50 jberger what is so bad about that?
17:50 inokenty joined #mojo
17:51 jberger and since you can test for a scalar reference you can still support ->message_ok( 'JSON message received')
17:51 sri hmmm... would be the first method there with an optional argument before the description
17:51 jberger I think we have established that something weird might happen here
17:51 jberger :-P
17:51 sri ye, i don't like it :/
17:52 jberger would ->last_message work after ->finish_ok?
17:52 jberger probably not right?
17:53 sri i'll start by adding text and binary events to Mojo::Transaction::WebSocket
17:53 sri dunno
17:53 jberger but since its blocking in Test::Mojo, it still isn't pretty right?
17:53 sri it's unrelated to this discussion
17:54 jberger true
17:54 sri but will make json_message_has and friends possible
17:54 jberger but like message_has you can only call them once
17:54 jberger message_like I mean
17:55 sri another problem with message_ok... you don't know if it is text or binary
17:55 jberger you have to know your own response api
17:55 sri it's common to send text messages to javascript
17:56 jberger and thats what's happening to me right now, I'm trying to change from having it send text to having it send json
17:56 sri so you have to reencode your message before you can json decode it
17:56 sri because you would get characters from message_ok
17:56 sri not bytes
17:57 sri (JSON has to be bytes, always... unless you're in javascript)
17:58 * sri wonders if anyone can still follow all the problems :)
17:58 * jberger just wants to get the message out
17:58 jberger I can handle all the other stuff later, but I can't if I can't reliably get the message out
17:59 sri we need a big picture solution though
18:00 jberger the tester should know that (s)he expects text or bytes right?
18:00 sri j(encode 'UTF-8', $t->message_ok) still sucks though
18:01 jberger ok, I got really big picture here
18:01 jberger $t->websocket_ok(...) doesn't return $t, it returns a new Test::Mojo::WebSocket object
18:01 sri false
18:02 jberger now you don't need message on all the methods
18:02 dod joined #mojo
18:02 jberger you could call finish_ok in DESTROY
18:02 sri now you lost me
18:02 jberger and all kind of pretty new methods for handling stuff
18:02 jberger a new test class for testing websockets
18:02 sri oh, a new class
18:02 jberger I said big picture
18:03 jberger the problem is (partially) shoehorning two paradigms into one test class
18:04 jberger you get more flexibility by separating them
18:04 sri i don't see that happening without api breakage
18:04 jberger you can leave the current implementation too if you want
18:04 jberger add websocket_foo_ok
18:04 jberger which does this new stuff
18:05 jberger and leave the old one, possibly deprecated
18:05 dhg joined #mojo
18:05 jberger no, it doesn't have to
18:05 sri actually, i don't see that chaning anything
18:06 sri *+g
18:06 sri problems are still the same
18:06 jberger websocket_ok returns the new object, but it has all the same methods, so thats no api breakage
18:06 jberger it just lets the paradigm shift
18:06 jberger you are worried about how the testing api is compared to the other methods
18:07 jberger so don't compare them
18:07 jberger new test class
18:07 sri even with the new class i will be worried about consistency
18:07 tempire that sounds like the wrong direction
18:07 jberger tempire, I'm not sure I like it much anymore either
18:07 sri passing references into a method to get stuff out is something i dislike in general
18:08 * tempire agrees emphatically
18:08 sri anyway, keep brainstorming, i'll add text/binary events :)
18:08 jberger ok, let me say it a different way, from a different starting point
18:09 jberger its always been a little odd to me that after you call websocket_ok the rest of the api is unavailable until you call finish_ok
18:09 jberger the problem is that the underlying transport/storage/etc has changed
18:10 jberger but if its a new object, you can even have the same names
18:10 jberger $t->websocket_ok( ... )->json_has()
18:11 jberger the user need never care that websocket_ok returned a new test instance of another class, unless (s)he need to
18:11 jberger and no (explicit) need for finish_ok, it can be in the DESTROY on that class
18:13 jberger does that make more sense, at least from a reasoning standpoint, if not implications
18:14 sri i don't disagree, but it's hard to argue about without at least a proof of concept
18:16 asarch joined #mojo
18:20 sri ok, what's better text/binary events or an $is_binary argument for the message event?
18:21 sri i mean text/binary events in addition to the message event
18:22 tsubasa joined #mojo
18:23 sri this is basically what the events would look like http://pastie.org/5669621
18:23 sri alternative is $self->on(message => sub { my ($self, $msg, $is_binary) = @_; })
18:24 dwery1 joined #mojo
18:29 jberger personally I think two events, because you probably know if you are expecting one or the other
18:29 jberger then again, if you are waiting for something and it never happens ...
18:30 jberger die "Got wrong message type" if $is_binary
18:30 sri having added the two events... i kinda get the feeling that the message event becomes useless
18:31 jberger ok, but now what if you expect text, and the service now sends binary
18:31 dod hmm.  The short test I've done shows that session cookies are indeed transmitted while creating a websocket. Even with Mojolicious 2.98
18:31 jberger you just wait forever
18:31 dod I've must have messed up somewhere else in my application
18:31 dod Sorry about the noise
18:32 sri well, your noise made me fix another cookie bug ;)
18:32 dod that's good news :-p
18:42 jberger seriously fast implementation: http://pastie.org/5669728
18:42 jberger sri++ dod++
18:45 jberger but now you add json_has etc in ways that work correctly for a websocket response
18:45 jberger IMO the api stays more consistent
18:45 jberger perhaps you even change the messge_* to content_* ?
18:45 sri that goto is horrible, otherwise not too bad
18:45 jberger yes the goto is horrible
18:46 jberger because I couldn't figure out how many levels to increment the test more thingy
18:46 sri just make a test fail to figure it out :)
18:48 jberger (actually I did the monkey_patch wrong)
18:48 jberger monkey_patch 'Test::Mojo', 'websocket_ok', sub { ...}
18:50 jberger actually, done this way, it can be opt-in
18:50 jberger use Test::Mojo::WebSocket
18:50 jberger and eventually if it should become the norm the Test::Mojo just loads it and the extra use call becomes a no-op
18:52 jberger (the DESTROY could be goto also actually, eeeek)
18:52 sri i'm extremely -1 on this kind of hackery
18:55 yakubori joined #mojo
18:57 jberger sri: the goto? yes me too
18:58 sri also the monkey_patch
18:59 jberger the monkey_patch is the entry point to the whole thing, do you mean you would rather have a different method in Test::Mojo to start this?
18:59 sri i don't want separate implementation at all
18:59 sri it's one or the other
18:59 sri *+s
19:00 jberger ? I thought that was what I was talking about?
19:00 jberger > sri: not bad
19:00 jberger I'm confused?
19:01 sri i don't want to deprecate websocket_ok and i don't want use Test::Mojo::WebSocket to monkey_patch it
19:01 sri anything new should be backwards compatible
19:01 sri without horrible hacks
19:03 jberger but changing the behavior of Test::Mojo::websocket_ok to return an instance of Test::Mojo::WebSocket is ok, or you don't like this line of thinking anymore
19:03 sri i also believe your finish_ok on destroy is flawed
19:03 jberger the monkey patch was just for proof_of_concept
19:04 * sri is still trying to understand the advantages
19:04 sri if you assign the new instance to a variable you have to manually destroy it or you're screwed
19:05 jberger or call finish_ok, just like you would have
19:05 jberger DESTROY was for convenience
19:05 sri yea, but now there are new speacial cases you have to think about
19:05 sri good luck explaining that in documentation
19:05 jberger not really, you would have call that anyway
19:05 jberger fine get rid of the destroy
19:06 jberger of course now if you don't call finish ok in the (unbroken unsaved) chain the object is gone so there's no way to call finish_ok on it
19:07 jberger the advantage is polymorphistic naming
19:08 jberger or calling $ws->messages->[0]
19:08 sri but are those messages text or binary?
19:08 jberger whatever _message returned
19:08 sri yea, that's bad
19:09 jberger its what it is now
19:09 sri yea, it doesn't solve the real problem
19:09 jberger right, now you have Test::Mojo::WebSocket::json_has that fails if it gets text
19:10 jberger and works like you expect if it gets binary
19:11 jberger nm, think on that later
19:12 jberger I have spent more time than I have on this already
19:14 sri i kind of wish the websocket test api didn't exist :(
19:14 sri perhaps i'll just deprecate it for now
19:15 sri it was designed when there was only text frames
19:15 sri text + binary frames ruined it
19:15 tsubasa left #mojo
19:16 sri tempire, marcus, crab: thoughts?
19:19 jberger no wait, I think I know what the disconnect is here
19:20 sh4 joined #mojo
19:20 jberger I don't think I've made it adaquately clear, Test::Mojo::WebSocket is a "subclass" of Test::Mojo
19:20 jberger which reimplements ALL the methods to do what you mean on websocket connections
19:20 jberger expect perhaps _test
19:21 jberger the monkey_patch was just proof of concept
19:21 sri i think i get what you're trying to achieve, but i don't see the real advantage
19:22 sri it's just differently organized, but doesn't solve the real problems we are having
19:22 sri $t->messages does not solve the problems, even though it might look that way
19:23 jberger currently $t->websocket_ok(...)->json_has doesn't make any sense
19:23 sri the whole api is secondary atm, the primary problem is how to fit binary and text differentiation into this
19:23 jberger but it would if the thing that websocket_ok returned new and knows how to deal with it
19:24 jberger you get errors if content_is gets binary and errors if json_has gets text
19:24 sri yea, and that's wrong
19:24 jberger yes its a "new" api, but it looks like the old one
19:24 sri sending json as text frames is ok
19:24 sri javascript often expects it even
19:25 sri you can send json as text *and* binary frames, just as well as everything else
19:25 sri the api has no indicator for that
19:25 sri supporting json is not the problem
19:25 dhg joined #mojo
19:26 sri text/binary events make it easy, supporting raw message access for message_ok is a huge problem
19:26 jberger if its not possible to make it do what you expect, then just leave it as is
19:26 jberger I wish I had never mentioned it
19:27 sri perhaps it is not very clean what text vs binary frames actually means
19:27 sri *clear
19:27 jberger my app always sends its websocket data from JSON.stringify, so hopefully that sends as test
19:28 jberger can you imagine a totally different test api (not the same as Test::Mojo) for websockets?
19:29 jberger and if you can can you imagine a mapping to those names?
19:29 sri text and binary are just flags on the websocket layer, *but* text frames guarantee that their content is UTF-8 encoded, so Mojo::Transaction::WebSocket automatically encodes and decodes everything that passes through it
19:29 sri so for binary frames we get the raw data and for text frames we get perl characters
19:30 jberger it seems to me that it would be rather hard to test the binary data, and easy to test the text
19:30 jberger so don't allow it to test the binary data
19:30 sri easy to test the text? Oo
19:30 jberger its what its already doing
19:32 jberger what about adding some callback to Test::Mojo to handle binary message events
19:32 sri but binary frames get used too
19:33 jberger then I don't know, I'm the wrong person to ask I guess
19:33 sri ideally we would have different apis for testing binary and text messages
19:33 sri s/apis/methods/
19:34 jberger yes, and if those method names mapped nicely to the existing api names ...
19:34 sri it's not an impossible problem, but the message preserving solutions so far (->messages/->last_message) are broken by design
19:34 jberger and if not, you add them in the new namespace and don't have to clutter up Test::Mojo::
19:36 sri if you really really want to preserve something it would have to be frames, not messages
19:36 sri but that's problematic as well
19:37 jberger ok, so last thing before I move on (because I have to)
19:37 sri prolly a pretty bad sign how we've been talking like forever and got nowhere yet :S
19:37 jberger is there any way to know that a full set of json has been sent via a websocket?
19:37 jberger if not, then the whole scheme is screwy
19:38 sri define full set
19:38 jberger from the first { to the last }
19:38 sri marcus, tempire, crab: unless you've got any ideas i tend towards deprecating websocket testing for now
19:39 jberger if you deprecate websocket testing Galileo loses most of its test suite
19:39 sri websocket messages have framing built in
19:39 sri jberger: i'm open for suggestions
19:40 jberger so I can know that a full message has been sent?
19:40 sri but it seems like nobody knows how to address the problems
19:40 sri you don't get incomplete messages
19:41 jberger then why can't there be some test that indicates that I expect to get a json response, then give me that json
19:41 sri i don't follow
19:41 tempire sri: I've never tried to test them, so I have relevant input.
19:41 sri like i said above, supporting json is trivial
19:42 sri the problem is the state keeping stuff (->messages/->last_message)
19:42 jberger when I create a page, the data for the page is sent from the client to the server over websocket, it then sends back json saying whether the insert was successful
19:42 sri json_message_is and friends are already possible with my next commit
19:42 tempire er
19:42 tempire s/have/have no/
19:42 jberger I just want to say message_json_deeply( {success=> \1, message => 'saved' })
19:42 jberger thats all I need
19:43 sri that's something we could do
19:43 jberger ok, now we're getting somewhere
19:43 sri it's dead simple
19:44 jberger message_like worked while it was text and even for text in json, but I couldn't know the hash order
19:44 sri i was talking about ->messages/->last_message the whole time :)
19:44 jberger and I just needed a way to introspect the json
19:44 jberger (I was thinking bigger picture for the Test::Mojo::WebSocket thingy)
19:45 jberger but this is all I need
19:46 jberger http://pastie.org/5669291
19:46 jberger but done like deeply
19:46 jberger (that was my first pastie from hours ago)
19:47 jberger and I do delete on success because I don't know how to make is_deeply work on the truth-y thing
19:47 jberger but internally message_json_deeply could probably handle that
19:51 good_news_everyone joined #mojo
19:51 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/2QYOQA
19:51 good_news_everyone mojo/master a799a9a Sebastian Riedel: added binary and text events to Mojo::Transaction::WebSocket
19:51 good_news_everyone left #mojo
19:51 sri ok, now we have the primitives necessary
19:54 sri jberger: there is one small problem though
19:54 sri _message and everything depending on it will have to change
19:55 jberger its not public api
19:55 sri yea, but it's work ;p
19:55 sri anyway, we have to preserve and check the message type in addition to the message in $self->{messages}
19:56 sri [text => '{...}', binary => '{...}', binary => '...', text => '...']
19:56 sri something like that
19:56 sri then we know which ones are encoded and which ones aren't
19:58 sri my $structure = $json->[0] eq 'text' ? Mojo::JSON->new->decode(encode 'UTF-8', $json->[1]) : Mojo::JSON->new->decode($json->[1]);
19:58 sri json in text messages needs to be reencoded
20:00 sri maybe it's now more clear why ->messages/->last_message/->message_ok(\$json) could never work
20:02 sri [[text => '{...}'], [binary => '{...}'], [binary => '...'], [text => '...']]
20:03 jberger and what about this in the meantime? http://pastie.org/5670129
20:03 sri doesn't work
20:04 sri due to the UTF-8 issue
20:04 jberger sorry better: http://pastie.org/5670131
20:04 jberger hmmmm
20:04 sri as soon as you have unicode characters it breaks
20:05 sri we need to know if they were sent in text or binary messages
20:05 sri add some unicode snowmans or hearts to your test data if you want to see it
20:06 jberger (or just don't send any in the real program, :-P)
20:06 sri ;p
20:06 jberger thats not for public consumption though
20:06 jberger it so happens that it doesn't
20:06 jberger and wont
20:06 jberger (my app wont)
20:07 jberger hmmmmmmmmmmmmmmmmmmmmmmmm
20:07 jberger wait a minute
20:08 jberger but the page data is sent as JSON over websockets to be saved
20:08 jberger poop, thats not going to work is it?
20:11 ObseLeTe joined #mojo
20:13 jberger your snowman sunk my CMS
20:14 sri unicode is hard lets go shopping
20:17 jberger http://pastie.org/5670191
20:17 jberger shopping it is
20:18 sri ok, now i see why we were talking past each other the whole time :)
20:19 sri jberger: ->send_ok( $data ) is very bad, JSON is already utf-8 encoded, so by sending it as a text frame that way you double encode it
20:20 jberger ok well I can fix that, I'm more worried about what's going on in the real logic
20:21 sri however, on the server side, if you receive it with the message event, it might look ok, since just the double encoding has been removed, but the JSON is ok again
20:21 sri now, javascript behaves differently, and you will get different results
20:22 sri ok, i think i'm going to change the text event based on our conversation :)
20:24 jberger the server side looks like this, and I'm going to guess that I hit a bug and thats why the extra decode is there: https://github.com/jberger/Galileo/‚Äčblob/master/lib/Galileo/Edit.pm#L32
20:24 jberger truthfully I don't remember
20:24 sri haha
20:24 sri that's what i'm talking about!
20:24 jberger SHOPPING!
20:25 sri javascript sends normal JSON, encoded with utf-8 once, we receive it server side and decode it, so you get JSON as characters instead of bytes
20:25 sri i think the text event needs to not decode at all and just give you bytes
20:26 sri it's more realistic
20:26 sri if you want to sent unicode text messages verbatim back and forth you can use the message event instead :)
20:27 jberger so now I don't do JSON.stringify either?
20:27 jberger or do I
20:27 * jberger is so lost
20:27 sri the wonderful world of unicode in perl
20:27 jberger at least I have one unified js-side sender function
20:28 sri you don't change anything on the javascript side
20:28 jberger ok
20:28 sri on the perl side you will use the text event in the future i suppose
20:30 jberger and what should I do rather than send_ok
20:30 sri {text => $json}
20:30 sri means send a text frame without encoding it
20:31 jberger ok
20:31 sri it doesn't work yet, after my next commit
20:34 jberger I'm good on this end: https://github.com/jberger/Galileo/commit‚Äč/3132be769121e963037db7e39ded7eb88a167acc
20:35 good_news_everyone joined #mojo
20:35 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/CE6oyA
20:35 good_news_everyone mojo/master 4b0e127 Sebastian Riedel: changed semantics of text event
20:35 good_news_everyone left #mojo
20:35 sri jberger: don't forget use utf8
20:36 jberger Mojo::Base
20:36 sri in the test
20:36 jberger Mojolicious::Lite
20:37 jberger so now my test passed when subscribed to the message event
20:37 sh4|2 joined #mojo
20:38 jberger should I stay with the message event or should I change some things?
20:38 sri there is something going on i don't understand then
20:39 jberger its going through a database too on this round trip
20:39 * jberger ducks
20:44 ka2u joined #mojo
20:46 sri i might have a fix for the websocket tests
20:47 sri ->message_is({text => 'lalala'})->message_like({binary => '...'})
20:50 jberger thats good, but no deeply yet?
20:51 sri first things first
20:51 jberger indeed
20:55 kongelaks if i want to use cookies in Mojo::UserAgent, do i need to do: 1. $ua->cookie_jar->inject($tx) 2. .. build_tx ... 3. $ua->cookie_jar->extract($tx) ?
20:56 kongelaks oops, i wrote that incorrectly
20:57 kongelaks 1. build_tx 2. inject 3. $tx->res 4. extract
20:58 sh4|2 joined #mojo
21:01 alester joined #mojo
21:08 jberger sri: it seems to be working for me using the message event https://github.com/jberger/Galileo/commit‚Äč/c61f2681b02ba8bae4770ec0f18191e409835d1c
21:08 xaka joined #mojo
21:09 jberger I'm on 3.73
21:20 jberger sri: I found the original issue that caused my extra encoding step. I wonder if the addition of utf8 to the templates actually fixed the bug and so now my most recent change works as expected
21:20 jberger either way, now at least I'm doing a little testing using utf8 data
21:30 good_news_everyone joined #mojo
21:30 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/m-Ad2Q
21:30 good_news_everyone mojo/master 1d98aeb Sebastian Riedel: added support for advanced binary WebSocket message tests to Test::Mojo
21:30 good_news_everyone left #mojo
21:30 sri jberger: now the framework for correct utf-8 handling is in place
21:30 sri json tests are trivial from now on if we decide to add them
21:32 jberger sri++
21:34 sri the biggest problem from now on will be deciding a method name ;p
21:34 sri json_message_content_is anyone?
21:35 jberger does it behave like deeply?
21:35 sri like json_content_is
21:35 sri (so yes)
21:36 jberger oh, yeah a name relative to json_content_is would be the way to go
21:36 * jberger sees another bump in the minimum Mojolicious version in Galileo's future
21:46 sh4 joined #mojo
21:57 good_news_everyone joined #mojo
21:57 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/CJXRlQ
21:57 good_news_everyone mojo/master f0e26bd Sebastian Riedel: added json_message_content_is method to Test::Mojo
21:57 good_news_everyone left #mojo
21:58 sri jberger: ^^
21:59 jberger yay!
21:59 jberger sri += 2
22:09 sri \o\
22:09 sri /o/
22:13 jberger and now to test for true/false I use 0 and 1
22:13 jberger it seems by my testing
22:14 jberger true=1 false=0 of course
22:14 bluescreen_ joined #mojo
22:16 sri marcus, tempire, crab: that method name acceptable?
22:17 sri it's a bit long since it's based on json_content_is
22:24 yakubori joined #mojo
22:32 jberger sri: looking at your tests, it looks like it doesn't matter if you send_ok( { binary  => ... }) or send_ok({ text => ... }) now
22:32 jberger they go through different channels, but they work the same? I'm still confused I think
22:33 jberger I will just keep using the text channel
22:33 sri text and binary are different websocket message types
22:35 good_news_everyone joined #mojo
22:35 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/W9DT7A
22:35 good_news_everyone mojo/master ae7e983 Sebastian Riedel: documentation tweaks
22:35 good_news_everyone left #mojo
22:37 jberger yeah, its getting clearer
22:39 jberger ok, I've got it now
22:40 jberger either send({ text => $json }) or send({ binary => $json }) should work (when I'm sending encoded json), but using send($json) wont do what I want
22:40 jberger because send then will encode it for me again
22:41 sri exactly
22:41 jberger BUT I do that interanally a few times, and I think thats why things are working when I'm subscribed to message and not to text
22:41 jberger when that was confusing you
22:42 jberger let me try to patch it all up
22:42 jberger on this end
23:08 tempire hmm
23:09 tempire that method name...
23:22 sri tempire: better ideas?
23:29 yakudza joined #mojo
23:29 sri i suppose ->json_message_is would be more useful anyway
23:30 sri maybe i'll just replace it for now
23:32 BeDa joined #mojo
23:32 davehorner joined #mojo
23:34 jberger sri: my code looks SOOO much better now
23:35 sri $t->json_message_is('/foo' => {bar => [1, 2, 3]});
23:35 sri i'm considering this as a replacement
23:36 sri with the / pointer it has the same functionality
23:36 jberger fine by me
23:36 jberger I'm coding this all in a branch
23:37 tempire I like that better
23:37 jberger would be kinda hard to call it master when it depends on an unreleased mojolicious :-P
23:39 lammel2 joined #mojo
23:39 good_news_everyone joined #mojo
23:39 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/YhzK2w
23:39 good_news_everyone mojo/master 07e197e Sebastian Riedel: replace json_message_content_is with json_message_is
23:39 good_news_everyone left #mojo
23:40 sri it will be released today, need to get the regression fix out
23:44 jberger my tests pass
23:44 sri your weird encoding code actually made me double check browsers :)
23:44 sri but i couldn't find one that double encodes
23:45 jberger just to be sure, let me check the behavior in a running instance
23:45 jberger not impossible that the testing round-trip makes things look right
23:46 BeDa joined #mojo
23:48 jberger hmmm, something is amiss
23:49 good_news_everyone joined #mojo
23:49 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/ZxczFQ
23:49 good_news_everyone mojo/master 3249875 Sebastian Riedel: added unicode test to WebSocket example
23:49 good_news_everyone left #mojo
23:49 sri might as well update the example :)
23:49 sri think i like the text and binary events
23:53 jzawodn joined #mojo
23:54 BeDa joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary