|
🦋 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. |
|||
|
01:30
nine left,
nine joined
02:37
japhb left
02:42
japhb joined
03:08
apogee_ntv left
03:09
apogee_ntv joined
07:00
finanalyst joined
08:18
finanalyst left
10:33
gfldex left
10:34
gfldex joined
11:21
guifa left
|
|||
| Geth | rakudo: heyajulia++ created pull request #5936: Change enum's raku method to return valid code |
11:34 | |
| roast: heyajulia++ created pull request #879: Add test for enum's raku method |
|||
|
11:49
guifa joined
12:17
guifa left
|
|||
| Geth | rakudo/main: 5e8d7f6567 | Julia++ (committed using GitHub Web editor) | src/core.c/Enumeration.rakumod Change enum's raku method to return valid code (#5936) Fixes #5935 |
12:48 | |
| roast: 51e8aff2cf | Julia++ (committed using GitHub Web editor) | S12-enums/misc.t Add test for enum's raku method (#879) This test aims to ensure that calling the raku method on a enum member returns valid code when the enum member is an emoji. See rakudo/rakudo#5935. |
12:51 | ||
| linkable6 | ROAST#879 [closed]: github.com/Raku/roast/pull/879 Add test for enum's raku method | ||
| RAKUDO#5935 [closed]: github.com/rakudo/rakudo/issues/5935 [good first issue] `raku` method returns invalid code for emoji enum members | |||
| [Coke] | julia++ | 12:52 | |
| Geth | roast: 1dfe687e4c | (Elizabeth Mattijsen)++ | S12-enums/basic.t Adapted tests to more correct enum.raku representation For an enum A <👍 👎>, A::👍 is not a grammatically correct .raku representation, but A::<👍> *is*. As described in: github.com/rakudo/rakudo/pull/5936 |
13:01 | |
| lizmat | weekly: github.com/Raku/problem-solving/issues/490 | 14:17 | |
| notable6 | lizmat, Noted! (weekly) | ||
| lizmat | tonyo ugexe ^^ | ||
| ugexe | im a bit confused, the ability of those two tools to not handle that trait shouldn't be an argument against it | 14:21 | |
| zef handles api perfectly fine | |||
| so i dont understand why we wouldn't consider those things bugs of those programs | 14:22 | ||
| lizmat | because fixing those bugs would mean considerable effort, for a very small result | 14:24 | |
| ugexe | if you take that to its logical conclusion one might argue that mi6 can't be used at all because it uses a separator that is also valid in the module name and version | ||
| no that is not a reason to change the language spec | |||
| i'm not sure why you think fixing it would take considerable effort | 14:25 | ||
| lizmat | so what would be a reason for you to allow identical name:auth:version: but with different :api ? | ||
| ugexe | there are a few, but first i'd point out that not immediately being able to think of what those are also shouldn't be a reason for removing a feature. as for why... why does e.g. debian have packages like gtk2, gtk3, where part of the version is encoded into the name itself? adding a level of abstraction why wouldn't it make sense to have a gtk native call module with api 2 or 3, and a separate | 14:30 | |
| version for the raku module updates themselves? | |||
|
15:00
guifa joined
|
|||
| lizmat | true | 15:08 | |
| tonyo | i thought the api field was for versioning the META file, not for specifying the dist api. for the scenario above loading it would just `use Gtk:ver<2.*>` noo? | 15:44 | |
| ugexe | there are versions of the native code (the api it provides). then is the version of the nativecall raku module itself | 15:47 | |
| [Coke] | I thought api was one of the 4 attributes on the distro. what does it mean to version a META file | ||
| ugexe | versioning the meta file is theoretically done with github.com/Raku/old-design-docs/bl...ta-version | ||
|
18:47
melezhik joined
|
|||
| jdv | lizmat: how's that whateverable move? | 18:47 | |
|
18:51
melezhik left
|
|||
| lizmat | jdv: stalled on the fact that I couldn't get any test running :-( | 19:05 | |
| jdv | ok, how can we fix that? | 19:07 | |
| can coke or i finish it or do some part(s)... | 19:08 | ||
| lizmat | well, at this moment, my head is firmly in SBOM/PURL land, I don't expect to be able to work on it until the weekend | ||
| jdv | i guess if i could fork and release under me | 19:09 | |
| ok, thanks | |||
| lizmat | the work I've done is in a branch | ||
| jdv | ok | 19:10 | |
| lizmat | the "communification" branch | ||
|
22:14
guifa left
22:15
guifa joined
|
|||