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

IRC log for #mojo, 2015-10-17

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

All times shown according to UTC.

Time Nick Message
00:00 Grinnz anyone object if i use Mojo::WebService as a namespace? Mojo::WebService::Client would be more precise but ... getting a little wordy
00:05 Grinnz (note: any objection must be registered via http://objection.mrdictionary.net/index.php )
00:16 disputin joined #mojo
00:17 aborazmeh joined #mojo
00:36 Grinnz joined #mojo
00:42 dabudabu joined #mojo
00:42 Zoffix heh
00:42 Zoffix Grinnz, http://objection.mrdictionary.net/go.php?n=8080576
00:43 Zoffix The module name tells me nothing about what the module is. That's my only "objection". I'd mark it more as an annoyance though :P
00:49 Grinnz basically, Mojo::WebService::Twitter, Mojo::WebService::Wikipedia, etc...
00:50 Zoffix Mojo::WebService::Twitter makes me think of something like twitter.com :S
00:50 Grinnz yes, thats what it's for
00:51 Zoffix So it's a module that lets you have your own Twitter?
00:51 * Zoffix points out they're a few beers deep right now and might not be very usable to get feedback from :P
00:51 Grinnz no, to interface with the twitter API
00:52 asarch joined #mojo
00:52 sri what makes it Mojo specific?
00:53 Grinnz uses Mojo::UserAgent, probably will make use of Mojo::Collection
00:53 sri so it's not ;p
00:54 Grinnz i'm not gonna write the calls to -not- make use of ->json and ->dom :P
00:54 sri i tend to draw the line usually if stuff hooks into the event loop for async stuff
00:55 sri that's when i call it Mojo::*
00:55 Grinnz it will allow async calls
00:55 Zoffix Dunno. To me, modules in Mojo:: namespace tend to follow the "mojo philosophy": concise docs; fluent APIs; no featuritis. That's when I call it Mojo::*
00:55 sri ok, then the namespace seems reasonable
00:56 sri Zoffix: hmm, dunno
00:56 Zoffix That's my perception of it.
00:56 Grinnz I just gotta decide what to do with error handling
00:56 Zoffix I've seen some module that did a fluent API and referred to it as "mojo-style API"
00:56 Grinnz i'm not going to return delays, don't worry :P
00:57 sri Grinnz: good :)
00:57 sri how did your promises experiments go anyway?
00:57 thowe joined #mojo
00:58 Grinnz Future worked out pretty well, it made the error handling much more centralized, though theres still a bit i havent figured out the best approach for
00:58 sri got any example projects?
00:58 Grinnz it's all in these https://github.com/Grinnz/maverick/tree/master/lib/Bot/Maverick/Plugin
00:59 Grinnz (related to what i'm starting now :P)
00:59 buu This is mostly unrelated but I thought you guys might have a sane answer: what the heck are you actually supposed to use angular for?
00:59 sri can't find any ->then calls :o
00:59 Grinnz sri, https://github.com/Grinnz/maverick/blob/master/lib/Bot/Maverick/Plugin/Weather.pm
01:00 Grinnz and https://github.com/Grinnz/maverick/blob/master/lib/Bot/Maverick/Plugin/Translate.pm
01:00 Grinnz those are the two async-heaviest
01:00 Zoffix buu, it's to look hip and cool and recent, mate
01:00 Zoffix (I don't actually know what angular even is; though I've seen the name often enough :P)
01:00 sri ng-hipster
01:01 Grinnz the returned future gets adopted here, and failures get logged: https://github.com/Grinnz/maverick/blob/master/lib/Bot/Maverick/Command.pm#L90
01:01 Grinnz and the adoption method: https://github.com/Grinnz/maverick/blob/master/lib/Bot/Maverick.pm#L458
01:01 sri Grinnz: ouch, those Future-isms hurt my eyes
01:01 Grinnz hehe
01:02 buu Zoffix: It's like a bit complex javascript framework
01:02 buu But I'm unclear as to what problem it's solving.
01:02 buu *big
01:02 Grinnz another thing i'll note though, the concept of cancellation is really helpful, i add a hook so that if the bot is stopped, *every* adopted future is cancelled
01:03 preaction buu: the main bit is bi-directional data binding: from <input> to {{template}}
01:03 Grinnz some may do some cleanup on cancellation or whatever
01:03 Zoffix preaction, bi-direction? A template that populates input?
01:03 preaction <input ng-model="foo" /> <p>you typed {{foo}}</p>
01:04 preaction Zoffix: yes, if i then modify the magic $scope.foo value, the input's value is updated
01:04 Zoffix Interesting
01:04 preaction well, not magic, that's exactly what $scope is for
01:04 thowe oh, we're talking about Angular(?)
01:04 preaction the way it does that is by doing a digest of the $scope object to figure out what changed and what needs to be refreshed, template-wise
01:04 preaction thowe: buu was asking what its purpose was
01:05 preaction React, i believe, is a more explicit version of the same kind of concept
01:05 thowe I was just looking at that the other day.  Looks nifty.
01:05 preaction angular, while i enjoy and use it, hides a lot of the details away in the hope that you don't need to open the hood (and i've not yet needed to, unlike most JS frameworks i've used)
01:06 sri Grinnz: you're closing over a few objects like $bot, and there are no leaks?
01:06 thowe I hadn't heard of React.  Is it used for similar things?
01:06 preaction afaik yes. but it's just the data-binding bit, iirc
01:07 Grinnz sri, not sure yet
01:07 preaction angular also has its everything else: DI, attributes, services, all that kind of stuff
01:07 Grinnz in my tests there were no leaks once the future became ready
01:08 Grinnz ah right, because i added an on_ready which deletes the future from the bot
01:09 sri i imagine there's not many instances of $bot, so a leak would be hard to detect
01:09 Grinnz only one, usually :)
01:09 buu preaction: So you'd use angular in a situation where you had a large number of dynamic elements on a single page that you might want to update independently?
01:09 sri the invocant problem usually trips me up with then-ables in perl
01:10 preaction buu: i use angular for all my single-page apps. that's generally the level i need to reach to choose something like that. the angular-ui router makes browser state transition/history soooo nice
01:10 preaction buu: so, i guess, yes
01:10 sri $ua->get('mojolicio.us')->then(sub { $ua->get('something.else') });
01:11 buu preaction: Can you give me an example of a single page app?
01:13 preaction buu: heh, either way. i think i used angular for vshift.emeraldkingdom.com, but as i'm not speaking to the guy who owns that, i'm not about to go check. otherwise, it's presently all internal $work stuff, though jberger wanted me to help angular-ify his Minion monitor, and likely the Mercury example app I will end up angular-ifying soon
01:14 buu Hrm
01:15 preaction i just started this one, but it's not working yet https://github.com/preaction/Mercury/blob/chat/eg/chat.html
01:16 buu ok
01:16 sri ember seems to be more widely used than angular these days
01:16 preaction i use the $scope.tabs thing quite a bit to add/remove tabs. how easy angular makes it (well, and bootstrap i guess) is part of the appeal
01:17 sri at least i can think of sites using it ;p
01:17 preaction yeah, the angular 2 thing is likely causing folks to jump ship. i wonder where that's happened before...
01:18 sri react might be the biggest framework now
01:21 sri heh, there's already a php7 book
01:24 sri gotta admire their tenacity, php now has an AST
01:24 preaction didn't zend even start beating hiphop for speed?
01:25 sri looks like it is :o
01:26 preaction yeah. php ain't going anywhere :p
01:27 sri having a dejavu looking at php type hints, they look exactly like what reini did in cperl
01:27 sri "function sendHttpStatus(int $statusCode, string $message) {"
01:50 damaya joined #mojo
01:51 jontaylor_ joined #mojo
01:55 panshin joined #mojo
02:07 PryMar56 joined #mojo
02:10 jb360 joined #mojo
02:15 noganex joined #mojo
02:42 bpmedley_ joined #mojo
02:45 nnutter joined #mojo
02:49 nnutter At work I recently made a scope guard for a Postgres cursor for Mojo::Pg a lot like Mojo::Pg::Transaction.  I also made an iterator to fetch results without having to manage the double-loop associated with using a cursor.  Do you think this is something that would be worth putting more effort into and sharing with Mojo::Pg?
02:50 sri interesting
02:51 sri i'm not sure
02:53 sri not having seen any code, i'm a bit sceptical
02:53 nnutter If I were to continue I'd make the iterator portion behave as much like Mojo::Pg::Results as possible but would probably not support `hashes()` or `arrays()` since using a `query()` would be appropriate in those cases.
02:53 sri doubt it could be very elegant
02:54 nnutter Are you anticipating any particular problem that you think would be inelegant or just your gut feeling?
02:55 sri gut feeling
02:55 sri also wondering if this would be better off in DBD::Pg
02:56 nnutter I'll put up what I have now (which is a first pass and not what I would want to suggest) in a couple minutes.  Gotta log into VPN and all that.
02:56 nnutter Yeah, honestly I was fairly shocked/horrified to see that DBD::Pg always fetches all results to client.
03:00 sri is the fetch a fast operation or can there be latency?
03:01 sri wondering if you'd need multiple callbacks for non-blocking queries with cursors
03:01 nnutter In my experience so far it's fast.
03:02 nnutter My current implementation is very minimal and I haven't thought about non-blocking usage yet.  That would be one of the things that would need to be added.
03:05 sri heh, this has been open for 7 years https://rt.cpan.org/Public/Bug/Display.html?id=19488
03:05 sri guess there is interest ib a DBD::Pg patch, considering it wasn't closed
03:06 sri s/b/n/
03:06 Grinnz not as long as https://rt.cpan.org/Public/Bug/Display.html?id=25590
03:06 Grinnz (that's the first of 3 bugs which are pretty much about the same issue...)
03:07 nnutter Here's my crappy minimal version if it helps imagine a real solution. https://gist.github.com/nnutter/3ebd6938c519a04e1789
03:09 mandreacchio joined #mojo
03:11 nnutter Hey Grinnz, you have any interest in allowing Mojo::JSON::MaybeXS to specify JSON::MaybeXS options?  I would like to use convert_blessed but not allow_blessed.  For now I just "vendored" it to manually change.
03:13 nnutter I had a "fun" time tracking down a bug today because we were setting a Mojo::Path object as a session value (flash value) and got bit by the null stringify caveat.
03:13 Grinnz nnutter, I'm trying to maintain compatibility with Mojo::JSON as much as possible, but it would be doable as import options
03:14 sri nnutter: the api is a little non-mojo-ish
03:15 sri having to set a name, and key/value pairs
03:15 nnutter sri: I agree.  I'm definitely not proposing that code.
03:15 Grinnz yeah, that situation sucks; https://github.com/rurban/Cpanel-JSON-XS/issues/37 still sitting there
03:15 sri otherwise, the ->fetch(100) to get a results object seems quite reasonable
03:15 nnutter sri: For the name I was thinking of grabbing a GUID either from a Perl module, if available, or from Postgres if not.
03:16 nnutter With the name out the k/v pair can go too.
03:16 sri although, personally, i guess i'd make it a little more magical, and have a custom results object that fetches on demand
03:16 sri did that in Mango for cursors
03:17 nnutter The iterator is that though I would make it way more like Results.
03:17 sri you set a batch size, and it keeps fetching batches
03:17 sri ah
03:17 sri that said, i still think it belongs in DBD::Pg :)
03:18 sri just setting an option to make selects use cursors would be awesome
03:19 nnutter Good to know.  Thanks for taking a look.
03:20 sri if you want to release this to cpan as Mojo::Pg::WithCursors or so, you could subclass Mojo::Pg and overload the db method to return your version of Mojo::Pg::Database objects
03:21 sri no need to monkey patch then
03:22 nnutter Yeah, I doubt I would monkey_patch if released on CPAN.
03:23 sri wait a minute, looks like there's even an easier way to fetch results in batches in libpg
03:23 sri https://rt.cpan.org/Public/Bug/Display.html?id=93266#txn-1336900
03:24 sri without cursors :o
03:24 * sri wants
03:27 sri i mean pqlib... that name always confuses me
03:29 damaya joined #mojo
03:57 panshin joined #mojo
05:17 damaya joined #mojo
05:36 nic Zoffix++ # csv loveliness
05:56 irqq joined #mojo
06:17 damaya joined #mojo
07:08 kaare joined #mojo
07:09 Grinnz https://github.com/Grinnz/Mojo-WebService it's a start, lots of busy work to go... and i might need to use more delays
08:05 Vandal joined #mojo
08:23 meshl joined #mojo
09:15 sh4 joined #mojo
09:32 gaunt joined #mojo
09:37 amon joined #mojo
09:44 damaya Hey all, I have an authed route (using under) /messages. If I try to access messages, I am redirected to login. However, if I try to access an authed route with params (e.g., /review/:type), I get a "Page not found.. yet!" error
09:45 damaya So, my under callback seems to work for routes with no params, but craps out for routes with params :/
10:00 jb360 joined #mojo
10:08 sugar_ joined #mojo
10:21 panshin joined #mojo
10:33 damaya joined #mojo
10:44 panshin joined #mojo
10:58 meshl joined #mojo
12:40 panshin joined #mojo
13:23 panshin joined #mojo
13:23 mattastrophe joined #mojo
13:24 jb360 joined #mojo
13:36 genio damaya: can you pastebot your routes?
13:37 sri or actually ask a question
13:42 trone joined #mojo
13:43 meshl joined #mojo
13:44 genio I'm assuming /foo/:bar   and then accessing /foo in the browser.
14:01 bpmedley joined #mojo
14:22 vanHoesel1 joined #mojo
14:46 asarch joined #mojo
15:30 lluad joined #mojo
15:34 human39 joined #mojo
15:35 zivester joined #mojo
15:38 PryMar56 joined #mojo
15:40 cpan_mojo Mojo-CSV-1.001002 by ZOFFIX https://metacpan.org/release/ZOFFIX/Mojo-CSV-1.001002
15:40 ajr_ joined #mojo
15:43 mudler joined #mojo
16:03 MartinR joined #mojo
16:27 dod joined #mojo
17:08 damaya joined #mojo
17:33 Mikey joined #mojo
17:42 irqq joined #mojo
17:57 ZoffixW joined #mojo
17:59 ZoffixW I'm having trouble adding handlers. I've got this: $self->app->renderer->add_handler( pdf => \&_pdf_handler, ); and I'm trying to render with ->render( pdf => \%data ), but I'm getting a 404 :/
17:59 sri http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Adding-a-handler-to-generate-binary-data
18:03 ZoffixW No love. Even if I stick a "die" into the handler, nothing dies.
18:06 damaya joined #mojo
18:11 ZoffixW Got it. Was missing this bit: http://fpaste.scsys.co.uk/500390
18:19 stephen joined #mojo
18:22 irqq joined #mojo
18:26 damaya joined #mojo
18:44 abra joined #mojo
19:16 theo joined #mojo
20:01 damaya joined #mojo
20:03 panshin joined #mojo
20:28 Martin90 joined #mojo
20:44 CandyAngel Should I be using EUMM for modules that are going onto CPAN?
20:45 * ZoffixW uses Dist::Zilla
20:46 preaction CandyAngel: http://chicago.pm.org/talks/ see 2015-08-27 - Distribution Management Shootout. there're quite a few options
20:47 CandyAngel Thankies
20:49 CandyAngel Ideally, I'd want something that is the least "noisy" amongst the other files
20:49 CandyAngel Even if it is just a description of what goes where
20:51 preaction generally everything knows what goes where based on the directory structure. it's files like CHANGES, and README, and META.{yml,json} that start making things difficult
20:52 ZoffixW CandyAngel, dist zilla uses just a single file (dist.ini) and autogenerates a lot of cruft that are included in distros. Here's an example (Note, README.md is auto-generated from pod) : https://github.com/zoffixznet/Mojo-CSV
20:52 ZoffixW CandyAngel, and here what it generated when I used "dzil release" command: https://metacpan.org/source/ZOFFIX/Mojo-CSV-1.001002
20:55 CandyAngel That looks pretty nice
20:56 * sri hates Dist::Zilla
20:56 preaction i also use Dist::Zilla. Minilla is like Dist::Zilla if you use github. Dist::Milla is like Minilla if you want configurability like Dist::Zilla
20:56 ZoffixW sri, why?
20:56 sri Dist::Zilla always makes people not have Makefile.PL in their repos
20:57 sri if i have to install Dist::Zilla to contribute to your project, i'm not going to contribute
20:57 CandyAngel I don't mind one file specific to the builder (in the repo), but having like.. 20 is wayyy too much
20:57 ZoffixW ¯\_(ツ)_/¯
20:57 preaction it doesn't put it there by default, sure. my dist.ini configuration puts the build files in the root and commits them as part of the release
20:57 CandyAngel Makefile.PL is EUMM?
20:57 ZoffixW But it's a good point. I recall trying to contrib to some dude and his author plugin bundle wasn't installing.
20:58 preaction CandyAngel: generally yes, but not always
20:58 sri ZoffixW: in my experience it's always like that ;p
20:58 ZoffixW :D
20:59 sri if you have a Makefile.PL and i don't have to use your Dist::Zilla toolchain, i have no problem with it
20:59 kaare joined #mojo
20:59 CandyAngel Hmm
21:00 CandyAngel I'm not sure if my email went out to module-authors list :/
21:00 CandyAngel Want to check the names I've chosen (and intend to use in the future) are alright
21:00 preaction dist name you mean? prepan.org is also a good spot for that
21:01 CandyAngel Names for the modules
21:02 preaction one of which should be the name for the distribution. the main module should also be the distribution's name, and every other module should be underneath it in the directory tree
21:03 CandyAngel Hmm
21:04 CandyAngel Maybe how I'm intending to do this won't work then
21:04 ZoffixW What are you intending?
21:05 CandyAngel The first thing I've done is write a thin wrapper for OpenHMD using Inline::C and that is called 'OpenHMD' which should be installable on its own
21:05 ZoffixW not necessarily -> "and every other module should be underneath it"
21:05 ZoffixW Consider: https://metacpan.org/source/SRI/Minion-2.05/lib
21:05 CandyAngel Then I have OpenHMD::Simple which depends on it and provides a really really simple OO interface
21:06 preaction ZoffixW: the rules are for experts to break for expert reasons
21:06 CandyAngel Later on, I want to write a "full" OO interface which I was going to call OpenHMD::Context and OpenHMD::Device
21:06 ZoffixW Fair enough :)
21:06 ZoffixW CandyAngel, I don't see an issue with that.
21:07 CandyAngel What would the dist-name be for ::Context and ::Device.. they are used together
21:07 preaction or you could make your Inline::C version OpenHMD::Raw
21:07 ZoffixW OpenHMD
21:07 preaction do they have to be in another dist?
21:07 CandyAngel It can't be OpenHMD because that's taken
21:07 ZoffixW Oh
21:07 CandyAngel By the Inline::C module wrapper
21:07 preaction think huffman coding: what will be the easiest way to use the Open HMD thing?
21:08 CandyAngel Maybe OpenHMD::OO (distname) and OpenHMD::OO::Context and OpenHMD::OO::Device?
21:09 CandyAngel Er.. the sanest way will be the ::Context and ::Device modules, but they (may) lag behind what you can do with the thin wrapper
21:10 CandyAngel Oh, I guess I could have "dumb" get/set methods so you can pass any constant you want in those too
21:10 CandyAngel Like in ::Device, you'll be able to do: $device->rotation_quaternion which will return a Math::Quaternion object
21:11 preaction so why not OpenHMD::Raw then? then OpenHMD is the context object, and OpenHMD::Device is the device object
21:12 CandyAngel Hmm.. could do
21:13 CandyAngel Or have the thin wrapper be OpenHMD::Backend::Inline
21:13 preaction i mean, i generally approach APIs from the outside: what do i need to do with this API? how quickly can i achieve it? the "Object-Oriented Design Heuristics" book has helped a lot
21:13 CandyAngel So I can do OpenHMD::Backend::XS in the future
21:14 CandyAngel You know, if I ever learn XS or someone wants to make it
21:14 preaction you could just call it OpenHMD::XS. but Inline::C requires a compiler, so there's no benefit either way
21:14 preaction perhaps also check out FFI::Raw and make an OpenHMD::FFI?
21:15 ZoffixW Anyone recall the docs that talk about how to make a CPAN distro from your mojo app?
21:17 CandyAngel preaction: One of the reasons I think OpenHMD::Simple is a fine name for that module is that it gives you access to the simplest case in 3 method calls (and one of those is 'new')
21:17 ZoffixW :S can't find it anywhere >_<
21:18 CandyAngel And like.. 5 method calls to implement the OpenHMD simple example :P
21:18 preaction CandyAngel: why would one ever need anything else then? more complex cases should be extensions of that common case
21:19 CandyAngel Performance. At the moment, if you need to get any information about the state of a device in OpenHMD::Simple, you get *all* the state back, making like.. 12 calls to the library to do so
21:19 CandyAngel Which includes things that only change if you actually change them (e.g. IPD)
21:20 ZoffixW Found it https://metacpan.org/pod/distribution/Mojolicious/lib/Mojolicious/Guides/Cookbook.pod#Making-your-application-installable
21:32 Grinnz [16:59:01] <sri> if you have a Makefile.PL and i don't have to use your Dist::Zilla toolchain, i have no problem with it
21:32 Grinnz thats how my plugin bundle is desgined ;)
21:32 damaya joined #mojo
21:32 CandyAngel Can you install individual modules from a dist?
21:33 Grinnz not generally
21:33 CandyAngel Okie
21:33 Grinnz and theyre usually interdependent so thats probably a bad idea
21:33 preaction disk space is cheap though
21:34 Grinnz i originally got the "installable from repo" idea from Dist::Milla btw, it's worth a look for a github based plugin bundle, my bundle stole a lot of things from it but does a few things differently
21:36 mattastrophe joined #mojo
21:43 CandyAngel OKay, how's this? 3 dists, OpenHMD (containing OpenHMD::Context and OpenHMD::Device), OpenHMD-Backend-Inline and OpenHMD-Simple?
21:45 ZoffixW I get a whiff of Distiritis... and I speak from experience: http://backpan.perl.org/authors/id/Z/ZO/ZOFFIX/
21:45 CandyAngel :P
21:46 ZoffixW What I mean is, why not make one dist with all those modules? If they're closely related, pack them all in one place. Easier to maintain
21:46 CandyAngel In the same way you shouldn't pollute people's namespaces with @EXPORT, I don't want to pollute people's filesystems with modules they don't need :P
21:46 ZoffixW pfft. Two extra files that are a few KB each. No one will even notice your good deed.
21:49 damaya joined #mojo
21:49 CandyAngel Can I split them later?
21:51 ZoffixW Sure
21:53 CandyAngel Okay, I'll just do an OpenHMD dist with everything and split it if someone ever asks me :P
21:53 ZoffixW Good plan.
21:53 CandyAngel Thankies :)
22:00 * CandyAngel watches ZoffixW fly away now their job is done :P
22:18 damaya joined #mojo
22:39 panshin joined #mojo
22:48 meshl joined #mojo
23:25 damaya joined #mojo
23:35 asarch joined #mojo
23:41 damaya joined #mojo
23:57 damaya joined #mojo

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