🦋 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:34 buildable6 left 00:37 buildable6 joined 01:37 buildable6 left 01:40 buildable6 joined
Geth rakudo: MasterDuke17++ created pull request #5441:
Use new stat-time-nanos syscall		 02:12
02:40 buildable6 left 02:41 buildable6 joined 02:46 buildable6 left, buildable6 joined 03:41 buildable6 left 03:43 buildable6 joined 03:47 buildable6 left, buildable6 joined 04:43 buildable6 left 04:46 buildable6 joined 05:46 buildable6 left 05:49 buildable6 joined 06:49 buildable6 left 06:52 buildable6 joined 06:56 buildable6 left 06:57 buildable6 joined
Geth rakudo/main: f1de73e9ed | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/ast/signature.rakumod
RakuAST: Avoid re-declaration of $_ in sub-sigs

This fixes the following code:
   for [1,2],[3,4] -> ($_,$b) { }
which was previously dying with the error that $_ is already declared.
With this change, we avoid this re-declaration without adding too much logic dedicated to this corner case.		 07:36
07:40 sena_kun joined 07:52 buildable6 left 07:54 buildable6 joined 08:54 buildable6 left 08:55 buildable6 joined
ab5tract_ lizmat: iiuc, the patch to fix RHS binding of $_ to LHS value in smartmatch is also ready 08:59
Geth rakudo/main: 790c7ac94c | ab5tract++ (committed by Elizabeth Mattijsen) | 2 files
RakuAST: Fix binding of $_ on smartmatch RHS

The smartmatch operator is supposed to bind the topic variable to the LHS value such that using the topic variable on the RHS will refer to the LHS.
This was already working in both base and RakuAST for cases such as: ... (21 more lines)		 09:00
rakudo/main: 7a3b2becd6 | ab5tract++ (committed by Elizabeth Mattijsen) | t/12-rakuast/regex-charclass.rakutest
RakuAST: Fix test cases to not use topic variable

These tests were relying on the (broken) behavior of base to just ignore that the topic variable is supposed to be bound to the LHS value during smartmatch operations.
ab5tract_ Eventually I’d like to add a worry so that $foo ~~ $_ for @potential-matches does not silently change behavior
But atm how to do so eludes me 09:02
nine: do you already have an idea about how we might implement warnings/errors that require more/full context? 09:03
Geth rakudo/main: 3a44581f62 | (Elizabeth Mattijsen)++ | 4 files
RakuAST: fix deparsing of regex modifiers

  - simplify RakuAST::Regex::InternalModifier subclasses
  - add a modifier attribute to RakuAST::Regex::InternalModifier
  - adjust .raku and deparsing accordingly
  - make sure modifiers are localized		 09:04
09:55 buildable6 left 09:57 buildable6 joined
Geth rakudo/main: 090e6f5116 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: fix localized deparsing for regex adverbs
 09:58
rakudo/main: 6a991a02d9 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: fix localized deparsing for postcircumfix adverbs
 10:11
nemokosch re smartmatching to the topic 10:53
I think one should at least ruminate a bit if wrong code makes it to the Rakudo tests 10:54
there are multiple possible takeaways but it seems like there is some fundamental issue behind the scenes 10:55
10:57 buildable6 left 10:58 buildable6 joined
lizmat
.oO( correctnes is in the eye of the beholder )
 11:00
|Tux| FYI, my home PC is 10½ years old and I am contemplationg replacing it with something more modern. That will make all timing look silly as of that momemnt 11:04
lizmat well, it will be closer to reality *now* and still be valuable as long as the sudden difference is understood 11:06
|Tux| and contemplation != bought, installed & up-and-running. Just a front-up notice 11:19
nemokosch "correctness is in the eye of the beholder" is a compromising statement about a formal language 11:25
lizmat
.oO( formality is in the eye of the beholder :-)
 11:26
