»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg camelia perl6: ... | irclog: irc.perl6.org | UTF-8 is our friend!
Set by sorear on 25 June 2013.
lue In any case, the only useful place I've seen so far is substr, where you could supply a StrLen for length or a StrPos for endpoint. But that doesn't help the integer cases of substr (you can have Int length but not Int endpoint), and (I hope) :end and :length work better anyway :) 00:01
lue o_o how old is S32::Str ‽ → " multi trans(List of Pair %data --> Any );" 00:17
"List of Pair", a.k.a. "Hash", no?
colomon they're two different things 00:18
lue well yeah, but why not just call it Hash? (esp. with the % there). Doesn't that mean Hash[Str, List[Pair]] anyway? 00:19
r: my List of Pair %h; say %h.WHAT;
camelia rakudo-parrot e9b185, rakudo-jvm e9b185, rakudo-moar e9b185: OUTPUT«===SORRY!===␤Type List cannot accept type arguments␤»
lue r: my Array of Pair %h; say %h.WHAT; 00:20
camelia rakudo-parrot e9b185, rakudo-jvm e9b185, rakudo-moar e9b185: OUTPUT«(Hash[Array[Pair]])␤»
retupmoca re: building native libraries with panda: would something like this for generating Makefiles be a good idea? github.com/retupmoca/P6-LibraryMak...ryMake.pm6 00:30
btyler is there a general preference for `my Str $foo = 'abc'` vs `my $foo of Str = 'abc'?` 02:48
moritz www.minnowboard.org/meet-minnowboard-max/ looks like the 2GB variant would be a nice, low-cost machine for smoking rakudo :-) 07:16
FROGGS_ @all, please test: froggs.de/perl6/rakudo-star-2014.03.tar.gz <-- rakudo@parrot star release candidate 07:38
FROGGS_ btyler: I prefer the former, because it is shorter and other languages I work with do it this way too 07:39
dalek ar: 499084f | (Tobias Leich)++ | tools/star/release-guide.pod:
remove note about MIME::Base64, add one about LWP::Simple
07:58
ar: dca1065 | (Tobias Leich)++ | tools/build/Makefile.in:
remove perl6-debug, it is included in rakudo now
ar: f307717 | (Tobias Leich)++ | / (3 files):
bump versions
07:59
ar: ce9dfba | (Tobias Leich)++ | docs/announce/2014.03.md:
add announcement for 2014.03
08:00
moritz FROGGS_: star RC built fine, including modules 08:01
now running module-test
dalek ar: 048af2b | (Tobias Leich)++ | modules/ (12 files):
bump submodules to latest versions

