🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:55 buildable6 left 00:58 buildable6 joined 00:59 samcv left 01:00 samcv joined 01:02 buildable6 left, buildable6 joined
Xliff lizmat: So is that moar's job? 01:28
01:58 buildable6 left 02:01 buildable6 joined
jdv random datapoint, ive seen docker just lock up on no space... 02:29
just saying not all "real" sw handles faults well. happy path engineering ftw! 02:30
03:01 buildable6 left 03:03 buildable6 joined 04:03 buildable6 left 04:06 buildable6 joined 05:06 buildable6 left, buildable6 joined 06:06 buildable6 left 06:10 buildable6 joined 07:10 buildable6 left 07:13 buildable6 joined 08:13 buildable6 left 08:15 buildable6 joined 08:26 sena_kun joined 08:57 RakuIRCLogger__ joined, Geth left 08:58 RakuIRCLogger left 08:59 lizmat left 09:01 RakuIRCLogger__ left, RakuIRCLogger joined 09:15 buildable6 left 09:17 buildable6 joined 09:19 lizmat joined 10:17 buildable6 left 10:20 buildable6 joined 11:20 buildable6 left 11:22 buildable6 joined 11:26 buildable6 left, buildable6 joined
lizmat bisectable6: my %h{Cool}; dd %h.of 11:51
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, ¦6c (72 commits): «Any␤» 11:52
lizmat, Nothing to bisect!
lizmat bisectable6: my %h{Cool}; old=2015.12 dd %h.of
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight 11:53
lizmat bisectable6: old=2015.12 my %h{Cool}; dd %h.of
bisectable6 lizmat, Output on all releases: gist.github.com/8a638f929ce688bda8...656004a80d
lizmat, Nothing to bisect!
lizmat, On both starting points (old=2015.12 new=f45297d) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Any␤»
12:02 Geth joined
Geth rakudo/main: fef0c62961 | (Elizabeth Mattijsen)++ | src/Raku/ast/scoping.rakumod
RakuAST: allow nulls in resolving logic

To allow building resolve lists with fixed index references
Based on ab5tract's work in PR #5417		 12:04
rakudo/main: 48068a03c8 | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix codegenning of object hashes with explicit constraint

And some additional streamlining.
Based on ab5tract's work on PR #5417
12:22 buildable6 left 12:23 buildable6 joined
Geth Benchmark/main: c48c2e1a7d | 2colours++ | 5 files
2.0
 12:52
rakudo: ab5tract++ created pull request #5420:
DRAFT: RakuAST: Add :{} object hash initialization		 13:02
rakudo/main: bb9496e512 | ab5tract++ (committed by Elizabeth Mattijsen) | 3 files
RakuAST: Improve WhateverCode's .raku

This change allows `(* * *).raku` to return `* * *`, providing round-tripping through `raku` for WhateverCodes.		 13:12
13:16 Xliff left 13:23 buildable6 left, buildable6 joined 14:23 buildable6 left 14:27 buildable6 joined 14:31 buildable6 left, buildable6 joined
releasable6 Next release in ≈4 days and ≈3 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
Geth rakudo: usev6++ created pull request #5421:
(Re-)align backtraces on JVM with MoarVM		 15:19
15:27 buildable6 left 15:29 nebuchadnezzar joined 15:30 buildable6 joined 16:30 buildable6 left 16:32 buildable6 joined
Geth rakudo/main: 7e66cd2fc4 | (Elizabeth Mattijsen)++ | 6 files
RakuAST: add sections to translation context

  - named-A .. G
  - removed named datagram, exitcode: they turned out to be of named
   arguments of internals		 17:02
roast: 2c72b5b7e2 | (Christian Bartolomäus)++ | S02-types/array-shapes.t
Fix tests for arrays that aren't shaped