nemokosch okay but then I don't get when somebody makes a sad face about Raku not getting a serious backer... 11:27
lizmat what I'm saying is that what may have been a formal definition in the past, may not be correct now anymore 11:31
nemokosch well then you picked up on the correctness approach 😛 11:36
in any case, the problematic code showed up in rakuast-related tests
I can't promise even to myself but if I ever have enough time and motivation at once, I will try to at least informally "specify" the de-facto behavior, in a similar spirit to the synopses 11:38
better (more manageable at the very least) to have some part accurately specified than touching all at once 11:39
lizmat ++nemokosch
nemokosch operators are always a fun topic for example... 11:40
11:58 buildable6 left 11:59 buildable6 joined 12:59 buildable6 left 13:02 buildable6 joined
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/10/23/2023-...leastober/ 13:09
14:02 buildable6 left 14:05 buildable6 joined 14:06 japhb left 14:16 japhb joined
ab5tract_ lizmat++ 14:19
[Coke] Is JJ the only person left on twitter/X at this point? 14:25
15:05 buildable6 left 15:06 buildable6 joined
|Tux| mee too 15:37
jdv pepper x is now the guiness confirmed hottest chili pepper 16:00
16:06 buildable6 left 16:08 buildable6 joined 16:12 buildable6 left, buildable6 joined 16:16 buildable6 left 16:17 buildable6 joined
Geth nqp/main: b0bbc4d570 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get new nano-based stat times
 16:35
rakudo/main: 8eee6c3976 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get new nano-based stat times
 16:44
rakudo/main: cc15340f41 | (Daniel Green)++ (committed by Elizabeth Mattijsen) | src/core.c/IO/Path.rakumod
Use new stat-time-nanos syscall

It gives more precision and is faster creating an `Instant` than using the num version.		 16:45
|Tux| Rakudo v2023.10-36-g6a991a02d (v6.d) on MoarVM 2023.10-2-g18604f691
csv-ip5xs0.898 - 1.014
csv-ip5xs-205.432 - 5.751
csv-parser3.845 - 5.135
csv-test-xs-200.399 - 0.501
test6.354 - 8.010
test-t1.582 - 1.598
test-t --race0.994 - 1.232
test-t-2020.945 - 24.512
test-t-20 --race6.896 - 7.581
 16:53
Text::CSV$ fez upload
✔
Text::CSV$ zef upload
syntax error. What does JJ want from me now?
17:08 buildable6 left 17:10 buildable6 joined 17:13 unicodable6 left, unicodable6 joined 17:15 buildable6 left, buildable6 joined
nemokosch what is "zef upload"? 17:25
jdv what is it? 17:26
ugexe there is no upload zef subcommand 17:27
nemokosch in any case, a new version of Text::CSV has been uploaded 17:28
jdv woohoo! 17:29
Geth rakudo/main: 06d9773ed1 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add RakuAST::Deparse::L10N module

  - load deparsing logic for all possible core localizations
  - export "localizations" logic with the two-letter codes of the
   available localizations
