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

IRC log for #mojo, 2016-03-06

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

All times shown according to UTC.

Time Nick Message
00:34 disputin joined #mojo
00:55 jberger bpmedley: I think the problem is the flock
00:55 jberger But all I wanted was to discard the log so unsubscribe was the right option
00:57 jberger sri: am I missing something?
00:57 sri ?
00:57 jberger I read that earlier and didn't see what was surprising about it
00:57 sri i have no idea what you two are talking about
00:58 jberger No I was referencing your article link
00:59 jberger Sorry I switched topics too quickly
01:00 jontaylor joined #mojo
01:05 jberger ok, let me ask it differently
01:05 jberger sri: what do you find curious about that article?
01:06 jberger it seemed pretty expected to me
01:06 jberger and yet if it was curious to you and mauke it makes me wonder if I should be more curious too
01:07 sri that ${...} is actually a block, not just an operator
01:07 sri it looks like a circumfix operator
01:09 jberger I guess to me it always seemed to me that $ is the operator and it takes a block
01:10 jberger and that because $$ref works so $ must be the operator
01:10 jberger I guess there's no reason that that had to be true
01:11 jberger anyway, on a completely different subject
01:11 jberger https://github.com/jberger/Mojo-ACME/search?l=perl6
01:11 jberger sigh
01:11 jberger my totally perl5 project is now 20% perl6
01:11 jberger haven't we given perl6 enough grudging support?
01:11 jberger argh
01:13 mattp_ jberger: howd that happen
01:14 jberger mattp_: github's indexer has been having a pretty hard time
01:14 jberger https://github.com/github/linguist/issues?utf8=%E2%9C%93&q=is%3Aissue+perl6+
01:15 jberger but 20% seems excessive
01:15 jberger hahaha mojo is even worse now
01:15 jberger 23.5% perl6
01:15 jberger \o/
01:16 jberger sri: guess you don't need to port mojo to perl6 after all!
01:16 jberger :p
01:17 sri yea, so much stuff is misinterpreted as perl6
01:18 sri i bet actual perl6 usage is pretty much non-existant
01:18 sri s/a/e/
01:21 mishanti1 Perl 6? Is that the unicorn the neckbear hipsters keep obsessing about? I feel I've heard people going on and on and on about i forever.
01:23 jberger oh neckbears! run away!
01:23 mishanti1 Hah! Well spotted.
01:23 mishanti1 ANd no, it was not intentional.
01:24 * jberger finally is trying to trim the neckbeard actually
01:24 mishanti1 Not trying to trim the neckbear?
01:24 jberger that takes special training and gloves and things
01:24 jberger I'm not qualified :-P
01:25 mishanti1 I have gloves you can borrow if you want to have a go at it anyway. :)
01:25 mishanti1 I'm sure I have some proddy-thingies as well.
01:25 jberger nope, I'm too scared
01:25 * jberger runs away again
01:26 mishanti1 Yeah. I guess stabby thingies is better than proddy thingies.
01:26 * sri wrote most of this patch... but doesn't like it much https://github.com/kraih/mojo/pull/929
01:27 s1037989 sri: bummer...  wish there was something I could do to help, but you saw my first attempt!  :O
01:28 jberger do you have to set the context each time?
01:28 jberger I see delete $self->{context}
01:28 sri btw. the context needs to be reset so we don't leak stash data in EPRenderer
01:28 jberger eeeee
01:28 sri it's not even relevant to Mojo::Template itself
01:29 jberger oh I'm not getting a good feeling about that
01:29 sri thing is, if you reset it in EPRenderer manually, you can leak if an exception gets thrown ;p
01:29 sri so, yea, it's not elegant at all
01:30 jberger the only way I could see that working work be passing it to the actual render
01:31 jberger but the arguments to render are already used up
01:31 sri yea, that was my first thought too
01:31 sri and yea, it would be a mess
01:31 sri if we could start from scratch it would be easy
01:32 jberger you could add a render_with_variables
01:32 jberger or some such
01:32 sri not so easy
01:32 sri you have 3 methods that can render
01:32 sri render, render_file and interpret
01:33 sri render a scalar, render a file, render whatever we rendered before again
01:33 jberger right
01:34 jberger the thing is, its a feature that would be nice, I've wanted more EP-like Mojo::Template in the past too
01:34 jberger but it seems like that's gonna be a lot of work
01:34 sri reminds me that i always wanted to rename ->interpret
01:35 sri i'm totally ok with having context support in Mojo::Template, it just can't be too expensive
01:35 jberger well I'm mildly +1 on the concept and so far I'm -1 on that implementation :s
01:35 s1037989 Hey...  I've got a few hundred bucks I've been meaning to dump into bountysource...  Maybe it could be applied to that??
01:36 jberger woah, the stakes just went up
01:36 s1037989 LOL!
01:36 sri hehe
01:37 s1037989 It's totally not like that big of a deal to me, but I think it'd be a great feature.  And I like the idea of the money that I want to donate anyway getting applied to something specific.
01:39 jberger my $rendered = do { no strict; local ${$template->namespace . ":$_"} = $context{$_} for keys %context; $template->render };
01:39 jberger ish
01:40 jberger not saying that's an implementation for in the module, it would have all the same problems
01:40 sri i guess it depends on the scope, untangling the api to make context support clean, should be possible in a few hours
01:40 jberger I'm saying that's something that would be possible(-ish) when using it
01:40 sri but you won't be able to move the helpers
01:40 sri jberger: you don't want namespaces based on context
01:41 jberger no certainly not
01:41 sri leaks leaks leaks
01:41 jberger I'm saying that's a user-level way to hack the variables in at their level
01:41 sri eww
01:41 sri i misunderstood the intention of your one-liner
01:41 sri this is worse :)
01:42 * jberger loves local symbol table hacking :D
01:42 jberger http://irclog.perlgeek.de/mojo/2014-01-26#i_8178303
01:43 sri btw. the big problem with adding helpers to Mojo::Template is actually performance, it would make ep templates quite a bit slower
01:43 sri because right now we do that kind of symbol table hacking with a namespace shared by all templates
01:43 s1037989 What makes it not slow with the way it's done now?
01:44 jberger and not only that but the old helpers way scales badly with more helpers
01:44 sri all ep templates use one namespace, and we only import helpers once into it
01:44 jberger while the current way doesn't care
01:44 sri right
01:45 s1037989 Would it reduce performance only if you *used* helpers?  And if not, not have an impact?
01:45 sri we always have helpers
01:45 jberger s1037989: but helpers are shared between templates
01:45 jberger in ep that is
01:45 jberger and clearly that can't generally be the case in Mojo::Template
01:46 sri and like jberger said, it's not just an overall performance loss, but also makes every new helper expensive, while currently you can have as many helpers as you like, and it wouldn't care
01:47 s1037989 Well...  like I said I was going to dump some money in any way.  And this reminds me to do it.  If you guys can make it work, that'd be a very happy use of my monies!  If not, whatever you see fit!  As always, thank you all for all your wonderful work on this project!
01:48 s1037989 I'd say if there's anything I can do to help, please let me know...  But I'm a user developer, not a developer developer!  :D
01:49 sri developing developers
01:55 sri the EPRenderer/EPLRenderer relationship makes api changes much harder too
01:56 sri hmm, that's very fixable
02:02 jontaylor joined #mojo
02:11 sri Mojo::Template has not gotten a lot of love recently, i suppose there's more that could be done to make it more fun standalone
02:13 s1037989 Yeah!!  Context, helpers, and handlers were on my list...
02:13 sri what are handlers in that context?
02:15 s1037989 If I understand correctly, right now I have to specify the specific file name "template.html.ep".  I like how in a Mojo app I can just say "template" and provide a format, and it'll pull up template.html.ep or template.html
02:15 s1037989 Does that make sense?
02:16 jberger s1037989: that doesn't apply here
02:16 s1037989 Yeah, I thought that might be the case.  No biggie!
02:17 jberger s1037989: I'm curious, what are you using Mojo::Template for
02:17 jberger (Not that using it standalone is strange, I've done it plenty)
02:18 s1037989 Probably something stupid...  :)  But I'm building a base class model where I define my SQL queries in templates.  There may be problems with the strategy, but by and large it's working for me.
02:19 s1037989 Like Model::Users, e.g. in Mojo::Pg's example, but rather than providing the SQL in the the method, I'm calling a method via AUTOLOAD and it pulls the correct SQL template.
02:20 sri think a context hash can work in Mojo::Template with an attribute like we have for auto_escape, where we switch between normal list of args to a context hash
02:21 sri Mojo::Template->new(context => 1)->render('<%= $test %>', {test => 'whatever'});
02:21 s1037989 That would be wonderful!
02:22 sri the way we handle $c/$self needs to be changed, but that's fine if EPRenderer/EPLRenderer get refactored ;p
02:23 sri so, it should actually be possible without a performance loss
02:23 s1037989 I don't understand the use of the name 'context'.  Does that apply to providing both stash contents as named variables as well as making helpers available?
02:24 jberger I still have one fear, we still get lots of questions about default stash values in ep
02:24 sri no, i think helpers are impossible
02:24 sri context is just an arbitrary choice
02:24 s1037989 <%= $test %><%= some_method_in_my_class %>
02:24 jberger I think we would see similar requests about this context hash
02:25 sri i mean... Mojo::Template->new(context => 1)->render('<%= $test %>', {test =>  'whatever'});
02:25 jberger Of course they could just merge the user's context with a hash of defaults
02:25 sri oops
02:25 s1037989 I wouldn't link variables and helpers...  But in talking about variables, I saw you guys use the word helper a lot.
02:25 sri copy pasta fail
02:26 sri Mojo::Template->new(context => 1)->render('<%= $test->(...) %>', {test => sub {...}});
02:26 sri that would already be possible
02:26 s1037989 To be clear: I wouldn't instinctively lump variables and helpers together with my expectations of this "context" feature.
02:27 s1037989 Perfect!  That would surely solve my "helper" needs.  By that, I just mean want to get access to my module methods within a template.
02:28 s1037989 Sorry, my vocabulary probably needs to be broadened significantly.  I may be using incorrect terms from time to time.
02:28 jberger s1037989: you could also do like ep does and use a namespace that has functions already installed
02:30 s1037989 Works for me!  Whatever sugar Mojo::* can bring to the table will be great, and whatever is possible for me to do on top is fine.  I would just need to know *how*.  So either built in functionality or cookbook...?
02:30 sri that is actually an interesting topic
02:31 s1037989 I like interesting topics...  What is?
02:31 sri Mojo::Template modifies the namespace a little when it compiles a template
02:31 sri "use Mojo::Base -strict; no warnings 'ambiguous';"
02:32 sri that may or may not be localized to a scope
02:32 sri i'm not actually sure
02:32 sri so, if you did Mojo::Template->new(namespace => 'main'), would it have an effect on the outside world?
02:33 jberger Pragmata are lexical to an eval
02:34 sri same for block and string eval?
02:34 jberger Yeah
02:34 jberger 90% sure
02:35 sri hehe
02:36 jberger Think about it this way, they are compile time operations
02:36 sri this little edge case comes to mind https://github.com/kraih/mojo/blob/master/lib/ojo.pm#L18
02:36 jberger So it must treat string eval as a scope
02:37 jberger Hmmm
02:51 sri i do wonder what the most common use cases are for standalone Mojo::Template
02:51 sri like, maybe something common enough for a shirtcut function
02:51 jberger I use it for JavaScript in my phantom module
02:52 sri s/i/o/
02:52 sri don't cut your shirts
02:52 jberger Especially not the mojo shirts! :o
02:53 sri use Mojo::Template 'render_template'; my $output = render_template('<%= $test %>', {test => 'whatever'});
02:54 s1037989 Speaking of shirts...!  I saw not too long ago in #mojo that someone said no one bought the glow in the dark tie die raptor shirt.  I did!  And I love it!  Second favorite to the rainbow puking unicorn raptor.
02:54 sri but stuff like auto_escape would have to be clear
02:54 sri s1037989: i could swear none of them sold! :O
02:54 sri then you've got a pretty unique shirt
02:55 s1037989 Weird!  Check again!  I bought it around christmas time.
02:55 sri to be fair, the spreadshirt ui is.... not great
02:55 s1037989 I'll go tweet it!  :D
02:56 sri recently someone from japan bought puking uniraptor hoodies... and i swear i never made those... no clue how that happened either
02:56 sri raptors... find... a... way
02:57 jberger Malcolm wad right!
02:57 jberger Was
02:58 jberger Blah blah chaos theory blah blah
02:59 s1037989 The glow in the dark is super bright.  Surprises me every time I walk into a dark room!
02:59 sri nice
03:00 sri i'm about to get some normal tie tye shirts for myself
03:02 s1037989 Twitter hashtag mojo or mojolicious?
03:02 sri mojolicious
03:04 sri is it just me or has the mustache template language kinda vanished?
03:05 sri (i mean on the server side)
03:06 sri for a time it was all the rage
03:07 s1037989 Seems like I heard it raged for about a month.  And then the rage was gone.  And so I never got around to looking at it.  And it's been gone from my memory ever since!
03:10 sri i remember how everybody loved it because it works client and server side :)
03:16 s1037989 Isn't that why everybody loves node, too?
03:17 sri used too, maybe
03:17 sri actually havn't heard much about meteor.js recently either
03:18 sri that used to be the poster child of that movement
03:19 s1037989 This past summer I outsourced a project through Toptal and they were really trying to push meteor on me.  They really felt that was the way to go.  I had described my project and wanted a Mojolicious backend.  They really wanted to do meteor.  It was neat, but it seemed complicated.  But I had zero experience with it.
03:20 s1037989 ...so of course it would seem complicated.
03:22 jberger I wonder if es6 might bring some life back to server side js
03:22 sri think meteor.js still requires mongodb... so...
03:22 jberger But yah I don't see much momentum there lately
03:23 s1037989 I had tried to get into mongodb when ou were pushing Mango.  I really struggled with it.  :(
03:23 jberger Facebook/react has some system for shared client/server side stuff doesn't it?
03:24 sri s1037989: haha, in the thumbnail your shirt looks burned
03:24 s1037989 Oh, the dark edge of the sleeve??
03:25 jberger Link?
03:25 sri and the folds at the bottom
03:25 sri looks really nice in the full image though, me wants
03:26 jberger Oh sri, btw, the frosty mug is really nice
03:26 s1037989 :D  Originally I had the sleeves down, but then you couldn't even tell it was a shirt!
03:26 * s1037989 loves the frosty mug!
03:26 sri wasn;t sure if i take blue or black... but that's settled now... definitely black :)
03:26 jberger If I had a complaint it's that the image is a little small
03:26 jberger But it looks good
03:26 jberger And the mug is high quality
03:29 s1037989 I also bought the teddy bear for my wife for valentine's and the stocking cap for these cold winter days!
03:29 s1037989 Just about everything in my house in Mojo branded now!  :P
03:30 sri lol
03:30 * sri looks around... why am i laughing...
03:30 sri just about everything here too ;p
03:31 s1037989 haha!
03:32 sri even my little nephew has baby clothes with pirate clouds
03:34 s1037989 That's a great idea!  I'll start get that for gifts for my nieces and nephews.  Brilliant, actually!  Every year I always pick a theme gift idea to get them all.  Next year it's mojo, no doubt!!
03:48 noganex_ joined #mojo
03:57 jberger Hahaha
03:57 jberger zomg! robots have families!
04:01 sri http://i.imgur.com/5oHUZ.png
04:35 ichi joined #mojo
05:13 sri hmm, i guess Mojo::Template could also generate a little more optimized code
05:14 sri a hash slice for initializing the variables should be faster
06:11 jontaylor joined #mojo
06:49 Vandal joined #mojo
06:53 dod joined #mojo
06:58 dod joined #mojo
10:02 sri yea, looks faster
11:14 ichi joined #mojo
11:44 ichi joined #mojo
11:57 good_news_everyon joined #mojo
11:57 good_news_everyon [mojo] kraih pushed 4 new commits to master: https://git.io/v2AEX
11:57 good_news_everyon mojo/master af1c5e8 Sebastian Riedel: add support for named variables to Mojo::Template
11:57 good_news_everyon mojo/master 7a1e50d Sebastian Riedel: more generic example
11:57 good_news_everyon mojo/master 29288f4 Sebastian Riedel: a few more named variable tests
11:57 good_news_everyon left #mojo
11:59 sri liked $mt->vars(1) more than $mt->context(1)
11:59 jontaylor joined #mojo
12:00 sri been measuring a performance gain of up to 15% from 6.53
12:01 sri one of the benchmarks https://gist.github.com/anonymous/3a33cbed156ebef93923
12:02 sri this is how variables are generated now "my ($bar,$baz,$foo)= @{shift()}{qw(bar baz foo)};"
12:03 sri one thing i'm still unsure about is the name of the new method
12:03 sri $mt->run
12:06 sri $mt->parse('<%= 1 + 1 %>')->run;
12:08 sri s1037989++ # thanks for sponsoring
12:11 sri maybe for 7.0 we can consider if vars(1) becomes the default
12:14 sri btw. the deprecations are because those methods are pretty much useless and limit the possibility of optimizations
12:15 sri ->compile would now even require an argument to be able to compile the code with variables... which is really hard to explain in the docs
12:15 sri so it just makes sense to remove
12:19 odc joined #mojo
12:23 good_news_everyon joined #mojo
12:23 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/v2Aze
12:23 good_news_everyon mojo/master e535cbc Sebastian Riedel: slightly less verbose examples
12:23 good_news_everyon left #mojo
12:34 good_news_everyon joined #mojo
12:34 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/v2AzB
12:34 good_news_everyon mojo/master 136a138 Sebastian Riedel: the code name is not important anymore
12:34 good_news_everyon left #mojo
12:35 meshl joined #mojo
13:20 sri hahahaha https://twitter.com/sonicadvance1/status/706219050473549824
13:28 asarch joined #mojo
13:33 neilhwatson joined #mojo
15:01 neilhwatson joined #mojo
15:24 jberger Hehe
15:25 jberger Btw I like the patch, though I might bikeshed on the name
15:26 jberger What about execute? It mirrors DBI's prepared statement execute
15:27 jberger Both are words that seem too much like process control but execute has the DBI precedent
15:28 sri was my first thought too... but $mt->parse('...')->execute doesn't feel right
15:28 sri maybe it actually was DBI that spoiled it for me ;p
15:28 jberger what about being really semantic? reuse
15:28 sri never felt right there too
15:29 sri it's not just for reuse
15:29 jberger Or again or something
15:29 jberger Nah
15:29 jberger I don't actually like again
15:29 sri hahaha
15:29 sri my first version used ->again
15:29 jberger ENOCOFFEEYET
15:30 sri but
15:30 jberger nice
15:30 sri Mojo::Template->new->parse(...)->run is a thing too
15:30 sri Mojo::Template->new->parse(...)->again
15:30 sri doesn't look right
15:31 sri Mojo::Template->new->parse(...)->process
15:31 sri old school
15:32 jberger Hmmm process isn't bad
15:32 FloydATC joined #mojo
15:33 jberger gods the synonyms for "render" are terrible
15:36 sri yea, i guess process is the best so far
15:37 FloydATC With Mojo, what is the proper way to trigger a request every n seconds unless it's already running?
15:37 good_news_everyon joined #mojo
15:37 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/v2ASv
15:37 good_news_everyon mojo/master 954a652 Sebastian Riedel: rename run method to process
15:37 good_news_everyon left #mojo
15:38 jberger a few things from more googling: depict, restate
15:38 jberger I think I'm in favor of process
15:38 jberger man english needs more words for render
15:38 jberger sri: is there some ridiculously long German word for render ? :-P
15:39 sri i'm sure there is
16:22 dvinciguerra joined #mojo
17:22 dod joined #mojo
17:22 bpmedley FloydATC : I'm confused.  What do you mean?
17:36 PryMar56 joined #mojo
18:23 preaction FloydATC: use a state variable in a timer callback perhaps?
18:52 s1037989 sri: Thanks for acting on that so quickly and pushing out a really solid solution!!  I was always confused by the parse/compile/build/interpret.  Seemed like too many steps!  I like how it's condensed now.  And the performance gain is a big bonus!!
18:57 s1037989 ->rerender would be good if it was a word and didn't look funny!  Dang it!
19:02 jberger I thought about that one too
19:03 vanHoesel joined #mojo
19:29 dotan joined #mojo
19:55 lluad joined #mojo
20:12 meshl joined #mojo
20:25 davido joined #mojo
20:37 PryMar56 joined #mojo
20:38 vanHoesel joined #mojo
20:43 janus joined #mojo
20:45 janus joined #mojo
20:48 vanHoesel joined #mojo
20:48 janus joined #mojo
20:49 nicomen joined #mojo
20:58 lluad joined #mojo
21:06 Adura joined #mojo
21:28 cpan_mojo App-txtnix-0.06 by MDOM https://metacpan.org/release/MDOM/App-txtnix-0.06
22:10 lluad joined #mojo
22:12 vanHoesel joined #mojo
22:22 vanHoesel1 joined #mojo
23:51 meshl joined #mojo

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