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

IRC log for #mojo, 2016-03-23

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

All times shown according to UTC.

Time Nick Message
00:11 Rubes joined #mojo
00:15 melo1 joined #mojo
00:19 dhg joined #mojo
00:26 sri oh, npm is having a meltdown
00:30 preaction rubygems was earlier today too apparently
00:30 sri https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c#.punxq2yzk
00:31 preaction oh, different kind of meltdown
00:34 preaction half-reminds me of Nagios::Plugins, though with a different result
00:34 sri the memes are strong there https://github.com/azer/left-pad/issues/4
00:34 Grinnz preaction, the different result being important, I think :P
00:35 preaction i mean, the different result is because cpan isn't centralized. npm is a company. cpan is a community. if someone wants to send a C&D, first they have to find an entity to sue
00:36 preaction which is funny because neilb is writing a blog post series exactly about what makes pause/cpan different
00:39 meredith i think it's clear that there are folks who do have the power to pull from cpan and see it pulled from mirrors
00:39 meredith a lawyer can make liability out of that when it comes to IP infringement
00:40 Grinnz sure, but they don't have interest in it coming to that
00:40 meredith mirrors and index websites are probably the best bet for keeping hands clean if someone really started picking fights
00:41 mattp_ not sure why a crappy chat app company (kik) would bother paying a lawyer to deal with some other crappy npm module
00:41 Grinnz the smaller companies are usually all the more defensive about their brand
00:42 meredith in the US, once you know of a trademark violation you're practically compelled to protect it if you want to keep it
00:42 meredith that is, if someone can prove you knew about an issue and didn't pursue it, they can win their own trademark fight against you
00:43 Rubes joined #mojo
00:44 preaction a few years back i got a request for my twitter handle from Pre-action Fire Sprinkler Systems. I said thanks but no thanks, and they went away. they have not yet threatened me with meritless legal thuggery
00:44 Grinnz hahaha
00:44 Grinnz well, that's reasonable
00:45 preaction this kik thing went from 0-100000000 instantly...
00:50 pink_mist meredith: trademarks are very specific though; just being a company that's named "kik" isn't enough that a python module named "kik" would infringe. however if they had a trademark for specifically a program or library named "kik" that might be a different matter, but the story doesn't tell that much
00:51 meredith trademark context gets really fuzzy in the computer world because it gets judged by people who don't have the specific knowledge we do.  kik + "computer stuff" can be enough for some folks to think that is a case where someone will be confused over brands
00:52 preaction in the end it doesn't matter: i can sue you for anything, and you likely cannot afford to defend yourself
01:22 genio finally finished daredevil
01:44 good_news_everyon joined #mojo
01:44 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/va5Ow
01:44 good_news_everyon mojo/master 4034b64 Sebastian Riedel: slightly more consistent formatting
01:44 good_news_everyon left #mojo
01:44 Grinnz genio, that last scene, eh
01:53 genio yea.  I'll refrain from saying anything as I don't want to ruin it from anyone, but next season should be action packed
01:55 sri an action packed season of daredevil? no way!
01:55 genio haha
01:59 Grinnz lol
02:14 asarch joined #mojo
02:15 mroy_ joined #mojo
02:24 zivester joined #mojo
02:31 bpmedley http://bmedley.org/c.html <-- Maybe one day live in the debugger, eh?  :)
02:36 Rubes joined #mojo
02:48 Rubes joined #mojo
03:20 Rubes joined #mojo
03:32 noganex_ joined #mojo
03:50 Rubes joined #mojo
03:53 good_news_everyon joined #mojo
03:53 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/va54e
03:53 good_news_everyon mojo/master e301dc7 Sebastian Riedel: update Changes
03:53 good_news_everyon left #mojo
03:56 mattp_ is it possible to redirect to a different action from within an action?
03:56 mattp_ Im sure it is, just looking for the right doc
03:57 mattp_ a redirect_to without an external 302 is essentially what im looking to do
03:59 melo joined #mojo
03:59 sri nope, that pattern is frowned upon around here
04:00 mattp_ ah. hmm
04:00 mattp_ isnt it juts return $self->controller_method(@_) ? that might be all i need
04:01 sri if that's all you need
04:01 sri that's fine
04:03 mattp_ sri: thanks
04:20 cpan_mojo Minion-5.02 by SRI https://metacpan.org/release/SRI/Minion-5.02
04:21 cpan_mojo Mojo-Pg-2.24 by SRI https://metacpan.org/release/SRI/Mojo-Pg-2.24
04:21 good_news_everyon joined #mojo
04:21 good_news_everyon [mojo] kraih tagged v6.57 at 5514586: https://git.io/va5B2
04:21 good_news_everyon left #mojo
04:23 good_news_everyon joined #mojo
04:23 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/va5Br
04:23 good_news_everyon mojo/master 1b0343c Sebastian Riedel: bump version
04:23 good_news_everyon left #mojo
04:24 Rubes joined #mojo
04:51 inokenty-w joined #mojo
05:09 jberger Wow npm, what a shitshow
05:09 jberger Milwaukee.pm talk went really well
05:09 jberger Now time for the sleeps
05:22 melo1 joined #mojo
05:23 Rubes joined #mojo
05:48 sri holy shit, i had no idea "unpublish" means that the name is released back into the wild https://news.ycombinator.com/item?id=11341006
05:49 sri thought it just broke millions of apps... but in reality millions of apps broke and are now vulnerable
05:57 Rubes joined #mojo
06:22 melo joined #mojo
06:56 melo joined #mojo
07:00 dod joined #mojo
07:04 dod joined #mojo
07:24 salva joined #mojo
07:48 melo joined #mojo
07:53 sugar joined #mojo
08:11 osfabibisi joined #mojo
08:20 AndrewIsh joined #mojo
08:22 Vandal joined #mojo
08:41 ashimema that's kinda scary sri, thanks for pointing it out
08:55 McA joined #mojo
09:01 trone joined #mojo
09:13 csroli joined #mojo
09:18 sugar joined #mojo
10:07 odc joined #mojo
10:27 mdom Has anybody a good idea how to check if only a list of allowed params is set?
10:30 mdom I hoped there would be something similar to validation->required ... like validation->allowed
10:38 Kripton joined #mojo
10:38 melo joined #mojo
10:57 dvinciguerra_ joined #mojo
11:23 irqq joined #mojo
11:57 mattp_ sri: i guess thats impossible on cpan without maint bit yes? otherwise its an unauthorized release
12:10 perlpilot_ joined #mojo
12:32 mcsnolte joined #mojo
12:36 pink_mist https://medium.com/@Rich_Harris/how-to-not-break-the-internet-with-this-one-weird-trick-e3e2d57fee28#.t9v0gvbyb
12:47 Lee i'm not sure you can rage-quit CPAN in quite the same way
12:47 Lee s/quite/quit/
12:48 Lee gah, brian no worky today
12:53 mdom Ah, sorry, so easy ... i just need call $c->validation->optional($_) for @allowed_params
12:55 pink_mist Lee: you can do what mlehmann did and make your modules fail to install on newer versions of perl unless you switch to his stableperl fork
12:56 Lee yeah
12:56 eseyman but no perl module is going to depend on those new versions
12:57 Lee he seems to have a spurious letter "b" in the name of this fork
12:57 pink_mist Lee: heh, nice one :P
12:57 neilhwatson joined #mojo
12:57 Lee anyway, i mean total total rage-quit is possible but you'd have to delete all of your dists and then remove first-come
12:57 Lee and i'm not sure if you can do the latter
12:58 Lee (which is generally why the top level namespace isn't something to upload new stuff to)
12:58 Lee and even *then* backPAN will have most stuff
12:59 Lee but this is interesting
13:00 Lee mlehmann's actions will just lead to forks (which has already happened) and people moving away in the longterm (which is already happening) so i don't think that's a problem
13:03 jberger mlehmann's actions before that had already started the forks and migrations
13:03 Lee yep
13:04 jberger Holding JSON::XS hostage, exit 1 in AnyEvent
13:05 pink_mist hmm, speaking of, what's the name of the Mojo::JSON fork to provide just the JSON handling?
13:05 pink_mist (or don't we speak of that?)
13:06 jberger I can tell you, but again i ask why that's of any value
13:06 jberger The entire mojo dist is tiny as it is
13:07 pink_mist need to bundle a JSON module in a script and I really don't want to bundle a webserver too
13:07 jberger Fatpack
13:08 pink_mist that's what I'll be doing, yes
13:09 pink_mist so anyway your answer was that we don't speak of that then
13:09 jberger When you fatpack doesn't it only pack the modules you need?
13:09 nic I'm confused; shirley you just need Mojo::Util + Mojo::JSON; I see no webserver in that
13:10 pink_mist any devs will need the entire distribution; I don't want to force all of them to install a webserver
13:10 jberger I can say it, its JSON::Tiny, but i still don't think you need it nor do i endorse it
13:11 jberger I don't know how often or faithfully it has been kept up to date, it may have been, but I don't know
13:12 jberger pink_mist: just remember that Mojolicious is 8400 something lines of code and installs in less than a minute
13:13 jberger That's why we don't break it up, it isn't worth doing
13:14 jberger If you use anything like dzil for building, you won't even notice mojo install
13:14 nic pink_mist's dev friends use _really_ expensive disks and can't spare the extra bytes
13:15 nic If you use anything like dzil for building, you won't even notice your coffee was substituted by dishwater
13:16 jberger http://jberger.github.io/MojoliciousIntroduction/#/4/1
13:18 jberger The server is 245 lines https://github.com/kraih/mojo/blob/master/lib/Mojo/Server/Daemon.pm#L245
13:19 jberger Yes i know that's a gross oversimplification, but ;)
13:22 vicash pink_mist: it is JSON::PP and that is in the core.
13:26 jberger Or there's that
13:30 Lee JSON and JSON::PP are essentially abandonware at this point
13:30 Lee i asked makamaka if he wanted to pass on maintenance about a year ago but he said he didn't
13:33 vicash Lee: Mojo::JSON uses JSON::PP under the hood
13:33 Lee interesting
13:34 * vicash says to do cat `perldoc -lm Mojo::JSON` | grep JSON:PP
13:34 pink_mist oh, JSON::PP is in core? well alright then, much easier to deal with =)
13:35 Lee vicash: oh it's only using if for booleans
13:38 vicash that's right. i didn't bother checking the rest of the code. thought Mojo::JSON was a wrapper
13:41 * vicash wonders why JSON::PP is considered abandonware considering it already works and JSON isn't changing
13:43 Lee 10 issues in the last 2 years and no response to them
13:44 Lee oh and a tonne of PR's too, with no response
13:44 vicash that sucks.
13:45 Lee i don't know if makamaka is busy no longer working with perl
13:45 Lee s/ no/ or no/
13:47 Lee generally when i come across stuff like this i offer to take over maintenance, or will fork. but something like JSON, JSON::PP, etc, i *don't* want to fork
13:48 bwf joined #mojo
13:49 vicash maybe a perl foundation grant for fixing the bugs should be done. last year ingy did that for fixing Inline, Inline::C and Inline::CPP
13:49 vicash seemed to have gone well
13:49 genio From what I gather, several people have offered to take over JSON::PP to no avail
13:51 Lee genio: right, and not updated in 2 years, ergo: abandonware
13:52 Lee it's rather frustrating
13:53 genio Yea. I agree.
13:53 melo joined #mojo
13:53 nic It's bizarre that can happen with a module included in core.  Sometimes I don't think the perl (5) community is taking things seriously
13:54 genio And with you already having taken over larger projects that are old and crufty, I can't imagine why he wouldn't pass it off to you, but meh.  Some people just don't want to cede any control
13:54 Lee nic: i think anything critical would be fixed, given it's core
13:54 Lee but in its current state it contributes to a "broken windows" effect on CPAN
13:55 Lee of course there are many modules like this
13:55 Lee and the usual caveats that it's all open source, people have varying levels of free time and motiviation, and so on
13:56 genio yea, but that should also mean having a willingness to let others participate in the development of it.  If you hoard the privileges and don't want to do anything with it, you're doing nothing but creating a problem
13:56 genio people--
13:56 Lee :)
13:58 mitya joined #mojo
13:59 genio I can completely understand not wanting to just give anyone privileges to your stuff that you worked hard on and especially if it's in core.  But when people who have proven they can take on complex older code step up to provide help, I don't understand the hesitance there.
14:02 vicash this is what patches or pull-requests were designed to solve. if you don't have time and others do, and they're fixing issues in an appropriate manner, then all you have to do is merge and test
14:03 genio yet, if you let said PRs sit there for ages and do nothing...
14:03 Grinnz JSON::PP/JSON.pm are also both incredibly inefficient and bloated, they could not complete the JSON benchmark I tried a while back
14:03 Lee PRs are awesome, it's the ultimate form of lazy-delegation
14:03 Grinnz Mojo::JSON/JSON::Tiny did fine despite also being pure perl
14:04 Grinnz haarg has asked makamaka for comaint from what I recall but I have not heard that there was any response
14:04 haarg no response
14:04 Grinnz :/
14:05 Lee IIRC it took makamaka a few weeks (months?) to get back to me and the answer was no
14:05 Lee that was on twitter
14:05 Grinnz I included JSON.pm in the above statement about being inefficient, because it somehow manages to make its delegation to JSON::XS also extremely slow
14:06 vicash isnt there a JSON::Any for that ?
14:06 Grinnz whereas JSON::MaybeXS does not, since it just gives you the underlying module's object
14:06 vicash i guess JSON::Any is deprecated
14:06 Grinnz JSON::Any is ... complicted
14:06 Grinnz complicated*
14:07 Grinnz but deprecated for anyone other than the author is as good a description of the situation as any
14:12 mitya joined #mojo
14:15 asarch joined #mojo
14:22 marcusr joined #mojo
14:30 sri JSON::Tiny is the perfect example for why those kinds of forks suck a lot
14:30 sri bugs get reported on its github repo, sit there for weeks, and we get never notified
14:31 sri it takes resources from this project
14:31 sri and no, it's not even kept up to date
15:07 sri Grinnz: on a related note, what you're doing with DOM::Tiny sucks
15:11 zivester joined #mojo
15:11 sri this is really tough, since i like Grinnz
15:13 jberger well I like davido too
15:13 mitya joined #mojo
15:15 sri i don't know davido enough
15:15 jberger very nice guy
15:15 jberger met him at YAPC in SLC
15:20 sri at the end of the day we don't gain anything from hostile forks, it only costs us
15:20 sri JSON::Tiny has shown that over many years
15:20 mitya joined #mojo
15:22 sri i've made my feelings on this issue very clear to Grinnz in the past, and he said he would stop with DOM::Tiny
15:22 Grinnz_ ...?
15:23 haarg i think it's inevitable given your packaging model
15:23 sri what packaging model?
15:23 sri it's just a dist with web related modules
15:24 sri we even went out of our way to make everything fatpackable
15:26 haarg people don't want to depend on the whole dist when all they want it a json module.  or maybe they want 5.8 support.
15:27 haarg i know there are good reasons to package it like that, but one of the consequences of that choice is things like JSON::Tiny
15:27 jberger "people don't want to" is a silly argument
15:27 sri yea
15:27 haarg people won't
15:28 jberger the entire library is 8491 lines of code
15:29 jberger there is no onerous burden there
15:29 meredith i just don't think the mojolicious dist is that heavy or that loading mojo::{dom,tiny} alone pull that much more into the process.
15:29 jberger so the only remaining problem is a "gut feeling" that installing a web server isn't "necessary"
15:29 haarg 5.10 is an onerous burden for some
15:29 sri just to be clear, this really hurts me personally that people have no respect for my wishes on this
15:33 genio 5.10 requirement aside, would copying the version to each separately usable thing help some?  People like to add requirements for exactly what they want to use
15:34 preaction so we are doing this again then? you already add a requirement on what you want, that pulls in the distribution with the module you require
15:35 sri what if i stopped all work on mojolicious as long as hostile forks exist?
15:35 genio ah, sorry to rehash old stuff. *shuts up*
15:36 preaction i'm fairly certain that this policy has been well-covered by blog posts, with included discussions. there's also likely quite a few instances of this discussion in the irc logs
15:36 PryMar56 joined #mojo
15:37 sri Grinnz: i want you to know that you're doing real damage
15:37 haarg preaction: you can add a req on a given module, but not a version
15:37 haarg because Mojolicious is the only module with a version specified
15:37 Grinnz_ I am not sure what you expect from me. The modules cannot unexist. I prefer it to be up to date than abandoned since it will continue to exist
15:38 genio preaction: my bad. I spoke up trying to be constructive, not spark annoyance.  I am also ignorant of much of the toolchain, so in hindsight, I shouldn't have said anything.
15:40 sri Grinnz: you can delete it
15:41 Grinnz_ There are modules dependent on it
15:41 sri then you can deprecate and then delete it
15:42 Grinnz_ Then it will just be forked and continued
15:42 Grinnz_ probably less effectively
15:42 jberger and yet another reason that RT.cpan is annoying, you can turn off github issues on a repo (to direct users to mojolicous issues) but you still can't turn off RT.cpan
15:43 meredith jberger i learned that fact more than once from the mlehmann autoresponder ;)
15:43 jberger yeah, but this was a use-case that I hadn't considered
15:43 meredith now you know how evil RT is
15:44 jberger imagine a blessed fork in which the author explicitly agreed to direct all bug reports upstream
15:44 jberger that isn't even possible
15:45 genio It could be with an autoresponder email (a la mlehmann) that forwards those emails to the other RT queue (thus re-creating the ticket there)?
15:45 meredith yeah, i thought about that, but i wouldn't want to shunt bug reports that are fork-specific to the main project
15:46 meredith i'd just have to commit to being responsible with my issue tracker, which is why i don't run any forks :)
15:52 csroli left #mojo
16:05 mtths joined #mojo
16:08 dvinciguerra joined #mojo
16:08 sri so, i've actually created a cpanratings account to give DOM::Tiny a review, it has come to this
16:09 jberger sadly funny that the lack of action on the cpanratings issue would make that possible
16:10 * Lee made a PR for the cpanratings issue, don't know if it'll help
16:11 sri http://cpanratings.perl.org/dist/DOM-Tiny
16:11 Rubes joined #mojo
16:25 sri harsh, but factual correct
16:26 sri i might even be upset enough to blog about it
16:32 sri that actually did make me feel better, maybe i misjudged cpanratings after all
16:33 sri ¯\_(ツ)_/¯
16:36 sri some yes clicks would be appreciated though
17:17 sri oh, 2 no votes already
17:18 sri now i'm pissed again
17:23 sri so, now i'm getting silenced by the community
17:23 sri that's fucked up
17:25 disputin joined #mojo
17:27 jberger that is a little bit fucked up
17:28 jberger I don't quite know what to say, in open source, forks happen
17:28 jberger I think its fair for you to make your case known
17:28 jberger obviously
17:38 sri it's like people want me to make a perl is a ghetto blog post
17:39 jberger and there's yelling on #toolchain about other (somewhat related) things too
17:39 jberger its a bad day in open source land
17:40 sri we laugh about the npm problems, but this shit is messed up
17:41 Rubes joined #mojo
17:42 jberger what's funny is that what's being talked about in #toolchain is almost arguing for what happened to npm
17:42 jberger the idea that an owner can't give his perms to whomever (s)he chooses
17:43 jberger yes some authors make bad choices and give up perms to people who shouldn't have them, but cpan/pause policy can't and shouldn't be able to do anything about that
17:43 jberger anything else is closer to what just happened on npm
17:44 preaction there's another thread ongoing on cpan-workers@perl.org about the same thing
17:45 jberger if you are going to depend on a module in an open source world (and not pin/bundle your dependencies) you have to make a choice to trust the author/owner
17:46 jberger that includes trusting that they don't irresponsibly throw away their module (like npm just saw or like handing ownership to someone who wrecks the code)
17:46 jberger but also just that they won't go off the deep end
17:46 jberger I could make one of my modules run malicious code if I wanted to, but my users trust that I wont
17:51 mcsnolte joined #mojo
17:56 csroli joined #mojo
17:58 abra joined #mojo
17:59 dod joined #mojo
18:02 Rubes joined #mojo
18:03 sri i miss the days when there was not as much political bullshit around open source projects
18:04 jberger that I can highly second
18:06 sri not even sure why i'm still doing this
18:06 sri i'm not profiting financially, and it's rarely fun anymore
18:08 csroli Hello! What is the recommended way of making complex html tag helpers? Do I have to use the Mojo::Dom module's tree format?
18:09 sri instead you have to deal with jerks like Grinnz, that just take your code an repackage it, without any respect for the years of work that went into it
18:09 sri no, i do not like Grinnz anymore
18:13 Rubes joined #mojo
18:13 sri and people think it's funny to silence your criticism of such behavior
18:13 sri maybe this is it for me
18:16 genio Well, I doubt my opinion will make you feel better, but I, for one, appreciate your work and thank you for making an awesome dist that makes my life easier.  It may not always get mentioned, but many people appreciate your work
18:16 neilhwatson ++
18:18 genio So, please don't let the negatives stop you from doing something you obviously do very well.  You and your work are a great benefit to the Perl community as a whole
18:23 CandyAngel okay, I'm going to have a go at using Redis for my IRC notifier. Looks like it can do queuing for non-connected clients..
18:35 mdom genio: I fully agree! There's almost no new project where i don't list some mojo module as it's first dependency.
18:35 mdom sri: Thanks!
18:43 asarch joined #mojo
19:03 CandyAngel sri: Definitely remember that not everyone is forking Mojolicious. My OpenHMD::OO modules just depends on Mojolicious for the bits I use in it
19:19 Rubes joined #mojo
19:24 jberger tempire: ping
19:25 jberger marcus: ping
19:27 tempire pong
19:50 s1037989 sri++
19:59 disputin joined #mojo
20:00 ivi joined #mojo
20:11 Rubes joined #mojo
20:17 lluad_ joined #mojo
21:15 sugar joined #mojo
21:17 irqq joined #mojo
21:26 Rubes joined #mojo
21:30 s1037989 I'm creating Mojo::Sendgrid, an implementation for the Sendgrid API using the Mojo framework.  I want to be able to send requests per the API in a non-blocking fashion using Mojo::UserAgent.  Can someone look at my module and see if it's ok and offer any feedback?  https://gist.github.com/s1037989/c7e911fa61ed7d1651f9
22:11 irqq joined #mojo
22:25 cpan_mojo Dist-Zilla-Plugin-Stenciller-MojoliciousTests-0.0200 by CSSON https://metacpan.org/release/CSSON/Dist-Zilla-Plugin-Stenciller-MojoliciousTests-0.0200
22:26 HtbaaPi joined #mojo
22:51 good_news_everyon joined #mojo
22:51 good_news_everyon [mojo] jberger pushed 1 new commit to master: https://git.io/vabSx
22:51 good_news_everyon mojo/master 8f6a052 Joel Berger: Added an official policy on forks
22:51 good_news_everyon left #mojo
22:53 sri jberger++
22:53 jberger I think it is important to link these irc messages from last december
22:54 jberger http://irclog.perlgeek.de/mojo/2015-12-05#i_11662945
22:54 jberger http://irclog.perlgeek.de/mojo/2015-12-05#i_11663097
22:54 jberger so this is not new, just newly codified
22:56 jberger personally I found some guidance in this blog post: https://jamesdixon.wordpress.com/forking-protocol-why-when-and-how-to-fork-an-open-source-project/
22:56 good_news_everyon joined #mojo
22:56 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vab99
22:56 good_news_everyon mojo/master 2ed9196 Sebastian Riedel: fix a few typos
22:56 good_news_everyon left #mojo
22:57 jberger sri: one of these days I'll add a . after the changes entry
22:57 jberger :s
22:57 sri i'll belive it when i see it :)
22:59 jberger also want to note that there are approved forks in existence, for example vicash's Minion::Backend::Pg91
22:59 sri these kinds of forks are a surprisingly perl specific problem
23:01 sri i also want you to know that i take pleasure in the fact that the shortcomings of cpanratings i complained about recently, prevented an angry mob from being able to silence me http://cpanratings.perl.org/dist/DOM-Tiny#12742
23:03 genio No way to see up/down votes a comment?
23:04 genio * see who
23:05 sri at least i've been unable to find forks in the ruby and python worlds that were made for the sole purpose of changing the distribution format
23:05 sri genio: nope
23:06 sri unless someone decides to leak the data
23:08 genio curious.  You can't up/down vote without a login, yet there's no visible vote history.
23:09 sri the whole system is ridiculous, one yes equals like four no votes
23:17 cpan_mojo Mojolicious-Plugin-BootstrapHelpers-0.0201 by CSSON https://metacpan.org/release/CSSON/Mojolicious-Plugin-BootstrapHelpers-0.0201
23:22 avenj left #mojo
23:31 anonymous joined #mojo
23:32 anonymous is the reason for DOM::Tiny because of wanting Perl v5.8.x compatibility?
23:33 anonymous Mojolicious requires minimally Perl v5.10.1.
23:34 genio anonymous: Probably best to search through the channel log than to rehash the conversations.
23:34 jberger it couldn't have been an initial goal https://metacpan.org/changes/distribution/DOM-Tiny#L8
23:34 jberger oh this is too bad: http://theconcourse.deadspin.com/batman-v-superman-is-v-bad-1766555948?rev=1458753430696&amp;utm_campaign=socialflow_deadspin_twitter&amp;utm_source=deadspin_twitter&amp;utm_medium=socialflow
23:34 anonymous It's been a sad day seeing this today and the negative review. But, I did not know the history either. Perhaps, many folks do not, unfortunately.
23:35 anonymous thanks. not easy to search though. will read through the links provided.
23:36 jberger forks aren't something we can prevent, it is open source after all, but we can try to discourage them especially where there are no tangible benefits
23:36 anonymous Ah, jberger, missed that in the change log.
23:36 anonymous :(
23:37 jberger actually, one other point, mojolicious often was accused of being anti-cpan for its reinvention of wheels
23:38 jberger and yet copying someone's code just to distribute it differently is a rather anti-cpan thing I would think
23:41 anonymous ah, there can be so many interpretations of it all. jberger++.  And the sad thing of it all is possibly innocent bystanders not knowing what to do.
23:42 dvinciguerra joined #mojo
23:42 jberger the average mojo user doesn't need to know anything
23:43 anonymous thank you for the clarification
23:44 jberger to be clear I was even careful to put in "public forks" because I don't care if you need to inline some changes into say Mojo::JSON in a company project for some reason
23:45 jberger that can't be handled here or needs fat-packing in a super tiny way for some reason
23:45 jberger of course if there are bugs I hope those would be reported in any case
23:45 jberger you know what I mean :-P
23:45 jberger I'm tired, its been a long and stressful day
23:45 anonymous joined #mojo
23:48 anonymous I want to apologize SRI. I gave one down vote because of thinking DOM::Tiny was created due to wanting Perl v5.8.x compatibility and could not understand why that isn't allowed. But jberger pointed out that wasn't the main reason. :( I'm really sorry SRI.
23:49 anonymous I made a mistake and feel bad about that.
23:49 anonymous :(
23:51 anonymous I was able to change my vote and did so just now. It can take a couple hours before the change is reflected.
23:52 anonymous This has bothered me all day. Am not sure what side to choose sometimes. Thank you jberger for clarification on the matter.
23:53 zivester joined #mojo
23:55 Grinnz_ I am saddened by the contentious direction of the discussion, and I regret that my actions led to it, but I continue to intend to forward any bug reports should they occur. 5.8 compatibility was an initial reason, but the first release didn't achieve it. That is all I wish to say on the matter.
23:55 anonymous joined #mojo
23:57 anonymous will breaking Mojolicious into 2 modules or small number help?  Basically, allowing some parts to run on Perl v5.8.x? Will that help solve some problems.

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