Camelia, the Perl 6 bug

IRC log for #mojo, 2012-11-11

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

All times shown according to UTC.

Time Nick Message
00:21 Molaf_ joined #mojo
00:27 coff joined #mojo
01:18 Mike-PerlRecruiter_ joined #mojo
02:14 duncanthrax2 joined #mojo
03:34 noganex joined #mojo
05:52 Polarn joined #mojo
06:08 xaka joined #mojo
06:12 Vandal joined #mojo
06:19 bzero joined #mojo
06:19 yko joined #mojo
06:37 Kulag joined #mojo
06:44 ruz joined #mojo
06:49 Kulag joined #mojo
07:15 ladnaV joined #mojo
07:18 Kulag joined #mojo
07:41 dod joined #mojo
07:46 Kulag joined #mojo
07:58 dod joined #mojo
08:00 mire_ joined #mojo
08:02 robinsmidsrod joined #mojo
08:05 jayallen joined #mojo
08:11 Kulag joined #mojo
08:56 Vandal joined #mojo
09:11 Kulag joined #mojo
09:14 sh4 joined #mojo
09:19 Drossel joined #mojo
09:22 Vandal joined #mojo
09:40 Kulag joined #mojo
09:41 inokenty joined #mojo
09:45 Britzel_ joined #mojo
10:00 Polarn_ joined #mojo
10:03 yakudza joined #mojo
10:05 yakudza_ joined #mojo
10:21 coff joined #mojo
10:22 dpetrov_ joined #mojo
10:32 arthas joined #mojo
10:49 batman joined #mojo
10:52 dvinciguerra joined #mojo
10:57 batman yay! Mojo::TFTPd is on cpan :)
10:57 batman my seventh mojo module on cpan actually... wonder if there's something else that i should rewrite to mojo...
11:20 Foxcool joined #mojo
11:31 sri \o/
11:40 Kulag joined #mojo
12:15 memowe joined #mojo
13:18 Mike-PerlRecruiter_ joined #mojo
13:30 Polarn joined #mojo
13:56 batman i think i'm in the same situation as murray now... getting Can't call method "res" on an undefined value in Mojolicious/Controller.pm
13:56 batman i'm doing Mojo::IOLoop->timer(4, sub { $self->redirect_to("..."); });
13:56 batman and $self->render_later; before the timer()
13:57 batman it only seem to happen sometimes and not always
13:57 sri $self->{tx} is weakened
13:57 batman could it be that mojolicious trigger the inactive timeout callback before timer() is reached?
13:57 batman how do i keep $self->{tx} alive?
13:58 sri if the daemon destroys its reference to the tx it vanishes
13:58 sri make a reference
13:59 batman ok. so i can simply do $tx = $self->tx; and "undef $tx" inside timer() ?
13:59 sri sure
13:59 sri we've been looking for a better solution than weakening it for over a year now
13:59 batman seems hackish :)
14:00 batman testing now
14:00 sri so far nobody came up with something
14:01 sri well, pretty much nobody actually groks that stuff
14:01 sri https://github.com/kraih/mojo/blo​b/master/lib/Mojolicious.pm#L146
14:01 sri the line in question
14:02 batman who's keeping tx around other than $c ?
14:02 batman the daemon?
14:02 sri if you decide to work on a solution, make sure to do lots and lots of find_cycle tests in t/mojolicious/longpolling_lite_app.t
14:02 sri daemon
14:03 batman ok
14:27 gryphon joined #mojo
14:35 rhaen_fork joined #mojo
14:41 mire_ joined #mojo
14:43 ryozi joined #mojo
14:51 ObseLeTe joined #mojo
15:51 batman how can i skip a module from a given os? (cpan testers)
15:51 batman i'm getting fail on freebsd all the time, and i really don't care :P
15:54 motoboi joined #mojo
15:59 Foxcool joined #mojo
16:22 Foxcool_ joined #mojo
16:22 cosimo_ joined #mojo
16:39 jberger joined #mojo
16:39 jberger is there some reason that Mojo::Collection overloads 'bool' to return 1?
16:40 jberger it seems to me that it might overload bool as sub { !! shift->size }
16:41 sri that seems illogical
16:41 sri [] is always true
16:42 jberger but people don't test [] for truth, they test @{[]}
16:43 sri then testing @$collection as well would seem logical
16:43 jberger the use case I'm thinking of is `if $dom->find(...)` or `if $dom->find(...)->grep{qr/.../}`
16:44 jberger unless there is some reason to test it and expect true, I think it would be a nice helper
16:44 sri then add ->size
16:44 jberger right, I know
16:44 jberger you are right from a pure comparison
16:45 jberger I was just wondering if the convenience of it would be nice?
16:45 sri collections are meant to be as close to normal arrayrefs as possible
16:45 sri originally Mojo::DOM returned arrayrefs
16:46 jberger would overloading `@{}` be useful
16:47 jberger on overloading bool, I still think that `if $col` would be read by most people as "does it contain elements?"
16:47 jberger but I can see your point
16:49 jberger use overload '@{}' => sub { my $self = shift; wantarray ? $self->each : $self->size };
16:50 jberger not a big deal, I was just doing an example on SO and this popped into my head
16:52 jberger hmmm, ok, it seems like using @$col works as expected. Does that come from fallback =>1 ?
16:53 jberger or I guess just that it is a blessed array
16:53 jberger ok
16:53 SmokeMac_ joined #mojo
16:53 sri ye :)
16:55 SmokeMa__ joined #mojo
16:56 * sri tries to stay away from wantarray these days
16:57 jberger one more time on bool: Since objects are necessarily true, I don't think anyone would test the object for that purpose
16:57 jberger I think there is the oportunity to allow testing the collection for truth to be more useful than the analogy to a hashref
16:57 sri i always overload bool together with stringify
16:58 sri for performance
16:58 jberger I get that
16:59 jberger but would anyone ever do `print "true" if bless {}, 'MyClass'`?
17:00 jberger I guess I'm arguing for more magic, and I know thats not in the goals for Mojolicious
17:00 jberger but its not much magic, its useful, and IMO its DWIM
17:00 sri magic for the sake of magic is not cool, but if it adds real value a discussion sure doesn't hurt
17:01 sri so far it sounds rather meh though i'm afraid
17:04 jberger since $dom->find returns an empty collection when nothing is found, it seems that the return (a collection) could bool-ize for truth as "do I contain anything?"
17:05 sri don't think that's even up for discussion, due to backcompat breakage
17:05 sri like i said, Mojo::DOM used to return arrayrefs, and we never deprecated that usage
17:05 batman joined #mojo
17:05 jberger print "Found" if Mojo::DOM->new('')->find('a');
17:06 jberger I'm not really fighting it
17:06 jberger just thinking
17:06 sri keep thinking, i'm going to get beer :)
17:06 jberger haha
17:06 jberger ok
17:07 * jberger hands sri one of mine
17:07 jberger (if only it worked that way, I'd be happy to buy you one if you are ever in Chicago)
17:15 jberger further I understand the deprecation problem, but I would counter with, if no one does `if []` because its always true, then no one probably does `if $col` because of the same reason
17:15 jberger so hopefully its not too break-y
17:15 * jberger needs to move on
17:15 jberger :-)
17:35 Polarn joined #mojo
17:35 sri i would counter with people using it like return $collection->each(sub { $_->side_effects }) if $whatever; to return a true value :)
17:37 sri something i would do to keep code short (with a !!)
17:37 sri but there is also the possibility of performance regressions
17:38 sri $whatever and $collection->...;
17:38 sri you may not care about the return value, but it gets generated and costs
17:39 sri we've been bitten by that pretty bad pre 1.0, doubled overall performance with a few small cleanups
17:40 sri (not saying there's a huge possibility it will matter here, but additional method calls cost)
17:52 sri but yea, those are all pretty minor... same as the pretty minor gain
17:53 * sri is much more interested in a device to dispense beer over the internet
18:06 xaka joined #mojo
18:25 kongelaks joined #mojo
18:50 jberger chicago now has a few bars with beer taps at the tables, I think its basically just an extension of that technology
18:50 jberger :-P
18:50 jberger as always I defer to you on features, it was just a thought floating through my head
18:59 rhaen_fork joined #mojo
18:59 rhaen_fork good evening everyone
19:05 tempire I don't trust you, you're not the real rhaen
19:05 tempire just a fork
19:05 rhaen_fork yeah.
19:06 rhaen_fork I am using the fork one when I am on MacOSX
19:06 rhaen_fork and the rhaen_ithreads when I am on Win32
19:06 rhaen_fork :)
19:06 rhaen_fork omg, I am about to code everything for the LPW2012
19:06 sri so none of you are trustworthy :o
19:06 rhaen_fork talking about multiple deployment environments.
19:07 rhaen_fork I am using Mojolicious as an example and I am deploying everything with puppet
19:07 rhaen_fork holy!
19:07 rhaen_fork The next time in my life when someone asks me what I should pick up for learning
19:07 rhaen_fork I will answer...
19:07 rhaen_fork hm...
19:07 rhaen_fork something different
19:08 sri rhaen_fork: perhaps you'll have some input on the recent hypnotoad deployment discussion then
19:08 rhaen_fork huh, I saw it, however - hm.
19:08 rhaen_fork I'll look into it :) You mean the default conf discussion?
19:08 sri ye
19:08 rhaen_fork oh, I don't care - I automate everything with puppet.
19:09 sri i see mojolicious more as a platform for higher level frameworks in that regard
19:09 sri the problem in question was applications that are basically blackboxes devops folks can't touch
19:09 rhaen_fork let me quick check
19:10 rhaen_fork oh, we have puppet - it's our devops surgery tool.
19:10 sri as in, not even allowed to touch the application config
19:10 rhaen_fork oh. as a devop I know more about the configuration as you do.
19:10 sri or to require a HypnotoadConfig plugin that allows a secondary config file for devops
19:11 sri personally i think the argument is a bit silly, since database config is a devops concern too, and that can't go through a hypnotoad.conf
19:12 rhaen_fork well, if you ask me - all of this is out of scope :)
19:12 rhaen_fork As a devops person I do care about the worker threads - because I know how this app will behave in real production life.
19:13 rhaen_fork I probably like to tweak the log levels, I will look for the log locations - I set the workers.
19:13 rhaen_fork I check the app config - you mentioned the database, I'll probably look for URLs there.
19:13 sri ok, sounds like we agree :)
19:13 rhaen_fork the dev people don't have access to the production environment.
19:14 rhaen_fork It's the job of the application administration engineers
19:14 rhaen_fork They could do a far better job but that's out of the scope of this IRC channel :)
19:15 rhaen_fork I am working on a puppet module for deploying Mojo apps and I will show it on LPW2012
19:16 rhaen_fork therefore the developers can make suggestions, they can see the production settings and probably can change it (inside the git repo) and puppet will care for the deployment and the hypnotoad restarts.
19:17 rhaen_fork I see devops more in the terms of toolchain builders. They do care about deployment and about production robust environments - so, yep - I will look everywhere in your application :)
19:27 mire joined #mojo
19:40 mattastrophe joined #mojo
19:49 rhaen_fork joined #mojo
19:50 bobkare rhaen_fork: does that puppet module include anything at all to help generate configs, or is it all left to the user to try and get quoting right through both puppet and mojos perl format?
19:51 rhaen_fork bobkare: oh, no - I don't care about configs that much.
19:51 rhaen_fork It's more a demonstration how you can deploy your mojo apps to multiple servers
19:52 rhaen_fork puppet is a great tool for configuration management. The modules have a clear interface, that's all.
19:52 rhaen_fork It's up to you how to actually configure your application.
19:52 rhaen_fork oh, and there is no trial and error.
19:53 rhaen_fork bobkare: Are you used to puppet?
19:53 bobkare so basically "configuration is left as an exercise to the reader"
19:53 bobkare yes
19:53 rhaen_fork no, it's a define
19:54 rhaen_fork so, you'll have something like: class {'mojoapp':
19:54 rhaen_fork app name => 'hello_world',
19:54 rhaen_fork }
19:54 rhaen_fork inside your node definition.
19:54 rhaen_fork that's all.
19:54 bobkare have a module that imho works really great, except it doesn't work with newer mojo versions
19:55 rhaen_fork the module will care that mojo is installed. The hypo toad is running as a service
19:55 rhaen_fork a user mojo and a group mojo is created.
19:56 rhaen_fork If you change something in the app, puppet will redeploy the stuff and restart the hypnotoad.
19:56 bobkare then when I have 5 different apps on the same server and want to make sure they stay on separate ports and export a resource that makes the load balancer pick them up, all that stuff needs to be handled outside your module
19:56 sri bobkare: i've thought about the problem a bit more too and imo generic config files are impossible, devops will always have to configure stiff that's unreachable for hypnotoad
19:57 sri there will alaways be something app specific to configure
19:57 rhaen_fork bobkare: It is a simple example - not a full blown toolchain.
19:58 rhaen_fork however, every app has it's own service start script which will be generated by a template
19:58 rhaen_fork so there shouldn't be a problem in running multiple apps on one server
19:58 bobkare rhaen_fork: Yeah, I understand that. It's just that I'm not making an example but something that needs to actually work and not be too horrible to work with
19:59 rhaen_fork bobkare, specifying just a simple app name isn't too horrible :)
19:59 bobkare rhaen_fork: separate run scripts doesn't help with hypnotoad, the _only_ way to configure the port is through whatever config plugin the app has loaded
20:00 sri bobkare: only having to configure the port for a real app is unrealistic
20:01 sri database is a devops concern as well
20:01 bobkare I have a bunch of apps that only talk to other webservices that are just resolved by DNS
20:02 rhaen_fork hm, I can specify the config file on the command line for hypnotoad.
20:02 sri that's a very limited scenario
20:04 bobkare rhaen_fork: a separate hypnotoad config file? Then you're on the same old version as me
20:04 rhaen_fork I am just looking what's interesting in the configation file: accepts, clients, group, listen, lock file, etc.
20:05 sri rhaen_fork: hypnotoad has no config file
20:05 rhaen_fork ah, yes. Right, sorry - messed up a bit here.
20:05 rhaen_fork I was talking about the app conf here.
20:06 rhaen_fork Did I miss something here?
20:06 sri nope
20:06 rhaen_fork I still can have the hypo toad setting in the app.conf file, right?
20:06 sri you do
20:06 rhaen_fork k
20:07 sri bobkare was talking about the old way, when hypnotoad had its own hypnotoad.conf, separate from app.conf
20:07 rhaen_fork In my opinion that's not a job for puppet - that's an application setting and I don't want to mess with the system there.
20:08 rhaen_fork yep, all my old configs were using the --config switch
20:08 rhaen_fork probably there is sane way to do everything in puppet, but I doubt that.
20:08 bobkare rhaen_fork: then how do you get config parameters from puppet into the config file?
20:09 rhaen_fork I don't get them from puppet inside the config (for now) - I am using a file resource to copy it and notify the service on changes.
20:09 rhaen_fork Please keep in mind - that talk is about managing deployments and dependencies - not having a full blown mojo module for puppet.
20:10 rhaen_fork but that might be a nice project :)
20:10 rhaen_fork I'll ship the code on github when it's working the way I'd like to show.
20:10 rhaen_fork Probably this will be a good starting point.
20:10 rhaen_fork oh, here is another thing which makes it easy for me :)
20:11 bobkare it's impossible to do for the general case since there are multiple config plugins for mojo with separate formats
20:11 rhaen_fork I am only allowed to have one application per server. :)
20:11 sri mojolicious would basically have to ship with its own model layer and provide a generic config file for general purpose deployment recipes
20:11 rhaen_fork bobkare: oh, why - just use puppet templates and fill everything inside the defines as parameters.
20:11 rhaen_fork bobkare: you can even use hiera for the auto injection of values there.
20:11 perlite joined #mojo
20:13 bobkare rhaen_fork: that would have to assume a certain config plugin was used and not configured in any special way
20:14 sri bobkare wants to write something once and have it work with every mojolicious app, that's simply impossible
20:14 bobkare sri: a 95% solution would be to have the default examples and stuff use one of the config plugins
20:15 bobkare or somehow default to one of the config plugins
20:16 rhaen_fork hm, let me think of it. I still don't get the point.
20:16 sri even then there won't be a standard for database option naming
20:16 sri but i agree, it sure would make it easier
20:16 rhaen_fork ah.
20:17 bobkare sri: that doesn't matter, because it would be configureable. In puppet I could do mojo::app {'foo': config => {db => 'whatnot', hypnotoad => {listen => '...'}}}
20:17 sri unrealistic at least for lite apps though
20:18 sri apps die if no config file exists
20:18 bobkare unless you add default => {}
20:19 sri if the config plugin was loaded by default you wouldn't have that choice
20:20 rhaen_fork hm, why not using a template to write the config file?
20:21 sri i see lots and lots of backwards compatibility issues
20:21 sri but am open for well researched proposals
20:21 bobkare could it be loaded with default => {} by default and if you want the current behaviour of die if no config file then you load it manually?
20:22 rhaen_fork sri: hm, I don't see that it is needed now.
20:23 bobkare rhaen_fork: you mean per-app? that means the puppet module for every app needs code to properly quote things for whatever config file format the app wants
20:24 rhaen_fork oh, probably the module only copies the config file from the files section to the server and notifies the service if needed.
20:24 rhaen_fork So you still have a plain text file for the configuration - no magic in creating it.
20:25 bobkare That simply doesn't solve my problem since different deployments need different configs
20:25 rhaen_fork hm, why can't you have multiple files that way?
20:26 sri bobkare: i've just added "$self->plugin(Config => {default => {}});" to Mojolicious.pm for fun, and multiple tests break
20:26 sri so it's not an option before 4.0
20:26 rhaen_fork class mojo::config ($appname) { file {"/etc/hypnotoad/$appname.conf: source => "/files/$appname",} }
20:27 rhaen_fork make it a define if you need it multiple times
20:28 rhaen_fork so you have a directory (in this case /files) with all your conf files in it.
20:29 rhaen_fork probably some more code is needed to show what i mean.
20:29 rhaen_fork I will try to push everything to github by Wednesday - maybe things will get easier to explain
20:29 rhaen_fork I fully understand your concerns, tho.
20:30 bobkare I don't want to maintain lots of different complete config files for every combination of server and instance
20:30 rhaen_fork ah, that's understandable.
20:31 rhaen_fork isn't it possible to have smaller boxes?
20:31 rhaen_fork sounds like a super server with millions of jobs on
20:31 bobkare and then manually make sure that matches the parts of my puppet manifest where things like the port number is used to export a resource to put it into the load balancer
20:31 rhaen_fork *ouch* - ok.
20:32 rhaen_fork that was one of the design decisions in my company.
20:32 rhaen_fork no exported resources at any cost.
20:32 rem_lex|pivo joined #mojo
20:32 bobkare 5-20 apps is slightly less than a million, and there is some overhead in both maintenance and resources per server
20:33 rhaen_fork ok, as I said - due to compliance reasons I am only allowed to have one app per server
20:33 bobkare we have a few apps that we need to push to several servers, and also a lot of small apps that really don't need a whole server
20:33 lukep joined #mojo
20:34 bobkare with the number of small apps we throw together for small things it wouldn't be hard to convince management it was costing too much if we had a policy like that
20:34 rhaen_fork k. Yep, so you probably need to think of a solution then.
20:34 rhaen_fork But then I would set some standards and enforce them internally.
20:36 bobkare yeah, saying all internal apps need to load the same config plugin is fine. only works for internally developed apps though.
20:36 rhaen_fork yepp.
20:36 * rhaen_fork hugs bobkare.
20:36 rhaen_fork Welcome to my job!
20:37 rhaen_fork yep - that's a problem. And it's a tough problem.
20:37 rhaen_fork but (don't meant to be offensive) - this is not a framework problem, it's a problem in terms of coding guidelines everyone has to follow.
20:38 rhaen_fork I solved this problem by having certain conventions, otherwise I refuse to put the code in production. :)
20:38 bobkare imho that's at least partly a framework problem
20:38 rhaen_fork but this maybe a lot easier.
20:38 sri or you build a higher level framework on top of mojolicious that has *a lot* more conventions
20:38 rhaen_fork sri: na, don't think so. You need a sheet of paper :)
20:39 sri bobkare: mojolicious is not high level enough
20:39 bobkare it would help enormously if mojo at least had a convention for how config and setting log level should be done
20:39 rhaen_fork value people and processes more than tools :) - Agile manifesto :)
20:40 sri that's just not gonna happen, you will have to make your own conventions
20:40 Adura Yes, configuration over convention!
20:41 * rhaen_fork sneaks out of the minefield.
20:41 bobkare so basically mojo is then limited to being only A) meta-framework or B) for in-house apps
20:41 sri just like sinatra and node.js don't have conventions for that
20:41 sri mojolicious is not rails or django
20:42 rhaen_fork guys I am in a little hurry - but, that's what I like about mojo and it's lightweightness.
20:42 bobkare I haven't used sinatra or node so I don't know how they are from a sysadmin perspective
20:42 rhaen_fork bobkare: they are a horror!
20:42 bobkare can't say I'm surprised
20:43 rhaen_fork bobkare: they are pure dev stuff. Never meant to run on production servers.
20:43 rhaen_fork Don't quote me on that :)
20:43 sri rhaen_fork: don't tell that heroku
20:43 rhaen_fork sri: I won't :)
20:43 sri heroku folks made sinatra to test their stack afair
20:43 rhaen_fork sri: it's running incredibly well there.
20:43 rhaen_fork Same with cloud9.
20:43 rhaen_fork brrr.
20:44 rhaen_fork but it seem to work for them. Probably after spending a lot of time in the infrastructure.
20:44 rhaen_fork anyways - I need to go to bed, cya tomorrow
20:45 * rhaen_fork waves.
20:45 bobkare see ya
20:46 bobkare sri: the fact that you can make an infrastructure for something doesn't mean it isn't horrible for normal sysadmins
20:47 bobkare but I should make myself an evening meal. bbl.
21:25 Kulag joined #mojo
21:26 coff_ joined #mojo
21:26 coff_ left #mojo
21:27 coff joined #mojo
21:34 Kulag joined #mojo
21:50 Kulag joined #mojo
21:59 Drossel joined #mojo
22:12 foristh joined #mojo
22:20 dabudabu joined #mojo
22:24 ObseLeTe joined #mojo
22:44 Kulag joined #mojo
22:54 jzawodn joined #mojo
22:59 jayallen joined #mojo
22:59 coff left #mojo
23:00 jayallen joined #mojo
23:05 jayallen joined #mojo
23:07 Averna joined #mojo
23:09 jayallen joined #mojo
23:10 jayallen joined #mojo
23:37 SmokeMachine_ joined #mojo

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