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

IRC log for #mojo, 2016-04-04

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

All times shown according to UTC.

Time Nick Message
00:00 jontaylor joined #mojo
00:07 asarch joined #mojo
00:56 asarch joined #mojo
00:57 asarch joined #mojo
01:01 tencendur joined #mojo
01:02 jontaylor joined #mojo
01:03 woz joined #mojo
01:55 ivi joined #mojo
01:58 t4nk730 joined #mojo
02:40 noganex joined #mojo
03:05 woz joined #mojo
03:13 inokenty-w joined #mojo
03:17 sunrise joined #mojo
03:19 sunrise i have a Lite app which works fine on openbsd, im trying to get it running on bananian/debian on a banana pi,
03:19 sunrise when i try to enumerate the request parameters i get
03:20 sunrise Can't locate object method "names" via package "Mojo::Parameters"
03:20 sunrise on a line like:     foreach my $n (@{ $c->req->params->names })
03:20 sunrise i remember this changed somewhat recently ?
03:22 Grinnz that was added in 6.0, sounds like you're trying to use an old version
03:22 sunrise yes i remember this broke before, when openbsd brought in the new package version
03:23 sunrise so bananian is using old mojolicious packages
03:24 punter joined #mojo
03:28 sunrise whats the old syntax then :(
03:51 sunrise $c->req->param
03:55 sunrise hooray
04:39 jberger I don't know if bananian has a full toolchain but you can of course install mojo from cpan too
04:40 jberger Meh not here anymore
04:40 jberger I usually check when its a name i don't recognize
05:06 woz joined #mojo
05:40 jontaylor joined #mojo
06:04 melo joined #mojo
06:24 dod joined #mojo
06:33 salva joined #mojo
06:45 dod joined #mojo
06:47 vicash joined #mojo
06:49 dod joined #mojo
07:02 woz joined #mojo
07:06 kes joined #mojo
07:12 McA joined #mojo
07:22 trone joined #mojo
07:27 csroli joined #mojo
07:34 woz joined #mojo
07:48 trone joined #mojo
07:55 osfabibisi joined #mojo
07:58 melo joined #mojo
08:17 Vandal joined #mojo
08:26 woz joined #mojo
08:44 punter joined #mojo
08:48 woz joined #mojo
08:48 mdom http://blogs.perl.org/users/joel_berger/2016/03/on-the-mojolicious-codebase.html#comment-1700748 is like saying cut is not following the unix principle because it's packaged in coreutils ... *ts*
08:52 woz joined #mojo
08:57 woz joined #mojo
09:18 woz_ joined #mojo
09:45 woz joined #mojo
09:46 csroli Hello! I think I've found a bug in Mojolicious::Plugin::ConsoleLogger module. In my ajax requests, the conent_type in the response's header is 'application/json;charset=UTF-8', and the logger's <script> output is present. I think the charset stuff was added automatically, and the logger has no matching stop condition for this case. Am I right?
09:53 jontaylor joined #mojo
09:58 batman tempire: ^^^
10:06 batman csroli: because of timezones it might be while before tempire can answer you.
10:07 batman i'm not sure what the actual bug is though...
10:10 csroli thanks batman. I can fix it here (https://goo.gl/CrcJrK) changing the "eq" part to pattern matching, but I'm not sure this is the best solution.
10:11 batman ah! right. sounds like you should make PR with a new test case :)
10:11 batman sounds right to me
10:15 woz joined #mojo
10:21 woz joined #mojo
10:32 Kripton joined #mojo
10:33 mdom joined #mojo
10:35 jontaylor_ joined #mojo
10:49 csroli There is an issue on github (https://github.com/tempire/mojolicious-plugin-consolelogger/issues/3). What should I do? I think I must write another issue first, then make a fork, do the fix (+ test), and make a pull request.
10:51 nic Why must you write another issue first?
10:56 csroli Just for documentation. I don't know what is your policy for this kind of forking.
10:56 nic There's an existing (open) issue.  I'm not following how it helps anyone to open an additional one.
10:58 csroli That problem was solved. This is a slightly different case.
10:59 kaare joined #mojo
10:59 nic I guess it all hangs on what you mean by "slightly" so I'll leave it to your judgement
10:59 woz joined #mojo
10:59 nic If you do open a new issue, be sure to mention the previous one and why the new one is different
11:00 nic When you do your PR, be sure to mention the main issue id it relates to
11:00 csroli Ok. I think a comment will be enough.
11:03 tchaves joined #mojo
11:42 woz joined #mojo
11:43 ribasushi joined #mojo
11:45 bd jberger: i wanted to give Mojo::ACME a try, but i have used the "official" acme client. is there a document describing on how to extract/convert the needed data? also anything on running Mojo::ACME behind apache?
11:50 CandyAngel sri: Do you have a short list of your concerns about people forking bits of Mojo off?
11:50 woz joined #mojo
11:54 dvinciguerra_ joined #mojo
12:06 jberger CandyAngel: the concerns are the same as we're in my article
12:06 jberger Were
12:06 marcus candyAngel: Also http://mojolicious.org/perldoc/Mojolicious/Guides/Contributing#FORK-POLICY
12:07 jberger My article made the perlweekly this week
12:07 jberger I pasted it in time for last week's when i wanted to have our side out there
12:08 jberger Now I'd rather it not have been in this week so the story would go away
12:08 jberger Gabor didn't give it a very pleasant synopsis either :s
12:09 nic I really don't like their 'editorials' generally
12:09 jberger bd: all you really need is your account key
12:09 CandyAngel marcus: I've read the policy :)
12:09 CandyAngel jberger: I'll read your article, thanks
12:10 bd jberger: in what form? /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/$ID/ has 3 json files,
12:11 jberger Oh right
12:11 jberger Look at acme-tiny
12:11 jberger They have some tools for extracting the account key
12:11 jberger I forgot about that
12:11 jberger Maybe that is something i could add
12:13 jberger bd: https://github.com/diafygi/acme-tiny/blob/master/README.md#use-existing-lets-encrypt-key
12:13 bd jberger: thanks, let me read that
12:15 jberger My code started as a port of scme-tiny
12:15 jberger I've modified it quite a bit since then if course
12:20 woz joined #mojo
12:22 CandyAngel jberger: The only thing that your article doesn't touch on is that people might be forking Mojo *because* it is updated regularly, making people uneasy that it will be "broken" for their use
12:22 nic the issues are only around public forks -- re-published code
12:23 CandyAngel At least, that's why I was considering it for my OpenHMD (because that uses the very separable modules)
12:23 CandyAngel OpenHMD module*
12:24 CandyAngel Though I was on the fence about it, so I won't be as you've said you'd prefer me not to :)
12:26 CandyAngel nic: Yeah, when I say "their use" I mean in modules they may be pushing to CPAN
12:26 nic I'm just pointing out your argument didn't really justify that in any way
12:26 nic (i'm not arguing either side, btw)
12:28 jberger CandyAngel: if you have an in house fork of mojo for business purposes I'm sure no one cares
12:28 jberger The problem comes when those forks are then made public
12:30 jberger And as i say in the article, you are legally allowed to fork, we just want people to consider why they are doing it and what some outcomes might be
12:31 nic It sounds like you're saying Mojolicious has the wrong licence
12:31 jberger No not really
12:32 jberger I think we still believe in open source
12:33 jberger I I've just been surprised at the number of forks that people make or the reasons they make them
12:33 nic As a reader/listener, sitting on the wall, it's not clear how you marry the licence with the policy
12:33 jberger Forking is an important part of open source but it should be a serious decision
12:34 nic So "Don't fork by accident"
12:34 jberger Like forking mysql or open office after oracle bought sun
12:34 jberger Yeah
12:35 jberger The "I'm going to fork this because i need one part and i don't want the whole thing" usually ends in an unmaintained module
12:35 nic We could ask github to add a popup on the fork button, asking the user to confirm they're not drunk
12:35 jberger Which is bad for everyone
12:35 jberger Github fork is a different thing too
12:36 jberger I'm not talking about that
12:36 jberger And indeed it does a good thing by linking back to the original in that case too
12:36 jberger But github forks are more like branches
12:37 jberger We want people to gh fork and then pr to us!
12:37 jberger Are people getting that point confused? Do i need to add a clarification on that?
12:37 jberger Sigh
12:38 woz joined #mojo
12:40 CandyAngel Well, as the policy comes with the threat of being banned from the community if you fork, I think you need to be absolutely clear what is and isn't acceptable
12:40 CandyAngel fork under the wrong circumstances, I mean
12:42 CandyAngel So if github forks are always okay, that should be mentioned
12:43 jberger That's not a fork though
12:43 jberger Gah
12:43 jberger They chose a stupid name for open source parlance
12:43 jberger Technically correct but not useful
12:43 marcus let's start a campaign to call them github spoons
12:44 jberger marcus++
12:44 marcus "I spooned your repo so I can send you a PR in a minute"
12:44 woz joined #mojo
12:45 jberger <3
12:46 mdom jberger: The link to "How it works" on Mojo::ACME does not work anymore
12:47 mdom It's now https://letsencrypt.org/how-it-works/
12:48 nic I'm just getting 404s from https://letsencrypt.org/how-it-doesnt-work/
12:48 jberger Where do i link that?
12:48 jberger I remember linking to it ... just from where
12:49 marty joined #mojo
12:49 jberger I use that link in the blog post
12:49 mdom /lib/Mojo/ACME.pm
12:49 jberger Ah
12:50 jberger OK I'll try to remember that after my commute
12:50 mdom and README.pod ...
12:50 jberger mdom: could i trouble you to open an issue for me?
12:50 mdom I can spoon you, but what the master file? ACME.pm?
12:50 jberger Yeah
12:50 jberger Readme just clones it
12:51 jberger podselect lib/Mojo/ACME.pm > README.pod
12:53 mdom okay, pr on its way
12:54 jberger mdom: thanks
13:11 woz joined #mojo
13:11 woz joined #mojo
13:17 CandyAngel jberger: Would you consider removing the threat from the fork policy?
13:20 asarch joined #mojo
13:36 nic perlweekly.com/archive/245.html is really poorly presented
13:36 nic Joel's title
13:36 woz joined #mojo
13:36 nic Joel's name and username
13:36 nic Joel's picture
13:37 nic but "Apparently ... results." are not Joel's words
13:37 nic I'm guessing it's 'dishonesty through incompetence'
13:38 CandyAngel Wait.. the whole subtext thing isn't what Joel wrote?
13:38 nic I'm pretty sure the text I referenced is 'editorial'
13:39 nic in which case the layout is badly misleading
13:41 CandyAngel Yeah, it is
13:43 arthas joined #mojo
13:44 CandyAngel Maybe no-one has said anything because it has always been like that so "everyone knows"
13:49 CandyAngel I guess if you read it from the top, you can tell they aren't as one of the authors is discussed in that subtext "I like [Author's Name]'s enthusiasm"
13:49 CandyAngel Which would be a little weird to write about yourself :D
13:50 woz joined #mojo
13:50 CandyAngel At least CandyAngel thinks so.
13:52 nic It smells of amateurs out of their depth
13:54 nic I wonder, if you hide all the <p> nodes, does it become less annoying
13:54 woz joined #mojo
13:55 nic no, that doesn't work
13:56 nic sadly they don't even use semantic markup
14:00 mcsnolte joined #mojo
14:02 tchaves joined #mojo
14:03 orev joined #mojo
14:04 nic p[style="font-size: 16px"] { visibility: hidden; } improves it a lot
14:07 mattp_ is there any easy way to stream json responses when very large?
14:07 mattp_ or is implementing some kind of cursor the general approach
14:08 tchaves joined #mojo
14:23 mattp_ sri: do you think making Mojo::JSON::to_json not recursive would be a large perf win?
14:27 woz joined #mojo
14:28 woz joined #mojo
14:29 preaction how would that work?
14:32 tchaves joined #mojo
14:36 batman mattp_: you can't have recursive json objects.
14:38 mattp_ batman: eh? i meant the actual encoder (to_json, _encode_value, _encode_hash, _encode_array)
14:38 melo joined #mojo
14:38 preaction right, how would that work? what would happen if you gave it a hash or an array?
14:39 batman mattp_: so what happens on recursion?
14:40 batman and i don't see how it can be a "perf win" (if perf = performance). checking if some "thing" is already seen should make it slower
14:40 preaction and it doesn't matter how fast it is if it doesn't work
14:46 mattp_ preaction: I think youd just need to walk the struct. with some state of your current level to open/close braces
14:46 preaction you mean making it a stack
14:47 mattp_ yes
14:48 preaction and likely no, since you'd have to maintain your own stack in perl, rather than having perl's stack. the loop would required the same lexical cleanup as the sub call. and the code would be a lot more complex
14:49 mattp_ i cant remember if perl 5 can / does tail call optimization. that would likely make what im talking about moot
14:49 preaction it doesn't
14:49 preaction you can use goto though
14:50 jberger mdom: merged and thanks again
14:50 jberger nic: yeah, you convinced me to drop the editors a note
14:50 asarch joined #mojo
14:51 mdom jberger: Not for that, i'm profiting so much from your work!
14:51 jberger contributions are very valuable
14:51 jberger in all forms
14:52 jberger I've probably put too much on cpan, I know I let issues (rarely PRs I hope) sit longer than I should for lack of time
14:52 preaction eh, they get what they pay for :p
14:53 jberger If only releasing to CPAN wasn't so darned addictive!
14:54 preaction .. yeah... that... addictive... right...
14:54 CandyAngel jberger: "contributions are very valuable, in all forms" <- that is very good to hear :)
14:54 preaction you and sharyanto should get together and build a support group. zoffix has recovered, maybe he can help ;)
14:54 jberger oh, gods, I probably am getting into that category aren't I
14:54 preaction not at all
14:55 jberger sharyanto has other problems though
14:55 jberger well meaning certainly, but he kinda epitomizes the problems of forks
14:55 CandyAngel Releasing to CPAN is addictive? Scary to me -.-
14:56 jberger CandyAngel: oh come on, try just this once :-P
14:56 CandyAngel I have releasing something to CPAN
14:56 CandyAngel Released*
14:56 preaction you have less than 50: https://metacpan.org/author/JBERGER they have 850: https://metacpan.org/author/PERLANCAR https://metacpan.org/author/SHARYANTO
14:56 jberger that's getting into INGY territory isn't it?!
14:57 jberger CandyAngel: got a link?
14:57 preaction zoffix looks to have deleted a lot of his, it seems. only 100 https://metacpan.org/author/ZOFFIX
14:57 CandyAngel I actually have more modules to release but I'm err.. code shy :P
14:57 jberger https://metacpan.org/pod/distribution/OpenHMD/lib/OpenHMD.pod
14:57 mattp_ most of perlancars stuff is ... dubious
14:57 jberger sharyanto == perlancar
14:58 genio preaction: I think he put all of his to HANDOFF and ADOPTME
14:58 CandyAngel jberger: You found it :P
14:58 jberger metacpan++
14:58 Adura I released one module after requesting a means of changing session cookie serialization.
14:58 CandyAngel I have an OO interface for OpenHMD (the one that uses bits of Mojolicious) but I'm still very unsure about the API
14:59 CandyAngel So I haven't released it yet
14:59 jberger that was what held up Mojo::ACME for so long
14:59 jberger fears over the api
14:59 jberger so I stabilized the things I thought were actually going to be used and left it at that
14:59 preaction the best way to get feedback on something is to release it
15:00 jberger CandyAngel: there is also prepan
15:00 jberger I'm not sure if people still do that
15:00 jberger I haven't heard about it in a while
15:00 preaction they do, but not very often
15:00 jberger CandyAngel: you could post it to prepan and link it here
15:00 jberger kinda halfway house
15:01 * preaction looks at his paltry 13 dists and despairs
15:02 jberger 13 sounds like plenty
15:02 preaction i've got like 5 more things on github that haven't been released from lack of even useful amounts of completion
15:03 preaction and two of my dists need to die, as they're completely useless and i can't recommend or support them anymore
15:03 jberger I have several of those
15:03 jberger maybe we should do that on a Chicago.pm office hours
15:03 jberger :-P
15:04 preaction end-of-life some dists?
15:04 jberger yeah
15:04 CandyAngel If I can link it here for feedback, that's be great
15:04 jberger though it seems the one I'm thinking of I did actually remove
15:04 CandyAngel that'd*
15:05 jberger I wrote an unholy marriage of Devel::Declare and a module loader
15:06 woz joined #mojo
15:06 preaction CandyAngel: sure. that's what we're for
15:07 CandyAngel Some bits of the API I *love*. It's probably not a coincidence that those parts are afforded by Mojolicious :P
15:09 CandyAngel But on the other hand, I'm not even settled on module names :P
15:10 jberger names are easy
15:10 jberger actually names are sometimes the hardest part :-D
15:10 CandyAngel :P
15:11 CandyAngel I have OpenHMD which is just the dist. OpenHMD::Backend::* which are the modules which implement the binding to the OpenHMD library
15:11 CandyAngel Then I'm not sure if I should have the OO stuff under OpenHMD::OO or not
15:13 jberger ::OO seems redundant
15:13 jberger the module is OO if the interface is OO, doesn't matter what the name is
15:13 CandyAngel Yeah
15:14 CandyAngel At the moment, there are a few ways to use it
15:14 CandyAngel You can either do it the full way (OpenHMD::Context, find the device you want) which is what full applications will use
15:14 CandyAngel Or for a really quick way..
15:15 CandyAngel my $hmd = OpenHMD::Device->new(index = 0);
15:15 CandyAngel Will use the default device (if you put => instead of = anyway)
15:16 CandyAngel Or, if you want to open the DK1 in particular: my $rift = OpenHMD::OO::Context->new->devices->first(product=> 'Rift DK1');
15:18 woz joined #mojo
15:20 jberger how is OpenHMD::Context and OpenHMD::OO::Context different?
15:20 jberger s/is/are/
15:28 CandyAngel They're not, I've just changed between the two so often I mix them up >.<
15:28 jberger ah
15:29 jberger in that case then, I certainly argue for dropping ::OO
15:29 jberger :P
15:29 CandyAngel :P
15:29 CandyAngel If that is the better way, I'm fine with that
15:37 CandyAngel This is the module stuff I have at the moment: http://codepad.org/laaNdp0u
15:38 CandyAngel Thinking it would be better to drop the ::Eye::* subclasses and just make two instances of ::Eye
15:41 CandyAngel preaction: Also, releasing something to get feedback on it only really works if other people use it :P
15:42 preaction that's a form of feedback, no? ;)
15:42 CandyAngel As far as I am aware, I'm the only person doing VR stuff in Perl (which also makes me probably the only person asking chm to update the OpenGL module :P)
15:42 CandyAngel Yes, but not useful feedback :P
15:43 CandyAngel Besides, if other people were doing VR in Perl, I'd probably not have gotten the chance to author the module in the first place! :)
15:43 CandyAngel (because someone else would have done it)
15:44 Adura 3D regexes...!
15:45 CandyAngel Well, seeing as regex's can already induce motion sickness, it's a perfect fit :D
15:46 CandyAngel Which reminds me, I need to check if my P5 glove works in Windows..
15:47 vicash CandyAngel: i also have a P5 glove i bought about 8 years ago... if you're looking for testers i will be interested in doing some stuff on weekends or so
15:48 CandyAngel vicash: That'd be great :) Thank you!
15:48 CandyAngel I want to submit a driver for the P5 to OpenHMD :)
15:48 pink_mist <preaction> and likely no, since you'd have to maintain your own stack in perl, rather than having perl's stack. the loop would required the same lexical cleanup as the sub call. and the code would be a lot more complex <-- actually you're wrong. calling subroutines in perl is surprisingly expensive. there are many cases where maintaining your own stack in a loop is much more efficient. I doubt it'd be ver
15:48 pink_mist y noticeable for a JSON parser though. and it would likely make the code less maintainable, so unless there's a very clean proposition for it it sounds like a bad idea
15:48 CandyAngel But I don't know if mine is broken (it doesn't behave with libp5glove's demos)
15:49 vicash CandyAngel: try linux ? libusb support for p5glove exists
15:49 CandyAngel It's not behaving in Linux, but I haven't tried it in Windows. So I don't know if it is broken physically or libp5glove is broken
15:49 CandyAngel I just need to remember to test it in WIndows
15:50 CandyAngel Would be nice to get it in OpenHMD, leverage their sensoir fusion for smoothing
15:50 vicash i look forward to doing it...
15:50 Adura P5 Glove... what's it stand for?
15:53 vicash Adura: it is a wired glove that has a 3D mouse.. based on the Nintendo Power Glove.. P5 was made by another company but the P5 ==> Power which is 5 characters
15:53 woz joined #mojo
15:53 odc joined #mojo
15:54 Adura Straightforward enough.
16:04 woz joined #mojo
16:22 woz joined #mojo
16:36 woz joined #mojo
16:36 orev joined #mojo
16:38 disputin joined #mojo
16:49 woz joined #mojo
17:00 woz joined #mojo
17:36 dod joined #mojo
17:37 woz joined #mojo
17:53 woz joined #mojo
18:13 yysachinyy joined #mojo
18:16 yysachinyy Hi everyone
18:20 jberger yysachinyy: hi
18:21 yysachinyy Hi jberger... New to mojo
18:22 jberger glad you're here!
18:22 yysachinyy Looking for a big example of mojo app to read some code..
18:22 jberger well first off have you read the Guides?
18:22 jberger yes it is good to get into code too
18:23 yysachinyy Yes gone through them quickly..
18:23 jberger they are quite packed with content, be sure to come back to them once parts of it start to clear up
18:23 jberger hmmm I wonder which is our best example app?
18:23 yysachinyy Went through one example app in github as well.. Buut found them small..
18:24 jberger yysachinyy: which one did you read?
18:24 jberger this might be the best one atm: https://github.com/kraih/mojo-pg/tree/master/examples/blog
18:25 jberger I also have a full mojolicious app on CPAN
18:25 jberger a cms called Galileo
18:26 woz joined #mojo
18:26 jberger it is getting a little old and if I were to go back I'd do some of it differently, but it is still a useful example I suppose
18:28 yysachinyy http://mojoexample.herokuapp.com/
18:28 yysachinyy I read the one above
18:28 jberger ah, that one is tempire's
18:29 jberger probably even older than mine
18:29 yysachinyy I will go through yours.. Thank you
18:29 jberger then again, IIRC mojoexample was pretty good in its day
18:29 jberger we should probably audit it to see if it is still ok
18:30 jberger tempire still comes around but he does more iOS development these days
18:30 jabberwok with Mojo::Pg, from a query I can get a Mojo::Pg::Results object and call ->hash or ->hashes to get key/value pairs.  Suppose i change one or more values in that hash; Is there a corresponding way to pass that hash back to an insert/update query?
18:30 jberger jabberwok: sql doesn't really work that way
18:31 jberger $db->query('SELECT this AS that')->hash
18:31 jberger how would the generated update statement know what to do ?
18:32 jabberwok with mysql I could do a "UPDATE table SET ".(map {$_ . '=?'} keys %hash)
18:32 jabberwok and i'm looking for a common idiom in the pg world
18:33 jberger but your hash would have been {that => 'value'} but you needed to update "this"
18:33 jberger UPDATE queries are the same
18:34 jberger http://www.postgresql.org/docs/9.5/static/sql-update.html
18:34 jabberwok no, mysql has:  UPDATE table SET FIRST="joe", LAST="shmo" WHERE ID=1;  but postgres you have to use the VALUES... syntax
18:35 jabberwok o.  hmm... ugh.  is that new? =sheepish=
18:35 jberger I kinda doubt it
18:35 jberger the upsert syntax is different from mysql
18:35 jabberwok memo to secretary: strike my previous comments
18:35 jberger hehe
18:35 jabberwok second memo to secretary: where's my coffee?
18:42 PryMar56 joined #mojo
18:51 woz joined #mojo
18:53 Grinnz jabberwok, if you want to automate selecting and updating sort of stuff, you're looking for an ORM, maybe Mad::Mapper will be useful
18:54 Grinnz otherwise, you have to construct the queries as you see fit
19:04 woz joined #mojo
19:30 kaare joined #mojo
19:34 bwf joined #mojo
19:42 dvinciguerra_ joined #mojo
19:56 dvinciguerra_ joined #mojo
20:04 woz joined #mojo
20:15 woz_ joined #mojo
20:16 Kripton joined #mojo
20:19 woz joined #mojo
20:20 woz_ joined #mojo
20:27 woz joined #mojo
20:28 woz joined #mojo
20:36 cpan_mojo Paws-0.23 by JLMARTIN https://metacpan.org/release/JLMARTIN/Paws-0.23
20:36 woz joined #mojo
20:52 woz joined #mojo
21:11 sri hahahahahahaha http://blogs.perl.org/users/joel_berger/2016/03/on-the-mojolicious-codebase.html#comment-1700748
21:11 sri wonder if he ever actually looked into LWP to see all the things it contains
21:13 marcus sri: shush, it's a lean unix-style tool, don't you know?
21:13 marcus not at all 15 years of accumulated cruft
21:14 genio LWP is being worked on.  It's just slow-moving. :)
21:15 sri starting to wonder if anyone actually looked at the DOM::Tiny source, it's pretty horrible
21:16 sri everything just mashed together
21:18 sri the entire comment is rubbish really
21:19 sri someone should really point out coreutils
21:21 sri he doesn't get the unix philosophy
21:21 sri and i think many people don't really
21:21 sri they're just repeating the gospel
21:21 mattp_ in terms of being really anal, I can sort of understand the "I dont want a web framework when I install a json module" thing
21:21 sri you can make small building blocks and distribute them together!
21:22 mattp_ except a 600kb dist is .. negligble. it wont make a difference. you arent deploying to a 486
21:22 marcus mattp_: I've never heard anything but emotional objections to that tho. is there a pragmatic problem with the way mojolicious is distributed?
21:23 mattp_ marcus: yes. exactly. there is no actual rationale besides it being 'unclean' to get some stuff you didnt explicitly ask for
21:24 Grinnz_ personally I do not consider LWP cleaner, I pester people to change to HTTP::Tiny all the time :P
21:24 sri LWP is a total mess
21:31 mattp_ sri: I think what jnap meant was less 'the unix way' and more 'the perl way'
21:32 PopeFelix joined #mojo
21:33 mattp_ not to say the way mojo dists is wrong, but it is certainly not the standard
21:39 odc joined #mojo
21:44 perlpilot I don't really understand janp's coercion comment.  Do people really freak out about having to download a "whole framework" when all they need is JSON ?
21:44 perlpilot s/janp/jnap/
21:45 perlpilot If I needed it and Mojo has it ... what's the problem?  Presumably I downloaded Mojo::JSON because I'm looking at code that uses it and kinda does what I need.  Or someone recommended it.
21:46 perlpilot Does it really matter that I got more?
21:46 perlpilot (excepting embedded environments, of course)
21:48 lluad If it actually depends on all the other things you downloaded then you've increased your maintenance, risk of bugs and security footprint out of all proportion to the amount of code you're using.
21:48 lluad If it doesn't then the depencies are a lie, and that's a problem.
21:49 lluad So I can see why people care about it, to some extent.
21:50 lluad (I don't care about it in the case of Mojo, but over in javascript land I see some trainwrecks that are similar that I do - sort of - care about)
21:50 sri but that's not at all what this is about
21:51 sri nobody really cares about what modules are used where, it's all about how it is distributed
21:52 sri i would welcome a discussion about mojo modules that are too entangled
21:52 jberger reminds me of this SO post I made a long time ago
21:52 jberger http://stackoverflow.com/questions/7777252/uninstall-all-perl-modules-installed-by-cpan/7778134#7778134
21:52 sri i'd be all over that discussion!
21:52 jberger too entangled?
21:53 sri yea, apis that are not generic enough
21:53 sri perhaps dependencies on implementation details
21:57 sri hahahaha, pretty much what Mojo::DOM58 does ;p
21:57 sri in mojolicious that would all be considered a bug
21:58 sri could you imagine Mojo::Collection as a private class in mojolicious?
22:00 jberger no, but if the goal is 5.8 compat then it can't rely on Mojo::Collection
22:19 genio I'd argue that making Mojo::Collection58 would be better.
22:28 woz joined #mojo
22:42 woz joined #mojo
22:50 woz joined #mojo
22:58 sri and a separate dist, so people who only want Mojo::Collection58 don't have to install Mojo::DOM58  ;p
22:59 cpan_mojo Mojolicious-Plugin-INIConfig-Extended-0.06 by HESCO https://metacpan.org/release/HESCO/Mojolicious-Plugin-INIConfig-Extended-0.06
23:00 sri with Mojo::DOM58::Entities it gets tougher
23:01 sri that's something extracted from Mojo::Util
23:01 sri so basically a partial fork of a module ;p
23:10 lb left #mojo
23:12 asarch joined #mojo
23:31 yysachinyy joined #mojo
23:50 dvinciguerra_ joined #mojo

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