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

IRC log for #mojo, 2016-04-24

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

All times shown according to UTC.

Time Nick Message
00:19 * jberger looks
01:18 tchaves joined #mojo
01:23 jberger Hmmm that's going to take a bit of looking
01:24 tchaves joined #mojo
02:06 asarch joined #mojo
02:11 jasanj_ joined #mojo
02:29 noganex_ joined #mojo
03:24 kaare joined #mojo
06:34 dod joined #mojo
06:39 dod joined #mojo
06:59 salva joined #mojo
07:42 Vandal joined #mojo
07:53 sri another argument against Mojo::Pg expanders https://github.com/kraih/mojo-pg/pull/18#issuecomment-213909293
07:54 HtbaaPi joined #mojo
07:58 odc joined #mojo
08:35 jberger sri: is that just an example?
08:49 sri yes, but it highlights how sketchy the DBD::Pg types situation is
08:50 sri i mean, i feel comfortable doing it for json, because even if stuff breaks at some point, json support is worth it
08:50 sri the other types are meh at best
08:51 sri it's just not worth making the code look worse than before
08:54 jberger Yeah
08:55 jberger As I've said, to_json(table.column) fixed my boolean needs
08:56 sri yea, i'll give it a -1 https://github.com/kraih/mojo-pg/pull/18#issuecomment-213917233
08:56 jberger The same is basically true for an extra precision number too I'd guess
08:57 jberger select table.very_long_number::text
08:57 sri don't you get it as a string now anyway?
08:57 jberger No idea
08:57 sri think so
08:57 sri it just loses precision when you do math ops on it
08:58 jberger Even if it doesn't by default I'd think a pg side coercion would mitigate
08:58 jberger (Re getting a string)
09:01 * jberger wears his failraptor shirt to the last day of qah
09:02 sri RAPTOR PRIDE!
09:02 * jberger wore the pirate cloud on the first day
09:06 kes joined #mojo
09:07 kes joined #mojo
10:36 irqq joined #mojo
10:49 meshl joined #mojo
11:04 jasanj_ joined #mojo
12:03 sri oh my, of course the guy who hates me even more than rjbs becomes new perl pumpking, gonna be fun...
12:05 sri why can't we have someone nice for a change?
12:05 pink_mist heh, where's the announce? =)
12:05 sri multiple tweets from the hackathon popped up like 20 mins ago
12:06 pink_mist ahh
12:06 preaction it was just announced here like 22 minutes ago
12:06 sri seems like a total desaster to me, at least rjbs was competent
12:07 * sri is actually worried now
12:08 sri maybe getting more invested in perl6 is not such a bad idea after all :S
12:12 jberger sawyer and I have been working well together all weekend
12:13 jberger if he has an opinion on us, I think he'll keep it to himself
12:14 sri i remember a talk from not to long ago where he made sarky remarks about mojolicious
12:16 sri few years ago i made peace with sukria (after the big mojolicious stole code from dancer thing), and sawyer has been the one keeping the feud alive since then
12:16 sri imo he's one of the worst people in the community
12:17 pink_mist what was this stole code thing? 0_o before my time
12:17 sri that was back when use.perl.org still existed
12:18 sri when we added Mojolicious::Lite some time in 2011/2012 sukria started ranting on use.perl about how we stole his code
12:19 sri dancer was like a few days old, and i had never heard of it
12:20 pink_mist oh, I can see how that could have looked
12:20 sri oh no wait, it was even earlier
12:20 sri 2009/2010 :o
12:21 sri it was pretty silly really, Mojolicious::Lite has been a tiny wrapper around Mojolicious from the start
12:28 sri anyway, i couldn't care less about dancer, but they have two people on the core team i despise, sawyer and the homophobic guy
12:37 sri oh well, at least sawyer will bring back the drama to p5p and make things more interesting
12:41 sri look at that, homophobic guy is now a team lead at booking.com, go figure
12:42 Adura At least they know he won't start an office relationship with the other males.
12:45 sri man, i must sound crazy to people who have been not been around for so long and experienced all this :)
12:47 sri the real drama pretty much stopped happening around 2011 i guess
12:47 sri 2006 - 2011 was a crazy time
13:03 sri looks like all records of the mojolicious/dancer fight have vanished from the public internet
13:08 jberger I'm all for burying the hatchet
13:08 sri i tried, sawyer didn't let me
13:09 sri liek i said, i'm good with sukria
13:11 sri which was surprisingly easy, we both realized we got too passionate about our code and let things spiral out of control
13:12 sri sawyer is different, i can't really read him, he acts all nice and then suddenly attacks out of nowhere
13:16 jasanj_ joined #mojo
13:22 sri reini is gonna get a heart attack when he reads about the new pumpking
13:22 jberger yeah, we were joking about that too :D
13:22 jberger funny thing happened during the rjbs goodbye announcement
13:23 jberger neilb had cue cards with comments from a few people that couldn't make it here
13:23 asarch joined #mojo
13:23 jberger they had the name of the person on the front of the card
13:23 jberger so we could see it
13:24 jberger and in the middle was one that said reini, which neilb paused on then threw over his shoulder
13:24 jberger :P
13:24 sri lol
13:24 jberger got a good laugh
13:29 nicomen damian mentioned it might end up as a shared-position, is sawyer elected alone?
13:32 sri i'd appreciate more votes on this https://github.com/kraih/mojo-pg/pull/18
13:33 sri drama is fun and all, but we've got a project to run!
13:34 nicomen hehe
13:36 nicomen is expand meant to be something analogous to DBIx Inflate plugins?
13:36 sri not quite
13:37 sri inflate is tied to the column name, while expand is based on type
13:37 sri right now it only handles json and jsonb
13:38 nicomen ok, I see it's mainly for json/b, but it seems to me like a system that could be applied on more values returned
13:38 sri types in DBD::Pg are weird though
13:39 sri postgres extensions end up as "unknown", and then there's custom undocumented stuff like "_json" and "_jsonb"
13:39 sri think i don't like pluggable expanders because the foundation is not good
13:43 eseyman joined #mojo
13:46 jberger commented on the post to the effect of our discussions on irc
13:47 sri jberger: the pull request makes things slower
13:49 jberger let me clairify
13:49 sri his benchmark results seem flawed too
13:50 sri he reports 90/s vs 91/s for ->hashes, but the code is the same
13:52 jberger I've clarifed though he happened to comment just before it so I don't know if he noticed
13:52 jberger oh well
13:55 sri which types are worth expanding anyway? http://www.postgresql.org/docs/9.5/static/datatype.html#DATATYPE-TABLE
13:56 sri boolean and time seem to be the obvious ones
13:56 jberger if long number types do get stringified on the way out, then that's a major use-case lost
13:57 jberger xml -> Mojo::DOM would be kinda fun :D
13:57 sri if they aren't, then expand wouldn't help either
13:57 jberger sri: hmmmm, true
13:57 jberger sri: oh, but BigInt
13:57 dvinciguerra joined #mojo
13:57 jberger or BigFloat
13:58 jberger anyway, none of these are strictly necessary, they are all about convenience
13:58 sri json is the big one i care about personally
13:59 sri actually, i might be more interested in having a way to force json decoding
13:59 jberger if a pluggable interface is possible without too much complexity/hit then I think it makes sense
13:59 sri or acutually, no i don't care too much ;p
13:59 sri jberger: yea, the implementation matters a lot
14:00 jberger but yeah, json has always been a priviledged citizen in Mojo-land
14:00 jberger I don't mind the eventual answer being "JSON gets an expander and others don't, see JSON-over-websocket"
14:01 jberger it would be nice to have because the Results class can more easily see the returned types
14:01 sri also there's http://mojolicious.org/perldoc/Mojo/Pg/PubSub#json
14:10 asarch joined #mojo
14:24 chansen sri: What have I missed (Have not backlogged for a couple of weeks), homophobic guy is now a team lead at booking.com?
14:39 tchaves joined #mojo
15:20 lluad joined #mojo
15:30 yysachinyy joined #mojo
15:30 yysachinyy O
15:31 yysachinyy Hi
15:31 yysachinyy nl
15:33 mishanti1 Maybe we could give a failraptor shirt to the phobic guy, whoever it is?
15:53 sri chansen: think we've had enough drama for today
16:05 yysachinyy joined #mojo
16:20 sri chansen: i'm referring to damog, who at the time really liked to throw around homophobic slurs on twitter
16:34 Adura joined #mojo
17:14 meredith joined #mojo
17:20 PryMar56 joined #mojo
18:30 thowe huh.  I think I have successfully done a non-blocking Pg query.
18:31 thowe bpmedley, Thanks again for your help, I think I have a successful test :)
18:34 thowe so now I just wonder, am I doing this right? https://gist.github.com/thowe/0bdd78b54d77f44b2592eafa790bd728
18:36 sri thowe: a) query has no return value there, b) you should initialize a Mojo::Pg instance during startup
18:37 sri http://mojolicious.org/perldoc/Mojo/Pg#DESCRIPTION
18:37 sri that is very important for performance
18:40 thowe Oh, yeah, I didn't get rid of that when I changed it.
18:42 thowe I use DBIC for 99% of everything.  And these functions that use Mojo::Pg will be used rarely.  So I wasn't sure if having the Pg instance at startup was completely sensible.  But if there is no down side...
18:43 thowe Thanks for taking a look, BTW.
18:46 thowe Am I using render_later correctly?  And then I assume I need to call render in that sub(?)
18:47 sri yes
18:47 thowe OK, thank you very much =)
19:27 mishanti1 We also use DBIC for almost all of our DB-stuff. I was super sceptical towards it when we started (as I've seen the innards of a few ORM's), but have been pleasantly surprised.
19:27 mishanti1 It produces surprisingly sensible SQL.
20:00 meshl joined #mojo
20:03 irqq joined #mojo
20:04 inokenty joined #mojo
22:37 thowe running a non-blocking SQL query is good and fine...  But what if I need to run three queries non-blocking, and I need to use all the results to build the data needed to render?  Embedding the sub routines seems obvious, but I can easily see that becoming a problem.  I'm guessing there is a better way.
22:38 thowe nm, maybe delay is what I want
22:38 preaction yes
22:38 thowe preaction, "yes" there is a better way, or "yes" delay is what I want?
22:39 preaction yes, there is a better way, and delay is what you want
22:46 thowe wow, except that the syntax is making my head explode...  I am not sure I can figure out how to use this thing.
22:51 preaction thowe: https://gist.github.com/preaction/b60c0d0fc960f9072d27e71b05375939
22:53 thowe so, each query need not be its own sub, I can delay until they complete the whole series?  Inthis example, how to I get the different results from each query?
22:53 thowe or, no, what is happening here?
22:54 thowe is @results an array of the result objects returned by each query?
22:55 preaction yes. @results is the combination of all the args passed to the callbacks (which are created by begin())
22:55 preaction by having multiple begin(), i tell delay to wait until they are all done
22:55 preaction then the next step will run
22:57 thowe so, if not done with steps...  Could I write a sequence of subs and basically get the same thing back?
22:58 thowe I mean, is this shorthand for that?
22:58 preaction you mean not  using delay?
22:59 thowe no, using delay, but not using "steps".
22:59 pink_mist I don't think your question makes sense
23:00 pink_mist steps is the whole point of delays
23:00 thowe oh...
23:02 preaction thowe: https://gist.github.com/preaction/b60c0d0fc960f9072d27e71b05375939#file-gistfile2-txt
23:02 preaction those, to my knowledge, are equivalent
23:04 thowe I'm curious how the results of two statements get returned.  I'm used to a function returning whatever is last.
23:04 thowe or is this somehow the magic pf passing forward behavior?
23:05 Adura Welcome to the magical world of non-blocking.
23:05 preaction $delay->begin returns a subroutine that collects the arguments passed in to it
23:07 preaction thowe: does this make more sense? again equivalent to the above 2: https://gist.github.com/preaction/b60c0d0fc960f9072d27e71b05375939#file-gistfile3-txt
23:07 thowe Does that mean the return value of the previous statement is collected, or does it mean it collects all of the return values from calls to itself and returns them as an array?
23:08 preaction it sounds like something you could test
23:09 preaction but delay just encapsulates what i demonstrate in that gistfile3.txt thing
23:10 thowe I don't think the former of what I typed above makes sense.  I'm guessing it rolls them together, which is what I think you are showing below by pushing onto the array.
23:11 thowe that's kick butt.
23:13 thowe What if you need the results from the first sub as part of your query in the next?  Can you put that together, not render, and create another delay for your next call(s)?
23:13 preaction that's what steps is for. the result of all the callbacks in the previous step are given to the next step
23:13 preaction why create another delay object when you can use the same one?
23:15 thowe if you call $delay->begin in the next sub, is it building on the previous chain?  Or does it start rolling another array of return values?
23:15 preaction it's another array
23:15 preaction again, this seems like something you could test
23:15 thowe OK.  Awesome.
23:16 thowe Wow, OK.  I think this is gonna be cool.
23:17 thowe haven't quite wrapped my head around this passing forward style yet, but it is starting to hurt less to think about it.
23:17 thowe preaction++
23:33 thowe is there going to be any sort of BOF or something similar for Mojo at YAPC::NA 2016?
23:37 pink_mist what's a BOF?
23:38 pink_mist (also, I wouldn't be able to answer /anyway/, as ::NA is a bit far for me)
23:38 preaction Birds of a Feather. like, just get a room and say hey
23:38 pink_mist oh, I see, neat
23:38 thowe Birds Of a Feather.  I guess it's something they do at conferences.
23:46 meshl joined #mojo

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