Camelia, the Perl 6 bug

IRC log for #mojo, 2011-10-29

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

All times shown according to UTC.

Time Nick Message
00:08 MojoGuest203 joined #mojo
00:08 MojoGuest203 From: http://news.ycombinator.com/item?id=1277067 (58 hits)
00:32 metaperl|2 joined #mojo
00:35 andrefs joined #mojo
00:36 tholen__ joined #mojo
00:52 ispy_ joined #mojo
01:12 ispy__ joined #mojo
01:17 perlrocks Twitter: "Mojolicious 2.0, an interesting web framework for Perl via @ genbetadev http://t.co/nSPG9omA" (es) --jferrero http://twitter.com/jferrero​/status/130090740905816064
01:21 ispy_ joined #mojo
01:27 metaperl joined #mojo
01:34 metaperl|2 joined #mojo
01:47 ispy__ joined #mojo
01:54 ispy_ joined #mojo
02:03 mattastrophe joined #mojo
02:04 ispy__ joined #mojo
02:16 metaperl|2 joined #mojo
02:40 ispy_ joined #mojo
02:46 ispy__ joined #mojo
03:11 mire joined #mojo
03:16 ispy_ joined #mojo
03:21 ispy__ joined #mojo
03:25 ispy_ joined #mojo
03:31 ispy__ joined #mojo
03:48 ispy_ joined #mojo
04:06 metaperl|2 joined #mojo
04:08 MojoGuest429 joined #mojo
04:08 MojoGuest429 From: http://www.google.com/url?sa=t&rct=j&​q=html5%20irc%20client&source=web&cd=​2&ved=0CCQQFjAB&url=http%3A%2F%2Fdev.​xantus.org%2F&ei=Q3yrTrD_MIqs8QOroa2ZCw&a​mp;usg=AFQjCNGw6nZv0wO42uzUnHhWcD0vcKNULg (1 hits)
04:09 MojoGuest780 joined #mojo
04:09 MojoGuest780 From: http://news.ycombinator.com/item?id=1277067 (59 hits)
04:18 ispy__ joined #mojo
04:22 GitHub69 joined #mojo
04:22 GitHub69 [mojo] kraih pushed 1 new commit to master: http://git.io/XmRgGw
04:22 GitHub69 [mojo/master] added on method to Mojolicious::Controller and message event to Mojo::Log - Sebastian Riedel
04:22 GitHub69 left #mojo
04:25 ispy_ joined #mojo
04:30 sri app->log->on(message => sub {…}) should be the perfect beginner event :)
04:30 perlrocks Twitter: "Mojolicious 2.15 by SRI - http://t.co/kxDyySl5" --cpan_new http://twitter.com/cpan_new​/status/130139409466134528
04:40 ispy__ joined #mojo
05:01 ispy_ joined #mojo
05:29 ispy__ joined #mojo
05:31 Vandal joined #mojo
06:03 kaare joined #mojo
06:28 ispy_ joined #mojo
07:50 noganex joined #mojo
07:58 mire joined #mojo
08:01 Eugene joined #mojo
08:21 sugar joined #mojo
08:22 Vandal joined #mojo
08:57 perlrocks Twitter: "Web Status Checker made a simple Perl "mojo-checkbot" - MOONGIFT | IT engineers axis and introduce open source software, Web Designers Blog http://t.co/55nsWPK5" (ja) --ariki4160 http://twitter.com/ariki416​0/status/130206675218075648
09:00 perlrocks Twitter: "ドイツの製版用サーバソフト、REDHAD用なのを無理やりCentOSに入れ​たりなど割とCentOSには愛着があるのだけれども、そろそろ潮時なのかな。 / “M.C.P.C.: Mojolicious 2はPerl 5.10.1以上を要…” http://t.co/qksqQuoa" (ja) --CLCLCL http://twitter.com/CLCLCL/​status/130207342439563264
09:16 perlrocks Twitter: "MCPC Mojolicious 2] [request more than Perl 5.10.1. Tears in my eyes CentOS 5 by default. : Previously, Mojolicious-unable to install the 1.9.8 ... http://t.co/UEkWKiu6" (ja) --yorozu_yaji http://twitter.com/yorozu_ya​ji/status/130211405793210368
09:41 abra joined #mojo
10:52 batman joined #mojo
10:54 perlrocks Twitter: "Web Status Checker made a simple Perl "mojo-checkbot" - MOONGIFT | IT engineers axis and introduce open source software, Web Designers Blog http://t.co/tGVBtcpV" (ja) --se_binocchi http://twitter.com/se_binocc​hi/status/130236006535409664
11:59 andrefs joined #mojo
12:02 mspo joined #mojo
12:03 mspo can I run morbo or hypnotoad through inetd?
12:10 mire joined #mojo
12:14 mspo does plack need all of cpan?
12:31 batman joined #mojo
12:34 preflex_ joined #mojo
12:35 prefle_x joined #mojo
12:42 noganex joined #mojo
13:04 metaperl|2 let me guess - running a website under http and having passwords stored in plain text is pure suicide
13:15 preflex_ joined #mojo
13:25 mspo what do you mean?
13:34 metaperl|2 i mean running a website on plain http and sotring plaintext passwords would allow them to be sniffed ...
13:34 metaperl|2 I cant invest in running over https
13:59 perlrocks Twitter: "This new event should be great for introductions to using the #mojolicious event api. http://t.co/zougzIOe #perl" --kraih http://twitter.com/kraih/status/130282733980233728
14:14 metaperl|2 joined #mojo
14:26 jwang metaperl|2, storing hashed plaintext passwords would be just as bad. you need some server secret like a salt
14:27 metaperl|2 i'm wondering about this - http://search.cpan.org/~minimal/Mojolicious-Plug​in-Bcrypt-0.03/lib/Mojolicious/Plugin/Bcrypt.pm ...
14:27 jwang well, plain hashes would still be somewhat better, but it would prevent prevent sniffers from compromising accounts
14:27 metaperl|2 so if I run a site over http, then it would be easy for a hacker to compromise it similar to perlmonks.org
14:28 metaperl|2 (which was compromised awhile back)
14:28 jwang wasn't their entire db compromised?
14:29 jwang a sniffer can grab all the passwords it sees on its network, so if you're in the right place, you can grab all the passwords w/o compromising the server
14:29 jwang it's like using raw telnet or ftp
14:30 metaperl|2 yes, the whole database was published
14:30 jwang mmm
14:31 jwang esp bad for the people that use the same password on multiple websites - which is like 99.999% of the people
14:31 metaperl|2 so I guess my question is, if you were building a webapp, how would you store passwords and is https a necessity?
14:31 andrefs joined #mojo
14:31 metaperl|2 Django has salting and hashing built in
14:32 jwang it depends on how big of a target you are. If you're big enough, https, salting and hashing isn't enough.
14:32 jwang so it's a start
14:32 jwang every major service
14:33 jwang uses https for login
14:33 metaperl|2 basically i'm building a site to trade solidcoins, so I expect some attacks
14:33 jwang if the coins have real value, you need https
14:34 metaperl|2 they will have value .. .what's odd is all the mining sites use https
14:34 metaperl|2 i mean http, not https
14:34 metaperl|2 and they have huge wallets of coins
14:34 jwang well, it depends on how big of a target you are as I said
14:34 metaperl|2 is setting up https hard?
14:34 jwang maybe there are much more attractive targets than mining sites
14:35 jwang not really, it's a webserver configuration thing. the biggest issue is that you need to pay $$$ per year for a certificate from a CA unless you want to use a self-signed cert.
14:36 metaperl|2 i think we use self-signed at work
14:36 jwang A self-signed cert is free but is not "trusted" by browsers so users will get an "untrusted cert" error message until they explicitly trust you
14:36 metaperl|2 right
14:36 metaperl|2 yes
14:36 metaperl|2 but I think I can setup https in no time
14:37 metaperl|2 and I would want to reject http ... I wonder how to do all this in a ::Lite app
14:37 jwang yeah, it's just that, and whatever URLs you want to switch to https in your app
14:38 metaperl|2 and then I would store the salt in a config file outside of the app (because the app is opensource)
14:39 jwang then each person running your app can have their own salt - which they should
14:39 jwang you can  make it empty in the default config and fail on startup if it's not there - that way they are forced to come up with something that isn't a default
14:40 jwang not sure where in ::Lite but it seems like you should be able to generically hook the request process and either error out or redirect to https if the request uri is http
14:41 jwang you'd probably want to at least redirect the homepage
14:42 jwang metacpan does http->https redirection on every page
14:42 metaperl|2 hmm
14:42 metaperl|2 I dont see how to specify protocols in ::Lite routing ...
14:43 metaperl|2 I think I might just leave https out of hte picture and get the bcrypt plugin working
14:43 metaperl|2 although the statements about MD5 being insecure are largely impractical in practice --- i would notice if someone were running 7,000,000 crack attempts per second :)
14:45 arpadszasz joined #mojo
14:47 jwang hashes are designed to be very fast
14:47 metaperl|2 yes but no one could hack on my website that fast
14:48 metaperl|2 it would be ddos'ed first
14:48 jwang well, usually what happens, is they compromise your server, download the hashes to their own system, can brute force the passwords there
14:48 metaperl|2 ah
14:48 metaperl|2 yes that's what I was thinking. the main thing is to not get compromised.
14:49 jwang of course, if they compromise your server, they are usually done with you - compromising the passwords of the users individually lets them attck the users other accounts on other servers
14:50 jwang yep
14:51 Vandal is there an analog of Data::Dumper->Dump?
15:10 tempire Vandal: http://mojolicio.us/perldoc/Mojoli​cious/Plugin/DefaultHelpers#dumper
15:10 Vandal it is not the analog
15:13 Eugene joined #mojo
15:41 trone_ joined #mojo
15:46 Foxcool joined #mojo
16:29 tempire it isn't?
16:29 tempire guess I don't know what you mean by analog then
16:33 Eugene joined #mojo
16:38 Vandal sub Dumper and sub Dump of Data::Dumper package are different
16:39 Vandal helper dumper is equiv to sub Dumper
16:41 perlrocks Twitter: "Mojolicious 2.0: Modern Perl For the Web" --PythonPRR http://twitter.com/PythonPR​R/status/130323406955622400
16:49 mattastrophe joined #mojo
16:51 tempire ah
16:51 tempire well
16:51 tempire writing a helper and/or plugin for it would be easy as pie
17:05 Vandal doesn't matter I've alreade find another way
17:14 GitHub136 joined #mojo
17:14 GitHub136 [mojo] kraih pushed 1 new commit to master: http://git.io/kN9hNA
17:14 GitHub136 [mojo/master] better message and request event examples - Sebastian Riedel
17:14 GitHub136 left #mojo
17:22 xaka joined #mojo
17:31 Foxcool joined #mojo
17:47 iana joined #mojo
18:20 trone joined #mojo
18:25 trone_ joined #mojo
18:45 sri hmm
18:45 sri wonder if unsubscribe and unsubscribe_all should be merged
18:52 sri $e->unsubscribe('foo') vs $e->unsubscribe_all('foo')
19:03 mattastrophe joined #mojo
19:08 MojoGuest893 joined #mojo
19:08 MojoGuest893 From: http://blog.kraih.com/perl-is-ready-for-html5 (14 hits)
19:16 mire joined #mojo
19:16 d4rkie joined #mojo
19:32 sri $e->no('foo') and $e->no(foo => $cb) would be kinda funny in combination with $e->on and $e->once
19:42 mire joined #mojo
19:46 tempire I'm really happy about on() as opposed to bind()
19:46 tempire It's strange that prepan doesn't allow searching
19:47 jwang tempire: I'm guessing it's on the backlog but fulltext search often requires other dependencies that push it down lower on the list - solr, elastic search, xapian, etc.
19:49 sri tempire: what about no()?
19:49 jwang though for prepan's size right now perhaps a database full text search would be fine - mysql isam, pg, or sqlite even
19:49 tempire for a full text search sure, but I'd be happy with module name search
19:50 xaka joined #mojo
19:50 tempire no is cute.  how to you remove events now?  unsubscribe?
19:50 sri unsubscribe and unsubscribe_all
19:51 tempire My only concern with whether no is too cute
19:51 tempire *is whether
19:51 tempire but I like it.
19:51 sri there is such a thing as too cute?
19:51 tempire too cute == more code to maintain that no one uses
19:52 sri no would just replace unsubscribe and unsubscribe_all
19:53 sri eventemitter is still experimental, i'll make it stable in the next mini release
19:53 sri that's why i'm cleaning up the method names now
20:02 sri tempire: so you're in favor of the rename?
20:03 tempire oh, did you remove subscribe completely?
20:03 sri yes
20:03 sri actually, i'm moving from subscribers to listeners
20:03 sri since that term is moe universally used
20:04 sri *+r
20:04 tempire hmm.  that seems like a bold step, since subscribe/unsubscribe generally associated with events.
20:04 tempire you think listener is more widely used?
20:04 sri very
20:04 sri google "event listeners" and "event subscribers"
20:04 tempire well, if you don't have subscribe, unsubscribe is dumb.
20:06 sri hmm
20:06 sri actually subscribers wins now -.-
20:06 tempire I like sub/unsub for the record.
20:06 * sri is confused
20:07 tempire the metaphor is universally understood
20:07 tempire I wonder if on/no is a lot to ask from people.  confusion about events seems to be a common theme in here.
20:08 sri ok, lets stick to calling it subscriptions
20:08 sri but the unsubscribe/unsubscribe_all -> no renaming is still up
20:09 tempire I vote for merging them.
20:09 tempire it's perish to accept list and dwim
20:09 tempire
20:09 sri merge only, or merge and rename?
20:10 tempire "ok, lets stick to calling it subscriptions" - I assumed that meant you were going to reinstate subscribe.
20:10 sri there is no subscribe method
20:11 sri there is on/once and unsubscribe/unsubscribe_all
20:11 sri now on/once and unsubscribe
20:11 sri (ignoring emit and friends)
20:12 sri (friends = emit, has_subscribers, subscribers)
20:12 tempire merge unsubscribe and unsubscribe_all
20:12 sri into what?
20:12 tempire unsubscribe fo rnow
20:12 tempire *for now
20:13 sri for now is not good, i want to remove experimental state
20:13 tempire hmm
20:14 tempire it seems dumb to have unsubscribe without subscribe.
20:14 tempire I wonder if there's a more obvious name other than "no"
20:15 sri there's has_subscribers and subscribers though
20:16 tempire we really need a solid tutorial on events.
20:16 sri events are hard
20:16 tempire shopping?
20:16 purl shopping is a drag. or a great time, if it's *barber* shopping! </kitch>
20:16 sri \o/
20:22 sri tempire: you prefer unsubscribe over no?
20:23 sri unsubscribing won't be very common i think, so it's not that important
20:24 sri most of our event emitters have only a limited lifetime anyway
20:24 sri somehow i'm also more comfortable with unsubscribe
20:24 tempire Well I definitely don't like unsubscribe_all
20:25 tempire unsubscribe is safer…I'm unsure because no is so pretty, relative to unsubscribe.
20:25 sri no is also a built-in
20:25 purl okay, sri.
20:25 tempire but I don't think that's a good enough reason to switch by itself
20:26 sri even if it's ok for methods, i generally don't like using names of built-ins
20:26 tempire hrm.  I vote unsubscribe somewhat ambivalently.
20:27 tempire it's almost halloween!
20:27 tempire do they have halloween in europe?
20:27 sri nope
20:28 tempire boo
20:29 GitHub19 joined #mojo
20:29 GitHub19 [mojo] kraih pushed 1 new commit to master: http://git.io/IsEIhg
20:29 GitHub19 [mojo/master] removed experimental status from Mojo::EventEmitter and merged unsubscribe_all method into unsubscribe - Sebastian Riedel
20:29 GitHub19 left #mojo
20:33 MojoGuest957 joined #mojo
20:33 MojoGuest957 From: http://www.google.com.tr/url?sa=t&amp;rct=j​&amp;q=websocket%20provider%20for%20extjs%2​0demo&amp;source=web&amp;cd=3&amp;ved=0CDwQ​FjAC&amp;url=http%3A%2F%2Fdev.xantus.org%2F​&amp;ei=-GKsToibNMzOswai443RDw&amp;usg=AFQj​CNGw6nZv0wO42uzUnHhWcD0vcKNULg&amp;cad=rja (1 hits)
20:34 MojoGuest957 testing
20:34 sri fail
20:34 MojoGuest957 :)
20:35 sri emit_safe will stay experimental since i'm not sure about the implementation yet
20:42 GitHub171 joined #mojo
20:42 GitHub171 [mojo] kraih pushed 1 new commit to master: http://git.io/nRsHHw
20:42 GitHub171 [mojo/master] better Mojo::Log descriptions - Sebastian Riedel
20:42 GitHub171 left #mojo
20:43 sri tempire: so you think this api is perfect now? http://mojolicio.us/perldoc/Mojo/EventEmitter
20:44 tempire I don't know about perfect…but it's simple and easy to parse.
20:46 sri that's good enough for removing experimental i guess
20:47 tempire I haven't been using it though…you should get xantus opinion since he's been doing that ignite stuff.
20:47 sri it's mostly just about names
20:49 noganex_ joined #mojo
20:50 sri i think the big problem with explaining events is the many side effects
20:50 sri the concept itself is really simple
20:51 perlite joined #mojo
20:51 tempire side effects like blocking with sleep?
20:51 sri and weaken *shudder*
20:52 tempire I've heard you talking about it, but I don't quite understand the problem that the ref counting causes with events.
20:52 perlrocks Twitter: "Mojolicious 2.16 by SRI - http://t.co/WVf0gJq6" --cpan_new http://twitter.com/cpan_new​/status/130386587681951744
20:53 sri $req->content->on(body => sub { say $req->url });
20:53 sri tempire: you see the problem?
20:54 tempire the $req remaining in scope?
20:54 sri it's a circular reference
20:55 sri $req will never get garbage collected
20:55 tempire it would get collected if unsubscribe were called, though, wouldn't it?
21:00 tempire er, I guess that doesn't apply in a request.
21:01 sri that's true
21:01 sri it would get garbage collected then
21:02 tempire so it's not so much a problem as much as it's a "you gotta hold it right"
21:02 tempire but that's the standard ref counting vs gc thing anyway.
21:03 tempire I don't know.  doesn't seem so hard to me.  (knocks on wood)
21:03 sri so far that's what i got the most problem reports about
21:08 sri hmm
21:08 sri wonder if we could make it easier with a DESTROY method that unsubscribes all events
21:09 tempire sounds sensible
21:12 noganex joined #mojo
21:14 sri hmm
21:14 sri or events could be stored inside out
21:24 sri interesting
21:24 sri it leaks but then frees up lots of memory randomly
21:24 sri where it would just keep leaking without DESTROY
21:24 D4RK-PH0ENiX joined #mojo
21:36 chansen joined #mojo
21:43 sri really weird
21:43 sri same behavior with inside out storage
21:44 sri leaks up to 500mb and then frees 100 gains 100 frees 100….
21:50 tempire you can DO it!
21:50 * tempire cheers sri on with pom-poms
22:01 * sri shrugs
22:02 * sri goes to get chocolate ice cream
22:07 tempire sugar+fat causes heart disease.
22:09 chansen joined #mojo
22:15 sri tasty poison
22:18 elb0w joined #mojo
22:36 kvorg joined #mojo
22:40 kvorg Hi. Is there a RSS parser or aggregator or generator for mojo? Using DOM? Packaged as a plugin?
22:53 sherr joined #mojo
22:55 mspo I just made a template to generate it
22:59 xileph joined #mojo
23:01 kvorg Hm, i want to aggregate both rss and atom. Tempted to play it with Mojo::Dom. Will report.
23:03 mspo my atom doesn't validate yet ;)
23:30 tempire goodbye perlrocks

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