»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: irc.perl6.org or colabti.org/irclogger/irclogger_log/perl6 | UTF-8 is our friend! 🦋
Set by Zoffix on 25 July 2018.
timotimo anyone else seeing rather an increase in mail spam volume since about yesterday? 00:03
geekosaur I've been seeing it for several weeks 00:18
SmokeMachine Is there a way to a Seq inform to a `race` or `hyper` method what is the best batch size to be used? 01:36
timotimo the seq could implement its own race or hyper method that has different defaults for example 01:41
SmokeMachine timotimo: yes, that solves the problem, thanks! 02:13
andrzejek araraloren: hi 07:56
andrzejek araraloren: nicht da 08:34
jmerelo releasable6: status 10:24
releasable6 jmerelo, Next release will happen when it's ready. 3 blockers. 447 out of 449 commits logged
jmerelo, Details: gist.github.com/2da3dba3caaa6841d7...a417b4479a
jmerelo So, no release yet, right? 10:31
AlexDaniel jmerelo: yeah, not yet 10:42
jmerelo: but I'm pretty sure it'll happen next week 10:43
jmerelo: btw I made this list: github.com/perl6-community-modules...aster/wiki
jmerelo AlexDaniel++ 10:44
AlexDaniel jmerelo: and today I toasted things once again, and it seems like there are some modules failing that were previously hidden because of native deps
jmerelo AlexDaniel: great. So you install everything before toasting...
AlexDaniel yeah
jmerelo AlexDaniel: I still think there's an error that is similar to the intermitent error we get in perl6/doc travis 10:45
AlexDaniel: I don't remember where I told zoffix about it, it wasn't an issue. Anyway, I think it's related to the number of compunits open or something like that.
jmerelo AlexDaniel: you see, for instance, here: toast.perl6.party/module?module=DB...4-g66aa689 10:46
jmerelo AlexDaniel: it's this same error travis-ci.org/perl6/doc/jobs/415536136 10:47
jmerelo AlexDaniel: which modules are failing? 10:53
lizmat weekly: perlhacks.com/2018/08/the-perl-con...n-glasgow/ 11:03
notable6 lizmat, Noted!
lizmat weekly: perlmonks.org/?node_id=1220578 11:16
notable6 lizmat, Noted!
lizmat afk for some sighhtseeing& 11:17
jmerelo lizmat: you do that. Have fun!
masak what's the significant difference in Perl 6 between CATCH and CONTROL, and between exceptions and control exceptions? 18:22
timotimo control exceptions are normally resumed i guess?
masak oh, there's a difference in semantics? interesting. 18:23
timotimo m: CONTROL { .say; say "controlled" }; say "hi"; warn "oh my"; say "bye"; warn "oh see ya"
camelia hi
oh my
MoarVM panic: Trying to unwind over wrong handler
timotimo hah
timotimo m: sub it { CONTROL { .say; say "controlled" }; say "hi"; warn "oh my"; say "bye"; warn "oh see ya" }; it 18:23
camelia hi
oh my
MoarVM panic: Trying to unwind over wrong handler
masak that went well :P
timotimo yeah, not really 18:23
masak besides, I can't really think of a control exception that's resumed 18:30
masak if `next` and `last` are governed by control exceptions, it doesn't seem to me they are resumed 18:30
today I got the crazy idea (for 007) that dynamic variables could be implemented using control exceptions :)
timotimo mhh, i can imagine how that might work 18:33
you throw the name of the variable and the first frame that "defines" it will catch, set the value to a container that was passed along, and resumes
stmuk OpenSSL is broken on some non-linux systems (OS X and OpenBSD) :-( 18:36
masak it's like you're reading my mind :)
timotimo well, you've done all the thinking to pinpoint the idea, and then boiled it down to the key insight that would probably lead anyone to the same conclusion :) 18:41
jnthn masak: `take` and `emit` and `warn` are all examples of resumable control exceptions 18:44
jnthn masak: The main reason CATCH doesn't catch control exceptions is because it'd be really awkward for the language user. There's nothing deeply different about control exceptions - the resolution machinery is the very same - it's just valuable to keep them distinct at the language level. 18:46
You could in theory do dynamic variables with the exception system, but not all pretty unifications are performant unifications. :) 18:47
timotimo does the profiler work fine on a rakudo with all the specified revisions? 18:58
robertle can I check my understanding of Supplies? does the tap() block get executed by the thread that does the emit()? if I want multiple worker threads, I would have to do a start { ... } within the tap block? 19:38
timotimo there's also a .start method on Supplies; it results in a supply of supplies that emit the single result value from the promise, though 19:41
masak jnthn: thank you for the explanation about user-level distinction. that's what I was looking for (and where I will continue my train of thought) 19:44
jnthn: also, noted about pretty unifications ;)
robertle hmm, my problem is that I have a single thread that creates events (async I/O), but many supplies (e.g. one per socket). I want to do stuff in parallel, but I do not want to execute two items from the same supply in parallel because then they could get reordered. currently I have a tap( ->$i { $!lock.lock; start { .... $!lock.unlock; } } ) 19:45
this does what I want I think, but seems like a very C-like construct with the explicit locking and unlocking, also the fact that the lock() and unlock() happen in different threads...
there must be a cleaner way...
timotimo react blocks have "only one thread in the block at one time" semantics 19:46
they probably do what you want
so you don't have to fiddle with taps manually
robertle timotimo: ok, but is that also true if there is only one thread calling emit() on the supply?
timotimo not sure if i understand, but i think so? 19:47
robertle I will try, but I thought react is just syntactic sugar over act()
robertle well, perhaps a bit more in the sense that it could protect more than one supply 19:48
but is the general assumption for tap() and act() correct that the tap()/act() block is executed by the thread that calls emit()?
timotimo react is more than just act, it also does lots of super helpful subscription management for you 19:50
jnthn robertle: Yes, supplies are a mechanism primarily for concurrency control, not for introducing parallel processing 20:02
jnthn The $supply.Channel.Supply idiom is one way to stick a Channel in as a buffer and have events handled on another thread 20:04
robertle jnthn: ok, that matches my observations. so if I do IO::Socket::Async.listen().tap(-> $client-socket { $client-socket.Supply(:bin).tap( -> $input { handle-input($input) }) }) 20:06
then all calls to handle-input are run by the one thread dealing with async I/O, right? 20:07
jnthn robertle: No
Because it inserts the events into the ThreadPoolScheduler's input queue
So you could have different threads handling different clients concurrently there 20:08
Of course, it'll only "do one accept" at a time and process one bit of input for a given client at a time 20:09
robertle right, that would be fab. but it's not what I am seeing, let me golf this...
gist.github.com/robertlemmen/9d082...cb48f4ec8e 20:15
as I said, I have a way to work around it, but it seems ugly
jnthn robertle: You're just not doing enough work to make it need more than one thread :) 20:19
robertle I did have sleeps in there before, but I guess they do not count as work? 20:21
jnthn I stuck a sleep 0.5 in there and I see stuff like:
input, handled in thread 19
input, handled in thread 30
robertle interesting, my sleep was 0.1 and it did not trigger it! with 0.5 it does do things in parallel 20:22
where is the logic that decides when to put work on the thread pool and when to do it directly? would be very interesting to have a look... 20:24
jnthn It *never* does these directly 20:25
The event loop thread never runs user code, it only ever puts stuff into the queue 20:26
But see src/core/ThreadPoolScheduler.pm6 for the place it decides how many threads
In particular, grep for affinity-worker or some such
robertle hmm, when you run it with sleep(0.1), do you get execution on multiple threads? 20:27
jnthn No
It's a heuristic algorithm trying to start a sensible number of threads, so it's maybe that it wants a tweak in some cases 20:28
robertle ah! I looked that that a while ago!
the heuristic is largely based on cpu utilisation!
jnthn Ah :) 20:29
So sleep is a pretty poor fake after all :)
Though being tuned for real apps rather than fakery is probably sensible :)
robertle well, the reason I was remembering it is that I have apps at work that primarily shovel data around, so they do not sleep but would send onwards and wait for a response. they are not written in perl 6, but they also have the problem that they have low cpu utilistaion yet need more threads to handle the work 20:31
without blocking I/O mind you, I think it's just the task switching that kills it
robertle weirdly if i remove the sleep and run it in a tight loop, I get about 125% cpu utilisation yet still only one thread that does the work. but perhaps it is now throttled by the accept() that always happens sequentially 20:39
jnthn Well, there's an event loop thread running in the background dispatching the work too 20:41
robertle I'll play some more with it. but you must have some benchmarks or real-world apps for cro, right? can you get more than a few hundred RQ/s through it? 20:43
jnthn I've seen 700+ in the past 20:44
That's for the full HTTP/router stack
away for a bit 20:46
robertle that's cool. I don't get any more than that for a really simple case
jnthn Tested with ab also, fwiw 20:47
robertle I wish ab was able to do keepalive
Garland_g[m] Say I declare an enum Color <Red Green Blue>. I don't want "Red" to become a symbol in the current scope, but want to only be able to access it with "Color::Red" instead. Is there a way to do this? 23:31
timotimo Garland_g[m]: try this: 23:51
m: constant Color = do { enum Color <Red Green Blue>; Color }; say Color::Red
camelia Red
timotimo m: constant Color = do { enum Color <Red Green Blue>; Color }; say Red
camelia Red
timotimo oh damn
forget about this!
Garland_g[m] I tried something similar, and I was surprised that it escaped the block too. 23:53

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!