🦋 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:00 reportable6 left 00:02 reportable6 joined 00:14 Kaiepi left 00:21 sortiz left, sortiz joined 01:42 MasterDuke left
tbrowder lizmat: so that's your secret! i'm not smart enough to which of 42 versions of a post i'm editing, and it's most always the wrong one :( 01:57
03:12 linkable6 left, evalable6 left, shareable6 left, squashable6 left, nativecallable6 left, tellable6 left, committable6 left, sourceable6 left, bloatable6 left, statisfiable6 left, coverable6 left, greppable6 left, unicodable6 left, benchable6 left, notable6 left, bisectable6 left, quotable6 left, releasable6 left, reportable6 left, unicodable6 joined, greppable6 joined, shareable6 joined, evalable6 joined 03:13 releasable6 joined, quotable6 joined, sourceable6 joined, linkable6 joined, bloatable6 joined, squashable6 joined, notable6 joined, reportable6 joined 03:14 bisectable6 joined, benchable6 joined, tellable6 joined, statisfiable6 joined, committable6 joined 03:15 nativecallable6 joined, coverable6 joined 03:46 Kaiepi joined 05:50 benchable6 left, committable6 left, nativecallable6 left, statisfiable6 left, evalable6 left, greppable6 left, shareable6 left, bloatable6 left, sourceable6 left, reportable6 left, bisectable6 left, unicodable6 left, squashable6 left, tellable6 left, linkable6 left, evalable6 joined 05:51 benchable6 joined, greppable6 joined, bisectable6 joined, reportable6 joined, nativecallable6 joined, statisfiable6 joined, sourceable6 joined, bloatable6 joined 05:52 shareable6 joined, tellable6 joined 05:53 squashable6 joined, linkable6 joined, committable6 joined, unicodable6 joined 06:00 reportable6 left 06:02 reportable6 joined
Geth URI: 4e570bdc47 | (JJ Merelo)++ | 2 files
badge :arrow_up: + :see_no_evil:

Also closes #50 by adding a tag with current release		 07:26
07:30 epony left, epony joined
Geth ¦ problem-solving: JJ assigned to codesections Issue Choose some precise (or rough) way to "adopt" modules in the Raku Module Adoption center github.com/Raku/problem-solving/issues/355 07:52
08:14 epony left 08:19 epony joined 08:20 epony joined 08:41 sena_kun joined 08:58 sena_kun left
Geth URI: ea2cd064f2 | (JJ Merelo)++ | t/missing-components.t
Adds test for empty-parts, closes #42
 08:58
09:01 sena_kun joined
Geth URI/master: 4 commits pushed by (JJ Merelo)++ 09:29
URI: f0dd4ae6b4 | (JJ Merelo)++ | lib/URI.rakumod
:recycle: to improve coverage #52
 09:38
URI: 02742f2a85 | (JJ Merelo)++ | lib/URI.rakumod
:recycle: :coffin: uri is deprecated #52
URI: c2769a4165 | (JJ Merelo)++ | lib/URI.rakumod
:recycle: :coffin: init is deprecated #52
rakudo: michaelruigrok++ created pull request #5114:
Simplify X::TypeCheck::Assignment for containers		 10:18
10:21 sena_kun left 10:22 sena_kun joined 10:29 sena_kun left
Geth URI: c0250d7fd1 | (JJ Merelo)++ | 5 files
:coffin:
 10:37
URI: 42026d0c9e | (JJ Merelo)++ | 2 files
:coffin:
URI: a5d56402c1 | (JJ Merelo)++ | 2 files
Add auth too
rakudo: 1e30b43c00 | (Michael Ruigrok)++ (committed using GitHub Web editor) | src/core.c/Exception.pm6
Simplify X::TypeCheck::Assignment for containers (#5114)

For container assignment type errors, change the message from:
  "Type check failed in assignment to an element of <symbol>; expected <type> but got <type> (<value>)"
to
  "Type check failed for an element of <symbol>; expected <type> but got <type> (<value>)".
This removes possible confusion about assignment syntax. Possibly resolves #5110.		 10:54
10:55 linkable6 left 10:57 linkable6 joined 11:22 sena_kun joined 11:45 epony left 12:00 reportable6 left 12:01 reportable6 joined 12:26 epony joined 13:36 linkable6 left, evalable6 left 13:37 evalable6 joined, linkable6 joined
lizmat vrurg: any ideas of providing dynamic variables that have a different value depending on the language level ? 13:43
sortiz lizmat: Could you please review my PR #5113, I think it's trivial. 13:56
lizmat I'm ok with it, but we're close to a release, so I'll let the release manager decide 13:59
it's a trivial change, but the chance of it causing ecosystem fallout in testing, is significant
sortiz Oki. Thank you. 14:00
14:02 Kaipei joined 14:05 Kaiepi left
Geth rakudo/lizmat-least-most: 06f8879ffe | (Elizabeth Mattijsen)++ | 6 files
Introduce Least / Most

Work in progress as it unearthed a number of issues.
Introduce the dynamic variables $*LEAST and $*MOST as identifiers for the smallest and largest possible value (like -Inf and Inf, but without any typing). ... (10 more lines)		 14:12
rakudo: lizmat++ created pull request #5115:
Introduce Least / Most
[Coke] ^^ What problem is this trying to fix? 14:17
Geth rakudo/lizmat-least-most: 58b33c1ca0 | (Elizabeth Mattijsen)++ | 3 files
Fix basic tests
 14:21
lizmat ().min returning Inf, ().max returning -Inf which are numeric
m: my str @a; say @a.min 14:22
camelia Inf
lizmat the smallest on a native str array returning a Num
vrurg lizmat: not possible. The variable might be created by any language.
lizmat meh :-) 14:23
[Coke] m: <this that other cat>.min.say 14:24
camelia cat
[Coke] m: <meh ok>.min.say
camelia meh
lizmat afk for a few hours& 14:26
vrurg Out of the box I can think of a kind of a configuration class. class RakuDefaults { method value { pi } }. Then in 6.e core it can be class RakuDefaults is CORE::v6c::RakuDefaults { method value { e } }
14:27 sena_kun left, Altai-man joined 15:38 Kaipei left 16:29 sortiz left
nine_ lizmat: aren't -Inf/Inf exactly what Least/Most are supposed to be according to github.com/Raku/problem-solving/is...1331490466 16:29
m: say Inf cmp "cat" 16:30
camelia More
Nemokosch nine_: the other way around, rather. Least and Most are what -Inf and Inf were supposed to be (but aren't) 16:34
nine_ If -Inf and Inf are not what they are supposed to be, why not make them what they are supposed to be? Why instead add yet some new thing instead? 16:43
Nemokosch how are you gonna change the fact that Inf and -Inf are Nums? 16:44
while retaining backwards compatibility...
nine_ I wouldn't. And why would I need to do that? 16:45
Nemokosch because it's inconsistent that the minimum of an empty list of whatever non-Numeric type is a Num? 16:46
because it breaks the type system?
nine_ Apparently -Inf and Inf are supposed to be treated as undefined value for any (non-numeric) type. 16:47
Nemokosch Okay, how are you gonna achieve that without breaking the type system? 16:48
lizmat m: say Inf le "J" # nine
camelia True
nine_ I don't know. Haven't looked at it yet.
lizmat: looks like cmp is implemented correctly, while other operators aren't
lizmat so I guess we could add candidates to infix ops handling Inf 16:49
and -Inf
hmmm
nine_ Such candidates do exist for cmp but probably not for those others, so le stringifies the Inf and find's it smaller than J
lizmat yeah, duh, that's why the example 16:50
Nemokosch Anyways, this is not only a lot of work with minor breaking changes everywhere but I frankly have no idea how `Str $smallest = $input.words.min` will ever work with it. 16:51
when $input happens to contain no words 16:52
lizmat that would never work
or: that would only work if it returned Nil
fwiw, I think the behaviour of .min and .max predates the existence of Nil 16:53
Nemokosch does this possibly mean that the "old design documents" have no knowledge of Nil? 16:56
lizmat could well be 17:06
nine_ Actually Nil gets mentioned a lot by those docs 17:07
design.raku.org/S02.html#Nil 17:08
"Assigning Nil to any scalar container causes the container to throw out any contents and restore itself to an uninitialized state". If we treated -Inf and Inf the same way for any non-numericly typed container, Str $smallest = $input.words.min; would get you an undefined Str 17:10
lizmat the text of Nil is from 2015, the text of method min/max is from 2012 17:11
in S32-setting-library/Containers.pod
17:11 Kaipei joined
lizmat so I think my feeling in that regards is correct :-) 17:11
nine_ Contrary to what I've so far written may sound, turning Inf into another Nil doesn't sound like a winning strategy to me. It just bothers me when people talk about language design while dismissing the actual design documents. A lot of thought already went into the language to make it as awesomely consistent as it is. I'd hate for that to get drowned in a sea of bolted on solutions for odd corner cases. 17:14
I wonder, if turning Inf into a Nily thing doesn't work out. Can we turn Nil into Inf instead? I.e. make Nil be larger than the largest value and smaller than the smallest value for any type? 17:16
Nemokosch I'm about to finish my comment 17:23
I can say the same thing here as well, though. Design documents can be useful or not useful - just like the design itself can be good or bad. 17:27
In many cases, the design documents are super useful - here, whether you call it "dismissing" or not, I think the design document itself is totally unconvincing. 17:28
So I can say the same way that it bothers me when people talk about an admitted language design proposal just by reciting an old, unmaintained document that has proven to cause problems for many people in real-life scenarios. 17:29
(I intentionally phrased this in a radical way, to illustrate how your sentiment sounded to me.) 17:30
17:37 AlexDaniel left
Anyways, my impression is that there is a friction within the core regarding design documents, even more so than breaking changes. Some people say they are mostly historical documents, others say they would just need a little maintenance work to be virtually authoritative. 17:39
17:43 AlexDaniel joined
steering back towards Nil & friends - I'm not sure if Nil can be the biggest and the smallest value without breaking algebra... also, fun fact: Nil acts as 0 with `min` and `max`; I'm not sure if this is intended 17:44
and `0 cmp Nil` says "Use of Nil in string context"... 17:48
nine_ Of course, right now Nil isn't a working replacement for Inf. But maybe it could be? 17:53
Nemokosch I think this is a very dangerous territory, possibly the term "strangely consistent" would fit here. Let's say Nil could be a minimum and a maximum. Does that mean Nil < Nil? What about Nil >= Nil, then? And so on. 17:54
18:00 reportable6 left 18:03 reportable6 joined
Geth rakudo: 6cded78e9a | (Elizabeth Mattijsen)++ | src/core.c/Code.pm6
Make two WhateverCodes non-equivalent if different

In response to github.com/rakudo/rakudo/issues/5116
infix:<eqv> falls back to the calling .raku if two objects are of the same type. This makes sure that WhateverCode.raku will produce different strings for different WhateverCode objects.		 18:04
roast: e4f4f0945d | (Elizabeth Mattijsen)++ | S03-operators/eqv.t
Add tests for WhateverCode equivalence

See github.com/rakudo/rakudo/issues/5116		 18:12
18:14 Altai-man left
leont lizmat++ # that was a much quicker fix than I expected :-) 18:22
lizmat it was basically cat-licensed from Block.raku 18:23
the only thing tricky was referencing $!signature like that: it needed the nqp::getattr() as the attribute is not known in HLL space 18:24
Nemokosch What does HLL stand for? 18:27
nine_ High Level Language 18:29
[Coke] like raku, perl, etc. as opposed to nqp, or moarvm bytecode (or PIR if you're as old as I am) 18:31
Nemokosch that's in the PAST 😛
nine_ Depending on context, NQP may also be a HLL
Nemokosch oh okay, so it's an umbrella term? 18:35
In my mind, it was a mysterious third thing besides Raku and NQP 😅 18:36
[Coke] nine: fair; could just be "higher in the chain than what I'm writing in currently" 18:56
19:11 sortiz joined 20:18 sena_kun joined 20:21 epony left, epony joined 22:45 sena_kun left 22:48 sortiz 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!