The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2015-12-14

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

All times shown according to UTC.

Time Nick Message
00:00 sri you want to commit it to master?
00:00 sri just remove those lines and the comment, and squish it all together without blank lines
00:00 jberger sure
00:00 jberger we don't need to remote the queue names?
00:01 sri nope
00:01 jberger ok
00:01 disputin joined #mojo
00:01 sri _finish calls _remove which calls _dequeue on the id
00:01 sri so the queues will just end up empty
00:02 sri this is nice
00:02 sri jberger++
00:03 sri there are tests for keep-alive queue clearing btw.
00:03 good_news_everyon joined #mojo
00:03 good_news_everyon [mojo] jberger pushed 1 new commit to master: http://git.io/v0W1t
00:03 good_news_everyon mojo/master 1038834 Joel Berger: remove some dead code
00:03 good_news_everyon left #mojo
00:04 sri they perform a request, keep the id from $tx->connection, clear the queue (change $$), and then perform another request to check $tx->connection again
00:05 good_news_everyon joined #mojo
00:05 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0W14
00:05 good_news_everyon mojo/master fa2ff9b Sebastian Riedel: not all connections are active
00:05 good_news_everyon left #mojo
00:06 sri here for example https://github.com/kraih/mojo/blob/master/t/mojo/user_agent.t#L384
00:08 jberger rebased against new master
00:08 good_news_everyon joined #mojo
00:08 good_news_everyon [mojo] jberger force-pushed channel_jberger_3 from 9d3a4ca to aa156dc: http://git.io/v0W16
00:08 good_news_everyon mojo/channel_jberger_3 13072dd Joel Berger: use a Channel class rather than bare hashref
00:08 good_news_everyon mojo/channel_jberger_3 97ee3d6 Joel Berger: further reduce use of private data
00:08 good_news_everyon mojo/channel_jberger_3 aa156dc Joel Berger: queue connections based on ioloop
00:08 good_news_everyon left #mojo
00:10 jberger next I think it might be possible to get rid of $nb all together
00:10 good_news_everyon joined #mojo
00:10 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0W15
00:10 good_news_everyon mojo/master 2330a02 Sebastian Riedel: more keep-alive tests
00:10 good_news_everyon left #mojo
00:11 sri \o/
00:11 saki o_O
00:17 sri i like how this is going, every time you get stuck, there's a clear flaw in Mojo::UserAgent
00:17 jberger hehe
00:23 jberger so the idea was to let _start take a loop as its first argument (rather than $nb)
00:23 jberger but there is the absoluting relative to the server's (nb_)?url
00:23 jberger :s
00:39 jberger I've almost got that even, but two keep alive tests fail when I do it
00:44 good_news_everyon joined #mojo
00:44 good_news_everyon [mojo] jberger force-pushed channel_jberger_3 from aa156dc to 5a5167c: http://git.io/v0W16
00:44 good_news_everyon mojo/channel_jberger_3 6b901e6 Joel Berger: use a Channel class rather than bare hashref
00:44 good_news_everyon mojo/channel_jberger_3 986317d Joel Berger: further reduce use of private data
00:44 good_news_everyon mojo/channel_jberger_3 4c15f3c Joel Berger: queue connections based on ioloop
00:44 good_news_everyon left #mojo
00:47 good_news_everyon joined #mojo
00:47 good_news_everyon [mojo] jberger pushed 1 new commit to channel_jberger_3: http://git.io/v0WHC
00:47 good_news_everyon mojo/channel_jberger_3 e25e02c Joel Berger: revert on unintentional change
00:47 good_news_everyon left #mojo
00:48 jberger sri: any idea why those tests fail with these changes?
01:00 jontaylor joined #mojo
01:05 nnutter joined #mojo
01:12 sri hmm, lets see
01:13 nnutter joined #mojo
01:13 sri jberger: looks like a new feature ;p
01:16 sri in those tests $ua->loop is equal to Mojo::IOLoop->singleton
01:16 sri "$ua = Mojo::UserAgent->new(ioloop => Mojo::IOLoop->singleton);"
01:19 sri at the very least i'll clean up those tests
01:24 good_news_everyon joined #mojo
01:24 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0WNc
01:24 good_news_everyon mojo/master 74b8a99 Sebastian Riedel: not all tests require the singleton
01:24 good_news_everyon left #mojo
01:24 sri this does not change anything yet
01:33 sri ah, right
01:33 sri now i see why we need the singleton
01:33 sri we test timeouts
01:34 sri $c->inactivity_timeout(...) only works if the ioloop the server uses is the singleton
01:34 sri and there's a few more calls like Mojo::IOLoop->stream(...), which require the singleton
01:35 sri ok, so $ua->ioloop(Mojo::IOLoop->singleton) is important for testing
01:35 sri jberger: i think at least one of the failing tests is one that expects a connection from a previous blocking request not to be reusable in a non-blocking followup request
01:36 sri which is a bit meh
01:45 good_news_everyon joined #mojo
01:45 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0WhR
01:45 good_news_everyon mojo/master 8ea4321 Sebastian Riedel: organize keep-alive tests a little better
01:45 good_news_everyon left #mojo
01:49 jberger joined #mojo
01:49 good_news_everyon joined #mojo
01:49 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0Wjg
01:49 good_news_everyon mojo/master 1151591 Sebastian Riedel: not all tests require the singleton
01:49 good_news_everyon left #mojo
01:50 jberger hmmm, little power troubles
01:51 jberger sri: nice, that fixes those tests
01:51 sri Oo
01:51 sri didn't even expect that, but hey, i'll take it
01:52 jberger pushing the rebased branch
01:52 good_news_everyon joined #mojo
01:52 good_news_everyon [mojo] jberger force-pushed channel_jberger_3 from e25e02c to 1ea18e9: http://git.io/v0W16
01:52 good_news_everyon mojo/channel_jberger_3 cf139a7 Joel Berger: use a Channel class rather than bare hashref
01:52 good_news_everyon mojo/channel_jberger_3 c61148b Joel Berger: further reduce use of private data
01:52 good_news_everyon mojo/channel_jberger_3 ba62434 Joel Berger: queue connections based on ioloop
01:52 good_news_everyon left #mojo
01:53 sri looks good
01:53 jberger my only question is should I weaken the $loop instance
01:53 jberger in the proxy callback
01:53 jberger https://github.com/kraih/mojo/compare/channel_jberger_3#diff-955b07afef3c0b8632a50118b370262cR128
01:55 sri that callback is stored in $ua, so i doubt it
01:55 jberger not for cycle prevention, just regular lifecycle protection
01:55 jberger should a loop instance be kept alive if there is a pending proxy connection?
01:56 jberger a rare case I expect
01:56 sri considering i don't understand the question, i doubt that too ;p
01:56 jberger ok
01:57 jberger hehe, no need for _loop anymore either :D
01:57 kafkaesque Anyone know why morbo would sometimes return a 403? 90% of the time it works, but 10% it returns 403 with the same URL as when it works.
01:57 sri \o/
01:57 kafkaesque I'm curious if it's just getting too many requests or something
01:58 good_news_everyon joined #mojo
01:58 good_news_everyon [mojo] jberger pushed 1 new commit to channel_jberger_3: http://git.io/v0leA
01:58 good_news_everyon mojo/channel_jberger_3 e7bebbb Joel Berger: remove unused _loop
01:58 good_news_everyon left #mojo
01:58 jberger kafkaesque: were you the person making the scraper?
01:58 kafkaesque jberger: yeah :)
01:58 jberger does it depend on that scraping?
01:59 kafkaesque yes, somewhat
01:59 jberger does it always work with fewer requests?
01:59 kafkaesque I mean, the scraper hits an API that returns a proxy, and it returns fast when testing from browser.
01:59 jberger oh, hmmm
01:59 kafkaesque yeah, but N::DNS::Native is installed
01:59 kafkaesque hm
02:00 kafkaesque let me test something
02:00 jberger well, I can't answer without seeing more code
02:00 kafkaesque it's not installed on the server
02:00 jberger also you might need to have lots of connections in the ua and lots of filehandles available through EV
02:00 jberger oh, well that might do it
02:02 sri looks like you've got the basics covered now, $c->{timeout} will be easy to move
02:03 sri i imagine start/stop methods in the Mojo::Channel base class
02:03 sri with an event maybe
02:03 sri $c->{cb} is a little odd
02:04 sri think you mentioned before that it might be reasonable to turn that into an event
02:05 sri and that's about it i guess, everything else is just moving transaction methods and user agent code into the channel :o
02:06 pink_mist bash will send {foo:bar} to curl, and that's not valid JSON
02:06 pink_mist err, I was scrolled up quite a bit :P
02:06 pink_mist so never mind that
02:06 Grinnz lol
02:07 good_news_everyon joined #mojo
02:07 good_news_everyon [mojo] jberger pushed 1 new commit to channel_jberger_3: http://git.io/v0lfo
02:07 good_news_everyon mojo/channel_jberger_3 c267384 Joel Berger: a little cleanup
02:07 good_news_everyon left #mojo
02:07 jberger sri: yeah, that's the next thing to think about
02:07 jberger start could just take a callback
02:08 jberger you'd only ever want to subscribe once
02:09 jberger the timeout callback is harder
02:14 jberger what should I do with the delete $c->{tx}?
02:15 jberger maybe there will be a reuse method in the Channel
02:23 harleypig joined #mojo
02:23 phillipadsmith joined #mojo
02:28 good_news_everyon joined #mojo
02:28 good_news_everyon [mojo] jberger deleted channel_jberger_2 at 186d949: http://git.io/v0lTh
02:28 good_news_everyon left #mojo
02:40 disputin joined #mojo
02:41 voldemortensen joined #mojo
02:45 sri jberger: $c->tx(undef)?
02:45 jberger hehe, yeah, that's true
02:45 jberger as before the problem is event propagations
03:03 inokenty-w joined #mojo
03:19 jberger sri: still there?
03:21 sri ye
03:22 jberger review please
03:22 good_news_everyon joined #mojo
03:22 good_news_everyon [mojo] jberger pushed 1 new commit to channel_jberger_3: http://git.io/v0l3A
03:22 good_news_everyon mojo/channel_jberger_3 8a6a0be Joel Berger: move _write to channel
03:22 good_news_everyon left #mojo
03:22 jberger my question will be is this going to make client_write hard to move
03:22 kaare joined #mojo
03:23 jberger because this might be websocket client_write sometimes, isn't it?
03:24 sri oh wow
03:24 sri big move
03:25 sri if anything it looks like client_write would be easier to move, since you don't even need to make it public
03:26 jberger but isn't it polymorphic?
03:26 sri passing the id to ->write seems not so nice though
03:27 jberger it's either that or the channel knows its id or its stream
03:27 jberger I'm ok with either
03:27 sri if you keep moving in that direction, i imagine just having an id attribute would be best
03:28 jberger is there another direction?
03:28 jberger (this is why I asked yesterday, it seemed clear this was what was coming)
03:28 sri i expected the actual io stuff to stay in Mojo::UserAgent
03:28 jberger oh
03:28 sri not that i doslike this direction
03:28 sri s/o/i/
03:29 sri actually i'm intrigued
03:29 jberger I'm still worried about delegating to the correct client_write/client_read
03:29 sri not sure why
03:30 sri perhaps you should add Mojo::Channel::WebSocket::Client too
03:30 sri to get a feel for it
03:30 jberger yeah
03:30 jberger probably
03:30 sri think i like this direction
03:31 noganex_ joined #mojo
03:32 sri but i need to see the ->read part too, to really get a feel for it
03:32 jberger argh! I hate indirect objects!
03:32 jberger http://www.cpantesters.org/cpan/report/62421225-6c02-1014-86f8-7f360b15b51d
03:32 jberger https://github.com/marcusramberg/Mojolicious-Plugin-MountPSGI/blob/master/t/script/path.psgi#L4
03:33 jberger no I'm not trying to call {}->Mojo::JSON::encode_json!!!
03:33 sri :)
03:34 sri so, the current ->write method would move to Mojo::Channel?
03:35 sri and you'd need a new name for client_write
03:35 jberger _write
03:35 sri i guess ->write is not a great name anyway
03:35 sri it's more like ->resume
03:36 jberger you know I don't mind if you want to take a hack
03:36 sri i don't like private methods as an api, even across subclasses
03:36 jberger you can always branch from my branch
03:36 jberger oh, you are imaging that ::WebSocket::Client is a subclass of ::HTTP
03:37 sri no
03:37 jberger I guess we did discuss that
03:37 jberger oh, then I'm really confused
03:37 sri i was expecting Mojo::Channel::_write as an abstract method
03:37 sri which Mojo::Channel::write depends on
03:38 sri and Mojo::Channel::HTTP::Client::_write would be the replacement for client_write
03:38 sri i don't like that
03:38 jberger ah
03:38 sri that's what i thought you meant
03:38 jberger yeah, I see the concern then
03:39 kafkaesque joined #mojo
03:39 kafkaesque ok, so I got one thing working, one last thing to fix and then this should be working. how do I view what IP my $ua request was sent from?
03:39 kafkaesque it's not in req headers, so not sure if there's some way to get that information
03:43 jberger kafkaesque: http://mojolicio.us/perldoc/Mojo/Transaction#remote_address
03:43 kafkaesque ok, nothing, figured it out
03:44 kafkaesque :)
03:44 kafkaesque thanks jberger
03:44 jberger yeah, I'm not sure that's right anyway
03:44 kafkaesque yeah, it is
03:44 kafkaesque well, it's working for me anyway
03:51 nnutter joined #mojo
03:57 sri jberger: i feel like i would just do damage to your branch
03:58 sri in fact, i'm very curious where you'll be heading next :)
03:59 sri but i'll be here to answer questions and clean up stuff in master that doesn't make sense
04:05 jberger hunh
04:05 jberger a similar move of _read seems to fail badly
04:05 jberger I can't figure out what is different
04:05 sri had a hunch that it would be tricky
04:06 jberger that's interesting, what gave you that suspician
04:06 jberger ?
04:07 sri because a handle becoming readable happens on errors and stuff
04:07 sri there's more stuff happening
04:08 jberger ah
04:08 sri _finish and _remove interactions
04:09 sri although, looking at it now... it doesn't seem so bad
04:10 Zoffix joined #mojo
04:12 jberger sri: http://pastie.org/10631562
04:12 jberger I suspect that something is going wrong with the finished event
04:13 jberger (seeing as its basically the only thing that actually changes)
04:13 sri was about to ask if you subscribed to it
04:13 jberger from the previous commit
04:13 sri maybe you subscribed to late
04:13 jberger hmmmm
04:20 jberger ok I got it
04:20 jberger now to clean up all the thing I tried
04:20 jberger :-P
04:28 jberger of course this doesn't completely move _read
04:29 jberger because there is the corruption handling
04:29 jberger it'd be nice if that could move too
04:33 jberger sri: when does tx go away in a way that gets caught here: https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L256
04:33 jberger ?
04:34 jberger hmmmm, it passes without that line
04:34 sri hard to test, i imagine in between requests
04:35 sri like, the server writes something you did not expect
04:36 sri you need bad timing for that
04:36 jberger but something would have to actually remove the tx object
04:36 jberger I don't see anything doing that
04:37 sri first request is finished, connection goes into the queue, you perform another request on a different connection, and while you wait for that response, the old server decides to write some garbage to the queued connection
04:37 sri _reuse does
04:37 jberger true
04:37 jberger that didn't seem related
04:38 sri it is
04:38 jberger oh
04:38 jberger I understand
04:38 jberger that can move into the channel though
04:38 jberger which completes the move
04:39 sri i think these lines in _read and _write don't serve a purpose anymore though https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L255
04:39 sri umm, i mean the return
04:39 sri the lines still do something :)
04:39 jberger sure
04:40 jberger those go away on their own
04:45 jberger so the question is, is it better for that _remove to happen in the same way or should the channel emit an unexpected event
04:47 sri or an error event?
04:48 sri sucks that it would be untested though
04:48 voldemortensen joined #mojo
04:48 jberger I can leave it where it is
04:48 jberger its the user agent that has to clean up when that happens
04:49 sri might be better for now
04:54 jberger still have this client_read to deal with: https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L241
04:54 sri that's for websockets though
04:55 jberger oh I suppose it is
04:55 sri in case a server sends the first websocket frame with the handshake response
04:55 sri the frame ends up in the leftovers buffer
04:56 sri so we pass it along to the websocket transaction
04:56 jberger where would the new Mojo::Channel::WebSocket::Client->new happen?
04:56 sri https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L237
04:56 sri somewhere around there
04:56 sri that's the transaction upgrade
04:57 jberger so that will be the first real difference
04:58 sri $new is a Mojo::Transaction::WebSocket
04:58 jberger and that's why I don't have to work about polymorphism with client_read
05:01 jberger last question for the night I think
05:01 jberger why doesn't this line have $self &&
05:01 jberger https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L114
05:02 jberger sri ^^
05:03 sri because it never caused problems :)
05:03 jberger ah
05:05 good_news_everyon joined #mojo
05:05 good_news_everyon [mojo] jberger pushed 1 new commit to channel_jberger_3: http://git.io/v0lg7
05:05 good_news_everyon mojo/channel_jberger_3 ee08396 Joel Berger: move (most of) _read to channel
05:05 good_news_everyon left #mojo
05:05 jberger still plenty to go
05:07 jberger and a little bit of me is starting to consider your original pov where the io didn't go in the channel
05:13 jberger anyway, I'm off to bed
05:13 jberger nn
05:36 melo joined #mojo
06:03 sri nn
06:19 kafkaesque exit
07:27 dod joined #mojo
07:29 McA joined #mojo
07:32 dod joined #mojo
08:03 osfabibisi joined #mojo
08:10 CandyAngel joined #mojo
08:10 esh joined #mojo
08:11 Vandal joined #mojo
08:15 eseyman joined #mojo
08:18 Lee joined #mojo
08:19 vytas joined #mojo
08:19 trone joined #mojo
08:22 AndrewIsh joined #mojo
08:31 bpmedley joined #mojo
09:01 berov joined #mojo
09:01 odc joined #mojo
09:13 vanHoesel joined #mojo
09:34 jontaylor joined #mojo
09:49 henq joined #mojo
09:50 meshl joined #mojo
10:24 Lee joined #mojo
10:25 melo joined #mojo
10:40 henq joined #mojo
11:50 mishantil joined #mojo
11:56 mishanti1 joined #mojo
12:07 hernan605 joined #mojo
12:08 Lee joined #mojo
12:43 Lee_ joined #mojo
12:46 McA joined #mojo
13:07 plicease joined #mojo
13:32 marty joined #mojo
13:44 meshl joined #mojo
13:53 kaare joined #mojo
14:35 vanHoesel joined #mojo
14:59 PopeFelix joined #mojo
15:03 ZoffixW joined #mojo
15:04 ZoffixW sri, what are your thoughts on me stealing all of Mojo::DOM, Mojo::DOM::HTML, and Mojo::DOM::CSS and basically changing the code just enough so it runs on Perl 6?
15:04 ZoffixW I wouldn't use the Mojo name in the port.
15:05 voldemortensen joined #mojo
15:05 ZoffixW I'd gladly write my own thing, but I'm not smart enough and I'm thoroughly annoyed that P6 doesn't have a decent HTML parser :(
15:06 pink_mist I thought he wanted an official port to p6 0_o so if you did that ... well, discuss with sri :P
15:06 pink_mist he might have changed his mind since then
15:08 Lee_ joined #mojo
15:08 ZoffixW pink_mist, official port of what? The parser or entire Mojolicious?
15:08 pink_mist entire Mojo
15:08 ZoffixW That's no longer an attractive option to sri, from what I understand.
15:08 pink_mist or at least the parts that are actually relevant for p6
15:08 ZoffixW 'cause P6 is pretty slow.
15:08 * ashimema thinks that would actually temp him to learn perl6
15:09 ZoffixW Last conversation I recall is sri saying they don't care if someone ports Mojo to P6 as long as the name is not used...
15:09 ZoffixW Well, that and the snail logo :P
15:09 asarch joined #mojo
15:21 genio ZoffixW: https://metacpan.org/pod/DOM::Tiny already exists.  You could P6-ify that possibly with some help from Grinnz
15:22 ZoffixW Ah, right, I forgot about that one :)
15:22 ZoffixW Grinnz, what are your thoughts on me stealing all of DOM::Tiny and basically changing the code just enough so it runs on Perl 6? XD
15:27 Grinnz it's essentially Mojo::DOM's code, just adapted to run on 5.8 and with the entities stuff extracted from Mojo::Util; you'd be better off going from the source probably
15:28 ZoffixW "going from the source"? What do you mean? Mojo::DOM's source?
15:28 Grinnz yes
15:28 * genio is saddened that 5.8 is still needing to be considered
15:29 ZoffixW k, gonna wait to see if sri would mind...
15:31 tyldis joined #mojo
15:45 ZoffixW And it would involve stealing the test too: https://metacpan.org/source/SRI/Mojolicious-6.36/t/mojo/dom.t
15:56 * jberger doesn't consider 5.8
15:57 * ZoffixW doesn't consider <5.14
15:58 ZoffixW Well, I guess it's not totally true. Depends on how annoyed I am to pass up s///r :)
15:59 jberger for a while I had a module that required 5.16
15:59 jberger I guess I still have it but the service it talks to is defunct
15:59 jberger <3 __SUB__
16:01 sri ZoffixW: after all the recent trouble with hostile forks, i'm hesitant to give my ok to a port
16:02 ZoffixW sri, but mine isn't hostile but fuzzy and all :P  What were the troubles? I recall one is bug reports not propagating to Mojolicious, which in my case would definitely happen, since I use Mojolicious in production. What were the other ones?
16:03 ZoffixW *would definitely NOT happen
16:04 genio Probably not best to re-hash the drama in the channel.  :)
16:04 ZoffixW Drama?
16:04 sri a certain individual has also used my ambiguous reactions to hostile forks to attack me a few times now
16:05 genio if he says there was trouble, that likely involves drama, no?  asking him to expand on it invites
16:05 sri so, in the future i think anyone who maintains one, will have to leave the community
16:05 ZoffixW :(
16:05 ZoffixW Yeah, but my fork is in a different language...
16:06 sri yea, that makes it a little different
16:06 sri problem is that an official perl6 port is still in the cards
16:06 sri at which point we would be competing
16:07 sri so, i don't know what to do, and i don't want to repeat past mistakes :S
16:09 genio Porting all of Mojo to P6 is likely a huge effort.  If someone were to work on smaller bits of Mojo on P6 and have you included so that it could be folded into the full project at a later time, would that be more acceptable?
16:10 ZoffixW My motivation for the port is to have a Mojo::DOM available in P6. I don't care who makes it. So if a port surfaces, I'll gladly toss my own version—less things to maintain. Of course, that leaves broken code if my module's name is not Mojo::DOM or the API of yourported Mojo::DOM doesn't match.... And of course, I have nothing but my words to offer for any guarantees that this is what happens and not whatever issues you had with othe
16:10 ZoffixW r forks.
16:10 genio meh, that probably invites a whole host of potential problems.  nevermind.  Don't listen to me
16:10 ZoffixW At the moment, there's no working HTML parser in P6.
16:11 ZoffixW The one that exists is slow as molases, has confusing API, and currently is broken because one of the modules it depends on is broken and its author is awol.
16:11 genio Is there no XML::LibXML yet?
16:12 sri marcus, jberger, crab, tempire, batman: what are your thoughts on the situation?
16:12 ZoffixW I only see XML::Parser::Tiny, which seems to be the P6 version of XML::Simple
16:14 jberger sri: personally, I think if ZoffixW wants to start a Mojo port by starting to port portions, with the intent to merge if a port surfaces, I'm ok with that
16:15 jberger just like a book, I think success of a volunteer project of that size is going to have a better chance of success with lots of hands
16:15 sri that seems reasonable
16:15 ZoffixW Yes, that would be my intent. And if my code is unacceptable for merging, I'll gladly toss it if a better alternative exists.
16:16 ZoffixW Where "better" is judged by the Mojo core team.
16:16 genio Some considerations would need to be taken first with regard to structure.  If Mojo::DOM is created, does that not first mean that Mojo::Base and likele Mojo::Collection need to be considered?
16:16 Grinnz you can use perl6 builtins for both of those i believe
16:16 genio *likely
16:16 sri genio: those parts are native in perl6
16:17 sri even the event loop is native
16:17 sri you only need to port higher level stuff
16:17 genio ahh, nice.
16:18 jberger that's why a direct port isn't really desirable
16:18 jberger P6 has a lot of what Mojo does for P5
16:19 ZoffixW Indeed.
16:19 sri Zoffix: looks like you have our blessing with that premise
16:19 genio Last I checked, method chaining required some forethought. hrm
16:19 sri not even sure if i would try to convert Mojo::DOM::HTML to grammars
16:19 sri since grammars are so horribly slow
16:20 ZoffixW Yes, they are.
16:20 sri genio: not sure if i would use chaining
16:20 sri that would require experiments
16:21 genio sri: :( that's one of the nice/great things about Mojo to me.
16:21 * sri would start with trying to use idiomatic perl6
16:21 ZoffixW sri, alright, thanks. What about the name of the module? Should I go with Mojo::DOM so it could silently be replaced with Mojolicious version should a port surface or pick something else?
16:22 sri think a different name would be better
16:22 ZoffixW OK. I'll start working on this then and will share the URL to the repo in here, once I have something ready.
16:23 sri i'm curious about performance
16:24 hernan606 joined #mojo
16:34 sri genio: i guess chaining with methods will be fine, but attributes are tricky
16:35 sri since you're using "$foo.bar = 'baz'" to assign values
16:35 melo joined #mojo
16:36 sri a lot of the chaining in mojolicious is actually attribute accessors
16:37 genio yea, there was something on that fluent interface wiki doc that showed a sample of how it might be done...   https://en.wikipedia.org/w/index.php?title=Fluent_interface&amp;oldid=681159116#Perl_6
16:37 Grinnz i believe that syntax doesn't require \ anymore
16:38 genio They updated the example later to get rid of that for the "Perl 6" way, but I prefer the method chaining to the Perl 6 way
16:38 ZoffixW Right, "\" are not needed anymore
16:38 ZoffixW wait..
16:39 ZoffixW Most recent version uses given :/ meh.
16:39 genio right, which is the P6 way I was referring to that I find... eww
16:39 Grinnz the given form is decidedly not fluent
16:39 ZoffixW I wouldn't even call that fluent interface. It's just assigning the object to a topicalizer to avoid adding it before each method call.
16:40 sri the given form looks awful
16:40 genio but adding the chainable mutators like the older version does requires some voodoo that would need to exist in a Mojo::Base type of container
16:41 genio which leads me back down the road of looking at the structure first
16:42 sri not sure which one i would pick
16:42 meredith I just took a look at someone's old ASP / VBScript code that uses With(), I guess it was ahead of its time on fluent interfaces :)
16:43 sri on the one hand i'd want to try perl6 idioms, on the other, i love chaining
16:43 genio heh
16:44 Grinnz if nothing else, since the object system is builtin, you can just add a package to use for applying the property to attributes later
16:44 gryphon joined #mojo
16:44 Grinnz no need to use it as a base class
16:45 sri do you make a role with a trait?
16:45 * sri doesn't know how that works yet
16:45 Grinnz it looks like the example from that older version of the wiki page does something like that
16:46 genio right "a new attribute trait to define an attribute as both read/write and returning the invocant"
16:48 sri jberger: have you thought about backporting the queue stuff from Mojo::UserAgent to master?
16:49 jberger I hadn't
16:49 orev joined #mojo
16:49 jberger though it would just be a matter of replacing $nb with $loop in the hash and making the same changes
16:50 jberger like it that much, do you?
16:50 sri yea, i see some of it depends on $c->ioloop
16:50 jabberwok joined #mojo
16:50 jberger sure but that could just be $c->{loop}
16:50 sri well, i never liked nb_queue ;p
16:50 sri lets say it that way
16:51 jberger nothing I did last night until those moves of _read and _write to the channel would be impossible to backport
16:51 sri $c->{ioloop} would actually be interesting for a performance test
16:52 jberger of course that would be the third time I had written most of that code :-P
16:52 jberger first came before the master refactor of keep alive
16:54 hernan605 joined #mojo
17:00 lluad joined #mojo
17:05 sri jberger: i'm trying a backport for performance testing
17:08 sri well, that was easy, worked first try
17:08 sri https://gist.github.com/anonymous/c608fc0a662edfa1a321
17:08 sri no measurable difference for a simple one-liner
17:09 sri perl -Ilib -Mojo -E 'n { g("/") } 1000'
17:09 sri went with this for a simple keep-alive test
17:11 sri this might be better though
17:11 sri perl -Ilib -Mojo -E 'any("/" => {text => "Hello World!"}); n { g("/") } 1000'
17:12 jberger sri: cool
17:14 sri for the record, i also never liked $nb or _loop
17:14 jberger it was clearly low hanging fruit as I read through it
17:15 vanHoesel joined #mojo
17:15 jberger extra metadata that just obscured the real purpose
17:15 sri yea
17:16 sri if i committed that to master would it make your life much harder?
17:17 sri (on the plus side, resulting leaks would become my problem ;p)
17:19 jberger hahaha
17:19 jberger it wouldn't be much harder no
17:19 sri doesn't look like anything leaks though
17:20 jberger the only thing I did differently was then once I got to that part I started passing around the $c rather than the loop and the tx
17:21 jberger s/part/point/
17:22 sri yea, i noticed, wanted to keep things concistent for now
17:22 sri it seemed unfinished
17:23 jberger what seems unfinished?
17:23 sri the passing around $c part
17:23 jberger k
17:23 jberger then sure, go ahead and commit it
17:24 jberger just don't then look through the commit log and think I haven't committed in a while :-P
17:25 sri you committed yesterday
17:25 jberger oh right
17:25 * jberger is losing his mind
17:26 good_news_everyon joined #mojo
17:26 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0R1y
17:26 good_news_everyon mojo/master 55d299b Sebastian Riedel: backport some of jberger's refactoring work
17:26 good_news_everyon left #mojo
17:27 jberger that does look nicer
17:27 sri indeed
17:27 sri jberger++
17:28 jberger incremental progress
17:28 sri another good thing, we get to test for other side effects of the queue change much earlier
17:29 jberger oh?
17:29 sri i have a hunch that maybe Mojo::UserAgent::Server could cause some problems
17:30 sri not very likely, just a feeling
17:30 sri it's a bit quirky
17:37 jontaylor joined #mojo
17:42 sri that new syfy mini-series starting today sounds pretty cool
17:42 sri childhood's end
17:43 sri it's almost like syfy is really trying again
17:44 sri first episode of the expanse was also pretty good
18:06 jberger did you watch the promo for the new independence day
18:06 jberger ?
18:06 pink_mist agreed, was surprised at how good expanse was for being a syfy show
18:07 pink_mist at least ep 1
18:10 sri jberger: yea, looked fun
18:10 sri new star trek trailer is out too, kirk is crashing yet another ship xD
18:11 jberger :o
18:11 jberger haven't seen that yet
18:12 jberger trek doesn't know what to do if they aren't crashing ships
18:12 jberger lately
18:12 jberger meaning since generations
18:16 sh4 joined #mojo
18:32 meshl joined #mojo
18:37 noganex joined #mojo
18:41 sri jberger: thought about what you want to do with the callback?
18:42 jberger does it just become the callback to a start method?
18:42 sri hmm
18:42 jberger I think most uses of an event would be as "once"
18:43 sri we also have plain callback attributes
18:43 sri like Mojo::UserAgent::CookieJar::ignore
18:44 jberger the interesting thing for an event is that it might come from multiple places
18:44 jberger like for after a connection is established or after it is reused
18:45 jberger but I guess both would get started with a start call anyway
18:45 neilhwatson joined #mojo
18:47 sri looking through the code, it is quite entangled
18:47 sri from _connect_proxy to _finish
18:47 sri with special cases like failed proxy connection
18:50 jberger yeah
18:50 jberger its wasn't clear to me either
18:50 trone joined #mojo
18:50 jberger I was going to try to disentangle it once I moved some quick wins to the class
18:51 sri feels like it belongs more to the user agent than the channel
18:51 jberger who does the logic of making a connection belong to?
18:52 sri user agent i think, because of _proxy_connect
18:53 sri and stuff like tls/socks
18:55 sri i still see the user agent as the glue between connection management and protocols
18:55 sri maybe i'm wrong though
18:56 sri i guess if the channel could do more, it might be a good idea to let it
18:57 sri perhaps the user agent should only be a container for config stuff and manage a pool of channels
18:57 sri that's a bit more node.js-ish
18:59 sri https://nodejs.org/api/http.html
19:00 meshl joined #mojo
19:01 sri jberger: actually, if you think you can put more logic into the channel, just go for it
19:01 sri it would be cleaner in the end
19:02 sri the user agent is for stuff that deals with a pool of channels, and channels are for managing a single connection
19:04 sri although, i think i would try to keep io code together
19:05 jberger which is why I was moving the _read/_write over, since we knew we wanted to move client_read/client_write over
19:05 sri i think the only tricky part here is _proxy_connect actually
19:06 sri establishing a connection is not really io, but establishing a connection with CONNECT requires io
19:07 sri i'm overthinking it
19:07 sri _connect and _proxy_connect will definitely stay in Mojo::UserAgent, it's connection management
19:08 sri the channel gets attached to the stream events
19:09 sri _connect is where the user agent glues together the stream and channels
19:12 sri sooo, yea, think i agree that it's ok to move _read/_write
19:13 sri although
19:13 sri maybe the channel should not know the connection id
19:13 jberger you could just move the client_ methods to the channel and leave the rest alone
19:13 sri or maybe it should, hmm, i don't know :)
19:14 jberger its a tough call
19:14 sri the channel already knows about the ioloop, so letting it call $self->ioloop->stream(...)->write(...) itself is not that crazy
19:15 sri _read is easier, since there's no direct interaction with the ioloop
19:15 sri _write calling ->stream(..)->write(...) feels a little like stepping over a boundary
19:16 * jberger thinks he broke sri
19:16 kyshtynbai joined #mojo
19:16 * jberger calls a technician
19:16 jberger marcus: we need more beer!
19:17 sri ☠️
19:19 jberger 😱
19:29 mtj joined #mojo
19:39 PryMar56 joined #mojo
20:20 voldemortensen1 joined #mojo
20:28 sue joined #mojo
20:29 voldemortensen joined #mojo
20:31 tyldis joined #mojo
20:34 bwf joined #mojo
20:36 tyldis joined #mojo
20:54 sri jberger: have you thought about replacing ioloop with the stream?
20:54 jberger the actual stream object?
20:54 sri ye
20:54 jberger I thought about attaching the stream object to the channel
20:54 jberger but doesn't it make sense to queue by loop?
20:55 sri $stream->reactor works too
21:01 sue joined #mojo
21:02 jberger if you made a new loop instance with the same reactor instance, those don't block each other do they?
21:02 mrEriksson joined #mojo
21:02 jberger (I mean, its a punchable offense, but I'm still curious)
21:03 sri don't think so
21:04 human39 joined #mojo
21:15 sri ok, it doesn't work
21:15 sri we need the {connections} structure before the connection has been established
21:16 jberger ah
21:16 jberger yeah
21:17 sri we do have the id from $loop->client(...) but the stream only exists once the client callback has been called
21:18 * jberger nods
21:19 jberger if the channel were to build the connection itself it could store its own channel object in that callback and then emit a "connected" callback which the useragent could use to do its thing
21:19 jberger but that starts to get convoluted
21:19 jberger I thought about a lot of that
21:19 jberger we are in the belly of emit-hell
21:20 sri and i've thought about the queue changes again, they were really good :)
21:20 jberger \o/
21:21 sri keeping the connections structure for queued connections is very good for http/2, since an http/2 channel could always be in the queue because it can handle more multiplexed requests
21:22 sri so, the basic idea is very future proof
21:22 anon joined #mojo
21:22 marty_ joined #mojo
21:22 gryphon_ joined #mojo
21:23 sri and the channel persists between requests, that's all very good
21:36 disputin joined #mojo
21:48 jberger yay, joomla 0day
21:48 jberger https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html
22:01 * sri starts trying to clean up Mojo::Server::Daemon for jberger
22:02 sri it's mostly super easy... there's just one small quirk
22:03 sri $c->{tx} and $c->{ws} can coexist for a short time
22:11 Zoffix joined #mojo
22:12 Zoffix I started the repo for the P6 Mojo::DOM port (nothing there yet but the tests half-ported): https://github.com/zoffixznet/perl6-DOM-Parser#author
22:13 * Zoffix points at the AUTHOR section
22:27 good_news_everyon joined #mojo
22:27 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0EbF
22:27 good_news_everyon mojo/master e78c4ad Sebastian Riedel: test IPv6 and TLS together
22:27 good_news_everyon left #mojo
22:28 meshl joined #mojo
22:32 sri i guess the http and websocket channels will have to coexist for a time
22:32 sri problem is that we create the websocket transaction once the http request has arrived, but we still need to send the http response afterwards
22:33 sri well, actually, the websocket transaction needs to exist earlier, nto the channel
22:33 sri hmm
22:35 sri Zoffix: looks good
22:35 Zoffix \o/
22:39 jberger the 0day in joomla is pretty insane
22:39 jberger http://arstechnica.com/security/2015/12/hackers-actively-exploit-critical-vulnerability-in-sites-running-joomla/?comments=1&amp;post=30291415
22:40 sri rofl
22:40 jberger code injection via the user agent string, which is fed into the session without validation (odd, but meh) but then php inflates that to an object on reading it back out of the db
22:40 jberger lol php wat?!
22:41 CandyAngel Seems legit
22:42 jberger sri: when do you think we can get the subprotocol negotiation released?
22:43 jberger demoed the novnc stuff at $work today, had to do it in firefox
22:44 sri well, if you need it later today i guess
22:44 * sri is impatiently waiting for more jberger refactorings :)
22:44 jberger its no hurry, this isn't even a production piece of software (yet)
22:44 jberger refactoring gets slower during the week
22:46 jberger currently, novnc is done by fork/exec-ing websockify (a python websocket/tcp bridge)
22:46 jberger this replaces that with like 6 lines of mojo code
22:47 jberger honestly its so little code its not worth writing a Mojo::Websockify
22:48 jberger though I still am thinking about releasing a Mojo::NoVNC which has both that bridge and the novnc js code (and a simple template)
22:48 jberger the js code is unfortunately untidy
22:49 jberger which is where my hesitation comes from
22:50 CandyAngel I really wish I could just steal^Wcopy the skillbase in this channel :P
22:54 sri http://justinpwnsnoobs.weebly.com/uploads/6/5/6/2/6562945/282935944.jpg
22:54 jberger http://memesvault.com/wp-content/uploads/I-Have-No-Idea-What-Im-Doing-Dog-04.jpg
22:58 voldemortensen joined #mojo
23:52 punter joined #mojo

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