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

IRC log for #mojo, 2018-01-18

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

All times shown according to UTC.

Time Nick Message
00:10 purl joined #mojo
00:51 mattp <jberger> I'll read the log later, I'm so upset I'm shaking, literallly
00:51 mattp might want to relax there friend
00:51 preaction when has saying "relax" to anyone ever worked?
00:53 Grinnz you might not be aware, but that comment mostly just comes off as dickish
00:54 aborazmeh joined #mojo
00:55 mattp my point is you dont have to get heated about perl 6 trying to make perl 5 irrelevant, because it is infinitesimally more irrelevant
00:55 Grinnz if that were true, there wouldn't be confusion about the name
00:56 mattp the damage is long done, and that ship has long sailed
00:56 Grinnz unfortunately its name is the most relevant part, and it's the detrimental part
00:56 Grinnz it has not, the damage continues
00:56 preaction i can absolutely be annoyed that a call for the two communities to work together is instead being expressed as "Perl 5 needs to make Perl 6 better"
00:57 mattp preaction: sure
00:58 mattp I guess my point was at this point p6 is so inconsequential it will not matter either way, not that you should or not be upset by it
01:00 preaction i mean, that's external. and you're right, it doesn't matter. but internally, we can be more helpful and better to each other. but not like this we can't
01:03 mattp maybe they should just pick a new name in secret, and pop the repos one day, erasing all evidence of perl
01:04 mattp then post on HN. it would probably have a better chance of doing something
01:04 mattp anyway :)
01:04 Grinnz mattp: that was my secret hope.
01:05 Grinnz if they did it right, it would do better than perl 6's launch ever did. but they haven't demonstrated much appetite for that kind of marketing
01:36 gizmomathboy joined #mojo
01:47 zakame joined #mojo
02:02 sprog joined #mojo
02:27 karjala_ joined #mojo
02:56 jberger mattp it wasn't just the p6 situation, it was liz's flagrant disregard
03:01 mohawk she seems to be openly saying that her previously espoused position was not honestly believed, but was espoused for temporary advantage
03:01 mohawk that looks cynical, and not very honest
03:05 mohawk she also seems to be trying to treat "perl5's only way forward is running on a rakudo vm" as simply, unquestionably factual, and using that as the premise for her "modest proposal" of "porting" perl modules to rakudo
03:06 mattp Meanwhile help us show that Perl 5 isn't dead; the easiest way to do so would be blessing a release of Perl 5 called say Perl 7 or Perl 28 or some other name that ends the confusion
03:06 mattp that would be quite the troll
03:08 mohawk ah, there's no desire there at all to help perl5
03:08 mohawk after all, the runtime's "reached its end of life" (simple assertion as fact without evidence)
03:09 mohawk i think i need to sign up to reddit to make these points
03:19 mohawk which also lets me +1 jberger's very well-expressed thoughts
03:19 jberger I'm considering a full blog post
03:19 jberger I'm trying to get ideas together in a salient way
03:23 mohawk i think a full blog post would be a good idea
03:24 mohawk especially since that would force one to maximise the light:heat ratio
03:24 Grinnz it might be a good idea to let something like that stew for a day, too
03:25 Grinnz so it's not too rash
03:30 mohawk that was a thought i had too
03:31 mattp i still say its largely irrelevant regardless of action or inaction
03:31 mattp the damage to perl 5 was done years ago; shes not wrong that p5p should stop attempting to do anything but port
03:34 Grinnz that seems defeatist as well as naive; perl 5 still works fine for everyone that's still here
03:34 mohawk PHP7 says you're wrong, mattp ;-)
03:35 Grinnz and just because damage was done back then doesn't mean the situation isn't still damaging
03:36 mohawk yes
03:36 mohawk "oh, the ship has sailed, so dry your eyes and do what we tell you"
04:15 mtj joined #mojo
05:04 dboehmer joined #mojo
05:36 inokenty-w joined #mojo
05:38 zakame joined #mojo
05:39 anon_ joined #mojo
06:22 Vandal joined #mojo
06:33 dod joined #mojo
06:39 dod joined #mojo
07:10 tyldis I am missing something basic. I have an object [A], which is an eventemitter. Then I have another object [B] that subscribes to events from A. Now, B is a client handler, so I have many of those and they are transient. But when they end, the subscrition is still present on A. So it leaks.
07:11 tyldis I'm not able to find a sane way to unsubscribe from the perspective of B
07:11 tyldis And for A, I find no easy way to determine which instance of B is subscribed, and if it is still alive.
07:39 AndrewIsh joined #mojo
07:47 Grinnz "when they end" would be the time to unsubscribe it, no?
07:52 tyldis Yes, but that call is on A, not from B
07:52 tyldis This is my missing link
07:54 Grinnz B would need to hold onto the subs it needs to unsubscribe
08:01 plicease joined #mojo
08:01 Ralesk joined #mojo
08:01 mdom joined #mojo
08:01 Zx3 joined #mojo
08:01 romel joined #mojo
08:01 augensalat joined #mojo
08:01 q_gone joined #mojo
08:01 exp-innit joined #mojo
08:01 pink_mist joined #mojo
08:01 esh joined #mojo
08:01 dotan_convos joined #mojo
08:01 chandwki joined #mojo
08:01 Kundun joined #mojo
08:01 haarg joined #mojo
08:01 S joined #mojo
08:01 robinsmidsrod joined #mojo
08:01 stokachu joined #mojo
08:01 dboehmer joined #mojo
08:01 cosimo joined #mojo
08:01 mgrimes joined #mojo
08:01 alilles joined #mojo
08:01 iamb joined #mojo
08:01 genio joined #mojo
08:01 [0xAF] joined #mojo
08:01 sivoais joined #mojo
08:01 schelcj joined #mojo
08:01 AndrewIsh joined #mojo
08:01 dylan joined #mojo
08:01 da5id joined #mojo
08:01 charsbar joined #mojo
08:02 preaction joined #mojo
08:02 cng joined #mojo
08:02 Xyem joined #mojo
08:02 Eke joined #mojo
08:02 oalders joined #mojo
08:02 suede joined #mojo
08:03 ccakes joined #mojo
08:03 Bender joined #mojo
08:03 McA joined #mojo
08:03 vicash joined #mojo
08:03 jabberwok joined #mojo
08:05 tianon joined #mojo
08:08 bc547 joined #mojo
08:11 gordonfish joined #mojo
08:14 tyldis I'll play around with it some more
08:24 trone joined #mojo
09:07 Edward joined #mojo
09:14 sri tyldis: or if B just "ends", you cound unsubscribe all
09:15 kes joined #mojo
09:15 sri s/n/l/
09:16 tyldis There might be many instances. But looking at the tests in mojo, I should be able to store the return from the subscription and use that for unsub when ending B. Back in the office soon to try it out.
09:17 tyldis The mojo tests are a great source of enlightenment.
09:20 seba left #mojo
09:22 dod joined #mojo
09:24 sri $b->unsubscribe('foo') is possible
09:25 sri just removes all
09:35 ghenry joined #mojo
09:59 seba joined #mojo
10:14 markong joined #mojo
10:14 tyldis Yay, I had a typo :)
10:15 tyldis my $id = $t->on(poke => sub { say "Poke detected" }); ... $t->unsubscribe( poke => $id); # works like a charm.
10:34 sri i didn't realize how close to my ideal exception system Syntax::Keyword::Try already is :o
10:34 sri https://rt.cpan.org/Ticket/Display.html?id=123918#txn-1766403
10:34 sri it's so cool that it propagates unhandled exceptions to the outside context
10:35 sri with a smarter catch it would be almost perfect
10:47 coolo joined #mojo
11:06 karjala_ joined #mojo
11:06 tchaves joined #mojo
11:07 aborazmeh joined #mojo
11:23 Ricaz Using $app->session('key' => 'value') just sets the $app->cookie('mojolicious'), right?
11:35 Ricaz How am I supposed to set cookie domain, expiration, and name on my $app?
11:40 sri $c, not $app
11:41 sri http://mojolicious.org/perldoc/Mojolicious#sessions
11:41 sri http://mojolicious.org/perldoc/Mojolicious/Sessions#cookie_domain
11:55 Ricaz sri oh, I was setting it from a controller, thanks. So Mojo serializes my hash as json, then encodes it to base64, then adds a checksum based on a secret, then puts it in 'value=' of the cookie?
11:55 sri http://mojolicious.org/perldoc/Mojolicious/Guides/Growing#Sessions
11:56 Ricaz Damn, thanks. Had trouble finding any documentation
12:31 marcus What happened with the new UV Reactor btw, was that abandoned?
12:31 marcus (Just saw there was a new libuv release which reminded me).
12:34 Ricaz sri, that doesn't add up.. The cookie will look like: my $encoded = base64(json($session)); my $checksum = hmac-sha1($encoded); my $cookie = "$encoded--$checksum";  right??
12:40 marty joined #mojo
12:47 seba sri: do you think should it be possible that Mojo::Promise->then->wait to pass return value of last ->then sub?
12:48 sri seba: why?
12:48 sri when would ->wait ever be called by something in the middle of the promise chain? that doesn't appear to make sense
12:49 seba IMHO ease-of-use: my $channel = Mojo::RabbitMQ::Client->new(url => $url)->connect_p->then(sub { shift->acquire_channel_p() })->wait;
12:49 seba not in the middle, at the end
12:49 sri if it's at the end there is no need to have a return value
12:49 seba acquire_channel_p returns a promise which in turn returns a channel instance
12:50 sri promises have no return value
12:50 sri they have arguments passed to then handlers
12:51 bpmedley joined #mojo
12:51 sri you may be misusing ->wait
12:51 sri it's a portability helper only
12:51 seba possibly
12:52 sri in an already running event loop ->wait does absolutely nothing
12:54 seba I know, but currently I'm trying to simulate synchronous behavior with ->wait
12:54 seba I'll try to post this test I'm working on soon, so you'll what I mean...
12:54 sri that's not what it is for i'm afraid
12:55 sri only way to simulate a blocking API is how Mojo::UserAgent does it
12:55 sri https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L55-L64
12:56 sri there is no easy way
13:02 sri btw. do we have any ideas for possible GSoC projects?
13:03 sri i could mentor them through the openSUSE org
13:11 noganex joined #mojo
13:33 sri documentation is of course always a good task, we have many open issues for that
13:33 Ricaz Can I have two seperate session cookies? One using cookie_name 'mojolicious' and one with '$app->moniker' for example?
13:33 sri one that came up in #mojo-core was a plugin that collects request statistics in shared memory, think we talked about that a few months ago here too
13:34 jberger Ricaz you can have as many cookies as you want, I'm not sure if you can make the mojo session handler handle both of them though
13:35 jberger if you need, you could use Mojo::JWT to make the other(s)
13:35 jberger it does basically the same thing
13:35 Ricaz jberger, that was my question
13:49 xdg joined #mojo
14:20 maschine joined #mojo
14:28 gizmomathboy joined #mojo
14:38 marty joined #mojo
14:45 mib_zt54nm joined #mojo
15:21 noganex_ joined #mojo
15:49 hkclark joined #mojo
15:53 ChmEarl joined #mojo
16:07 Pyritic joined #mojo
16:29 tchaves joined #mojo
16:51 tchaves joined #mojo
17:02 Grinnz marcus: not abandoned, but genio is still working on less segfaulting
17:16 jamesaxl joined #mojo
17:21 sh14 joined #mojo
17:55 dod joined #mojo
18:31 marty joined #mojo
18:33 noganex joined #mojo
19:15 Seth joined #mojo
19:16 noganex joined #mojo
19:17 Seth1 joined #mojo
19:35 jamesaxl how can I optimize mojolicious? I have request with timeout for every second, and I have more than 100 users
19:35 mohawk profile
19:36 Grinnz can you reword "I have request with timeout for every second"?
19:37 jamesaxl Grinnz: I am using mojo (resful API), and I have an other desktop application that send request every second to server, and the number of people are more than 100 usres
19:38 jamesaxl s/usres/users
19:38 Grinnz so basically you have more than 100 clients each sending a request every second?
19:39 Grinnz how to optimize it will depend a lot on what specifically you're doing in response to each request
19:39 jamesaxl Grinnz: yes exactly
19:40 Grinnz if you're doing HTTP requests, or slow database requests, running them asynchronously may help
19:41 Grinnz however this is not a simple change, you have to change the flow of the response handler to work that way
19:41 Grinnz it could be a simple change if async/await became core ;)
19:42 jamesaxl Grinnz: thank you for this idea. And how about hypnotoad workers?
19:42 sri with 100 concurrent users async might overload your database
19:42 Grinnz true
19:42 Grinnz you can scale up the number of hypnotoad workers and see if it helps
19:43 Grinnz more workers also means more database connections too of course
19:43 jamesaxl Grinnz: it is a problem too :)
19:43 jamesaxl sri: what is your idea?
19:43 mohawk https://metacpan.org/pod/Devel::NYTProf
19:44 Grinnz there's nothing really specific to recommend without knowing what the slow part of your responses are
19:45 sri jamesaxl: i can't give advice until you identify the bottleneck
19:45 jamesaxl feel that the desktop application works very slow, When a lot people connect.
19:46 jamesaxl And I Think also, I did mistake when I make an API do a lot of works
19:48 sri that's a symptom, not the bottleneck
19:48 jamesaxl It is for a call-center, so it controls status of agents. t generates reports for teams coach. and it does RealTime to show what every person does with his/her phone
19:51 jamesaxl Grinnz: I really want to add workers in hypnotoad, but I have agents status that calculate time of every agent, so if I use ten workers, one second will be ten seconds
19:51 mohawk jamesaxl, you can help identify bottlenecks using the profiler i linked above
19:51 Grinnz ... what?
19:52 Grinnz jamesaxl: that sounds like you are doing something in the worker that would be better done externally, so that you can scale up the number of workers without affecting that
19:52 Grinnz jamesaxl: you can communicate with other processes from the workers via pubsub, through pg or redis or mercury
19:53 Grinnz or among the workers themselves
19:54 jamesaxl mohawk: thank you for your links, I am going to try it also
19:54 jamesaxl Grinnz: Good info thanks
19:54 mohawk i've found it a very quick, easy tool to use
19:54 mohawk let us know how you get on :-)
19:55 jamesaxl I will combine all these ideas and see :)
22:02 Seth joined #mojo
22:45 gryphon joined #mojo
23:02 Seth joined #mojo
23:03 Seth joined #mojo
23:11 preaction joined #mojo

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