Except perl6-lwp-simple, we switch to a patched fork here.
08:02
FROGGS_ moritz++ # thank you! :o)
moritz: would be more than awesome if you could proof read the announcement 08:03
moritz FROGGS_: will do. And sorry for not merging the lwp-simple pull request earlier, I somehow lost track of it
I've done it now
FROGGS_ ahh, no problem 08:04
moritz github++ # making forking easy
FROGGS_: since there wasn't a star release in Februar, the release announcement for March could contain compilre impreovements from February 08:05
FROGGS_ I did not even know that you have push right to lwp-simple 08:06
ahh, good point!
moritz Result: PASS
FROGGS_ \o/
moritz worms his way into most p6 projects :-)
nwc10 moritz: congratulations on the new project. How is sleep?
"the sleep is a lie"? 08:07
moritz FROGGS_: also, might be worth mentioning that JVM and Moar support for star is being worked on already, and experimental support is expected for the April star release
nwc10: thanks. Sleep is LTA, but OK (at least for me; $wife and $newborn are still in the hospital, so they don't wake me right now)
nwc10 it's "close" - is it worth saying that?
FROGGS_ I changed a paragraph to: While the other backends 08:08
mostly implement the same features as the Parrot backend, some bits are
still missing that lead to module build problems or test failures.
We hope to provide a JVM-based and MoarVM-based Rakudo Star releases soon.
I add a note about our expectations :o)
dalek ar: 2228882 | (Tobias Leich)++ | docs/announce/2014.03.md:
add changes of 2014.02 and notes about r-m/j* in 2014.04
08:12
ar: 8a004b1 | (Tobias Leich)++ | tools/star/release-guide.pod:
update release peeps list
08:13
moritz FROGGS_++ # shipt it! 08:17
FROGGS_ shipt?
moritz ship 08:18
FROGGS_ I am uploading the updated tarball that contains the fixed announcement
and I am going to unpack and test again
FROGGS_ okay, new release tarball is online at froggs.de/perl6/rakudo-star-2014.03.tar.gz 08:25
I just wonder why it is 2MB smaller
jnthn FROGGS_: In github.com/rakudo/star/commit/22288827d0 it looks like you added changes in the wrong place, under the "stuff that's not quite there" heading 08:35
FROGGS_ ohh damn! 08:36
jnthn++
dalek ar: 6363be3 | (Tobias Leich)++ | docs/announce/2014.03.md:
move changes to correct section, jnthn++
08:37
nwc10 FROGGS_: if you want it even smaller, see the notes about 7-Zip etc here perl5.git.perl.org/perl.git/blob/fc...e.pod#l836
FROGGS_: aha, here's a pretty version: metacpan.org/pod/release/RJBS/perl...he-tarball 08:38
FROGGS_ nwc10: dunno if we want to provide .7z
(I don't want to upset packagers by changing that now) 08:39
nwc10 no, point is that the 7z tools make tigher gzip files
tighter
FROGGS_ aha, okay 08:39
nwc10 and, rougly, bzip2 isn't worht it any more 08:40
.gz and .xz seem to be the two with useful CPU/size trade offs
brrt why is bzip2 out of favor? 08:43
nwc10 doesn't get much better compression than gzip, but uses quite a bit more CPU
xz gets a lot better compression, for not massively more CPU than bzip2
and on modern hardware, CPU speedups outpace disk access speedups, IIRC 08:44
although SSDs might have skewed that since then
xiaomiao nwc10: xz/lzma is a bit better on decompression, but afair a bit worse on compression than bzip2 08:45
so for compress-once, uncompress-many it wins, but for compress-and-read it doesn't matter much 08:46
nwc10 thanks - I wasn't aware of that detail 08:48
moritz FROGGS_: your implementation of $*EXECUTABLE is much better than $*EXECUTABLE_NAME, but it's still dangerous 09:32
FROGGS_: it always points to the installed perl6-{m,j}, but usually you spectest *before* installing 09:33
FROGGS_ moritz: I'd love to check for the running process, but I don't know how
moritz FROGGS_: and the spectests happen to be one of the major users of $*EXECUTABLE_NAME, so probably $*EXECUTABLE soon
:( 09:34
FROGGS_ spectests and panda, yes
both very important bits
moritz pandaspec 09:38
lizmat for some reason, make t/spec/S32-io/IO-Socket-INET.t started failing for me today 09:49
am I the only one seeing that ?
jnthn lizmat: Backend? 09:50
lizmat: It was busted on r-m for a bit; HEAD r-m resolves it.
lizmat moar
will check
jnthn I hastily did some locking stuff on I/O to get sleep sort in shape for you 09:51
And unfortunately reacquired a mutex, which is a no-no with pthreads.
The whole patch has been re-done now to something more robust/complete. :)
lizmat cool 09:53
if that works, should I bump versions again?
jnthn Feel free :) 09:54
lizmat hmmm... still seeing error 09:58
s 09:59
could it be that a failed test leaves behind cruft that will make next tests fail?
jnthn maybe; I know there's a flag file
lizmat thinking about servers hanging on a port that the test uses
jnthn Also, I know there were new tests in that file of late...
..so may be worth checking it's not a new, shoulda-been-fudged one. 10:00
lizmat: BTW, how was the talk? :)
lizmat hmmm... it seems that I have 3 moar processes running each eating 100% CPU
better killl them first
jnthn om nom nom 10:01
lizmat killed, no change in tests :-( 10:02
lizmat also, without FROGGS_++ last commit, it also fails 10:06
for the record: moar on darwin
the presentation went fine (for a first real appearance), only a little over time 10:07
title: "How the camel is de-cocooning: 10:08
jnthn Yes, I liked teh title. :) 10:08
Look forward to seeing it in a few weeks time :)
lizmat # [0s] Testing on port 1024 10:09
not ok 1 - [2s] echo server and client
# got: 'echo ''Twas brillig, and the slithy toves
# Did gyre and gimble in the wabe;
# All mimsy were the borogoves,
# And the mome raths outgrabe.O frabjous day! Callooh! Callay!' received
# '
# expected: 'echo '0123456789abcdefghijklmnopqrstuvwxyz' received
huh? why am I getting Lewis Carroll on the horn here ?
hmmm.. I still have something running on port 1024? 10:11
it appaars I had at least 5 more moar processes running, one of them on port 1024 10:13
jnthn oh!
masak one of them channeling Lewis Carroll... :)
lizmat tests all ok now after killing all those moars 10:14
jnthn phew!
lizmat running full spectest now to see if that leaves behind any moar processes
lizmat aha, Ctrl-Cing out of t/spec/S32-io/IO-Socket-INET.t leaves a moar behind 10:19
I guess we cannot catch that yet, right?
lizmat anyway, once you've done that, t/spec/S32-io/IO-Socket-INET.t starts to fail 10:20
and continues to fail until you killed all the moars 10:21
lizmat feels to me that t/spec/S32-io/IO-Socket-INET.pl should have some sort of expiration feature on the server side 10:25
don't have time for that now... going to see some sights&
FROGGS_ lizmat: have fun!
jnthn Enjoy :) 10:26
FROGGS_ sometimes I *hate* windows 10:27
how can it be that windows reboots because of an update and you can only click "later" to interrupt? and then it reboots while you are fetching some lunch 10:28
nice that this happens while I prepare a star msi relase ò.ó
release*
that is win xp, mind 10:29
jnthn There are ways to disable that stuff.
FROGGS_ and I hope win7+ does not try to be smarter than me
Ven FROGGS_: win 7+ tries even harder to be smarter than you. 10:46
FROGGS_ :/ 10:47
arnsholt o/ 11:01
FROGGS_ hi araujo
err
hi arnsholt
colomon \o
FROGGS_ o/
simula67 lizmat: or this : www.dnorth.net/2012/03/17/the-port-0-trick/ 11:03
FROGGS_ that is very nice indeed! 11:05
simula67 but that will leave the server processes as zombies 11:08
dalek p/O-refactor: 7e96389 | (Arne Skjærholt)++ | src/ (2 files):
Refactor how the <O()> rule works.

