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

IRC log for #mojo, 2016-01-10

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

All times shown according to UTC.

Time Nick Message
00:00 sri jberger++
00:00 good_news_everyon joined #mojo
00:00 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuF2q
00:00 good_news_everyon mojo/channels/master 1d4cb41 Sebastian Riedel: better descriptions for a few methods
00:00 good_news_everyon left #mojo
00:00 sri that was a very productive day
00:02 jberger think about how we want to address the member data and events
00:02 jberger {state} is going to be the hardest probably
00:02 sri i think the hardest part is behind us
00:02 jberger I think likely we can move a lot of the others into the channel with appropriate resetting
00:02 sri but it's a little tricky
00:04 jberger I'm gonna step away for a bit
00:05 jberger might peek at it a little bit later
00:05 sri laters
00:05 jberger and more tomorrow?
00:05 sri sure
00:05 sri i'll have to think about {state} for a bit too
00:05 jberger \o/
00:33 asarch joined #mojo
01:00 jontaylor joined #mojo
01:35 lsm joined #mojo
01:58 good_news_everyon joined #mojo
01:58 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuFdB
01:58 good_news_everyon mojo/channels/master ca51074 Sebastian Riedel: no need for a prefix
01:58 good_news_everyon left #mojo
02:06 cpan_mojo Statocles-0.066 by PREACTION https://metacpan.org/release/PREACTION/Statocles-0.066
02:07 good_news_everyon joined #mojo
02:07 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuFbv
02:07 good_news_everyon mojo/channels/master 28b02d2 Sebastian Riedel: add is_closing method to Mojo::Transaction::WebSocket
02:07 good_news_everyon left #mojo
02:07 sri one down ;p
02:14 good_news_everyon joined #mojo
02:14 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuFbp
02:14 good_news_everyon mojo/channels/master c17cda5 Sebastian Riedel: transactions are always reading
02:14 good_news_everyon left #mojo
02:32 good_news_everyon joined #mojo
02:32 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuFjW
02:32 good_news_everyon mojo/channels/master 065861e Sebastian Riedel: no need to check the state as often
02:32 good_news_everyon left #mojo
02:34 sri i think we might need two kinds of finished states for transactions
02:34 sri one that says the transaction is done generating stuff, and one that signals all the generated stuff has actually been written to the connection
02:35 sri to get rid of {state}
02:49 good_news_everyon joined #mojo
02:49 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vubv2
02:49 good_news_everyon mojo/channels/master 8e54539 Sebastian Riedel: add frame method to Mojo::Transaction::WebSocket
02:49 good_news_everyon left #mojo
03:36 kaare joined #mojo
03:43 good_news_everyon joined #mojo
03:43 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vubIR
03:43 good_news_everyon mojo/channels/master 7ea4766 Sebastian Riedel: remove extra newline
03:43 good_news_everyon left #mojo
03:59 noganex joined #mojo
04:15 sri https://gist.github.com/anonymous/59caa04092e502378b65
04:15 sri something like that might be a reasonable intermediate step for removing {state} from the transaction
04:29 c--__ joined #mojo
04:36 sri maybe not
05:27 good_news_everyon joined #mojo
05:27 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vub6m
05:27 good_news_everyon mojo/channels/master ad4fecd Sebastian Riedel: slightly better method names
05:27 good_news_everyon left #mojo
05:27 sri closed was not very good, its purpose is really to let the transaction know that everything has been written to the underlying socket
05:28 sri anyway, we can't keep the state machine in Mojo::Transaction
05:29 sri it has to go into Mojo::Channel
05:29 sri Mojo::Transaction can know if it is finished or not i think, but not if it is reading or writing
05:36 sh4 joined #mojo
06:28 Vandal joined #mojo
07:29 dod joined #mojo
07:29 alexbyk joined #mojo
07:34 dod joined #mojo
07:37 alexbyk joined #mojo
07:39 alexbyk_ joined #mojo
08:17 sugar__ joined #mojo
08:55 batman sri, jberger: i made some comments for channels/master: https://gist.github.com/jhthorsen/f3599b1a167f91f4ad32
10:47 abra joined #mojo
11:06 punter joined #mojo
13:13 bpmedley https://github.com/brianmed/patches <-- I've updated my Patches.pl app so that it can support Querying, Updating, and Rebooting remote hosts from one manager.
13:19 t4nk149 joined #mojo
13:27 t4nk200 joined #mojo
13:39 binlei joined #mojo
14:26 sri batman: i'm afraid that patch doesn't work, each websocket connection requires its own copression context
14:26 sri +m
14:27 sri if all tests still pass, we need better tests
14:28 sri there is just no way you can extract inflate/deflate into functions
14:29 sri batman: "is_server {undef}" is a convention we use all over mojolicious
14:30 sri batman: "Mojo::Channel::HTTP::close" not taking an argument while "Mojo::Channel::HTTP::Client::close" does is actually a convention we already use
14:31 sri batman: "$tx->{$_} ||= 0 for qw(offset write);" can't go into Mojo::Transaction, because we want to remove all state from the transaction, so all uses of "$tx->{...}" will have to become $self->{...} in the channel classes
14:32 sri batman: what is "\%args"?
14:34 sri the biggest problem right now is $tx->{...} all over the channel classes
14:34 sri and specifically $tx->{state}
14:44 marty joined #mojo
14:59 batman sri: thanks for looking at my comments :)
14:59 batman yeah. as mentioned in the gist, the tests fail when i try to extract inflate/deflate :-)
14:59 batman sri++
15:00 batman i like 0/1 for "booleans" instead of undef/1, but consistency is most important
15:01 batman so "like" == ignore my comment ;)
15:02 batman %args: Mojo::WebSocket::build_frame({masked => 1}, ....) instead of build_frame(1, ...);
15:02 sri btw. i renamed Mojo::Transaction::closed to delivered
15:02 batman yeah. looks great (delivered)
15:03 sri batman: there should be no need for a %args, frame building has not changed in years
15:03 batman ok. cool.
15:03 sri we should really focus on $tx->{...} stuff
15:03 batman guess jberger should be here any moment now...
15:04 sri and i'm a little out of ideas what to do about it :/
15:04 batman shout if i can do more "move code from here to there" tasks.
15:04 sri $tx->{state} is really tricky, it is used from almost every channel class, and transaction class
15:04 sri grunt work is mostly over i think, now we need clever ideas
15:05 batman ok
15:06 batman ah! one last thing: why keep Mojo::Channel around?
15:06 batman (it's empty now)
15:07 sri will it stay empty?
15:08 sri i don't think so!
15:08 batman ok.
15:08 sri at the very least there will be a tx accessor
15:08 batman i don't think i can come up with clever ideas... i don't see the big picture :/
15:08 batman but i'll stick around and see if i can pick up a thing or two
15:09 sri think i might backport Mojo::WebSocket to master later, if we don't find a way to get rid of $tx->{state}
15:09 sri and a few other changes
15:09 batman right. let me know if you want me to do that (so you can focus on more important things)
15:09 batman that = move M::WS to master
15:10 sri well, if you want to do that, sure, go ahead :)
15:11 batman but... won't that result in a breaking change?
15:11 batman ...which require a major version bump?
15:11 sri deprecate the stuff that is tested
15:12 sri i think the _challenge and _handshake methods have no tests
15:12 batman ok... i'll give it a try.
15:13 batman pretty sure i will mess up, but if i do the "dumb" stuff first, you can probably (very easy) clean up the rest...
15:13 sri sure
15:17 batman *brb*
15:18 good_news_everyon joined #mojo
15:18 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vuAaN
15:18 good_news_everyon mojo/master 78d2ecd Sebastian Riedel: use a little less code
15:18 good_news_everyon left #mojo
15:20 binlei joined #mojo
15:25 good_news_everyon joined #mojo
15:25 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vuAwl
15:25 good_news_everyon mojo/master 0e3af25 Sebastian Riedel: there is no need to modify the handshake
15:25 good_news_everyon left #mojo
15:25 sri i know, that makes merging channels/master harder later on, but it's not like we can keep master frozen until 7.0 anyway
15:33 sri batman: i don't know how horrible the deprecations will end up looking, i think that will decide if we backport or not
15:34 jberger hi, I slept longer than I expected
15:34 jberger reading back
15:36 batman sri: makes sense. i'll make a new branch soon-ish...
15:37 batman hi jberger :)
15:41 jberger batman: o/
15:42 sri \o
15:42 jberger sri: since we know {state} is going to be hard, should we try to work on the parser state ones?
15:42 jberger the ones that I was having trouble resetting yesterday?
15:43 sri those seem trivial
15:43 sri all you really need is a method to call when a new transaction gets assigned
15:43 jberger so lets knock em out
15:44 sri i want to find a solution for the hard problem :S
15:45 sri actually, i have a feeling we might have already waited too long with trying to fix it
15:45 sri looking at master, it's much easier to untangle the state there
15:46 sri splitting up read/write and finished into separate things
15:46 jberger we can figure it out in either place
15:46 jberger the code hasn't changed much, just moved around
15:46 sri it's so much harder with {state} in 5 more classes
15:47 sri or maybe that's just me
15:49 jberger I'm not as worried
15:49 sri i suppose you've seen the changes i made after you went away? https://github.com/kraih/mojo/compare/ca510740f3c1062c7ad82f15de15391187bca865...ad4fecd9b79218480c8f69bf4dcf01a08df216fe
15:49 jberger yeah, I read each diff
15:50 sri i stumbled over another naming thing, we now have Mojo::Transaction::WebSocket::frame, which emits the frame event
15:50 sri in Mojo::Transaction::HTTP we have a request event, but we can't just name the method request
15:51 sri jberger: oh, and don't let me distract you, clean up whatever you like
15:52 jberger here's a silly idea
15:52 sri (we can't name the method request, because there's already a req method, which would be confusing)
15:52 jberger what if the channel had a state change event that the transaction could subscribe to?
15:53 sri the transaction shouldn't know about the read/write states
15:53 sri it has no relavance to anything the transaction actually does
15:53 sri s/a/e/
15:53 jberger can we move those first?
15:54 jberger that probably goes with the parse state cleanup
15:55 * sri shrugs
15:55 sri there is one $tx->is_writing call in mojolicious
15:55 sri i think we can replace that
15:56 jontaylor joined #mojo
15:56 sri yea
15:57 good_news_everyon joined #mojo
15:57 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuAMP
15:57 good_news_everyon mojo/channels/master 7baa1c0 Sebastian Riedel: Mojolicious does not need to know about the transaction state
15:57 good_news_everyon left #mojo
15:57 sri now i think all other calls to $tx->is_writing are lower level
15:57 sri and could use the channel
15:58 jberger cool
16:00 good_news_everyon joined #mojo
16:00 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuAD8
16:00 good_news_everyon mojo/channels/master c358417 Sebastian Riedel: handle states a little more consistently
16:00 good_news_everyon left #mojo
16:00 sri i think Mojo::Transaction::is_finished will be using a simple flag later on... $self->{finished}++ or so
16:01 jberger so you have now forward-ported both changes to master to channels/master?
16:01 sri instead of {state}
16:01 sri jberger: yea, i made a bit of a mess -.-
16:01 jberger let me see if it rebases easily
16:04 sri what actually makes this whole state business messy is the 'finished' assignments
16:04 sri https://github.com/kraih/mojo/blob/channels/master/lib/Mojo/Channel/HTTP.pm#L50
16:04 sri they can't actually call $tx->delivered, because they depend on the finish event not getting emitted
16:05 sri because the finish event is only supposed to be emitted when all data has actually been sent over the wire, not when the transaction is done generating messages
16:06 sri that's what i meant with us having basically two finished states
16:06 sri which are conflated right now
16:06 jberger could delivered take a $should_emit?
16:06 jberger at least as a short-term fix?
16:06 sri in my intermediate patch i added a second method
16:06 jberger oh
16:07 sri i turned it into an inside out state machine
16:07 sri https://gist.github.com/anonymous/59caa04092e502378b65
16:07 sri right, closing/closed
16:08 sri it could be Mojo::Transaction::completed/delivered or so now
16:09 sri the rest of the patch sucks though ;p
16:09 sri since it gets hard to find {state} usage, and it changes nothing about the transaction keeping the state
16:10 sri well, that's my thoughts so far
16:12 sri it might be necessary to have two states during the transition, one in the channel and the one in the transaction
16:12 jberger sounds reasonable to me
16:13 sri don't think i can work on that though for now, my head is still spinning a bit
16:14 jberger I'll keep tinkering
16:20 sh4 joined #mojo
16:22 marty_ joined #mojo
16:28 hummeleBop joined #mojo
16:36 PryMar56 joined #mojo
16:44 jberger argh, I just got through an entire rebase sequence and somehow ended up with Mojo::Transaction::HTTP::(client_close|client_write) existing
16:44 jberger :s
16:47 good_news_everyon joined #mojo
16:47 good_news_everyon [mojo] jhthorsen created mojo_websocket (+2 new commits): http://git.io/vuAhG
16:47 good_news_everyon mojo/mojo_websocket 2297a01 Jan Henning Thorsen: Refactored code into Mojo::WebSocket
16:47 good_news_everyon mojo/mojo_websocket 72025db Jan Henning Thorsen: Moved documentation and deprecated methods moved to Mojo::WebSocket
16:47 good_news_everyon left #mojo
16:48 batman should i make a PR...?
16:48 batman sri: https://github.com/kraih/mojo/compare/mojo_websocket
16:49 batman sri: i need to update the tests as well (getting a lot of deprecated warnings)
16:50 batman but i don't want to do that now, in case you decide to drop the branch...
16:50 batman will do it, if you say "continue"
17:09 jberger sri: this is interesting
17:09 jberger https://github.com/kraih/mojo/blob/channels/master/lib/Mojo/Channel/HTTP.pm#L43
17:11 * sri is eating
17:12 sri batman: maybe jberger has an opinion, i'll take a look in 30 mins or so
17:13 jberger all the backporting needs to be considered relative to when we would think about merging the branch and thus a 7.0 release
17:46 sri jberger: what do you mean?
17:46 jberger batman's branch and your changes to master
17:46 sri well, i don't see 7.0 happening anytime soon
17:47 sri after looking at the transaction state situation, i'm a little worried this might still fail
17:48 sri $c->{tx} is also a problem, if all those cases get replaced with method calls, it's getting really expensive
17:49 sri in Mojo::UserAgent and Mojo::Server::Daemon
17:50 sri i know it looks like we are pretty close to done, but there's still some rally big problems
17:50 sri +e
17:50 jberger I certainly understand that that's possible
17:51 jberger but if this effort doesn't succeed then there might never be one that does
17:51 sri that's true
17:51 sri it's too bad we don't have more eyeballs for this
17:52 sri batman: patch looks ok, just some stuff out of order
17:53 batman sri: ok. which file?
17:53 sri imports somewhere i think
17:54 batman "out of order" = (a,c,b) ?
17:54 sri yes
17:54 sri oh, and "deprecated 'Mojolicious::Routes::Pattern::..."
17:54 sri :)
17:55 batman haha!
17:55 batman uhm... well... i just put that in there to make sure you had actually read the diff..................
17:55 batman ;)
17:55 batman hehe
17:56 sri this while looks horrible https://github.com/kraih/mojo/compare/2297a016a1eb%5E...72025dbaee39#diff-64a29645785d5a12b67f6ffc4049bc0aR142
17:56 sri do "my $max = $self->max_websocket_size;" on the line before
17:56 batman ok
17:56 sri you don't want to call a method over and over in a while enyway
17:57 sri s/e/a/
17:57 batman sorry... i can't find what is out of order :(
17:58 sri batman: some of those methods might not even require a deprecation i think, they don't have tests
17:58 sri like client_challenge
17:59 sri marcus, tempire, crab: we could use more eyeballs on the channels/master branch
17:59 batman i'll see what needs to be deprecated...
18:00 * marcus tears out the right one and hands it to sri
18:00 marcus I never liked that eyeball anyways.
18:00 marcus I've been lurking for the last couple of hours, but I'm not really sure what your overarching goals are.
18:01 sri pluggable protocols
18:01 marcus the whole channel branch situation is a bit of a mess afaict
18:01 marcus sri: Like making it easy to support smtp/
18:02 sri right now Mojo::Transaction::HTTP is tied to the HTTP/1.1 protocol
18:02 sri making it easy to support HTTP/2
18:02 sri there needs to be a layer between Mojo::UserAgent and Mojo::Transaction::HTTP
18:03 batman sri: https://github.com/kraih/mojo/blob/master/t/mojo/transactor.t#L505 # do i need to keep the Mojo::Transaction::WebSocket::server_handshake() method?
18:03 batman (that's the only place i could find Mojo::Transaction::WebSocket::server_handshake() in the test suite)
18:04 sri batman: that's already changed in channels/master
18:04 batman sure. but can i just remove Mojo::Transaction::WebSocket::server_handshake() or do i have to deprecate it?
18:05 sri oh also, you can pass the normal $tx object to those functions, no need to do Mojo::Tansaction::WebSocket->new(handshake => $tx)
18:05 thowe joined #mojo
18:05 sri batman: remove, it doesn't test the functionality
18:05 batman sweet.
18:05 batman will fix both
18:06 sri i think you did that in Mojo::UserAgent::Transactor too
18:08 sri jberger: or do you have ideas for {state} and $c->{tx}?
18:09 sri (if we can figure those out, i guess there is still a chance for a soonish 7.0)
18:09 jberger we need to find all the places that tx (and cb) are set
18:09 sri i'm not at all worried about anything else really, just those two
18:09 batman sri: why not just document "has 'tx'" but access it directly in the code for speed?
18:09 jberger once again, I've been trying to do the http parser and again I'm not able to make it work
18:10 sri jberger: did you add a method to start the whole thing?
18:10 jberger yep
18:10 sri did you try one value at a time? {http_state} first... and so on
18:11 sri should be pretty easy
18:11 jberger http_state first actually makes everything blow up :o
18:12 sri Oo
18:13 sri marcus: and no, it's not a mess
18:13 jberger it intentionally violated encapsulation in order to port the code without breaking the tests
18:13 marcus sri: I just meant, there's a lot of different channel/ branches. but didn't realize channel/master was actually the name of a branch and not referring to the diff between channels and master
18:14 marcus I'm reading the diff btw
18:14 sri batman: encapsulation violations for performance says to me that the design is wrong
18:14 sri marcus: ah, yes, jberger has been testing a lot of stuff
18:16 batman ok if i put all the channel_* into archive/channe_xxx ?
18:16 batman sri: not sure if i agree.
18:16 sri jberger: maybe because you only updated Mojo::UserAgent, but not Mojo::Server::Daemon?
18:16 batman (but that's fine)
18:17 sri batman: no
18:17 jberger I think I updated Daemon but since I've done a lot less there I'd expect its possible I missed something
18:17 batman sri: what did you answer "no" to..?
18:17 sri batman: do not move branches
18:18 sri we'll delete them when they are not useful anymore
18:18 batman ok. thought it might make it easier to move the branches that is not actively in use
18:20 good_news_everyon joined #mojo
18:20 good_news_everyon [mojo] jhthorsen pushed 3 new commits to mojo_websocket: http://git.io/vuxB7
18:20 good_news_everyon mojo/mojo_websocket d487f8f Jan Henning Thorsen: Harder, better, faster, stronger while()
18:20 good_news_everyon mojo/mojo_websocket b8dc81d Jan Henning Thorsen: Cleaned up client_handshake()
18:20 good_news_everyon mojo/mojo_websocket d584cae Jan Henning Thorsen: Improved deprecation of M::Transaction::WebSocket methods
18:20 good_news_everyon left #mojo
18:20 batman i think i've fixed what you commented on sri - except "our of order"
18:20 batman (couldn't find it)
18:21 batman oh! u before w
18:21 pink_mis1 https://www.youtube.com/watch?v=GDpmVUEjagg
18:22 good_news_everyon joined #mojo
18:22 good_news_everyon [mojo] jhthorsen pushed 1 new commit to mojo_websocket: http://git.io/vuxRw
18:22 good_news_everyon mojo/mojo_websocket e4bb92e Jan Henning Thorsen: Fix use ...; order
18:22 good_news_everyon left #mojo
18:23 sri for easy review https://github.com/kraih/mojo/compare/master...mojo_websocket
18:23 batman yeah. i'm using that
18:24 sri it's meant for others that want to help ;p
18:24 batman :D
18:25 batman i'll squash the commits into one before rebasing onto "master".
18:25 batman just waiting for "go"
18:25 sri the Mojo::WebSocket changes are mostly orthogonal to channels/master
18:26 sri think it's a rather harmless backport
18:27 sri batman: well, i give it a +1
18:29 batman cool. jberger, marcus?
18:29 marcus +1 from me too for the websocket changes.
18:30 marty joined #mojo
18:31 batman does the changes in Changes have a specific order..?
18:31 batman like "Remove..." before "Added..." ?
18:31 sri don't worry about it, i'll write the Changes entries
18:31 sri but yes, i try to keep the same order
18:32 thowe joined #mojo
18:32 batman ok
18:32 sri i'm also changing the docs a little
18:33 jberger I'm ok with the websocket change
18:33 sri oh, since you added a new module, it needs to be added to the module list in Mojolicious::Guides
18:33 batman under Mojo::Util ?
18:34 sri somehwere next to Mojo::Loader i imagine
18:34 sri sounds right
18:34 sri yea, between Mojo::Util and ojo
18:34 jberger ah, found one tx assignment in daemon
18:36 * batman will push Mojo::WebSocket to master
18:37 sri argh!!! http://blogs.perl.org/users/jt_smith/2016/01/perl-6s-killer-app---async.html
18:37 sri because we have no async in perl5
18:38 sri perl6 has not even proven yet that its super high level async constructs can ever be fast
18:38 * sri facepalms
18:39 sri perl5 async features are not crappy at all, among dynamic languages they are even pretty high up imo
18:40 sri go try doing some async in ruby!
18:41 sri sorry... back on topic :)
18:42 good_news_everyon joined #mojo
18:42 good_news_everyon [mojo] jhthorsen pushed 1 new commit to master: http://git.io/vux2D
18:42 good_news_everyon mojo/master 9fd0137 Jan Henning Thorsen: Moved code from Mojo::Transaction::WebSocket into Mojo::WebSocket (new module)
18:42 good_news_everyon left #mojo
18:42 batman feels awful to commit such big changes into master :P
18:42 * batman finds a beer
18:43 good_news_everyon joined #mojo
18:43 good_news_everyon [mojo] jhthorsen deleted mojo_websocket at e4bb92e: http://git.io/vuxav
18:43 good_news_everyon left #mojo
18:45 jberger batman++
18:45 sri batman++
18:45 jberger I need to go up to madison sometime soon and talk with jt
18:45 jberger at $job[-2] I got to see him a lot
18:46 jberger interesting guy
18:46 batman :)
18:48 jberger oh nice, I got a parse patch working
18:48 jberger final-freaking-ly
18:48 batman jberger++
18:48 sri jberger++
18:51 good_news_everyon joined #mojo
18:51 good_news_everyon [mojo] jberger force-pushed channels/jberger from 08325e1 to 992467e: http://git.io/vudpX
18:51 good_news_everyon mojo/channels/jberger 992467e Joel Berger: add start to Mojo::Channel::HTTP, move parse state to channel
18:51 good_news_everyon left #mojo
18:52 sri oh, you did all at once
18:52 sri looks good
18:52 jberger ok, moving to channels/master
18:53 good_news_everyon joined #mojo
18:53 good_news_everyon [mojo] jberger merged channels/jberger into channels/master: http://git.io/vuxwh
18:53 good_news_everyon left #mojo
18:54 jberger ok time for lunch
18:55 jberger interesting, github irc noticed that was a merge even though it was a ff
18:55 jberger that's scared me
18:56 jberger now lunch
19:12 good_news_everyon joined #mojo
19:12 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vuxP0
19:12 good_news_everyon mojo/master f7a76a9 Sebastian Riedel: update Changes
19:12 good_news_everyon left #mojo
19:14 sri this is crazy, every streamer on twitch is now listening to this song... and now i can't stop either :S https://www.youtube.com/watch?v=tCL9FiAuezk
19:26 zivester joined #mojo
19:38 jberger I'm afraid to click it
19:38 sri it's very soothing
19:44 jberger Oh that reminds me
19:45 jberger It's past Christmas but I don't think I linked this here when I should have
19:45 jberger https://youtu.be/r_jRAJZ9_y0
19:46 sri nope
19:46 sri you shouldn't have ;p
19:49 jberger What's next? Triggering the cb?
19:49 good_news_everyon joined #mojo
19:49 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vux71
19:49 good_news_everyon mojo/master 3614b9d Sebastian Riedel: allow WebSocket constants to be imported
19:49 good_news_everyon left #mojo
19:49 ZoffixWin joined #mojo
19:49 sri does that seem like a reasonable convention for us to handle public constants?
19:50 jberger Looks fine to me
19:51 jberger Certainly consistent, if possibly a little verbose
19:51 batman +1 on the constants
20:05 sri jberger: planning the next steps for channels/master?
20:09 jberger as I said, I'm trying to think of a good way to trigger that cb
20:12 sri well, then i'll push another small thing
20:12 good_news_everyon joined #mojo
20:12 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuxb1
20:12 good_news_everyon mojo/channels/master 74f436f Sebastian Riedel: add handle method to Mojo::Transaction::HTTP
20:12 good_news_everyon left #mojo
20:14 sri maybe that should be in a start method in Mojo::Channel::HTTP::Server
20:14 sri hmm
20:15 kyshtynbai joined #mojo
20:17 sri yea
20:17 good_news_everyon joined #mojo
20:17 good_news_everyon [mojo] kraih pushed 1 new commit to channels/master: http://git.io/vuxNy
20:17 good_news_everyon mojo/channels/master d3f3b91 Sebastian Riedel: Mojo::Channel::HTTP::Server needs a start method too
20:17 good_news_everyon left #mojo
20:21 jberger sri: this is really the odd one: https://github.com/kraih/mojo/blob/channels/master/lib/Mojo/UserAgent.pm#L270
20:21 sri haha, yea
20:21 sri i stumbled over that too
20:22 sri have you thought about keeping the callback on the outside?
20:22 jberger yes
20:24 sri the abstraction there is off
20:26 jberger I'd really prefer that there would be something in the Channel that the UserAgent could subscribe to
20:26 sri it wouldn't help you here though
20:26 jberger right
20:27 jberger that's why that's the hard one
20:27 sri all that remains is the callback, transaction is new, connection is new, all new
20:30 sri ok, that means 3 hard problems remain ;p
20:31 sri marcus: more eyeballs!
20:32 jberger what can we do with these {writing} things?
20:32 jberger https://github.com/kraih/mojo/blob/channels/master/lib/Mojo/UserAgent.pm#L328-L330
20:33 jberger can that be in the channel?
20:33 sri trying to shove everything into the channel is getting a little messy
20:34 sri that flag is very much an implementation detail
20:34 sri it only protects from recursion
20:34 jberger the reason I asked is that that might be another thing that might be tracked outside
20:34 sri yea, it should
20:35 sri we could also leave ioloop out that way
20:35 sri and the tls flag in daemon
20:36 jberger so here's the real question then
20:37 jberger do we restart back at master (with the included changes) and keep the original data structure
20:37 jberger and simply replace the transaction with a channel object that holds the transaction
20:37 sri hmm, i guess that wouldn't actually be too hard now
20:39 jberger heck you could even leave the tx on the hashref too which would save the overhead of a method call
20:40 sri the channel has to interact with the channel a lot though, we would have two references
20:40 sri umm tx
20:41 jberger that's what I'm asking about
20:41 jberger is it better to have the safety of only one?
20:41 jberger or the speed of saving the lookup
20:42 sri i think two would bug me
20:42 sri at best, or just be very very confusing
20:42 jberger that's true
20:43 sri we don't know yet how expensive the method calls will be
20:43 sri on a newer perl it might just be meh
20:43 jberger true
20:52 marcus sri: I'm on strike after you posted sami music.
20:53 marcus https://www.youtube.com/watch?v=2W2dYcJ6jqw
20:53 batman sri, jberger: how about doing sub tx { $_[0]->{tx} } as an attribute?
20:54 batman maybe it would result in some sort of folding..?
20:55 jberger so you have to start to set and then tx is ro
20:55 jberger works for me
20:56 jberger I doubt you'd get any folding though
20:56 batman of course... not without benchmarking though :)
20:56 jberger you do get multideref
20:59 sri so, for getting mojolicious stickers made, is stickermule.com the best choice?
21:01 batman stickers?
21:01 * batman lost track
21:01 sri yea, i want mojolicious stickers!
21:04 sri well, lets see if i get an invite
21:04 marcus sri: Can you make a nice one to put on top off the mbp apple?
21:04 marcus currently wearing my hackerspace logo there. (hackeriet)
21:04 * sri shrugs
21:06 jberger oh that'd be cool
21:06 jberger like these https://www.macdecals.com/macbook-decals
21:07 sri well, they do have this https://www.stickermule.com/custom-skins
21:07 sri so i guess it wouldn't be too hard
21:07 jberger https://www.macdecals.com/beer-mug-spot-light-decal
21:07 jberger give me a mojo cloud like that
21:08 jberger it'd be awesome
21:09 batman jberger: a bit faster https://gist.github.com/jhthorsen/249a14c5deedd16a4000
21:29 batman perl question: can i do my $a = 123; or is that considered a bad thing to use $a and $b as lexical variables?
21:33 PryMar56 joined #mojo
21:34 bpmedley batman : In my experience, while a lot of the time there are no technical issues with doing that the usage can confuse some people.
21:35 batman ok
21:35 batman thanks
21:46 punter joined #mojo
21:50 sri batman: did you see anything else in Mojo::Transaction::WebSocket we could extract?
21:55 jberger batman: the reason not to is that they are excluded from strict
21:55 jberger so if you forget and do $a rather than my $a it won't catch you
22:04 pink_mist also, if you happen to put a sort call where your $a is declared, it may be clobbered
22:05 good_news_everyon joined #mojo
22:05 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vupZf
22:05 good_news_everyon mojo/master e9b5615 Sebastian Riedel: a few more WebSocket tests
22:05 good_news_everyon left #mojo
22:12 vicash hello again. in trying to use the "link_to" method in the templates I see that when I use   %= link_to 'Home' => '#'  the '#' gets converted to '%23'. Is that always going to happen ?
22:18 sri vicash: looks like a bug
22:25 good_news_everyon joined #mojo
22:25 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vupCi
22:25 good_news_everyon mojo/master 1834915 Sebastian Riedel: fix url_for to handle fragments correctly
22:25 good_news_everyon left #mojo
22:25 sri vicash: fixed
22:25 vicash sri: so do I need to use Mojo from github now ?
22:26 sri or wait for the next release
22:26 vicash ok i'll wait for the release. thanks. the result seems to work though with %23 but i was just curious.
22:28 jberger vicash: that's probably the browser fixing it up
22:28 good_news_everyon joined #mojo
22:28 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vupWO
22:28 good_news_everyon mojo/master 78d62c0 Sebastian Riedel: put the fragment example last
22:28 good_news_everyon left #mojo
22:28 sugar__ joined #mojo
22:33 batman sri: maybe with_compression() and with_protocols()... they could take $headers as input.
22:33 batman jberger: ah. good point ($a)
22:34 batman sri: nah... they are part of the Cookbook. probably best to just let them be
22:35 Grinnz well the other reason is that my $a will break any usage of sort functions in that scope
22:37 batman Grinnz: yeah. what pink_mist said :)
22:37 batman thanks all. i got enough reasons now
22:37 * batman gets some sleep
22:58 jberger sri: I've been thinking about what you were saying about the abstractions being wrong
22:58 jberger I think you're right
23:00 jberger I think we need the classes that we've made here, but they are really protocol classes not channel classes
23:01 jberger to back up a bit, I was trying to think of what kind of object the remaining bits in that hashref could be
23:01 jberger and I kept coming up with something like a "Transaction Context"
23:02 jberger and it got me to thinking that there are probably pieces of the UserAgent (and perhaps even the transactor) that could go into a Context class
23:04 jberger it could have the abstractions like the callback (I'm imaging calling it "then" except for the implication of futures) and maybe the websocket upgrade mechanics
23:05 jberger and it got me to wondering about http/2 and thinking that while these refactorings are necessary cleanup before then I don't know if they have encapsulated the functionality that a future http/2 capable useragent would need
23:06 jberger I get the impression that it won't be the same kind of mechanism for upgrading a websocket (yes I know there aren't http/2 websockets yet)
23:07 jberger does any of that ramble make any sense?
23:08 jberger anyway, I'm out for a bit, I'm curious what the response to the above will be
23:14 punter joined #mojo
23:16 sri jberger: yes, makes sense
23:21 sri jberger: maybe we should really start researching how others deal with the problem ;p
23:22 sri i've tried a few times to read the netty code... but it's sooooooooooooooooo verbose
23:25 sri the cowboy code is easier to read but the architecture is very erlang specific

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