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

IRC log for #mojo, 2017-10-23

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

All times shown according to UTC.

Time Nick Message
00:04 Grinnz huh, Promises without a hard dependency on AnyEvent might actually be useful
01:15 mohawk zomg mojolicious plugin <-> graphql <-> graphql-js tutorial idioms! http://blogs.perl.org/users/ed_j/2017/10/graphql-perl---graphql-js-tutorial-translation-to-graphql-perl-and-mojoliciousplugingraphql.html
01:16 aborazmeh joined #mojo
01:16 mohawk vaguely constructive criticism welcome as always :-)
01:18 itaipu joined #mojo
01:19 jberger Raw xhr in a tutorial, that's hardcore
01:21 jberger It's ok if you know and made this choice, but do you know that use Mojolicious::Lite implies strict and warnings?
01:22 jberger While plack middleware are allowed they aren't recommended because they don't work with the mojo nonblocking servers
01:23 jberger Or I should say it forces you to a psgi server and thus you don't get the mojo "real time" features
01:24 jberger I haven't read through the examples yet but those are my initial thoughts
01:25 mohawk jberger, i just translated theirs to have the right fieldname! don't hit me :-)
01:26 mohawk i didn't know the implied strict/warnings, will zap in a moment
01:26 mohawk is there a mojo authenti-doodah?
01:50 mohawk i lmgtfy-ed myself and found some pointers
01:54 mohawk jberger, incorporated your points (and credited people on the channel here with helping)
02:06 jberger meanwhile I pushed my change for relative urls so now its down to a super cute test https://github.com/jberger/Mojo-Chrome/blob/master/t/tester.t
02:07 mohawk noice
02:22 noganex_ joined #mojo
04:04 dboehmer joined #mojo
05:39 inokenty-w joined #mojo
06:01 [1]mohawk joined #mojo
06:30 salva joined #mojo
07:00 AndrewIsh joined #mojo
07:02 dod joined #mojo
07:09 dod joined #mojo
07:13 Vandal joined #mojo
07:16 pirateFinn_ joined #mojo
07:31 rba joined #mojo
07:48 karjala_ joined #mojo
07:52 trone joined #mojo
08:06 rba joined #mojo
08:14 dod joined #mojo
08:41 rba joined #mojo
08:44 rshadow joined #mojo
09:01 prg joined #mojo
09:11 dod joined #mojo
10:12 sri re promises, this is actually an interesting way to write ->then https://metacpan.org/source/HATZ/Promise-Tiny-0.02/lib/Promise/Tiny.pm#L58
10:13 sri it follows the js promise api a little too closely though
10:29 marcus sri: It's certainly rather easy to follow.
10:50 tchaves joined #mojo
11:09 kes joined #mojo
12:11 itaipu joined #mojo
12:57 AndrewIsh joined #mojo
13:03 gryphon joined #mojo
13:19 gizmomathboy joined #mojo
13:27 tcohen joined #mojo
14:04 VVelox_ joined #mojo
14:08 ChmEarl joined #mojo
14:33 rba_ joined #mojo
15:06 Pyritic joined #mojo
15:34 zivester joined #mojo
16:04 dod joined #mojo
16:21 maschine joined #mojo
16:32 gizmomathboy joined #mojo
16:50 rba joined #mojo
17:04 bwf joined #mojo
17:07 trone joined #mojo
17:19 rshadow joined #mojo
17:30 Pyritic joined #mojo
17:49 Pyritic joined #mojo
18:01 Pyritic joined #mojo
18:25 jacoby joined #mojo
18:34 gizmomathboy joined #mojo
18:57 itaipu joined #mojo
19:03 sri interest in promises seems to be vanishing
19:07 sri interesting this is a thing in js now https://developers.google.com/web/updates/2017/10/promise-finally
19:09 sri raises an interesting problem
19:09 sri ->then and ->catch would be inconsistent
19:13 sri that might end up killing promises in mojo
19:23 Peppard joined #mojo
19:26 gizmomathboy joined #mojo
19:30 rick_soc1 joined #mojo
19:31 rick_soc1 hola
19:32 rick_soc1 anybody here give the "toto" plugin a try?
19:33 rick_soc1 I'm looking at generating menu links and this one came up in a search, I don't see any alternatives
19:47 Pyritic joined #mojo
21:05 sri yea, i think there is no way around this https://github.com/kraih/mojo/issues/1139#issuecomment-338796243
21:09 jberger that's just attaching a fail handler right?
21:09 jberger that's fine (I think)
21:10 jberger its hard for me to comment since I'm not versed in Promises
21:13 sri attaches a fail handler and returns a new promise
21:18 sri it breaks a test https://github.com/kraih/mojo/blob/master/t/mojo/delay.t#L238
21:19 sri who would have thought that something as simple as adding a ->catch convenience method to Mojo::EventEmitter would some day kill promises in mojolicious
21:19 sri weird how these things go sometimes
21:24 sri unless someone can prove me wrong this failed now https://github.com/kraih/mojo/issues/1139#issuecomment-338801011
21:25 sri and we are back to the question of how to fix delays in other ways
21:26 jberger I still don't think there are any problems with delays
21:27 jberger but admittedly I'm a fan of them so I'm probably not the right voice
21:28 sri people pass them around, that needs fixing
21:29 jberger if anything that sounds like documentation then
21:29 jberger if Delays can't be made to fit the Promise pattern, could we just also provide a Mojo::IOLoop::Promise (or whatever name) that is just a different tool (and leave Delays alone)
21:30 sri so, how would you change the docs?
21:30 jberger "don't pass them around because they aren't composeable"?
21:30 jberger heh
21:30 jberger kidding
21:31 jberger I guess I need to get off my butt and redo my talk from MojoConf about patterns for Delays in abstract functions
21:32 jberger everything about that talk is out of date, from the presentation software to the examples that it uses
21:32 sri hmm, another possibility is to just ignore promises and make delays composable anyway
21:32 jberger but the concepts are still largely correct and since then I have a lot more experience in actually using them
21:32 jberger true
21:33 jberger I personally find that making each nonblocking method take a callback and contain a Delay, and those methods may call other methods that contain a Delay works just fine
21:33 jberger but perhaps that's not everyone's taste (and clearly that's not the case because people do other things)
21:33 Grinnz I didn't find that to be sufficient
21:34 jberger because of setting a toplevel timeout (and/or cancelling)
21:34 jberger ?
21:35 Grinnz and all the repetition
21:35 Grinnz if i screwed up any level i wouldn't have proper error handling
21:35 jberger fair point, the repetition gets old
21:36 jberger but as I said the other day, the decreased complexity makes that palatable for me (may not for others)
21:36 Grinnz Future made it more of an abstract endeavor, whereas doing it with delays seemed like grunt work
21:37 Grinnz thats just how it felt to me
21:37 sri btw. i'm against having delays and promises as separate concepts in mojo
21:37 sri competing concepts make for very confused users
21:38 sri we either find a way to merge them, or embrace one
21:38 Grinnz not to mention Future turned out to be a lot like what i was starting to homebrew in my irc bot at the time, before i even made it all Mojo
21:38 Grinnz (event emitter was also quite useful there, so i simplified some things with that)
21:39 sri Grinnz: how do you rewrite this cookbook example with promises? http://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Synchronizing-non-blocking-operations
21:41 Grinnz it's my understanding that promises don't have the same features or names as Future, i could only tell you how to do it with Future
21:43 sri that's fine
21:44 sri i'm open to promise extensions that address the usual shortcomings
21:47 Grinnz something like... https://perlbot.pl/p/hhnf8c
21:49 sri Grinnz: no, i mean without changing the user agent api
21:49 Grinnz well i don't know how that would look
21:50 sri the whole point is to work well with continuation passing style apis
21:50 Grinnz it's always nicer looking when everything is returning futures, thats why i abstract that part away
21:51 sri jberger: i am going to deprecate Mojo::IOLoop::delay
21:51 sri doc changes are not going to fix the problem, delays have to become a utility
21:54 Grinnz more like this then https://perlbot.pl/p/283apf with probably some weakening needed depending how new_future and adopt_future were implemented
21:58 Grinnz i would have a utility function that created a new future and ran the useragent method, returning that future after whatever appropriate operations on it
22:29 good_news_everyon joined #mojo
22:29 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vdpwN
22:29 good_news_everyon mojo/master bc9b000 Sebastian Riedel: deprecate Mojo::IOLoop::delay in favor of Mojo::IOLoop::Delay::delay
22:29 good_news_everyon left #mojo
22:29 sri i know this will be controversial, but i think it's necessary
22:32 * sri pokes jberger, marcus and batman
22:59 jberger I disagree with this change. It doesn't actually fix any problem and breaks just about every usage in the wild
23:01 kiwiroy joined #mojo
23:01 pink_mist I'm with jberger
23:01 pink_mist if promises are a no-go anyway, what's the point?
23:02 jberger Plus Mojo::IOLoop has several convenience constructors so I don't see any inconsistency in having one for delays
23:43 kiwiroy joined #mojo
23:46 mohawk pink_mist, that's a bit self-fulfilling?
23:50 pink_mist mohawk: huh?
23:55 kiwiroy joined #mojo

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