Things brings us closer in line with how STD does things, and does away with the rule taking a string of colonpairs that we then dissect into the precedence information.
11:10
arnsholt jnthn: Leaving the O refactor in a branch for now. I get some terribly weird errors compiling the setting with Rakudo when I try to update that
FROGGS_ arnsholt: is there also a rakudo branch? 11:11
arnsholt Not yet 11:13
I guess I could commit what I have so far, but it doesn't actually compile, though =
s/=/=)
FROGGS_ but you replaced rakudo's init block in the grammar too?
census hi masak -- you around? 11:15
arnsholt Yeah, I've made the same kind of changes in Rakudo
But Rakudo has some more complicated things going on (related to user-defined operators, I think), which is where the breakage happens (AFAICT) 11:16
FROGGS_ ahh, I see 11:18
arnsholt The actual error I get is "Cannot assign to non-container", which is... weird 11:19
FROGGS_ not too weird when you mix nqp and rakudo 11:20
arnsholt True, true 11:21
masak census: sort of. is it #perl6-related? 11:21
census masak -- no, quick latex question i wanted to run by you, if that's ok 11:22
masak census: kind of a little busy right now. maybe try on #latex or #help-census? 11:26
kthx
FROGGS_ moritz: can you please upload froggs.de/perl6/rakudo-star-2014.03.tar.gz and froggs.de/perl6/rakudo-star-2014.03.msi ? 11:28
moritz: please download both afresh because I updated the tar.gz also
census thanks masak. yes i'm in the help-census room 11:31
no worries about it
[Coke] there was still a hang in the JVM. 12:24
yesterday's run now lost as well, today's run compromised from the old running process. 12:25
FROGGS_ [Coke]: are you able to upload stuff to rakudo.org/downloads/star/?
jnthn [Coke]: Well, it wasn't fixed until last night, so yesterdays was probably before the fix. 12:27
[Coke] jnthn: I had re-started a run yesterday after the fix. 12:32
(a full run, not just the JVM stuff, so it re-fetched git, etc.)
so I suspect there is still a hang.
jnthn [Coke]: Does it get HEAD, or the NQP_REVISION?
[Coke]: 'cus that wasn't immediately bumped... 12:33
[Coke] NQP_REVISION only.
muuuuust do the ulimit stuff...
but for now, re-starting today's run. 12:35
jnthn++
timotimo github renders the text as "@ as shortcut for @$, % as shortcut for %$ 14:32
FROGGS_ is here someone here who can upload froggs.de/perl6/rakudo-star-2014.03.tar.gz and froggs.de/perl6/rakudo-star-2014.03.msi to rakudo.org/downloads/star/? 14:35
dalek Heuristic branch merge: pushed 29 commits to nqp/r2-lex-to-local by timo 15:11
[Coke] solely from an htop monitoring standpoint, i wonder if we'd be better off setting rakudo.jvm's classpath via env var rather than as a command line arg 15:47
moritz [Coke]: that's a bit brittle, because some process might want to spawn a subprocess with a clean env 15:55
[Coke] yup. I'm just selfish and don't expect you to change. :) 15:56
also, rakudo.jvm run still reaaaaly slow. :)
moritz tries a j-spectest again 15:57
[Coke] note that I'm not using the eval server, and am doing one-at-a-time testing.
jnthn moritz: Do you ahve access to upload tarballs to rakudo.org? 15:58
moritz jnthn: yes 15:59
moritz backlogs
jnthn moritz: Could you possibly upload the ones in the backlog?
moritz: I'd do it, but unsure where my key is...
Thought it was on this machine.
moritz runs it
[X] tarball uploaded 16:00
[X] msi uploaded
jnthn: the comment in ~/.ssh/authorized_keys says [email@hidden.address]
[Coke] moritz++ jnthn++ FROGGS++
I am reminded - has anyone tried to make a rakudo.jar yet? 16:01
moritz hasn't
FROGGS[mobile] moritz++ 16:01
thank you
[Coke] wanted to have something where he could run perl6 code apps inside eclipse. 16:02
[Coke] s/code// 16:02
moritz FROGGS++ # release
timotimo \o/ 16:04
[Coke] .u ಠ 16:11
yoleaux U+0CA0 KANNADA LETTER TTHA [Lo] (ಠ)
[Coke] .u ‿ 16:14
yoleaux U+203F UNDERTIE [Pc] (‿)
[Coke] .u ʘ 16:15
yoleaux U+0298 LATIN LETTER BILABIAL CLICK [Ll] (ʘ)
[Coke] just had to implement "can" in coldfusion. whee. 16:46
(thankfully, introspection is possible, it's just verbose.) 16:47
dalek rlito: 4fdfade | (Flavio S. Glock)++ | / (3 files):
Perlito5 - js - create ''
16:56
dalek rlito: c7afb9d | (Flavio S. Glock)++ | / (3 files):
Perlito5 - syntax - allow '0'
17:06
Ven perlito's alive ? or the perl5-to-js backend is ? Seems to do a lot of things :p 17:12
:o*
Ven *before installing new rakudo-star * perl6 -v *after 5 seconds+* "2013.09" *install new rakudo star" perl6 -v "2014.03" instantly <3 17:16
moritz \o/ 17:19
arnsholt Oh. nqp/O-refactor is broken on Moar. Maybe that's the same reason it's broken on Rakudo *fingers crossed*
Ven I'm really impressed with the huge speedup :). My gameoflife actually runs at a correct pace now. (the version in another language runs at the same speed ... though it has a sleep in it :p) 17:21
arnsholt [Coke]: Ideally, I'd like both NQP and Rakudo on JVM to be shipped as a single JAR, with all the deps inside 17:26
Unfortunately, bundling JARs inside another JAR requires a certain amount of hackery to get working =/
Ven Though, I really don't know how you can get 60fps on your perl6 games when I get 1fps on my game of life ._. 17:30
moritz does building NQP and Rakudo on top of parrot only feels a lot slower than on moarvm, or is that actually the case? 17:31
Ven perl6-m (and -j) will probably be next month, right ?
I mean next rakudo star 17:32
moritz Ven: yes, though it'll be still experimental support 17:33
Ven: but the patches (or at least most of them) that are needed for star's build system are already in a branch
moritz FROGGS[mobile], jnthn: now that star is released, what about merging tristar into master? 17:33
FROGGS +1 17:34
Ven kinda wants to see the speedup improvement moar will bring
moritz Ven: you can build a rakudo-moar right now, without star 17:35
Ven Definitely, if you guys are saying it's cool 17:37
moritz it sure is
Ven tastes the water 17:38
FROGGS it is very very cool
jnthn moritz: +1
moritz: And yeah, r-m builds faster 17:39
dalek Heuristic branch merge: pushed 28 commits to star by moritz 17:41
moritz the merge conflicts were pretty trivial to resolve 17:42
arnsholt jnthn: Could you take a look at nqp/O-refactor? I'm not quite sure what's up with the compile error on Moar. Somehow the hash doesn't get flattened properly or somesuch? 17:43
FROGGS moritz++ 17:52
arnsholt: you maybe look at run() or shell() and what we needed to get ha hash without containers (if that is the problem you have, dunno) 17:53
in terms.pm or control.pm or where that is
arnsholt I'm using nqp::hash (the grammar is NQP anyways, so no containers), the old O() returned a containerless hash as well, so not sure if that's it 17:56
[Coke] (tristar merging) have to get the daily runs for that doing all three now. 18:00
though I get the feeling the release manager is not looking at the failing tests until day of.
jnthn arnsholt: What backend did it work on? 18:02
arnsholt I did my testing on JVM
jnthn Hm, I thought that had same semantics as Moar...
arnsholt Yeah
moritz [Coke]: depends on the release manager :-) 18:03
isBEKaml [Coke]: Are we really on tristar release this month? I saw only parrot from FROGGS++... 18:05
btyler isBEKaml: next month is the target, as I understand it
jnthn Well, "this month" now. It's April today :) 18:07
[Coke] are there any docs in the tristar merge that explain how to build for the various backends?
isBEKaml btyler: Ah, okay. 18:08
[Coke] I grepped around for jvm/moar in the top level and in the release guide, nothing stands out.
isBEKaml jnthn: Sure, I'm not the one picking dates for release. :-)
jnthn arnsholt: I don't see why you'd be hitting a problem. I wonder if it's a code-gen issue. 18:09
[Coke] is the star process the same, just the build of the bundle that's different? 18:09
(and at that point, just like building for a regular build?) 18:10
arnsholt jnthn: Something codegen-y with hash flattening might fit, yeah 18:11
isBEKaml [Coke]: IIUC, the makefile for star build will have a single command to build all 3 backends.
[Coke]: So, the build process remains the same except perhaps an extra step for additional backends. Though, it's really not for me to say. :-) 18:12
jnthn [Coke]: It needs doc'ing, but it takes --backends=... and should be a lot like configuring Rakudo itself. 18:13
arnsholt Huh. It's broken on Parrot as well, actually
FROGGS isBEKaml: we missed to release a tristar for march by an inch :o) 18:14
isBEKaml FROGGS: Yeah, we don't want people to take this release less seriously now, do we? :P 18:15
dalek ar: aa98b5c | coke++ | tools/star/release-guide.pod:
Fix count, add more markup
18:17
[Coke] S17-concurrency/channel.t is still apparently hanging on the jvm. 18:20
(it's using no cpu time, but not exiting)
killing it manually so we can get a run today. 18:21
jnthn [Coke]: Weird...it stopped for me after last night's NQP patch
FROGGS[mobile] the msi build might become interesting
[Coke] jnthn: Perhaps it would have eventually, but the 0 cpu utilization was suspect. 18:23
dwarring [Coke]: I just submitted RT121556 18:24
looks like the same problem
jnthn [Coke]: No, there was no delay here. 18:24
[Coke]: What revision is the n-j? 18:25
dwarring gist.github.com/dwarring/9920038 18:26
[Coke] # HEAD detached at 08e997a 18:27
jnthn [Coke]: And cf3bdf1 came after that and fixed the bug.
[Coke]: So it's just an old NQP
[Coke] jnthn: this is the build script: github.com/coke/perl6-roast-data/b...udo.jvm.sh 18:28
jnthn Oh!!
For some reason I thought an NQP_REVISION bump had been commat after my patch
But it hasn't been. 18:29
[Coke] ah, that would 'splain it.
jnthn [Coke]: Doing revision bumps.
Yeah, sorry 'bout that. Musta just misremembered what I saw going by in the commit log...
[Coke] no worries.
I will try to manually kill the hangs for today's run, we'll get a fresh one tomorrow. 18:30
jnthn++
dalek p: 46fab27 | jnthn++ | tools/build/MOAR_REVISION:
Get a Moar with various thread/locking fixes.
kudo/nom: 358582e | jnthn++ | tools/build/NQP_REVISION:
Bump to latest NQP.
18:31
[Coke] (Ծ‸ Ծ) . o O (will this $dayjob project ever end?!) 18:33
jnthn need a walk; bbiab 18:40
LLamalessRider Good job to all for the 2014.03 release! And thanks for - the "@ for @$" and "% for %$" shortcuts. 18:55
also, I apologize if this joke has already been made, but thanks for not making $ a shortcut for $$ :)
FROGGS *g* 18:59
no, there was no joke until yet 19:00
we usually do not tend to have humour :o)
moritz too many Germans around here :-) 19:01
jnthn The joke warfare left a bitter taste... :P 19:16
[Coke] wants to make a pun on spec using Kummerspeck, but feels it's a bit of a stretch. 19:21
dwarring jnthn, [Coke] my jvm hang problem has gone away after rakudo rebuild - thanks 19:24
jnthn yays 19:25
lizmat good *, #perl6! 19:29
looking at: until $server_ready_flag_fn.IO ~~ :e { sleep(0.1) }
I wonder whether it makes sense to create a dedicated Promise out of that 19:30
something like "Promise.e($path)"
jnthn lizmat: I think watching file system events is more naturally a supply... 19:31
lizmat ah, good point, a promise working on a supply ? 19:32
jnthn And then we make a way to turn any supply into a promise that completes when the supply gives its first result, for example.
lizmat but the supply would be giving *all* file system events, no? 19:34
lizmat and the promise would be kept as soon as the "created file with this path" comes down the supply ? 19:34
feels more like a tap on a supply, turned promise 19:35
jnthn Right, when you ask for such a promise, it taps the supply, keeps the promise with the first value that arrives, and then untaps.
lizmat gotcha
jnthn That's pretty much what Rx's .FirstAsync() does, fwiw. :)
lizmat except we don't have a supply for file system events (yet) 19:36
jnthn No, but I kinda want it for my reactive talks that are coming up.
So I'll probably implement it in the nearish future.
lizmat ah... presentation driven development!
jnthn ;)
lizmat the season is starting again :-)
jnthn Yeah. 3 confs coming up for me! \o/ 19:37
Hm, I should make travel plans for 'em soon too I think.
lizmat wonders whether a reduced Perl 6 (like brian d foy's R) would just be called '6' 19:38
lizmat jnthn: and in the case of Promise.e, check first if the file already exists of course, and don't bother tapping if it is there already 19:39
hmmm... no, that would probably be a race condition
jnthn yeah :)
.e usually is... :)
lizmat first tap, then check if it exists, then untap if it already exists 19:40
I also just realized that the sleep sort test in t/spec/S17-concurrency/promise.t 19:41
basically also contains a race condition on the @a.push
it will most likely never happen, but it could 19:42
so I was thinking whether to create something like an "is shared" attribute 19:43
which would turn the array basically into an endpoint of a tap
lizmat and all accesses to it as mores into the supply 19:44
all write accesses that is
jnthn Just all. 19:45
I'm not sure I like an "as shared", but it occurs to me that if we provide a monitor module and an actor module then:
vendethiel lizmat: isn't it called "nqp" ;)? 19:46
jnthn actor Wrapper { has $.wrapped handles *; }; sub actorify($wrapped) { Wrapper.new(:$wrapped) }
moritz lizmat: or just write the results to a Channel, not to an Array 19:47
lizmat moritz: perhaps 19:48
but that would probably require more typing and would thus be more work that just using @a.push
moritz not that much more work 19:49
lizmat so people would tend to do the intrinsically wrong thing in this context
it also would need a context change in the minds of people
moritz my $c = Channel.new; ... $c.send($_); ... $c.close; is ~$c.list, '0 1 2 3 '...
lizmat furthermore, simple examples for parallelising code
such as: for @foo { ... } turning into: await do for @foo { start { ... } } 19:50
lizmat would not generally work if they access variables outside of the scope, like the sleep sort test 19:50
raiph jnthn (& others thinking about concurrency in P6): i'm curious what you know about ptolemy.eecs.berkeley.edu/ or more specifically your reaction to the abstract at ptolemy.eecs.berkeley.edu/publicati.../index.htm 19:51
moritz lizmat: I can see the appeal to that, but I also think there's a danger
lizmat: a shared array would have to be protected by locks (afaict), and that implies a risk of deadlocks 19:52
so we lose on the composability front
jnthn Right. There's no free lunch here.
lizmat not if the array would in fact be an endpoint of a channel or a supply?
moritz and tracking down the deadlock if everything looks like a standard, non-concurrent variable might be much trickier 19:53
lizmat: I can't imagine how that would work; might be just my limited imagination though 19:54
lizmat all accesses (read/write) to that array, would go through a channel/supply setup 19:55
jnthn s/might/almost certainly will/. One of the things I always find myself at pains to explain when I teach stuff like the concurrent collections, say, in .Net, is that *yes* they are thread safe collection types, but you can't just program with them like you'd program with non-threadsafe ones but just taking away locks.
lizmat with commands such as GET / STORE and the like going down the channel/supply
so basically make sure all accesses are done in order 19:56
jnthn my @results = await (1..10).pick(*).map: start { sleep $_; $_ }; # Channel free, thread safe, sleep sort
raiph: I'll have to read that in some detail to have a good answer. Will put it on my to read list, if you think it's worth it :)
m: say await (1..6).pick(*).map: start { sleep $_ * 0.5; $_ }; 19:57
camelia rakudo-moar e9b185: OUTPUT«(signal ABRT)No such method 'count' for invocant of type 'Promise'␤ in method reify at src/gen/m-CORE.setting:7521␤ in method reify at src/gen/m-CORE.setting:7432␤ in method reify at src/gen/m-CORE.setting:7432␤ in method gimme at src/gen/m-COR…»
jnthn oops
m: say await (1..6).pick(*).map: { start { sleep $_ * 0.5; $_ } };
camelia rakudo-moar 358582: OUTPUT«(signal ABRT)2 1 5 4 3 6␤»
jnthn oh lol
duh :) 19:58
jnthn stops trying to do 5 things at once :)
moritz wonders if say race (1..6).pick(*).map: { sleep $_; $_ } ; will eventually work 20:00
jnthn It may but it depends on granularity 20:01
vendethiel moritz: isn't that what's it doing right now ? 20:01
"just compute and return it whatever is the order"?
jnthn notes that a Promise.race($p1, $p2, ...) would be useful 20:02
vendethiel Allow promises to be passed to race ? `race ($p1, $p2)` ? Looks more composable 20:02
jnthn race is a modifier on a lazy list, like eager/hyper/lazy 20:03
moritz +1 to Promise.race 20:04
vendethiel then +1 to Promise.race too :-)
lizmat maybe "await" should return the promises in the order they were kept ?
moritz lizmat: I think that's not usually a good idea
vendethiel lizmat: that's what it looks to me, compared to hyper/race (?)
jnthn lizmat: I've had other use cases where I cared for the order. 20:05
lizmat mayby await would return in order of given promises, and queue(@p) would return in order of kept ? 20:06
timotimo r: class Foo { has $.name }; my $f = Foo.new(name => "hey there how are you"); say $f ~~ name => /hey/;
vendethiel wonders if actually having `eager (1..6).pick(*).map: { start { sleep $_ * 0.5; $_ } }` would look better
camelia rakudo-moar 358582: OUTPUT«Cannot call 'match'; none of these signatures match:␤:(Cool:D: Any $target, *%adverbs)␤ in method match at src/gen/m-CORE.setting:3568␤ in method Bool at src/gen/m-CORE.setting:12874␤ in method Bool at src/gen/m-CORE.setting:829␤ in method AC…» 20:06
..rakudo-jvm 358582: OUTPUT«(timeout)»
..rakudo-parrot 358582: OUTPUT«Cannot call 'match'; none of these signatures match:␤:(Cool:D: Any $target, *%adverbs)␤ in any at gen/parrot/BOOTSTRAP.nqp:1219␤ in any at gen/parrot/BOOTSTRAP.nqp:1210␤ in method match at gen/parrot/CORE.setting:3572␤ in method Bool at g…»
timotimo oh, that's not how that works :(
vendethiel m: say await (1..6).map: { start { sleep $_ * 0.5; $_ } };
camelia rakudo-moar 358582: OUTPUT«(signal ABRT)1 2 3 4 5 6␤»
vendethiel m: say hyper (1..6).map: { start { sleep $_ * 0.5; $_ } }; 20:07
camelia rakudo-moar 358582: OUTPUT«Cannot call 'hyper'; none of these signatures match:␤:(Any \op, Any \a, Any \b, Any :dwim-left($dwim-left), Any :dwim-right($dwim-right))␤:(Any \op, Any \obj)␤:(Any \op, Associative \a, Associative \b, Any :dwim-left($dwim-left), Any :dwim-right($dwi…»
moritz vendethiel: not much fun in sleep-sorting an already sorted list
hyper is NYI
vendethiel moritz: I'm just wondering if `await` is actually on the same level as `hyper` and `race` ? 20:08
S03 probably
moritz vendethiel: no
vendethiel: await is a concurrency primitive; lazy/eager/hyper/race control laziness/eagerness of a list
vendethiel moritz: doesn't hyper and race imply concurrency, though ? 20:09
moritz vendethiel: potential concurrency
jnthn Potential, and they're for data parallel rather than task parallel operations.
vendethiel so, the compiler is free to rewrite `say race (1..6).map: { $_ * 5 }` to `say await (1..6).pick(*).map: { start { $_ * 5 } }` ? 20:10
jnthn vendethiel: No, it'll be implemented differently. 20:10
vendethiel (not that it's useful, but I mean that it has the correct meaning)
jnthn: Yeah, not *implemented like that*, just "follows semantics"
jnthn vendethiel: With "await" the implementation is allowed to use the current thread you're on to do other stuff while you wait, and resume the code on another one later... 20:11
lue r: say "abcde" X <f g> 20:11
camelia rakudo-parrot 358582, rakudo-jvm 358582, rakudo-moar 358582: OUTPUT«abcde f abcde g␤»
vendethiel jnthn: not sure how that answers my question ?
lue r: say "abcde".comb X <f g>
camelia rakudo-parrot 358582, rakudo-jvm 358582, rakudo-moar 358582: OUTPUT«a f a g b f b g c f c g d f d g e f e g␤» 20:11
lue r: say "abcde".comb X "fg".comb
camelia rakudo-parrot 358582, rakudo-jvm 358582: OUTPUT«a f a g b f b g c f c g d f d g e f e g␤» 20:12
..rakudo-moar 358582: OUTPUT«␤»
lue I think I found a bug :)
vendethiel it's nice that the main thread can be used, but why is my 2nd version (beside being stupid) not following semantics?
FROGGS lue: go on and fix it :o)
lue I have no clue what's going wrong though 20:13
jnthn vendethiel: The compiler isn't free to re-write it, I don't think
vendethiel: But I think they'd be equivalent-ish
vendethiel jnthn: all I'm asking :). Thanks!
FROGGS r: say "fg".comb 20:14
camelia rakudo-parrot 358582, rakudo-jvm 358582, rakudo-moar 358582: OUTPUT«f g␤»
vendethiel (WRT data parallelism VS task parallelism, in the case where you take a range and map over it, isn't it data parallelism ?)
jnthn vendethiel: Yeah, which is why then using start is odd :) 20:16
Well, it's not odd in so far as hyper/race are NYI, but... :)
vendethiel jnthn: oh, just realized you meant you'd use hyper/race instead of await/start here.
jnthn yes :)
vendethiel jnthn++ # being patient with me 20:17
timotimo can i combine lines() working without an argument and sub MAIN(some stuff here)? 20:32
timotimo ah it's just a dynamic variable i can do whatever i want with 20:33
dalek ast: b069ef0 | (David Warring [email@hidden.address] | integration/advent2013-day14.t:
adding 2013 advent day 14
20:43
dwarring jnthn: I've changed one thing in class INIFileActions... 20:46
for $<entry> -> $e { %entries{$e<key>} = ~$e<value> } => for @<entry> -> $e { ... } 20:47
was giving error: postcircumfix:<{ }> not defined for type Array
lizmat jnthn: am I correct in assuming tha: winner * { done @promises { ... } } 20:58
is NYI ?
jnthn lizmat: I don't know off hand, but it woudln't surprise me. 21:00
lizmat m: my @p = (^10).map: { start { $_ } }; winner * { done @p { say $:v.result } } 21:03
camelia rakudo-moar 358582: OUTPUT«(signal ABRT)Type check failed in assignment to '&block'; expected 'Callable' but got 'Promise'␤ in method STORE at src/gen/m-CORE.setting:7092␤ in block at src/gen/m-CORE.setting:18481␤ in sub WINNER at src/gen/m-CORE.setting:18476␤ in block …»
lizmat something wrong in Actions setting up the parameters to WINNER ? 21:04
lizmat jnthn: ^^^ 21:22
perhaps not setting "wild_more" ? 21:23
jnthn lizmat: Hm, good guess. 21:25
lizmat: I'm not too familiar with the actions code there.
lizmat ok, I'll delve some more into it
I'll get back if I have more questions 21:26
jnthn k
lizmat setting wild_more manually to 1, doesn't fix the problem 21:32
lizmat more complicated than I thought and therefore not the right time to do this 21:32
so instead, I'll sleep on it& 21:33
jnthn lizmat++ # investigating
'night
dalek rl6-roast-data: 74de701 | coke++ | / (6 files):
today (automated commit)
22:01
dalek p/multispec: 4d20d38 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Map setmultispec op for MoarVM.
22:37
dalek kudo/multispec: baef318 | jnthn++ | src/Perl6/Metamodel/ (2 files):
Start using setmultispec on MoarVM.
22:50
kudo/multispec: 5bdac8b | jnthn++ | src/Perl6/Actions.nqp:
Auto-gen'd protos don't need special vars.

We will never look at them or use them, so don't waste time/space on having them.
rakudo/multispec: 60d56fa | jnthn++ | src/core/Regex.pm:
rakudo/multispec: Partial fix to regressions from setmultispec work.
rakudo/multispec:
rakudo/multispec: We need to make onlystar protos consistently not show up in caller
rakudo/multispec: introspection to make this reliable. We need that for not getting