Camelia, the Perl 6 bug

IRC log for #mojo, 2012-11-06

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

All times shown according to UTC.

Time Nick Message
00:49 sri coff, bobkare: i think the hypnotoad config design is final
00:50 sri and i don't see a reason why you can't have a separate plugin for loading a hypnotoad specific config file and merge it into the global config
00:50 sri plugin 'HypnotoadConfig';
00:50 sri $app->config->{hypnotoad} = {...};
01:18 Mike-PerlRecruiter_ joined #mojo
01:21 dvinciguerra joined #mojo
01:23 laouji joined #mojo
01:42 Kulag joined #mojo
02:17 thaljef joined #mojo
02:47 ispy_ joined #mojo
03:25 good_news_everyone joined #mojo
03:25 good_news_everyone [mojo] kraih created gzip (+1 new commit): http://git.io/aomBZQ
03:25 good_news_everyone mojo/gzip 38e0679 Sebastian Riedel: added gzip support to Mojo::UserAgent
03:25 good_news_everyone left #mojo
03:26 sri garu: you reminded me of some unfinished work on compression i never committed
03:27 sri it's a branch now, perhaps someone would like to clean it up
03:27 sri while compress sucks to implement, uncompress is rather simple
03:28 sri aside from the usual security risks i don't think there is much that could go wrong
03:29 sri for it to go into master the tests would need to be better (chunked and buffer limit tests) and security risks would have to be researched
03:29 * sri pokes tempire, marcus and crab too
03:32 good_news_everyone joined #mojo
03:32 good_news_everyone [mojo] kraih pushed 1 new commit to gzip: http://git.io/oUjclQ
03:32 good_news_everyone mojo/gzip ca78ec2 Sebastian Riedel: fixed comment
03:32 good_news_everyone left #mojo
03:33 sri garu: pluggable filters were something i considered a long time ago, but i'm not sure it could really work
03:38 garu sri: IO::Compress is core since 5.9, so it compression could even be bundled into the main dist :)
03:38 garu s/it//
03:38 sri garu: indeed
03:38 garu though I rather it was pluggable
03:39 garu sri: I'm sorry, I don't know enough of the http spec to figure whether pluggable messages make sense
03:39 sri make a pretty api then ;)
03:39 garu I can try :)
03:39 sri yea, when i started the first built in filter was chunked encoding...
03:40 noganex_ joined #mojo
03:40 sri when i learned more about http i realized how stupid that was
03:40 sri and pretty much gave up then
03:40 sri pluggable filters have to watch out for so much, everything can cause security problems
03:41 sri remember, Mojo::Content is for both, server and client
03:43 garu right
03:44 garu I'm looking at gisle's HTTP::Message, it seems pretty straightforward
03:44 sri well, it can block :)
03:44 garu heh, indeed
03:44 sri my worry is stream buffers and memory exhaustion attacks
03:46 sri the current code would theoretically support a chunked gzip compressed multipart file upload :)
03:46 garu I'll have those in mind, maybe even write the attack itself before commiting the code
03:46 sri which is then streamed into a file automatically
03:47 sri garu: what other filters are there anyway besides gzip?
03:48 sri more than one good use case is a prereq for a new api layer imo
03:49 garu x-gzip, bzip2, deflate, compress, base64, quoted-printable
03:49 sri are any of those actually used?
03:49 sri qp and base64 seem silly
03:50 garu I think deflate is the evolution of x-gzip
03:50 garu or maybe that's just how apache labelled their mod_* thingies and I just got them wrong
03:50 sri pretty sure deflate is a poor version of gzip
03:50 garu heh, here's a funny piece of code from HTTP::Message
03:51 garu elsif ($ce eq "compress" || $ce eq "x-compress") {  die "Can't uncompress content"; }
03:51 sri compress is discouraged by the rfc anyway
03:52 sri right, gzip is deflate with a header and footer
03:53 sri gzip is more portable afair
03:53 sri due to meta data
03:54 sri bzip2 is not really deployed i believe
03:54 sri so we are back to only gzip :)
03:54 garu it's trivial to implement, though
03:54 garu are we able to check?
03:54 garu I mean
03:55 sri check what?
03:55 garu are there global statistics on content-encoding accepted by online servers?
03:55 garu I know gzip is the wildly used one, or at least it seems that way
03:56 garu but I wouldn't dismiss bzip and others that easily, specially since they seem so trivial to implement
03:56 sri i think gzip is the only widely used one
03:56 sri well, it's not like adding gzip only for now would prevent a pluggable api in the future ;)
03:57 garu absolutely :)
03:57 garu can even be seen as a starting point!
03:57 garu "if you are interested in adding others, this is how you should do it"
03:57 sri i'm not even convinced we should add gzip yet though ;p
03:57 garu dammit
03:57 garu :P
03:58 sri security research and tests need to be done
03:58 garu fair enough
03:59 sri i tend towards a +1 vote once that is done though
04:00 garu cool
04:00 garu I'll see if I can come up with some security research regarding content-encoding, specifically gzip
04:01 sri \o/
04:01 sri tests are not such a big deal, it's just security i'm worried about really
04:02 sri portability of the tests would also be interesting
04:02 * sri has no clue how good gzip works on windows perl
04:06 aptituz joined #mojo
04:06 sri aaaaaaaaaaaah
04:06 sri http://www.vervestudios.co/proj​ects/compression-tests/results
04:06 sri stats!
04:06 * sri pokes garu
04:06 garu oO
04:10 garu sri: so, everybody loves gzip, not everybody loves deflate
04:11 garu ok, I've dug a bit into cpantesters
04:11 sri and deflate has compatibility problems
04:11 garu the uncrompression bit from HTTP::Message is simply IO::Uncompress::Gunzip::gunzip($content_ref, \$output, Transparent => 0)
04:11 garu and IO::Uncompress::Gunzip seem to pass win32 fine
04:12 garu by win32 I mean activeperl/strawberry, though it also passed within cygwin
04:12 * sri assumes IO::Uncompress::Gunzip passing means Compress::Raw::Zlib passes too
04:15 garu yup => http://matrix.cpantesters.org/​?dist=Compress-Raw-Zlib-2.056
04:25 xaka joined #mojo
04:26 sri i'm interested in if it's possible to make Compress::Raw::Zlib buffer grow indefinitely
04:26 sri *+the
04:28 sri maybe with a special gzip header
04:28 sri or by feeding it garbage
04:31 garu right
04:31 garu I'll look into it
04:31 garu I know there have been zlib exploits, but I don't think they're web based
04:33 garu sri: you mean something like that, right? => http://cve.mitre.org/cgi-bin/c​vename.cgi?name=CVE-2010-2328
04:33 garu (only more generic)
04:34 good_news_everyone joined #mojo
04:34 good_news_everyone [mojo] kraih pushed 2 new commits to gzip: http://git.io/AzlYMg
04:34 good_news_everyone mojo/gzip 1cc78c4 Sebastian Riedel: added buffer limit test for gzip compression
04:34 good_news_everyone mojo/gzip 6072f3a Sebastian Riedel: better buffer limit test
04:34 good_news_everyone left #mojo
04:35 sri feeding it garbage looks ok so far :)
04:35 garu \o/
04:36 garu I guess gzip is every now and again target to code exploits like http://cve.mitre.org/cgi-bin/c​vename.cgi?name=CVE-2006-4338
04:36 sri :/
04:37 garu but they always patch their stuff
04:37 garu it's a cat-mouse chase, like all other libs
04:38 sri then again, https traffic is often compressed too
04:38 sri or used to be before the ssl+gzip attack
04:39 sri (which is not gzips fault)
04:41 garu servers and browsers usually prefer gzip, if it's implemented on both ends
05:06 Foxcool joined #mojo
05:19 laouji joined #mojo
05:20 good_news_everyone joined #mojo
05:20 good_news_everyone [mojo] kraih pushed 1 new commit to gzip: http://git.io/9oOQSw
05:20 good_news_everyone mojo/gzip 1e977dd Sebastian Riedel: fixed gzip compression to work with chunked content
05:20 good_news_everyone left #mojo
05:20 sri garu: ok, test coverage should be fine now :)
05:21 garu sri++
05:31 gryphon joined #mojo
05:36 good_news_everyone joined #mojo
05:36 good_news_everyone [mojo] kraih pushed 1 new commit to gzip: http://git.io/cWGfHA
05:37 good_news_everyone mojo/gzip 47773e3 Sebastian Riedel: a few more gzip compression tests
05:37 good_news_everyone left #mojo
05:41 sri hmm, google.com does not gzip html
05:41 sri amazon.com does
05:42 xaka how come? content-encoding:gzip - google.com
05:43 sri maybe a geo dependent thing
05:45 sri ok, the branch needs reviewers https://github.com/kraih/mojo/commits/gzip
05:47 sri ooooh
05:47 * sri discovered a neat github feature
05:47 sri https://github.com/kraih/m​ojo/compare/master...gzip
05:56 xaka sri: why did you choose Compress::Raw::Zlib over IO::Uncompress::Gunzip? the last one is modern, can work as normal file handle and has easier api (imho)
05:56 sri xaka: how would that work?
05:58 xaka what do you mean? (i know i know, question for question)
05:59 sri we don't use a file handle and don't have the whole content
06:03 xaka ah that. it works in either way - with file handles, scalars or arrays, but the point is that it has more usual api, like you read from file handle. i just done like bits, statuses and inflate method from Compress::Raw::Zlib, looks ugly :)
06:03 xaka *don't
06:03 sri umm
06:03 sri you're welcome to make it more pretty
06:03 sri but i'm pretty sure your option is more ugly
06:04 xaka the code itself looks great, as always ;) i just against some packages, hehe
06:24 Adura I use the gzip module where you can set compression to 1.
06:25 Adura Ah, but that's a client... never mind.
06:47 good_news_everyone joined #mojo
06:47 good_news_everyone [mojo] kraih pushed 1 new commit to gzip: http://git.io/TizLMQ
06:47 good_news_everyone mojo/gzip 2cbbf8f Sebastian Riedel: more tests for buffer limit
06:47 good_news_everyone left #mojo
06:48 * sri is waiting for votes
06:49 ruz joined #mojo
06:58 spleenjack joined #mojo
07:01 dpetrov_ joined #mojo
07:10 Vandal joined #mojo
07:12 coff joined #mojo
07:16 ovnimancer joined #mojo
07:18 bobkare sri: Would that plugin idea work without ops patching every app we want to deploy?
07:21 dpetrov_ joined #mojo
07:28 batman left #mojo
07:32 bobkare I have this quite nice puppet module that means installing and configuring an instance of a new application looks like this: mojolicious::app {'appname': svnurl => 'http://...', port => 3210, config => '{"foo":"bar"}', nagios_check_path => '/some/where', }. How can I make something like this work with newer mojo versions?
07:34 michaelfung joined #mojo
07:39 batman joined #mojo
07:39 sri bobkare: if you have no control whatsoever about the application code you're screwed
07:39 batman marcus: let me know when you have looked at the feature branch for mojo-redis...
07:40 sri pretty sure i actually brought up your argument back then when we merged the config files
07:40 bobkare sri: Uh, so writing mojo applications for general distribution and then deploying with hypnotoad isn't supported?
07:41 batman zpmorgan: would like to get your input as well: https://github.com/marcusramberg/mojo-redis/co​mmit/2557afd2cad15c8a5a216d750f5b1f6b67ee19e1
07:41 sri bobkare: depends how you define it
07:42 sri but i guess not
07:42 sri the whole idea is silly when you think about it
07:43 sri applications usually require more configuration than a port to listen on
07:43 sri like the address of a database server, passwords, a shared secret
07:43 zpmorgan batman, i almost completely approve
07:43 sri a single unified application configuration just makes more sense
07:43 batman zpmorgan: give me more! :)
07:44 bobkare but that's application config. a webserver is imho a separate component
07:44 zpmorgan it might be a challenge to port subscriptions to/from other redis libraries
07:44 zpmorgan so maybe an alternative subscribe method would be more appropriate?
07:45 sri bobkare: disagree about that
07:45 batman zpmorgan: do i really need to care about other redis libraries?
07:45 zpmorgan maybe not.
07:46 batman zpmorgan: i will onlye care if it makes the wheel rounder
07:46 zpmorgan okay; it would be inconsistent with every other redis command.
07:46 bobkare sri: It really sucks if what I have to do with the puppet module is rip the whole config out into a big ugly string and stuff it in the manifest file. With all the levels of quoting that will be _really_ ugly. Or I have to add small silly templates for every different app I want to deploy
07:46 sri i see hypnotoad as an application server, that's part of the application
07:47 zpmorgan dunno whether that's a problem that needs solving thouhg
07:47 batman zpmorgan: you're not doing a killing argument here :/
07:47 zpmorgan i'm trying
07:47 batman zpmorgan: but i share your concern
07:47 batman zpmorgan: yeah! i like it :)
07:47 bobkare So creating general deployment methods/helpers aren't supported?
07:47 batman thanks
07:48 sri bobkare: your use case is not common, i don't think you should expect it to be simple and pretty
07:48 mire joined #mojo
07:48 sri it is supported through extra plugins the application has to load
07:49 * bobkare prefers to leave application code alone when he has his ops hat on
07:49 sri not even cloud hosting providers have that kind of expectations
07:49 batman zpmorgan: so i'm thinking if we should keep the subscribe() as a "normal" method, then it should overtake the _connection, and not allow you to run any other methods on the object afterwards
07:49 sri look at heroku
07:49 batman ...instead of like now: it's adding a connection to the same object
07:49 sri they give you a few env vars, and you do with it whatever you like
07:49 batman zpmorgan: but i like how you're getting a new object with new events
07:49 coff sri: would be very nice if we had a HYPNOTOAD_CONFIG
07:50 sri coff: please elaborate
07:50 coff sri: that would make things comfortable for all parties involved methinks
07:50 zpmorgan batman, i was thinking that if subscribing created a new connection, that new $redis would only be present in the subscribe callback.
07:50 bobkare How does the deploy mojo stuff to heroku stuff work? Require you to add application code to read $PORT or whatever their env var is called?
07:50 batman zpmorgan: that's difficult when you want to avoid memory leaks
07:50 coff sri: if I in ENV could set a HYPNOTOAD_CONFIG pointing to a file containing the hypnotoad specific config then app and ops could be nicely separated
07:50 zpmorgan ah
07:51 batman not impossible though
07:51 batman but i do like $sub->on(message => sub { .... });
07:51 sri bobkare: simple shell script with something like "./myapp daemon --listen http://*:$PORT" or so
07:51 bobkare ok, so it just doesn't use hypnotoad at all
07:51 * zpmorgan beers batman in the future.
07:52 sri bobkare: but it could
07:53 sri app->config(hypnotoad => {listen => ["http://*:$PORT"]})
07:53 sri point is, the developer makes the choice
07:53 sri the hoster just provides a few guidelines
07:53 Gedge joined #mojo
07:53 sri while you want total control
07:53 batman zpmorgan: "beers" ? doesn't sound like you disagree that much after all..?
07:53 batman :)
07:54 coff sri: Here we differ in opinion. We believe that ops should govern ops. Devs should have app responsibility.
07:54 bobkare my point is the developer doesn't know and doesn't care, I'm the ops guy that need to take random stuff from dev and make it actually work on servers
07:54 zpmorgan batman, it still breaks my code ;)
07:54 batman zpmorgan: _that_ is true. that's why it's not on cpan anymore
07:54 sri coff: then establish a rule that all apps need to load the HypnotoadConfig plugin or they won't work
07:55 batman zpmorgan: but does your code use the $redis object for both get() (and friends) and subscribe() ?
07:55 batman s/anymore/yet/
07:55 zpmorgan it uses different connections
07:55 sri it's not like what you want is impossible, you want it built in because your developers don't listen to you
07:55 zpmorgan different $redises
07:56 batman so you do $sub = Mojo::Redis->new->subscribe(...) and $redis = Mojo::Redis->new->get(...) ?
07:56 zpmorgan yeah, i have a singleton model with a pub_redis, a getset_redis, a block_redis, and a method to generate new sub_redises
07:57 bobkare sri: So deploying mojo apps from outside my own organization isn't supported?
07:57 zpmorgan i'm sure all that wasn't necessary though
07:57 zpmorgan the block_redis uses its own ioloop
07:57 bobkare sri: Why would $random_cpan_app_author want to add my special deployment config plugin?
07:57 sri bobkare: not the exact way you want it
07:58 batman zpmorgan: no, but it makes it more compatible. i can make some changes to my commit... don't hold your breath though
07:58 sri bobkare: they wouldn't! they would just read an application config file
07:58 sri *you* provide the config file
07:59 bobkare Right, and generalizing the general parts of that config isn't supported
08:01 yakudza joined #mojo
08:02 sri bobkare: well, maybe bring it up on the mailing list and see if there's a wider interest, so far i'm not convinced
08:02 coff sri: sorry, but not true. _sometimes_ I write the application config. Most times it comes from someone else (since app-config is in their domain). I need to make sure that one some node (I seldom know which, since that is determined depending on server health, traffic etc at the time) there will start serving the app.
08:02 sri or lobby the other core developers, marcus, tempire and crab
08:02 coff sri: so I am the one making sure the hypnotoad config is in place
08:03 bobkare Hm, how is the command module lookup? Could I write a command plugin that sets up these typical deployment options and fires hypnotoad?
08:03 coff sri: I dread a situation in which I would need to parse the configfile from them, inject my own and rewrite
08:04 coff bobkare: or we could just write our own preforking server.
08:04 coff bobkare: sorry, fork and patch hypnotoad ;)
08:04 sri i will always vote against adding another config file because it would suck to explain in the documentation, so you have to get other votes
08:04 coff sri: Ok.
08:05 bobkare sri: What about adding command-line arguments to hypnotoad?
08:05 sri bobkare: once you look into the code you'll see why that's a very bad idea :)
08:06 sri zero downtime restart is very very complicated
08:06 coff sri: Although "You can put hypnotoad config in config->{hypnotoad}, or set env-var HYPNOTOAD_CONFIG to point to a file in which hypnotoad can find it's config" does not seem terribly complicated?
08:06 bobkare OK. Hm, but looking at the documentation on commands in the cookbook that route seems like it should be possible
08:07 sri coff: my problem is multiple features doing the same and having to explain it in documentation
08:07 sri it feels like patchwork
08:09 sri btw. i'm pretty sure MOJO_LISTEN actually works with hypnotoad
08:09 coff bobkare: Your idea of hooking into a command module seems doable. That means we could get logging working.
08:10 coff sri: I check MOJO_LISTEN out with hypnotoad and let you know if it doesn't work.
08:10 bobkare sri: I'm very sure it doesn't. Daemon.pm has a default that includes $ENV{MOJO_LISTEN}, hypnotoad overrides that with :8080
08:10 coff bobkare: oh. right. *reading code*
08:11 sri ok
08:11 sri you're of course welcome to fork hypnotoad
08:12 sri making a fork popular is a sure way to sell your feature :)
08:12 bobkare sri: Do you see any obstacles with the command approach? Have ./myapp my_hypnotoad_deploy initialize the app, set up the config and start hypnotoad?
08:12 coff sri: hehe, true enough but I'd rather avoid forking things. I believe forking weakens the projects overall, and I do not want that with mojo as I really do like it. :)
08:13 sri bobkare: it will surely break zero downtime restarts, but if you don't care about that...
08:13 bobkare sri: Oh, that depends on launching through the wrapper?
08:13 sri coff: heh, disagree strongly about that, forks for experimeting with new features are a very good thing imo
08:15 sri bobkare: it does
08:15 sri zero downtime restarts put very very strong contraints on hypnotoad
08:15 sri *+s
08:16 sri it's based on fork/exec with inherited %ENV, file descriptors and lock files
08:16 sri just like nginx does it
08:16 coff sri: Would running hypnotoad with all the same parameters for every restart (eg. after new code has been pushed out) enable zero-downtime restarts?
08:17 coff sri: I never (_ever_) manually restart a hypnotoad instance :)
08:19 bobkare hm, so from what I see it's basically $ENV{HYPNOTOAD_EXE} ||= $0; exec($ENV{HYPNOTOAD_EXE}), would it be possible to set that env var to the path to the app plus an argument to launch my special command?
08:20 bobkare zero-downtime restart is really awesome, so I'd love to keep it working. But I don't want to maintain a copy of hypnotoad
08:20 dod joined #mojo
08:30 fhelmber_ joined #mojo
08:35 sri and back on topic! i'm still looking for opinions on https://github.com/kraih/m​ojo/compare/master...gzip
08:43 marcus sri: gzip looks great. +1 from me.
08:45 mire joined #mojo
09:03 pau4o joined #mojo
09:04 pau4o left #mojo
09:09 sri that's +2 already \o/
09:11 sri oh, looks like the bot doesn't announce a normal merge :/
09:11 dod joined #mojo
09:17 cosmincx joined #mojo
09:17 sri hmmmm
09:18 sri i did not think that through
09:18 sri https://github.com/kraih/m​ojo/compare/master...gzip # that link is now borked :S
09:24 cosmincx joined #mojo
09:26 bobkare sri: my command idea seems to work, all that was needed for zero downtime restart was $ENV{HYPNOTOAD_EXE} = "$0 my_command_name"
09:27 arthas joined #mojo
09:30 batman marcus and zpmorgan: https://github.com/marcusramberg/mojo-redis/co​mmit/4a503d4a1136e2d283b517ad21978843448289db
09:30 batman i actually think that commit makes sense :)
09:31 batman also: i think pubsub is server wide and not pr. database. <--- any input on that?
09:38 Adura joined #mojo
09:38 marcus batman: I think it makes sense and I think you are right.
09:38 marcus all praise the batman
09:39 cstamas sri: as per janus instructions (it seems he is offline) I made a new pastebin http://pastebin.com/LQC1UWdC
09:39 cstamas thx
09:39 zpmorgan I agree with marcus
09:40 tholen joined #mojo
09:43 batman marcus: ship it! :)
09:44 Britzel_ joined #mojo
09:45 batman marcus: i can try to put it on cpan as well... what do you think?
09:46 batman i really like the MOJO_REDIS_DEBUG=1 feature :)
09:46 batman zpmorgan: are you still online?
09:46 zpmorgan yep
09:46 batman have you looked at the commit?
09:47 zpmorgan yep, I haven't studied it
09:47 marcus batman: go for it.
09:47 zpmorgan is it a new $redis that's given in the subscribe callback?
09:47 ObseLeTe joined #mojo
09:48 crab gzip what?
09:48 batman zpmorgan: no. it's the same $redis object
09:49 zpmorgan batman, okay, just wondering
09:49 batman zpmorgan: i think it's consistent with https://metacpan.org/module/Re​dis#Publish-Subscribe-commands
09:49 crab ah, gzip support in the useragent. good idea.
09:50 batman zpmorgan: if you want to get a new $redis object, you need to do just $sub = $redis->subscribe('foo')->on(data => sub { ... });
09:50 zpmorgan oh, nice!
09:50 batman :)
09:53 batman marcus: what will the version be? 1.0 ?
09:53 zpmorgan do you think that anyone will use sub->new(...)->connect instead of $redis->subscribe?
09:53 batman zpmorgan: no idea. but it's possible.
09:53 zpmorgan okay
09:54 batman marcus: or 0.99
09:54 batman zpmorgan: don't really care, hehe
09:54 zpmorgan :)
09:54 judofyr joined #mojo
09:54 batman zpmorgan: i think it will do $sub = Mojo::Redis->new(...)->subscribe('foo'); instead, but it's optional
09:56 ladnaV joined #mojo
10:00 Vandal joined #mojo
10:04 sri cstamas: still not a clue i'm afraid, perhaps a broken Test::Harness or so
10:04 batman marcus: it's almost on cpan...
10:05 batman https://github.com/marcusra​mberg/mojo-redis/tree/0.99
10:06 batman marcus: README.pod is outdated :(
10:06 batman not sure how you did that
10:06 batman s/did/made/
10:10 cstamas sri: it can be that, yeah
10:16 ladnaV joined #mojo
10:16 michaelfung joined #mojo
10:20 Vandal joined #mojo
10:31 Adurah joined #mojo
10:34 batman marcus: it's alive: https://metacpan.org/release/Mojo-Redis
10:35 batman the pod is a bit messed up though :(
10:37 sr joined #mojo
10:42 judofyr so, what's new and fresh in Mojolicious?
10:42 * judofyr hasn't been in here for a while
10:43 judofyr batman: I hope you didn't write that pod yourself…
10:43 judofyr (I'm thinking about the REDIS METHODS section)
10:47 sri APPLE... Y U NO SHIP MY MACBOOK
10:47 judofyr oh
10:47 judofyr :(
10:48 batman judofyr: fixing it now. care to review it?
10:48 judofyr batman: sure
10:49 batman https://github.com/marcusramberg/mojo-redis
10:49 batman https://github.com/marcusramberg/mojo-redis/co​mmit/1ceb6aff27e7b6647b57a1a4f6adc633071c660d
10:50 batman i like the websocket example :)
10:50 Averna joined #mojo
10:51 batman need to make a new release if you approve the changes...
10:52 judofyr four-space indentation? :P
10:52 batman haha. ok, will fix that :D
10:53 judofyr batman: it's not clear if this is blocking or not: $redis->set(key => 'value');
10:53 judofyr especially when you have a ->get right under
10:53 batman i will add that to the description + comment to the example
10:54 judofyr but yeah, seems fine
10:55 batman thanks
10:55 sri pubsub example for websockets should be quite useful
10:55 sri for all those questions on the mailing list :)
10:56 batman sri: ok. will add "pub" to the example as well
10:56 marcus pub++
10:57 marcus I've been thinking about what kind of abstraction would make sense on top of redis.
10:57 marcus been considering something like reverse routes for defining redis key structures
10:57 * sri wonders if $ua->compression(0) and MOJO_COMPRESSION=0 should exist
10:58 judofyr marcus: hm. reverse routes?
10:58 sri (which would disable Accept-Encoding: gzip)
10:58 marcus judofyr: well, named key patterns.
11:00 marcus like $redis->get('connections',id=>$id, sub { … } ); after defining connections as /client/connection/:id
11:00 marcus or something like that.
11:00 judofyr ah
11:00 judofyr right
11:00 marcus just to structure the redis keys a bit more than just ad-hoc using them.
11:01 judofyr yeah
11:02 spleenjack1 joined #mojo
11:03 jmaister ever, all F1 cars weigh significantly less than this (some as little as 440 kg
11:03 jmaister ops
11:03 batman so i just added pub to the sub ws example. care to review?
11:03 sri thank you for subscribing to racecar facts!
11:03 batman https://github.com/marcusr​amberg/mojo-redis#SYNOPSIS
11:04 dod joined #mojo
11:04 batman i guess it should say $pub->subscribe('messages'); ...
11:05 marcus batman: I am now planning Mojo::Redis::Schema ;-)
11:05 batman marcus: what? that doesn't sound right :S
11:05 dod joined #mojo
11:06 batman marcus: i'm doing a new release now: 0.9901
11:06 marcus batman: example looks great, with the correction you just did.
11:06 marcus batman: can discuss my crazy ideas tomorrow.
11:06 judofyr Schema++
11:06 batman cool!
11:06 batman shipping it
11:06 batman *shipped*
11:07 batman that was easy ;)
11:08 batman so... i wonder if i'm going to get any actual work done today :P
11:08 batman marcus: btw... i think you need to press a button here: https://www.getbetsy.com/bet/b21c93edd72a :)
11:08 batman "Only the loser can settle the Challenge."
11:09 marcus 'Delete challenge' seems right
11:09 marcus :D
11:09 batman no, no, no
11:09 batman :D
11:09 batman yay! i'm epic-awesome :)
11:11 marcus uploaded a picture too
11:13 ver joined #mojo
11:13 batman sweet
11:14 batman and it actually worked. that's just crazy, hehe
11:40 D4RK-PH0ENiX joined #mojo
11:43 judofyr batman: I see you have faith in your service
11:54 d4rkie joined #mojo
11:57 memowe \o/
12:02 sri \o\
12:03 ryozi joined #mojo
12:05 * memowe 's so tired: four hours salsa teaching on sunday, eight hours normal work yesterday followed by five ours ballroom teaching. Impossible to raise my arms again: _o_
12:06 memowe s/\bours/h$&/
12:08 crab bours!
12:08 memowe jours!
12:08 bluescreen joined #mojo
12:11 spleenjack joined #mojo
12:16 mire joined #mojo
12:25 spleenjack joined #mojo
12:29 crab what is the right way to use the ->tag() helper from my own helper?
12:30 good_news_everyone joined #mojo
12:30 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/Y1uVfw
12:30 good_news_everyone mojo/master 0148799 Sebastian Riedel: fixed small bug where "chunked" would not always be the default transfer encoding
12:30 good_news_everyone left #mojo
12:30 crab $app->tag(...), right?
12:31 sri $c->tag() imo
12:32 sri the overhead of $app->tag() doesn't seem worth it
12:57 dvinciguerra joined #mojo
13:07 ladnaV joined #mojo
13:17 Vandal joined #mojo
13:18 Mike-PerlRecruiter_ joined #mojo
13:22 ladnaV joined #mojo
13:24 mire joined #mojo
13:27 batman joined #mojo
13:48 Vandal joined #mojo
13:51 batman joined #mojo
14:06 crab it's very rewarding to revisit my old plugins and hooks and see how much cleaner i can make them now (that various things are either no longer experimental, or there are better ways to do them)
14:07 Adurah Code works, I'm happy.
14:11 ladnaV joined #mojo
14:19 crab is that a response to what i said, or an unrelated statement?
14:23 judofyr it's a statement
14:24 crab it is certainly a statement, but is it also a response to what i said?
14:24 * sri wonders if this issue is going anywhere https://github.com/kraih/mojo/issues/410
14:29 atrodo joined #mojo
14:32 atrodo left #mojo
14:39 gryphon joined #mojo
14:41 Vandal joined #mojo
14:46 bobkare sri: My command idea turns out to be impossible. Would a patch to hypnotoad to split the run method into a few different methods that would make it less impossible to customize things be considered, or rejected because I'm not supposed to be able to use hypnotoad the way I want?
14:47 sri bobkare: prolly rejected
14:48 bobkare So basically I have to become a web framework maintainer to be able to configure a simple app server?
14:48 bobkare That makes absolutely no sense to me
14:50 sri you should have joined the discussion in february when the config files were changed ;)
14:50 Adurah I load config files based on hostname.
14:51 bobkare Adurah: but it's all based on the fact that you are both sysadmin and app developer, right?
14:52 Adurah Pretty much.
14:52 sri the philosophy behind hypnotoad these days is simply that the server *is* your app
14:53 sri similar to node.js, it's the new wave
14:53 sri perhaps you would be happier using some PSGI server
14:54 bobkare one of the things I like about mojo is how an app can be this really small 5-minute job and I can deploy it with about 4 lines of puppet manifest. Sadly that means I'm limited to mojo versions that are getting a bit old
14:54 bobkare does all the nice nonblocky interactive stuff like websockets and such play nice with that?
14:55 sri no
14:55 crab bobkare: how do you want to split the run method, and how would it help you?
14:57 crab i've also wondered how mojo apps are configured for heroku, and never quite understood
14:57 bobkare crab: I can easily replace the hypnotoad wrapper script with a command which gives me a bit more control. Then if I could get control of app initialization I could configure what I want before starting the run loop.
14:58 sri crab: it's very very trivial https://github.com/judofyr/perloku
14:58 bobkare crab: So I'd basically want to split initialization and the run loop
14:58 bobkare crab: as far as I can tell that doesn't work with hypnotoad, it just uses the plain daemon
15:00 sri such a change would have to bring amazing unit tests to even be considered
15:00 zivester joined #mojo
15:00 sh4 joined #mojo
15:02 bobkare why?
15:02 sri also, the HYPNOTOAD_* env vars are not public api, they could change at any time
15:05 sri because hypnotoad is extremely complicated code, making the api more complex can easily make it unmaintainable
15:05 bluescreen joined #mojo
15:06 bobkare Right, so making hypnotoad behave is supposed to be impossible. What about splitting the most complicated part, which as far as I understand it is zero-downtime restart, and have the preforking part be a separate thing? Mojo::Server::PreforkDaemon or something
15:07 judofyr bobkare: what is the real issue here? what do you want to do?
15:07 sri making hypnotoad more testable and giving it amazing unit tests is a worthy goal i can get behind
15:07 sri if that involves splitting the module i would be ok with that
15:08 coff sri: I will get behing putting resources towards that goal
15:08 coff *behind
15:09 sri key is that hypnotoad gets more and better testing, not more special cases
15:09 bobkare judofyr: I want my puppet module that deploys mojo apps with very little config (essentially svnurl and port) to continue working with new versions of mojo
15:10 sri judofyr: https://github.com/kraih/mojo/issues/280
15:11 sri i've changed my stance since then though, imo the server *is* the app now
15:11 bobkare Uh, about that ticket. Did the original issue of setting logfile actually get fixed there? I've got a couple of lines of code to set logfile and level from config file that I try to remember to copy/paste between apps
15:12 bobkare But OK, when I find some time I'll start looking into separating out the preforking bits and writing tests for that
15:13 sri kick ass tests please
15:13 sri they have to gain us something over the current t/mojo/hypnotoad.t
15:15 crab that perloku thing only sets PORT from the environment, and yeah, it doesn't use hypnotoad.
15:15 sri you basically never use hypnotoad on a cloud hosting service
15:15 crab how come?
15:15 sri zero downtime has no value there and they have custom process watchers
15:16 sri you just spin up more little isolated daemon instaces on demand
15:16 sri the cloud routing layer takes care that nothing gets interrupted
15:17 dod joined #mojo
15:17 alester joined #mojo
15:17 bobkare But for say the free one worker heroku plan, wouldn't a preforking server be likely to improve how much you could squeeze out of one heroku instance?
15:17 sri no
15:18 sri the router limits incoming connections
15:21 bobkare ok. not relevant to me though, cloud providers are for several reasons not an alternative to us
15:25 sri judofyr: basically, bobkare wants to be able to configure hypnotoad without having to ask the app developer to add the appropriate options to the config file
15:25 crab wait, the one-worker heroku plan means one concurrent connection?!
15:26 crab surely not
15:26 inokenty joined #mojo
15:26 sri crab: not anymore i believe
15:27 ladnaV joined #mojo
15:27 sri but there are still strict limits
15:29 knshaum joined #mojo
15:31 Vandal joined #mojo
15:33 sri bobkare: btw. splitting up hypnotoad into multiple modules is something i'm not too keen on, they would all have to be useful on their own and the api look elegant
15:36 sri we once had a plain prefork daemon... it did not work out well https://github.com/kraih/mojo/blob/b3​f6a8c1edbe3813a39e43e2ffbd9c49b7b2a9c​1/lib/Mojo/Server/Daemon/Prefork.pm
15:44 bobkare I was thinking rip out the parts of hypnotoad that are related to preforking, no daemonization or anything like that. It would be a subclass of Daemon and the interface would just be an extension with the extra parameters that are relevant. It would be a snap-in replacement so hypnotoad would simply instantiate that instead of a plain daemon
15:44 bobkare Did hypnotoad ever use that, or was the daemonize, pidfile etc functionality duplicated?
15:45 sri hypnotoad replaced that
15:45 sri what would be the gain of the new class for mojolicious as a whole?
15:46 bobkare What is the bar for usefullnes? If all my usecases are deemed unwanted and useless it probably wouldn't count as much of an improvement
15:47 sri well, it has to convince the other core devs to give it a +1 vote
15:47 bobkare but if you see hypnotoad as having too much complicated code then surely getting some of it out of there and into a place where it's easier to test it by itself is a good thing?
15:48 sri having worked on Mojo::Server::Daemon::Prefork, that code was just as horrible to test
15:48 sri i don't see an improvement just by splitting the module
15:48 sri you still have to duplicate pretty much everything from t/mojo/hypnotoad.t
15:49 bobkare do you have any thoughts on what parts of it makes it hard to test?
15:49 sri preforking in general
15:49 sri zero downtime restart is actually not that bad, just requires thought to find the right test cases
15:50 sri from my point of view Mojo::Server::Prefork would gain us nothing, besides duplicated tests in t/mojo/hypnotoad.t and t/mojo/prefork.t
15:51 sri it makes the testing situation worse
15:52 bobkare So having a base so other people can make preforking servers for mojo doesn't count as an improvement?
15:52 sri it's not a common use case
15:53 sri but i'm just voicing my opinion, there are 3 more votes
15:53 bobkare From my perspective I'm getting towards two alternatives: A) Never ever again upgrade mojolicious B) Use plain Daemon.pm which it will be a royal pain to scale if we have to.
15:54 sri that's silly, scaling daemon is the easiest thing in the world
15:54 sri just spin up more instances when necessary and buy some RAM
15:54 bobkare plus add an extra load balancer
15:55 sri scaling without a load balancer? :)
15:56 sri hypnotoad is meant to run behind a reverse proxy
15:58 bobkare yeah, but with hypnotoad I can point varnish at the single port where there are as many workers as needed/wanted on a given host
15:58 sri do we actually have anyone else here that would like a prefork daemon building toolkit in mojolicious?
16:02 bobkare Why can't it be a feature that something like the following puppet manifest works? mojolicious::app {'appname': svnurl => 'http://...', port => 1234, workers => 8 }
16:03 bobkare One thing I really like about mojo is how that used to be possible, even for really trivial apps where the dev doesn't bother with lots of deployment-related code
16:03 sri my -1 vote for that is because it duplicates already existing functionality and sucks to explain in docs
16:04 sri and of course, again, the need to test everything twice
16:04 sri also, i'm pretty sure if we add that, your next request would be for being able to configure logs files with it
16:05 sri which would make everything a total mess
16:05 bobkare why would you need to test preforking again in hypnotoad.t if it's already tested in prefork.t? Do you duplicate all the daemon tests into hypnotoad?
16:05 bobkare I wouldn't need to, I could easily live with the default stderr and just redirect that
16:06 bobkare Command::daemon with better scalability is basically what I need
16:06 sri sorry, but this discussion is going circles now, i'm gonna step back a bit and let others chime in
16:07 bobkare sri: I'd love an answer to my last line about duplicated tests
16:08 sri perhaps you should highlight what you really want, which seems to be a third server option in mojolicious
16:09 sri because the tests would look exactly the same, even if they had different purposes, i've been there
16:09 mire joined #mojo
16:14 Britzel joined #mojo
16:14 dod joined #mojo
16:15 bobkare Do the hypnotoad tests actually test prefork specific things like multiple workers, hung workers, and restarting workers after a certain number of requests? I don't see how tests for that look exactly like tests for zero-downtime restart
16:17 thaljef joined #mojo
16:18 SmokeMachine joined #mojo
16:30 labrown joined #mojo
16:34 memowe joined #mojo
16:42 SmokeMachine joined #mojo
16:54 xaka joined #mojo
17:12 sh4|2 joined #mojo
17:31 zivester joined #mojo
17:32 zivester joined #mojo
17:46 Vandal joined #mojo
17:47 ladnaV joined #mojo
17:49 thaljef joined #mojo
18:31 dpetrov_ joined #mojo
18:48 bobkare sri: Just to try to understand your viewpoint: Is your position that the app dev is responsible for pretty much everything related to deployment? If so, why doesn't the output from generate_lite, generate_full or MojoExample contain the necessary code to make deployment with hypnotoad, which seems to be the preferred thing, possible?
18:50 bobkare well, it would work, but only for one app per server since you can't change the port it listens on
19:10 tempire joined #mojo
19:16 tempire as I see it, issue 410 is already solved in.  I've kept it open because useful information came out of it, and people might still have opinions.
19:18 tempire sri: in other words, you don't need to take responsibility for closing it.  I will handle it.
20:31 rem_lex|pivo joined #mojo
20:32 lukep joined #mojo
20:50 marcus \o/ new Textual is finally out
21:12 asarch joined #mojo
21:20 xaka joined #mojo
21:45 batman joined #mojo
22:24 asarch joined #mojo
22:27 * tempire voted
22:32 marcus tempire: I sure hope you voted for the black guy.
22:34 tempire I voted for a 3rd party.  I don't think either of the two main party candidates are fit to lead.
22:35 tempire unless it's a karaoke party.  then I'm all for obama.
22:35 marcus tempire: I agree about that, but your system basically works as a 2 party system.
22:35 marcus tempire: I think there's a significant difference between them tho.
22:37 tempire I refuse to accept that it's only a 2-party system, no matter what.
22:37 * tempire fights the good fight
22:38 tempire I'm much more interested in the local candidates and propositions, though.
22:45 lukep joined #mojo
22:49 jzawodn joined #mojo
22:57 crab in a plugin, i want to add nested routes under a particular named route (established before calling ->plugin)
22:57 crab is this supported, and if not, is there a better alternative?
23:00 marcus batman++ # JIT coding
23:01 * batman need to ask google for JIT
23:01 batman hehe
23:01 batman marcus: i really, really, really like redis://foo:AUTH@host:port/DB_INDEX support
23:01 batman going to make my life easier
23:02 marcus I really like beating people at letterpress.
23:02 marcus but that is neat too :)
23:02 batman :O
23:02 marcus and it actually works!
23:03 batman my commit or letterpress?
23:03 marcus commit
23:03 batman what did you expect? ;)
23:03 marcus Just tested url syntax in the example for oslo.pm tomorrow
23:03 marcus horrible eldric horrors
23:03 batman haha! but... https://github.com/marcusramberg​/mojo-redis/blob/0.9902/t/auth.t
23:04 batman i've tested it ffs! :)
23:04 marcus :)
23:04 crab any ideas?
23:04 marcus crab: about nested routes inside plugins?
23:04 marcus crab: or finding a route by name?
23:05 crab finding a route by name, or doing something functionally equivalent to allow a plugin to establish extra routes in a user-selected place.
23:05 crab i'm not attached to any particular way of accomplishing it
23:06 marcus crab: iterate over the https://metacpan.org/module​/Mojolicious::Routes::Route object and find your named child?
23:06 crab though i do want to be able to do it in multiple places, so ->plugin('x', pt1 => ..., pt2 => ..., pt3 => ...) may not be the best way.
23:07 marcus crab: actually, there's a ->find() that takes a name.
23:07 crab oh wow.
23:08 * marcus heads for bed
23:08 marcus nite guys, great work batman!
23:09 crab protecting gotham city tirelessly?
23:09 marcus crab: improving mojo-redis
23:09 marcus and getting it released before my tutorial tomorrow :)
23:13 batman marcus: see you around
23:14 batman three releases in one day... not too bad :)
23:20 gryphon joined #mojo
23:24 crab batman: good job
23:30 * crab sees the (no-longer-)new rearranging routes section in the routing guide
23:35 crab find and add_child are my bestest friends
23:40 Averna joined #mojo

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