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

IRC log for #mojo, 2016-11-28

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

All times shown according to UTC.

Time Nick Message
01:01 mr_trousers joined #mojo
01:29 aborazmeh joined #mojo
02:02 polettix joined #mojo
02:16 stryx` joined #mojo
02:35 ivi joined #mojo
03:24 noganex_ joined #mojo
04:03 polettix joined #mojo
04:06 parv joined #mojo
05:04 dboehmer_ joined #mojo
05:50 jasper joined #mojo
05:56 yoshi joined #mojo
06:13 inokenty-w joined #mojo
06:25 parv joined #mojo
06:40 dod joined #mojo
06:47 dod joined #mojo
07:15 polettix joined #mojo
07:30 dod joined #mojo
07:53 peter-aus joined #mojo
07:54 * peter-aus yawns
07:57 mbudde joined #mojo
07:59 ashimema joined #mojo
08:03 rshadow joined #mojo
08:10 AndrewIsh joined #mojo
08:11 Jonis it's a bit early
08:20 kes joined #mojo
08:28 trone joined #mojo
08:39 cpan_mojo Mojolicious-Plugin-Vparam-1.19.1 by RSHADOW https://metacpan.org/release/RSHADOW/Mojolicious-Plugin-Vparam-1.19.1
09:01 osfabibisi joined #mojo
09:22 janl joined #mojo
09:37 stryx` joined #mojo
09:49 CandyAngel Can I do a PR with 2 alternatives or would I hav to make 2 PRs?
09:49 CandyAngel I on't know which form is more likely to be accepted
09:57 rshadow joined #mojo
10:37 Vandal15263 joined #mojo
10:47 CHYC joined #mojo
11:06 rshadow joined #mojo
11:08 rshadow joined #mojo
11:09 Paddi joined #mojo
11:11 tchaves joined #mojo
11:14 rshadow joined #mojo
11:19 sri CandyAngel: two pull requests, with comments referring to each other i guess
11:20 rshadow joined #mojo
11:22 rshadow joined #mojo
11:23 rshadow joined #mojo
11:28 sri think this was the first year we had real black friday hype in germany
11:28 rshadow joined #mojo
11:28 osfabibisi Schwartze Freitag!
11:29 sri some deals were pretty crazy, i wanted to get some nice asics running shoes for 100 euros, and ended up paying only 30 :o
11:29 tchaves joined #mojo
11:33 CandyAngel sri: Okie, thank you. I will submit them when I get home.
11:33 osfabibisi ah, it's good if you get something you actually cared about cheap, rather than buying lots of useless things you don't need :D
11:41 tyldis Norway had a "black Friday week" which totally misses the point.
11:53 sri haha
11:53 sri amazon here called it cyber monday week
12:13 gregf_ joined #mojo
12:28 stryx` joined #mojo
12:37 mishanti1 So I have seen it mentioned here that it is expected to see a reduction in performance (wrt latency) when going from blocking to non-blocking mojo apps. What we're seeing though is a pretty significant decrease, so much that I would classify the performance as abysmal.
12:37 mishanti1 With that said: I am assuming this is due to us doing something wrong somewhere. Are there any known common mistakes or things that should be tuned that people forget? Have been through and checked https://github.com/kraih/mojo/wiki/Tuning-servers-for-high-concurrency-workloads already.
12:38 sri mishanti1: you seem to misunderstand something, non-blocking is supposed to reduce latency
12:39 sri while there is a slight reduction in performance in super high load scenarios, for pretty much every use case non-blocking should be better if done right
12:40 mishanti1 sri: I understand that. I was just commenting on my impression of peoples result using mojo for non-blocking. I have not seen any benchmarks, it was just my impression from stalking the channel here.
12:43 mishanti1 But regardless; when we benchmark we get rather poor results as it is now. What we did was this: remove usage of DBIx::Class and started using Mojo::Pg, got _great_ increase in performance. Then we started making things non-blocking, and the more we made non-blocking the worse performance seem to get.
12:43 tyldis Non-blocking is about concurrency, though
12:44 sri did you make things like inserts non-blocking?
12:44 mishanti1 So I am _assuming_ we are doing something incorrectly, but having read through the documentation I can't seem to figure out where we might have gone wrong. I mean, even if we do a simple shift->render(text => 'foo'); the numbers we see are far below what I would expect.
12:44 mishanti1 sri: All database calls are now non-blocking.
12:44 sri ye, that's wrong
12:44 sri only long running queries benefit from non-blocking
12:46 mishanti1 Right. So in our eagerness to drizzle delay-steps in our code we have inadvertantly given the scheduler more to do than is required.
12:47 sri you're making DBD::Pg and Postgres do extra work
12:47 sri extra tcp roundtrips through the network
12:48 sri for no reason
12:49 mishanti1 Ok yeah, we should have thought of that. :)
12:50 tyldis Aren't the connections to the database persistent?
12:51 mishanti1 One more question though: do we not need to use the non-blocking versions of calls to `$pg->db->query(...)` for each worker to be able to keep accepting new connections (up to `max_connections`) while serving existing clients?
12:52 pink_mist the connection might be, but roundtrips are still roundtrips
12:52 pink_mist mishanti1: a delay of some milliseconds is no problem
12:53 sri yea, you're overthinking it
12:53 sri blocking db operations with postgres are fine, only make stuff non-blocking that takes seconds
12:55 sri blocking on db operations is often even advantageous, because it prevents your postgres from getting overloaded with parallel queries
12:55 sri postgres is not good at huge numbers of parallel queries
12:57 rshadow joined #mojo
12:59 mishanti1 We had almost no load on our database when everything was non-blocking, and if the frontend was super-busy with just cycling through the various concurrent tasks that explains it.
13:00 mishanti1 So we should backtrack and remove our use of the non-blocking style since the queries we do are very small and quickly completed.
13:10 mishanti1 And if we set max connections to lets say 500 it is reasonable to expect that each worker will be able to accept up to that amount of concurrent requests?
13:13 mishanti1 Though I expect that the answer is no. Should we instead go for firing up loads of workers, given that all db-queries are very fast and quickly completed?
13:14 mishanti1 Eg. 100 workers of 40 max connections, instead of 4 workers of 1000 connections?
13:26 aborazmeh joined #mojo
13:39 asarch joined #mojo
13:54 gryphon joined #mojo
13:59 gryphon joined #mojo
13:59 khfeng_ joined #mojo
13:59 gizmomathboy joined #mojo
14:09 Dandre joined #mojo
14:19 Pyritic joined #mojo
14:25 stryx` joined #mojo
14:29 khfeng_ joined #mojo
14:51 AndrewIsh joined #mojo
14:56 rshadow joined #mojo
15:16 AndrewIsh joined #mojo
15:16 khfeng_ joined #mojo
15:30 exp-innit joined #mojo
15:31 exp-innit Afteroon. I'm implementing an endpoint that outputs a PDF, and this PDF is generated (currently) from a template toolkit template, what would you recommend is the right way to go about this for Mojo? I'm not tied to any particular template style or anything other than pdf generated by a latex file
15:42 Yysachinyy joined #mojo
15:43 jberger exp-innit: well the easiest part is the actual rendering at the end of the process
15:44 jberger probably using a temporary compile directory for each pdf, you'd use reply->asset to serve the finished product: http://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Custom-responses
15:45 jberger as to the actual templating, you could use mojo's own template system, render_to_string and spurt that into a file in a temporary directory
15:45 jberger then again, you can probably as easily get TT to do that also (so you don't have to rewrite your templates)
15:45 jberger the depending on your load, simply compile or else use Mojo::Subprocess to compile in a new fork
15:46 jberger http://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Subprocesses
15:47 exp-innit jberger: thanks for the list, i'm hoping to get away with http://search.cpan.org/~ehuels/Template-Plugin-Latex/lib/Template/Latex.pm .. i notice that there is a couple existing plugins for using the Template framework in mojo
15:47 jberger given that you already are using LaTeX you probably already know how to compile it, that said if you haven't tried latexmk, I highly recommend it
15:47 exp-innit but they implicitly create Template objects, so i can't easily provide my own
15:47 exp-innit will check latexmk now
15:47 jberger I know nothing about the TT system so I can't  help you there
15:48 Yysachinnyy joined #mojo
15:48 exp-innit my technique is based around use of entr and double invoking lualatex :)
15:49 jberger yeah, it seems that module is just for doing the compiling of the LaTeX
15:49 jberger I'd just shell out to latexmk tbh
15:49 jberger its a pretty smart system, it watches the compile logs and detects whether additional compiles are required
15:50 exp-innit jberger: that's somewhat handled by LaTeX::Driver
15:50 exp-innit so i'd like to keep that in the chain if possiblle
15:50 jberger ok, well, you can manage your own compile chain, that's fine
15:50 exp-innit but it looks like you pre-answered my question by pointing me to the rendering
15:50 exp-innit it looks like i can probably use Mojo::Asset::Memory or similar to pass the output back directly
15:50 jberger yeah, in the end, that's the only part that you need mojo for, rendering the result
15:50 jberger Mojo::Asset::File
15:50 purl Mojo::Asset::File is *not* a general purpose module for interacting with files
15:51 jberger thanks purl, that isn't really helpful here
15:51 exp-innit actually yeah looks like i likely do have to write it out to a temp file
15:51 exp-innit a little frustrating as i'm trying to engineer with the idea of immutable containers, but even they ship with tmpfs
15:52 exp-innit does mojo ship with anything for creating temporary filenames? seems to have a first class solution to everything :)
15:52 jberger latex is frustrating in that way
15:52 marty joined #mojo
15:52 jberger no, File::Temp is good enough for Mojo's internal use
15:52 purl okay, jberger.
15:52 jberger purl: forget File::Temp
15:52 purl jberger: I forgot file::temp
15:52 exp-innit how polite purl is :)
15:52 exp-innit and roger that jberger
15:53 jberger man, purl, you're being a pain this morning
15:53 exp-innit better a polite pain than a rude saint ;)
15:53 exp-innit i'm gonna keep latexmk in my workflow even if i do use Latex::Driver, so thanks for that too jberger
15:54 jberger I really love it
15:54 jberger you can set it up to watch for changes and automatgically recompile and then notify your editor
15:54 jberger did my whole thesis that way
15:54 exp-innit do you rate dbic with mojo, or you prefer a Mojo::Pg approach?
15:55 jberger depends on what you want
15:55 exp-innit jberger: that's what i use 'entr' for, i use it for CI in general
15:55 exp-innit i only have a few tables, and very little needs to be ORMy
15:55 exp-innit the nicest thing about entry is it sets up a pgroup, so i can (for example) spawn 4 different processes for each node in a test network, then 'kill 0' and it'll take them down when i change code
15:56 jberger sounds interesting
15:56 jberger if I had a bit more time I'd read all about it
15:56 exp-innit ain't that always the way
15:56 * jberger adds to mental list for later
15:56 exp-innit right gonna get this generating on the terminal as a test
15:56 exp-innit many thanks again jberger
15:57 jberger np
15:58 lluad joined #mojo
16:00 Yysachinnyy Hi all... A very quick question. I want to put a new functionality in DateTime module. I clonned from github into a directory and i put a new sub in DateTime.pm. now when i put a test case for newly added sub it says sub newsub not found.. I tried using use lib pragma to point tomy directory where i cloned DateTime.pm
16:01 Yysachinnyy It looks like already existing DateTime is being used. How do i go ahead with this issue?
16:02 Yysachinnyy Newbie and want to contribute to cpan
16:03 Yysachinnyy Much appreciate any help or gudence
16:03 nicomen 1) you do a pull request against the DateTime github repo?
16:03 Zen change the name of the module you are making changes to so the "real" DateTime.pm doesnt get loaded
16:03 purl Zen: that doesn't look right
16:03 nicomen 2) you make your own module DateTime::SomethingSomething?
16:03 Zen purl: ?
16:03 purl i don't know, zen
16:03 Zen oh ok
16:04 Yysachinnyy Nop.. I used the same name DateTime.pm
16:07 jberger Yysachinnyy: try using "perl -Ilib ..." or "PERL5LIB=lib perl ..." rather than using the lib pragma
16:07 Yysachinnyy So i need to do 1 and 2 steps is it?
16:07 jberger depending on how you use the lib pragma it might be too late
16:07 polettix joined #mojo
16:07 jberger Yysachinnyy: I'm curious, why are you asking in here?
16:08 jberger DateTime is rather off topic
16:12 Yysachinnyy Sorry Joel..  I tried in perl irc channel.. Dint get response.. Thought it would be a quick off topic question.
16:12 jberger we generally are ok with quick diversions, but a more general channel is more appropriate
16:13 Yysachinnyy Sure .. I understand.. Thanks
16:15 Zen so all the apple hardware talk, how's that ontopic?
16:22 jberger (a) we are developers, many of which use apple hardware, (b) it is more of a social topic, which is clearly off topic if someone were to come in to ask about Mojo
16:23 jberger for questions about developing DateTime, no one in here is likely to have expertise (beyond the usual) and it might distract if someone came in with a Mojo question
16:23 Zen thanks for clearing that up
16:24 jberger maybe I should phrase it the other way, there are better channels for that discussion, which will have more expertise
16:34 Yysachinnyy I think it would have been on topic if i would have said that i was trying to add a sub in Mojo::Util module and i faced the issue of not finding then newsub..
16:50 Yysachinyy joined #mojo
16:56 yysachinyy joined #mojo
17:02 Grinnz yysachinyy: #perl-help or #perl on this network would be more appropriate places to ask this particular question, or for help with DateTime usage or development
17:02 Grinnz i am not sure where you tried to ask, but I don't see the question in any of my other channels
17:05 janl joined #mojo
17:09 sri looks like i ran into my first real mojo bug at SUSE :)
17:09 sri https://progress.opensuse.org/issues/13876#note-23
17:12 kes joined #mojo
17:29 jberger nice
17:41 sylo joined #mojo
17:50 sylo joined #mojo
17:57 laidback_01 joined #mojo
18:01 rshadow joined #mojo
18:18 dboehmer_ I'd like to discuss whether Mojolicious should write to "log/$mode.log" only if the log/ directory exists
18:18 dboehmer_ in our app we also create a log dir but want to Mojolicious to log to STDERR
18:19 dboehmer_ we found that behaviour quite surprising
18:19 dboehmer_ however, if the app is run via "prove" I really depend on messages being written to STDERR. i have multiple failing tests and can't connect them to exceptions in the log.
18:21 dboehmer_ I want to propose an additional check in Mojolicious::new if it's run in an harness. also I'd like to see an additional check for the log file, e.g. if "log/$mode.log" already exists or a config option
18:21 dboehmer_ I'm talking about these lines https://metacpan.org/source/SRI/Mojolicious-7.10/lib/Mojolicious.pm#L156-157
18:26 rshadow joined #mojo
18:29 jberger dboehmer_ you can change those settings in your startup method
18:31 dboehmer_ jberger: it's guaranteed that the intermediate code will not write to the log file?
18:31 jberger I believe that has been the policy yes
18:31 jberger I don't know if it is guaranteed or not
18:32 jberger we are aware that many users want to configure their logging via their configuration
18:33 dboehmer_ I feel like Mojolicious is polluting my log/ dir and as I didn't notice at first it also hid my debugging messages. we consider this too much magic here
18:33 dboehmer_ would you possibly accept a PR that adds a check for the existence of the particular log file?
18:34 jberger so this is a conflict between sane defaults and easy configuration, I think our current behaviors are sane defaults
18:35 jberger checking for the existence of a log file would be rather abnormal from a usual unix perspective; most services will create their log files on demand
18:36 sri dboehmer_: you're welcome to make a proposal and lobby for votes
18:36 dboehmer_ I'd say it's easy to get the log files by "mkdir log" but I'd also say it's unsafe to write to locations that not explicitly configured just because their (quite usual) name happens to exist
18:36 jberger dboehmer_: it is documented to behave that way
18:38 jberger like sri, I'm open to a proposal, but it needs to still address sane defaults for new users
18:38 sri also needs to address the docs
18:39 dboehmer_ only after I found the reason for the behavious I found a description in Guides::Tutorial. can you link to any other documentation where it's described?
18:40 jberger Guides::Tutorial is the first document that people are supposed to read
18:40 dod joined #mojo
18:42 dboehmer_ I'd expect some kind of specification to discuss that, too.
18:43 jberger here's a possibility from my POV that would address several concerns
18:44 jberger rather than have Mojolicious::new setup logging (as documented here too btw: http://mojolicious.org/perldoc/Mojolicious#new)
18:44 rshadow joined #mojo
18:44 jberger have those log setup lines be in an attribute initialization subref?
18:45 jberger yes that overloads the logger that already exists in Mojo.pm
18:45 jberger but that would then allow an application to further overload it to override that default behavior
18:45 dboehmer_ sounds like an improvement to me
18:45 jberger and that it would also give a clear place to document the default behavior
18:46 jberger it still has the problem of if something in ::new were to log before calling your ::startup method
18:46 jberger because if you load configuration in your startup it wouldn't have been loaded yet
18:46 jberger but that's no worse than the current case
18:48 sri jberger: i like that idea a lot
18:49 sri might make $app->mode('foo') more viable
18:49 dboehmer_ jberger: to answer "where to?" I'd say STDERR but I am not yet sure what happens before $self->log is initialized
18:49 jberger dboehmer_: I'm not proposing changing the default behavior, I'm proposing making it more overridable in your application
18:50 sri but the relation between Mojo and Mojolicious gets awkward
18:50 sri since both would define the same attribute in different ways
18:51 jberger is that a problem? since Mojo::Base is strictly defined as a hashref-based object with simple accessor method creation, I see it simply as overriding the accessor method
18:51 sri no, it works fine, but it feels like a design mistake
18:52 dboehmer_ I'm leaving $work now and will look into this as soon as I am home
18:52 sri otherwise i'm very +1 on moving it
18:53 rshadow joined #mojo
18:54 Grinnz i think that would make some things easier for me as well
18:55 sri could get rid of this awkward note http://mojolicious.org/perldoc/Mojolicious#mode
18:55 sri (or move it to the log attribute description)
18:56 sri where it would be much less awkward
18:56 jberger yeah, I think that would move to the attribute descript
18:56 jberger ion
18:56 jberger ok, well I think we are all agreed that it is worth making a patch, who wants to do it?
18:57 jberger (not saying that it will be accepted, but that a full proposal should be made)
18:57 * sri hides
18:59 * jberger starts
19:02 tyldis +1!
19:06 jberger here's the code change I'd propose: http://paste.debian.net/899541/
19:07 Pyritic joined #mojo
19:09 sugar joined #mojo
19:16 gizmomathboy joined #mojo
19:19 sri jberger: looks about right
19:20 jberger with less deep recursion of course :-P
19:21 jberger sri: does this change need a new test? if so what should it be? overloading the logger?
19:22 sri jberger: not necessarily
19:23 sri i guess the fact that you can switch the mode very late might be nice to test
19:23 sri imagine that's why people will like it
19:24 sri there's prolly some existing test that can be modified quickly for that
19:28 good_news_everyon joined #mojo
19:28 good_news_everyon [mojo] jberger created log_attribute (+1 new commit): https://git.io/v1LNO
19:28 good_news_everyon mojo/log_attribute 4a99b83 Joel Berger: move default log behavior to overloaded attribute
19:28 good_news_everyon left #mojo
19:28 jberger started a brach
19:28 jberger oh there it is
19:29 jberger think about the wording of the doc while I find a place to test
19:30 marty_ joined #mojo
19:32 jberger maybe here: https://github.com/kraih/mojo/blob/log_attribute/t/mojolicious/app.t#L455
19:33 gizmomathboy joined #mojo
19:33 rshadow joined #mojo
19:35 jberger I'll push to that branch for now, I'll squash it before a merge
19:37 good_news_everyon joined #mojo
19:37 good_news_everyon [mojo] jberger pushed 1 new commit to log_attribute: https://git.io/v1LAi
19:37 good_news_everyon mojo/log_attribute 8f9a555 Joel Berger: add a test for non development mode
19:37 good_news_everyon left #mojo
19:41 good_news_everyon joined #mojo
19:41 good_news_everyon [mojo] jberger pushed 1 new commit to log_attribute: https://git.io/v1LxG
19:41 good_news_everyon mojo/log_attribute 7a3ec12 Joel Berger: update Changes
19:41 good_news_everyon left #mojo
19:45 good_news_everyon joined #mojo
19:45 good_news_everyon [mojo] jberger force-pushed log_attribute from 7a3ec12 to 35ac19c: https://git.io/v1LpW
19:45 good_news_everyon mojo/log_attribute 35ac19c Joel Berger: move default log behavior to overloaded attribute
19:45 good_news_everyon left #mojo
19:46 jberger ok, unless people want to discuss the documentation I think that is my proposed commit
19:48 PryMar56 joined #mojo
19:49 Grinnz "L<Mojolicious> will pick up the current mode" now that it's in an attribute, i'm not sure saying what Mojolicious would do is what you need there
19:49 Grinnz more the default logger
19:49 lluad joined #mojo
19:50 dod joined #mojo
19:51 Pyritic joined #mojo
19:57 bwf joined #mojo
20:06 jberger Grinnz / sri: do you like this better? http://paste.debian.net/899548/
20:08 Grinnz the mode parts a little ambiguous, maybe "The level will default to C<debug> if the L</mode> is C<development>, or C<info> otherwise"
20:08 Grinnz otherwise seems good
20:17 good_news_everyon joined #mojo
20:17 good_news_everyon [mojo] jberger force-pushed log_attribute from 35ac19c to b5f87cd: https://git.io/v1LpW
20:17 good_news_everyon mojo/log_attribute b5f87cd Joel Berger: move default log behavior to overloaded attribute
20:17 good_news_everyon left #mojo
20:19 polettix joined #mojo
20:22 jberger opened a PR, available for voting https://github.com/kraih/mojo/pull/1017
20:36 good_news_everyon joined #mojo
20:36 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/v1tTh
20:36 good_news_everyon mojo/master c895cab Sebastian Riedel: Merge pull request #1017 from kraih/log_attribute...
20:36 good_news_everyon left #mojo
20:36 sri accepted, since it fixes a common new user problem
20:38 jberger \o/
20:52 good_news_everyon joined #mojo
20:52 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/v1ttU
20:52 good_news_everyon mojo/master 4b37c3a Sebastian Riedel: we import all modules used in the current class
20:52 good_news_everyon left #mojo
20:59 sugar joined #mojo
21:00 CandyAngel Sorry if I made a mess of those PRs
21:01 CandyAngel Eh. it fails with Travis anyway. Argh
21:01 sri what mess?
21:01 purl PLEASE DO NOT MAKE A MESS IN HERE
21:03 jberger botsnack
21:03 purl :)
21:05 CandyAngel Oh, it's the proxy with bad target one failing.. but I had to do the same check there on my work machine
21:06 CandyAngel I need to think about that one because I think the Mojo::IOLoop->stream() call triggers the behaviour
21:09 stryx` joined #mojo
21:10 CandyAngel A line reordering fixes it, but I don't know if the line order is important
21:11 jberger shouldn't `return Mojo::IOLoop->stop` work where `Mojo::IOLoop->stop and return` isn't defined?
21:11 jberger and take 4 less characters to boot
21:12 CandyAngel I just copied the 'and return' idiom from another part of Mojolicious
21:12 CandyAngel I can change it to 'return Mojo::' if that's preferred
21:12 sri it's not about preferred, it's about working ;p
21:13 jberger and return only works if Mojo::IOLoop->stop return a true value
21:15 CandyAngel Good point. What's the bet that I won't be able to find where I copied it from now either -.-
21:16 sri it's in Mojo::UserAgent for example, i use the idiom in docs when i want to make it clear that the return value is unimportant
21:16 pink_mist maybe it was copied from your imagination :P
21:16 pink_mist oh :)
21:16 CandyAngel Ah okies
21:17 CandyAngel That makes sense because I was trying to track down what was actually getting stuck
21:17 CandyAngel So I was looking at UA and IOLoop
21:17 sri see, this is why i use editors with great find in project feature people
21:18 CandyAngel pink_mist: It wouldn't be the first time. I reported a bug in some other software, then later couldn't even figure out which machine I'd updated to check if it still happened
21:18 CandyAngel Let alone reproduce it >.<
21:21 jberger this is interesting though because we've seen reports of this recently and none of us can reproduce
21:22 sri "this"?
21:22 purl somebody said "this" was not an article
21:22 * Grinnz uses "git grep" for find in project :P
21:22 jberger a fix for this websocket test failure
21:22 sri Grinnz: you're a dinosaur
21:23 * jberger uses ack or ack.vim
21:23 Grinnz i was gonna say, at least i don't use vim or make :P
21:25 CandyAngel This is actually awkward because at work, I can't test that the test passes when it should
21:25 CandyAngel And at home, I can't test that it fails when it should
21:26 good_news_everyon joined #mojo
21:26 good_news_everyon [mojo] jberger deleted log_attribute at b5f87cd: https://git.io/v1t3u
21:26 good_news_everyon left #mojo
21:26 CandyAngel You can hold off accepting these if you need me to double check before accepting either of them
21:28 CandyAngel Err, that was worded badly
21:28 tyldis sri: And what does the kool kids use these days? IntelliJ?
21:29 CandyAngel What I meant was, if you want to accept either of these, I can check tomorrow that they definitely fix the infinite looping before you do
21:32 CandyAngel Did the other people experiencing the test failure get the infinite looping?
21:33 jberger hmmm maybe I was wrong
21:33 jberger I was thinking of https://github.com/kraih/mojo/issues/1011
21:34 CandyAngel Oh
21:34 CandyAngel Hm.. I do get a failure on the "fail intentionally" test (the one returning status 4000, instead gets like.. 25809)
21:35 CandyAngel I will check what I get on that test tomorrow
21:38 CandyAngel Yay, passed Travis \o/
21:39 jberger eeep
21:40 jberger super-high websocket closes statuses remind me of that other bug :s
21:40 Pyritic joined #mojo
21:48 CandyAngel Happy to help getting the bottom of it if I can
22:11 Pyritic joined #mojo
23:10 Grinnz https://metacpan.org/pod/Mojo::Transaction#remote_address should this return the first value of X-Forwarded-For instead? according to the spec, if it has multiple values the first one is the original client
23:10 Grinnz i ask because we're probably going to be using an AWS proxy in front soon...
23:11 sri tyldis: atom, vs code, sublime
23:13 sri vs code is actually pretty good from what i hear
23:19 Grinnz i guess the problem there is that anyone can provide an existing X-Forwarded-For header saying whatever they want, so you can only rely on the last value
23:19 Grinnz unfortunately the last value would be useless to us
23:20 Grinnz i might just add my own logic to parse the 2nd to last address out of that header
23:32 stephan48 basically it comes down to the decision to trust the proxy server
23:33 stephan48 which might be a problem in apps which are supposed to be deployed with and without a frontend proxy
23:33 stephan48 some frameworks/best practice solutions recommend a configuration variable to control the behaviour(pulling the IPs out of X-Forwarded-For)
23:33 Grinnz yeah, for various reasons we are going to have the same proxy situation on dev and prod, though
23:34 Grinnz mainly because i want to make sure this AWS thing will actually work correctly
23:35 stephan48 i don't know about AWS but some frontend proxies are configured to block the X-Forwarded-For and other headers coming from the user(or what they think is the user) and inserting their own
23:35 stephan48 yup makes sense
23:35 stephan48 i think theres a Mojo Plugin for this scenario
23:35 Grinnz it's just one line of code really :)
23:36 stephan48 jup
23:38 stephan48 just for the reference: http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html AWS seems to be ignoring any outside X-Forwarded headers
23:38 stephan48 anyway i am off!
23:46 Grinnz it doesn't sound like that to me
23:47 Grinnz it does for X-Forwarded-Proto, but that one only has the one value
23:47 Grinnz also, it is really annoying that most of the documentation for elastic load balancers is under the "Classic" load balancers, when we want to use the "Application" load balancer
23:47 Grinnz so it's unclear which parts apply to it
23:57 marty joined #mojo

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