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

IRC log for #mojo, 2016-08-30

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

All times shown according to UTC.

Time Nick Message
00:59 kaare joined #mojo
01:04 tchaves joined #mojo
01:14 tchaves1 joined #mojo
01:52 zivester joined #mojo
01:57 doc joined #mojo
01:59 doc is it ok to ask questions here about my post?  http://www.perlmonks.org/?node_id=1170750
01:59 doc I don't want to be a pest!
02:03 sri someone wanted to answer you earlier, but you left too fast
02:03 doc sorry, I had to catch a bus
02:05 doc I am understanding how data gets passed and used by the stash.  Can you adjust the stash from within the template?  or is that where you need to use jQuery?
02:11 doc I had tried the taghelper plugin with: "%= submit_button 'validate', id => $file" thinking the id would get set in the stash, but that may not make sense wrt how rendering works.
02:11 doc I'm sorry to be a pest; I am reading and rereading the docs.  And things are moving along for me
02:14 mcsnolte joined #mojo
02:42 noganex_ joined #mojo
02:44 sri this is very odd, just got like two dozen test fails for 7.05 with this http://www.cpantesters.org/cpan/report/928e91ca-6e1d-11e6-8cbd-f4ce58b9f28c
02:49 jberger doc: after the render you don't have server-side features like the stash anymore
02:49 jberger you are now purely client side
02:50 jberger unless you are using websockets or something, but that would be overkill for this
02:56 doc Yes!  That makes sense.  So outside of websockets you must use jQuery for such click actions
02:56 doc Thanks!
03:08 jberger np
03:09 haarg sri: that's my fault kind of
03:10 haarg those reports are smokers that have a dev release of List::Util that has a PP implementation
03:11 haarg which has a slight incompatibility with the handling of @_
03:11 sri oh, the infamous broken List::Util::PP
03:12 sri someone mentioned that here a few days ago
03:12 * sri forgot
03:12 haarg Grinnz_ probably
03:13 haarg he got similar reports on Mojo::DOM58
03:13 asarch joined #mojo
03:17 tchaves joined #mojo
04:44 che-quest joined #mojo
05:14 mpapec joined #mojo
05:21 mpapec joined #mojo
05:39 stefan joined #mojo
05:54 inokenty-w joined #mojo
06:25 Vandal joined #mojo
06:29 mbudde joined #mojo
06:31 margeas joined #mojo
07:09 AndrewIsh joined #mojo
07:47 dod joined #mojo
07:52 dod joined #mojo
08:14 aaannz joined #mojo
08:15 vytas joined #mojo
08:20 cuechan joined #mojo
09:39 osfabibisi joined #mojo
10:12 mpapec YAPC https://youtu.be/2pRf9yu5KVM?t=8039
10:16 romel joined #mojo
11:08 tchaves joined #mojo
11:14 tchaves joined #mojo
12:01 Guest-questX joined #mojo
12:01 gabiruh joined #mojo
12:21 dod joined #mojo
12:24 gizmomathboy joined #mojo
12:47 marty joined #mojo
13:05 dod joined #mojo
13:08 asarch joined #mojo
13:23 sri this one needs more feedback https://github.com/kraih/mojo/issues/988
13:39 jberger re tobi's mailing list post
13:40 jberger I think a thing most people fail to appreciate about fork call (and this is mlehmann's code I'm talking about) is that watching for the close of the return stream takes the place of needing to poll with nonblocking waitpid
13:41 jberger since SIGCHLD is useless
13:42 jberger once you would allow users access to that stream they might close it
13:46 t4nk950 joined #mojo
14:02 zivester joined #mojo
14:30 PryMar56 joined #mojo
14:30 Dandre left #mojo
14:37 tchaves joined #mojo
14:38 bossert joined #mojo
14:42 bossert_ joined #mojo
15:00 orev joined #mojo
15:01 q_gone joined #mojo
15:03 lluad joined #mojo
15:07 cuechan joined #mojo
15:09 Adurah joined #mojo
15:23 Janos joined #mojo
15:46 sri what apple did with their eu taxes is really ridiculous
15:46 sri and that tim cook letter to the public couldn't be any more sleazy...
15:48 CW joined #mojo
15:49 bossert joined #mojo
15:50 jberger and if every other major company hadn't done or at least explored the same option it wouldn't SO obvious what a ploy that tactic was
16:03 sri that's sad
16:03 sri oops wrong channel
16:03 sri jberger just told me his minion fork barely has any minion code anymore
16:04 jberger I gave back the most prominent piece of my minion fork while it was still minion-y
16:04 sri since it's the second such fork, i think i might stop supporting them
16:04 jberger ?
16:04 sri so, don't expect me answering questions anymore
16:05 jberger not helping competitors?
16:05 sri my motivation for being ok with them was to explore new features that can be pushed back upstream to minion
16:05 sri but yea, now you're just competing
16:06 jberger you know my motivations, this is a very different problem space than minion
16:07 jberger it is now written almost entirely in PL/pgsql stored functions
16:07 jberger has to be
16:10 jberger anything that is useful to minion I still will contribute back
16:14 itaipu joined #mojo
16:14 * jberger is sad
16:15 jberger who knows, maybe I can mash it back into the minion backend api at some point
16:16 jberger jobs have several different attributes now though, specifying the jobs is almost completely different
16:17 sri i find it rather demotivating when all bigger installations of minion just turn into custom job queues that have nothing to do with the original anymore
16:19 sri i've not seen that in other communities
16:19 sri is something fundamentally wrong with minion?
16:20 sri is it the lack of a pretty admin ui that makes forks more appealing?
16:21 jberger what other forks are there?
16:21 jberger mine was motivated by the need for job resource locking checks before dequeue
16:21 dotan_convos sri: I think it's that when people start making heavier use of a job queue it's natural for them to look to modify it for their specific use cases
16:22 jberger which basically meant dequeue had to entirely be inside a stored proc
16:24 sri there is also https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Plugin/Gru.pm#L17
16:24 sri and one i've learned about in private
16:25 * jberger reads
16:34 dotan_convos Or if people are already committed to a different database or model layer (DBIC), it might be simpler to use minion as inspiration/copypaste rather than use it directly. Just like I've stolen ideas from Mojolicious for our internal framework. It's probably more annoying when the code is also open source, though
16:35 jberger rewriting minion just because you are DBIC zealots would seem a little on the crazy side
16:36 sri right, open sourcing is where you become competition
16:36 jberger anyway, job parents literally came from my efforts on this project
16:37 sri i still think rate limiting/token buckets could be part of minion
16:39 jberger would you prefer that I not open my queue?
16:40 jberger I don't think they compete on many of the same spectra
16:41 preaction if they copied code, they are in violation of the code's license by relicensing and claiming all copyright...
16:42 jberger I actually don't THINK I have any minion code in mine
16:44 sri not open sourcing would certainly have avoided this discussion ;p
16:45 preaction yes. that's section 1 of Artistic 2. looks like they might not be in violation because of 4.c.ii
16:47 sri i don't want to keep anyone from open sourcing their passion projects
16:48 * sri has very conflicting feelings about this
16:48 jberger well anyway, a release isn't imminent
16:48 preaction artistic 2 is an interesting license now that i'm reading it...
16:48 jberger you've now seen the code, it is really dirty
16:49 jberger brb, lunch
16:51 sri i think this is best summed up as "i don't want to compete with jberger"
16:56 sri jberger: why do you even need resource locks?
16:56 sri you're already got job dependencies
16:56 sri resource locks during dequeue are so insanely expensive
16:57 sri i just can't make sense of it
16:57 sri from what i understand you want to be able to enqueue a bunch of jobs tied to specific servers that only run one at a time
16:58 sri sounds like you could just shift the cost to the enqueue side
16:58 sri say you add job tags to minion, and allow jobs to be searched by tag, each server could be a tag
16:59 sri and before enqueue, you perform a search for that server's tag, and make the last job the parent
17:00 sri of course you have to avoid two jobs being enqueued at the same time, but that's an easy problem
17:01 sri i mean, building a job chain like that based on a tag could even be a special backend operation
17:02 sri performed server side atomically it might not even be that expensive
17:04 preaction will that work for a job that has more than one resource requirement?
17:05 preaction i guess that question is really: can a job have more than one parent?
17:06 sri yes, there is no limit on number of parents
17:07 preaction yep. just went to the docs
17:08 * pink_mist is reminded of "Twins"
17:08 preaction so that creates a chain and then it gets worked through. it'd be possible to splice the chain to insert jobs, though probably a bit annoying. basically we're talking a linked-list now (kind of), or maybe more properly a DAG...
17:08 pink_mist the arnold/devito movie -- iirc they had like 9 dads or something?
17:09 preaction i think i'm happy i don't remember that movie at all
17:09 sri yes, sounds liek a DAG
17:10 sri since you're not allowed to change the parents of existing jobs there's no cycles
17:11 preaction once i insert a job, i can't change its parents?
17:11 sri not from the api
17:12 preaction okay, that might be a problem. one of our requirements is "jumping the queue" to run an important job immediately (though iirc that's more of a soft requirement)
17:13 preaction it would be possible to simply fail a path in the dag and add the new important job and then requeue the jobs that were force-failed though
17:13 sri i mean, you can always add stuff to your fork of the backend
17:13 sri point is, this all fits into an extended version of minion
17:15 sri and shouldn't have much of an effect on performance
17:15 nic preaction: doesn't having a high-priority queue satisfy that requirement?
17:16 preaction nic: not when you add dependencies into the mix
17:16 sri nic: not if it's at the end of a job chain
17:16 nic Do you mean there are circumstances when you want to remove a job's dependencies so it can fire immediately?
17:16 nic Wouldn't you just dequeue and requeue without the hold-ups?
17:17 preaction dependencies are absolute and inviolate. we can _not_ have two jobs running on the same resource, it could render the resource inoperable for 10-30 minutes
17:17 nic yeah, I'm in the same position
17:17 preaction like, it's stupid, but it's reality
17:18 sri funny thing is, this is not even a hard problem to solve ;p
17:18 preaction dequeue, as far as i know in minion, means "prepare to do the thing"
17:18 sri rate limits are much harder than your job chain, which is pretty much just a tiny extension of job dependencies
17:18 preaction so, you could fail the path through the DAG that enables you to do what you want immediately, and then requeue that path
17:19 sri preaction: or have an operation to splice the special job into the chain
17:19 preaction right, but the api does not presently allow that, which we could build our own backend to enable
17:19 sri right, worst case you subclass the Pg backend and add a new method to do it
17:20 preaction exactly. the data structure isn't changing, only the operations that are provided to manipulate it
17:20 sri doesn't even require other methods to be changed
17:21 sri jberger: yea, so your job dependencies patch for minion made this a trivial problem to solve actually ;p
17:23 sri just needs tags and search for tags
17:23 jberger holy backlog batman!
17:24 sri rate limits are an entirely separate problem btw., i'm just mentioning them since that's what i've been reading up on, and they seemed like a possible solution
17:24 jberger have you discussed parallel sequential queues? especially creating them on the fly (ie not spinning up a new worker)?
17:26 jberger that tags and job deps would probably get me pretty close to able to use minion
17:27 nic I'm not sure I want to search for tags if the answer can change before I've acted on the answer I was given
17:27 jberger pretty late in my project I figured out how to do that too btw, named fifo queues are a row in another table and job ids are pushed into a pg array column on the row
17:27 nic ie checking tags and enqueueing with a tag are not atomic
17:27 sri nic: you can easily turn it into an atomic operation though
17:28 nic I DON'T WANT ATOMIC, I WANT NUCLEAR
17:28 jberger nic: I think you mean nuluclar
17:28 preaction nucular?
17:28 jberger dammit preaction you even spelled it right
17:28 sri https://i.ytimg.com/vi/JU-OycAb_Lg/maxresdefault.jpg
17:28 preaction wrongly correct? correctly wrong?
17:29 jberger well, mine wasn't even close :-P
17:30 sri jberger: jobs with the same priority are sequential in minion anyway
17:31 cuechan joined #mojo
17:38 ningu joined #mojo
17:39 ningu with Mojo::Pg, if I call my $db = $pg->db; and then my $tx = $db->begin; is it safe to use $db->dbh to execute all queries within the transaction? I assume the answer is yes but just wanted to make sure
17:39 disputin joined #mojo
17:40 ningu since $db is a container for a dbh, it seems like it must always be the same dbh and therefore the same transaction
17:42 doc joined #mojo
17:42 jberger why do you want to use the dbh directly?
17:43 jberger I'm pretty sure the answer is yes, but if that's what you're doing why not just use DBI?
17:44 Grinnz_ DBI doesn't give you a scoped transaction
17:44 jberger ah true
17:44 Grinnz_ and yeah that should be safe
17:44 jberger that is nice
17:45 ningu jberger: wrapping legacy code, basically
17:50 dod joined #mojo
17:50 jberger sri: the problem with using parents as "fifo queuing" or resource locking or whatever is that then if the parent job fails the later job fails too
17:51 jberger one might argue that that is corrent in some circumstances but it probably isn't always
17:52 jberger anyway, certainly all of this is all up for discussion, and I won't open source mine until more discussion happens
17:52 jberger (and when I would have enough free time, HA!)
17:57 sri maybe it's time to retire minion as a mojo spin-off project
17:57 jberger ?
17:58 sri competing in a contested space is a bit of a waste of resources
17:58 sri i know i will prolly think twice before putting resources into a big minion feature now
17:58 jberger I think that's quite hasty, I know if several projects that are moving TO minion
17:58 jberger including MetaCPAN
17:59 preaction likely cpantesters will be moving in that direction as well
18:00 jberger if there is actual resource splitting I would favor throwing weight behind minion not away from it
18:00 jberger I can't help what I had to develop for $work
18:00 preaction how would i maintain some shared data structures between controller instances? should i use the app for that? or just some package variables?
18:00 jberger preaction: ?
18:00 jberger why would they need shared data?
18:00 sri you know me, i'm terrified of community fragmentation
18:01 jberger don't think of it as that
18:01 Grinnz_ in a single process daemon you can use helpers, if you're going to prefork it you'll need to use something external and databasey
18:01 sri it's what kills stuff in the perl world
18:01 jberger I'm still onboard with minion
18:01 jberger I still hope to do Minion::Monitor, MetaCPAN needs it
18:02 preaction jberger: because every request for a websocket needs to be registered with the rest of the websockets (i'm re-architecting Mercury to be more composable)
18:02 jberger isn't there a central mercury instance?
18:03 preaction Grinnz_: single process luckily. so that means that the app needs something that allows the controllers to share information then? and helper would be better than random package variable our %DATA
18:03 jberger mercury kinda has to be a single process, since it is acting as a broker
18:04 preaction jberger: composable means individual controllers that can be added to your own app, and state-tracking objects that could be used to make your own controllers
18:04 preaction but the controllers need to track the state-tracking, because more state is always amazing
18:04 jberger sounds like you are going the opposite direct that I went for Multiplex
18:04 jberger btw, Multiplex is in working code at $work now
18:04 jberger \o/
18:05 jberger there are a few open questions still, especially around the ambiguity between websocket close and requested unsubscribe
18:05 bossert joined #mojo
18:06 jberger not really ambiguity, but, not having to replicate code that is likely the same but timed differently
18:08 preaction oh, you mean in multiplex
18:08 jberger yeah
18:08 jberger sorry, I hijacked your question :(
18:08 jberger I kinda suck at community today :'(
18:09 dantti_laptop joined #mojo
18:09 preaction no worries. i kind've figured that i'd have to carve a space in the app object
18:09 jberger it seems like an app level property
18:09 jberger with the caveats already mentioned (and well known to you)
18:11 ningu left #mojo
18:11 Grinnz_ preaction: right so it would be a standard helper that accesses a lexical in app startup, or a state variable if you use that feature
18:17 preaction right. so a consuming user will need to $app->plugin( 'Mercury' ); and then set up routing (though i could add some other special plugins to auto setup routing perhaps...)
18:19 sri now i'm wondering why we ever added the queue field to minion instead of tags
18:20 itaipu joined #mojo
18:26 Grinnz_ preaction: most plugins that need routing will add routes themselves, with some configuration to be able to change the route names and such
18:28 jberger I actually have gotten to like the pattern where you can give a string '/path/etc' or a Mojolicious::Routes::Route object and it DTRT
18:28 preaction i'm going for a la carte here. the only reason to not use the default Mercury app is because you want to heavily modify how it works
18:28 jberger because of using under for validation
18:30 ivi joined #mojo
18:59 preaction and more. like i currently want a way to combine a push/pull and a pub/sub into one controller, so that my pushers also send out messages on a sub, so that one privileged worker gets the message (push/pull), but any number of interested parties can see the messages as they flow (pub/sub)
19:48 wippler joined #mojo
19:54 mullagain2 joined #mojo
19:54 cpan_mojo Mojolicious-Plugin-CHI-0.14 by AKRON https://metacpan.org/release/AKRON/Mojolicious-Plugin-CHI-0.14
19:55 cpan_mojo Mojolicious-Plugin-ClosedRedirect-0.10 by AKRON https://metacpan.org/release/AKRON/Mojolicious-Plugin-ClosedRedirect-0.10
20:01 orev joined #mojo
20:28 itaipu joined #mojo
20:50 disputin joined #mojo
20:55 laidback_01 joined #mojo
21:45 meshl joined #mojo
21:46 margeas joined #mojo
22:05 cuechan_ joined #mojo
22:19 itaipu joined #mojo
22:54 zivester joined #mojo
23:07 disputin joined #mojo
23:08 disputin joined #mojo

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