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

IRC log for #mojo, 2018-02-04

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

All times shown according to UTC.

Time Nick Message
00:30 polettix ?
00:41 ChmEarl joined #mojo
01:31 nohuhu joined #mojo
01:39 aborazmeh joined #mojo
05:04 dboehmer_ joined #mojo
05:50 zach joined #mojo
05:51 zach question, any of you ever used cloudflare with a full mojo app and what all did you have to do?
06:23 polettix joined #mojo
07:07 polettix joined #mojo
08:04 Vandal joined #mojo
09:02 marcus CandyAngel: what will you use to write your display manager?
09:05 dod joined #mojo
09:10 dod joined #mojo
09:13 bobkare joined #mojo
09:15 trone joined #mojo
09:18 jamesaxl joined #mojo
09:30 marcus zach: I've used cloudflare with mojo behind it, didn't have to do anything special. Just set cache headers?
10:19 polettix joined #mojo
11:19 mishantil joined #mojo
12:06 sri so, nobody has any use cases for ISO 8601? https://github.com/kraih/mojo/pull/1167
12:16 CandyAngel marcus: Perl, of course :P
12:16 Leffe joined #mojo
12:18 CandyAngel I've tried.. 3 DMs on my X230 and they all have silly flaws.. though LXDM is, by far, the worst (leaks running applications into other accounts)
12:18 marcus i3 ftw
12:18 CandyAngel It's currently on LightDM, whose flaw is "every user is listed twice", which is mild in comparison :P
12:19 CandyAngel DM, not WM :P (and yes, i3 ftw)
12:19 marcus I actually use lxdm now.
12:19 marcus I only have my own account tho.
12:20 CandyAngel What happens with LXDM is I log into my account, start Firefox (for example), then I close i3 (logging me out of my account) and then log into my sisters account.. my Firefox will then show up in her account
12:21 CandyAngel As in, the actual, running Firefox process
12:21 mishanti1 xmonad works very well for me. But I wish to have zero UI-elements except the windows I launch, so I guess it is sort of niché.
12:22 CandyAngel Pretty major security issue, in my opinion..
12:23 marcus CandyAngel: that really sound weird
12:23 CandyAngel I was surprised, to say the least!
12:24 * sri is boring and just runs GDM, which mostly just works
12:29 CandyAngel Oddly, it doesn't happen the other way around though (running stuff in my sisters account doesn't show up on mine when I log in)
12:29 CandyAngel So.. Xfce (hers) is logging out differently to i3 (mine)
12:30 CandyAngel You can work around it by making it restart LXDM on PostLogout but that is jarring and probably breaks something :P
12:39 mishanti1 sri: Well, for me at least having ISO 8601-support would save me from having to go `DateTime::Format::Pg->parse_datetime(...)` on all such fields pulled from a database where I know ISO 8601 is returned (most of the ones I have to work with).
12:40 mishanti1 Or let me rephrase: I would much rather use Mojo::*-modules than other modules as the Mojo-ones just tends to be _better_ than everything else.
12:44 sri mishanti1: but that's not a good use case
12:44 sri extract(epoch from foo) as foo
12:45 sri postgres already handles that well
12:46 sri with Mojo::Pg that's no problem to use at all
12:47 sri in fact i've added a feature to make it easier to SQL::Abstract::Pg http://mojolicious.org/perldoc/SQL/Abstract/Pg#AS
12:55 mishanti1 For the latter kind of usecase I'd much rather write plain SQL, as that makes it clear what is run. Those kinds of "sql builder"-methods are great for simple things like `$db->select('foo', undef, {id => $id})`, but get a bit cumbersome once you involve aliasing, mutations, joins etc.
13:01 sri disagree
13:03 mishanti1 It is easier for you to remember the internals og SQL::Abstract::Pg than read the sql?
13:03 mishanti1 s/og/of/
13:03 sri DBI_TRACE=SQL
13:03 purl somebody said DBI_TRACE=SQL was maybe a better hammer though, as it will work more often
13:04 mishanti1 But that requires you to to run the code and read the output to see what it does, instead of just looking at the code.
13:05 sri well, if you don't know how to use SQL::Abstract then that's of course a problem, like with all modules
13:06 sri it's not rocket science, everything SQL::Abstract::Pg adds on top of SQL::Abstract is shown with example here http://mojolicious.org/perldoc/Mojo/Pg/Database#select
13:17 sri and btw. i think \'extract(epoch from foo) as foo' is very obvious in what it does, since that's a convention that works all over SQL::Abstract
13:19 mishanti1 When sql-builders have fluent interfaces and those are used then intent and consequence is clearer, but when perl-datastructures are passed it is suddenly a different ballgame. Hence my comment that it is great for simple selects, but once you have more work being done (selecting only a few fields, mutating those etc) then you can no longer "just read" the code to see what is being executed.
13:19 sri no
13:19 mishanti1 Also, \'extract(epoch from foo) as foo' is great for a single field, but when you have five such fields and they are not timestampz then it gets messy very quickly.
13:20 mishanti1 Ok, so philosophical differences. :)
13:22 sri yes, and i'm starting to think that ISO 8601 support would encourage bad practices
13:29 * sri casts his vote https://github.com/kraih/mojo/pull/1167#issuecomment-362906861
13:29 sri jberger, marcus, batman: formal vote please
13:50 Leffe joined #mojo
14:27 epiphero joined #mojo
14:47 epiphero_ joined #mojo
14:50 dikim joined #mojo
15:07 genio sri: In your appveyor.cmd you pull dmake down specifically. is that because the later version of strawberry uses gmake and it's easier that way to build no matter the version?
15:08 genio I'm going to try and remove that all together as  instead of prove -l ...  I'll just tell it to    cpanm --test-only -v .
15:28 ferreira joined #mojo
15:45 polettix joined #mojo
16:02 sri genio: i did not write that
16:03 genio hrm. I guess I need to go through and try to understand everything it's doing
16:24 berov joined #mojo
16:24 Leffe joined #mojo
16:34 sh14 joined #mojo
17:06 sh14 joined #mojo
17:27 sh14 joined #mojo
17:35 dotan_convos sri: would you reject a pull request that adds time zone support to Mojo::Date? It is part of rfc822 that Mojo::Date ignores.
17:36 dotan_convos I suggest handling it like HTTP::Date, i.e, using Time::Zone if it is installed, else just handling offsets.
17:37 sri i don't know, i would most likely vote -1 to prevent feature creep
17:38 sri depends on how well the argument for adding it is and what it costs
17:38 sri pulling in moe modules is a definitive rejection though
17:38 sri *more
17:38 sri we don't add 3rd party dependencies for stuff core mojo does not need
17:41 dotan_convos I'm saying if the timezone is an offset, do the math. If it's a string (one of the limited set listed in rfc822), and the Time::Zone module is installed, use that to get the offset.
17:41 dotan_convos No hard-coded new dependency
17:42 dotan_convos I mean, no required dependency.
17:42 sri it's the same for us
17:43 sri well, technically, a required dependency is even harder to get added
17:43 sri almost impossible
17:46 sri dotan_convos: make it a role
17:50 jberger I have a few thoughts wrt roles
17:50 dotan_convos What, use Class::Method::Modifiers to wrap parse() and epoch() just so I can do a little more bookkeeping after a regular expression?
17:50 jberger I wonder if we could define an interface for adding more parser methods
17:52 jberger Other idea would be to delegate more to the core module Time::Piece and its strptime method
17:52 sri and then we redesign all other modules for more role hooks?
17:53 sri i don't think so
17:53 sri dotan_convos: why would you wrap ->epoch?
17:54 dotan_convos Mojo::Date is a small and stand-alone utility, I can just keep using a different small (and a bit less standalone) utility - (HTTP::Date + Time::Zone). I think my RSS-parsing code predates Mojo::Date's introduction.
17:54 dotan_convos Right, don't need to wrap epoch.
18:10 dotan_convos (Sorry, my stuff was from 2014, Mojo::Date was commited in 2008. I think I wasn't aware of it until sri mentioned he was experimenting with adding relative times to it, or some other feature I'm not sure ended up in core)
18:11 jberger I didn't think it was as old as 2008
18:24 ferreira joined #mojo
18:26 polettix joined #mojo
18:31 sh14 joined #mojo
18:40 Grinnz mishanti1: DateTime, Time::Piece, and Time::Moment are already fully featured excellent date/time manipulators, and you should not feel that they need to be replaced. the only thing they don't do optimally is time zone handling, and there is no way Mojo is going to reimplement handling that massive amount of data.
18:42 polettix_ joined #mojo
18:43 Grinnz DateTime::TimeZone and DateTime::TimeZone::Olson are two implementations of complete timezone handling
19:33 karjala_ joined #mojo
19:52 Leffe joined #mojo
20:06 marty joined #mojo
20:08 marty joined #mojo
20:17 marty_ joined #mojo
20:38 stefan Regarding the bulk inserts from the mailing list, is this the right approach, or am I still not getting it?  my $tx = $db->begin; $results->hashes->each(sub{$db->insert('b', $_)}); $tx->commit;
20:41 tyldis Well I do date handling all day, and ISO8601 is exclusively used in my industry.
20:41 tyldis All in UTC always, no TZ handling
20:43 sri the rfc 3339 subset of 8601 we already support
20:46 tyldis The optional T delimiter bugs me with 3339.
20:47 tyldis Oh, it was the other way
20:53 mishanti1 Yeah, the optional T is always annoying.
20:56 CHYC I have no vested interest in PR#1167, but I would say that I have a subclassed Mojo::Pg::Database to transparently convert timestamptz columns into DateTime objects when "->expand"ed. Granted this is probably a niche trick, but the PR would allow transparent convertion of psql columns to Mojo::Date objects.
21:01 sri CHYC: actually, that's a planned feature for Mojo::Pg for some time
21:02 sri allowing custom expanders
21:02 sri $pg->add_expander(json => sub {...})
21:03 sri $pg->add_expander(timestamp => sub {...})
21:03 sri something along those lines
21:03 purl something along those lines is the only explanation
21:03 CHYC sri: I know, I wrote working code that was rejected for inclusion https://github.com/chy-causer/mojo-pg/commit/1b156c614d8bcbde25a49d0a5fd945b84fc92250
21:03 CHYC But since I can subclass Mojo::Pg::Database I did that and took the code above into my own codebase.
21:04 CHYC Subclassing didn't exist at the time of my PR
21:04 sri i only vaguely remember that :S
21:05 CHYC I get a significant speed boost and significantly smaller codebase by expanding raw booleans over "to_json(column)"
21:07 sri ah yea, the patch was never finished https://github.com/kraih/mojo-pg/pull/18
21:07 sri bummer
21:13 veryrusty joined #mojo
22:03 polettix joined #mojo
22:20 ferreira joined #mojo
22:36 nohuhu joined #mojo
22:42 ferreira joined #mojo
22:49 ferreira joined #mojo
23:02 epiphero joined #mojo
23:04 epiphero_ joined #mojo

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