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

IRC log for #mojo, 2017-01-02

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

All times shown according to UTC.

Time Nick Message
00:03 sri mostly been using Path::Tiny, and even though some of the api is a little clunky it worked well enough, but after the whole DBIx::Class thing i'm phasing out xdg modules from my code... so i'm getting more and more intersted in a sleek alternative
00:36 jberger That's interesting. I know some people use Mojo::Asset::File for more than just assets at times. Might be nice to have a proper module to encapsulate that
00:40 sugar joined #mojo
01:48 aborazmeh joined #mojo
03:14 noganex joined #mojo
03:56 asarch joined #mojo
04:33 aborazmeh joined #mojo
05:04 dboehmer_ joined #mojo
07:10 khfeng joined #mojo
07:12 trone joined #mojo
07:25 sugar joined #mojo
07:31 Vandal joined #mojo
09:32 janl joined #mojo
09:33 sri right, File::Path also goes into the list
09:36 sri actually wasn't sure if it should be an object or a package with utility functions
09:37 dod joined #mojo
09:37 mishanti1 Sometimes I feel like the Chromium devs are just trolling.
09:38 sri but i guess object wins
09:38 mishanti1 https://chromium.googlesource.com/chromium/src/+/29cea456ef3562dd7364e8e6e80aaddc0365a516  <-- broke anchor-links in our API-documentation
09:42 dod joined #mojo
09:48 rshadow joined #mojo
10:15 jamesaxl joined #mojo
10:22 stryx` joined #mojo
11:10 sword_smith joined #mojo
11:10 sword_smith_ joined #mojo
11:28 tchaves joined #mojo
12:08 jamesaxl joined #mojo
12:35 stryx` joined #mojo
12:36 foursixnine joined #mojo
12:43 stryx` joined #mojo
12:46 foursixnine joined #mojo
12:47 sh14 joined #mojo
13:13 dod joined #mojo
13:16 stryx` joined #mojo
13:24 jamesaxl joined #mojo
13:57 gryphon joined #mojo
14:06 sri this is crazy... bitcons are now above $1000
14:07 sri haha... bitcons
14:07 sri !!!
14:19 Zen_ jup
14:19 Zen_ already made some money of it using binary options
14:23 Zen_ I expect another rise when China wakes up
14:27 mmp /b 28
15:32 stryx` joined #mojo
15:44 asarch joined #mojo
15:46 kaare joined #mojo
16:00 ivi joined #mojo
16:31 xdg @sri, sorry to hear you feel that way about my technical work over an unrelated social issue.  But please feel free to use any of the guts you need to avoid File::Spec platform inconsistencies.
16:44 sri xdg: i don't consider it unrelated, like i don't avoid mlehmann code only for technical reasons
16:45 xdg I think his social issues bleed over into his interest/style of support and bug fixing, so is more directly related, but that's really not here nor there.
16:45 xdg I'm sorry to have made (yet again?) a bad impression on you.
16:46 sri while i'm satisfied by andk's response to my concerns regarding pause administration, i still find your DBIx::Class call for votes very troubling
16:46 xdg Nonetheless, if the work I've done -- extracted -- helps you give a better product to the Perl community, I'm supportive of that.
16:48 xdg I would try to untrouble you, but I don't know if you would welcome or reject the attempt at this point. :-/
16:50 sri i would still be interested in knowing why the call for votes was so biased
16:53 xdg I'll try to explain as best I can.  (Background context: I was the one who originally floated the DBIC2 fork idea to the list.)
16:55 xdg The major "problem" I saw at the point I called for the vote was Peter's refusal to provide any details of his plans or manner for interacting with the community or succession (or explicit denial thereof).
16:55 xdg The problem was compounded by some community members viewing that state of affairs as a "plan" in any way comparable to the community governed alternative.
16:57 sri see, this really bugs me, you were supposed to be a neutral mediator acting on behalf of the pause admins, but you let personal feelings affect decisions
16:57 xdg The sequence to that point had been: (1) initial dispute; (2) Peter largely abdicates in the face of community's lack of interest in a freeze; (3) Matt proposes community governance; (4) community largely in favor of community governance...(more coming)
16:58 xdg (5) a couple people say they want a choice; (6) Matt agrees that community should have a choice; (7) Peter's long delayed response is essentially #1.
16:59 xdg To the "neutrality" bit, the PAUSE decision making part was long done.
16:59 sri i don't question that everyone is at fault to some degree
17:00 xdg I will own to a degree of annoyance at (a) having my own time wasted; and (b) a non-proposal proposal that wasn't really a comparable community choice.
17:01 xdg So the "bias" was to try to ensure that the community saw that they were choosing apples/oranges.
17:01 xdg Back at #5, people wanted an alternative *governance* model for community.  At #7, Peter merely proposed the community ratify a fork.
17:02 ribasushi between 6 and 7 mst publishes an email largely consisting of inaccuracies (I am being diplomatic here), to which I try to craft a response, but realize it is a waste of time for which (not responding) xdg thanks me in private, and then turns around and discloses out of context a paragraph from that same communication, which was explicitly followed by "this is not polished, do not disclose"
17:02 sri did you ever say that you were no longer acting on behalf of the pause admins?
17:03 xdg Had the community ratification at #4 not been deferred, they could have made a decision to fork or not entirely within the governance structure they approved
17:03 sri i very much doubt that andk would be ok with biased mediation
17:03 ribasushi I am still going to publish the response when I get a chance, now that the admin overreach took place
17:03 ribasushi anyway got to run to the store &
17:04 xdg I remained involved because Peter had a consciencious objection to transferring permissions himself and insisted a PAUSE admin "push the button".
17:05 sri xdg: the steps that took place don't really concern me, mst had a take back clause, it was enacted, end of story... things derailed... shit happens... the thing that still bugs me is a pause admin mediating in official capacity with a bias
17:06 xdg sri, if I could do it over, I would have transferred permissions to mst after #4 and let him sort it out.
17:07 sri that's what i would have expected, yea
17:07 sri actually, as soon as it was clear the take back clause was real
17:08 jberger I still really would like to see action on an additional level of pause permissions to prevent something like this happening again
17:08 xdg Matt was willing to let the community decide if the take back clause should hold.  Had Peter agreed to transfer permissions based on that, PAUSE admins wouldn't have had to be involved at all.
17:09 jberger as I've said before, I'd like to hand more power over Alien::Base to plicease, but I don't want to lose final say; given this dispute there's no chance I'd do a "gentleman's agreement" as mst and riba did
17:09 xdg The "bias" I was aiming for was to make sure the community knew their decision needed to be about governance, not permissions, and if I leaned to far in getting that across, I regret it.
17:10 xdg I.e. the vote was intended to be a do-over of #4, not a do-over of #1.
17:17 xdg Anyway, I hope that clarifies any bias in the call for votes.
17:17 xdg Now I'm going to get lunch. Happy to read/respond to feedback later. &
17:22 good_news_everyon joined #mojo
17:22 good_news_everyon [mojo] kraih created mojo_file (+1 new commit): https://git.io/vMmUQ
17:22 good_news_everyon mojo/mojo_file e4f7a5b Sebastian Riedel: add a proof-of-concept version of Mojo::File for easier decision making
17:22 good_news_everyon left #mojo
17:22 sri anyway, here's a proof of concept
17:22 sri to get a feel for what we're thinking about
17:25 jberger I like it at a glance
17:25 jberger should we mark it as experimental for a bit?
17:26 sri it's not nearly ready
17:26 jberger of course
17:26 sri just grepped for "use File::" in mojo and put the stuff in a class ;p
17:27 jberger hahaha
17:27 jberger maybe skim Path::Tiny and see if there are other methods that make sense?
17:27 sri regarding portability, i think we can sidestep some of those concerns for now
17:28 sri for our core uses, File::Spec was good enough so far
17:28 sri what concerns me more for now is performance
17:29 sri instantiating so many objects might hurt in some places
17:33 good_news_everyon joined #mojo
17:33 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vMmT5
17:33 good_news_everyon mojo/master 6f233e1 Sebastian Riedel: no longer use the legacy API
17:33 good_news_everyon left #mojo
17:38 jberger I'm a little curious (this is the crazy part of me, perhaps it should be ignored) about incorporating Mojo::Path in this somehow
17:39 jberger I guess they interoperate as strings already
17:43 sri don't go there
17:48 sri those methods would fit better in Mojo::ByteStream, lol
17:48 sri it already has slurp and spurt ;p
17:54 Eke joined #mojo
17:56 karjala joined #mojo
17:57 sri anyway, i would very much appreciate feedback on Mojo::File, especially if we should be having something like that in core in general
17:59 mrallen1 joined #mojo
18:02 batman +1 from me. I like to have methods that die() for me
18:03 batman But I also wonder about speed... not sure where to start to pin point that though.
18:04 sri the "good" thing is that file system i/o is already pretty slow, so odds are instantiating a few objects might be totally irrelevant most of the time
18:04 sri but we do have to make sure
18:12 jabberwok +1 altho a tempfile() that calls File::Temp->new(@_) [for permanently saving uploads with the TEMPLATE parameter] and an alias for File::Basename->fileparse()  would eliminate all my uses of File::*
18:15 sri jabberwok: tempfile would be added as well
18:17 sri funny you mention fileparse
18:17 sri because i just removed the last use ;p
18:18 good_news_everyon joined #mojo
18:18 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vMmLg
18:18 good_news_everyon mojo/master 81fb4f9 Sebastian Riedel: there is no need to use fileparse
18:18 good_news_everyon left #mojo
18:18 sri that one will not be coming to Mojo::File
18:19 good_news_everyon joined #mojo
18:19 good_news_everyon [mojo] kraih force-pushed mojo_file from e4f7a5b to ae679c1: https://git.io/vMmLr
18:19 good_news_everyon mojo/mojo_file ae679c1 Sebastian Riedel: add a proof-of-concept version of Mojo::File for easier decision making
18:19 good_news_everyon left #mojo
18:19 genio File::Basename and File::Spec are already in core, though.  *confused*
18:21 genio as is File::Temp
18:24 sri as are File::Copy and File::Path and and and
18:24 sri and now you're starting to see the point
18:25 sri guess Mojo::Util::files would get moved
18:25 sri and prolly produce a Mojo::Collection of Mojo::File objects
18:27 sri path('/etc')->list_tree->grep('is_file')->join("\n")->say
18:28 jabberwok nice
18:28 genio ah, I just read Mojo::File.  I get it.  I should have actually looked before confusing myself
18:29 sri we actually have uses for ->list and ->list_tree in core
18:31 jabberwok As long as there is a common idiom for saving each of $self->req->every_upload('files') as a permanent, uniquely named file preferably with the user's original extension, I will be ecstatic.
18:31 sri Mojo::Home feels a bit clunky with Mojo::File existing
18:50 trone joined #mojo
18:53 good_news_everyon joined #mojo
18:53 good_news_everyon [mojo] kraih pushed 1 new commit to mojo_file: https://git.io/vMmmq
18:53 good_news_everyon mojo/mojo_file f6451ce Sebastian Riedel: add list_tree method
18:53 good_news_everyon left #mojo
18:57 batman sri: didn't you already optimise how files() was implemented...? thought we had some speed issues when changing how morbo watch files
18:58 batman maybe i don't remember correctly
18:58 sri batman: dunno, maybe you should test ;p
18:58 batman i think maybe i'm confusing myself with how i thought stat() would be slow, while it wasn't
19:07 sri batman: well, now you can test
19:07 good_news_everyon joined #mojo
19:07 good_news_everyon [mojo] kraih pushed 1 new commit to mojo_file: https://git.io/vMmYf
19:07 good_news_everyon mojo/mojo_file 2fbc3f2 Sebastian Riedel: stop using Mojo::Util::files
19:07 good_news_everyon left #mojo
19:10 mishanti1 Yup, definitly buying from bose again. Got my (free) replacement cable today, and it turns out the old cable was faulty. So now I don't have to return my headset. :)
19:18 vicash joined #mojo
19:20 good_news_everyon joined #mojo
19:20 good_news_everyon [mojo] kraih pushed 1 new commit to mojo_file: https://git.io/vMmY7
19:20 good_news_everyon mojo/mojo_file cb2168d Sebastian Riedel: force scalar context
19:20 good_news_everyon left #mojo
19:21 sri (should nobody actually test norbo performance, i'm going to count that as disinterest in Mojo::File)
19:21 sri s/n/m/
19:24 sri my experiment is done, now it's up to the community
19:42 * sri posts https://groups.google.com/d/msg/mojolicious/8ld7jmH-qbg/wO2OCkCsEQAJ
20:17 sugar joined #mojo
20:47 sonicepk joined #mojo
21:01 henq joined #mojo
21:08 Grinnz sri: seems like a nice idea to me. as far as performance, basing it on Path::Tiny is definitely a good idea, as Path::Tiny was borne of the bad performance of Path::Class
21:40 sri technically, it should be faster at the moment
21:41 sri what i'm worried about is all the object instantiation though
22:20 PryMar56 joined #mojo
22:33 ccakes joined #mojo
22:37 xdg @sri, for speed, unless you require the File::Spec that has XS canonpath, avoiding repetitive File::Spec calls (which usually call canonpath 1+ times) is a big speed win
22:38 xdg Path::Tiny aims for a single canonpath call at object creation time to get the path into a known sane state, and then avoids File::Spec like the plague
22:38 xdg I suggest something similar if your needs allow.
22:42 sri when doesn't File::Spec have XS canonpath?
22:50 xdg Has XS canonpath as of 3.47 (Perl 5.22)
22:51 xdg Pure perl before that
22:52 xdg And there's a (trivially minor) CVE on the XS version until 3.62 last year.
22:55 sri that's actually good enough for us, we only fully support the last two major versions of perl
22:55 sri so, working but slow on anything older is perfectly fine
23:08 sri batman: grats on second place :) http://niceperl.blogspot.de/2017/01/10-best-perl-distributions-created-at_2.html
23:10 Grinnz rofl @ first
23:10 sri yea, who could compete with that, definitely in a league of its own
23:13 jberger batman++
23:13 jberger hey I made the list too
23:13 jberger though I bet there are dozens with +5
23:13 jberger I'm going to call that a win for batman actually
23:14 jberger no one is actually USING the thing that won
23:23 sri in february is the next suse hackweek, wonder what i should work on
23:24 sri two possible projects would be unix domain socket support, or blocking websocket support in Mojo::UserAgent
23:24 sri and now i guess Mojo::File
23:25 sri (hackweek is when everyone at suse gets to work on open source stuff for a week)
23:34 genio That's awesome.  I wish $work had something similar
23:39 zivester joined #mojo
23:41 jberger oh neat, they do it all at once?

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