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

IRC log for #mojo, 2018-01-16

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

All times shown according to UTC.

Time Nick Message
00:03 mfontani sri: https://gist.github.com/mfontani/2ec76fc511b868313be44a6f4e405b73 there was one missing pod entry needing updated, AFAICT
01:35 klapperl_ joined #mojo
03:52 dantti_laptop|2 joined #mojo
05:04 dboehmer joined #mojo
06:10 Ya_ALLAH_Ya_Muhmd_ joined #mojo
06:10 Ya_ALLAH_Ya_Muhmd_ left #mojo
06:30 Vandal joined #mojo
06:36 inokenty-w joined #mojo
06:47 zivester joined #mojo
06:49 dod joined #mojo
07:00 dod1 joined #mojo
07:05 dod joined #mojo
07:12 dod joined #mojo
07:14 cng2 joined #mojo
07:34 Ya_ALLAH_Ya_Muhmd joined #mojo
07:34 Ya_ALLAH_Ya_Muhmd left #mojo
07:40 McA joined #mojo
07:45 AndrewIsh joined #mojo
08:18 karjala_ joined #mojo
08:26 trone joined #mojo
08:46 kes joined #mojo
08:53 mib_azsko7 joined #mojo
09:16 reetp joined #mojo
09:18 reetspetit joined #mojo
09:48 McA Can someone give me a hint / explanation why logging in Mojo::Log is done via emitting an event and selfconsuming this event in contrast to just appending the logline to the handle? I'm really interested in the why of this indirection.
09:50 batman McA: on usecase could be that you subscribe to the event and pass it over a websocket to the web browser to see the log messages in the dev console.
09:50 batman i think there's even a plugin for that...
09:51 McA @batman: Thank you
10:03 zakame joined #mojo
10:13 good_news_everyon joined #mojo
10:13 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vNlZL
10:13 good_news_everyon mojo/master dde6b9e Sebastian Riedel: fix typo in documentation
10:13 good_news_everyon left #mojo
10:54 tchaves joined #mojo
11:37 marty joined #mojo
11:38 dantti_laptop joined #mojo
12:09 dantti_laptop|2 joined #mojo
12:14 markong joined #mojo
12:28 anon joined #mojo
12:29 dantti_laptop joined #mojo
12:36 dantti_laptop|2 joined #mojo
12:43 sri coolo: https://i.redd.it/iwl7vz69cea01.gif
12:45 coolo yeah, good entrance point!
12:55 dantti_laptop|2 joined #mojo
14:00 jnbek joined #mojo
14:06 jnbek joined #mojo
14:08 jnbek joined #mojo
14:15 jnbek joined #mojo
14:31 dylan joined #mojo
14:34 gryphon joined #mojo
14:39 marty joined #mojo
15:16 jberger Tulips gonna tulip
15:16 jberger so to McA's question, I've been thinking about a per-controller logger plugin/helper
15:18 McA @jberger: Is this a usecase you have in mind? Or something you did before?
15:18 jberger wherein you would get a $c->log helper and it would make a new instance of the logger class (or more likely a subclass) that's self-subscribed handler for the emit event would log to the app logger
15:18 jberger but would also be able to contain data and a serialization mechanism
15:18 jberger so closer to a contextual logger
15:18 jberger but still log via the global logger
15:19 jberger McA, I've used the message log event many times, tying in other log systems mostly
15:19 jberger syslog and some others
15:20 McA @jberger: as a secondary sink?
15:20 jberger yeah
15:20 McA ok
15:20 McA I have to wrap my mind arount the Mojo::EventEmitter class.
15:23 sri jberger: i think loggers are a bad example for per controller customizations
15:23 sri i mean, traditionally loggers are singletons
15:32 dylan joined #mojo
15:34 sh14 joined #mojo
15:42 geospeck joined #mojo
15:43 mishanti1 I'm looking at a particular mojolicious-plugin (not core) and seeing some circular references. What is this crowds favorite pattern to avoid that kind of situation? Any particular pattern chosen for modules in mojo core?
15:45 mishanti1 I see I might have formulated that a bit inaccurate. What I am seeing is Module A 'use'-ing Module B 'use'-ing Module A.
15:46 sri circular use can often be resolved with require
15:46 sri we had that with Mojo::Base and Mojo::Util
15:47 mishanti1 sri: Thanks :) Looking at that now.
15:48 mishanti1 So in which cases does require not work? When using the Export and such?
15:49 Seth joined #mojo
15:49 Seth1 joined #mojo
15:57 jberger sri: right traditionally they are singltons, but because of nonblocking and thus not being able to localize, I would like some other way to make a contextual logger
15:57 jberger and it would still feed the app-global logger, but just be able to contain per-request context too
15:57 jberger it is still just an idea that is floating around in my head
15:58 jberger but the problem isn't abstract, it is a real thing that we've been trying to work around in several ways in our $work codebase
16:21 jberger btw https://rt.cpan.org/Ticket/Display.html?id=124101&results=33514e75a89938a5e92a49cb34f7c0be
16:27 q_gone joined #mojo
16:28 q_gone joined #mojo
16:30 sri ah, you want a unique request id in the log output
16:30 sri yea, that is something i wanted for some time too
16:31 sri not sure that should happen with localized loggers though
16:31 sri would be nice if Mojo::Log methods just accepted a unique id argument
16:32 sri like an optional context identifier
16:32 sri that would actually help me at work
16:32 mishanti1 super-useful when you've got cross-system request identifiers you'd like to pass along.
16:32 sri i've been meaning to make debugging one of the bigger apps there easier
16:33 sri yea, we could go as far as making it a Mojo::Message attribute generated for every request
16:34 sri and pas it around in the right places to app->log->debug and friends
16:36 jberger sri: we usually have several ids but I guess just a unique one per-request would be enough to disambiguate and keep a global hash of contexts
16:37 sri i also think we should adopt *_p naming for all promise returning methods
16:37 sri as a convention
16:38 jberger usually things like userid, serverid, sometimes a jobid
16:38 sri looking at recent Mojo::RabbitMQ::Client changes it can be rather confusing to only have some methods with _p and some without https://github.com/inway/mojo-rabbitmq-client/commit/6989597c8f057cdde9ffdc983c900bd4d1937fc0
16:38 jberger I have no problem with that convention
16:38 sri jberger: i mean, you could change the unique id attribute and append more values
16:39 jberger true, if it is just a string, it could be a long semi-colon separated string
16:39 sri $requestid:$server_id:$job_id
16:39 sri yea, it would be an arbitrary string
16:40 sri although, encouraged to be numeric or hex checksum with : separators i suppose
16:41 sri hard part is adding it without breaking stuff
16:41 sri like, how would you even add it to the message event
16:41 sri bummer we didn't think of it earlier
16:42 jberger so this is why I was thinking of doing it as a per-request logger instance
16:42 sri [localtime] [debug] [123456] Some message
16:42 sri that would have been a better default
16:42 jberger that feeds to the global instance
16:42 sri jberger: but that is a horrible design imo
16:42 jberger but can hold a context
16:42 sri you'd only do that to avoid breakage
16:43 sri per request logger would never go into mojo core
16:43 jberger no, this would be a plugin
16:43 jberger honestly I hadn't even considered something for core
16:44 jberger that is an interesting idea
16:44 jberger how to do it in a core-friendly way
16:45 sri i think rails has unique request ids
16:47 sri another point is how to actually generate a reasonably safe unique id
16:48 sri mango actually had something for that https://github.com/kraih/mango/blob/master/lib/Mango/BSON/ObjectID.pm#L34
16:48 jberger from my perspective the id only has to be unique per-process, so a counter would be fine
16:48 jberger but I'm assuming that other people would want something more globally unique
16:48 sri multiple workers logging to the same file
16:49 jberger right, I'm thinking of using this as an index into a hash of data per-process
16:49 jberger so I don't need it, but as I say, others will
16:51 mohawk sri, starting point for unique request id: MAC address, port, pid, per-process-incrementing-id?
16:51 sri mohawk: and reasonably good performance
16:51 sri and portability :p
16:51 mohawk portability the above has
16:51 sri how do you portably get the mac address?
16:51 mohawk (also need process start-time in case a new process starts with same pid as a previous instantiation)
16:52 mohawk great question! no idea
16:52 mohawk want me to google it for you? :-)
16:52 sri you stated it was portable!
16:52 mohawk it's portable once you have that info
16:52 sri -.-
16:52 * sri sets mohawk on fire
16:54 sri also there is not always a port
16:55 jberger UUID is too slow
16:55 jberger right?
16:55 mohawk https://metacpan.org/pod/Net::Address::Ethernet is a contender
16:55 mohawk only one test result on windows, a fail
16:57 mohawk dear god, it uses M::I
16:59 mohawk worked on my win32 5.20 just now
17:01 mohawk great, looks like the wrong version number as well
17:01 mohawk RT time
17:04 mohawk anyway, the above works on linux and windows
17:04 mohawk https://rt.cpan.org/Ticket/Display.html?id=124102
17:12 mohawk sri, the port is probably unnecessary with pid, unique-machine-id-maybe-mac, start-time
17:12 mohawk (and request-inc-id)
17:13 gizmomathboy joined #mojo
17:18 jberger also it would probably have to be the hash of those things for security sake
17:18 mohawk doubtless
17:18 mohawk but that's the basis
17:44 gizmomathboy joined #mojo
17:45 sh14 joined #mojo
17:58 ChmEarl joined #mojo
18:08 trone joined #mojo
19:17 gordonfish joined #mojo
19:50 Repaster joined #mojo
20:14 seba joined #mojo
20:19 seba @mishantil Hi, I'm here as promised if you have any questions regarding Mojo::RabbitMQ:Client
20:27 mishanti1 seba: Hi there! Thanks for coming, and sorry for my late reply. Got stuck in work.
20:28 mishanti1 First of all I must say I'm liking the direction Mojo::RabbitMQ::Client is taking.
20:28 mishanti1 What I and some others wonder about is first of all what you would like help with, and which things you are already working on.
20:29 mishanti1 As an example, I know that there are certain api-specific decisions that are being contemplated, but I have not seen any specifics on what kind on structure you'd like for the module going forward.
20:31 seba Well, honestly all of my current WIP commits got pushed earlier today, so not much active work is being done
20:32 seba I've started to think about whole api redesign for v1.0 with use of Mojo::Promise
20:34 seba you can see some basic ideas in t/publisher.t test
20:34 tyldis Makes sense. I doubt breaking the API will affect many people. The implementation was very opiniated to your specific needs
20:35 tyldis Some of us want to contribute :)
20:35 mishanti1 *looking at todays commits*
20:39 seba tyldis: glad to hear that
20:39 mishanti1 Definitly heading in a good directiong.
20:39 mishanti1 s/iong/ion/
20:39 seba current api was directly inherited from AnyEvent::RabbitMQ
20:40 seba and it could use some portion of fresh technologies ;)
20:41 seba what I've made was to made it work with Mojo, and it works for me, has some flaws but since it worked almost nothing was changed
20:44 mishanti1 Ok, so one specific question: Consumer->start() and Publisher->publish() both do a lot of things. Is this by (recent-ish) design or is there a plan to split it up a bit?
20:51 seba about consumer start, it was most common use case for me - and as you can see in #12 now I believe binding should be removed from there
20:51 seba consumer should only setup a channel, qos & subscribe to messages
20:52 seba all other setup code should not be executed
20:53 mishanti1 I agree. What is your take on when the publisher is doing then. ANything you've identified there that might warrant some attention?
20:54 seba about Publisher, I think there's nothing to be cut from there
20:54 mishanti1 Ok. :)
20:57 seba you can see this new design principle in todays publisher.t, setup code with promises looks now clear, no callback hell ;)
21:00 stokachu joined #mojo
21:06 seba and about redesign, as tyldis pointed only other user of this module that I'm aware of is/was OpenQA from SUSE, so introducing totally new API with 1.0 should not be a big problem
21:07 mishanti1 That is definitly good to know.
21:07 sri seba: breakage would affect this rather big project https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Plugin/AMQP.pm
21:07 sri it's not a great plugin, but changes would be a little painful
21:08 sri ah, you noticed
21:10 seba I've noticed that they referenced this module somewhere, got no clue what it does there
21:11 seba currently, if we use _p suffix for new promise based methods there really isn't that much changes - for now ;)
21:12 sri use the _p suffix for all promise generating methods
21:12 sri it's now the mojo convention
21:13 seba suits me too
21:14 sri coolo: bitcoin seems to be crashing again :)
21:14 tyldis Pfft, it will just bounce back higher
21:14 tyldis Like last "crash"
21:15 sri i think bitcoin is finally over, nobody accepts it for payment anymore and transaction costs are skyrocketing
21:16 tyldis I "invested" in Ethereum, but sadly it keeps following bitcoin fluctuations
21:23 mishanti1 seba: I believe a colleague will create a PR for #12. I'll be playing around with the Publisher some more. See if I spot anything that I believe deserves some attention.
21:26 mishanti1 seba: Do you have any thoughts on when you'd like to release 0.1.0? And if there are additional stuff you'd like to see make it into 0.1.0?
21:37 seba mishantil: as for now, after introducing promise based api current documentation is somehow obsolete
21:39 tyldis Might quickly be parallel efforts here, everyone must remember to open a WIP PR early :)
21:39 mishanti1 Absolutely.
21:39 purl Oh my, yes.
21:48 mishanti1 seba: Will you be dropping by here from time to time, or would you prefer discussions in issues / PR's?
21:52 seba mishantil: I'll try to be available here more often
21:52 mishanti1 seba: Great. :) Don't feel like it is an obligation though.
21:53 seba just opened #18 regarding docs update, so with #12 those are only two issues I want to close for 0.1.0
21:54 mishanti1 Excellent.
21:54 seba sri: what about your issues with heartbeats in #11?
22:05 seba mishanti1: one last thought if your colleague plans to work on consumer in #12 maybe he'll implement it in similar way publisher is currently implemented - using new promise methods?
22:06 mishanti1 seba: I'll definitly forward that thought.
22:06 mishanti1 The codebase _should_ remain coherent and adhere to roughly the same design principles.
22:20 sri seba: had no opportunity to check yet
22:20 seba ok, I'll leave this issue open then
22:24 sri bitcoin keeps crashing
22:34 mishanti1 seba: Thank you for taking the time to be here today. Much appreciated. :) We'll probably talk again soonish.
22:37 seba no problem, I'm grateful that you want to support development of this module
22:41 marty joined #mojo
22:50 mib_ncc7dg joined #mojo
23:02 mib_uskx6m joined #mojo
23:08 Ralesk joined #mojo

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