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

IRC log for #mojo, 2018-01-03

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

All times shown according to UTC.

Time Nick Message
00:43 mohawk sri, i updated #1177
00:44 mohawk now ->race also updated to take non-promises (however bizarre that might be)
02:15 FROGGS_ joined #mojo
02:59 ilbot2 joined #mojo
02:59 Topic for #mojo is now 🍩 nom nom | http://mojolicious.org | http://irclog.mojolicious.org | http://code-of-conduct.mojolicious.org
03:00 mib_86sm1y joined #mojo
03:01 mib_86sm1y hello, everyone
03:02 mohawk hi
03:10 mib_86sm1y begin using mojo
03:13 mohawk ok
03:14 jberger You know how you all are always teasing me about the risks of living in Chicago?
03:15 jberger And I always reply that I'm totally safe
03:15 mohawk go on
03:16 jberger Well the I'm not liking the President taunting NK especially where I currently find myself
03:16 mohawk i'm sure he knows what he's doing
03:17 jberger Did you know that for the past free months they now test both a tsunami siren AND a nuclear attack siren? We heard it today coincidentally
03:17 jberger s/free/few/
03:18 mohawk that must be reassuring
03:19 mohawk i for one would hate to think i might miss out on knowing armageddon was coming
03:22 jberger I did ask what should we do if we heard it?
03:23 jberger actually the same thing is kinda true of the tsunami alarm where I'm currently at
03:23 mohawk that one actually makes a little sense
03:24 mohawk because as seen in the documentary "deep impact", you should head for high ground
03:24 jberger Oh it does, just I'm in a place where the only up from the water is basically straight up
03:25 mohawk gotcha
03:25 jberger And there is only one road around the mountain which is already pretty packed
03:25 mohawk yeah
03:28 jberger https://cloud.jberger.pl/apps/gallery/s/fXUJ0uPAynthjKN
03:29 mohawk that was weird, it wanted to save that instead of just show in a browser
03:30 jberger Odd
03:30 mohawk wow, epic scenery
03:30 jberger Yeah. That was our hike a few days ago
03:31 jberger So much epic hiking here
03:32 mohawk where are you?
03:32 jberger Hawaii
03:32 jberger North shore of Oahu
03:32 mohawk surrounded by big water
03:32 mohawk ocean water
03:32 purl i heard ocean water was collected in clouds that snow/rain on mountains that full up water reserves
03:32 jberger Thanks purl
03:33 mohawk when someone says "big water", purl should reply "ocean water"
03:33 jberger Yep, lots and lots of water. Most isolated land mass in the world by some metrics
03:33 mohawk no kidding
03:34 jberger I'm having fun with a 360 camera I bought for this trip. If anyone has a VR headset and wants to look I could share this too
03:35 jberger s/this/those/
03:36 mohawk do we know anyone here who's interested in VR headsets? #trolling
03:36 jberger hehe, true
03:37 jberger https://cloud.jberger.pl/s/A1atSgBPTju8cm9
03:38 jberger 360s are in their own subdirectory
03:38 mohawk CandyAngel, ^
03:41 jberger Call em CC BY 3.0 or so
05:04 dboehmer_ joined #mojo
05:51 Vandal joined #mojo
06:23 marvin_ joined #mojo
06:23 marvin_ hello
06:23 marvin_ everybody
06:23 purl i guess everybody is depraved
06:23 geospeck joined #mojo
06:28 geospeck joined #mojo
06:56 marvinbsd joined #mojo
07:15 Lee joined #mojo
07:24 marvinbsd joined #mojo
07:32 McA joined #mojo
07:49 trone joined #mojo
07:52 Lee joined #mojo
08:21 trone_ joined #mojo
08:36 CandyAngel mohawk: jberger: Woo, VR :P
09:09 CandyAngel Aw, sadtimes. Was going to change this script to Mojo but UA doesn't do ftp
09:13 McA2 joined #mojo
09:20 petru joined #mojo
09:24 dod joined #mojo
09:26 marcus ftp is such a shittttty protocol
09:26 marcus lots of ratholes
09:27 CandyAngel Sure. Unfortunately, all I have access to for this :P
09:28 CandyAngel Never mind, I can use Net::FTP and have a bunch of Mojo niceness around it :D
09:31 dod joined #mojo
10:03 petru joined #mojo
10:24 mohawk does N::FTP do non-blocking?
10:33 tchaves joined #mojo
10:36 CandyAngel Doesn't seem so :(
10:38 CandyAngel Net::Async::FTP might be?
10:39 mohawk one would hope so
10:41 mohawk CandyAngel, if you were feeling brave you could try making it work with Mojo::Promises (it returns a then-able)
10:41 mohawk however i don't know whether it would operate with Mojo::IOLoop
10:50 mohawk arguably Net::FTP (part of libnet) could be crowbarred to being async
10:50 mohawk and then Mojo-ised as a role, modelled probably on this: https://metacpan.org/source/DOTAN/Mojo-UserAgent-Role-Queued-0.04/lib/Mojo/UserAgent/Role/Queued.pm
10:50 mohawk i assume the author of that is dotan_convos
10:50 pink_mist I've tinkered quite a lot on making a Mojo::FTP::Client and Mojo::FTP::Server, but unfortunately I've abandoned those efforts
10:51 mohawk pink_mist, what was the sticking-point?
10:51 pink_mist time
10:52 pink_mist and I think I lost the work in a hdd crash too :(
10:54 mohawk doh!
10:55 CandyAngel I could see how UA could handle it, just like browsers "HTML-ise" it
10:55 CandyAngel Do a GET on a directory, you get a HTML page with a directory listing (for example)
10:58 mohawk sure
10:58 mohawk CandyAngel, what are you trying to achieve?
10:59 CandyAngel Currently, I have a script which does a wget mirror from ftp to a shared drive, then sends an email out with the files it has downloaded
10:59 CandyAngel Just wanted to move it to something more flexible
10:59 CandyAngel So I could, for example, get data out of the files and include that on the email, moves files that are now missing from ftp to an archive directory
11:03 mohawk i would approach this by writing a DSL
11:04 mohawk probably, most lazily, but just defining either perl functions so the DSL was just a simple perl script
11:04 mohawk or, by having an actions spec in say YAML, and reading/executing that
11:04 mohawk part of my #CodeFreeAgenda
11:21 kaare joined #mojo
11:44 dod joined #mojo
12:45 sri yay, perltidy got a lot smarter regarding nested containers https://metacpan.org/changes/distribution/Perl-Tidy
12:46 mohawk #winning
12:46 mohawk sri, did you have chance to look at latest #1177?
12:46 sri briefly, there's a huge inconsistency i think
12:48 mohawk between...?
12:52 sri my $loop = Mojo::IOLoop->new; my $promise = Mojo::Promise->all($promise2, $promise3); $promise->ioloop($loop); $loop->start;
12:52 sri my $loop = Mojo::IOLoop->new; my $promise = Mojo::Promise->all('foo', 'bar'); $promise->ioloop($loop); $loop->start;
12:53 sri assuming $promise2 and $promise3 are also tied to $loop
12:53 mohawk ok?
12:54 mohawk what's the inconsistency?
12:54 purl the inconsistency is the hobgoblin of ... consistent people
12:54 good_news_everyon joined #mojo
12:54 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vbjwH
12:54 good_news_everyon mojo/master b815d56 Sebastian Riedel: the new -wn option of perltidy looks really nice
12:54 good_news_everyon left #mojo
12:54 sri mohawk: one does not work
12:55 sri since you trigger a next_tick on the global ioloop in ->all
12:55 sri not the local one
12:56 sri and that is why i said we need to address the problem of the ioloop attribute before your patch could ever be considered
12:56 mohawk i am confused
12:57 mohawk you said "i trigger a next_tick" in ->all
12:57 mohawk i'm looking at the PR and i don't see it?
12:57 mohawk this is my code/doc: https://github.com/kraih/mojo/pull/1177/files?w=1
12:59 sri mohawk: https://github.com/kraih/mojo/pull/1177/files?w=1#diff-27bd5e0ace07b04f2ba7f5e7ec0115c1R36
12:59 mohawk ok
13:00 mohawk why does that trigger a next_tick?
13:01 mohawk (i can see that it does so in _defer)
13:03 mohawk seems to me that you have decided that Mojo::Promise->all makes a new promise, which implicitly uses the global IOLoop
13:04 good_news_everyon joined #mojo
13:04 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vbjri
13:04 good_news_everyon mojo/master 71777f2 Sebastian Riedel: Revert "the new -wn option of perltidy looks really nice"...
13:04 good_news_everyon left #mojo
13:04 mohawk i happen to agree with that
13:05 sh14 joined #mojo
13:06 sri looks like i bothed that commit, i better sleep some more :S
13:06 sri *botched
13:07 mohawk sri, if you want per-promise IOLoops to work, looks like you need to allow ->all as an instance method
13:07 mohawk and most particularly, add your above snippet as a test-case to avoid accidental breakage
13:08 sri it's not about what i "want"
13:08 sri i don't care about the use case
13:08 sri i don't even want it
13:08 sri what matters is what's "correct"
13:08 mohawk fine
13:09 sri we have to get rid of the ioloop attribute or make everything work with it
13:09 mohawk sri, if you FIND IT MOST CORRECT that per-promise IOLoops to work, looks like you need to allow ->all as an instance method
13:09 mohawk i think the first one is better :-)
13:09 mohawk (first = zap the ioloop attribute)
13:10 mohawk it may make lots of sense in "delay" land, but multi-ioloops isn't really a "thing" in JS promises-land, and it doesn't feel very necessary or natural to me
13:11 mohawk so eg they might be documented to always just use the global singleton
13:13 mohawk this is quite a big issue, so i leave it for you to ponder
13:13 mohawk while i get some food :-)
13:16 sri i'm not going to resolve that i'm afraid
13:16 sri that will have to be done with a vote
13:16 sri it's a big change
13:17 sri needs a deprecation strategy and stuff
13:36 ghenry joined #mojo
14:10 mohawk a deprecation strategy for promises?
14:11 sri for the attribute
14:11 mohawk sorry, i was unclear
14:11 mohawk my thought was the promises are so new that deprecation could be fairly short for this
14:12 mohawk s/the/that/
14:12 mohawk how does one initiate such a vote?
14:12 sri http://mojolicious.org/perldoc/Mojolicious/Guides/Contributing#Rules
14:12 sri rukes say it's always 3 months deprecation period
14:13 sri you can poke the core team members here for a vote, which might be unlikely to succeed without a concrete proposal
14:13 sri or, the right way would be a pull request
14:14 sri good enough to be mergeable, that would automatically trigger a vote
14:15 mohawk who's the arbiter of "good enough"?
14:15 sri if someone from the core team says it's good enough, it usually is
14:19 marcus why is this change needed anyways?
14:19 sri it's about https://github.com/kraih/mojo/pull/1177
14:21 sri mohawk: you should update the description though, the _clone part is no longer true
14:21 mohawk i will
14:22 mohawk done
14:24 mohawk i'll PR a deprecation of ioloop as an attribute now
14:25 marcus Seems like this thing is making the code somewhat more complicated.
14:26 sri mohawk: well, this is how we do deprecations https://github.com/kraih/mojo/commit/28a46cf3cbdc781f02273cfa7c38990d5319d611
14:26 mohawk sri, thanks
14:27 mohawk i was going to use that, but it's not very clear how to deprecate ioloop as an attribute
14:28 mohawk i'm hoping that an overridden, "around" will do the job
14:30 sri you also have to consider the use from subclasses like Mojo::IOLoop::Delay and all uses of Mojo::IOLoop->delay
14:31 mohawk oh dear god
14:31 mohawk they subclass off promise?
14:31 marcus sri: Perltidy -wn looks sweet. Nice that it includes a mojo example as well :)
14:31 sri you get the idea why i said you should have mentioned it earlier :p
14:32 mohawk i get why i'm handy to blame ;-)
14:32 sri marcus: well, i requested it with that example :)
14:32 * sri blames mohawk some more
14:32 * sri sets mohawk on fire
14:33 * marcus opens the alligator pit
14:33 * sri is actually freezing
14:33 sh14|2 joined #mojo
14:33 marcus make a man a fire, and you keep him warm for a day. set him on fire and he's warm for the rest of his life.
14:37 gryphon joined #mojo
14:38 mohawk yay pratchett
14:38 mohawk sri, is there a way to deprecate an attribute?
14:38 mohawk looks like "around" isn't routinely available
14:39 sri pretty sure i've done it in the past, might want to look into the changelog and go from there
14:40 mohawk i'm searching in git log -p -w
14:42 mohawk oh, i just stop it being an attribute and put in some deprecatin' code
14:42 mohawk easy
14:42 sri wait a moment
14:43 sri since $ioloop->delay always attaches the current ioloop to the delay, i'm not sure deprecation is really possible
14:44 mohawk oh, delays will still have an ioloop
14:44 mohawk but promises won't
14:44 sri delays inherit the attribute from promises
14:44 mohawk yes, work with me here
14:44 mohawk so my strategy is to move ioloop to being an attribute only of delay
14:45 sri but how would $ioloop->delay(...)->wait work?
14:45 mohawk the same as it does now?
14:45 sri wait is in Mojo::Promise
14:46 sri inherited by delays
14:46 mohawk good catch
14:46 mohawk so that will also get pushed down one
14:46 mohawk as will anything else using ->ioloop, that needs to
14:47 sri that makes the code really ugly
14:47 mohawk why do you have >1 ioloop in the first place?
14:48 sri to emulate blocking, all blocking methods in Mojo::UserAgent use a second ioloop and are internally still non-blocking
14:49 sri so all the non-blocking features still work, almost all code is shared, you can attach events and stuff
14:49 sri it's actually quite elegant https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L61
14:49 mohawk my gut says there is another way
14:52 mohawk an easier way to get #1177 working would be to de-deprecate the instance method thing, so that your use-case of wanting the right ioloop would be effected with M::Promise->new->ioloop($ioloop)->all(@promises_or_other)
14:52 mohawk if you want to have ioloop as a real attribute, and evidently you do, then ->all (and race) have to be available as instance methods
14:52 mohawk no?
14:52 sri that doesn't work with alternative promise implementations
14:53 mohawk why not?
14:54 sri i mean, if you make the code really really ugly and depect Mojo::Promise objects specifically as the first argument and have another fallback for then-ables i guess it works
14:54 sri but damn, that's ugly
14:54 mohawk if ref $class, $all = ->_clone else $all = $class->new
14:55 mohawk not ugly
14:55 sri and remember, i don't actually want this
14:55 sri it's mostly backwards compatibility for jberger
14:55 CandyAngel Stupid question incoming.. why is Mojo concerned with other Promise implementations?
14:55 sri it's the promises/a+ way
14:55 mohawk the normal thing for promises (and i believe part of the /a+ spec) is to interoperate
14:56 sri you're supposed to accept arbitrary then-ables
14:56 sri which, as of 7.60 we actually do
14:56 sri it's only the stuff mohawk wants to add that requires further changes
14:57 mohawk uhh...
14:57 mohawk https://promisesaplus.com/#the-promise-resolution-procedure
14:58 mohawk i read that as requiring "values" to be then-able or something else
14:58 sri that does not apply for all/race
14:58 mohawk well, that's a matter of debate
14:59 mohawk anyway, i suggest reprecating ->all as instance method, and instead applying my above thought.
14:59 mohawk want me to PR it?
15:00 sri i'm going to abstain from voting
15:00 mohawk i'll take that as a yes
15:01 sri $promise->all($promise2, $promise3) still looks really weird
15:02 sri oh, now i see what you proposed there
15:02 sri M::Promise->new->ioloop($ioloop)->all(@promises_or_other)
15:03 sri the invocant promise would be used as the promise collecting the results
15:03 sri for that you'd have to wait 3 months though, since it breaks the previous behavior
15:04 sri but yea, i agree, that would be much more sensible
15:05 sri you might have missed that $promise->all($promise2, $promise3) was equal to Mojo::Promise->all($promise, $promise2, $promise3)
15:05 sri which was rather shitty
15:07 mohawk not quite equal due to the ioloop thing
15:08 sri exactly equal
15:08 sri literally the same, in both cases it cloned from $promise
15:09 mohawk oh sorry, "was"
15:09 mohawk yes
15:09 mohawk which is where we started :-)
15:11 Pyritic joined #mojo
15:29 mohawk sri, jberger, marcus: https://github.com/kraih/mojo/pull/1179
15:30 mohawk oops, and batman too!
15:32 geospeck joined #mojo
15:32 sri mohawk: why do you want the old behavior back? how is it better than Mojo::Promise->new(ioloop => $loop)->all($promise, $promise2, ...)?
15:33 mohawk ...that's "all" as an instance method?
15:33 mohawk which you just deprecated?
15:33 sri yes, since i released the deprecation earlier, you now have to defend this as a new feature
15:33 mohawk wow
15:34 sri that is ->all as an instance method on a promise used for collecting the results
15:34 sri which i think is a better solution
15:34 Grinnz i still don't like the idea of removing the ioloop attribute from promises, since it means you can never use it within another event loop
15:34 mohawk yes, i'd be happy with that
15:34 mohawk Grinnz, that's not on the table now
15:34 sri only difference is that we can't have it now, and have to wait 3 months
15:35 sri Grinnz: not true
15:35 sri we can change the reactor of the global singleton
15:35 Grinnz ewww
15:36 sri i mean, normally you'd use EV to interoperate anyway
15:36 Grinnz no i mean, like what Mojo::UA blocking requests do
15:36 Grinnz a literal other event loop
15:36 sri sure
15:37 sri maybe you want to join the discussion then
15:37 sri how would we make ->all accept non-promise values with an ioloop attribute
15:38 Grinnz i didnt see the value in making it accept nonpromises
15:39 mohawk JS does it
15:40 dod joined #mojo
15:40 mohawk now to make Mojo::Promise->all work with GraphQL, i have to construct pointless extra insta-resolve promises
15:53 mohawk Grinnz, does that make sense as value?
15:54 ChmEarl joined #mojo
15:58 Grinnz if it didn't complicate being able to set other ioloops
16:02 mohawk it doesn't have to
16:03 mohawk sadly, the 3-month deprecation cycle apparently has to run before the instance-method can be resurrected
16:03 mohawk i assume what sri is thinking, is this time as a non-participant in the final values
16:06 mohawk sri, is that your thinking?
16:07 sri yes
16:07 mohawk huzzah
16:08 mohawk sri, i think a worthwhile addition to ->all right now, would be the docs explaining the array-ref thing
16:09 mohawk because it's basically undocumented at the moment, and a little surprising
16:09 mohawk would you like me to pull that out of #1177 and make a new PR for it?
16:16 jberger I don't have time to consider now, and I'm not sure I'd have the knowledge anyway
16:17 jberger So since sri is abstaining I'll proxy my vote to marcus (haven't seen batman in on this one yet)
16:19 sri jberger: i was abstaining on the other thing
16:19 sri there's now many small things we could vote on
16:19 sri and i have no idea what i'll do
16:19 batman i would like to see a real world example
16:20 jamesaxl joined #mojo
16:20 mohawk batman, of what?
16:21 batman of passing in "something else"
16:21 batman mostly because i'm too dumb to understand the value without it :/
16:21 mohawk i will talk you through it, rather than show code
16:21 mohawk because there's a lot of code in this example, and it's not necessary
16:22 batman can you say anything else than what is already said in the channel/pr?
16:22 mohawk graphql has two types of collection: objects (like a hash) and lists
16:22 mohawk let's find out
16:22 mohawk the values in either of those things could be promises
16:23 mohawk there's an optimisation path that if there are no promises, the object/list just gets returned immediately
16:23 mohawk if there ARE promises, the whole collection has to be promise-ified, using Promise->all
16:23 mohawk clear enough so far?
16:25 batman yes. i get it.
16:25 mohawk if all the things are promises, that's fine
16:25 mohawk if NOT all of them are, then in JS-land it's also fine
16:25 mohawk in Mojo-land, it's not fine because non-promises don't have a "then" method
16:25 mohawk so i have to put wrapper code to make insta-resolve promises for them
16:26 mohawk ...so that Promise->all can immediately promise those to the "all" promise
16:26 mohawk lots of fruitful activity
16:29 petru joined #mojo
16:31 batman it seems like a problem with an alternative solution.
16:36 mohawk i'd love to hear it
16:37 batman need to think :/
16:38 mohawk no rush :-)
16:51 geospeck joined #mojo
17:24 disputin joined #mojo
17:41 mib_jfk7p1 joined #mojo
17:43 batman i forgot to mention, but i found this interesting: https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/
17:50 petru joined #mojo
17:55 dod joined #mojo
18:14 mohawk that was interesting
19:00 FROGGS joined #mojo
19:03 mohawk holy cow, writing scheme takes a lot of staring-at-screen
19:03 mohawk "should i use a vector? or a list?" (one hour of staring)
19:19 mishanti1 mohawk: When I got started with lisp my reaction was "OMG! everything is a list! list all the things!", followed by a whole lot of staring at the screen.
19:19 mohawk mishanti1, are you through that stage yet?
19:19 mishanti1 Not sure what is best; staring before coding or staring in disbelief/confusion afterwards. :p
19:19 mohawk i'm starting to get a bit bolder in manually single-stepping
19:19 mohawk i had an infinite loop earlier which i sorted by doing that
19:19 mishanti1 mohawk: Hah. Not sure if I'm through. Rarely use lisp thes days.
19:20 mishanti1 *these
19:20 mohawk closest i'll ever get to using breakpoints and such
19:20 mohawk fair
19:20 mohawk off by one errors are the worst
19:20 mohawk don't tell anyone, but i just have to experiment to find the right thing, then optionally try to understand why after
19:21 mishanti1 Heh.
19:22 mohawk having got close to using a foldr earlier, i'm now pondering the fewest lines to do a binary search
19:23 mohawk and this is literally all just so my speech bubbles in gimp won't have lots of whitespace on the last line
20:23 ghenry joined #mojo

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