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

IRC log for #mojo, 2017-10-24

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

All times shown according to UTC.

Time Nick Message
00:01 mohawk pink_mist, "if promises are a no-go anyway, what's the point?"
00:02 pink_mist mohawk: yes, promises are a no-go anyway
00:03 pink_mist so why mess with something if it's not going to enable a way forward for promises
00:03 pink_mist there's no point
00:11 gryphon joined #mojo
00:20 mohawk so it's definitely a no-go
00:20 pink_mist that's how I understand things
00:20 pink_mist read the backlog
00:21 mohawk i did
00:28 mib_cl0gza joined #mojo
01:37 EvanCarroll joined #mojo
01:37 EvanCarroll Yoooo!!!! Anyone jump onto cperl?
01:51 jberger haven't seen any interest in this channel, especially since it isn't materially on topic
02:21 noganex joined #mojo
03:52 EvanCarroll joined #mojo
04:04 dboehmer_ joined #mojo
04:25 EvanCarroll joined #mojo
05:01 hesperaux__ joined #mojo
05:39 karjala_ joined #mojo
06:19 rba joined #mojo
06:21 inokenty-w joined #mojo
06:23 rba joined #mojo
06:31 ashimema joined #mojo
06:34 Vandal joined #mojo
06:43 ashimema joined #mojo
06:44 dod joined #mojo
06:51 marcus does mojo even work on cperl?
06:55 AndrewIsh joined #mojo
07:02 rba_ joined #mojo
07:06 kes joined #mojo
07:08 batman sri: i agree with jberger. at least, i think we should have a looooong deprecation periode for this change.
07:08 dod joined #mojo
07:20 sproing joined #mojo
07:39 prg joined #mojo
07:43 trone joined #mojo
08:35 sri pink_mist: why are promises a no-go?
08:36 rba joined #mojo
08:36 ashimema the migration path for that breaking change doesn't look too horrible at least.. so I'm not entirely against it..
08:36 pink_mist sri: huh? it was you who said they were a no-go
08:36 ashimema I've not read back far enough yet to comment on it's worth though
08:37 ashimema `00:01 <pink_mist> if promises are a no-go anyway, what's the point?
08:37 pink_mist 23: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
08:38 pink_mist that sounds to me like promises are killed in mojolicious
08:38 pink_mist a.k.a. a no-go
08:38 sri pink_mist: i was speculating
08:39 pink_mist it sounded pretty definitive to me
08:39 pink_mist and I've not seen you say anything to the contrary since
08:40 sri re my change, a lot of you are missing the big picture, by replacing Mojo::IOLoop->delay with Mojo::IOLoop::Delay::delay i'm opening a way to remove delays from core
08:41 sri that opens a way to add promises as a new concept to mojo
08:42 pink_mist I would support it if promises were added at the same time as the deprecation
08:42 marcus +1
08:42 purl 1
08:43 sri we don't have enough volunteers to do that i think
08:44 marcus what's the benefit of doing this change early?
08:44 sri some people are all talk sadly
08:44 sri it prevents new code relying on Mojo::IOLoop->delay
08:45 sri "WHY WOULD YOU NOT WARN ME IF YOU KNEW THIS WAS GOING TO BREAK!!1"
08:45 pink_mist too much code already relies on it for new code to matter enough
08:46 sri it's funny how nobody actually argues that delays are better than promises
08:46 pink_mist I think jberger did that
08:46 pink_mist unless I misunderstood him
08:47 sri no, he's just annoyed that he has to update so much old code
08:49 rba_ joined #mojo
08:49 marcus It's not clear to me that either approach has significant advantages over the other. Promises do have a lot of adoption tho. What I really want is async / await, which I think is built on top of promises in competing technologies.
08:50 sri can't have async/await without promises
09:01 rshadow joined #mojo
09:06 good_news_everyon joined #mojo
09:06 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdhsg
09:06 good_news_everyon mojo/promises 24d4fd2 Sebastian Riedel: make catch work properly for thenables
09:06 good_news_everyon left #mojo
09:07 good_news_everyon joined #mojo
09:07 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vdhsP
09:07 good_news_everyon mojo/master 82b0f09 Sebastian Riedel: Revert "deprecate Mojo::IOLoop::delay in favor of Mojo::IOLoop::Delay::delay"...
09:07 good_news_everyon left #mojo
09:09 sri i suppose technically the catch fix doesn't even qualify as breakage, since it was always untested
09:09 rba joined #mojo
09:11 sri pink_mist: so, even merging delays with promises is possible again
09:14 pink_mist sri++ I hope someone does manage to bring a good promises implementation to the table
09:14 sri so far nobody who said they'd help has done anything :S
09:18 bobkare_ joined #mojo
09:21 rba_ joined #mojo
09:38 rba joined #mojo
09:39 ashimema joined #mojo
09:45 ashimema joined #mojo
10:49 sri pink_mist: disclaimer: sometimes when i say something is impossible i'm being a bit overly dramatic in the hopes that it motivates people to prove me wrong :)
10:52 sri although, i don't think i'm overly dramatic saying that promises have won already outside the perl community
10:53 sri folks are learning promises anyway, they have all the mindshare, so whatever we do has to go in that direction somehow
11:33 itaipu joined #mojo
12:09 jberger sri I do prefer delays. As I was arguing the other day, they are a very simple rote pattern whereas promises have lots of complexity
12:10 jberger I'll agree that promises have won the war so I'll go along with a change, but don't misunderstand my (current) preference
12:13 jberger Who knows, once forced to learn all the promise patterns maybe I'll like them better but ...
13:47 batman i like delays as well.
13:47 * batman is busy with releases today, so haven't had time to say anything :(
13:49 tchaves joined #mojo
14:09 zivester joined #mojo
14:12 irqq joined #mojo
14:14 ChmEarl joined #mojo
14:27 gryphon joined #mojo
14:38 CandyAngel "Everyone else is doing it" <- seems like a dubious argument. See: everyone else is using Windows
14:40 sri CandyAngel: i'm using linux
14:40 CandyAngel Yeah, but most people aren't, so you should change.. right?
14:40 CandyAngel Hence, dubious argument
14:41 CandyAngel I don't oppose promises (whatever they are), just don't think popularity should be an argument for/against them
14:42 sri technically there should be more linux machines out there
14:42 sri *cough* android *cough*
14:43 sri so, i think i win this troll argument
14:44 sri but it's about doing the right thing, promises have the mindshare, people have to learn them anyway
14:44 sri and async is a hard topic
14:45 sri teaching delays has been tough, it can be a huge barrier
14:45 sri anything that makes teaching event loops easier is good for us
14:52 maschine my opinion is probably not that important - but I've struggled to understand delays personally
14:52 maschine I get the concept, but the implementation is another thing
14:53 perlpilot minor input from the peanut gallery:  +1 for promises
14:54 CandyAngel Okay, I'll keep my "troll" opinions to myself from now on
14:58 sri CandyAngel: no offence intended
14:59 sri sometimes "Everyone else is doing it" is actually a good argument
14:59 sri like when you have to make a hard to teach topic more approachable
15:05 gizmomathboy joined #mojo
15:07 CandyAngel I'm not offended
15:07 CandyAngel But I can't think what adding "troll" was meant to achieve, other than being derogatory
15:07 CandyAngel Omitting it still has the "haha i win" impact
15:08 CandyAngel "Be careful in the words that you choose. We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants."
15:08 sri CandyAngel: well, my android argument was trolling
15:10 CandyAngel Really, I thought it was a brilliant "gotcha" :P
15:10 * sri is currently booking a flight through a mind numbingly stupid enterprise tool and needs let off some steam
15:13 haarg which one?
15:23 sri bcd
15:32 EvanCarroll joined #mojo
15:42 mohawk if only there were a good enterprise travel-booking system
15:42 mohawk someone should write one
15:42 mohawk i've heard of a great web framework that ought to make such a thing super easy! #trolling
15:43 CandyAngel :P
15:43 mohawk btw, sri - you mentioned async/await (i actually prefer explicit promises, but i see the appeal) - "someone should" (yes, i'm volunteering) make that for perl 5
15:44 Grinnz mohawk: leonerd is
15:45 Grinnz and frankly, there's very few people with the knowhow other than him
15:45 mohawk i see someone called "genio" (is that even a real name) has made a gist with discussion
15:45 Grinnz for what async/await requires
15:46 sri mohawk: less volunteering, more doing :p
15:47 mohawk ha ha, i'll see if leonerd wants a hand
15:48 sri genio is part of the mojo family
15:48 mohawk sri, he's also part of the #native family
15:48 mohawk i was ironically noting that he's already part of this async/await business
15:49 Grinnz your sarcasm level might be dialed up a bit much
15:49 mohawk i think you're right
15:49 mohawk sorry
15:51 mohawk sri, soon as i've finished making SQL::Translator automatically generate a mojolicious::lite graphql applet from any sql database and/or dbic setup, i'm going to tackle the async/promise/... thing
15:51 mohawk and the sqlt thing looks surprisingly easy
15:56 sri actually i ended up rage quitting the travel booking tool and am just using email again to book :p
15:56 mohawk dohh ;-)
16:02 mohawk i'm looking at https://metacpan.org/pod/Future::AsyncAwait and thinking "hmm... source filters...."
16:02 Grinnz no, keyword api
16:02 mohawk yes, that's how paul is doing it
16:03 Grinnz mst wrote the source filter version, if you want something self admittedly insane
16:03 Grinnz https://metacpan.org/pod/PerlX::AsyncAwait
16:04 mohawk ha ha
16:04 mohawk i always do
16:05 mohawk paul's one is minimum 5.24 which is a bit steep
16:05 Grinnz yeah, he's focusing on "working" first and "compatibility back to 5.14" later
16:05 Grinnz the first one is pretty tough
16:05 mohawk yes
16:06 ashimema joined #mojo
16:06 Grinnz iirc some of the hooks he's using to make it work are new in 5.24 so it would have to be done differently for older perls
16:07 mohawk back-compat of an already-hard thing is going to be "challenging"
16:09 sri we still don't have a polyfill for sub signatures :(
16:09 sri that would be so damn popular
16:11 mohawk i am soon going to make a source filter (yaaay) to make Function::Parameters syntax available pre-5.14, using Type::Params. bonus is it will even be about 25% faster
16:12 mohawk that ought to do similar to what you're saying?
16:12 Grinnz 1. source filter, 2. Function::Parameters isn't a complete polyfill for signatures
16:12 sri i just want core signatures on old perls
16:12 sri with a source filter
16:12 dod joined #mojo
16:12 sri no more, no less
16:12 Grinnz it breaks the sub keyword in a couple cases, like when you don't specify a signature or when you do 'sub foo;'
16:14 sri technically, i suppose i want for it to use a source filter on older perls, and to activate core signatures on newer perls
16:14 mohawk sorry to be dumb: signature as in sub doo_dah (&$@) ?
16:14 Grinnz no, that's a prototype
16:14 Grinnz sub foo ($bar, @baz)
16:14 sri https://perldoc.perl.org/perlsub.html#Signatures
16:15 sri a good polyfill module would immediately become a hard dependency of mojolicious and we would push for its use in the community :)
16:16 mohawk that actually sounds better and no harder to do than my above crazy plan
16:18 mohawk i think i will have a stab at that after the sqlt thing, then
16:26 genio mohawk: Async/await is something LeoNerd is working on with pluggable keywords. All of my stuff in that regard was just trying to help him get organized so he could focus on getting work done.
16:27 genio in #io-async he and mst discuss progress fairly frequently (mst is working on a pure-perl portion of it)
16:27 genio What I've been working on mostly has been the libUV fun. I'd be very appreciative of any help on that
16:29 dod joined #mojo
16:30 genio and no, "genio" isn't a real name. It was a nickname provided by Brazilian friends during capoeira as a make-fun-of-me situation. It translates to "genius" but wasn't intended in a complimentary way
16:30 genio kind of stuck around
16:31 mohawk ha ha ha!
16:31 mohawk genio, Grinnz shared mst's PP version here
16:31 genio ah, yea, I see that now.
16:32 mohawk is there a convention for polyfills other than Filter::*?
16:32 mohawk i'm thinking the above-discussed crazy notion would be Filter::signatures
16:32 Grinnz whatever makes sense for the syntax
16:33 mohawk which for the right version of perl and above would just import::into the correct signatures
16:35 Grinnz mohawk: also important to keep in mind the core signatures are still considered experimental currently
16:35 Grinnz i presume in case breaking changes still need to be made
16:35 Grinnz it seems pretty stable lately but dunno
16:37 rshadow joined #mojo
16:38 mohawk i did note that
16:38 mohawk i don't mind F::s having to change - it's supposed to be a polyfill, if that's against a moving target then so be it
16:40 Grinnz https://metacpan.org/pod/Filter::signatures already exists, actually
16:41 Grinnz but yeah... source filters
16:41 mohawk ok
16:42 mohawk so sri, does https://metacpan.org/pod/Filter::signatures not meet your need already?
16:44 Grinnz it is very simple, but comes with the unfixable source filter issues
16:44 mohawk sure, source filters have limitations. i made one for gimp-perl and it functioned ok
16:45 good_news_everyon joined #mojo
16:45 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjmP
16:45 good_news_everyon mojo/promises 8de82b9 Sebastian Riedel: start with a clean implementation of Promises/A+
16:45 good_news_everyon left #mojo
16:45 sri that is a fresh start for promises merged with delays
16:46 mohawk sri++ # woo, promises
16:46 sri right now they are in the same module, but share no code
16:46 mishanti1 joined #mojo
16:46 sri i think that's better than fixing the old garbage
16:46 sri now the exercise is to make them work together
16:47 mohawk sri, your thoughts on the signatures polyfill mentioned above?
16:50 sri that might actually be good enough
16:52 mohawk while i'm disappointed not to get the undoubted kudos, i'm pleased if that solves a problem and i'm also pleased to have something to cargo-cult from for my Type::Params bodge
16:52 sri jberger: something for you to look into
16:53 sri wonder if we can activate it from Mojo::Base
16:53 sri i'm no source filter expert
16:55 * sri would really like to see an experiment where Filter::signatures gets added to Mojo::Base and we make the whole core code base use signatures
16:55 sri just to see if it works for a non-trivial code base
16:56 mohawk i'd like that too
16:56 mohawk if jberger is a bit busy i'll have a go?
16:56 gizmomathboy joined #mojo
16:57 Grinnz i would object to enabling it by default in Mojo::Base, since it can break existing code
16:58 Grinnz not just because of the signature thing but because of the source filter issues
16:58 Grinnz (such as listed in those docs)
16:59 sri we could make new variants of our Mojo::Base flags is that's really an issue
17:00 sri use Mojo::Base -sbase
17:00 sri or whatever
17:00 pink_mist -signatures ?
17:00 jberger I'm working so if someone wants to take a look, feel free
17:00 itaipu joined #mojo
17:01 sri i don't really care as long as it's not too terrible to look at
17:01 jberger one thought on the import, we haven't ever had multiple import flags, which we could do
17:01 sri just has to work for all the cases
17:01 jberger use Mojo::Base -base, -signatures;
17:01 sri sure
17:07 jberger If we should make a subnamespace of Filter:: for polyfills, Filter::Fill::
17:07 jberger that way Filter::Fill::signatures could be abbreviated :D
17:08 jberger (kidding)
17:12 trone joined #mojo
17:16 zivester joined #mojo
17:17 trone_ joined #mojo
17:36 dod joined #mojo
17:48 good_news_everyon joined #mojo
17:48 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjcI
17:48 good_news_everyon mojo/promises 96a5717 Sebastian Riedel: steps now settle the promise and wait is based on finally
17:48 good_news_everyon left #mojo
17:48 sri this works surprisingly well
17:49 sri i think the basic design for hybrid delays stands
17:49 sri finally is a real funny case, its callback can return a new promise, but it's not allowed to change the promise value
17:50 sri i stole a lot from stevans Promises btw. should credit him
17:50 sri he got Promises/A+ very right
17:51 sri Promise::Tiny on the other hand is borked i think
17:52 sri maybe i got it wrong, but i think it can't handle multiple ->then calls per promise
17:54 Grinnz meaning on the same promise, creating two different chains?
17:54 sri yes
17:54 Grinnz i dunno if i've ever actually done that, but important to support
17:55 sri "then may be called multiple times on the same promise."
17:55 sri from Promises/A+
17:55 sri it actually changes the whole internal design
17:56 sri i'm really surprised by how little broke https://github.com/kraih/mojo/compare/promises
17:57 rick_soc1 joined #mojo
17:57 rick_soc1 hello hello
17:57 purl o/` hello, hello? are you out there? huh? huh-huh? o/`
17:57 rick_soc1 purl, you are my best friend
17:57 purl ...but purl is <reply> I am a (modified) flooterbuck infobot, and my owner is perigrin.  Download source at http://flooterbuck.sourceforge.net/ or edenc's bitch or espertinho or bugado or stupid. or the mongodb of irc bots or Nuclear Biological Chemical or a big metal dummy. or he mongodb of irc bots or a big fat liar or my favorite robot or delightful today or a nasty woman...
17:58 rick_soc1 oh
17:58 dod joined #mojo
17:58 rick_soc1 we can't be friends anymore, sorry
17:59 sri jberger, marcus, batman: i think hybrid promises are now feature complete, please review
18:01 rick_soc1 hi jberger
18:01 rick_soc1 I'm watching your vuejs mojolicious video right now
18:03 itaipu joined #mojo
18:11 rick_soc1 I think it's going to take me awhile to get the hang of vue
18:26 good_news_everyon joined #mojo
18:26 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdj4U
18:26 good_news_everyon mojo/promises 21d79e5 Sebastian Riedel: add some documentation for promise methods
18:26 good_news_everyon left #mojo
18:27 sri ok, that's covered too now, most of it is actually stolen from the mozilla docs
18:27 sri which are excellent
18:27 sri i tried looking at the google docs... and nearly got a heart attack
18:29 sri not sure if ->race and ->all should be class methods
18:29 sri i mean, we need to assume the first argument is a Mojo::IOLoop::Delay anyway
18:29 sri so...
18:30 sri (because of the ioloop tied to the promise)
18:30 sri promises/a+ require a lot of next_tick calls
18:33 sri i'm comfortable with merging the branch now
18:36 sri the promise api could use some dedicated examples though
18:38 karjala_ joined #mojo
18:44 sri we could take it one step further and add $ua->aget, $ua->apost and friends
18:45 sri which would return a promise
18:50 rick_soc1 What big feature are you working on?
18:51 rick_soc1 more async support in mojo?
19:01 good_news_everyon joined #mojo
19:01 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjuW
19:01 good_news_everyon mojo/promises 16733a8 Sebastian Riedel: show how to wrap a continuation-passing style API with promises
19:01 good_news_everyon left #mojo
19:01 jberger rick_soc1: hope you enjoy it
19:01 sri rick_soc1: yes
19:01 sri https://github.com/kraih/mojo/pull/1141
19:01 jberger yes, there's a small learning curve, but IMO its the shallowest curve (and supported by the best documentation) available in the problem space
19:03 sri bet nobody will realize how elegant the new ->wait is
19:03 sri s/realize/notice/
19:04 jberger sri: neat
19:06 jberger so the callback to catch doesn't take the invocan't anymore?
19:06 jberger hahah s/'//
19:07 good_news_everyon joined #mojo
19:07 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjzO
19:07 good_news_everyon mojo/promises 19f245b Sebastian Riedel: mention how steps relate to the promise
19:07 good_news_everyon left #mojo
19:07 rick_soc1 jberger: I've been watching the vue community on twitter and I like how active it is and it seems anybody who uses it really likes it
19:07 sri jberger: yea, it's the smallest of breakages
19:07 sri and technically not a breaking change, since it was never tested
19:08 jberger I'm not too upset by it, but we are going to have to announce that somehow
19:09 jberger will this be a major version release then?
19:09 sri no
19:09 jberger I don't see how we deprecate that?
19:10 sri technically it's not a breaking change, i'm fine with that, and i want to keep the next major version if we notice big mistakes
19:10 jberger I know your definition of breaking requires that there was a test in our test suite, and yet how on earth was a use to know that?
19:10 jberger their code is going to break
19:11 jberger s/use/user/
19:11 sri you really want to kill the feature over that?
19:12 jberger no, I want to tell the users about it
19:13 pink_mist is mentioning it in the Changes file sufficient?
19:15 jberger consider the pattern ->delay(sub{ doit() }, sub { my ($delay, $err, $res) = @_; die $err if $err; $delay->$cb(undef, $res) })->catch(sub{ shift->$cb($_[1]) })->wait
19:15 irqq joined #mojo
19:16 jberger if doit has an exception, it dies, the catch handler is invoked, it calls the same callback $cb with the error in the error slot
19:16 jberger except it calls it with $_[1], which is now undef
19:16 jberger so the user code looks like it got a success
19:16 sri by all means... "This was not strictly a feature ... but a side effect of this class inheriting a method... change .... to .... if you find this in your code"
19:17 good_news_everyon joined #mojo
19:17 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjgV
19:17 good_news_everyon mojo/promises 1e83833 Sebastian Riedel: fix typo in description
19:17 good_news_everyon left #mojo
19:19 EvanCarroll joined #mojo
19:20 jberger could we wrap the callback passed to catch to correct the arguments? add a deprecation message if you want suggesting using "resolve"
19:21 jberger then after the deprecation period the arguments change
19:21 jberger the fact that it wasn't a "feature" doesn't mean we can't still offer a deprecation
19:22 sri umm, you were the one arguing earlier for *one* change for our users instead of *two*
19:22 sri quite loudly
19:22 jberger hunh?
19:22 sri you're on your own now
19:22 jberger I don't even know that that has to do with this?
19:23 jberger look I'm not trying to be combative, I'm trying to prevent user code that was an error from becoming a success unexpectedly and without any warning
19:23 sri "02:10 <jberger> But don't make everyone fix all of their nonblocking code more than once"
19:24 jberger they're going to have to change their code as a result of this
19:24 jberger I'd like them to know that they have to
19:24 jberger that's all I'm saying
19:25 jberger they can silence a depreaction warning by using ->then directly
19:25 jberger I'll write the code for it if you don't want to
19:25 jberger its a pretty simple wrapper
19:28 gizmomathboy joined #mojo
19:34 pink_mist sri: I'd suggest changing all the "fulfillment"/"fulfills"/... to "resolve"/"resolves"/... instead ... since ->resolve() is the name of the method
19:35 sri pink_mist: it's taken from the spec
19:35 sri i didn't make up the terminology
19:35 pink_mist ah, well I'd say the spec should be changed then, but that's unlikely to happen :P
19:37 sri well, i wish you good luck :)
19:46 jberger sri: this is intentional? (to suppress a return value I guess?) https://github.com/kraih/mojo/pull/1141/files#diff-892d699369fe9beca14818a2019adc36R54
19:49 rick_soc1 jberger: I don't think my mibbit pm option is working, but in case it is sorry for the double request - can I shoot you an email?
19:53 jberger sri: actually the fix is trivial? could we just fix it rather than break it?
19:54 jberger am I wrong or is the fix: sub catch { my ($self, $cb) = @_; $self->then(undef, sub { $_->$cb(@_) }) }
19:55 jberger oh sorry, I misread _defer
19:59 jberger sri: http://paste.debian.net/992596/
20:09 karjala_ coulnd't you do a check "if catch follows a promise, then don't issue warning"?
20:09 karjala_ follows a then, I mean
20:09 karjala_ typo
20:57 EvanCarroll joined #mojo
21:10 sri oh, i have a cool idea for the promise example
21:12 good_news_everyon joined #mojo
21:12 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjM2
21:12 good_news_everyon mojo/promises 43a73ac Sebastian Riedel: let Mojolicious race MetaCPAN
21:12 good_news_everyon left #mojo
21:12 sri that actually shows composition
21:12 sri same way two delays with steps can be combined now
21:13 Grinnz actually even moreso, since the current combination can only do more like ->all
21:13 sri yea
21:13 sri i wish there was a better name for ->all
21:13 sri $mojo->all($cpan) looks a little weird
21:13 Grinnz future's equivalent is needs_all
21:14 sri as a class method it would suck
21:14 Grinnz at least if i read correctly that it fails upon any failure
21:14 sri Mojo::IOLoop::Delay->all($mojo, $cpan)
21:15 sri nobody wants to type that
21:15 EvanCarroll joined #mojo
21:15 Grinnz is that a name from the promises spec?
21:16 sri yes, the js spec
21:16 sri we do differ in some regards already though
21:16 sri ->reject and ->resolve are both promise generators in the js spec
21:17 sri js promise constructor is a little awkward to use
21:18 Grinnz future kinda does that, i think; ->done and ->fail as class methods create an immediately resolved future
21:18 sri Promise->new(sub { my ($resolve, $reject) = @_; $resolve->(...) })
21:18 Grinnz unless i'm misinterpreting
21:18 sri and yes, this is the time for bikeshedding method names :)
21:19 sri the implementation is good, we just have to pick the right color
21:19 Grinnz i'm mostly just used to the future names :P
21:20 sri i'm not a huge fan of those :p
21:20 EvanCarroll joined #mojo
21:20 sri right now i'm just trying to pick the names that most people will recognize
21:20 sri so, a little js focused
21:28 Grinnz what happens if an already rejected promise gets ->resolve called on it?
21:28 Grinnz just thinking without cancellation, thats what could happen if ->all(...) gets rejected by one and then others resolve later
21:28 sri promises/a+ says nothing is supposed to appen i think
21:30 sri there are still many cases that could use tests
21:30 sri we will follow promises/a+ though, if our behavior is different we will adjust
21:30 sri and things like ->finally will be according to the js spec
21:32 EvanCarroll joined #mojo
21:36 good_news_everyon joined #mojo
21:36 good_news_everyon [mojo] kraih pushed 2 new commits to promises: https://git.io/vdjSD
21:36 good_news_everyon mojo/promises 523007c Sebastian Riedel: test early resolve and reject
21:36 good_news_everyon mojo/promises 13c627a Sebastian Riedel: the state of a promise cannot change
21:36 good_news_everyon left #mojo
21:37 sri this example makes me really happy https://github.com/kraih/mojo/pull/1141/files#diff-1c16334ff36c3caec7a1a3a0a1fd912cR412
21:37 sri we couldn't do that before
21:48 jberger you know
21:48 jberger you could take that example and use the roles features too
21:48 jberger make a role that adds aget
22:01 EvanCarroll joined #mojo
22:06 irqq_ joined #mojo
22:17 karjala_ joined #mojo
22:23 good_news_everyon joined #mojo
22:23 good_news_everyon [mojo] kraih pushed 1 new commit to promises: https://git.io/vdjdW
22:23 good_news_everyon mojo/promises 5998731 Sebastian Riedel: more promise tests
22:23 good_news_everyon left #mojo
22:26 pink_mist is there something similar to ->all that just gives you the results of all promises after they're all done (whether fulfilled or rejected)?
22:26 Grinnz no, that would be the equivalent of Future's wait_all
22:28 Grinnz currently ->all is like needs_all and ->race is like wait_any
22:29 pink_mist right
22:30 Grinnz the fourth is needs_any which is like ->race but only completes when the first one succeeds (or if all of them fail, it fails)
22:31 pink_mist oh, I thought race would be like that rather than like wait_any
22:31 Grinnz these seem useful to me abstractly but the hard part is probably naming them
22:32 sri lots of opportunities to make Mojo::IOLoop::Delay::Role::* modules :)
22:32 Grinnz also true
22:32 Grinnz i could make a role that gives it all Future names :P
22:33 sri indeed

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