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

IRC log for #mojo, 2017-03-06

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

All times shown according to UTC.

Time Nick Message
00:00 dave sri: thank you for Mojo::JSON::Pointer!
00:16 batman sri: I'm not sure about what move_to() and copy_to() should return. I don't know how often I would need the target instead of the invocant :/
00:17 batman i think it sounds consistent to return $self, but that will be very annoying if $to is often used afterwards, and $self is thrown away.
00:19 stryx` joined #mojo
00:55 lluad joined #mojo
01:04 aborazmeh joined #mojo
01:37 sugar_ joined #mojo
01:44 jnbek joined #mojo
02:21 lluad joined #mojo
02:28 stryx` joined #mojo
02:56 VVelox joined #mojo
03:15 noganex_ joined #mojo
03:32 sugar_ joined #mojo
03:41 PryMar56 joined #mojo
04:20 preaction i would think that i could $path->copy_to( $dest )->append( 'new information' ); and it would write to $dest. that seems to read well to me
04:33 Lee joined #mojo
04:48 inokenty-w joined #mojo
05:04 dboehmer joined #mojo
06:18 polettix joined #mojo
06:54 dod joined #mojo
07:01 lonerr left #mojo
07:21 polettix joined #mojo
07:23 Dandre1 left #mojo
07:36 Andreas joined #mojo
07:37 Vandal joined #mojo
07:53 AndrewIsh joined #mojo
08:10 polettix joined #mojo
08:39 trone joined #mojo
08:53 rshadow joined #mojo
09:00 coolo joined #mojo
09:01 rshadow joined #mojo
09:03 jnbek joined #mojo
09:05 coolo joined #mojo
09:05 marty joined #mojo
09:07 dod joined #mojo
09:10 sugar_ joined #mojo
09:12 sivoais joined #mojo
09:13 kes joined #mojo
09:14 dod joined #mojo
09:28 prg joined #mojo
09:33 mermi joined #mojo
09:33 mermi Are there manners associated with the name of keys a plugin uses?
09:34 mermi I assume I should stick to snakecase(everything-after-::Plugin::), but is that a thing?
09:55 kes that is up to you
09:59 kaare joined #mojo
10:13 prg jberger: i guess you're still asleep. last friday you said you had a suspicion about what was going on?
10:24 mermi kes: Not really, if others use it, it's kinda up to them ...
10:24 mermi which is you!
10:26 kes I use camelcase
10:30 mermi with the things all named after your plugin?
10:42 sri re Mojo::File::copy_to/move_to return values, my first instinct is also to expect a Mojo::File object for the new file
10:43 sri but on second thought, isn't the argument already a Mojo::File object for the destination anyway?
10:43 sugar_ joined #mojo
10:44 sri i mean, how often do you have the destination path as a string and don't need to generate it?
11:09 haarg it still seems more useful to return a Mojo::File for the destination
11:11 haarg if move_to returns the source, there's very little useful you can do with the return value
11:11 haarg if it returns the destination, you can chain various things off of it
11:36 rshadow joined #mojo
11:36 dotan_convos joined #mojo
11:39 dotan_convos joined #mojo
11:46 rshadow joined #mojo
12:12 sugar_ joined #mojo
12:23 pink_mist the same is not true for copy_to though - returning the original would make just as much sense as returning the target for that one, if not more
12:23 pink_mist haarg: ^
12:25 haarg i feel like the destination would still be a more useful return value for copy_to, but very weakly.
12:26 haarg i don't think there are any super compelling reasons to pick one over the other if you are considering only copy_to.  staying consistent with move_to is much more important.
12:29 dod joined #mojo
12:38 aborazmeh joined #mojo
13:02 khfeng joined #mojo
13:15 dod joined #mojo
13:40 itaipu joined #mojo
13:41 sugar_ joined #mojo
13:41 bwf joined #mojo
13:51 howitdo joined #mojo
13:58 * sri nods
14:16 Pyritic joined #mojo
14:44 jberger prg I do have a suspicion, but I don't know what to do about it
14:47 jberger The problem is that the worker fork finishes the job which triggers a notification
14:47 jberger Which it itself is scheduled to receive
14:47 jberger But before it does the worker fork goes away
15:03 prg i see
15:04 prg i kinda solved my problem, but i abandonded Minion::Notifier in the process
15:05 prg let me grab a quick smoke and then i can tell you about my solution
15:16 prg so, i basically implemented setup_listener() and setup_worker() from Minion::Notifier by myself, with a "hardcoded" transport
15:17 prg which suffered from the same problem
15:17 prg but it went away when i stopped reusing Minion's Mojo::Pg object
15:18 jberger prg: can I see what you did?
15:19 jberger gist or some other paste site?
15:19 prg hold on, let me pastebin it. it's not in a public repo
15:19 prg yeah, let me try that gist thing, never used it before
15:19 jberger pastebin has those horrible video ads on top
15:19 jberger gist is nice cause its actually a git repo under the hood
15:20 prg i just see "consider going pro" ads on pastebin ;)
15:21 jberger I'm the last otherwise-sane person that doesn't use an ad blocker
15:22 prg secret or public gist?
15:23 jberger I'd say public unless you need the privacy
15:24 prg nah, nothing confidential in there, i scrubbed it. but the code is kinda dirty :/
15:24 jberger up to you
15:25 nic http://paste.scsys.co.uk/mojo
15:27 prg https://gist.github.com/prg/5cec40f198b8a0bd9bceaac8185aacd0
15:27 prg formatting is a little bit screwed up due to copy&paste
15:30 prg i guess something similar could be done for Minion::Notifier by instantiating a new Mojo::Pg object instead of reusing Minion's
15:32 prg but i don't know enough about this stuff, so i have no idea what the ramifications are
15:39 rshadow joined #mojo
15:40 sh14 joined #mojo
15:47 jberger sri: I think I need to run Mojo::Pg::PubSub->_cleanup after the job/worker forks
15:47 jberger I haven't actually tested that but its the only thing that makes sense
15:48 sri jberger: if you need Mojo::Pg changes make sure to explain them detailed enough, i don't have time for much research
15:49 jberger I will
15:49 jberger I'm still digging
15:49 jnbek joined #mojo
15:51 prg jberger: let me know if i can help
15:55 sugar_ joined #mojo
15:56 jberger prg: in your test, can you add $job->minion->backend->pg->pubsub->_cleanup; as the first line in your task definition and see if that works?
15:56 jberger (note that this is evil in a few ways, but it would confirm what I suspect)
15:58 prg seems to work
15:59 jberger and actually I think I might have a way to do it in Minion::Notifier safely actually
16:00 prg yay \o/
16:06 lluad joined #mojo
16:07 jberger I wonder if Minion::Notifier should emit the start event
16:07 jberger it would essentially immediately follow the dequeue event so I don't know
16:07 jberger nah, I'll leave it as-is
16:14 * sri has built a frankenstein keyboard with a corsair k65 base and keycaps from 3 different keycap sets :)
16:15 jberger sri: so the problem is that the fork-safety code doesn't run until you do something with the pubsub object
16:16 orev joined #mojo
16:16 jberger but since it is already subscribed to notifications it really needs to do that
16:16 jberger calling $job->minion->pg->pubsub->_db is all I need to do
16:17 jberger I can do it on the start event, but it probably should be Minion::Job that does that
16:17 sri jberger: ah, i knew there was a bug
16:17 sri but never figured out how to fix it
16:18 jberger honestly I think this is the same problem I had trying to make an ioloop-based worker timer for my job queue
16:20 jberger I think the closest to a no-op that I can do using public methods is ->unlisten('ThisNotificationDoesNotExist')
16:29 jberger hahaha, emitting that start event is actually enough to fix it :D
16:30 jberger annoying though, because from the perspective of anything subscribed, the dequeue and start events are effectively the same thing
16:31 jberger I could cheat and move the dequeue emit in notifier into the start callback of the job
16:31 jberger the timing is slightly different but it fixes my bug
16:32 jberger ah no but it breaks the tests
16:32 jberger nm, dummy unsubscribe fixes it too
16:38 Pyritic joined #mojo
16:38 gizmomathboy joined #mojo
16:39 zivester joined #mojo
16:51 jberger sri: can we make Mojo::Pg::PubSub::_cleanup public?
16:53 dod joined #mojo
16:54 jberger I guess the other thing I could do would be to: delete $job->minion->backend->pg->{pubsub} but even though we've tacitly approved that kind of thing before, I still don't like it
16:57 jberger then for Minion to handle this for Minion::Backend::Pg users automagically, I guess Minion::Backend would need a sub cleanup {} that Minion::Backend::Pg could implement
16:58 jberger and call it after the Mojo::IOLoop->reset in the child-side of the fork
17:08 PryMar56 joined #mojo
17:16 kaare joined #mojo
17:24 trone joined #mojo
17:35 jberger hmmm, now I'm thinking against deleting it
17:35 jberger it something else has a reference to it, then it isn't destroyed and thus isn't cleaned up
17:38 dod joined #mojo
17:41 prg i'm confident you'll come up with a good solution :)
17:41 prg gotta go now, i'll be back tomorrow. bye
17:43 jberger bah
17:43 jberger I'm literally just releasing the fix for prg
17:43 jberger and they leave
17:51 jacobydave joined #mojo
17:58 asarch joined #mojo
18:16 itaipu joined #mojo
18:18 FROGGS joined #mojo
18:27 itaipu joined #mojo
18:29 irqq joined #mojo
18:42 sh14|2 joined #mojo
19:01 sugar_ joined #mojo
19:12 itaipu joined #mojo
19:17 bwf joined #mojo
19:24 sri jberger: so $pg->pubsub->reset?
19:25 jberger sure
19:26 sri no, i'm asking you :p
19:26 sri for a proposal
19:27 jberger yes, I guess reset is the name we've settled on, so my proposal is to take _cleanup and rename it reset
19:27 sri and i suppose to get rid of the other fork stuff
19:27 jberger ?
19:27 sri since it doesn't appear to work
19:27 jberger it does work
19:27 jberger you just have to call something in order for it to work
19:28 jberger if you subscribe to something, then fork and never need the pubsub again, you never anything that calls _cleanup
19:28 sugar_ joined #mojo
19:28 jberger I literally just need a way to call _cleanup that doesn't do anything else
19:28 sri you cant have ->reset and https://github.com/kraih/mojo-pg/blob/master/lib/Mojo/Pg/PubSub.pm#L40
19:29 jberger why not?
19:29 jberger it would just call ->reset
19:29 sri if it works then you don't need ->reset
19:29 jberger but you had to call something to do it
19:29 sri then it doesn't work!
19:29 jberger that works most of the time, for most people
19:30 sri what's the point if it only works sometimes, and other times you have to call ->reset
19:30 sri that's silly
19:30 sri i won't do that
19:31 sri one clean solution will get accepted, two half working ones not
19:32 sri it does not work as described here https://github.com/kraih/mojo-pg/blob/master/lib/Mojo/Pg/PubSub.pm#L95
19:33 jberger perl doesn't have an on-fork callback mechanism
19:33 jberger zomg ....
19:33 jberger wanna hear an insane idea
19:33 jberger Mojo::IOLoop->fork
19:33 sri i think some people redefine fork() to make one ;p
19:33 jberger hahahha
19:34 sri i mean, it's not even the worst idea ever
19:35 sri that's what CORE::fork is for, isn't it? ;p
19:35 jberger http://irclog.perlgeek.de/mojo/2014-01-26#i_8178303
19:35 irqq joined #mojo
19:36 sri jberger's law doesn't apply here
19:36 jberger I have a law \o/
19:36 sri it's not crazy if it was intended to be used that way!
19:37 jberger true, I'm just surprised you don't think its crazy :D
19:38 jberger but it would finally give people the on-fork they've always wanted, which has typically been done by Mojo::IOLoop->next_tick(sub{ ... }) assuming that the manager process doesn't start the loop
19:38 sri $ioloop->on(fork => sub {...}) would be kinda neat
19:39 sri does CORE::fork go back to 5.10.1?
19:40 genio 5.8.0
19:40 genio according to perldoc perlfork
19:41 genio wait, no. I spoke too soon. as of 5.8.0, fork emulation has considerably matured.
19:42 genio 5.6
19:42 pink_mist genio: that's not the question
19:43 pink_mist genio: fork() has always worked
19:43 pink_mist genio: whether there was a CORE::fork is different
19:48 haarg CORE::* has existed since 5.000 at least
19:48 pink_mist yes, but not everything was in CORE::
19:48 genio oh, I thought all functions in perlfunc were in CORE::
19:49 pink_mist there are still loads that aren't
19:49 pink_mist take print for example
19:50 haarg print is in CORE::
19:50 pink_mist hmm, really?
19:51 jberger I think you can't take a reference to some of them, but I don't think that's the same as them not being there
19:51 haarg taking a reference to CORE functions is somewhat new, but calling them by CORE:: has always been there
19:52 pink_mist oh, ok
19:55 haarg getting subrefs to CORE functions was added in 5.16, but not for all functions
19:56 Pyritic joined #mojo
19:57 pink_mist that sounds like it must have been what I was thinking of
19:58 haarg also a call to fork will always resolve to the CORE:: version unless you predeclare with use subs
19:59 haarg if you have a sub fork in your module, you'll get warnings and it won't get called
19:59 haarg and fork can't be overridden with CORE::GLOBAL::
20:28 sugar_ joined #mojo
20:46 sri bummer
20:50 sri jberger: do you have a test case?
20:51 jberger I could extract one out of the Minion::Notifier stuff
20:51 jberger which level are we talking about here?
20:51 jberger Mojo::Pg::PubSub?
20:51 sri https://github.com/kraih/mojo-pg/blob/master/t/pubsub.t#L128
20:53 jberger kinda hard to adapt that test
20:54 jberger what it needs is for the process to listen, then fork, then the parent notify and have the child not hear (or actually corrupt) the notification
20:54 jberger since you are just localizing $$ there not really forking, and as soon as the "child" calls notify everything is ok again
20:55 sri seems trivial
21:01 sri can't you just notify from another db handle?
21:04 jberger in the same process?
21:09 marty_ joined #mojo
21:14 Pyritic joined #mojo
21:16 howitdo joined #mojo
21:19 jberger well of course now I can't recreate in a minimal test
21:19 jberger as usual
21:20 jberger sigh
21:21 sri well, i've done this now https://github.com/kraih/mojo-pg/commit/df9e83b897c4f4dbf9060c51ddbe6167b22b0476
21:22 jberger I have an idea of what I'm not doing for this test ...
21:22 * jberger looks
21:22 sri the attempt at fork safety is gone, since it doesn't work well
21:22 rshadow joined #mojo
21:23 Grinnz that could cause a lot of issues
21:23 sri it's not like it worked
21:26 sri don't get me wrong, i'm not opposed to the feature, but you have to make it actually work
21:28 sri in fact, the current behavior caused problems for jberger and prg
21:29 haarg sri: bummer?
21:29 purl yeah, that sucks
21:34 jberger this becomes less and less clear for me the longer I can't replicate in small scale
21:34 jberger if that change I made to Minion::Notifier didn't fix the problem I'd be doubting myself at this point
21:34 jberger but it does
21:48 Pyritic joined #mojo
22:08 Janos joined #mojo
23:05 kaare_ joined #mojo
23:14 stryx` joined #mojo
23:36 jberger sri: I'd rather wait on that change
23:36 jberger I can't replicate and I'm getting less and less confident in my reasoning
23:36 jberger I'd like to see prg confirm that my fix (which works in my tests) fixes their real-world application
23:37 jberger my tests might be rather contrived
23:37 jberger I can't quite tell anymore
23:39 pink_mist haarg: I assume the bummer was that CORE::GLOBAL::fork wouldn't work
23:57 nicomen If unsure, add tests

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