After loading this module, any RakuAST tree can be deparsed with just .DEPARSE($lang) where $lang is the two-letter code of the localization.		 18:04
ugexe i kind of wonder if all these L10N modules should go into something that is only installed optionally 18:05
lizmat that is an option, indeed 18:06
ugexe or at least put into a separate distribution somehow so they can be uninstalled 18:07
lizmat why would you uninstall them ?
18:10 buildable6 left
ugexe because they can't yet be installed optionally, so uninstalling them optionally is an alternative 18:12
18:14 buildable6 joined
lizmat because of the diskspaces it takes up ?? 18:15
ugexe even installing it optionally would require the to be a separate distribution though
among other things yeah
lizmat 92K in source atm
ugexe 92K of code there is a high chance I don't need though
lizmat FWIW, I sincerely hope that you (or I) will ultimately be the average user 18:16
ugexe if i have my dependencies self contained i dont want a bunch of module unrelated to anything else to be installed alongside
lizmat *NOT*
well, I guess that goes for just about all modules in lib except Test ? 18:17
ugexe and NativeCall
it is quite unfortunate the modules aren't logically separated
but that is made difficult because the build system would need to be updated to point at -Ilib-for-test -Ilib-for-nativecall etc 18:18
18:18 buildable6 left, buildable6 joined
lizmat I propose we fix this issue before 6.e, is that a plan? 18:19
ugexe yeah i suppose that is realistic 18:21
lizmat BTW, what would you think if all the localizations would be combined into a single file? 18:22
so for deparsing you would only have RakuAST::Deparse::L10N and that would contain *all* supported localizations 18:23
[Coke] I think ideally you'd keep them separate and only install the ones you cared about.
but I don't know how that meshes with the practicality of the implementation
ugexe yeah that would be more ideal, but that would mean making each localization its own distribution which seems a bit weird too 18:24
i'm not sure if i have a strong opinion on a single file vs multiple files
lizmat no, I mean: the generator now creates separate files for each language, but it could also combine them into a single file
ugexe its not that i dont want to see a bunch of files. its that i dont want to have to e.g. worry about the additional security footprint etc 18:25
so a lot of times people installing everything they need into one location for their app 18:26
lizmat so that would e.g. exclude lib/Test ?
as an app would probably not need that at runtime? 18:27
ugexe it could very well install Test
Test has to come from somewhere, but there are many ways that could happen and the details aren't really important in the context of the rest of this 18:28
lizmat but Test would (maybe) only be needed at installation time of an app, not at runtime?
[Coke] I use test at runtime for my scripts a lot 18:29
lizmat Ah? interesting...
[Coke] I'm testing things that aren't the module itself.
ugexe yes you could ignore Test in that situation, i was oversimplifying a bit, but as Coke notes it isn't so obvious always
[Coke] "are these git repos all in good shape?" 18:30
ugexe but for example I might want to be sure I'm using the same version of Test every time
that is getting into the territory of better know what you're doing though 18:31
since we don't ensure any of the core modules work for any other version of rakudo 18:32
the other benefit would be we can stop doing this arguably wrong tactic of conditionally including modules in the core distribution 18:35
a distribution should probably always include the same modules
notably we have MoarVM:: modules 18:36
lizmat you mean content-wise, or number of modules?
ugexe i'd probably argue that a pure-raku distribution should always have the same checksum
so both 18:37
lizmat the reason the MoarVM modules are optional, is that they may not compile on other backends 18:38
ugexe right, but conditionally including them in a distribution wasn't the best way forward there
lizmat well the source files are included unconditionally 18:39
ugexe github.com/rakudo/rakudo/blob/06d9...ku#L27-L34
like that should be one or more separate distributions 18:40
and then you optionally install those
lizmat so part of the Rakudo dist, but not installed by default is what you mean?
or in the ecosystem?
ugexe it can be installed by default, thats fine. it wouldn't be installed on JVM for instance though 18:41
and Raku org could dual life their modules into an ecosystem as well
lizmat indeed... but could we guarantee the same checksum on different backends anyway?
ugexe that isn't a sword we have to die on yet, i brought it up because it helps guide one to organize this code 18:43
but i'm not sure why the checksum for a given distribution couldn't be the same across two backends 18:44
obviously now it can't be
lizmat because we preprocess our source files for different backends, resulting in different bytecode 18:45
ugexe i'm not sure i'd count bytecode in my definition of a distribution 18:46
the only thing i can think of that complicates it is the #~jvm type directives
lizmat ah, ok, well, then that shouldn't be an issue :-)
so you would include the gen/* files in he distribution checksum? 18:47
ugexe no 18:48
for instance if there was a distribution for Test it would just be Test.rakumod and the META6.json file for it
for something like zef, it would be everything in bin/, resources/, lib/, and arguably t/ 18:49
lizmat I guess Raku could install an "install" script that would take some parameters, and then install MoarVM modules, or L10N modules 18:50
which would depend on META6.json files somewhere ?
ugexe i'd probably just do like we do now but iterate over all the distributions and conditionally ignore them based on an environment variable 18:51
lizmat so after you did the base install of Rakudo, you could do an "install L10N"
ugexe rakudo/lib/distributions/Test/lib/Test.rakumod, rakudo/lib/distributions/Test/META6.json
19:14 buildable6 left 19:15 buildable6 joined
Geth rakudo/main: f6e7475b36 | (Elizabeth Mattijsen)++ | 7 files
RakuAST: add preliminary localization tests
 19:44
rakudo/main: f3a7c045ee | (Elizabeth Mattijsen)++ | tools/templates/moar/Makefile.in
Make sure t/13-localization tests are actually run

With "make test"		 19:52
20:15 buildable6 left 20:16 buildable6 joined
vrurg lizmat: Are newlines simply ignored when parsing rakudoc? 20:29
I mean, not all of them, apparently. But some. 20:30
nemokosch a lot are, for sure 21:00
if you take a look at the docs, it's all broken into reasonably short lines
bartolin committable6: 2015.07.2,2015.10 (1..10) * 10 21:06
committable6 bartolin, ¦2015.07.2: «» ¦2015.10: «WARNINGS:␤Useless use of "*" in expression "(1..10) * 10" in sink context (line 1)␤»
bartolin committable6: 2015.07.2,2015.10 say (1..10) * 10
committable6 bartolin, ¦2015.07.2: «100␤» ¦2015.10: «10..100␤»
nemokosch Range-as-a-pair 21:07
21:09 guifa joined
bartolin yeah. Personally, I found it interesting to read the premise that using Range objects in item context would usually be "non-sensical": github.com/Raku/old-design-docs/bl...in=1#L3634 21:11
21:16 buildable6 left 21:19 buildable6 joined
nemokosch what does it even mean, lol 21:31
in any case, I think there should be some odd feeling about (1..10) * 10 being 10..100
this operation is clearly not taken from math 21:32
or if it is, not from a concept like interval but a concept like vector!
in which case one would ask what I forgot to ask in the issue: what if you multiply it by a negative number? 21:33
m: (1..10) * -1 andthen .say
evalable6 -1..-10
Raku eval -1..-10
nemokosch if you guessed that the result would be a bizarre range 21:34
that coerces to True but has .elems == 0
then you are excellent at guessing but perhaps this is not healthy
Geth rakudo: vrurg++ created pull request #5442:
Don't drop out empty lines where they a part of the text		 21:39
nemokosch I'm baffled by this fixation on the special-casing of Ranges, not going to lie 22:04
Larry is right even if he changes his mind - but which Larry is right, then? 22:05
vrurg Did I mention Larry anywhere? Why do you deprive me in the right to have own mind? 22:15
nemokosch that's kind of a harsh assumption 22:16
you are not deprived of anything
neither did I say that you mentioned Larry anywhere 22:17
vrurg Re-read your sense above. It doesn't point at anyone in particular but looks like it point at everyone at once. This, actually, has a name: manipulation. That's when an impression created but it's hard to object to it.
nemokosch your conclusions are reaching too far 22:18
if there is a word you could rightfully react to, that's "fixation"
you are accusing me of manipulation which is very out of my character 22:19
I'm saying it straight ahead why I used the word "fixation": you seem to be changing the arguments in contradictory ways only to always reach to the same conclusion
22:19 buildable6 left 22:21 buildable6 joined
vrurg I only point at the impression your statement created. Nothing less, nothing more. I have certain problems with expressing myself. When I see that somebody got me wrong – I apologize. I said it all.] 22:21
nemokosch by the way, telling me to re-read my sentence, when we are typing in a channel that is completely unrelated to the whole discussion, so why are you even assuming people will take it as you are being talked about? there were multiple people involved and some of them referenced Larry Wall, including me indirectly at least
I'm telling you though, that one cannot simoltaneously state Ranges are not countable and that they are iterable 22:22
not because I forbid
but because it's a contradiction
22:28 sena_kun left
japhb An infinite iteration is still an iteration 22:34
tellable6 2023-10-09T17:21:41Z #raku <Xliff> japhb Looking for Terminal::Widgets help. How would you write a select list with it?
japhb Wow, guess I've been off channel a while.
Xliff -- are you still looking for Terminal::Widgets advice? That was ~3 weeks ago I think. 22:35
Oh, I guess I should do that as:
.ask Xliff Are you still looking for Terminal::Widgets advice? That was ~3 weeks ago I think.
tellable6 japhb, I'll pass your message to Xliff
nemokosch yes but alef null is still countable 22:36
the concept of iterability really maps to "countable sets" 22:37
japhb I suppose this may be true of classical ranges, but it's no true of general iterables *in the Raku sense*, because a List can contain lazy sequences that have truly unknown size, while you *can* try to iterate it. So there's no solid definition of the ordinality of a lazy list, but it is still Iterable. 23:19
Could be finite, could be infinite, could be *not actually pure* 23:20
Could be the ordinality is more like "it depends"\ 23:21
nemokosch In this context, I'd say ranges are actually enough. They are the kind of iterable that is purely coutable
Countable* 23:22
23:22 buildable6 left
Also depends on what we mean by "countable". By definition, anything you can iterate, you can map to natural numbers. You might not be able to offhand tell the length but like you can model the mapping 23:25
23:25 buildable6 joined
A math example would be the sequence of prime numbers 23:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!