Camelia, the Perl 6 bug

IRC log for #mojo, 2013-05-23

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

All times shown according to UTC.

Time Nick Message
00:37 davido joined #mojo
00:40 * jberger notices that Yanick just released Dancer::Template::Caribou and Dancer2::Template::Caribou
00:40 shmuel joined #mojo
00:48 ask joined #mojo
01:06 whitebook joined #mojo
01:20 ask joined #mojo
01:26 egopro joined #mojo
01:49 russum joined #mojo
01:56 Meiermann joined #mojo
02:00 d4rkie joined #mojo
02:30 abra joined #mojo
02:44 keedi joined #mojo
03:13 tempire sri: regarding perl culture,  I don't think it's anything you have to worry about.
03:13 tempire The solution is to keep making things that people want to use.
03:14 tempire They can grumble all they want, but in the end, they'll adapt.
03:14 tempire Because the alternative is to work harder.
03:21 tempire I'm clearly biased, but Mojolicious and these types of progress are exactly the sort of thing that will keep Perl from dying.
03:21 tempire *projects
03:22 tempire Because they push people to move forward, keeping things fresh.
03:22 tempire I've said it before, and I'll say it again, I would have quit Perl years ago if not for Mojolicious.
03:22 tempire The alternatives were just too old school, and I wanted to move forward.
03:23 * tempire steps off the soap box
03:38 fildon_ joined #mojo
03:39 jberger tempire: hear, hear!
03:40 zivester joined #mojo
03:42 zivester joined #mojo
03:43 zivester joined #mojo
03:50 egopro joined #mojo
03:50 egopro_ joined #mojo
03:55 zivester joined #mojo
03:56 preflex_ joined #mojo
03:59 Kovensky joined #mojo
04:18 xaka joined #mojo
04:22 KindTwo joined #mojo
04:33 keedi joined #mojo
04:58 KindOne joined #mojo
05:15 inokenty joined #mojo
05:26 davido joined #mojo
05:29 denisboyun joined #mojo
05:49 Britzel_ joined #mojo
05:59 dod joined #mojo
06:00 sh4 joined #mojo
06:02 suy joined #mojo
06:08 keedi joined #mojo
06:09 basiliscos joined #mojo
06:14 dod joined #mojo
06:35 Mike-PerlRecruiter_ joined #mojo
06:58 hrupp_ joined #mojo
06:58 KindTwo joined #mojo
07:38 cosmincx joined #mojo
07:42 dod joined #mojo
07:43 kwa sri: I used match->captures in a bridge method to get at the placeholder captures for the called route. stash->{mojo.captures} in a bridge only returned the captures for the bridge controller/action. I needed the calling route captures (e.g. :controller and :id). Using the match->stack atm, which is probably wrong.
07:45 jzawodn joined #mojo
07:47 dod joined #mojo
07:48 abqar joined #mojo
07:50 Vandal joined #mojo
07:55 egopro joined #mojo
07:55 egopro_ joined #mojo
08:12 maxhq joined #mojo
08:13 yakudza joined #mojo
08:21 kwa I've noticed that respond_to doesn't work as expected in bridges. It might be by design, but would appreciate pointers if I've gone awry. I've simulated the error in a Lite app: http://pastebin.com/CzqZGNYt
08:29 reneeb joined #mojo
08:30 Kovensky joined #mojo
08:34 inokenty1 joined #mojo
08:44 fhelmber_ joined #mojo
08:45 dpetrov_ joined #mojo
09:15 nelio joined #mojo
09:32 mrphilov joined #mojo
09:34 Vandal joined #mojo
09:47 KindOne joined #mojo
10:17 mugenken joined #mojo
10:19 mugenken joined #mojo
10:23 maxhq joined #mojo
10:40 KindTwo joined #mojo
10:47 ilbot2 joined #mojo
10:47 Topic for #mojo is now 🎩, indubitably | http://mojolicio.us | http://irclog.perlgeek.de/mojo/today
11:04 bc547 joined #mojo
11:14 whitebook joined #mojo
11:24 nic Mojolicious v4, now with even faster installation
11:31 mire_ joined #mojo
11:47 KindTwo joined #mojo
11:55 whitebook joined #mojo
12:05 KindTwo joined #mojo
12:16 abra joined #mojo
12:17 mire_ joined #mojo
12:25 moltar joined #mojo
12:29 Kovensky joined #mojo
12:39 mire_ joined #mojo
12:48 asarch joined #mojo
13:06 bluescreen joined #mojo
13:07 zivester joined #mojo
13:10 mire_ joined #mojo
13:20 kwa I have an authorization plugin, which builds a response using respond_to if the user doesn't have permission to a resource. How can I detach/finish the request cycle inside the plugin?
14:02 wruppert joined #mojo
14:04 dotan joined #mojo
14:09 dod joined #mojo
14:11 laouji joined #mojo
14:11 sh4 joined #mojo
14:18 r0b3rt joined #mojo
14:21 whitebook joined #mojo
14:22 dod1 joined #mojo
14:27 bluescreen joined #mojo
14:27 cosmincx joined #mojo
14:30 Kovensky joined #mojo
14:41 sri server side SNI is a feature i'd like to see in 4.x
14:42 sri it's pretty simple actually, biggest problem is to find a way to configure it
14:42 sh4 joined #mojo
14:43 sri similar to "-l https://*:443?key=...&cert=..."
14:44 sri was considering "-l https://*:443?mojolicio.us-ke​y=...&mojolicio.us-cert=..." or something like that
14:45 sri all you have to do basically is connect a bunch of key/cert files with domains
14:53 Vandal joined #mojo
14:53 marcus sri: "With this in mind, it's worth noting that kraih is more of a whiner."
14:53 Vandal joined #mojo
14:53 sri -.-
14:54 Vandal joined #mojo
14:54 marcus "Since Marcus's most active time is around 3pm, I would conclude that Marcus works best in the mid-afternoon." <- clearly, this is when I'm most distracted from paying work.
14:57 * sri just had a little websocket discussion over in #catalyst and wonders if we should have better support for protocol negotiation
15:01 sri new WebSocket('ws://...', ['protocol1', 'protocol2', 'protocol3']);
15:01 sri the js api
15:02 sri my $proto = $self->req->websocket_protocols(qw/protocol1 protocol3/);
15:02 sri something like that could work for negotiation
15:02 sri (on the server side)
15:03 sri the example would negotiate protocol1 btw
15:04 sri Mojo::UserAgent api is easier, $ua->websocket('ws://...' => [qw/protocol1 protocol2 protocol3/] => sub {...})
15:06 sri just the server side api that's unclear basically
15:06 sri jberger: i suppose you might be the one most interested in this :)
15:06 bjoernfan joined #mojo
15:07 sri not sure yet protocol negotiation is a thing yet though
15:07 sri having multiple endpoints is almost easier
15:08 jberger what are these protocols? is there something I can read?
15:08 sri they are arbitrary strings
15:08 sri you define them
15:09 kwa sri: (Sorry to disturb your websocket brain dump, but did you see my pastebin above? Is it a bug with respond_to within bridges, or by design?)
15:09 sri new WebSocket('ws://...', ['jberger-sync/1.0', 'whatever', ['whatever/0.9']]);
15:10 sri kwa: not looked very closely, but prolly by design
15:10 sri oops, s/[]//
15:11 sri jberger: basically the same as content negotiation with mime types
15:11 d4rkie joined #mojo
15:12 jberger oh I see
15:12 sri on the wire... protocols are just a header http://mojolicio.us/perldoc/Mojo​/Headers#sec_websocket_protocol
15:12 jberger essentially, because websockets generally intend that people will build protocols on top of them, this is a marker of what to expect
15:12 kwa sri: I can get respond_to to work correctly with the hack -- $self->stash(format => $self->match->stack->[1]->{format}) if $self->match->stack->[1]->{format}; -- within the bridge's method. I thought because I could do that it might be a bug. If it's by design then fair enough.
15:13 jberger I think this is especially useful for say json over websocket
15:13 whitebook joined #mojo
15:14 jberger remember we didn't know how to deal with it, so currently the json decoding tries on every message IFF there is a subscriber to the json event
15:14 rihegher joined #mojo
15:14 jberger this could be a way to indicate that a json message is arriving
15:14 rihegher left #mojo
15:15 sri it's whatever you make of it
15:15 sri the question is if and how mojolicious should use it
15:16 jberger right and I'm saying that that is one way we might choose to make use of it
15:16 sri hehe, we could actually hack respond_to to work differently for websockets
15:16 jberger incoming messages marked with a 'json' protocol would be decoded and trigger a json event, rather than the current behavior
15:17 sri $self->respond_to('jberger-sync/1.0' => sub {...}, any => sub {...});
15:17 sri jberger: it's per connection, not per message
15:17 jberger oh, hmmm
15:17 jberger well, that still might be acceptable
15:17 jberger "this connection may emit json messages"
15:18 jberger but yeah, its less nice
15:18 sri the point is, you define the protocol
15:18 jberger right
15:18 sri it's not random messages, it's jberger-sync/1.0 messages
15:18 jberger in which case perhaps the respond_to type handler is a good first-start
15:19 jberger indeed, galileo-send has such a protocol
15:20 jberger I basically intended that it would be endpoint enforced, but this would work too
15:20 jberger though I still think I would use it with a defined endpoint
15:21 jberger so then respond_to callbacks would be event handlers?
15:22 jberger and how does this spec propose to deal with a list of protocols? its confusing. how does the server know which type of message is arriving?
15:22 jberger unless all of the enabled protocols should be interoperable by design, which sounds like a mess and a half
15:23 lammel2 joined #mojo
15:37 sri jberger: it's exaclty the same as content negotiation
15:42 kwa I have an authorization plugin, which builds a response using respond_to if the user doesn't have permission to a resource. How can I detach/finish the request cycle inside the plugin? Checked the docs but can't seem to find anything.
15:44 lammel2 you mean something like $self->rendered?
15:45 lammel2 it's not ending the cycle but ensuring that no delayed rendering is assumed
15:45 lammel2 Mojolicous::Plugin::BasicAuth is using this if I remember that correctly
15:46 davido joined #mojo
15:47 kwa lammel2: Yeah something like that. I want the request cycle to stop, and whatever has been set in respond_to should be displayed.
15:47 kwa I'll have a look at that plugin, thanks.
15:56 mrphilov joined #mojo
16:02 delias joined #mojo
16:08 good_news_everyone joined #mojo
16:08 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/1vwWOA
16:08 good_news_everyone mojo/master c8ddc63 Sebastian Riedel: added WebSocket protocol support to Mojo::UserAgent::Transactor
16:08 good_news_everyone left #mojo
16:09 sri well, we can do that part at least
16:09 sri server side will take more time
16:16 kbenson joined #mojo
16:17 kbenson Has anyone attempted making a plugin that makes certain files available by default like /js/jquery.js is?
16:18 good_news_everyone joined #mojo
16:18 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/y7atSg
16:18 good_news_everyone mojo/master f6e43bd Sebastian Riedel: test tweaks
16:18 good_news_everyone left #mojo
16:18 russum left #mojo
16:19 sri kbenson: there's even a recipe for that http://mojolicio.us/perldoc/Mojolicious/Gui​des/Rendering#Bundling_assets_with_plugins
16:19 kbenson Sheesh, and I spent while last night googling...  thanks
16:21 sh4 joined #mojo
16:38 jberger kbenson, I have made Mojolicious::Plugin::Humane which provides humane.js
16:38 jberger if its any inspiration
16:46 basiliscos joined #mojo
17:01 good_news_everyone joined #mojo
17:01 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/lZIK3g
17:01 good_news_everyone mojo/master 6163118 Sebastian Riedel: use version in subprotocol examples
17:01 good_news_everyone left #mojo
17:31 good_news_everyone joined #mojo
17:31 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/CATMrg
17:31 good_news_everyone mojo/master 7718f7b Sebastian Riedel: documentation tweaks
17:31 good_news_everyone left #mojo
17:45 kbenson jberger: thanks, but the recipe is really simple.  I did see your module when looking through plugins last night for a different purpose, but it didn't occur to me that it was providing a default humane.js at the time.
18:16 ynonp joined #mojo
18:25 sri hmm
18:26 sri in addition to a server side api we also need something for the user agent to check the result of the protocol negotiation
18:26 sri so at least two methods
18:27 sri $tx->res->headers->sec_websocket_protocol eq 'v1.proto' is not exactly convenient
18:31 Kovensky joined #mojo
18:35 Mike-PerlRecruiter_ joined #mojo
18:38 jmaister joined #mojo
18:39 alester joined #mojo
18:42 mrphilov joined #mojo
18:57 nelio joined #mojo
19:19 denisboyun joined #mojo
19:28 dpetrov_ joined #mojo
19:31 yakudza joined #mojo
19:36 sri App::cpanchanges is neat
19:38 reneeb_ joined #mojo
19:53 davido joined #mojo
19:54 sri hmm
19:55 sri perhaps something like my $proto = $tx->negotiate_protocol('v1.foo', 'v1.bar'); my $proto = $tx->negotiated_protocol;
19:55 sri first for server, second for client
19:57 sri or return unless $tx->negotiated_protocol('v1.foo');
20:02 denisboyun_ joined #mojo
20:04 sri could also be a single method i suppose... since we know if we are on the client or server side from $tx->masked
20:04 sri my $proto = $tx->subprotocols('v1.foo', 'v2.foo'); and it would just do the right thing
20:05 sri on the server side it would set the response Sec-WebSocket-Protocol header, on the client side it would check if one of the listed protocols is the selected one
20:09 sri perhaps in combination with a $t->websocket_subprotocol_is('v1.foo') test
20:29 denisboyun_ joined #mojo
20:38 fhelmber_ joined #mojo
20:42 inokenty joined #mojo
20:48 good_news_everyone joined #mojo
20:48 good_news_everyone [mojo] kraih created subprotocol_negotiation (+1 new commit): http://git.io/2-vd2A
20:48 good_news_everyone mojo/subprotocol_negotiation af89e25 Sebastian Riedel: added basic WebSocket subprotocol negotiation support
20:48 good_news_everyone left #mojo
20:49 sri jberger, tempire, marcus, crab: review!
20:49 sri it's pretty basic
20:50 travis-ci joined #mojo
20:50 travis-ci [travis-ci] kraih/mojo#704 (subprotocol_negotiation - af89e25 : Sebastian Riedel): The build passed.
20:50 travis-ci [travis-ci] Change view : https://github.com/kraih/mojo/commit/af89e254adbb
20:50 travis-ci [travis-ci] Build details : http://travis-ci.org/kraih/mojo/builds/7441110
20:50 travis-ci left #mojo
20:54 marcus I don't understand when I'd use it.
20:56 marcus The actual problems I have with web sockets is that they seem to stop working sometimes, and things like changeConversation conversation_1:00:23mojo misc.js:143 WebSocket connection to 'wss://wirc.pl/socket' failed: WebSocket is closed before the connection is established.
20:57 sri subprotocols are for versioning your application protocol for example
20:57 sri v1.marcus.chat.nordaaker.com
20:57 sri v2.marcus.chat.nordaaker.com
20:58 sri and handling them with the same /chat endpoint
20:59 marcus mkay
20:59 marcus I think I'd just use a different endpoint. Less messy
20:59 marcus and a different controller
21:00 marcus but I'm sure someone will find this useful.
21:00 * marcus & # bedtime
21:00 sri you could also just not use content negotiation
21:00 sri and use different endpoints
21:01 sri /marcus.html /marcus.json /marcus.txt
21:02 sri or rather /marcus_html /marcus_json /marcus_txt
21:02 marcus changeConversation conversation_1:00:23mojo misc.js:143 WebSocket connection to 'wss://wirc.pl/socket' failed: WebSocket is closed before the connection is established.
21:02 marcus oops
21:02 marcus sri: The reason I'd like to keep a different api version in a different controller is that I can easily remove it when all the old clients are gone.
21:04 sri versioning is just one use case
21:05 sri there are standard subprotocol specs in the works
21:06 sri like for xmpp over websockets
21:07 sri well, perhaps i'm wrong and it's not a useful feature yet
21:09 sri support for requesting a subprotocol on the client side stays though, so we can interact easily with web services that do protocol negotiation
21:16 sri another use for subprotocols would be targeting specific browser features
21:17 sri like specific compression apis being present
21:18 sri check for presence, negotiate a slightly more optimized version of the application protocol
21:24 good_news_everyone joined #mojo
21:24 good_news_everyone [mojo] kraih tagged v4.04 at 93fe45c: http://git.io/ne_xkQ
21:24 good_news_everyone left #mojo
21:36 lukep joined #mojo
21:43 perlite_ joined #mojo
21:57 sri hehe, whoever maintains the V8 changelog is just as OCD as me :) https://github.com/v8/v8/blob/master/ChangeLog#L3
22:06 denisboyun_ joined #mojo
22:16 jnbek joined #mojo
22:29 Averna joined #mojo
23:00 rem_lex|pivo joined #mojo
23:14 delias joined #mojo
23:14 whitebook joined #mojo
23:21 freman joined #mojo
23:21 freman Greetings, I'm once again doing things you never intended me to do to Mojo.
23:23 freman I'd really like to borrow the EPRenderer (and probably Mojolicious::Renderer) outside of the entirety of a mojolicious app (it's for generating pre-rendered static content) but I can't work out how to do it...
23:24 freman I'm seeing a lot of interdependancy so I'm beginning to think I can't
23:26 sri they are no longer meant to be usable independently
23:27 sri many of the performance gains recently has been through tighter coupling of components
23:28 freman I can appreciate that. I've even tried use Mojlicious::Lite; Mojolicious::Controller->new(app => app)->render('index');
23:28 freman but that's not outputting to stdout
23:31 Kovensky joined #mojo
23:33 freman ah, $output = app->renderer->render(Mojol​icious::Controller->new(), {template=>'index'});

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