The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2014-09-10

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

All times shown according to UTC.

Time Nick Message
00:24 d4rkie joined #mojo
00:46 woz joined #mojo
00:48 d4rkie joined #mojo
00:50 good_news_everyon joined #mojo
00:50 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/O2n4cA
00:50 good_news_everyon mojo/master 04b1268 Sebastian Riedel: link to tx attribute
00:50 good_news_everyon left #mojo
00:52 sri i still wonder if render_exception and render_not_found should be helpers, so they can be easily redefined for the entire app
01:07 klapperl joined #mojo
01:22 jberger sri: did you take a look at Nei's question from this morning
01:23 sri no
01:23 jberger Other than subscribing to the reactor, i couldn't figure out out
01:23 jberger Now I'm curious for the answer
01:25 sri wonder if something like this would make sense in the SUPPORT sections "While not one of our official support channels, your question may already have been answered on L<Stack Overflow|http://stackoverflow.com/questions/tagged/mojolicious>."
01:26 sri or if that just means we wold have to link to all possible answer sites...
01:26 sri jberger: unless you link to it, i will prolly not look it up
01:37 Averna joined #mojo
01:39 Eke- joined #mojo
01:47 woz joined #mojo
01:49 genio sri: on the github mojo wiki, for the minor edits to fix typos and stuff, do you mind that I just go ahead and do it? (should have asked before fixing a few things on the Using-mongodb page)
01:55 jberger genio: on the wiki, have at it
01:57 jberger The honest truth is, i really never look at the wiki and i doubt many of the other core devs do either
02:17 sujithm joined #mojo
02:49 woz joined #mojo
02:49 mattastrophe joined #mojo
02:53 noganex_ joined #mojo
03:04 sujithm_ joined #mojo
03:06 basic6 joined #mojo
03:34 sh4 joined #mojo
03:38 jamesaxl joined #mojo
03:46 r0b3rt left #mojo
03:48 ua_ joined #mojo
03:50 woz joined #mojo
03:55 irq joined #mojo
04:09 Guest joined #mojo
04:43 KCL_ joined #mojo
04:52 woz joined #mojo
04:54 doby joined #mojo
05:05 Guest joined #mojo
05:46 mr-foobar joined #mojo
05:49 Eke- joined #mojo
05:51 batman sri: turning them into helpers sounds like a great idea!
05:51 batman I've often wanted to make my own render_exception()
05:52 batman I often end up with render_500() or something instead :/
05:54 woz joined #mojo
05:56 dabudabu_ http://toroid.org/ams/etc/mojo-testing-exceptions <-- I use this to make my own render_exception
06:03 sujithm joined #mojo
06:24 sujithm_ joined #mojo
06:29 sujithm joined #mojo
06:31 Wim joined #mojo
06:33 dod joined #mojo
06:37 Vandal joined #mojo
06:39 sujithm_ joined #mojo
06:42 KCL joined #mojo
06:43 d4rkie joined #mojo
06:44 doby joined #mojo
06:46 Eke|| joined #mojo
06:48 basiliscos joined #mojo
06:52 mattastrophe joined #mojo
06:53 sujithm joined #mojo
06:58 woz joined #mojo
07:02 rawler joined #mojo
07:14 sujithm joined #mojo
07:32 trone joined #mojo
07:34 marcus sri: it was rather underwhelming.
07:51 Dandre joined #mojo
07:54 irq joined #mojo
07:59 woz joined #mojo
08:04 bodgix_wrk joined #mojo
08:10 preaction joined #mojo
08:20 denis_boyun joined #mojo
09:00 woz joined #mojo
09:02 edestler joined #mojo
09:08 sujithm joined #mojo
09:16 basiliscos joined #mojo
09:22 Wim joined #mojo
10:00 fhelmber_ joined #mojo
10:02 woz joined #mojo
10:03 ver joined #mojo
10:25 fhelmber_ joined #mojo
10:29 da5id joined #mojo
11:03 woz joined #mojo
11:31 sujithm joined #mojo
11:32 d4rkie joined #mojo
11:32 mojobot19465 joined #mojo
11:34 mojobot19479 joined #mojo
11:39 carneirao joined #mojo
11:42 neilhwatson joined #mojo
11:57 aleksey joined #mojo
12:00 lipizzan joined #mojo
12:04 woz joined #mojo
12:06 rawler joined #mojo
12:14 dp_ joined #mojo
12:25 mishantil Oslo just is not the same without a #mojoconf
12:35 carneirao left #mojo
12:37 cpan_mojo MojoX-JSON-RPC-Service-AutoRegister 0.001 by MUDLER - http://metacpan.org/release/MUDLER/MojoX-JSON-RPC-Service-AutoRegister-0.001
12:43 sri rofl, and now apple might buy Path... they've lost it
12:45 mishantil sri: Well, they did after all loose the entire core of Apple a little while back.
13:01 good_news_everyon joined #mojo
13:01 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/Zw5Tqg
13:01 good_news_everyon mojo/master 7ff69de Sebastian Riedel: use a little less code
13:01 good_news_everyon left #mojo
13:05 woz joined #mojo
13:06 Nei sri the question was how to catch exception in on(json, or potentially other places that are caught by mojo eval, see example code on http://paste.scsys.co.uk/422288 from a place higher up in the chain (i.e. without eval in the on)
13:33 aleksey joined #mojo
13:38 aleksey joined #mojo
13:41 sri Nei: dunno
13:41 sri use try/catch
13:42 Nei ->on(error doesn't work, ->catch doesn't work
13:43 Nei at least jberger couldn't figure it out either
13:43 sri which error event are you subscribing to?
13:44 Nei I tried $client and $client->tx, chances are I need to target another place?
13:44 sri umm, you randomly subscribed without checking?
13:45 sri where the hell did you get the idea?
13:47 Nei that's put lightly ;) I read the docs and found them to indicate that, a transaction is a eventemitter so it can emit errors
13:47 Nei however, it doesn't emit an error for this "error" (unhandled exception in the handler)
13:48 good_news_everyon joined #mojo
13:48 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/MN00YA
13:48 good_news_everyon mojo/master d2bbee2 Sebastian Riedel: more precise description for error event
13:48 good_news_everyon left #mojo
13:48 Nei maybe I read the docs wrong, maybe you just improved the docs a little bit
13:49 Nei still I find them leave me pretty clueless as to where I might be able to "catch" this error
13:49 sri how do you catch errors everywhere else?
13:50 moritz with an eval { }. But that only works when I call the code myself
13:50 Nei depending on which part of the program, if it is in the main part the program might just crash
13:50 Nei however mojo event handlers are run (by mojo) in an eval
13:50 moritz a framework calls code for me, so it should also make it easy to catch errors for me
13:50 Nei so they only show up in my debug log and the app continues running
13:50 sri Nei: where did you read that?
13:51 Nei that's the fact I am observing from my very simple, I would think, example code
13:52 Nei app doesn't crash. it's like java's try {}catchall{resume}
13:52 sri moritz: you're welcome to make a proposal
13:52 cpan_mojo Mandel 0.21 by Jan Henning Thorsen - http://metacpan.org/release/JHTHORSEN/Mandel-0.21 (depends on Mojolicious)
13:54 moritz sri: my proposal is to to have an on_callback_error or so that's triggered by exceptions from my callbacks
13:54 Nei for some cases I'd rather it crashed instead of silently resuming. otherwise it would be helpful to know which parts are protected from where with an eval, or which code constructions will require me to handle exceptions and tear down the app
13:54 sri moritz: in patch form please
13:54 moritz sri: and if no such handler is present, the default one dies
13:55 Nei but I couldn't find this information in the doc. maybe I missed it then I would also be glad for pointer where to read it up
13:55 sri well, you two figure it out please
13:55 sri moritz's proposal seems counter to your assumptions so far though
13:56 Nei what?
13:57 Nei if moritz' proposal is that, a proposal, then that means  there is currently no way to what I'm asking, right
13:59 * moritz doesn't know Mojolicious/Mojo architecture well enough to know where such a handler should go
13:59 moritz any proposals?
14:00 sri Nei: i don't know what exactly you want, and you've made too many assumptions not based on docs for me to know if there's really something missing
14:01 Nei sri, I showed you a *simple* 2 line mojolicious::lite app
14:01 Nei and ask how to catch the fatal error there
14:01 Nei no other assumptions
14:01 sri and i said use try/catch
14:01 sri right at the beginning
14:02 moritz I guess it's about catching errors in   get '/' => sub { ... } handlers and the like, but not repeating with try/catch for every sub
14:02 moritz at least that's what I've wanted a few times
14:02 Nei ok so your answer is, all handlers where I may need to catch exception, should be wrapped in try/catch?
14:02 sri moritz: it's sooooo much more complicated
14:03 Nei then maybe let me ask it this way, can I somehow influence the behaviour to make my app die, when exceptions arise in handlers. or do you consider that an anti-feature
14:03 sri moritz: you are inside an event loop, stuff happens outside the web framework sandbox
14:03 sri on many different layers
14:04 moritz sri: maybe another approach would work
14:04 moritz sri: giving &get, &post, &any etc. an option to wrap the code in an eval
14:04 moritz or maybe on a controllor or application level
14:05 Nei otherwise I need to anticipate all possible exceptions so I basically need to wrap any code in try/catch. which makes me want to know, which code is *required* for me to manually wrap in try/catch so that I can be *sure* app dies on exceptions
14:05 moritz (that is, don't try to handle it in the event loop, but prepare/wrap the callback before the event loop ever sees it)
14:05 Nei instead of silent resume
14:06 woz joined #mojo
14:06 sri i'm not sure what you are arguing for
14:06 sri if there was a simple solution, we would be using it
14:07 sri this is a complicated topic, you two don't seem to grasp yet, which is why i keep asking for proposals
14:07 Nei I just want to be sure my app can die in peace
14:07 r0b3rt joined #mojo
14:07 Nei moritz' suggestion doesn't seem too bad on first glance
14:07 moritz sri: and I'm talking about a proposals all the time
14:07 sri allright, let me be 100% clear.... THIS IS AN UNSOLVED PROBLEM
14:07 moritz sri: and I also told you that I don't know enough about mojolicious architecture to make it a patch
14:08 Nei it certainly sounds like it would be able to solve *my* issue
14:08 sri moritz: so far your proposal makes absolutely no sense
14:08 moritz sri: are there any high-level architecture docs for mojo/mojolicious?
14:08 moritz sri: why not?
14:08 sri moritz: there is no relation at all between actions and events
14:08 sri this stuff is async
14:08 moritz sri: what's an "action" and what's an "event" in your terminology?
14:08 sri actions are sync for a short timeframe, in which we already catch exceptions
14:09 Nei his proposal, as far as I can tell, is just providing a way to *catch* exceptions thrown in a handler, when the handler wasn't surrounded by try/catch manually
14:09 sri jberger: please take over!
14:09 Nei may be by subscribing to some error event
14:09 moritz sri: ok, what happens with the exceptions from a handle?
14:09 moritz erm
14:09 Nei and that would be a feature that could solve my issue
14:09 moritz sri: ok, what happens with the exceptions from an action?
14:10 moritz (sorry for confused terminology)
14:10 Nei certainly it *is* already catched by an eval somewhere inside mojo
14:10 Nei the reactor I think
14:10 moritz sri: can I register a callback that gets that exception as an argument?
14:11 Nei would think running them handlers thorugh eval_safe instead of eval_unsafe just do it maybe
14:12 Nei although I'm sure it's more complicated than that;))
14:12 sri you have no idea how much
14:12 Nei I admit as much
14:12 sri and i think i'm not able to explain it clearly
14:13 Nei imagine me as someone clueless, why cannot all handlers be run through eval and emit errors?
14:13 sri bottom line... UNSOLVED PROBLEM... and i very much welcome well thought out proposals with a patch, actual code we can discuss
14:14 Nei fair enough I guess. unsolved is unsolved
14:14 sujithm joined #mojo
14:14 moritz sri: are there any high-level overview docs of the mojo(licious) architecture?
14:15 sri if you're sync, exceptions are caught and render_exception applies, if you're async all bets are off and things happen differently on every layer
14:15 sri that's as simple as i can make it
14:15 sri moritz: no
14:16 Nei I see. it's confusing to me that the exceptions are caught "somewhere"
14:16 disputin joined #mojo
14:17 btyler Nei: async exception handling is also kind of all over the place in node.js land. one best pracice is "when an exception actually throws, you need to restart your application"
14:17 sri yea, people still seem to think async exception handling can be easy
14:17 sh4 joined #mojo
14:18 sri PLEASE SEND PROPOSALS if you can do it!
14:22 btyler this is largely about node conventions, but the distinction between operational errors and programmer errors is a handy one, I think: http://www.joyent.com/developers/node/design/errors
14:22 btyler (their suggestion is that programmer errors should throw and explode violently, operational errors should be handled with try/catch (less common in node) or the error event/err argument in the callback
14:22 btyler nested parentheticals, whoops
14:23 sri and add to that the lack of proper error objects in perl
14:24 btyler ...yeah
14:25 odc an idea: in jquery, async functions take 2 callback, 1 for success, 1 for error
14:25 sri i soooo knew someone would bring up promises
14:25 odc but that would make a huge api change...
14:25 sri BULLSHIT!!!
14:25 purl bullshit is or caca de taureau or http://www.jelks.nu/misc/articles/bs.html or http://www.rit.edu/~cepasp/bsmeter.gif
14:26 sri promises are for things that happen once, the whole time we are talking about recurring events
14:27 odc sri, who's talking about promises?
14:28 sri then please elaborate
14:29 odc example: $ua->get($url => $cb_success, $cb_error)
14:29 sri success/error is jquery promise/thenable terminology though
14:29 odc oh
14:29 odc but still i don't see the problem with that
14:29 sri and ->get invokes the callback only once
14:30 sri ->get is not the problem we are talking about at all
14:30 sri not even remotely
14:30 sri $c->on(json => sub {...})
14:30 sri or even if you want to go simple Mojo::IOLoop->recurring(2 => sub {...})
14:31 odc hmm
14:32 Nei say I have a programming error in my json sub. in mojo it will just not blow up in my face
14:33 odc well the first one is easy: $c->on(json => { valid => sub{}, invalid => sub{});
14:33 Nei if it's an expected operational error that may or may not occur on this specific run of the callback, I can try/catch as sri suggested
14:35 sri odc: what is that pattern called?
14:36 odc no idea
14:36 sri hmm... so you can't qualify valid and invalid?
14:36 sri what kind of terminology is that?
14:36 Nei I don't see how valid/invalid solves anything
14:37 sri i don't see it either, which is why i wanted to read up on the pattern
14:37 odc yes, i didn't understood your issue
14:37 odc too complicated for me
14:38 Nei what I believe to be looking for - but may be wrong - is $c->on(json => { throws...; and $c->catch(... or app->somewhere_async->catch(...
14:40 odc that's what we are doing with die() instead of throw right?
14:40 Nei yep but catching it is the unsolved problem
14:40 odc ah
14:41 odc i also think catching die() is bad since my application also catches sig __die__
14:41 odc but it works...
14:42 Nei I like some parts of the node article btyler linked
14:42 odc is the callback executed inside an eval ?
14:42 Nei no clue yet if/how that might applicable to mojo
14:43 Nei indeed the callback is somewhere executed in an eval which I complained about;)
14:43 odc i see, and what is your complaint? speed?
14:44 Nei that it doesn't blow up
14:44 odc !!
14:44 odc i don't want it to blow up
14:44 odc not production code
14:45 Nei but try{}catchall{resume} is not a solution to that imo
14:45 Nei mind you the code still doesn't work
14:45 Nei (fully or properly at least)
14:46 rawler joined #mojo
14:46 odc mmm but you can analyse the error in the catch{} and take a decision accordingly. Isn't that enough?
14:47 Nei I can't catch it, unless I make preparation beforehand and wrap it like json => sub { try { actualsub} catch{}}
14:48 odc ho i see, i was talking about ioloop->delay
14:49 odc the json decoder should send the error message to the callback
14:50 odc like most other mojo modules
14:52 cpan_mojo MojoX-CustomTemplateFileParser 0.09 by CSSON - http://metacpan.org/release/CSSON/MojoX-CustomTemplateFileParser-0.09
14:52 sujithm joined #mojo
14:53 D4RK-PH0ENiX joined #mojo
15:03 sri personally, i think the only proposal someone could make would be to emit all events safely https://gist.github.com/anonymous/fce39e6449107e0b5912
15:05 sri and before anyone asks what the downside would be... I DON'T KNOW!
15:05 Nei :D
15:05 Nei universe will implode
15:05 sri it could have catastrophic side effects
15:06 sri all errors will be caught, which means central stack trace stuff could break horribly
15:06 aleksey left #mojo
15:06 Nei from a lwymans point I'd also judge this change rather sever
15:07 sri this stuff is really really hard, no matter what you do, there will be side effects
15:07 woz joined #mojo
15:08 sri i can put it up for a vote... but the problem is nobody is qualified to vote
15:08 * sri pokes jberger, marcus, tempire, batman and crab
15:09 * marcus explodes
15:09 sri see!
15:09 * marcus is scattered all over the channel in a fine mist
15:10 sri i know jberger has asked for this before... but considering he asked me yesterday about the topic... i doubt he really knows what the consequences are either
15:12 marty joined #mojo
15:12 marcus I love reading gists inline in convos
15:13 marcus so this means every event in mojo will be run inside an eval cage and emit error events?
15:13 marcus sri: any ideas about the performance hit?
15:17 good_news_everyon joined #mojo
15:17 good_news_everyon [mojo] kraih created safe_events (+1 new commit): http://git.io/A5JjUw
15:17 good_news_everyon mojo/safe_events 05cf42a Sebastian Riedel: emit all events safely
15:17 good_news_everyon left #mojo
15:17 sri marcus: check for yourself
15:17 Nei note that, it already runs in an eval cage
15:17 Nei it would run in one more
15:20 sri i can't measure a difference
15:20 sri eval blocks seem to be dirt cheap
15:21 * sri pokes jberger, marcus, tempire, batman and crab again
15:21 jamesaxl joined #mojo
15:21 batman i'm not qualified to vote yes.
15:24 marcus I'm still trying to figure out what the bad consequences could be.
15:24 sri i fear this might get rejected due to lack of votes
15:25 marcus I'm trying to think of code that could be broken by the change.
15:26 batman i can't think of any, but my brain is not back online yet
15:27 marcus it would be code that relied on events dying inside the ioloop? That seems a bit far fetched.
15:27 sri http://stream1.gifsoup.com/view2/4853503/zombies-don-t-want-homers-brain-o.gif
15:28 sri marcus: if the error event has no subscriber it rethrows
15:28 sri we made that for delays
15:28 sri so worst case you have a lot of rethrows bubbling up
15:30 marcus So it might expose some hidden errors? :)
15:31 sri as in error messages may change, like https://github.com/kraih/mojo/commit/05cf42af6a2a#diff-d6b886f585c3cd63e0c6671bf71505a7L915
15:31 sri that one now says "Mojo::Content::Single: Event "drain" failed: Body callback was called properly"
15:32 mr-foobar joined #mojo
15:32 sri every rethrow adds the current class name to the front
15:49 sri *crickets*
15:53 tempire I don't know what we're voting on
16:00 D4RK-PH0ENiX joined #mojo
16:02 basiliscos joined #mojo
16:03 sri tempire: https://github.com/kraih/mojo/compare/safe_events
16:07 * sri pokes jberger, marcus, tempire, batman and crab again
16:07 sri and anyone else for that matter
16:08 woz joined #mojo
16:20 basiliscos joined #mojo
16:24 sri *crickets*
16:25 tempire I guess I missed it in the backlog
16:25 tempire What's the motivation?
16:25 purl the motivation is brownies
16:25 sri the backlog ;p
16:25 cpan_mojo Dist-Zilla-Plugin-Test-CreateFromMojoTemplates 0.05 by CSSON - http://metacpan.org/release/CSSON/Dist-Zilla-Plugin-Test-CreateFromMojoTemplates-0.05
16:25 sri ALL OF IT
16:25 * sri has smoke coming out of his ears only thinking about it
16:25 tempire Catching an exception
16:26 sri Nei started it with the problem that exceptions in $c->on(json => sub {...}) get caught "somewhere" on a lower level he can't reach
16:27 sri the idea is to always allow the object emitting the exception also to catch it with ->on(error => sub {...})
16:28 sri if you can't follow, that's fine, i barely understand the whole thing either
16:29 tempire The principle sounds reasonable.
16:29 * tempire thinks
16:30 * sri sees smoke coming out of tempire's ears
16:31 sri am i the only one who keeps forgetting how to gzip/gunzip stuff? i just want to add a Mojo::Util::gzip/gunzip every other week...
16:31 * tempire revisits the guide example whenever necessary
16:32 sri use IO::Compress::Gzip 'gzip'; gzip $uncompressed, \my $compressed;
16:32 sri haha, me too
16:32 sri it's not exactly a lot of code, or very hard.... but i always forget
16:32 sri b($stuff)->gzip would be neat
16:33 sri with a default compression level of 9
16:33 sri if only there was a core use case besides examples in the guides...
16:43 ryozi joined #mojo
16:46 sri of course 10 lines of code is a lot for a little bit of convenience https://gist.github.com/anonymous/05ab0470345759ee386e
16:52 sri anyway... i'm distracting from the real topic of the day
16:53 sri Nei: like i said, i doubt we have enough voters
17:05 Eke- joined #mojo
17:07 cpan_mojo Dist-Zilla-Plugin-InsertExample-FromMojoTemplates 0.02.00 by CSSON - http://metacpan.org/release/CSSON/Dist-Zilla-Plugin-InsertExample-FromMojoTemplates-0.02.00
17:09 woz joined #mojo
17:17 irq joined #mojo
17:18 disputin joined #mojo
17:40 irq_ joined #mojo
17:41 bodgix joined #mojo
17:54 gissel joined #mojo
17:54 gissel Hello, can anyone help me?
17:55 gissel i added a route for a POST request, the route is there
17:56 gissel but i get this "None of these routes could generate a response for your POST request"
17:56 gissel and the route appears in the list of possible routes
17:56 gissel anyone?
17:56 purl Somewhere, someplace, in some universe, somebody uses whatever you just asked about.
17:57 gissel did you?
17:57 sugar joined #mojo
17:58 gissel hmmm...
17:58 gissel alguien me da bola?
17:59 gissel joined #mojo
18:05 ignacio_ joined #mojo
18:06 sri btw. the other way around, switching all emit_safe to emit does not work
18:06 sri since that prevents connections from getting cleaned up
18:07 sri so, it's either mixed emit/emit_safe, or pure emit_safe
18:09 sri moritz: i suspect you're seeing the problems too now, if you have anything to contribute, now is the time
18:10 woz joined #mojo
18:20 jamesaxl joined #mojo
18:29 disputin joined #mojo
18:31 dod joined #mojo
18:31 marty joined #mojo
18:32 ignacio_ joined #mojo
18:32 ignacio_ joined #mojo
18:35 * jberger_ tries to catch up
18:36 jberger_ Btw generally i want less use of emit_safe, it can catch errors in strange places
18:37 jberger_ I know what such consequences are
18:40 sri jberger_: what are such consequences?
18:40 sri jberger_: also, are you speaking of the current version of emit_safe or an older one?
18:41 sri it used to be the case that it didn't rethrow
18:41 sri now, if the error event has no subscribers it rethrows
18:42 mattastrophe joined #mojo
18:42 KCL_ joined #mojo
18:43 jberger_ Oh I'm talking about old emit_safe i guess
18:43 sri :)
18:44 jberger_ I'm at $work, so I'm not able to give 100%attention
18:45 sri i think you might be the only one who has a chance of really understanding the patch
18:47 sri btw. i've tried less emit_safe, can't work, we need to catch certain errors for the user agent and other clients
18:48 jberger_ When did the new emit_safe come in?
18:48 jberger_ I have still had problems with it fairly recently
18:48 sri not sure, just remember i changed that for delays
18:49 sri so delays would throw if they don't have an error subscriber
18:50 jberger_ Forkcall has one delay i added purely for the purpose of catching before the stream's emit_safe kicked in
18:51 jberger_ So in response to Nei's original question, my response would be, if the transaction's error event cannot catch this error, then you should catch it yourself
18:52 jberger_ Callback have that ability where some other code paths do not, and this they get safe code
18:53 sri that was my original answer as well ;p
18:54 jberger_ https://github.com/jberger/Mojo-IOLoop-ForkCall/blob/master/lib/Mojo/IOLoop/ForkCall.pm#L28
18:55 jberger_ I didn't realize what i was starting highlighting that question
18:56 sri there's always consequences
18:56 jberger_ My point in asking was that i was curious about the path that the error was bubbling up from, not saying that it should be changed
18:56 sri the answer is that it's currently very inconsistent
18:58 neyasov joined #mojo
18:58 jberger_ Several of these are tough because they are essentially stream errors as far as where they are emitted
18:58 sri to the extent that you have to do the try/catch dance in every ->on(foo => sub {...}) yourself, and cannot count on something catching for you
18:59 jberger_ Yep
18:59 jberger_ Use delays early and often
19:00 sri NOOOOOO
19:00 sri that's completely wrong
19:00 sri delays for for stuff that happens once
19:00 sri eventemitter events happen one or more times
19:00 sri they should never be mixed
19:01 sri only $object->once() would be ok
19:01 sri never $object->on()
19:02 sri this is the difference bwteen promises and supplies in perl6
19:02 jberger_ Not us,  the user
19:02 jberger_ Delay has a nice catch built in
19:02 jberger_ As i used it in forkcall
19:02 sri you can't be serious
19:03 sri we are not going to recommend a ->delay(sub {...})->catch(sub {...}) pattern
19:03 jberger_ I can, also it breaks cycles
19:03 jberger_ I'm not to the point of absolutely recommending that, but i find myself doing it a lot
19:04 sri cycles should be irrelevant for a try/catch
19:04 sri since nothing is stored in an object
19:04 irq joined #mojo
19:04 jberger_ Two different issues, but they come together sometimes
19:07 sri i don't see any reason for why you can't do "eval { $self->_run(@args); 1} or $self->emit(error => $@);"
19:07 sri shorter, faster, an looks better
19:10 sri i think you might have convinced me to merge the branch ;p
19:11 sri (although the fact that i've looked into how node.js handles the problem helped too)
19:11 woz joined #mojo
19:15 jberger_ This shows why i needed the delay (for cycle prevention) : https://github.com/jberger/Mojo-IOLoop-ForkCall/commit/8f3c842f28176b77c141b6399e0280624f63a28d
19:15 jberger_ And then the error handler was added later
19:16 jberger_ https://github.com/jberger/Mojo-IOLoop-ForkCall/commit/1372b0957321916c360588ee43a65ea315e04a88
19:19 batman jberger_: if you have some spare time: https://travis-ci.org/jhthorsen/mandel/jobs/34946019
19:19 batman i can't seem to reproduce it here :(
19:23 sri jberger_: oh, that is an odd case
19:23 sri but i really don't think that represents a common pattern
19:24 jberger_ But it might end up being very similar to what you might need in an "on json" callback
19:25 jberger_ batman: i can't look at that right now, but i will try to remember for tonight
19:25 sri if that was the case i think it would be a disaster
19:26 batman jberger_: thanks
19:27 jberger_ sri: the more i look at it, probably not
19:27 sri why would you ever want $c->on(json => sub { Mojo::IOLoop->delay(sub {...})->catch(sub {...}) }) over $c->on(json => sub {...}); $c->on(error => sub {...}); ?
19:27 jberger_ The next_tick  was really the driving problem
19:27 sri it doesn't rule out your pattern either
19:28 sri only allows errors to be caught with the transaction object
19:28 jberger_ No i wouldn't prefer to use delay over the error event
19:28 jberger_ But the error event was not catching errors in that callback
19:29 jberger_ So i guess safe is good there
19:29 sri no it wasn't, which is why we are discussing the patch ;p
19:29 * jberger_ has smoke coming out of marcus' ears
19:29 sri :o
19:29 marcus jberger_: that will teach you not to bogart so much.
19:30 * jberger_ passes the... event
19:30 * sri slowly stops gesticulating wildly
19:30 * jberger_ changes sri's name to Josh Lyman
19:31 genio ... the West Wing character?
19:32 * jberger_ refers genio to the episode "The Supremes"
19:33 mattastrophe joined #mojo
19:33 * jberger_ hands sri another glass of scotch and tells him not to try to keep up
19:34 woz joined #mojo
19:36 sri oh, i might have been wrong about getting rid of emit_safe
19:37 sri it's actually rather simple ;p
19:38 marcus eval none of the things
19:40 sri for the record, node.js does not catch all event errors in the object
19:41 * marcus buys sri a "What Would Node do" sticker.
19:41 sri i don't mind stealing here, they have more experience with this than we do
19:44 cpan_mojo MojoX-CustomTemplateFileParser 0.10 by CSSON - http://metacpan.org/release/CSSON/MojoX-CustomTemplateFileParser-0.10
19:56 good_news_everyon joined #mojo
19:56 good_news_everyon [mojo] kraih created no_safety (+1 new commit): http://git.io/-4QadQ
19:56 good_news_everyon mojo/no_safety 524bc73 Sebastian Riedel: handle all events the same
19:56 good_news_everyon left #mojo
19:56 sri jberger/marcus/tempire/batman/crab: that's the other alternative
19:56 sri all exceptions would reach the reactor
19:59 sri jberger_: i believe that's what you wanted originally
20:02 sri i think we should pick one, for consistentcy
20:03 sri https://github.com/kraih/mojo/compare/no_safety
20:03 sri or
20:03 sri https://github.com/kraih/mojo/compare/safe_events
20:06 good_news_everyon joined #mojo
20:06 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/8x40PQ
20:06 good_news_everyon mojo/master af9666c Sebastian Riedel: fixed Perl 5.16 support
20:06 good_news_everyon left #mojo
20:07 sri jberger/marcus/tempire/batman/crab: you don't get to complain later if i choose one for you
20:07 batman i'm leaning toward emit_safe() if i have to choose
20:07 marcus Me too
20:08 marcus sri: keeping the status quo isn't an alternative?
20:09 sri in what way is the status quo better than those two?
20:09 marcus it's familiar :)
20:09 sri i mean, seriously, where were you earlier when i had to explain the status quo?
20:09 sri can you explain the status quo to me?
20:10 marcus I think I cannot.
20:10 sri no, you can't, I CAN'T FRICKING EXPLAIN IT!!!1 ;p
20:10 sri argh... you stole my punchline
20:11 marcus well, then I am seriously leaning towards safe emit all the things.
20:11 marcus Feels like emit should just be safe by default then
20:11 marcus but I guess that's an even bigger change.
20:11 batman +1
20:11 purl 1
20:11 sri hmm
20:12 sri plain emit might still be needed for error though
20:12 sri or maybe not
20:14 marcus I'd like to hear crab's perspective too, but I guess it's past his bedtime.
20:14 sri actually, doesn't look like such a big change
20:15 sri making everything safe and deprecating emit_safe seems very possible
20:15 marcus in code lines or consequences? :)
20:17 sri ah, it seems to break delays
20:17 sri so not as easy
20:20 sri we are back to the two options above
20:21 marcus It's not like anyone uses delays. :D
20:21 marcus (says the biggest delay user of them all)
20:22 batman marcus: hey! what about me? ;)
20:22 marcus batman: You might win this one, actually
20:23 batman hehe
20:23 batman marcus: have you looked at the new issues in convos? 177, 178 and 179
20:24 marcus batman: sorry, been busy tweaking my vim config https://github.com/Valloric/YouCompleteMe
20:24 marcus :D
20:24 marcus I've read the mails. will respond tonight
20:25 batman does the plugin work with perl?
20:25 marcus Well, re 177 I really don't have any feedback.
20:25 marcus batman: it falls back to omnicomplete
20:25 batman issues: no stress. i'm still not to in a condition to think new, complicated thoughts :/
20:25 batman vim: ok
20:25 batman 177: yeah, i think it's just me screwing up...
20:26 batman did you see my new assetpack?
20:28 marcus Yeah, I saw
20:28 batman i wonder if there's a way i can be back compat when it comes to calculating checksum...
20:28 batman or if i even want to
20:29 batman marcus: https://github.com/jhthorsen/mojolicious-plugin-assetpack/commit/94673b1ec5d8f9f8c0cbb864d7e828c9fd7afe4e <--- thanks for the idea
20:30 sri jberger, tempire, crab: we have two votes for safe_events, all up to you now
20:30 marcus sri: did you vote?
20:30 sri not yet
20:31 marcus I guess you'd break a tie now that we're 6
20:31 sri i have no strong preference for either solution though, i just want consistency
20:32 sri no safety would be what node.js does, all safety seems to be what our users expect... so meh
20:33 sri node.js does have this domain thing though, where you wrap globalish error handlers around a bunch of eventemitters... it failed completely though, nobody uses it
20:33 sri so, maybe all safety events is the way to go
20:33 * sri shrugs
20:38 sri but honestly, if i was to dictate, i might have chosen no_safety, just because it's simpler
20:39 sri how often do you really want to recover from event failures and not just log them centrally?
20:39 jberger_ I vote no safety in that it mucks with the error message mostly
20:39 jberger_ I vote no safety in that it mucks with the error message mostly
20:39 sri you only get one vote ;p
20:40 jberger_ Resend seems to have lied to me
20:40 jberger_ Crappy network in the building
20:41 sri there is a certain beauty to sending all non-blocking exceptions to one central event
20:41 * jberger_ agrees
20:41 sri its job would be to make sure the server never does from something that mundane, and to log stuff
20:41 jberger_ I wonder if we are going to get a split vote on this
20:42 sri already have
20:42 sri 2 for safe_events 1 for no_safety
20:42 dod joined #mojo
20:42 sri purl: seen crab
20:42 purl crab was last seen on #mojo 9 days, 17 hours, 41 minutes and 2 seconds ago, saying: internet giants!  [Sep  1 03:01:39 2014]
20:42 sri oh
20:43 sri tempire: all the cameras are pointed at you
20:45 jberger_ I see emit_safe as vestigial code from before errors bubbled up
20:46 sri that's true
20:51 jberger_ Looking back on it, errors that bubble up might have been one of the more important changes of the last while
20:53 * sri hopes for a fancy GoT title, like "sri, Breaker of Ties"
20:54 jberger_ Mother of Delays
20:54 sri :D
20:57 sri batman, marcus: you two can still change your vote *hint hint*
20:58 marcus So can jberger_
21:00 * jberger_ challenges marcus to a battle of wits
21:00 marcus A battle of dimwits
21:01 marcus Sorry, busy playing nethack
21:01 marcus G - A two handed sword (weapon in hand)
21:01 jberger_ NEVER GO AGAINST A SICILIAN WHEN DEATH IS ON THE LINE
21:02 marcus http://youtu.be/JBCbPsiflQQ
21:04 sri never was i so glad half of youtube is unavailable in germany
21:04 sugar joined #mojo
21:06 r0b3rt left #mojo
21:14 jberger_ http://youtu.be/dQw4w9WgXcQ
21:16 marcus Somehow that one always works tho.
21:16 marcus http://youtu.be/htgr3pvBr-I
21:17 marcus sri: Must be sad to have no youtube.
21:18 marcus I've become a huge fan of chromecast and youtube tv queues lately
21:19 sri http://www.anatone.net/Administration/Data/Photos/Resource/77b1973d-8976-485e-9a0a-13ef531d72c7_sad_owl.png
21:29 berov joined #mojo
21:35 good_news_everyon joined #mojo
21:35 good_news_everyon [mojo] kraih pushed 1 new commit to no_safety: http://git.io/3oEGQA
21:35 good_news_everyon mojo/no_safety 11f2cf5 Sebastian Riedel: better recipe for exceptions in events
21:35 good_news_everyon left #mojo
21:38 neyasov_ joined #mojo
21:44 good_news_everyon joined #mojo
21:44 good_news_everyon [mojo] kraih pushed 1 new commit to no_safety: http://git.io/oarqUg
21:44 good_news_everyon mojo/no_safety a4b9e1a Sebastian Riedel: mention how to make all exceptions in callbacks fatal
21:44 good_news_everyon left #mojo
21:44 sri yea, i tend towards this solution, since it's easy to explain https://github.com/kraih/mojo/compare/no_safety
21:48 tempire my vote is no_safety
21:49 tempire with the Mojo::Reactor/error subscription
21:49 sri oh my
21:49 sri we have a mexican standoff
21:51 tempire http://www.youtube.com/watch?v=h1PfrmCGFnk
21:56 sri i just wanted to add a try/catch example to the recipe, what's the currently recommended idiom?
21:56 sri eval {}; ... if $@; seems fine again... since we recommend a modern perl
21:58 disputin joined #mojo
21:58 woz joined #mojo
22:01 btyler can't $@ be a false value?
22:02 good_news_everyon joined #mojo
22:02 good_news_everyon [mojo] kraih pushed 1 new commit to no_safety: http://git.io/P5NS5g
22:02 good_news_everyon mojo/no_safety cad17b9 Sebastian Riedel: more complete exception handling example
22:02 good_news_everyon left #mojo
22:02 sri https://github.com/kraih/mojo/compare/no_safety#diff-b659d9bfeffa6b78a1f2950c7e72259bR521
22:03 sri what i had in mind
22:03 sri all the details
22:06 sri for better reading https://github.com/kraih/mojo/blob/no_safety/lib/Mojolicious/Guides/Cookbook.pod#exceptions-in-events
22:09 disputin joined #mojo
22:11 disputin joined #mojo
22:13 good_news_everyon joined #mojo
22:13 good_news_everyon [mojo] kraih pushed 1 new commit to no_safety: http://git.io/S8-MLQ
22:13 good_news_everyon mojo/no_safety bee389a Sebastian Riedel: use the term exception more often
22:13 good_news_everyon left #mojo
22:15 bodgix left #mojo
22:19 woz joined #mojo
22:21 disputin joined #mojo
22:33 * sri votes +1 on no_safety btw.
22:33 sri sorry batman and marcus
22:34 marcus guess crab's vote is moot then
22:34 * sri nods
22:34 sri deprecate emit_safe or keep it?
22:37 sri i barely remember how to deprecate something
22:41 jberger_ Is it used often in cpan dists?
22:41 * jzawodn just shipped Mojo::IOLoop in a piece of our infrastructure that handles several hundred million queries/day
22:42 jzawodn slowly chisseling away at mod_perl
22:42 jberger_ jzawodn++
22:42 jberger_ jzawodn: do you use emit_safe?
22:42 jzawodn I mostly skipped the earlier emit discussion here :-)
22:43 disputin joined #mojo
22:44 jberger_ jzawodn: do how many fewer servers do you need now?
22:45 jberger_ s/do/so/
22:45 woz joined #mojo
22:45 sri http://grep.cpan.me/?q=emit_safe
22:45 jzawodn jberger_: I'll know when the other half ships: a replacement mojo-powered daemon that offloads a bunch of the requests
22:45 sri mostly just batman and you using it ;p
22:47 jberger_ This looks familiar : https://metacpan.org/source/MUDLER/Deeme-0.04/lib/Deeme.pm
22:48 sri heh
22:52 jberger_ sri: https://metacpan.org/source/JBERGER/Mojo-IOLoop-ForkCall-0.14/lib/Mojo/IOLoop/ForkCall.pm#L103
22:52 jberger_ This is a case for emit_safe
22:52 good_news_everyon joined #mojo
22:52 good_news_everyon [mojo] kraih pushed 2 new commits to master: http://git.io/6WAXMA
22:52 good_news_everyon mojo/master 79c5645 Sebastian Riedel: Merge branch 'no_safety'
22:52 good_news_everyon mojo/master f35376d Sebastian Riedel: deprecated Mojo::EventEmitter::emit_safe
22:52 good_news_everyon left #mojo
22:53 jberger_ If that fails where does the error come from?
22:53 jberger_ I will test when i get home
22:53 sri no core use means it is out imo
22:53 jberger_ Probably
22:54 davido_ joined #mojo
22:55 sri now i want to get this right http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Exceptions-in-events
22:56 jberger_ If one event has several subscribers and the first dies do the others get called?
22:56 sri no
22:58 jberger_ Deprecation message is a little strong
23:03 jberger_ It is a bit of a change, especially for things like forkcall
23:04 sanya_com_ua joined #mojo
23:06 jberger_ Except that since the stream won't emit_safe either, an error will still emit from the fc instance
23:06 * jberger_ makes a new mental model
23:07 jberger_ It's more like a proper call stack again!
23:09 woz joined #mojo
23:12 cpan_mojo Mango 1.11 by Sebastian Riedel - http://metacpan.org/release/SRI/Mango-1.11 (depends on Mojolicious)
23:13 disputin joined #mojo
23:13 sri jberger_: you're saying it got better? :)
23:17 sri i like the smell of less special cases in the morning
23:23 good_news_everyon joined #mojo
23:23 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/P_kRhA
23:23 good_news_everyon mojo/master 4b27b60 Sebastian Riedel: added more details to the exception handling recipe
23:23 good_news_everyon left #mojo
23:23 sri anyone who still wants to make a last minute proposal will have to include better documentation than this http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Exceptions-in-events
23:24 sri but i'm rather happy with how clear it is
23:28 sri and i hope you all learned your lessen, don't ask for my opinion! ;p
23:29 sri jberger_: rofl, i didn't get what you meant before with your comment about the deprecation message
23:29 sri yea, that's a bit harsh
23:30 jberger ;-)
23:31 good_news_everyon joined #mojo
23:31 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/eAJ3Xg
23:31 good_news_everyon mojo/master 2fb41c6 Sebastian Riedel: we will not be deprecating the whole event emitter :)
23:31 good_news_everyon left #mojo
23:31 jberger If you hadn't seen it when i got home i would have fixed it
23:49 woz joined #mojo
23:53 jberger the problem is that the message is wrong about which event failed
23:55 jberger then again, I don't want the prepended message anyway, I'll catch it myself
23:57 jberger sri: how does this look? https://github.com/jberger/Mojo-IOLoop-ForkCall/compare/no_safe
23:58 jberger that way it appears that the error event is emitted directly from the fc instance

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