01:00 dogbert17 left 01:27 lucasb left 02:48 softmoth left 04:40 statisfiable6 left, sourceable6 left, linkable6 left, evalable6 left, bisectable6 left, tellable6 left, unicodable6 left, quotable6 left, squashable6 left, committable6 left, notable6 left, releasable6 left, shareable6 left, benchable6 left, nativecallable6 left, greppable6 left, bloatable6 left, coverable6 left, reportable6 left, nativecallable6 joined 04:41 quotable6 joined, squashable6 joined, benchable6 joined, linkable6 joined, shareable6 joined, evalable6 joined, notable6 joined 04:42 statisfiable6 joined, bloatable6 joined, sourceable6 joined, committable6 joined, reportable6 joined, greppable6 joined, releasable6 joined 04:43 bisectable6 joined, unicodable6 joined, coverable6 joined, tellable6 joined 05:10 tyil left 05:15 tyil joined
Geth_ rakudo: 717b3266d1 | (Christian Bartolomäus)++ | tools/build/create-jvm-runner.pl
[JVM] Fix generated runner files
 05:41
06:09 AlexDaniel left 06:22 MasterDuke joined
MasterDuke timotimo: did you get it? i think it's still available at send.firefox.com/download/e038cb2e...U-ijUAWoyw 06:22
07:37 patrickb joined
nine AlexDaniel`: I actually prefer rebasing before a merge as it gives you a nice linear history that can be bisected more easily 08:11
08:28 ufobat joined 09:10 sena_kun joined 09:13 Altai-man_ joined 09:16 sena_kun left
Geth_ rakudo: 66a2250aa1 | (Christian Bartolomäus)++ | 3 files
Add missing label support for some loop constructs

A couple of loop constructs were missing support for labels. Probably this went unnoticed, because 'for' loops were not affected and a lot of iterating is handled by optimized code in src/core.c/Any-iterable-methods.pm6 (IterateOneWithPhasers and friends).
This should fix the problem described in #3622.		 10:16
linkable6 RAKUDO#3622 [open]: github.com/rakudo/rakudo/issues/3622 Some loop constructs crash when used with labels
rakudo: 77b7e0cde5 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
Merge pull request #3623 from usev6/issue3622_label_for_nqp-handle

Add missing label support for some loop constructs
roast: 53d332addf | (Christian Bartolomäus)++ | S04-statements/label.t
Test usage of labels within nested loops

  ... as reported in github.com/rakudo/rakudo/issues/3622.
roast: 0bbe015c4f | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S04-statements/label.t
Merge pull request #635 from usev6/rakudo_issue3622

Test usage of labels within nested loops
rakudo: 2fb7198f3d | (Elizabeth Mattijsen)++ | src/core.c/Date.pm6
Add Date.last-date-in-month

This short-cut method gives you the last date in the month of the Date object, or returns the invocant if the day value is already the last day of the month.
This should allow for much easier ranges like
   $date .. $date.last-date-in-month
for all remaining dates in the month.		 10:17
10:24 dogbert17 joined 10:38 MasterDuke left 10:47 AlexDaniel joined, MasterDuke joined 10:48 AlexDaniel left, AlexDaniel joined 10:56 patrickb left 11:13 Xliff joined 11:15 sena_kun joined 11:17 Altai-man_ left
Xliff use NativeCall; sub malloc(uint64) is native returns Buf { * }; my $a = malloc(100); say $a; <-- Kills rakudo dead with an infinite hang 11:17
use NativeCall; sub malloc(uint64) is native returns Pointer { * }; my $a = malloc(100); say $a; <-- Works fine. LTA? 11:18
11:19 camelia left
nine Xliff: how would it know how large that Buf actually is? 11:20
lizmat TIL about BagIt en.wikipedia.org/wiki/BagIt
chloekek: wonder how that applies to CRAI ? 11:21
tellable6 lizmat, I'll pass your message to chloekek
lizmat chloekek: that being en.wikipedia.org/wiki/BagIt
tellable6 lizmat, I'll pass your message to chloekek
Xliff nine: Then rakudo should test for that and throw an error! 11:25
Hence LTA 11:26
11:26 camelia joined
Xliff I'm bugging it. 11:26
lizmat nine: you can presize a Buf / Blob
nine #10 0x00007ffff787e615 in MVM_exception_throw_adhoc_free_va (tc=0x405f60, waste=0x0, messageFormat=0x7ffff7a637b0 "Internal error: unhandled dyncall return type", args=0x7fffffffbc68) at src/core/exceptions.c:899 11:27
It tries to, but then runs into a deadlock
lizmat m: dd Buf.allocate(10)
camelia Buf.new(0,0,0,0,0,0,0,0,0,0)
Xliff Ouch.
That took a long time.
lizmat m: dd Buf.allocate(10)
camelia Buf.new(0,0,0,0,0,0,0,0,0,0)
nine lizmat: maybe, but how would you give that preallocated Buf to the native sub to fill with the returned data
lizmat: just doesn't make sense. We do have CArray for this 11:28
Xliff nine: Isn't this all moot? If Buf/Blob aren't working as return types. Why allow them to be used? And yes! We have CArray for this. Just my point.
Buf would be a better alternative, but I can wait until it's working properly.
lizmat isn't it that that part of NativeCall actually precedes the invention of Buf/Blob ? 11:29
nine Buf cannot ever be a valid return type for a native sub, because it would need to know how large that array is. CArray is appropriate as it puts the responsibility to keep track of that on its user. 11:30
lizmat but Blob could be, as its size cannot change ? 11:31
nine Not it cannot.
lizmat ?
nine Buf is just Blob with some extra methods. Both are using VMArray reprs and VMArray expects to manage it's memory itself and always know how large that array is. 11:32
CArray has its own repr that supports unmanaged memory.
lizmat aha ok 11:36
nine I just fixed that deadlock in MoarVM
Xliff nine++ 11:37
So shouldn't steps be taken to insure that Buf/Blob cannot be used as return types??
I take it they are fine as parameters?
nine Fine as params, invalid as return types
Xliff Wouldn't they just act as Pointer from that standpoint?
nine Xliff: yep, please submit a PR 11:38
Xliff OK. I'm going to finish bugging.
nine Finish bugging. Start debugging :D
lizmat Files=1306, Tests=111232, 216 wallclock secs (28.61 usr 8.46 sys + 3035.09 cusr 277.00 csys = 3349.16 CPU) # from last night 11:39
nine Memory usage looking quite good now :) niner.name/files/matikon-memory-usage-fixed.png 11:41
Xliff nine: :P
#3630
nine: I have over 374,000 lines of my own code to deal with, ATM ;q 11:42
lizmat wow 11:47
lizmat hopes a lot of that is generated
jnthn That's...a lot of code
Xliff lizmat: Yes. 11:49
All of it is hand maintained, tho. 11:50
And yes, that's Raku code.
lizmat wow
Xliff github.com/Xliff - Check the featured projects.
Almost 2 years woth of work. 11:51
nine Xliff: is that webkit or webkit2? 11:58
Xliff Webkit2 12:03
Now 376k. ;q
Just committed more to p6-GStreamer. 12:04
And with that... it's now time to face $dayJob.
AlexDaniel nine: for a lot of smaller projects having a linear history is nice, but when dealing with substantial PRs I'd much rather have a merge commit that can be easily reverted if needed 12:25
moreover, you can only rebase your own PRs, so it doesn't really matter in the end as you'll never really have linear history 12:26
Xliff Yeah, but squashing commits kinda cheats the contributors. At least as far as Github is concerned.
12:27 Xliff left
AlexDaniel I'm not too worried about rewriting the commiter field, but throwing away the signature is kinda meh 12:28
I guess it's a weak argument cuz most people don't sign their stuff, but then of course they wouldn't if we start to routinely throw away the signatures :) 12:29
Geth_ rakudo: 92750571e4 | (Elizabeth Mattijsen)++ | 2 files
Don't use named variables between internal methods

There's no need, so why have the extra overhead of an optional named parameter, when a obligatory positional will do.		 12:30
AlexDaniel also I'm not sure how it makes bisecting harder, I never had an issue with it
and it's probably fair to say that I bisected a lot of stuff :)
12:35 cognominal joined
nine AlexDaniel: rebasing doesn't preclude having a merge commit 12:36
12:38 cognomin_ left
AlexDaniel sure 12:38
jnthn lizmat: Names aren't so terribly expensive after specialization, fwiw; they end up being handled by index without any string comparisons. 12:40
*nameds 12:41
lizmat well, this involved just about any loop that we have
so I figured it was worth the change even if they are not that expensive
jnthn Only lazy ones :) 12:42
But yeah, in that case it's not really much of a readability loss
lizmat also nameds imply optionalness to me... which they weren't really
jnthn The named actually was optional in the original code, though? 12:43
I don't see a ! on it
- method CStyleLoop(&body,&cond,&afterwards,:$label) { 12:44
lizmat indeed, but it wasn't used as such in the code
if it had been a obligatory named, I wouldn't have changed it
these are internal methods 12:45
I didn't touch the outward facing parts
like Seq.from-loop 12:46
bartolin_ jnthn: those :$label params were just added by me to fix github.com/rakudo/rakudo/issues/3622 I should have made them required. 12:49
tellable6 2020-04-14T19:03:32Z #raku <[Coke]> bartolin_ so, printfh is slightly more used, it's made it into the stage-N snapshots. It's probably still removable, though.
bartolin_ I copied that from github.com/rakudo/rakudo/blob/9275...s.pm6#L39, so maybe that :$label should get it's exclamation mark, too? 12:50
jnthn lizmat: OK, sounds fine.
lizmat bartolin_: no, that's an outward facing method (at least to Actions)
that's why I didn't change that one
AlexDaniel sena_kun: I'm testing a fix for November and other modules 12:52
bartolin_ lizmat: ok. thanks for taking care :)
AlexDaniel sena_kun: it's a mistake on my side, I don't think I ever meant to install into directories that are not empty
sena_kun AlexDaniel, yay! What was that?
AlexDaniel sena_kun: I mean, in some way it's still a rakudo or zef issue. But either way Blin shouldn't be trying to install a module into the same directory twice 12:53
so what happens is that it tries on --new first, which fails, then it tries again using --old but attempts to install into the same directory 12:54
which is not empty even though the installation failed
the solution is extremely simple – create a temp dir to install stuff into 12:55
something that should've been done in the first place…
looking at the code I think I was relying on --dry a bit too much 12:56
sena_kun: anyway I'll let you know when you can rebuild the image :) 12:59
lizmat bisectable6: dd "a" ...^ "e" ...^ "a" 13:12
bisectable6 lizmat, Bisecting by output (old=2015.12 new=9275057) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/03a94674b6e0df6f9f...5528d8506e
lizmat, (2018-04-21) github.com/rakudo/rakudo/commit/6a...036e7652c6
AlexDaniel lizmat: I think it bisected something else 13:13
6c: dd "a" ...^ "e" ...^ "a"
committable6 AlexDaniel, gist.github.com/c525a21a313bd2e547...3d96349e42
13:14 Altai-man_ joined
lizmat yeah, I was wondering whether that was something that worked ever 13:14
looks like no
m: dd "a" ... "e" ... "a" # this does 13:15
camelia ("a", "b", "c", "d", "e", "d", "c", "b", "a").Seq
lizmat m: dd ("a" ... "e") ... "a" # this does not 13:16
camelia ("a",).Seq
lizmat m: dd "a" ... ("e" ... "a") # yet this does
camelia ("a", "b", "c", "d", "e", "d", "c", "b", "a").Seq
13:17 sena_kun left
lizmat m: dd ("b" ... "e") ... "a" # yet this does work again 13:18
camelia ("b", "c", "d", "e", "d", "c", "b", "a").Seq
AlexDaniel lizmat: the last one works for a wrong reason I guess?
m: dd "a" ... ("e" ... "a")
camelia ("a", "b", "c", "d", "e", "d", "c", "b", "a").Seq
AlexDaniel m: dd "a" ... <e x z>'
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3dd "a" ... <e x z>7⏏5'
expecting any of:
infix
infix stopper
postfix
statement end
statement modi…
AlexDaniel m: dd "a" ... <e x z>
camelia ("a", "b", "c", "d", "e", "x", "z").Seq
AlexDaniel I had no idea you could do that btw?
does it really match against the first element? 13:19
jnthn m: say 'e'
camelia e
jnthn m: say 'e' ~~ <e x z>
camelia False
AlexDaniel jnthn: yeah, it's something else. Notice how it also includes x z in the sequence 13:21
jnthn *nod*
Was just curious :)
lizmat yeah, there's quite a jungle of conditions there 13:22
and I wonder how much is actually used out there
AlexDaniel m: .say for ‘a’ … <d a> … ‘e’
camelia a
b
c
d
a
b
c
d
e
lizmat as many people don't know they could do tha 13:23
t
AlexDaniel well, I can see a lot of uses for this… in code golf… 13:24
Geth_ nqp: ee70250772 | (Daniel Green)++ | tools/templates/MOAR_REVISION
Bump Moar

Brings a couple fixes and the ability for nqp::encode() to append to a pre-existing buffer.
lizmat what I don't understand is, why it is correct that this produces a single value:
dd "aaa" ... "z" 13:25
evalable6 ("aaa",).Seq
AlexDaniel lizmat: well, what do you understand about the string generation so far?
like, what do you think should it produce and why
lizmat I think that should produce an empty Seq 13:26
because "aaa" is before "z", it uses .succ 13:27
but then when the next value is generated, it sees that it can never reach the end because it has more characters than the end point
and then decides to quit
it could have known that for the first value as well
AlexDaniel oh… it's using .succ in this case??
13:27 lichtkind joined
lizmat github.com/rakudo/rakudo/blob/mast...CE.pm6#L28 13:28
AlexDaniel m: say ‘aab’ cmp ‘z’
camelia Less
AlexDaniel m: say ‘aab’.succ cmp ‘z’
camelia Less 13:29
AlexDaniel lizmat: so if it's using .succ, then why does it decide to quit if it's still less?
lizmat github.com/rakudo/rakudo/blob/mast...CE.pm6#L29
because it also checks the length, but only after it produced a value 13:31
AlexDaniel lizmat: well, generally it is simply because the condition on line 24 is different from the one on 29, but it's not that this whole block makes much sense anyway 13:32
for example, let's say it's More 13:33
then what, why is it not calling .pred?
or at least why doesn't it do that with the same .chars logic
m: say ‘aaa’.pred
camelia Decrement out of range
in block <unit> at <tmp> line 1
AlexDaniel oh. 13:34
lizmat m: dd ("zz" ... "a").head(20) # it actually does, sort off
camelia ("zz", "zy", "zx", "zw", "zv", "zu", "zt", "zs", "zr", "zq", "zp", "zo", "zn", "zm", "zl", "zk", "zj", "zi", "zh", "zg").Seq
lizmat however if you run it to completion:
m: dd "zz" ... "a"
camelia Decrement out of range
in block <unit> at <tmp> line 1
lizmat still not sure why that happens 13:35
as the endpoint is clearly reached
m: dd ("zz" ... "a").skip(676).head 13:36
camelia Decrement out of range
in block <unit> at <tmp> line 1
AlexDaniel lizmat: well it's the .pred itself that blows up on ‘aa’
lizmat ah, duh 13:37
AlexDaniel m: say ‘zz-9’.succ
camelia zz-10
AlexDaniel m: say ‘zz-9’.succ.pred 13:38
camelia zz-09
lizmat m: say 09 + 1 - 1
camelia Potential difficulties:
Leading 0 has no meaning. If you meant to create an octal number, use '0o' prefix, but note that 9 is not a valid octal number. If you meant to create a string, please add quotation marks.
at <tmp>:1
------> …
lizmat he
m: say "09" + 1 - 1 13:39
camelia 9
lizmat yeah... it's all pretty .... magic :-)
AlexDaniel lizmat: also the code you're showing somewhat assumes that cmp somehow relates to .succ and .pred
which, for strings at least, doesn't work this way 13:40
.succ on Str gives you what? Next filename or something?
m: say ‘zz-10.txt’.succ 13:41
camelia zz-11.txt
lizmat m: say ‘zz-10.txt’.IO.succ
camelia "zz-11.txt".IO
AlexDaniel m: say ‘zz-10.txt-20’.succ
camelia zz-11.txt-20
lizmat thing is, since we allow open() to just take a Str 13:42
there's too much code out there depending on that behaviour to simply change
we could decide to create a new behaviour for 6.e 13:43
AlexDaniel lizmat: yes, which is why I think .succ on Str should in the end tell you “I don't know how to do that”
and before that we can maybe give a warning or something
want to work with filenames? Sure, .IO.succ 13:44
lizmat: but then … will have to continue doing the magic so that ‘a’…‘z’ keeps working…
lizmat "a" ... "z" doesn't use .succ anyway 13:46
if the strings are of the same length, it uses codepoint semantics anyway
m: dd "▁▁" ... "██" 13:47
camelia ("▁▁", "▁▂", "▁▃", "▁▄", "▁▅", "▁▆", "▁▇", "▁█", "▂▁", "▂▂", "▂▃", "▂▄", "▂▅", "▂▆", "▂▇", "▂█", "▃▁", "▃▂", "▃▃", "▃▄", "▃▅", "▃▆", "▃▇", "▃█", "▄▁", …
lizmat m: dd "☀☀" ... "☂"☂"" 13:48
camelia 5===SORRY!5=== Error while compiling <tmp>
Bogus postfix
at <tmp>:1
------> 3dd "☀☀" ... "☂"7⏏5☂""
expecting any of:
infix
infix stopper
postfix
statement end
statement mo…
lizmat m: dd "☀☀" ... "☂☂"
camelia ("☀☀", "☀☁", "☀☂", "☁☀", "☁☁", "☁☂", "☂☀", "☂☁", "☂☂").Seq
AlexDaniel which is cool, but then: 13:49
m: .say for ‘10’…‘20’
camelia 10
20
lizmat m: .say for ‘10’…‘21’ # even more confusing ? 13:50
camelia 10
11
20
21
lizmat it was actually mentioned as a feature in the speculation
m: .say for ‘000’…‘777’
camelia 000
001
002
003
004
005
006
007
010
011
012
013
014
015
016
017
020
021
022
023
024
025
026
027
030
031
032
033
034
035
036
037
040
041
042
043
044
045
046
047
050
051…
AlexDaniel lizmat: with constants it is actually not as confusing, but if you have $a…$b and somehow end up with strings then it can be a problem 13:51
m: say ‘10’+‘20’
camelia 30
AlexDaniel so a lot of the ops will work fine, and even … works fine with single digit numbers 13:52
lizmat: if we had a separate op for string generation then we'd be able to define reasonable and easy semantics for … based on .succ/.pred 13:53
and probably also easy to understand behavior for that separate string op 13:54
Geth_ nqp/master: 5 commits pushed by (Daniel Green)++, MasterDuke17++ 13:57
AlexDaniel greppable6: '\s*... 13:59
14:02 greppable6 left
AlexDaniel I see… 14:02
Geth_ rakudo: fdfa6ac85c | (Daniel Green)++ | tools/templates/NQP_REVISION
Bump NQP

Brings some MoarVM fixes as well as an NQP that writes bytecode on the fly to reduce allocations.		 14:09
lizmat m: dd ("⚀⚀" ... "⚅⚅").roll(5) 14:11
camelia ("⚄⚅", "⚀⚁", "⚄⚁", "⚁⚁", "⚂⚅").Seq
lizmat guess it could be useful for something like that
AlexDaniel lizmat: nothing is ever totally useless, but it doesn't always mean that it should be there :) 14:14
lizmat m: dd ("a" ... "e" ... 10).head(9) # 10 magically interpreted as a string 14:22
camelia ("a", "b", "c", "d", "e", "d", "c", "b", "a").Seq
lizmat m: dd ("a" ... "e" ... 10).head(10) 14:23
camelia ("a", "b", "c", "d", "e", "d", "c", "b", "a", &CORE::infix:<orelse>(Failure.new(exception => X::AdHoc.new(payload => "Decrement out of range"), backtrace => Backtrace.new), *.self)).Seq
14:33 greppable6 joined
AlexDaniel Altai-man_: OK, actually, I have no idea. 15:10
I changed it so that it writes to separate dirs, it didn't help
it has no access to the previous installation dir but somehow it still manages to install the module on second try
if I had to guess I'd say it's leaving some precomp files somewhere, but I have no idea where 15:11
Altai-man_ AlexDaniel, that's sad, but trying to debug it is admirable. On the bright note by now I know all the false positives by heart, so just have to filter them out. :)
15:15 sena_kun joined 15:16 Altai-man_ left
AlexDaniel how does rakudo know that it should recompile stuff if rakudo itself was changed (e.g. updated to a newer version)? 15:19
by stuff I mean modules
15:25 ufobat_ joined
AlexDaniel sena_kun: btw this is wrong 15:26
weird, I thought I fixed that
sena_kun: github.com/Raku/Blin/commit/3f3a3e...e9f73b9707
15:29 ufobat left
Geth_ Blin: 08fded2e33 | (Aleks-Daniel Jakimenko-Aleksejev)++ | bin/blin.p6
Unbreak --custom-script

By fixing an oops in 3f3a3e8c9954a85f0c0b36181a7440e9f73b9707.		 15:35
nine AlexDaniel: the precomp stores contain a directory named after the compiler's id which in turn contains the actual precomp files
15:38 lichtkind left
AlexDaniel nine: mind if I ask some possibly stupid questions? :) 16:05
nine: so when I ask zef to install a module, it first runs tests, and if tests are OK it install the module
nine: does it precompile modules twice or does it avoid that somehow? 16:06
nine it does so twice 16:08
greppable6 AlexDaniel, and I oop! Backtrace: gist.github.com/0646a64339c1cb54ce...b225343d2b 16:16
lizmat nine: I don't think you could do it once, right? 16:17
AlexDaniel lizmat: why not?? 16:22
lizmat because during testing it is using -Ilib ? 16:23
so using a different repo ?
nine Well in theory it should be possible to install the module into a staging repository, use that for testing and when everything's fine, just copy the result files to the actual target repository. 16:25
That way you'd actually test what will end up installed which could expose issues like %?RESOURCES used wrong (or not at all when it should) 16:27
AlexDaniel sena_kun: D'OH! Dammit! I think I figured it out :D 16:40
sena_kun is very interested
AlexDaniel sena_kun: I'm dumb. It's failing when trying to install the module, but on --old revisions it does --dry
so it's not even attempting to install them, it just tests
of course that succeeds 16:41
sena_kun So the behavior differs for new and old?
Or, rather, check method.
AlexDaniel sena_kun: no, it's just that Blin tends not to install anything it doesn't need 16:42
and if a module fails during the installation (not testing), then you won't see that
sena_kun looks forward towards testing out a patch to see how many false positives can be eradicated 16:43
AlexDaniel nine: where does it store precomp files that were created during testing? 16:44
16:46 cognomin_ joined 16:50 cognominal left
nine AlexDaniel: in .precomp 16:51
AlexDaniel nine: which one? So do I understand it right that if I do `PERL6LIB=foo zef install smth` I'll end up with `foo/.precomp` containing different precomp files created from both steps? 16:57
nine: also, if I'm doing --install-to=bar, will bar have any precomp file or will any process that tries to use inst#bar have to precompile it again (into its own .precomp folder, wherever that is)? 16:58
files*
sena_kun: and now I understand why I didn't see anything like this before! github.com/Raku/Blin/commit/debe67...a871059269 17:04
sena_kun: basically, any module like this appeared as a Flapper
until I “fixed” it
[Coke] Can someone give a brief overview of the "hll*" ops? just "things that might be customized based on the language that is targeting NQP (which is basically almost always Raku)" 17:10
nqp: nqp::say(nqp::bool(1)) 17:11
camelia No registered operation handler for 'bool'
at gen/moar/stage2/QAST.nqp:1504 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)
from gen/moar/stage2/QAST.nqp:6145 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_node)…
[Coke] nqp: nqp::say(nqp::bool_I(1))
camelia This representation (P6int) cannot unbox to other types (for type BOOTInt)
at <tmp>:1 (<ephemeral file>:<mainline>)
from gen/moar/stage2/NQPHLL.nqp:1916 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nqp…
[Coke] nqp: nqp::say(nqp::bool_i(1))
camelia No registered operation handler for 'bool_i'
at gen/moar/stage2/QAST.nqp:1504 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)
from gen/moar/stage2/QAST.nqp:6145 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_node)…
17:14 Altai-man_ joined 17:17 sena_kun left
lizmat m: dd ("aa" .. "z").list 17:26
camelia ("aa",)
lizmat m: dd (100 .. 10).list
camelia ()
lizmat these feel inconsistent
nine AlexDaniel: yes on foo/.precomp, no on inst#bar 17:27
AlexDaniel: if you -install-to bar, then bar/precomp contains the files 17:28
18:05 lichtkind joined 18:15 commavir joined
AlexDaniel Altai-man_: can you please check what's the status of Inline::Perl5? 18:29
Altai-man_: there are modules that fail with `Please install Inline::Perl5 for Perl 5 support.` so something is off
nine: thank you! 18:30
Altai-man_ AlexDaniel, later today, in 2-3 hours, I think. Check as in if it installs on master?
AlexDaniel Altai-man_: no, what's the output in blin
Altai-man_ ah
AlexDaniel, started a run 18:32
AlexDaniel Altai-man_: I didn't fix it yet!
Altai-man_: also, can't we take a look at the previous run? 18:33
Altai-man_ AlexDaniel, oops, just deleted /output. :S failures.md is still on github, I think. 18:34
AlexDaniel Altai-man_: yeah but Inline::Perl5 is not there, understandibly
Altai-man_: ok lemme push my blin fixes first…
18:34 finsternis joined
AlexDaniel hmmm okay my fix is not helping November 18:38
back to the drawing board…
Altai-man_ AlexDaniel, what data for Inline::Perl5 you want, json?
AlexDaniel Altai-man_: yeah, that'd be fine
Altai-man_ clbin.com/4jJnF 18:39
Hmm, missing dependency is not what I'd expect. 18:40
AlexDaniel interesting :)
okay I'll check, it's a blin thing 18:41
Altai-man_ AlexDaniel, should I do another run with latest blin?
AlexDaniel Altai-man_: not really
maybe tomorrow I'll get stuff ready
Geth_ nqp: 25e3ccd006 | Coke++ | docs/ops.markdown
document jvmgetproperties
 18:42
[Coke] nqp: nqp::say(nqp::totalmem()) 18:44
camelia 3055808512
[Coke] ^^ bytes?
AlexDaniel [Coke]: yes 18:46
18:49 softmoth joined
Geth_ nqp: b6c4b56f13 | Coke++ | docs/ops.markdown
document totalmem op
 18:51
18:51 cognominal joined
AlexDaniel Altai-man_: “Inline::Perl5 – MissingDependency – Dependency “perl” was not resolved” 18:54
Altai-man_: and then it refuses to test it xD
18:55 cognomin_ left
Geth_ nqp: 1f86644328 | Coke++ | docs/ops.markdown
Document isttyfh op
 19:00
AlexDaniel Altai-man_: it's even more interesting because I have code that is supposed to specifically ignore that… :) 19:02
19:04 softmoth left, softmoth joined 19:12 cognominal left 19:15 sena_kun joined 19:17 Altai-man_ left 19:27 softmoth left 19:28 softmoth joined 19:36 dogbert17 left 19:38 Xliff joined
Geth_ Blin/master: 5 commits pushed by (Aleks-Daniel Jakimenko-Aleksejev)++ 20:01
AlexDaniel sena_kun: OK, you can rebuild and rerun now :)
sena_kun: a bunch of modules should not appear now, except for November and maybe some others
sena_kun: we'll see where we stand after this run and I'll try to fix the remaining ones 20:02
sena_kun Trying it out...
AlexDaniel sena_kun: also if you notice that it is much slower please let me know 20:04
sena_kun Will do.
20:26 pmurias joined 21:14 Altai-man_ joined 21:17 sena_kun left 21:39 softmoth left 21:49 pmurias left 23:15 sena_kun joined 23:17 Altai-man_ left 23:19 softmoth joined 23:54 lichtkind 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!