Camelia, the Perl 6 bug

IRC log for #mojo, 2013-01-02

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

All times shown according to UTC.

Time Nick Message
00:13 Molaf_ joined #mojo
00:19 Averna joined #mojo
00:23 connor_goodwolf joined #mojo
01:16 connor_goodwolf joined #mojo
01:29 connor_goodwolf joined #mojo
01:38 chenryn joined #mojo
01:43 amirite memorize helper in ep is really just a cache
01:43 amirite perhaps there should be a default helper that proxies to the user's cache
01:43 amirite similar to memorize
02:03 connor_goodwolf joined #mojo
02:28 guilherme joined #mojo
02:29 guilherme Has anyone here done parallel http requests using the ua from within a Mojolicious application?
02:30 guilherme I'm getting "Premature connection close" from the UA right away after making the non-blocking requests.
02:31 guilherme The UA is not the one from the App. I'm creating a new one.
02:31 guilherme I don't know if that may be a problem.
02:31 amirite joined #mojo
02:35 buu guilherme: Which server is running it?
02:35 guilherme morbo
02:36 buu Morbo is pretty simple..
02:36 buu Try with hynotoad or apache?
02:38 guilherme well, right now I'm using morbo because I'm developing but eventually I will push the code to production which is running on hypnotoad behind nginx.
02:38 buu Sorry, I really don't know much about the innerworkings of morbo
02:38 guilherme ok, I'll try that.
02:43 guilherme in hypnotoad I get a different error saying that there is a Mojo::IOLoop already running... maybe because I'm calling ->wait without the ->is_running check...
02:45 connor_goodwolf joined #mojo
02:47 guilherme nope, same error with hypnotoad... premature connection close.
02:49 amirite joined #mojo
03:04 vervain joined #mojo
03:14 Adurah joined #mojo
03:22 iskyee joined #mojo
03:26 noganex_ joined #mojo
03:33 kitt_vl joined #mojo
03:39 chenryn joined #mojo
04:02 connor_goodwolf joined #mojo
04:29 amirite joined #mojo
04:38 amirite joined #mojo
06:14 amirite joined #mojo
06:20 asarch joined #mojo
06:26 arthas joined #mojo
06:33 amirite joined #mojo
06:49 Vandal joined #mojo
07:28 PanzerBjorn joined #mojo
07:29 PanzerBjorn So, headers... I think I'm doing it wrong. Id there a default helper or something for headers as opposed to creating a Mojo::Headers->new() just to read one?
07:34 PanzerBjorn I'm trying to use $mojo->tx->req->content->headers->x_forwarded_for; and that's just failing on me. =/
07:34 PanzerBjorn (Where $mojo is a Controller)
08:06 d4rkie joined #mojo
08:07 d4rkie joined #mojo
08:30 alnewkirk joined #mojo
08:32 tempire $mojo->$req->headers->header('A-Header')
08:33 tempire er, $mojo->req
08:35 PanzerBjorn Ah, MUCH easier than what I was doing ;D
08:39 PanzerBjorn Okay, so now I'm having an issue with setting a cookie. I set a cookie like this and nothing happens (where $mojo is a Controller): $mojo->cookie(session => $values, { expires => '+1y', domain => (".". $mojo->siteinfo->{tld}), path => '/' });
08:40 PanzerBjorn $values is a string that looks similar to "un:testuser|sp:feed|sid:24687246421".
08:49 tempire why are you setting a cookie?
08:51 tempire just use the session.  it handles all that for you.
08:51 tempire $mojo->session(name => 'value')
08:53 Foxcool joined #mojo
09:01 Miked joined #mojo
09:09 PanzerBjorn Because this is integrating into an existing site with an existing cookie implementation. =/
09:10 PanzerBjorn Yes, Mojo sessions are awesome, and I'd love to use them - will use them in fact once the whole site is converted to Mojo (in like 6-9 months). Until then, Mojo has to play with the existing base.
09:11 PanzerBjorn So, this is to set a cookie that the old portion of the site can recognize.
09:18 iskyee joined #mojo
09:27 SmokeMachine joined #mojo
09:28 SmokeMachine joined #mojo
09:29 PanzerBjorn Okay, so in sandbox testing, I found that 1) Mojo seems to need the value side of the cookie uri_escaped() using URI::Escape and 2) Mojo doesn't set the cookie when the 'expires' hash param is set in the attributes hash. At least that's what it would seem.
09:30 PanzerBjorn Outside of those, seems to work just fine.
09:32 PanzerBjorn Okay, nevermind 1) above, it wasn't the uri_escape that made it or broke it, it was using a method call as the rvalue in the hash definition. Moving the string to a variable made it work.
09:40 sri o/
09:40 PanzerBjorn Uodating an existing cookie also seems to not work...
09:41 PanzerBjorn Updating
09:46 PanzerBjorn Someone posted on a newsgroup that you can delete a cookie this way, but I tried it and it didn't work: my $cookie = Mojo::Cookie::Response->new( name => 'cookie', value => '', expires => -1); $self->res->cookies($cookie);
09:57 PanzerBjorn Well, I can't find anything in any docs or in a Google search on updating existing cookies or deleting existing cookies. =/
09:57 PanzerBjorn Using Mojo.
10:01 PanzerBjorn I need to get to sleep, will leave this window up overnight in case anyone responds. Thanks and cheers.
10:10 espent joined #mojo
10:25 ObseLeTe joined #mojo
10:25 ObseLeTe joined #mojo
10:25 dod joined #mojo
10:46 * sri thinks it might be time for the first release of 2013
10:46 basic6 joined #mojo
10:57 nic aha, PanzerBjorn, was thinking this morning... there might be an easy solution to what you were talking about before
10:57 nic https://metacpan.org/modul​e/Mojar::Mysql::Connector
10:58 nic If you use the helper in that, it caches the dbh, but gives you a new one if the old one dies
10:58 nic (you can force a fresh one via $self->dbh(undef)->dbh;
10:59 nic I know you have your own DBI wrapper class, so you might just want to copy the helper part
11:01 dod joined #mojo
11:32 basic6 joined #mojo
11:55 good_news_everyone joined #mojo
11:55 good_news_everyone [mojo] kraih tagged v3.71 at c7686ed: http://git.io/F2EMwQ
11:55 good_news_everyone left #mojo
11:58 Foxcool_ joined #mojo
12:19 labrown joined #mojo
12:30 sinkovsky joined #mojo
12:35 ObseLeTe joined #mojo
12:43 wircus joined #mojo
12:43 rbmntjs_ joined #mojo
12:44 wircus blah
12:58 Miked joined #mojo
13:52 jnbek^dt joined #mojo
13:53 sergeysinkovsky joined #mojo
14:27 amirite are there any browser detect plugins for mojo already in existance
14:28 connor_goodwolf joined #mojo
14:49 jpn joined #mojo
14:51 vervain It's easy enough to get to the User-Agent string via the agent helper, in conjunction with something like HTTP::BrowserDetect I think you'd be set.
15:01 gryphon joined #mojo
15:13 brrt joined #mojo
15:13 brrt hi #mojo
15:13 brrt i've some things to discuss
15:13 brrt first
15:14 brrt why call yourself a MVC framework when you have no models?
15:14 brrt second, MVC is a huge misnomer for web application frameworks, so don't call yourself that
15:14 brrt third, i actually have implemented something that might be called a Model, and was wondering if you'd care for inclusion
15:15 brrt https://gist.github.com/4428773 - i have some improvements as well as tests for that
15:16 Britzel_ joined #mojo
15:16 brrt fourth, i really like your framework
15:19 amirite building the model yourself is the best part of mojolicious!
15:19 amirite i need to put my mojo related work on cpan
15:19 brrt amirite, not that i don't agree
15:20 brrt but i think we as developers could do with something that helps us 'fix' data
15:20 brrt and i mean fix in the way as 'protect against change / being radically different from what somebody designed'
15:21 brrt if mojo already has an implementation of a user agent and a dom and a router and what more
15:21 sri odds are mojolicious will never ship with a model layer
15:21 brrt sri, i'm not at all advocating a traditional model layer
15:21 brrt where the model also does the storage
15:21 sri but i expect some pretty strong model layer plugins soon
15:22 brrt i'd be interested to see that
15:22 brrt basically, in the other case i'd have it uploaded as something like Model::Tiny, and that would be that
15:27 sri also, why is shipping a model layer a requirement for an MVC framework?
15:30 brrt because of the model name
15:30 sri you make some pretty strong statements, but do very little to back them up
15:30 brrt ok, why mvc is a misnomer?
15:30 brrt that is fair, that is strong indeed
15:30 Foxcool joined #mojo
15:30 Foxcool_ joined #mojo
15:31 brrt mvc implies that we have a view talking to a model possibly via a controller
15:31 jberger brrt: because Perl has CPAN and good CPAN clients there is no reason to limit users to a single model implementation
15:31 jberger Mojolicious is an MVC framework, where you bring your own M
15:32 jberger its expected that there will be an M, it just doesn't come as part of the package
15:32 sri if anything, MVC is a misnomer because the original Smalltalk pattern worked very different from what we currently refer to as MVC web frameworks... but that's a very different discussion
15:32 brrt now, we do have some things that could be called views, but they could also be called templates, and in many frameworks are called so
15:33 brrt we have something that could be called a controller, but /very/ typically they live just as short as their view
15:34 brrt sri, my point is that calling it MVC and teaching people MVC and all that just very much obscures what is going on
15:34 brrt jberger, again i don't disagree about the CPAN thing
15:34 brrt if you don't think that having a fixed idea of what data should look like (which is al i am proposing) belongs in mojo, that is absolutely fine with me
15:35 brrt i have no vested interest in it :-) just thaught it'd be something i could contribute
15:35 sri there is pretty much no consensus on what data should look like
15:35 jberger remember, TIMTOWTDI
15:35 brrt thought
15:35 brrt if you build the application you have the consensus
15:35 jberger Mojolicious::Plugin::ModelBRRT
15:36 brrt also, blessed hash refs seem pretty universal
15:37 jberger as to "object systems" Perl has one for every taste already
15:38 brrt agreed :-)
15:38 jberger :-)
15:39 brrt well, Model::Tiny it is then, thanks at any rate for the awesome framework
15:40 Adura joined #mojo
15:41 * jberger puts on his CPAN minder hat
15:41 jberger just please don't take the entire Model:: namespace
15:41 brrt hmm
15:41 brrt no
15:41 jberger Model::Tiny is probably ok
15:41 brrt is there a separate Tiny namespace?
15:42 jberger ::Tiny is a "pseudonamespace"
15:42 brrt fair enough
15:42 jberger is there any reason not to use Moo as the underlying OO framework?
15:43 brrt what, me? I haven't use Moo or a derrivative ever
15:43 jberger Moose is here to stay, and when the p5mop is finished (next christmas? :-P) things like Moose are going to be even more in vogue
15:44 jberger Moo is designed to gracefully integrate with Moose, but stay minimal until needed
15:44 brrt i see
15:44 jberger Moo is very cool
15:44 jberger Moose is very cool, but heavy
15:44 jberger Mouse is not cool anymore
15:44 jberger Any::Moose is also not
15:45 sri the subroutine signature discussion seems to have had a demotivating effect on the p5mop effort :(
15:45 jberger Moo killed them both, and with surprising speed
15:45 jberger yeah
15:45 sri if in doubt, just use Moose
15:45 jberger sri: after our last conversation, I'm more convinced that I think we need the bdfl to come fix this
15:46 jberger we need Larry
15:46 sri jberger: yea
15:46 brrt he's on #perl6 :-) usually
15:46 jberger I can't believe that no one would have told him what went on
15:46 sri he's too invested in perl6 i believe
15:46 jberger and if they really didn't, I'm not sure I'm the one to tell him (though I did meet him at YAPC this last year)
15:47 brrt i can't believe perl6 made for loops lazy
15:47 brrt god knows why
15:47 jberger sri: its true, but he's the only one that could break the gridlock
15:48 sri maybe rakudo on the jvm will speed things up a bit and we can all migrate :)
15:48 jberger you keep hoping, I'm not holding my breath
15:48 brrt yeah, i find that as likely as chromatic does
15:48 brrt but then again i worked on parrot a bit
15:49 brrt so maybe i'm biased
15:49 sri having a full featured vm to target is pretty big
15:49 sri look at how quickly niecza evolved
15:49 sri or scala/clojure on the jvm
15:50 jberger I wonder what the benefit of a spec-based language is, when the language spec is so hard to implement
15:50 brrt that is true, but the latter two were designed from the beginning to fit in the jvm
15:50 brrt and sorear hasn't universally been happy about niecza, either
15:50 sri or jruby then :)
15:50 brrt jruby has the benefit of people willing to pay top dollar for making a slow language somewhat faster
15:51 brrt which rakudo doesn't have
15:51 sri it's still just one person doing most of the work
15:51 jberger the opensource world gets a queasy feeling when you see opensource on top of closed
15:51 brrt while it will have much of the same challenges
15:51 sri the fact that there is no back and forth between compiler and vm teams is pretty huge
15:52 brrt uhuh
15:52 brrt but then again
15:52 brrt try to develop a vm that will in fact, support perl6
15:52 brrt from the grounds up
15:53 brrt that is not simple, much less so if you don't actually follow the perl6 spec closely
15:53 sri parrot was simply a bad decision, you can't design a vm for a language that doesn't exist
15:53 brrt no, you know what was the bad decision of parrot?
15:53 sri and develop that language at the same time
15:53 brrt a freakin' test suite
15:54 brrt that fixed behavior to what was a good idea 10 years ago
15:54 brrt it slowed down evolution
15:54 brrt ideal world, perl6 and parrot would have co-evolved
15:54 brrt that could've happened
15:54 brrt but parrot got more ambitious, said 'we will run all languages'
15:55 brrt how many flowers do you see that feed butterflies, bees, and hummingbirds all together?
15:55 brrt none
15:55 sri it's not an unreasonable goal, see jvm
15:56 brrt jvm and java co-evolved
15:56 brrt and every other language just took jvm as a given
15:56 brrt there are a /lot/ of pain points in running, say, ruby or python on jvm
15:57 sri i don't think java actually used invokedynamic when it was added
15:57 sri there are features that were added for other languages first
15:57 brrt that is true, yes :-)
16:02 mattastrophe joined #mojo
16:07 jberger brrt: as to your Model::Tiny, (and I'm not trying to be argumentative) is there benefit over using say Moo for OO and say Validation::Class for validation? http://blogs.perl.org/users/al_newkirk/​2012/12/say-it-once-dont-repeat-it.html
16:09 brrt jberger, i'm reading that post as we speak
16:15 jberger hmmmm, old documents for Validation::Class describe how to use it with Moose: http://search.cpan.org/~awncorp/Validation-Class​-7.78/lib/Validation/Class.pm#THE_OBJECT_SYSTEM
16:15 jberger but the newer ones don't
16:21 brrt jberger, ehm, i dunno actually, i'm guessing this is somewhat more tiny
16:22 anewkirk the functionality still exists but the POD about moose compatibility was removed because I realized that mixing them was largely a bad idea
16:23 anewkirk if you want Validation::Class in your moose class try Validation::Class::Simple
16:27 bluescreen joined #mojo
16:41 jberger anewkirk, I have never used Validation::Class mostly because I never have needed it
16:41 jberger and since you are here I can ask:
16:41 jberger is it an object system?
16:41 anewkirk you've never needed input validation?
16:41 jberger I'm mostly a scientist
16:42 jberger my interest in web stuff is just for fun
16:42 jberger and as such most of the data coming in is only what I expect it to be
16:43 jberger BUT, anticipating that this will not always be the case
16:43 jberger since you say that mixing V::C and Moo(se)? is a bad idea
16:44 jberger I wonder how the log chain works, to store data with Moo(se)? but validate with V::C works?
16:44 anewkirk V::C is a light object system designed around user-input
16:44 anewkirk you don't use Moo(se) to store data though
16:45 anewkirk rather to hold objects
16:45 anewkirk one such object could be a V::C instance
16:45 anewkirk (if that makes sense)
16:46 jberger yeah, I used a bad choice of wording, I understand object
16:46 jberger s
16:47 jberger so if I have MyApp::User class using Moo
16:47 jberger and I want to validate a new user's info using V::C
16:49 jberger presumably the credentials are coming from a form
16:50 jberger do I validate the data before making the Moo-based object? (or DBIx::Class etc)
16:51 anewkirk has 'validator' => sub { Validation::Class::Simple->new(params => shift->params()) }
16:51 anewkirk sub create_new_user { if (shift->validator->validate(...)) { ... } }
16:52 jberger ok that makes sense
16:56 wircus "Mojolicious, a leading develop of mobile apps"? http://www.virtual-strategy.com/2013/01/02/2012​-proves-successful-year-app-builder-mojolicious
17:00 mire_ joined #mojo
17:02 jberger wircus, other than that article, I don't see anything else where KeyLimeTie calls themself Mojolicious
17:02 sri odd
17:07 vervain That article reads to me like a writer got completely confused by the context of what they were told.
17:08 jberger anyway, thanks anewkirk!
17:10 jberger http://service.prweb.com/contact-us/
17:11 vervain PrWeb... we'll managed to completely hose up your statement and completely misrepresent your brand. :)
17:52 jzawodn joined #mojo
18:03 mattastrophe joined #mojo
18:04 jpn joined #mojo
18:22 PanzerBjorn joined #mojo
18:27 xaka joined #mojo
18:27 rem_lex|pivo joined #mojo
18:36 d4rkie joined #mojo
18:40 xaka joined #mojo
18:45 good_news_everyone joined #mojo
18:45 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/oqTogQ
18:45 good_news_everyone mojo/master 7851e9b Sebastian Riedel: document error event in Mojo::EventEmitter
18:45 good_news_everyone left #mojo
18:50 PanzerBjorn Not sure if anyone is still around, but I still have not been able to figure out how to update existing cookies or clear cookies using Mojo. $self->cookie(...) works great for setting a new cookie (unless you try to provide an 'expires' param) but it apparently doesn't work to update/delete one.
18:58 good_news_everyone joined #mojo
18:58 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/LBn19g
18:58 good_news_everyone mojo/master 063eb19 Sebastian Riedel: better cookie example
18:58 good_news_everyone left #mojo
19:01 ObseLeTe joined #mojo
19:02 PanzerBjorn joined #mojo
19:02 PanzerBjorn ... and Comcast chose the perfect time to drop for 10 minutes. =P
19:03 jberger PanzerBjorn, nobody responded to your last that I see
19:04 PanzerBjorn Oh, how fortunate. ;D
19:04 sri see topic for channel log
19:06 PanzerBjorn Nope, nothing I missed.
19:08 PanzerBjorn I wonder if I can just still use old CGI cookie creation and push that to the cookie header on the response...
19:35 yakubori joined #mojo
19:35 yakubori hello all
19:35 PanzerBjorn o/
19:48 ObseLeTe joined #mojo
19:53 priodev PanzerBjorn, not sure if you fixed your cookies problem already.. anyway..
19:53 priodev perl -Mojo -E 'a("/hello" => sub{$s=shift;$s->cookie(foo=>time,{expir​es=>time+10});$s->render(text=>r([$s->re​q->cookies,$s->res->cookies]))})->start' daemon
20:25 ObseLeTe joined #mojo
21:06 rem_lex joined #mojo
21:06 PanzerBjorn No, I haven't fixed it yet.
21:07 PanzerBjorn And I'm not sure what your code is attempting to show. Setting a new cookie is never a problem in Mojo. However updating a cookie and deleting a cookie don't seem to be possible purely in Mojo.
21:09 gryphon joined #mojo
21:14 PanzerBjorn My opinion is that if you provide syntactic sugar for something as complicated as cookies, it should work for all necessary use cases.
21:15 PanzerBjorn Porting from Perl/CGI to Mojo one would expect that Mojo's cookie capability would be at least as strong as CGI's.
21:16 PanzerBjorn CGI = web toolkit, Mojo = web framework. I'd expect the latter to be more robust and powerful.
21:19 PanzerBjorn (BTW I think Mojo sessions are awesome, and I'd love to be using them instead, but for compliance with an existing site cookies are necessary here. I plan to move to sessions once a full conversion of the existing code to Mojo is possible time-wise.)
21:20 yakubori is there any problem with me bumping mojo by using the logo on a web service i am developing?
21:20 yakubori in terms of IP/License?
21:26 PanzerBjorn Okay, cookie problem solved (sadly) by using CGI->cookie and $self->res->headers->set_cookie(...)
21:27 vervain Yakubori: Explicite permission is always best I guess, but Mojo/licious is Artistic License 2.0.  I my opinion (IANAL) you can use the logo on your site.
21:28 yakubori hmm
21:28 yakubori i suppose i will ask sri when the time comes. thanks vervain :)
21:29 yakubori and I suppose I could donate if I make a nice chuck of change off of it :D
21:29 yakubori *chunk
21:39 vervain PanzerBjorn: Do you need some functionality beyond this: http://pastebin.com/J1YFgYN6
21:42 xaka joined #mojo
22:07 PanzerBjorn Yes I do.
22:08 vervain Do you mind re-explaining, because I must have missed it.
22:08 PanzerBjorn The cookie also needs to be updatable.
22:09 vervain I'm updating the cookie in that example.
22:09 PanzerBjorn You're changing the expiration time, yes. But not the value of the cookie.
22:09 vervain If you run it, and then hit refresh several times you'll see the cookie increment, get deleted, and then get reset and start incrementing again.
22:10 vervain Line 12 is updating the value in the cookie
22:11 PanzerBjorn Your example is not setting a path, tld and expiration for every case though.
22:11 PanzerBjorn Which is something mine needs.
22:12 PanzerBjorn I ran a number of tests last night and no cookie I created through Mojo every actually updated.
22:12 PanzerBjorn s/every/ever/gi
22:12 vervain I fail to see the difference. <shrug>
22:13 PanzerBjorn Though you did point out that expires works differently from CGI's implementation - I had not anticipated that and didn't see any examples of how to use expires properly in Mojo.
22:13 PanzerBjorn CGI uses a relative translation string such as expires => '+1y', looks like Mojo expects a time_t value.
22:14 PanzerBjorn I couldn't find any documentation on that last night.
22:15 DaniBunny joined #mojo
22:16 vervain Mojo::Cookie::Response documents expires.
22:17 PanzerBjorn Yeah, that appeared to me to be a different implementation than $self->cookie(...) though.
22:20 vervain As far as I know Mojolicious::Controller->cookie is a helper for Mojo::Cookie::Request and Mojo::Cookie::Response
22:20 * tempire is anxious to run ubuntu on an android device
22:20 vervain and I throw around the term 'helper loosely'
22:21 * PanzerBjorn nods
22:25 DaniBunny joined #mojo
23:00 PanzerBjorn Time to go dilly dally around at 4500 feet.
23:09 PanzerBjorn Thanks again for the help folks.
23:10 vervain Np. Have fun playing with your dilly dally. :-)
23:44 jzawodn joined #mojo
23:46 DaniBunny joined #mojo

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