00:29 finsternis joined 01:06 AlexDani` joined 01:08 AlexDaniel left 01:22 maggotbrain777 joined 01:25 maggotbrain left 02:18 maggotbrain777 left 02:19 maggotbrain joined 02:27 maggotbrain left 02:28 maggotbrain joined 02:42 maggotbrain left 02:43 maggotbrain joined 02:47 maggotbrain777 joined, maggotbrain left 03:11 MasterDuke left 03:13 maggotbrain777 left 03:14 maggotbrain joined 03:22 maggotbrain left 03:34 maggotbrain joined 03:50 maggotbrain777 joined 03:52 maggotbrain left 03:55 [Coke]_ joined, [Coke]_ left, [Coke]_ joined 03:57 Geth left, Geth joined 03:58 [Coke] left, sjn left, sjn joined 04:26 [Coke]_ left 04:35 [Coke] joined, [Coke] left, [Coke] joined 05:28 squashable6 left 05:31 squashable6 joined
Xliff Is anyone seeing this? 06:30
cp: cannot create regular file '/home/cbwood/Projects/rakudobrew/versions/moar-blead/install/bin/perl6': Text file busy
06:44 domidumont joined 06:53 Altai-man joined 07:19 sena_kun joined 07:21 Altai-man left 07:49 maggotbrain777 left 07:52 maggotbrain joined 08:12 domidumont left 08:16 domidumont joined
lizmat Files=1336, Tests=113586, 222 wallclock secs (29.23 usr 8.46 sys + 3095.30 cusr 289.30 csys = 3422.29 CPU) 09:35
Xliff: not me
Xliff lizmat: ? 09:55
lizmat: Responding to my PM?
lizmat no, responding to: <Xliff>Is anyone seeing this?
Xliff Oh. OK. 09:56
I'm getting that from 'rakudobrew build moar-blead'
lizmat feels like w Windows thing to me 09:58
*a
Xliff Linux
lizmat hmmm...
stackoverflow.com/questions/167649...ge-in-unix 09:59
Xliff Odd. There should be no other build processes running. 10:00
lizmat: Not getting it with 'rakudobrew moar-blead HEAD~~'
timotimo Xliff: normally it means that a process using this binary is still running 10:03
Xliff lizmat: 'rakudobrew build moar-blead HEAD~' is also fine.
*sigh* -- Someone may want to get nine to look into R#3861 10:04
linkable6 R#3861 [closed]: github.com/rakudo/rakudo/pull/3861 Precomp store parallelism
Xliff Looks like the parallelism code may be affecting the installation process. That is just a guess based on the above results. 10:05
10:07 Kaiepi left 10:09 Kaiepi joined
[TuxCM] Rakudo version 2020.08.2-59-ge65466fcd - MoarVM version 2020.08-91-g590bac47e
csv-ip5xs0.981 - 1.003
csv-ip5xs-209.891 - 10.207
csv-parser24.827 - 26.619
csv-test-xs-200.390 - 0.397
test7.741 - 7.889
test-t1.856 - 1.902
test-t --race0.834 - 0.841
test-t-2032.006 - 32.557
test-t-20 --race9.041 - 9.351
 10:21
Xliff [TuxCM] You were able to build latest rakudo-blead? 10:27
HUH! 10:30
Had a zombie process running!
OK. moar-blead built successfully! Sorry for the false alarm. 10:32
lizmat ahh... zombies 10:37
[TuxCM] Xliff, I didn't check if it was rebuilt. Is that version old(ish)? 10:39
trying again 10:40
Xliff [TuxCM] - Nope was having problems building moar-blead. Trouble was I had a zombie process preventing the executable from being updated and it was causing the process to fail.
You don't need to try again.
My version string now matches yours. 10:41
[TuxCM] šŸ‘šŸ‘šŸ‘šŸ‘šŸ‘ 10:42
11:18 Kaiepi left, Altai-man joined 11:21 sena_kun left 11:26 Kaiepi joined 11:37 Kaiepi left 11:39 leont joined
Geth rakudo/ugexe-cur-emulates: 30e8c9ac13 | (Nick Logan)++ | src/core/CompUnit/Repository/FileSystem.pm6
Add `emulates` support for CURFS

Implements `emulates` support as described in s22. Note this can only work for a distribution with a META6.json since this info cannot be inferred like many other fields.		 11:50
rakudo/ugexe-cur-emulates: 02c46a96b4 | (Nick Logan)++ | src/core/CompUnit/Repository/Installation.pm6
Add `emulates` support for CURI
rakudo/ugexe-cur-emulates: 363e2a4861 | (Elizabeth Mattijsen)++ | 2 files
Merge branch 'cur-emulates' of github.com/ugexe/rakudo into ugexe-cur-emulates
lizmat ok, I'm confused now
this was supposed to fix the conflicts on github.com/rakudo/rakudo/pull/2732 11:52
except, I didn't see any conflicts
lizmat still does not like branchs
ugexe: I tried 11:53
ugexe ah, the PR came from my fork 12:21
lizmat afk for a few hours& 12:23
12:48 dogbert17 left 13:10 brrt joined 15:19 sena_kun joined 15:21 Altai-man left
Geth rakudo/rakuast: 9f562c1a57 | (Jonathan Worthington)++ | 5 files
RakuAST hash composer, block vs. hash distinction
 15:53
15:56 Kaiepi joined 16:04 Kaiepi left
Geth rakudo/rakuast: 51820000f7 | (Jonathan Worthington)++ | src/Raku/ast/scoping.rakumod
Add missing generate-lookup implementation
 16:56
rakudo/rakuast: 381b58a901 | (Jonathan Worthington)++ | 4 files
Implement tagged imports

Adding enough to be able to interpret the tags (in the current compiler they entail compilation to bytecode).
17:03 MasterDuke joined 17:14 brrt left 18:30 Kaiepi joined
timotimo is there a way to do IMPL-INTERPRET testing besides using a BEGIN prefix? like EVAL could in theory take a named argument / option to interpret instead of bytecode-compile 19:15
not sure if a user can just create their own InterpContext from scratch
oh ... that is a pretty empty class ... completely empty actually 19:16
i mean, it has IMPL in the name, so clearly not user-facing 19:17
19:18 Altai-man joined 19:21 sena_kun left
timotimo ok, RakuAST::Call::Name not being implemented for interpretation would probably be hit by a lot of code i guess, so why not have a quick little look at how that would look 19:24
19:25 Altai-man left
timotimo ah, perform-begin gets a working Resolver passed in, so that doesn't have an equivalent for interpreting without BEGIN 19:35
20:32 domidumont left 20:33 brrt joined, domidumont joined, domidumont left
timotimo env RAKUDO_RAKUAST=1 ./rakudo-m --ll-exception --stagestats -e 'my $ctx = RakuAST::IMPL::InterpContext.new; BEGIN say 99' 20:37
outputs 99
well, creating the ctx is left-over from earlier stuff
20:47 AlexDani` left
timotimo anyway, say 99 is good, but say 99 + 5 would be *better* 20:52
20:58 MasterDuke left
timotimo hm. does ApplyInfix need something to put named arguments for adverbs and such 21:09
21:13 MasterDuke joined
timotimo neat, i can output 99 + 5 now 21:30
Geth rakudo/rakuast: afdb7c5e9e | (Timo Paulssen)++ | 2 files
naive begin-time interpret for infixes and named sub calls
 21:31
MasterDuke cool 21:36
timotimo so, we want to get most of the BEGIN time stuff from the core setting interpretable 21:43
one of the very first things is a nqp::bindhllsym call :D 21:44
and so far we can only reach nqp ops by having it in compilation somewhere
of course at any time we can fall back to a full compile-and-execute cycle 21:56
22:01 [Coke] left 22:04 [Coke] joined, [Coke] left, [Coke] joined
timotimo getting all the trait_mod subs working with interpretation will, of course, be worth a lot 22:06
22:29 brrt left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!