00:33 maggotbrain left 00:36 maggotbrain joined 00:45 vrurg_ joined
gfldex I'm actually qualified to use escape hatches. When I was with the army we had to get a fat bloke out the bottom of a tank. It was a bit of a strech but we manages without him losing any important body parts. 00:46
00:48 vrurg_ left, vrurg left 00:49 vrurg joined 00:50 vrurg_ joined, lucasb left 00:53 vrurg__ joined 00:54 vrurg left, Altai-man_ joined 00:56 vrurg_ left, sena_kun left 01:01 vrurg joined 01:04 vrurg__ left 01:07 MasterDuke left 01:43 maggotbrain left 02:55 sena_kun joined 02:56 Altai-man_ left
releasable6 Next release in ≈1 day and ≈15 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
04:54 Altai-man_ joined 04:57 sena_kun left 06:46 leont joined 06:55 sena_kun joined 06:57 Altai-man_ left 07:39 JJMerelo joined
JJMerelo I'm trying to install dependencies for the doc repo with the latest (or yesterday's) commit and it simply hangs up 08:31
Download Raku/doc, and do zef install --deps-only .
Gonna check others 08:32
lizmat Files=1306, Tests=111384, 215 wallclock secs (29.06 usr 8.42 sys + 3017.94 cusr 286.20 csys = 3341.62 CPU)
JJMerelo Well, it looks like it's simply slow. 08:35
Seems to be working now.
sena_kun releasable6, status 08:38
releasable6 sena_kun, Next release in ≈1 day and ≈10 hours. 1 blocker. 143 out of 300 commits logged (⚠ 4 warnings)
sena_kun, Details: gist.github.com/9a0a4a8811887b9c49...9b1ad425ef 08:39
JJMerelo m: my @array= [1]; @array[3]=3; say @array.List; say @array.List(:view)
camelia (1 Nil Nil 3)
(1 (Mu) (Mu) 3)
JJMerelo m: my Int @array= [1]; @array[3]=3; say @array.List(:view) 08:42
camelia (1 (Mu) (Mu) 3)
JJMerelo m: my Str @array= ['a']; @array[3]='d'; say @array.List(:view) 08:43
camelia (a (Mu) (Mu) d)
JJMerelo lizmat is that ^^^ correct? 08:44
lizmat the :view named is an implementation detail
it exists to allow an optimization when coercing e.g. an Array to a List 08:45
JJMerelo Meaning, not documentable
lizmat right
also: BagHash "proxy" is a private sub, not visible from the outside
JJMerelo still, wouldn't it make mor sense if instead of always Mu, it would depend on the array element type?
lizmat it's an example; I wasn't thinking so much about that one than about Bag, for instance. 08:46
lizmat the whole point of :view is that it would not have to do any work.
JJMerelo OK 08:47
lizmat suppose you have an 1M elem Array, and you want a List for it
the :view would be instantaneous , without it you would need to copy 1M elements
the :view is only used internally when the contract is: I will not attempt to change anything you do *and* nobody will change the source 08:48
JJMerelo OK 08:49
Still
We should have some way of documenting implementation details
Even if it's for documentors (or doccers, whatever)
Somebody might view the definition for Array.List, go to source, say, hey, there's a named here, I'm going to document it, and then it disappears in the next version 08:50
I can simply add a comment in the source in the documentation, but it would need something on the other side 08:51
lizmat well, I *think* I've marked all public methods that are internal as "is implementation-detail" 08:52
JJMerelo By default, if it's not in roast, it's an implementation details, but a) somethings are not in roast and are spec, and b) we still document implementation details in some cases
lizmat if you find any that aren't, please let me know
also public subs
JJMerelo It's not so much the methods, but the arguments such as this one, :view
lizmat yeah, that's trickier 08:54
JJMerelo and I didn't know about that trait... Thanks! That really helps
08:54 Altai-man_ joined
JJMerelo Now we can get into the meta-discussion "is implementation-detail" is an implementation detail? 08:54
lizmat it will also hide subs / methods from introspection
JJMerelo But let's not.
lizmat I'd argue that "is implementation-detail" is *not* an implementation detail 08:55
as *any* module developer can use it
m: class A { method b() { } }; dd A.^methods>>.name
camelia ("b", "BUILDALL")
lizmat m: class A { method b() is implementation-detail { } }; dd A.^methods>>.name 08:56
camelia ("BUILDALL",)
JJMerelo Well, another issue for the doccers, then
lizmat guess we need to mark "BUILDALL" also as implementation-detailt somehow :-)
JJMerelo Also, Github is bombing right now with 500 errors
08:56 sena_kun left
lizmat yeah, otherwise I would have said what I just said as comments on Github :-) 08:57
JJMerelo lizmat what about this? github.com/rakudo/rakudo/blob/8134...Pretty.pm6
lizmat what about it ?
JJMerelo Well, deprecated and implementation detail. Let's forget about that. 08:58
I just discovered there was such a thing in Rakudo, I had never seen it before.
lizmat yes, indeed, and it has been deprecated
and now it is also an implementation-detail :-)
JJMerelo m: my Int @array= [1]; @array[3]=3; say @array.Slip 09:01
camelia (1 (Int) (Int) 3)
JJMerelo m: my Int @array= [0]; @array[3]=3; say @array.Slip 09:03
camelia (0 (Int) (Int) 3)
09:06 JJMerelo left 09:10 AlexDaniel left
Geth rakudo: 2bfaab6ccb | (Elizabeth Mattijsen)++ | 6 files
Mark :view as an implementation-detail

  - in comments for now, no way to mark Parameters like that yet		 09:25
