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

IRC log for #mojo, 2017-11-03

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

All times shown according to UTC.

Time Nick Message
01:05 aborazmeh joined #mojo
01:47 gordonfish joined #mojo
02:37 EvanCarroll joined #mojo
02:56 ilbot2 joined #mojo
02:56 Topic for #mojo is now 🍩 nom nom | http://mojolicious.org | http://irclog.mojolicious.org | http://code-of-conduct.mojolicious.org
02:58 batman sri: i would prefer if there was a way to instruct the methods to be in "promise" mode... like use Mojo::IOLoop::Delay 'P'; $p = $ua->get(..., P);
02:58 batman i know that looks awkward, but i just don't want to "pollute" all mye APIs with extra promise methods :/
03:15 batman jberger: typo s/phantom/chrome/ https://github.com/jberger/Mojo-Chrome/blob/master/lib/Test/Mojo/Role/Chrome.pm#L112
03:15 batman and here https://github.com/jberger/Mojo-Chrome/blob/master/lib/Test/Mojo/Role/Chrome.pm#L161
03:16 batman could you also add chrome_result_like() ?
03:16 batman not sure why detect_chrome_executable() is public
03:21 jberger I need it public (or public-ish) for use in the Build.PL file
03:22 jberger the thing about chrome_result_like and other tests ... I ALMOST decided to use the Test2 version of "is" which would make that super easy
03:23 jberger but I decided that would be inconsistent with the rest of the Test::Mojo methods
03:23 batman do you? can't you just do Mojo::Chrome->new->chrome_path ?
03:23 batman do you = do you need detect_chrome_executable() to be public
03:24 jberger I guess so but that would be awkward because i'd have to throw in an eval
03:24 batman ok.
03:24 jberger I don't want the Build.PL to die, that's not how cpantesters works with this stuff unfortunately
03:26 jberger interesting notions about combining the host+port
03:27 noganex joined #mojo
03:32 jberger I guess I'm interested to think about combining the arguments, but there is kinda some weird correlation
03:33 jberger the likely combinations are 'port or host and port' indicating a local or remote running chrome
03:33 jberger or startup options (which will likely usually be just the default of --headless)
03:34 jberger combine that with the fact that Mojo::URL doesn't actually handle just a port very well, so it would have to be '//:5000' or so to work correctly
03:34 jberger is there a protocol for this? would it be 'chrome://localhost:5000'?
03:34 jberger I know chrome uses chrome:// internally
03:35 jberger but is that what Mojo::Chrome could/should use?
03:40 jberger I almost wonder if I should get rid of the host entirely, are people actually going to use a chrome on another host?
03:43 jberger heh, and I don't even let you install it if you don't have a chrome on your local host so those two things are a little at odds with each other
03:46 batman i think you should allow that. pretty sure it's fine to run chrome inside a docker instance and then connect from another test runner
03:46 batman allow that = install the module without chrome present
04:01 batman and why not use `http://localhost/?--headless` and if host is "localhost" and no port is present, then spawn..?
04:01 disputin joined #mojo
04:09 disputin joined #mojo
04:12 batman _spawn() can then add the port
04:34 jberger so the problem with allowing to install without chrome present is I basically can't run any tests then
04:35 jberger hmmmm, that's a tough one
04:35 Grinnz any database client meant to connect to external servers kinda has the same problem unless they can mock a server up
04:38 jberger true
04:38 jberger many of those still need a client library or something though
04:38 jberger but you're right that's actually kinda the case
04:39 Grinnz funny enough mysql has the least problem with this, because it doesn't have a client library you can install without installing the server (lol)
05:04 dboehmer_ joined #mojo
05:04 sh14 joined #mojo
06:02 inokenty-w joined #mojo
06:10 EvanCarroll joined #mojo
06:41 Vandal joined #mojo
06:43 Peppard joined #mojo
07:14 kes joined #mojo
07:17 marcus sri: Yeah, stevan confirms it's all Yanick now.
07:18 marcus batman: I think the whole 'P' thing is a lot more awkward. I think promises is the way forward, and not an option to enable.
07:24 batman yeah... don't want to go in that direction, was just throwing out an idea instead of silence.
07:27 batman and there's no way we can do $p = p $ua->get(...) or something like that? (p is a function)
07:27 batman i guess it would do some `local $Mojo::WANT_PROMISE = 1` which is ugly as well...
07:28 batman (and it won't work)
07:33 marcus I guess the alternative would have been a subclass. my $ua=Mojo::UserAgent::Promise->new; $ua->get('....')->then(...);
07:37 batman hard to get people over i think... same with Mojo::UserAgent->with_roles("+Promise")->new(...);
07:39 anparker I tried to make role that overrides start method to return promises.
07:42 dod joined #mojo
07:47 dod joined #mojo
08:00 dod joined #mojo
08:09 EvanCarroll joined #mojo
08:16 AndrewIsh joined #mojo
08:37 rshadow joined #mojo
08:45 trone joined #mojo
10:12 cosimo joined #mojo
10:13 marcus Have to say my rewritten delay code looks a lot better as promises. Less code inside callback.
10:14 CandyAngel marcus: Would you be able to show a before/after?
10:14 CandyAngel I would be interested to see as I've not used promises before
10:15 marcus CandyAngel: I'll try to include some examples in the promises writeup I'm doing this weekend, hesitant to show the stuff I'm working on as it's work code.
10:15 CandyAngel Sure, I understand :)
10:19 sri batman: the decision for ->*_p methods has been made
10:20 sri it's the only sensible way
10:20 sri no matter what, you want blocking and non-blocking APIs next to each other anyway
10:21 sri no point making things ugly
10:31 tchaves joined #mojo
11:14 kes Sebastian, may I comment on #1148 about the work I have done?
11:14 kes on #1148 issue
11:16 sri kes: i would recommend against it, unless you have confirmation from someone here that your fix is correct
11:17 kes I have asked, but nobody take the review for the patch
11:18 sri that's a bad sign
11:18 sri you can't force people to look at your changes by posting them in the github issue
11:19 sri if they don't look at them here, chances are even lower on github
11:20 sri for me, i stopped looking at the gists you linked to when you started conflating multiple issues
11:20 sri that gives me headaches
11:21 sri wouldn't be surprised if others felt the same
11:21 kes I do not want to force. I want point my changes. Maybe that willbe useful for someone.
11:23 sri the issue right now is fine, and i'm sure at some point someone will find a fix
11:24 sri if you post half finished code, perhaps mixed with fixes for other things you're working on, or bad comments, you risk derailing it
11:24 sri i'm not saying that to be rude, that's just what happened over and over in the past
11:25 kes so may you please answer one question?
11:27 karjala_ joined #mojo
11:27 sri i don't know unless you ask
11:27 kes For my patch I get failed tests because it is not possible create two instances of lite mojolicious applications
11:27 kes here is testcase: https://gist.github.com/KES777/1f5fafe6b4c61091e18d4d4b8e90cd2b
11:27 kes is this a bug or it is designed in such way?
11:27 sri you're doing it again
11:28 sri we were talking about one issue and you force another issue on me
11:28 sri now you're just being rude
11:29 kes sorry, but the first one is blocked by this
11:29 sri i'm sorry, but unless someone else here confirms your problem is valid i will not be looking at your issues anymore
11:30 kes I can not continue, if I hear answer about lite apps. (
11:30 kes ok. thank you.
11:30 kes Please anyone look this: https://gist.github.com/KES777/1f5fafe6b4c61091e18d4d4b8e90cd2b
11:31 kes I wanna to know is this OK that two instances of lite application can not be created
11:40 rshadow joined #mojo
11:47 diegok o/ I will be doing a talk about the mojo::* stuff this saturday for the `barcelona, perl & friends` conf. I'm trying to follow all this "promises" and trying to pick the new stuff so I can show some, but what I'm most worried about is not to show too much code that wont work in further releases... is there something related to ioloop, delay's and async UA that will stop working in the near future?. I'm
11:47 diegok already checking my examples with last version and last docs...
11:47 sri diegok: there are no more changes planned
11:47 sri besides what's already deprecated and removed from the docs
11:48 sri i'll prolly replace some more cookbook delay examples with promises, but that's just docs
11:48 diegok thanks sri!, I will try to follow last commits so I don't miss last deprecations...
11:49 sri deprecations are all in the Changes file
11:49 diegok right! :)
11:49 sri always
11:50 diegok I have to finish the async slides this afternoon... looks like I'll have a long night :-)
12:14 ChmEarl joined #mojo
12:18 jberger kes recall that in my first example working with you on this, I used bare a Mojolicious app as the mounted app
12:18 jberger That's because you can only have one lite app
12:20 jberger In tests and examples using bare Mojolicious apps is an easy way to get one off apps
12:25 anparker kes: It works this way - https://gist.github.com/anonymous/2447fab3e1588c8450c04c4a21a3eba1
12:30 kes anparker: that is because you query different lite app
12:39 kes It also will work if you declare Lite app in the end of file without code change
12:40 kes just like this: https://gist.github.com/KES777/1f5fafe6b4c61091e18d4d4b8e90cd2b   (compare revisions)
12:45 haarg because it isn't actually using the /l[12]/addr that you intend
12:46 haarg because the /addr route in the Lite app doesn't exist when you are trying to access it
13:07 tcohen joined #mojo
13:09 tcohen joined #mojo
13:10 rickbol joined #mojo
13:13 sri hmm, this would also work nicely with a promise http://mojolicious.org/perldoc/Mojo/IOLoop#subprocess
13:14 marty joined #mojo
13:31 aborazmeh joined #mojo
13:35 Pyritic joined #mojo
13:42 geospeck joined #mojo
13:55 Pyritic joined #mojo
14:21 karjala_ While you're at it, maybe you could have subprocess send optional progress updates to the master process (so a websocket can notify the user)
14:21 jberger That isn't as easy as you might think, but also it is something you can do on your own
14:22 jberger open a pipe (or IO::Pipely) before calling subprocess
14:22 karjala_ I think there *is* a pipe there
14:22 karjala_ waiting already
14:23 karjala_ so maybe it is easy after all. Can I try creating a proof-of-concept?
14:23 jberger there is (remember I'm the one that wrote Mojo::IOLoop::ForkCall, which Subprocess is based on (full disclosure, I took the idea from AnyEvent))
14:23 karjala_ a PR?
14:23 purl well, a pr is Pre-Release or Public Relations or proportional representation or pull request https://help.github.com/articles/using-pull-requests
14:23 jberger when that pipe is used, it indicates that the subprocess is done
14:23 jberger there is a timing problem using it for anything else
14:24 karjala_ timing problem?
14:24 jberger its a big reason that you don't need to check the process with waitpid regularly
14:24 jberger the pipe acts as a close signal
14:24 jberger with other subprocess modules (say batman's ReadWriteFork) you have to monitor the child
14:24 karjala_ Can't you change the protocol of communication that uses the pipe?
14:25 karjala_ so that id doesn't act as a close signal anymore?
14:25 jberger what is the close signal then?
14:25 karjala_ by you, I mean anyone
14:25 karjala_ look:
14:26 karjala_ through the pipe, you will pass data structures instead of plain data
14:26 karjala_ like {type: 'close'} or {type: 'progress', data: {blabla}}
14:26 karjala_ wouldn't that do?
14:26 karjala_ does that answer your question?
14:27 karjala_ if type === close, then it's a close signal
14:27 jberger that would at least massively increase the size and scope of the module
14:28 jberger I also think it would make it more fragile
14:28 jberger but lets say it was possible
14:28 jberger how does the child address it? there is no infrastructure for the child to address the parent directly
14:29 karjala_ why would it make it more fragile?
14:29 karjala_ i mean why do you say that?
14:29 jberger look how simple this is: https://github.com/kraih/mojo/blob/master/lib/Mojo/IOLoop/Subprocess.pm#L31-L32
14:30 jberger build up a ton of message framing and parsing, events, hooks, and some way to address the parent, its going to get bigger
14:30 jberger and with more code is more chance to get it wrong
14:31 jberger look, I'm not saying don't go proof of concept on your own, fork the module and add more communication
14:31 karjala_ ok
14:31 karjala_ :D
14:31 jberger if it works and is a great fit, maybe we incorporate it, like ForkCall was incorporated
14:32 karjala_ I'll try to make the changes as tiny as possible
14:32 karjala_ While being still readable
14:33 karjala_ thanks for considering my proposal
14:34 jberger I wish you luck, but having done a similar thing a few times, I think you're going to find it harder than you expect
14:34 jberger but it certainly will be an interesting endeavor, have fun with it
14:34 jberger most of my modules start like that (indeed so did ForkCall)
14:37 sh14 joined #mojo
14:47 karjala_ jberger: Maybe it's hard after all
14:48 karjala_ But not infinitely so
14:49 vicash joined #mojo
14:50 jberger no, not infinitely so
14:50 jberger but pretty soon you start looking at schemes that are more like ReadWriteFork
14:51 jberger a more interactive system
14:52 jberger where Subprocess is trying to be as tiny and opaque as possible
14:52 jberger "make this code not block"
14:53 karjala_ Maybe a plugin would be more appropriate place for what I'm asking then?
14:53 jberger again, before you get too far, try just opening a pipe before subprocess and using that
14:53 karjala_ aha ok
14:53 karjala_ yes you're right
14:54 karjala_ I mean, maybe I should make a plugin that does subprocess_2 or whatever
14:54 jberger I could imagine a tiny module that manages pipe communications and maybe message framing
14:54 jberger it wouldn't even have to be a plugin it could just be complimentary
14:55 jberger my $pair = Mojo::IOLoop::PipePair->new;
14:56 jberger and in the child say, my $handle = $pair->writer # closes reader returns write handle
14:56 jberger and in the parent a similar method that closes the writer and adds the reader to the ioloop
14:56 jberger there are ways to make that all easier
14:57 CandyAngel This sounds suspiciously familiar
14:57 jberger that's just off the top of my head
14:57 CandyAngel I'm sure I've done something like that before
14:57 disputin joined #mojo
14:58 CandyAngel I think I got it so the parent/child could communicate, but then never knew when the child closed
14:58 sri if it's good enough i'm ok with having it in core
14:58 sri but it needs to be very clean code and 100% solid
14:59 CandyAngel Oh yeah
14:59 CandyAngel It was to work around the time limit in Windows
14:59 CandyAngel https://irclog.perlgeek.de/mojo/2017-08-22#i_15057159
15:19 gryphon joined #mojo
15:27 jberger sri: what you would think about adding a `use Mojo::Base -role;` flag?
15:28 jberger loading Role::Tiny into the caller and (more importantly to me) exporting has without setting the base class
15:28 jberger see https://github.com/jberger/Mojo-Chrome/blob/master/lib/Test/Mojo/Role/Chrome.pm for my current mechanism
15:33 CandyAngel That might help with CookieJar::Role::Persistent too?
15:38 sri jberger: neutral
15:38 jberger ok, maybe I'll take a try at it and see how it would work/look
15:40 Grinnz sounds neat to me
15:41 jberger if someone beats me to it, by all means
15:41 jberger I need to keep $working so it wouldn't be at least until tomorrow probably
15:42 jberger honestly I could live without it importing Role::Tiny, but importing has without setting ISA would be really nice
15:43 Grinnz um, isnt importing Role::Tiny the whole point
15:43 jberger that said, doing both would seem a little more semantically correct
15:43 jberger IMO not really, but I'm ok being wrong on that too
15:44 jberger look at the schenannigans I'm going through to add attributes to Test::Mojo::Role::Chrome
15:44 jberger that's what I'm trying to avoid
15:45 Grinnz i think it makes sense to do both
15:45 Grinnz i cant think of a reason other than roles that you'd want has without the Mojo::Base parent
15:48 jberger and we've basically chosen Role::Tiny as our role system given that it drives with_roles
15:49 Grinnz any other role system is going to have its own has(), probably
15:49 Grinnz like Moo::Role
15:53 ghenry joined #mojo
15:58 karjala_ joined #mojo
16:12 diegok I'm just playing around promises... in my examples, having IOLoop->timer(3) returning a promise would make a lot of sense. Probably the same will happen with subprocess :-)
16:16 Grinnz yes i find https://metacpan.org/pod/Future::Mojo#new_timer very useful so a promise equivalent would probably be as well
16:17 Grinnz i also added a version that rejects after the specified time, but apparently never released that
16:18 EvanCarroll joined #mojo
16:21 Grinnz and released
16:23 diegok Grinnz: nice reference, thanks.
16:25 Grinnz heres a case where i use it to delay repeated requests to pastebin.com's shitshow of a service https://github.com/Grinnz/maverick/blob/bb94e9d145e001d9db366fa3f8b79e5c96178e93/lib/Bot/Maverick/Plugin/Repaste.pm#L93-L102
16:25 Grinnz (timer_future is a wrapper around new_timer)
16:50 mohawk Grinnz, would it be more in line with sri's naming scheme to call it new_timer_p?
16:52 Grinnz new_timer is a Future::Mojo method, not really relevant
16:52 Grinnz just a similar interface
16:52 Grinnz the existing method on Mojo::IOLoop is ->timer
16:53 Grinnz it wouldn't even necessarily need a separate method, since it has no blocking version
16:56 mohawk fair enough
16:57 mohawk at some point i need to get my head round whether Future and Promises are interchangeable in Mojo-land
16:57 mohawk not yet had opportunity :-(
16:58 Grinnz they are different approaches to the same general goal
16:59 sri Promises are generally promises/a+ compatible
16:59 sri Futures are something leonerd made up
16:59 sri similar, not compatible
17:02 sri i've not actually tried mixing Mojo::IOLoop::Delay with other promise implementations
17:02 sri theoretically anything reasonably promises/a+ compliant should be compatible
17:02 sri but...
17:03 sh14|2 joined #mojo
17:03 garo joined #mojo
17:14 garo joined #mojo
17:26 good_news_everyon joined #mojo
17:26 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vFcIo
17:26 good_news_everyon mojo/master 5886c71 Sebastian Riedel: use promises everywhere in the documentation
17:26 good_news_everyon left #mojo
17:29 Grinnz sri: since that first example isn't using the delay helper anymore, does it need a ->render_later?
17:30 sri there is no template to render
17:30 sri so no
17:30 sri render_later is only important if there's something that could be auto rendered
17:42 Pyritic joined #mojo
17:42 dod joined #mojo
17:54 Seth joined #mojo
18:16 Pyritic joined #mojo
18:21 rshadow joined #mojo
18:22 jberger I'm usually paranoid and explicitly render_later anyway, but yeah, not super necessary
18:29 disputin joined #mojo
18:32 trone joined #mojo
19:10 EvanCarroll joined #mojo
19:20 Pyritic joined #mojo
19:43 sri thinking about it some more, i guess promises don't really work for subprocess
19:44 sri since we planned ahead for future extensions
19:44 sri with it returning an object and all
19:45 sri messaging support is a real possibility
19:45 sri $subprocess->on(message => sub {...})
19:46 sri $subprocess->send({foo => 'bar'})
19:46 sri from the subprocess to the original process
19:49 Grinnz you could still manually set a promise to resolve when the subprocess completes
19:51 sri of course
19:52 sri also teaching that now in the cookbook http://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Synchronizing-non-blocking-operations
20:33 gordonfish joined #mojo
20:48 kaare joined #mojo
21:11 mib_1dh9vz joined #mojo
21:16 jacoby joined #mojo
21:26 Grinnz sri: https://github.com/kraih/mojo/commit/5886c718d56001b9d53bc62441c759d24e64a1cb#diff-b659d9bfeffa6b78a1f2950c7e72259bR552 should probably be ->all($mojo, $minion)
21:36 sri Grinnz: no
21:37 Grinnz no?
21:38 Grinnz doesn't it need to wait on both to get both results?
21:48 Grinnz same thing in later example
21:52 Grinnz i dont understand why this would work either https://github.com/kraih/mojo/blob/master/t/mojo/delay.t#L159-L169
21:52 Grinnz how does $delay's result get in @results?
21:54 Grinnz ohh, the invocant
21:54 purl i think the invocant is the first argument when a sub is called as a method
21:54 pink_mist $delay->all(...) makes $delay be the first argument to all()
21:54 pink_mist and https://metacpan.org/source/SRI/Mojolicious-7.52/lib/Mojo/IOLoop/Delay.pm#L11
21:54 Grinnz i see, that's unexpected
21:56 Grinnz ->all and ->race make more sense as class methods to me, dunno if that's just me being used to Future
21:56 Grinnz but i don't interpret "the passed Delay objects" as including the invocant
21:59 sri it's about the ioloop attribute
21:59 sri we need to take it from somewhere
21:59 sri and typing the class... really?
22:00 Grinnz maybe then amend the docs "the passed Mojo::IOLoop::Delay objects, including the invocant, ..."
22:01 Grinnz i feel like it will catch people by surprise looking at the code though
22:10 Grinnz i still have futures so i'm not gonna push my preferences too hard on this... like cancellation :P
22:12 Grinnz unlikely they'll be able to be outright compatible but something could easily be written to 'convert' between the two
22:13 Grinnz i could even add ->from_promise and ->to_promise to Mojo::Future
22:14 Grinnz Future::Mojo*
22:15 brunoramos joined #mojo
22:25 Grinnz is there an example anywhere of ->then callbacks that return promises? like a sequential ->get_p chain, from the code that looks like it would work
22:34 robx joined #mojo
22:49 sri that's part of promises/a+
22:49 sri so of course supported
22:51 sri btw. anyone using alfred on macos, the menu search workflow is really fun
22:51 sri i want that for gnome
22:51 Seth joined #mojo
22:55 good_news_everyon joined #mojo
22:55 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vFcSG
22:55 good_news_everyon mojo/master 3eedd17 Sebastian Riedel: mention the invocant too
22:55 good_news_everyon left #mojo
22:55 sri Grinnz: seems reasonable to mention it
22:56 sri Mojo::IOLoop::Delay->all($mojo, $cpan)->then(...)
22:56 sri that would kinda suck to type
22:56 sri downside of having to reuse the name
22:56 Grinnz *shrug*
22:56 sri not that Mojo::Promise->all would be much nicer
22:57 sri IOLoop is especially annoying to type
22:57 sri :)
22:58 maschine joined #mojo
22:58 sri logically $foo->all($bar) looks a little weird too
22:58 sri i actually mentioned that a lot when i made the patch
22:58 sri but nobody had a good idea for making it better
22:58 sri $foo->race($bar) works better
22:58 Grinnz yea its the terminology of "all" that implies "all of the arguments being passed"
22:59 sri picked the name because it's the standard
22:59 Grinnz dont have any better ideas, my preference would still be the class method so
22:59 sri race and all is what people learn first
23:00 sri we could allow both too
23:01 Grinnz that would be a nice compromise imo
23:01 Grinnz ioloop can still be grabbed from the first promise
23:02 sri will Mojo::SQLite support ->query_p and friends?
23:02 sri will you have ->query_f? :p
23:02 Grinnz i'm putting that off for now, since the only reason it has an async api at all is for familiarity
23:03 Grinnz doesnt actually do anything useful
23:03 sri that's true
23:03 sri reasonable decision
23:05 sri i still have the look of Mojo::IOLoop::Delay->all though
23:05 sri *hate
23:07 Grinnz it could also be called as Mojo::IOLoop::Delay::all(@promises) with the current implementation ... that would actually work for me too
23:08 sri *shrug*
23:16 EvanCarroll joined #mojo

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