Camelia, the Perl 6 bug

IRC log for #mojo, 2013-04-04

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

All times shown according to UTC.

Time Nick Message
00:02 jberger truncate?
00:02 jberger escape?
00:02 jberger terminate? last?
00:03 jberger I kinda like last, it parallels the perl concept
00:04 jberger does the finish event fire after ->clear is called?
00:04 sri it does
00:06 jberger so probably not terminate
00:06 jberger or escape
00:12 d4rkie joined #mojo
00:12 jberger if you add a method that moves to the next step, then next and last should feel familiar to perl users
00:13 sri there will be no ->next ;p
00:15 jberger I've been trying to think what it would do, but I can't :-P
00:15 jberger beyond what return can already do
00:37 tempire I like clear
00:41 shmuel joined #mojo
00:55 gtodd joined #mojo
01:16 KindOne joined #mojo
01:23 Averna joined #mojo
01:36 ka2u joined #mojo
01:47 jberger joined #mojo
01:57 Meiermann joined #mojo
02:00 Gedge joined #mojo
02:00 preflex joined #mojo
02:57 preflex_ joined #mojo
03:36 jb360 joined #mojo
03:37 jb360 joined #mojo
04:48 ka2u joined #mojo
04:59 Meiermann joined #mojo
05:43 coff joined #mojo
05:49 ispy_ joined #mojo
05:50 basiliscos joined #mojo
06:12 dod joined #mojo
06:12 ispy_ joined #mojo
06:38 dpetrov_ joined #mojo
06:42 dod joined #mojo
06:55 davido joined #mojo
07:07 arthas joined #mojo
07:07 Vandal joined #mojo
07:07 dod joined #mojo
07:14 mire_ joined #mojo
07:16 ObseLeTe joined #mojo
07:22 suy joined #mojo
07:39 Andreas joined #mojo
07:51 ispy_ joined #mojo
07:52 jzawodn joined #mojo
07:52 fhelmber_ joined #mojo
08:13 jpn joined #mojo
08:35 maxhq joined #mojo
08:43 ver joined #mojo
08:48 mire_ joined #mojo
08:52 egopro joined #mojo
08:53 egopro joined #mojo
08:55 nelio joined #mojo
09:00 rem_lex|pivo joined #mojo
09:11 mire_ joined #mojo
09:39 egopro joined #mojo
09:46 Meiermann joined #mojo
09:55 egopro joined #mojo
10:03 egopro joined #mojo
10:07 mire joined #mojo
10:18 egopro joined #mojo
10:23 egopro_ joined #mojo
10:27 egopro joined #mojo
10:31 egopro joined #mojo
10:33 egopro joined #mojo
10:34 mattastrophe joined #mojo
10:34 Averna joined #mojo
10:38 egopro joined #mojo
10:40 Britzel_ joined #mojo
10:43 egopro joined #mojo
10:47 egopro joined #mojo
10:55 egopro joined #mojo
10:56 egopro joined #mojo
11:15 bzero sri: Why --accept-interval for prefork does not accept 0.5? Only 1 or more.
11:34 rihegher joined #mojo
11:37 bzero Nevermind. plackup exists. Thanks.
11:55 Kripton joined #mojo
11:55 Kripton_ joined #mojo
11:58 rihegher left #mojo
12:36 ispy_ joined #mojo
12:38 good_news_everyone joined #mojo
12:38 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/-6DlNA
12:38 good_news_everyone mojo/master 5589737 Sebastian Riedel: improved prefork command to allow -a and -L values below 1 second
12:38 good_news_everyone left #mojo
12:56 mire joined #mojo
13:08 moltar joined #mojo
13:10 bluescreen joined #mojo
13:21 * sri shakes marcus
13:26 ispy_ hey all
13:26 sri o/
13:26 ispy_ what's up sri
13:59 d4rkie joined #mojo
14:26 denisboyun joined #mojo
14:35 gryphon joined #mojo
14:39 coff joined #mojo
14:41 ObseLeTe joined #mojo
14:43 * tempire preforks
14:57 labrown joined #mojo
14:59 Akron joined #mojo
15:05 sh4 joined #mojo
15:06 ver joined #mojo
15:09 Akron I think now I understand the delay thing ... at least better. My problem with delay was, that I was thinking of a special timer thing ("delay"), although the class has more or less the job to push events on the IOLoop and control the flow of these events. The control however is quite limited.
15:09 Akron The class incorporates to concepts: Steps and flow control. The method ->steps is more like an attribute. I expected it to push events to the loop, but it replaces all steps. So maybe it's more intuitive to make ->steps(...) an attribute with ->steps(undef) being ->clear. And you have to ->begin manually.
15:10 Akron Does this make sense?
15:33 sri Akron: nope, first step needs to run right away
15:34 sri delays started out with only begin/end, steps is something we added later on
15:37 sri http://mojolicio.us/perldoc/Mojo/IOLoop#delay
15:37 sri maybe it shouldn't be so versatile, but it might be too late for changing that
15:39 sri then again, even if it had less features, the concept would still be too complicated for most
15:39 sri if you don't fully understand event loops, there is no chance you could understand delays
15:41 sri it's just the same with AnyEvent condvars, which are simpler, yet everybody tries to ->recv recursively
15:43 marcus <3 steps
15:43 sri marcus: opinion on $delay->clear?
15:43 marcus sri: What's the use case?
15:44 marcus sorry, I've been ill the last couple of days, and out of the loop.
15:44 sri break the steps https://github.com/kraih/mojo/​blob/master/t/mojo/delay.t#L72
15:45 marcus sri: I thought just not calling begin was enough to break the steps.
15:45 sri nope, next step runs anyway
15:46 marcus oh, then I'm in favor. And I need to check some of my code ;-)
15:46 sri https://github.com/kraih/mojo/compare/1ef​5a56c6af582410146c9d0433093e26ae24d93...0​3e5be5799e088e8284f8b1e2a8ca43c59e41bfe
15:46 sri the commits
15:46 marcus but when does the next step run if you don't call begin?
15:46 marcus after the sub ends?
15:47 sri yea
15:47 marcus Why?
15:47 sri because that's how we made it :)
15:47 sri judofyr might know better than me ;p
15:48 marcus I guess I'd rather just change that then add clear, but I guess someone might depend on that behavior now.
15:49 marcus unless judofyr knows a really good reason why it should work the way it does
15:49 sri it does not appear tested or documented though
15:51 marcus for how I use steps, it doesn't seem useful. The step usually prosesses whatever is run in the previous one.
15:51 sri actually
15:51 sri you might be right and it already works that way :O
15:51 mire joined #mojo
15:52 marcus if so, I vote no on adding ->clear ;-)
15:52 sri +1000
15:53 marcus I'm preparing a async mojo talk for yapc-eu
15:53 marcus Thinking of naming it - The internet is out of sync
15:54 sri sounds nice
15:55 sri ohoh
15:55 sri it did not quite work that way
15:55 sri there was a bug preventing the finish event it seems
15:55 sri the remaining steps were ignored though
15:57 xaka joined #mojo
16:02 Akron Just returning without ->begin would be definately better.
16:03 sri already works that way, just the finish event is not emitted in that case
16:03 Akron Yes - I read that. What I meant: Fix that and ->clear-- from me. ;)
16:04 sri trying to figure out if there was a reason
16:04 sri it's untested though
16:08 marcus joined #mojo
16:08 batman joined #mojo
16:12 sri there is an edge case
16:12 sri what happens if a step calls ->begin and ->end right away, so the event counter reaches zero while it is still inside the step callback
16:13 sri ?
16:13 sri Mojo::IOLoop->delay(sub { Mojo::IOLoop->timer(0 => shift->begin) }, sub { shift->begin->() }, sub { say "BOOM!" });
16:14 * sri pokes marcus and Akron
16:15 ka2u joined #mojo
16:16 sri Mojo::IOLoop->delay(sub { Mojo::IOLoop->timer(0 => shift->begin) }, sub { $_[0]->begin->(); Mojo::IOLoop->timer(0 => $_[0]->begin) }, sub { say "BOOM!" });
16:16 marcus sri: it should call the step, if possible.
16:16 sri ok, better example
16:16 marcus BOOM!
16:16 sri but when?
16:17 sri the timer already reached 0 when $_[0]->begin->() happens
16:17 marcus sri: my head hurts now
16:17 sri mine too
16:18 sri the next step is tied to the ->end call
16:18 sri so it happens whenever an ->end call results in an event count of 0
16:23 Akron Is there a real usecase for this? I mean - it might be unexpected behaviour - but it's also unexpected code.
16:23 sri use case it that it happens in real evented code
16:24 Akron You could even expect to run the following steps twice ...
16:24 Akron Hm.
16:24 sri how do you know FooBar->timer(23 => $delay->begin) doesn't call the callback right away?
16:24 sri it may not be good style for evented code, but it happens all the time
16:25 Akron Hm.
16:25 sri and is pretty much impossible to track down
16:25 sri all you see is steps and events running out of order randomly
16:29 Akron marcus: I hope you're well again.
16:29 sri that's what can happen now btw. so your code is already broken
16:29 sri we need clearly defined behavior
16:29 Akron Yes. And it seems to be untestable ...
16:30 sri it is testable
16:30 sri see examples i posted above
16:30 sri they just force the result
16:30 sri while in your apps it depends on timing
16:30 nelio joined #mojo
16:31 Akron Sorry, I don't understand.
16:35 denisboyun joined #mojo
16:35 sri that's ok, i fail completely at explaining it
16:35 sri bottom line, don't use delays, they are completely broken
16:36 Akron Staring at your examples and the second example of the synopsis I slowly start to understand why my assumption above was totally wrong.
16:37 dod joined #mojo
16:47 sri it gets worse
16:48 sri ordered results are completely broken too
16:49 sri not sure anymore if this is fixable
16:49 sri marcus: we may have to deprecate delays :(
16:50 bowtie joined #mojo
16:58 good_news_everyone joined #mojo
16:58 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/U_whOg
16:58 good_news_everyone mojo/master 0cb328d Sebastian Riedel: fixed multiple timing bugs in Mojo::IOLoop::Delay
16:58 good_news_everyone left #mojo
16:58 sri now it breaks in predictable ways
16:59 sri if that's the right thing to do i don't know
17:00 davido joined #mojo
17:01 davido Seems like there's a nice Mojolicious solution to http://www.perlmonks.org/?node_id=1026967 , but I'm not familiar enough with using event loops to answer.
17:01 heytrav joined #mojo
17:06 Akron Where is the id coming from?
17:07 Akron Forget it.
17:13 marcus sri: Ordered results have always worked well for me.
17:13 sri marcus: only if you're lucky
17:14 sri if one of your events gets emitted before the step callback has finished you're screwed
17:14 marcus sri: Guess that never happens for me because they talk to services outside of the app
17:14 sri because the same id gets reused, overwriting earlier results
17:15 marcus like a solr backend or redis.
17:15 sri $delay->begin->() is a simple example
17:15 sri mix those in and your app breaks
17:16 sri the question we need to answer is *how* it should break
17:18 marcus can we look at the js implementation we stole from ?
17:18 sri you tell me
17:18 marcus https://github.com/creationix/step ?
17:20 sri i don't think the case is handled there
17:20 marcus guess not. It doesn't seem well maintained either.
17:20 sri so step.js would have broken with the old dns api in node.js
17:21 Pizentios left #mojo
17:22 marcus there's like 15 such modules for node
17:22 marcus this one has 86 issues and 32 pull requests https://github.com/caolan/async/issues :-o
17:22 sri github down :S
17:23 marcus flow actually had a recent commit and not so many issues - https://github.com/willconant/flow-js
17:24 marcus works for me
17:24 sri async seems to push steps into nextTick()
17:24 sri letting the event loop handle timing
17:24 bzero sri: Thank you for prefork. :)
17:25 sri no wait, i'm misunderstanding... it's too complicated for me
17:26 marcus sri: that seems reasonable, but slows things down a bit?
17:27 sri it doesn't work
17:27 sri different problem
17:28 sri let me know if you find something, i still tend towards deprecating and replacing delays with something else
17:28 marcus I have so much code that uses steps:(
17:28 marcus almost everything I wrote the last year or so
17:30 sri then lets find a solution
17:31 marcus yea
17:32 * marcus sets up the batlight
17:32 sri Mojo::IOLoop->delay(sub { Mojo::IOLoop->timer(0 => shift->begin) }, sub { $_[0]->begin->(); Mojo::IOLoop->timer(0 => $_[0]->begin) }, sub { say "BOOM!" });
17:32 sri Mojo::IOLoop->delay(sub { Mojo::IOLoop->timer(0 => shift->begin) }, sub { shift->begin->() }, sub { say "BOOM!" });
17:33 judofyr joined #mojo
17:33 sri those are still the cases
17:33 judofyr delay is going? :(
17:33 sri think about what exactly should happen for both of them
17:33 sri judofyr: see backlog
17:33 * judofyr reads backlog
17:33 marcus judofyr: we have some sharp edge-cases
17:35 sri current behavior: 1) BOOM! the begin->() has no effect 2) nothing, begin->() has no effect
17:35 sri (nehavior after last commit that is)
17:35 sri *behavior
17:36 good_news_everyone joined #mojo
17:36 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/ZYdlMQ
17:36 good_news_everyone mojo/master 14fafc6 Sebastian Riedel: better tests for Mojo::IOLoop::Delay
17:36 good_news_everyone left #mojo
17:37 hesperaux joined #mojo
17:37 sri before... the begin->() could trigger the next step, and the timer would actually happen *after* the next step
17:37 denisboyun joined #mojo
17:37 sri making things fail randomly
17:38 sri ids for ordered results were based on the counter, so depending on when events fired, results would be overwritten
17:38 judofyr begin->() should not invoke the next step right ahead IMO
17:40 sri and indtead?
17:40 sri s/d/s/
17:40 judofyr one solution: initializing the counter to 1; decrement and check if it's 0 after calling the step
17:41 sri i've committed a protection mechanism for that already
17:41 denisboyun joined #mojo
17:41 judofyr and separate ID-counter and pending-requests-counter
17:41 sri already done as well ;p
17:42 marcus so we're good then? ;-)
17:42 judofyr oh
17:42 sri how exactly it should fail is still an open question
17:42 sri Mojo::IOLoop->delay(sub { Mojo::IOLoop->timer(0 => shift->begin) }, sub { shift->begin->() }, sub { say "BOOM!" });
17:42 sri BOOM or no BOOM?
17:43 judofyr BOOM
17:43 marcus yes
17:43 sri and now it gets complicated
17:43 sri this does not work
17:43 marcus no
17:43 marcus :(
17:43 sri the begin->() has no effect, the counter is 0 after the step
17:44 judofyr you already have a ` unless $self->{counter}`-check after invoking the step
17:45 judofyr god, this code is making my head hurt
17:45 sri welcome to my world
17:45 judofyr sub _step
17:45 sri go figure why i'm in favor of deprecating and replacing ;p
17:46 judofyr replacing with what?
17:46 sri something simpler, less features, only ordered results and so on
17:46 judofyr +1 for only ordered results
17:46 marcus do we support non-ordered results now?
17:46 marcus how?
17:47 sri i don't see a deprecation path for removing only parts of it really
17:47 marcus how do we support non-ordered results?
17:47 sri https://github.com/kraih/mojo/blob/​master/lib/Mojo/IOLoop/Delay.pm#L35
17:48 judofyr marcus: $delay->begin; $ua->get("foo", $delay->end)
17:48 sri $delay->end('foo', 'bar', 'baz')
17:48 judofyr oh
17:48 judofyr right
17:49 judofyr so ->get(…, sub { $delay->end(pop) })
17:49 sri whenever you call ->end() it's unordered, order requires my $end = $delay->begin; $end->()
17:49 marcus I've got to put $offspring to bed. Please don't deprecate anything while I'm gone
17:49 marcus Can't we deprecate ->end? I've never used it ;)
17:49 * sri needs food anyway
17:54 sh3 joined #mojo
17:56 suy joined #mojo
17:59 hesperaux joined #mojo
17:59 denisboyun joined #mojo
18:00 hesperaux joined #mojo
18:01 sri btw. another special case $delay->begin->(); $delay->begin->()
18:01 sri you need to take care of not starting two steps
18:16 coff Is there a 'best practice' on how to handle / log surprising crashes in mojo-apps? Since mojo can show an error-page when something goes apeshit I am guessing one could hook into somewhere to get at, and log stack trace.
18:17 coff Any hints? Also; did that line get chopped?
18:24 denisboyun joined #mojo
18:28 moltar joined #mojo
18:35 denisboyun joined #mojo
18:39 mire joined #mojo
18:40 marcus sri: That is retarded code tho.
18:40 sri marcus: it still can happen
18:40 coff We are all retards at some point in the AM
18:41 sri marcus: and if it happens, you get weird timing errors and things fail randomly, impossible to track down
18:41 marcus wouldn't you just get the same step triggered twice?
18:41 sri nope
18:42 marcus joined #mojo
18:42 batman joined #mojo
18:43 good_news_everyone joined #mojo
18:43 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/IRW82Q
18:43 good_news_everyone mojo/master 251b39c Sebastian Riedel: small optimizations
18:43 good_news_everyone left #mojo
18:43 sri marcus: of course we are talking about hypothetical code, since i have no idea how you want to make it work
18:46 marcus sri: For me it works fine now, with the exception of BOOM not happening above.
18:46 marcus sri: I don't care about unordered results, I don't see the need for them.
18:46 sri marcus, tempire, jberger, crab, judofyr, Akron: is everyone in favor of deprecating ->end now?
18:46 judofyr +1
18:46 denisboyun joined #mojo
18:52 sri examples wouldn't have to change much... just ... $delay->begin/$delay->end becoming my $end = $delay->begin/$end->()
18:53 ispy_ joined #mojo
18:55 sri oh wait
18:55 sri ->end doesn't chop off the first argument, while $end->() does, so there's a difference
18:57 Akron joined #mojo
18:58 nelio joined #mojo
19:02 coff Anyone got pointers as to how / where to catch 'unhandled exceptions' to provide logging of such events?
19:11 sri there was an example somewhere in the guides
19:12 Akron How does deprecating ->end effects the problem? Or is it just the questions if unordered results should be deprecated?
19:12 sri Akron: unrelated
19:13 sri just marcus trying to get me not to deprecate delays :)
19:13 marcus it'd make the code simpler.
19:14 Akron Not much.
19:14 sri we are really struggling with explaining delays to people, so i'm all in favor of making it radically simpler
19:14 Akron But yes - I see no real need for unordered results as well.
19:15 sri there is the argument thing though
19:15 Akron It would simplify the examples / documentation.
19:15 sri ->end(...) does not chop off the first argument, which $end->(...) does
19:15 davido joined #mojo
19:16 davido So according to an email I got, dotCloud will be phasing out its free "Sandbox" service, but will be open-sourcing its platform.
19:16 beyondcreed joined #mojo
19:17 sri funny how they make it sound like a good thing for users
19:17 davido yeah, I was trying to figure out how that is supposed to help me.
19:17 davido Now I have to add server costs to development for clients.
19:18 marcus or switch to heroku
19:18 davido exactly.
19:19 suy or to openshift, or to...
19:19 marcus I think even ec2 has a free tier?
19:20 marcus You could set up a free ec2 and run the open source dotCloud thing? ;-)
19:20 marcus see, they are helping you, davido!
19:22 davido Yes, helping me to do one of two things: (1) Deal with all the details that I prefer to avoid.  Or (2) Move to heroku.
19:25 suy And when heroku does the same, what? Move to another proprietary lock-in?
19:46 davido I never considered dotCloud nor Heroku proprietary.  I've been able to write such that migrating is simply a matter of detecting which configuration to use.
19:54 * gtodd plays with bootylicious ...
19:55 gtodd using it as a means of figuring out Mojolicious history and how it works :)
19:57 marcus gtodd: bootylite might give you more
19:57 sri marcus, judofyr: ideas for making begin->() trigger the next step with the right timing would be very welcome
19:57 gtodd and possibly documenting it à la django's famous "life of a request" document  http://www.b-list.org/weblog/2006/j​un/13/how-django-processes-request/
19:57 gtodd django has good docs :)
19:57 gtodd marcus: ok thanks
19:58 sri it's rather annoying that nobody wants to touch the delay code
19:59 gtodd attempting grokking .... bootylicious.pl ends with:
19:59 gtodd app->start;
19:59 gtodd 1;
20:00 gtodd so I can chmod +x it and do ./bootylicious.pl
20:00 gtodd since ... with 1;  ... morbo  bootylicious.pl  or hypnotoad bootylicious.pl  won't work ...
20:01 gtodd so I need to have the last bit of the app just be app->start;
20:01 gtodd but why would someone put 1;  at the end of their script?  isn't that a module/plugin kind of thing?
20:02 gtodd perhaps I'm underestimating the age of the script ... and it follow a version 1.0 best practice or something
20:03 denisboyun_ joined #mojo
20:03 sri it's just bad code
20:04 gtodd hah ok :)
20:05 gtodd I though I'd seen people at perl conferences wearing tshirts with nothing but  1;    so ...
20:06 gtodd or maybe that was:  use Perl;
20:08 gtodd (which really should produce some kind of deep religious linguistic sort of easter egg in perl and not just   Can't locate perl.pm in @INC ...)
20:11 sri if we deprecate $delay->end() we would have to add $delay->begin(0)
20:11 sri to get a callback that doesn't chop off the first argument
20:16 sri ok, if nobody participates i'm going to dictate that it stays exactly the way it is now, documented and tested, there will be a bugfix release soon and no more changes afterwards
20:16 Akron Then ->begin(0)->() == ->end
20:19 Akron The bugfix means your last commits? I'm fine with that.
20:20 Akron As Marcus seems to use delays regularly, he should raise his voice however. ;) But maybe he is just happy with having no deprecation. :)
20:23 marcus I'm happy with that
20:23 sri Mojo::IOLoop->delay(sub { Mojo::IOLoop->timer(0 => shift->begin) }, sub { shift->begin->() }, sub { say "BOOM!" });
20:23 sri that will not go BOOM
20:24 sri it's tested behavior now
20:24 marcus ok, fine.
20:24 marcus and not calling begin breaks the chain, right?
20:25 sri both
20:25 sri only way to keep the chain going is an active event
20:26 marcus fine
20:28 Akron Yes, that's nice.
20:33 jberger joined #mojo
20:33 good_news_everyone joined #mojo
20:33 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/nTB_nw
20:33 good_news_everyone mojo/master 71f6603 Sebastian Riedel: mention that the chain stops when there are no more active events
20:33 good_news_everyone left #mojo
20:33 * jberger is reading backlog online
20:36 * sri ponders adding Mojo::IOLoop->defer(sub {...}) again
20:36 lukep joined #mojo
20:36 sri or Mojo::IOLoop->next_tick(sub {...})
20:38 jberger I imagine that there is a good reason, but why does begin->() chop the leading argument?
20:39 sri invocant of course
20:39 sri my ($delay, $ua1, $tx1, $ua2, $tx2) = @_;
20:39 jberger can't it just push the invocant
20:39 jberger why replace?
20:40 jberger unshift, not push
20:40 * sri doesn't follow
20:40 * jberger is reading up on the internals of ::Delay
20:40 * jberger might not be making sense atm
20:41 jberger https://github.com/kraih/mojo/blob/​master/lib/Mojo/IOLoop/Delay.pm#L12
20:41 jberger no, thats not it either
20:42 jberger hmmm
20:43 robinsmidsrod joined #mojo
20:44 jberger ok so the sub returned by begin closes over the original invocant
20:44 jberger end uses the invocant that is passed
20:45 jberger are these going to be different?
20:50 sri http://mojolicio.us/perldoc/Mojoliciou​s/Guides/Cookbook#Backend_web_services
20:50 sri maybe that explains it
20:54 jberger yeah, that helps
20:54 jberger if you used ->end you wouldn't know if perl or python would show up first\
20:54 jberger s#\#?#
20:55 jberger but you don't get the ua object
20:55 jberger and thats the question
20:56 sri it's perfectly dwim in those use cases
20:56 jberger right
20:56 sri just sucks for using the callback manually instead of ->end
20:56 sri it is not very common to pass arguments to ->end() btw.
20:57 sri very few of our examples do it
20:57 jberger I guess I don't mind begin(0)
20:58 jberger ordered arguments seems very much preferred
20:58 jberger but I can imagine wanting the invocant sometimes
21:01 * gtodd boggles .... so ... many ... site ... that are  X-Powered-By: ASP.NET ...
21:01 suy joined #mojo
21:02 gtodd wow ... I wonder if North Korean hackers keep lists of that sort of thing
21:04 sri jberger: with ->end it would be sub { $delay->end(@_) } since it doesn't return a callback
21:05 jberger right
21:06 jberger but I'm saying I think it makes sense to have ordered arguments
21:07 sri you mean you want to deprecate ->end and replace it with my $end = ->begin(0)
21:07 gtodd what is the easiest way for me to run a mojo app "verbosely" say in the perl debugger so I can see what perl does and where perl goes ...
21:07 jberger yes
21:07 jberger I think it makes sense (from a avoiding confusion standpoint) that begin returns a thing which can end what was begun
21:08 jberger think of it like your delay handle (making up terminology)
21:08 * jberger thinks thats probably bad terminology
21:11 ispy_ joined #mojo
21:14 gtodd played with perl -d ./someapp.pl daemon    but not sure how to do that with morbo
21:14 gtodd oh well
21:14 gtodd more for later
21:34 sri on second thought, lets deprecate Mojo::IOLoop::Delay::end
21:36 moltar joined #mojo
21:43 moltar joined #mojo
21:45 denisboyun joined #mojo
21:46 good_news_everyone joined #mojo
21:46 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/EqYmwQ
21:46 good_news_everyone mojo/master f63ec86 Sebastian Riedel: deprecated Mojo::IOLoop::Delay::end in favor of generated callbacks
21:46 good_news_everyone left #mojo
21:47 sri $delay->begin(0) is now a thing
21:51 jberger damn, I was a second too late
21:51 jberger here was my idea
21:51 jberger http://pastie.org/7320537
21:51 * jberger braces for impact
21:52 jberger grrr
21:52 jberger obiously thats overloading &{} not @{}
21:53 denisboyun_ joined #mojo
21:54 moltar joined #mojo
21:54 sri jberger: that might be overkill
21:55 jberger just a thought
21:55 jberger I don't mind begin(0)
21:56 jberger I was just thinking of it in terms of a step ``handle'' and that led me there
21:56 sri i would be in favor of a special class if there were more attributes/methods
21:56 * sri is not really a fan of thin container classes
21:57 jberger well, I was thinking that you might use that object for storing more things, but this is all I had really thought through
21:58 jberger just spitballing, as is my custom
21:58 * sri appreciates that :)
21:59 jberger time for the commute
21:59 jberger be back in a bit
21:59 jberger o/
22:13 good_news_everyone joined #mojo
22:13 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/ETMPNA
22:13 good_news_everyone mojo/master 3017f01 Sebastian Riedel: better delay example
22:13 good_news_everyone left #mojo
22:18 ispy_ joined #mojo
22:47 ispy_ joined #mojo
22:55 jpn joined #mojo
23:01 denisboyun joined #mojo
23:03 jnbek joined #mojo
23:12 borkur joined #mojo
23:16 hrupp_ joined #mojo
23:21 ka2u joined #mojo
23:22 borkur How can I include local javascript files into my templates, so I don't have to duplicate code?
23:23 borkur I've tried "%= javascript 'file.js'" and "%= javascript '/file.js'" and "%= javascript '/script/file.js'"
23:33 janus joined #mojo
23:36 buu borkur: Have you considered <script> tags?
23:38 borkur "%= javascript 'file.js'" translates to '<script src="file.js"></script>' in the generated html file.
23:44 hesperaux_ joined #mojo
23:47 borkur "%= javascript 'http://code.jquery.com/jquery-1.9.1.min.js'" translates to '<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>' and jquery works fine.
23:50 buu borkur: So how do you access the javascript file you want?
23:52 borkur In a '%= javascript begin' / '% end' block.
23:54 buu borkur: I guess what I meant was, are you trying to include a remote js file? And if you are, what is the url of it?
23:54 borkur No, I want to include a local js file.
23:55 buu borkur: I mean remote in the sense that you're including it via url
23:55 buu Sorry
23:56 buu I mean, can you construct a <script> tag manually that works? And if you can, isn't it easy to translate into %= javascript thingy?
23:59 borkur you lost me... why would I want to  create a script tag manually, since "%= javascript 'file.js'" creates a valid script tag?

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