jnthn I don't think BUILDALL is really an implementation detail, though it'd be uncommon to call it directly 09:37
Or to implement it 09:39
lizmat jnthn: it definitely is *not* documented, so in that sense it is practically an implementation-detail 09:42
m: class A { }; dd A.^methods 09:43
camelia (submethod BUILDALL (Any:D: ;; @auto, %init, *%_) { #`(Submethod|70180816) ... },)
lizmat isn't that *not* helpful for IDE's ?
09:55 JJMerelo joined 10:09 ShimmerFairy left
gfldex raku: my $R = role Mime[$t] { has $.mime = $t }; my $i = '/home/'.IO but $R.^specialize('dir'); 10:09
evalable6 (exit code 1) Could not instantiate role 'Mime':
Too few positionals passed; expected 2 arguments but got 1
in any protect at gen/moar/stage2/NQPCORE.setting line 1216
in block <unit> at /tmp/nNyTouPJDd line 1
gfldex how does one actually specialize by hand?
jnthn You are meant to call .^parameterize 10:10
10:10 ShimmerFairy joined
gfldex raku: my $R = role Mime[$t] { has $.mime = $t }; my $i = '/home/'.IO but $R.^parameterize('dir'); 10:11
evalable6 (exit code 1) Type check failed in binding to p…
gfldex, Full output: gist.github.com/b0308d9c42527ed548...fc4fe6e0ca
gfldex Mobule authors might want to fiddle with parameterized roles. So I think we should proide better docs on Metamodel::* . 10:16
jnthn Well, .^parameterize at least 10:18
Of course, everything we document in the MOP makes it harder to change in the future, though given how little we've changed it... 10:19
[Tux] Rakudo version 2020.05.1-301-g2bfaab6cc - MoarVM version 2020.05-97-gb5bb4f8d1
csv-ip5xs0.869 - 0.910
csv-ip5xs-208.271 - 10.148
csv-parser24.512 - 27.662
csv-test-xs-200.391 - 0.406
test8.254 - 8.677
test-t2.068 - 2.240
test-t --race0.853 - 0.987
test-t-2035.177 - 35.493
test-t-20 --race9.534 - 10.395
 10:29
gfldex There are plenty of modules in the ecosystem that use nqp. Very few can be found under Rakudo::* . 10:43
10:55 sena_kun joined 10:57 Altai-man_ left
jnthn Sure, and that's what happens without us encouraging its use. :) 11:00
lizmat well, at least some are intended to be included in the core some day :-)
Set::Equality being one of them :-) 11:01
jnthn I'm not that worried about those with responsive authors. :-)
greppable6: nqp::findmethod 11:02
greppable6 jnthn, 15 lines, 12 modules: gist.github.com/58a778f21be6aa30d7...d625d95366
jnthn Those should probably start using .^find_method 11:03
If anybody wants to try and get ahead of the breakage.
Though we could in principle shim that one to just call .^find_method 11:04
lizmat looks like the core also has its fair share of nqp::findmethod 11:12
should those also be changed ?
jnthn Mayyyybe...I want to see why it's doing them 11:14
I supsect the answer in some cases is "to avoid hllization"
In which case switching them to nqp::dispatch(...) is a better bet
lizmat ok, won't touch them then... :-) INTERPOLATE is the biggest offender 11:16
afk for a few hours&
jnthn m: my @a = 1, Nil, 3; @a Z||= 2, 2, 2; say @a 12:23
camelia ===SORRY!===
Cannot find method 'ann' on object of type NQPMu
jnthn "oops" :)
12:30 JJMerelo left
jnthn (Discovered during RakuAST work, where I'm trying to figure out how to model/compile various meta-ops.) 12:42
I only really need the assign one for now, though
12:54 Altai-man_ joined 12:57 sena_kun left
moritz the rabbit hole goes really deep :D 13:09
Geth rakudo/rakuast: e324ce4d44 | (Jonathan Worthington)++ | 4 files
RakuAST supprot for the assignment meta-operator

Meaning that we can now compile various of the tests that depend on using += and similar. The assignment itself needs some attention yet (we don't compile assignments too smartly in general).		 13:23
rakudo/rakuast: f0a7682c66 | (Jonathan Worthington)++ | src/Raku/Grammar.nqp
Unbreak compilation of chaining ops

We can't depend on the pasttype any more.		 13:42
jnthn 12 out of 26 t/01-sanity/ passing with RakuAST
moritz nice progress! 13:55
jnthn A few are passing for the slightly deplorable reason that if you the output is 'ok $foo' because you don't compile interpolation yet, then it still passes :P
prove is a bit lax, it seems 13:56
haha 14:01
# expected: 99
# got: -> gnatur { #`(Block|64806336) ... }
I...can guess what is cheating and how it's getting caught :D 14:02
14:14 kubrat left
Geth rakudo/rakuast: ccf2bb274b | (Jonathan Worthington)++ | 5 files
RakuAST handling of bare blocks

  * Invoke blocks that are directly at statement level
  * Add a cheating circumfix:sym<{ }> to the grammar; for now, it does not
   do the bunch of rules to decide if we're really looking at a hash or
   not		 14:22
14:55 sena_kun joined 14:57 Altai-man_ left
timotimo would there be any value in tossing out, for example, trigonometry ops and turning them into "syscalls"? 15:03
could probably keep nqp::sin($x) to compile to nqp::syscall("sin", $x)
lizmat what would that make better ? 15:06
ShimmerFairy If they directly map to moar ops, then for one thing you've just deprecated a bunch of opcodes in MoarVM.
timotimo in theory it'd free up op space, which ... could be good?
ShimmerFairy Also, if nqp::syscall calls C functions, you'd now have to worry about which sin function you want. sin? sinf? sinl? 15:07
timotimo will we have checking of syscall arguments on the nqp level? if not, we'd save memory from closures that we've installed for all the different ops
you would normally already have to select a different nqp::sin for integers vs doubles 15:08
ShimmerFairy Is there a nqp::sin_i ? I thought there were only _n variants for trig ops. 15:09
timotimo unless it's got its own little compilation function which can inspect what it's getting and select the right type based on that
but in general we do it the other way around
where the op forces the type
we probably don't, no
jnthn Primarily, we'll want to swtich things that work on objects
Since then we'll have a uniform way to eliminate repr checks and so forth 15:10
timotimo oh, ok
do we have an idea for bounds check elimination btw?
assuming we have an MVM_spesh_is_bounds_check_necessary(tc, g, ins) -> bool
for atpos and bindpos 15:11
jnthn I think switching things like sin is only really of value if we get to the point where we can have <= 256 ops and we can consider having *byte*code ;)
But that entails far more
timotimo what keeps us from variable-sized integers for everything in our bytecode anyway? ;) 15:12
jnthn Time to decode them :P
timotimo CPUs do that just fine somehow, too
jnthn You could go the Java way though, and have a constant table for any above a certain size
timotimo if our op codes need only 15 bits to span the whole range, we can have a var int style that won't go up to three bytes ever 15:13
throwing out extops may be nice, we could potentially have a set of "common integers" and "common nums" that we could have const_i and const_n ops with that use only 16 bits 15:15
we already went part-way with const_i64_16 of course 15:17
OTOH this could all be premature optimization *shrug*
ShimmerFairy Extops seem useful for compilers to add features that you probably shouldn't bug MoarVM developers to add to the VM proper. 15:18
timotimo we're also currently in the process of getting rid of as many extops as we can from rakudo's stuff, hopefully all of them 15:19
among other things, when the extops are gone, rakudo won't have to compile any C at all 15:20
ah, though we build "runners" now 15:21
so that argument falls flat
jnthn Yes, but it still would unblock building a fat-pack executable
ShimmerFairy tbh the language I want to eventually write an NQP compiler has essentially a "savestate" feature, and I'm hoping I could do it with extops instead of asking MoarVM to please add a feature Raku will likely never want. 15:22
timotimo "serializable continuations" or a lot more?
ShimmerFairy I mean like savestates in your favorite video game emulator. Allowing you to pick up exactly where execution was at (the language is MDL, to be specific) 15:23
timotimo my question is perhaps mostly "can you model the entire functionality with just being able to serialize and deserialize a continuation" 15:24
the runtime / compiler / whatever would of course want to have some code outside of that to manage stuff 15:25
ShimmerFairy Perhaps. Solving that problem is far off, but something I'm keeping in mind. 15:27
timotimo in any case, extops are the only way i'd know of to get to the actual VM state, so it's kind of the most natural fit for what you want - at least in our current implementation of moar 15:28
ShimmerFairy All I can say for sure atm is that calling <RESTORE> in MDL causes you to jump back to just after calling <SAVE> and pretending it gave a return value that tells the code you just restored. 15:29
(Also, I've never had to mess with continuations before, which is why I can't answer the "is a serializable continuation good enough?" question very well)
Geth rakudo/rakuast: 1479fa30ee | (Jonathan Worthington)++ | 4 files
RakuAST support for string variable interpolation
 15:30