It looks like these tests have been added on the wrong assumption that adding a dot between the array name and the shape declaration should fail. At the time when the tests were added the synopsis (S09-data.pod) stated that those forms are errors. Later on it was clarified that they aren't supposed to die, but just can't be used to declare shaped arrays: github.com/Raku/old-design-docs/co...8527c2291.		 17:14
17:14 lizmat left
nemokosch on one hand it's great that somebody fills the most obvious gaps 17:17
on the other hand it doesn't seem like a good idea to just upstream commit to what is still considered to be the language specification 17:18
practically redefining the language on the fly
bartolin nemokosch: yeah, you have a point there. 17:21
nemokosch everything I wanted to say in this topic, I have already said. In fact, I even asked the RSC to at least refrain from committing to Roast without any formal procedure 17:26
bartolin oh, that's something I've missed.
nemokosch you aren't the only one, I'm afraid 😅
but of course this would mostly be solved if there was a "real specification" and there was no such pressure on Roast 17:27
bartolin btw, I would be totally fine with reverting the above commit and fix the issue in a different way. 17:28
nemokosch for what it's worth, I don't think there is a point in reverting; it's not something unprecedented to happen 17:30
I just wanted to raise awareness of the contradictory nature of this "long-standing tradition"
bartolin I was under the impression that we have an "immutable" branch "6.c" for the state of roast when 6.c was released -- and a branch "6.c-errata" for obvious errors (where this commit could be merged to). And then the same for 6.d. But it looks like we don't have a branch "6.d". 17:31
17:32 buildable6 left
nemokosch I think in general it would be good to still "see the forest for the trees" 17:33
it's a recurring theme that there is a broader problem and some particular examples get remedied, not the problem itself 17:34
17:35 buildable6 joined
reverting a commit when there is a long-running tradition to upstream redefine the language would be such a remedy 17:36
bartolin just to make sure I understand correctly: With "see the forest for the trees" you refer to (additionally) having a written description how things are supposed to work, instead of just roast?
nemokosch I mean it much more generally
general issue comes up -> "for example?" -> 3 examples given -> addressing the given examples one by one -> n-3 examples remain 17:37
ironically, the very idea of Roast relies very much on this way of thinking
in the presentation you linked, Patrick Michaud basically just said "there are still gaps in the spec but they will get filled over time". I really wish it was that simple. It didn't get filled over time, moreover I think it cannot get "filled" 17:39
17:40 buildable6 left, buildable6 joined
bartolin because the combination of features lets the number of required tests explode (so that it becomes impossible to manage/handle/understand)? (Please excuse my ignorance, if you already explained this in detail. I didn't follow that closely in the last months.) 17:44
nemokosch At the very least, all code paths that can run for user code, should be tested, any of them that aren't are immediately subject to undefined behavior 17:45
and "all code paths" should arguably cover the bytecode VM(s) as well 17:46
and then still, in theory, somebody could fulfill the spec in a different way, with different code paths, unfolding different undefined behavior
you cannot even phrase statements like "adding two Int (exact class) values with the &infix:<+> operator yields an Int (exact class)" 17:47
I also don't think there is any strategy for what operators must be available as subs, what absolutely mustn't, and what are compiler-specific 17:48
fortunately, this approach is so limiting that finding examples that break out of it is simple, I won't run out of them easily 17:49
we all just naturally imply that certain features "work", without any specification of what "working" means 17:51
bartolin I see your points. I'm afraid that I'm not qualified to propose a "good" solution to the problem :( 17:58
nemokosch I think, even if there isn't a great lot of motivated people to take up on it, or a tight deadline kind of thing, at least the aim/final goal should be a written specification, a la Ada, C, C++, iirc Pascal also had one, and so on 18:02
here, the examples are just to illustrate that this is definitely a real possibility
(again, even though I think "the interpreter is the spec" or "the reference guide is the spec" are also better approaches than "a very finite number of Raku tests are the spec") 18:04
PHP is a more recent example of a written specification, it was even mentioned in that talk 18:06
Mind you, I'm not saying that XYZ should suddenly start working on a written specification for Raku, much rather that it would be good to announce, or circulate the idea at the very least, that this is a long-term goal 18:08
which is really just a very symbolic acknowledging that Roast is uncapable of sufficiently defining the language 18:10
bartolin In my mind a combination of a written description and a (substantially expanded) test suite could form a specification. I've never looked into a C standard (or some such), but I could imagine that trying to write down everything verbally would be a really, really tedious work -- and it would leave room for corner cases or undefined behavior as well. So having an evolving test suite that codifies 18:22
exactly how things are supposed to work still seems reasonable to me.
nemokosch the C standard deliberately leaves space for "imagination" 18:27
but I'd say that's nothing compared to being unable to define any operations, let alone in a language with this abundance of built-in types and operations 18:28
bartolin But to come back to committing something to roast: Would it work to have immutable branches per released version of the language ("6.c", "6.d"). If new tests are added to the current default branch of roast ("master"), that wouldn't affect the released version. (It would affect the future versions, though.) 18:30
(That was my mental model how we handle roast. But only today I noticed that we don't have a branch "6.d".) 18:31
nemokosch What you suggest makes sense to me, and it definitely sounds more precautious than the current way 18:32
bartolin we *do* have "6.c-errata" and "6.d-errata", btw. Those would come into play for obvious errors in the released versions. 18:34
bartolin tries to find references to the setup with "6.c", "6.c-errata", etc. 18:35
18:35 buildable6 left
nemokosch is 6.d one big errata? 😂 18:37
18:38 buildable6 joined 18:47 notna joined
bartolin If I'm not mistaken, we (or better jdv++) not only run spectests against master, but also against 6.c-errata and 6.d-errata for each release (see github.com/rakudo/rakudo/blob/main...ain=1#L301 and github.com/rakudo/rakudo/blob/main...L510-L519) 18:55
19:10 notna left
bartolin ah, I finally noticed that we have a tag "6.d" (and "6.c") for roast. That sounds just fine -- no need for a branch there. Sorry for the noise. 19:28
nemokosch it's also strange that the versions are presented in an incremental fashion 19:30
as if 6.d was just 6.c plus stuff
19:38 buildable6 left 19:39 buildable6 joined
Geth roast: usev6++ created pull request #845:
Tweak README: Use tags for new releases, not branches		 19:59
20:39 buildable6 left 20:40 buildable6 joined 20:58 lizmat joined 21:40 buildable6 left 21:41 buildable6 joined 21:45 buildable6 left, buildable6 joined 22:01 sena_kun left
Geth rakudo/main: 495bec9f4e | ab5tract++ (committed by Elizabeth Mattijsen) | 4 files
RakuAST: Add :{} object hash initialization

This turns out to be a simple case of enabling multiple identities for `RakuAST::Circumfix::HashComposer` as both `&circumfix:<{ }>` and `&circumfix:<:{ }>`.
Send the :object-hash reality down from the grammar through the block-or-hash calculation into the composer itself, set the resolver to use the right lookup in the object-hash initialization case, and we're done.		 22:10
22:41 buildable6 left 22:44 buildable6 joined 23:44 buildable6 left 23:45 buildable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!