Camelia, the Perl 6 bug

IRC log for #mojo, 2011-11-13

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

All times shown according to UTC.

Time Nick Message
00:07 mire_ joined #mojo
00:08 tempire must be fun after all.
00:16 tm and do the job better than the previous one ;)
00:17 tm I just want to see mojolicious under hypnotoad on a server with 8-core CPU with 4xHT on each core...
00:18 tm 32 CPU threads at the same time
00:18 * sri wants to see that too
00:19 tm I'll try to bring the box up this week
00:19 sri should scale nicely, my bet is on 2 workers per core for best performance
00:20 tm for sure have one with 6-core x4 HT, so virtually 24 threads
00:20 tm but that's on 1 thread per core
00:20 tm thread in means of HT
00:20 tm this is 6-core with 4-way hyperthreading on each core
00:21 tm linux says CPU 0..23 - shows them separately, so my bet would be 1 worker per core for max throughput
00:22 sri when i say core i mean hyperthread ;)
00:22 tm ahh ok :)
00:22 tm we can try for sure
00:22 sri my bet is still on 2 workers
00:23 tm little off-topic... I maxed out FastCGI with simple CGI-type apps, Catalyst eats up tons of RAM... mojo is light and I can remove apache which is choke point now
00:24 tm sri: do I get it right - hypnotoad is request dispatcher... if I have 10 workers, is it 10k requests max or still 1k requests?
00:24 tm assuming I leave max request on defaults (1k)
00:25 sri http://mojolicio.us/perldoc/M​ojo/Server/Hypnotoad#clients
00:26 tm so clients * workers
00:26 * sri nods
00:26 tm sweet... most of my capcity issues taken away!
00:27 tm we used to use FastCGI with CGI-type app, now the team has written our own sockserv...
00:28 tm didn't like my suggestion of using AnyEvent - coded low-level in perl IO::Socket
00:28 tm didn't get to live deployment and already have problems maintaining it
00:28 tm last week told them to move to mojo... got some attention (wooot!)
00:29 tm fingers crossed
00:29 sri i used to be a FastCGI fan, but now that my focus has shifted towards realtime apps i'm all for http all the way
00:30 tm same here - we need to be almost real-time
00:30 chansen tm: sockserv, do you mean they pass fd suing sendmsg()?
00:30 chansen s/suing/using/
00:30 tm chansen: something like that - more like select() loop across FDs
00:30 chansen hardly something like that then
00:31 tm prolem is with external APIs - some cause delay up to 8sec... and FastCGI accept loop is linear
00:31 tm so max clients = number of FCGI processes
00:31 tm doesn't scale too well
00:31 tm no state shared between requests
00:31 sri ohoh, blocking will screw up hypnotoad too
00:32 tm I know
00:33 chansen tm: 8 sec delay? WTF?
00:33 tm but in normal operation HTTP requests (external API) are non-blocking, right?
00:33 tm chansen: database query sometimes gets dropped on other side, times out after 8
00:33 * sri goes searching for something to eat
00:33 tempire no pizza this time
00:33 tempire vegetables
00:33 purl If god had wanted us to eat vegetables, he would have made them out of meat. or what food eats
00:33 sri :S
00:34 sri tm: can be both, your choice
00:34 tempire antioxidants are good for mongodb development
00:34 chansen tm: sounds you have other issues to solve before looking for a efficient frontend
00:34 tm sri: plan is to go non-blocking all the way so we can take more requests in parallel without locking resources
00:35 tm chansen: true, but those APIs are independent, not under our control
00:35 tm and some are even worse
00:35 tm yet we have to use them
00:35 * chansen calls for kebab
00:35 tm yummy :)
00:35 sri think i still have some cheese filled jalapenos, those count as vegetables too, right? :)
00:36 chansen sri: not bad, lets have a picnic ;P
00:37 sri \o/
00:39 tempire best intro to redis pubsub?
00:39 tempire a screencast, maybe?
00:42 tm 1sec, I've seen something few days ago
00:45 tm sorry, can't find it... there was something on slideshare I believe
00:45 * tempire blocks ™ for 8 seconds
00:45 tm request timed out :D
00:46 mire_ joined #mojo
00:47 chansen tempire: you better switch from FastCGI then ;P
00:57 metaperl joined #mojo
01:06 tm good night folks
01:06 purl and bots!
01:06 tm thanks for your wisdom - learned a lot today :)
02:08 jimbo joined #mojo
02:08 jimbo good evening mojo
02:12 driller_work joined #mojo
02:48 gabriel_ joined #mojo
03:17 d4rkie joined #mojo
04:35 MojoGuest156 joined #mojo
04:35 MojoGuest156 From: http://news.ycombinator.com/item?id=1277067 (101 hits)
04:35 MojoGuest156 /server irc.dalnet.org
04:36 MojoGuest156 left #mojo
05:24 crab good lord, dalnet is still around.
06:10 Vandal joined #mojo
06:26 Eugene joined #mojo
06:34 Eugene joined #mojo
07:23 azawawi joined #mojo
09:13 MojoGuest459 joined #mojo
09:18 sugar joined #mojo
10:29 Foxcool joined #mojo
11:55 azawawi joined #mojo
12:10 sri hmm
12:10 sri still unsure where to go with Mojo::IOLoop
12:11 sri Mojo::IOLoop->connect(address => '127.0.0.1', port => '3000', sub { my ($loop, $stream) = @_; });
12:11 sri maybe something like that
12:11 Psyche^ joined #mojo
12:11 sri and just get rid of the on_read/on_close/on_error callbacks
12:33 crab the sub will be called for all events?
12:34 crab oh, or when the stream is created, and then it can register callbacks on the stream? or?
12:35 azawawi left #mojo
12:36 marcus oh hai
12:37 * marcus is at london hackspace
12:42 sri crab: the callback is called once when the stream is created, yes
12:43 sri one little problem though… error events can happen before the stream is created :/
12:44 sri for Mojo::IOLoop->listen it's easier, since it can only emit accept events
12:45 sri (the modules behind the scenes are Mojo::IOLoop::Client and Mojo::IOLoop::Server)
12:57 sri Mojo::IOLoop->connect(port => '3000', sub { my ($loop, $error, $stream) = @_; });
12:57 sri perhaps that could work
13:02 sri there might also be a simple deprecation path
13:03 noganex_ joined #mojo
13:03 sri Mojo::IOLoop->client(port => 3000, sub {…});
13:03 sri same for ->server()
13:13 sri ok
13:13 sri http://pastie.org/2856616 # old or new?
13:13 * sri pokes tempire
13:24 batman is it possible to dispatch on this kind of path: /foo/date/:date/tags/:tag1/:tag2/ where both tags and date are optional?
13:25 batman maybe i can solve it by adding three routes instead...
13:33 baton8 joined #mojo
13:45 sri it's actually just a small api change, we already have full access to the stream api with Mojo::IOLoop->stream($id)
13:46 sri basically the removal of a small convenience/backcompat layer
14:01 mire_ joined #mojo
14:41 abra joined #mojo
14:56 marty sri: I have not used IOLoop yet.  From looking at your examples my newbie impression is that the new example is not any more difficult to grok than the old example.
14:57 sri marty: and not any easier?
14:58 marty Yes, it is easier.  especially, $stream->write over $loop->write
14:58 sri i see
15:01 marty batman: If they are optional then yes, either multiple routes or a single wildcard palceholder
15:02 batman ok
15:03 mire_ joined #mojo
15:07 marty sri: I also think $stream->on(read => sub {} reads much better than on_read => sub {}  (In my newbie opinion)
15:07 sri marty: agreed
15:30 SmokeMachine joined #mojo
15:42 MojoGuest78 joined #mojo
15:42 MojoGuest78 From: http://news.ycombinator.com/item?id=1277067 (102 hits)
15:42 MojoGuest78 left #mojo
15:54 SmokeMachine joined #mojo
16:01 sugar joined #mojo
16:36 sri hmm, what would be a reasonable time based alternative to "one major release" in our deprecation policy?
16:36 sri 3 months, 6 months… other?
16:38 batman i think 3 months is not long enough
16:40 sri either i add a time alternative or we will have regular (boring) major releases to get rid of deprecation cruft
16:48 marty I see no logical reason to extend the deprecation period.  If it is determined that a feature needs to be deprecated then do it.   I see no benefit to a long deprecation period other than allow upgrading while ignoring deprecated features.
16:49 marty Long deprecations can hinder innovation.  imo
16:50 marty purl: short deprecation is RIP THE BAND-AID OFF!
16:50 purl OK, marty.
16:50 marty short deprecation?
16:50 purl short deprecation is, like, RIP THE BAND-AID OFF
16:51 * marty hugs purl
16:51 * purl hugs marty back
16:52 driller_work joined #mojo
16:55 sri marty: how many months would you suggest?
16:56 marty No more than 3.
16:56 sri interesting
16:56 marty I'm strange in that way
16:57 marty I'd rather see fast innovation and stick to my current version until I can deal with deprecation rather than see the software stagnate until I catch up.   Just my preference.
17:00 mire_ joined #mojo
17:03 sri http://pastie.org/2857454 # here's a full old vs new for what i have so far btw.
17:06 sri only thing i'm not sure about is the second argument for both callbacks
17:06 sri $id and $error
17:06 sri but that information needs to be passed along somehow
17:07 batman you can innovate, without breaking everything.
17:07 sri not always
17:07 sri and not easily
17:07 batman example bad decision for a three month deprecation: make all methods die instead of return $any
17:08 batman ..or remove something Mojo::Base would normally set up for you
17:08 batman imho
17:09 sri please elaborate, i don't see an argument
17:10 batman maybe you could do like moos, when you want to make some major change: download all mojo-modules and try to build them. if they don't, send an rt ticket...
17:10 sri half of the mojo modules on cpan are broken
17:11 sri people have ignored deprecations since i started using them
17:11 batman how do you inform about "deprecations" ?
17:11 sri changes of course
17:11 batman no warnings in code?
17:11 sri of course
17:12 sri but let me give you an example for something that couldn't be deprecated
17:12 sri for 2.0 we changed from callbacks to events
17:13 sri events have entirely different semantics
17:13 sri there is no way to have 100% backcompat for callbacks
17:14 sri that shit is real innovation, pretty much nobody does it that way yet, we have no idea where it is heading
17:15 sri or websockets, i can only add experimental warnings and hope for the best
17:15 sri or a simple example, camel case command names turned out to be a failure
17:15 batman i'm struggling between wanting to deprecate things and understanding the work to maintain scripts that are running in prod without "the best test coverage"
17:16 sri so we had to rename all commands to lowercase
17:16 sri that stuff behaves differently on case insensitive file systems
17:16 sri try deprecating that!
17:16 batman i see your point
17:17 batman i also guess that if someone don't want to fix their app, they could just bundle an old version of mojo to the given app
17:18 batman maybe that could even be in some sort of deprecation.pod file... like "if you don't want to keep your api up to date, you better bundle a given version of mojo to your app" :P
17:19 sri that said, we've had almost no backcompat issues that weren't simply bugs since 1.0 :)
17:19 batman that's cool :)
17:21 sri deprecations start piling up though, atm i think we have around 55 active
17:21 batman gf is home. need to start making dinner...
17:22 sri some do block new development, like the plugin ones… and possibly the upcoming ioloop changes
17:23 sri now back on topic! ;p
17:23 sri http://pastie.org/2857454 # i'd like some opinions
17:23 * sri pokes tempire, crab and marcus
17:23 * sri pokes yko
17:24 sri marty: maybe from you again (since arguments changed slightly)
17:25 sri the whole stream part is pretty much set in stone… but ->client/->server semantics are up for discussion
17:25 marty I see your point on $id and $error.  But I have no solutions.  :(
17:26 sri :,(
17:26 marty But overall I do think it is an improvement over the old.
17:26 sri improvement is not good enough, we need awesome
17:28 marty Also, $loop gives me trouble.
17:28 sri $id needs to be passed because the server creates new connections, and $error since we need to pass along connection errors
17:28 sri $loop is fine, it's just the Mojo::IOLoop instance
17:28 marty Ahhh, ok
17:30 marty Well for me.  Once I know what $id and $error are for, then I just commit it to memory and move on, even if I will not use them in any way.
17:31 sri the more i look at it the less i actually mind them
17:31 sri feel a bit random though
17:35 marty random maybe, but they are descriptive.
17:37 Eugene joined #mojo
17:40 yko sri: what's the point of such changes?
17:40 yko well, I understand the idea and it looks good, yeah
17:41 yko but every time you breaking compat I'm taking a voodoo doll, needles...
17:43 yko btw, why $id is not an attribute of stream?
17:44 sri yko: it's still the process of getting rid of callbacks in favor of events
17:45 sri the stream layer has no concept of id
17:45 yko I'm going to migrate one application I wrote about a year ago... from Mojolicious 1.21 to 2.25
17:45 yko and I'm walking around it last week - just afraid to start
17:46 sri i'd like to get Mojo::IOLoop to the point where people can really depend on it
17:46 sri sooner or later the changes i'm proposing now will happen anyway
17:46 sri since events are here to stay
17:47 yko I'm just explaining my point of view :)
17:47 sri sure
17:47 sri i'm glad you bring it up, that's why i started the discussion in the first place ;)
17:48 yko But talking outside of context that I have few Mojolicious-based applications I have to support, the way yo uare going looks nice
17:49 sri the only use for $id btw. is $loop->drop($id) and $loop->stream($id) as far as i can see
17:49 yko I don't get what 'stream' would be, but it really looks $id and $error should be just an attribute. doesn't it?
17:50 sri Mojo::IOLoop::Stream
17:50 sri not sure
17:51 yko $stream->drop? :)
17:51 sri $stream->close will trigger a drop :)
17:51 yko well, why the hell you need an id then? :)
17:52 sri all servers i've written rely on a unique connection id
17:52 yko overload stream's "" and make it return $id. and then you could just pass $stream around :)
17:52 sri we have one inside Mojo::IOLoop… it feels weird to generate another one for every server that uses it
17:53 sri hmm
17:53 yko ok, that's because I didn't look inside of Mojolicious for a while
17:53 yko so I just don't know why stream is here and what it's purpose
17:54 sri http://mojolicio.us/perldoc/​Mojo/IOLoop/Stream#SYNOPSIS
17:56 sri it mostly stands on its own, that's why it feels weird to add an id or error attribute it wouldn't use directly
17:57 sri you're prolly thinking of $tx->error, which is similar
17:57 sri those errors also come from inside the parser though
17:57 yko agree
17:58 yko the way I offered isn't acceptable
17:58 sri node.js has a similar problem with errors and callbacks
17:58 sri they went with error as first argument
17:59 MojoGuest992 joined #mojo
17:59 sri eventmachine differentiates between callback and errback
17:59 MojoGuest992 From: http://www.google.co.uk/url?sa=t&rct=j&q=h​tml5%20irc&source=web&cd=4&ved=0CDoQFj​AD&url=http%3A%2F%2Fdev.xantus.org%2F&ei=Y​AXATrnWKJLE8QP865nwAw&usg=AFQjCNGw6nZv0wO42uzU​nHhWcD0vcKNULg&sig2=EliwYYtti2T1rG2U8Qqfmw (1 hits)
17:59 yko well, I'll be  honest - it's very hard to say are changes good or no. a big part of me against any changes :)
18:00 sri short term i totally agree with you yko
18:00 sri we're in it for the long run though
18:01 MojoGuest203 joined #mojo
18:01 MojoGuest203 From: http://www.google.co.uk/url?sa=t&rct=j&q=h​tml5%20irc&source=web&cd=4&ved=0CDoQFj​AD&url=http%3A%2F%2Fdev.xantus.org%2F&ei=Y​AXATrnWKJLE8QP865nwAw&usg=AFQjCNGw6nZv0wO42uzU​nHhWcD0vcKNULg&sig2=EliwYYtti2T1rG2U8Qqfmw (2 hits)
18:02 yko that's why i don't speak loud and much. i'm too subjective in this case
18:04 sri there's also a clean deprecation path here, connect/listen will just keep working
18:04 sri they can actually be tiny wrapper around client/server
18:04 sri *+s
18:04 yko that sounds good
18:05 yko btw, could anyone say if MojoX::Run still works nowadays?
18:05 sri hard to say, it always relied mojo internals
18:06 sri untested/undocumented stuff
18:06 sri *+on
18:08 sri rule of thumb, if its name starts with MojoX it's prolly broken ;p
18:08 yko true for MojoX::CPAN::Uploader :)
18:09 yko I have to throw away my sentiments and delete it
18:10 sri its spirit will live on in "mojo cpanify" :)
18:10 yko oh! I missed that point
18:10 yko than I really have to delete my uploader
18:11 sri you're credited in the changes entry ;p
18:11 yko oh wait. there's no configuration in cpanify :D
18:11 yko no, than long live MojoX::*::Uploader :)
18:13 Sjors can I define helpers from inside my Controller, or do I have to do this in the Mojolicious application itself?
18:13 Sjors (they will only be used by templates that belong to the Controller)
18:25 yko damn, looks like MojoX::Run really broken now
18:27 tempire I'm unsure about ->client, ->server
18:27 tempire but the more I look at it the more I think it's just fine.
18:27 tempire in comparison to ->listen & ->connect, it's kind of funky
18:28 tempire but it makes sense on its own.
18:28 tempire The think I like about the ->connect is that you can pass stuff in as a list.
18:29 tempire with the current implementation of events, you have to embed everything in a sub
18:29 tempire I'm not sure if that would be an issue going forward.
18:29 tempire it does seem less flexible, though
18:32 tempire regarding deprecation...
18:33 tempire the biggest problem is that it's hard to identify if your app is going to be affected by changes if you're upgrading many releases ahead
18:34 tempire like yko's previously stated issue.
18:35 tempire It would be neat if we could scan changes based on git commits, and put changes into a set that could be compared with existing web apps.
18:35 tempire that sounds like a huge project, but it's something to think about going forward.  a new way to manage upgrades and deprecation is what is really needed.
18:37 tempire if each feature/deprecation/thing in changes could be mapped to a specific commit, it could probably be detected using devel::cover techniques
18:38 tempire and a tool to identify potential issues for an upgrade from version x to y would give the developer an idea of how much work is needed to do an upgrade.
18:40 tempire ./appname examine-upgrade [to] 2.04
18:41 MojoGuest289 joined #mojo
18:41 MojoGuest289 From: http://www.google.com/url?sa=t&rct=j&a​mp;q=extjs%20websockets&source=web&amp​;cd=6&ved=0CEoQFjAF&url=http%3A%2F​%2Fdev.xantus.org%2F&ei=3A7ATsqKOebSiA​KZk7y8Aw&usg=AFQjCNGw6nZv0wO42uzUnHhWc​D0vcKNULg&sig2=gjXF9YpiD6QOzYUunxxj1A (1 hits)
18:42 sri tempire: passing callbacks to connect is actually less flexible
18:42 tempire I mean flexible in the assignment, not in functionality
18:42 sri $stream is a full featured event emitter, you can do so much more with it in the new version
18:43 tempire For the record, I'm fine with the pastied implementation of ->client/->server
18:43 lammel2 joined #mojo
18:43 sri ok, any thoughts on $id and $error?
18:44 lammel2 joined #mojo
18:44 tempire I must have missed that conversation.
18:45 sri i'm mostly happy with client/server, just those two arguments feel a bit odd
18:53 sugar joined #mojo
18:54 lammel2 left #mojo
19:12 vel joined #mojo
19:13 smpb joined #mojo
19:25 mire joined #mojo
19:50 sri hmm, deprecating connect/listen is way easier than i expected :o
20:16 gshank joined #mojo
20:31 andrefs joined #mojo
21:05 d4rkie joined #mojo
22:13 vel joined #mojo
22:40 sri also found quite a few small bugs :)
22:49 mojimbo joined #mojo
23:23 SmokeMachine joined #mojo
23:27 sri yko: are you using the _class attributes from Mojo::IOLoop?
23:27 sri i remember adding them for you, but you never said if we should keep them
23:34 SmokeMachine joined #mojo
23:45 MojoGuest710 joined #mojo
23:45 MojoGuest710 From: http://www.google.com.tr/url?sa=t&rct=j&​amp;q=html5%20irc%20&source=web&cd=5​&ved=0CD0QFjAE&url=http%3A%2F%2Fdev.​xantus.org%2F&ei=kVbATseyOtP54QSpstz9AQ&​amp;usg=AFQjCNGw6nZv0wO42uzUnHhWcD0vcKNULg&a​mp;sig2=JUzzl8n1QojZCfLHoQZA8w&cad=rja (1 hits)
23:45 MojoGuest710 /server irc.freenode.net
23:45 MojoGuest710 pifff
23:46 MojoGuest710 left #mojo
23:47 tm joined #mojo
23:47 tm evening
23:51 SmokeMachine joined #mojo
23:54 * sri waves
23:58 * tm is trying to figure out one good reason to use Mojolicious::Plugin::Redis and can't find any
23:59 sri micro plugins like that one primarily exist for documentation
23:59 sri even if you don't use it, you have an actual usage example
23:59 tm they are nice - you can learn how to write your own

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