timotimo is there like a stack that restore and save act upon, or is there only ever a single save/restore "active"?
15:32 unclechu left
ShimmerFairy It saves to a file, so it's up to the compiler how many saves you have. 15:32
er, well, up to the person writing the code I mean. 15:33
15:35 AlexDaniel` left
ShimmerFairy I just checked the manual, and the save/restore business also makes sure all the files you had open at the time are open when you restore, which sounds like an extra layer of fun. 15:39
16:54 Altai-man_ joined 16:56 sena_kun left
Geth rakudo/rakuast: 045f347c95 | (Jonathan Worthington)++ | 4 files
Basic RakuAST anonymous subroutine support
 17:06
17:08 AlexDaniel` joined
jnthn Maybe I'll get to hack on named ones later...home time now 17:12
17:24 unclechu joined, pochi left
Altai-man_ releasable6, status 18:42
releasable6 Altai-man_, Next release in ≈1 day and ≈0 hours. 1 blocker. 143 out of 301 commits logged (⚠ 4 warnings)
Altai-man_, Details: gist.github.com/f414865369a4e8987a...337e1b2e80
Altai-man_ lizmat, ping?
.tell lizmat can I run blin again? 18:43
tellable6 Altai-man_, I'll pass your message to lizmat
18:55 sena_kun joined 18:56 Xliff joined, Altai-man_ left
Kaeipi i'm refactoring Parameter.BUILD since it's fairly easy to generate parameters that don't make sense for the arguments you give it 18:57
i'm not sure how to handle when the arguments you give it don't make sense though
Xliff \o
Kaeipi with what i have atm, the only time the submethod throws is if it's impossible to parse a name or type
Xliff Has RakuAST hit moar-blead? 18:58
sena_kun Xliff, as in, was something merged? No.
Kaeipi so Parameter.new(:name<*@foo?>) becomes *@foo, Parameter.new(:name<*@foo), :type<Int:D>) also becomes *@foo
but it might also make sense to throw if a name alone doesn't make sense, like the former 18:59
sena_kun Anyone who can look at patching our release blocker?
timotimo do we need to do anything other than skipping that method call if there are no args? 19:30
sena_kun I don't think so. 19:31
Anyway, there is a test suite that will tell you if you're right.
19:33 MasterDuke joined
lizmat sena_kun: go for blin! 20:04
tellable6 2020-06-19T18:43:29Z #raku-dev <Altai-man_> lizmat can I run blin again?
Geth rakudo/ugexe-patch-2: 9a75738f13 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/Proc/Async.pm6
Fix windows quoting bug (#3761)
 20:05
rakudo: ugexe++ created pull request #3762:
Fix windows quoting bug (#3761)		 20:06
linkable6 RAKUDO#3761 [open]: github.com/rakudo/rakudo/issues/3761 [BLOCKER][regression] rakudo/repl.t fails consistently on Windows
20:54 Altai-man_ joined 20:57 sena_kun left
Geth rakudo: 9a75738f13 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/Proc/Async.pm6
Fix windows quoting bug (#3761)
 21:38
rakudo: 1b52f017e5 | Altai-man++ (committed using GitHub Web editor) | src/core.c/Proc/Async.pm6
Merge pull request #3762 from rakudo/ugexe-patch-2

Fix windows process quoting bug (#3761)
linkable6 RAKUDO#3761 [closed]: github.com/rakudo/rakudo/issues/3761 [BLOCKER][regression] rakudo/repl.t fails consistently on Windows
Altai-man_ releasable6, status 21:40
releasable6 Altai-man_, Next release in ≈21 hours. There are no known blockers. 143 out of 301 commits logged (⚠ 4 warnings)
Altai-man_, Details: gist.github.com/341b9d3ba55f8f5a4f...a4ce6d892c
[Coke] nice, seems like a small fix for the windows issue 22:39
Altai-man_ [Coke], did you check it manually, by the way? 22:42
[Coke] nope, just looked at the PR 22:43
Altai-man_ I see. 22:44
22:55 sena_kun joined 22:57 Altai-man_ left
releasable6 Next release in ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00

Powered by Cro and the Raku® Programming Language.

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

Thank you!