|
🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
|
00:24
Summer left,
itaipu left,
Summer joined
00:37
itaipu joined
00:50
Manifest0 left
00:55
Summer left,
Summer joined
01:25
Summer left
01:26
Summer joined
01:28
bdju joined
01:54
oodani left
01:55
oodani joined
01:56
Summer left
01:57
Summer joined
02:20
MasterDuke joined
02:32
MasterDuke left
02:33
hulk joined
02:34
kylese left
03:15
hulk left,
kylese joined
03:21
Summer left,
Summer joined
03:31
andinus left,
andinus joined
03:52
Summer left,
Summer joined
04:22
Summer left
04:23
Summer joined
04:41
vrurg left
04:53
Summer left,
Summer joined
05:24
Summer left,
Summer joined
06:34
constxqt_ left
07:11
verzit_ joined
08:01
samebchase left
08:03
verzit_ left
09:02
snonux left
09:04
Manifest0 joined
09:26
samebchase joined
09:35
snonux joined
10:37
sena_kun joined
11:13
verzit_ joined
11:14
derpydoo joined
11:39
constxqt_ joined
11:46
derpydoo left
11:51
derpydoo joined
11:59
Sgeo left
12:30
verzit_ left
13:44
epony left
13:49
verzit_ joined
14:19
vrurg joined,
verzit_ left
14:54
izel joined
|
|||
| izel | hi isn't the following contradictory | 14:56 | |
| m: my %h{List} = (0, 0), 3; %h{%h.keys.head}.say | |||
| camelia | Type check failed in binding to parameter 'key'; expected List but got Int (0) in block <unit> at <tmp> line 1 |
||
| izel | may i never reach values of %h by manual key | 14:57 | |
| ugexe | something seems off about that. it works when using List.new: but not with .List | 15:08 | |
| m: my %h{List} = (0, 0), 3; %h{%h.keys.head.List}.say | |||
| camelia | Type check failed in binding to parameter 'key'; expected List but got Int (0) in block <unit> at <tmp> line 1 |
||
| ugexe | m: my %h{List} = (0, 0), 3; %h{List.new: %h.keys.head}.say | ||
| camelia | (3) | ||
| lizmat | probably better with my %h{Positional} ? | 15:12 | |
| izel | Positional gives the same error | 15:19 | |
| well except expected Positional instead of List | |||
| List.new version gives back a List as a value not single value but thanks | 15:20 | ||
| i'm using Tuple it seems to work | |||
| except i cannot `say %h` | |||
| it errors with "This representation (VMArray) does not support attribute storage (for type Tuple)" | |||
| nemokosch | what even is "type Tuple"? | 15:29 | |
| izel | google it | 15:30 | |
|
15:34
vrurg_ joined
|
|||
| nemokosch | there is no such thing in Raku | 15:36 | |
|
15:36
vrurg left
15:37
vrurg_ is now known as vrurg
15:53
MasterDuke joined
|
|||
| lizmat | nemokosch probably raku.land/zef:lizmat/Tuple | 16:17 | |
| roguerakudev | Is it possible to hook into object construction before accessors for attributes are generated? I thought BUILD would do it, but doing .set_rw on an attribute in BUILD doesn't make the generated accessor return-rw | 16:24 | |
| For context, I want to reuse the same event class for both sync and async events, and for the former case I want to make any publicly-readable attributes also publicly-writeable by mixing in a role | 16:26 | ||
|
16:26
izel left
|
|||
| might need to do traits on the members instead | 16:30 | ||
| trait would be better as it would give more fine-grained control, but I'm not sure how that would look, because you don't know until a specific instance is created whether it's for sync or async, and thus whether an rw accessor should be generated | 16:33 | ||
| actually that's not even good enough, because the object has to be constructed before the mixin is applied anyway | 16:36 | ||
| nvm you can mix in before calling new | 16:37 | ||
|
16:37
derpydoo left
|
|||
| lizmat | BUILD and TWEAK are runtime, you're really talking about compile (composition) time | 16:38 | |
| roguerakudev | so X but Y is compile-time? | 16:44 | |
| or for this purpose, I guess the question is will it be if X and Y are known at compile time | 16:45 | ||
| or maybe I don't need to worry about that, if I just add_method in the trait_mod:<is> for my custom trait, then have the method itself look at whether the role in question got mixed in | 16:46 | ||
| I may have rubber-ducked into a solution :P | 16:47 | ||
|
16:49
epony joined
|
|||
| lizmat | roguerakudev please post a link to your solution :-) more eyes on code help! | 16:50 | |
|
16:57
Summer left
|
|||
| roguerakudev | Not quite there yet... need to figure out how to get the ClassHOW for the class the Attribute is part of, so I can .add_method | 17:05 | |
| lizmat | call .^add_method ? | 17:06 | |
| roguerakudev | well, on what is the question... in multi trait_mod:<is>(Attribute $attr, :$sync-rw!) all I have access to is the Attribute itself | 17:09 | |
|
17:24
dpb left
|
|||
| I could pass $?CLASS in when using the trait, but that feels icky | 17:41 | ||
|
17:48
derpydoo joined
|
|||
| guifa | Attribute has a .package() method | 18:08 | |
| I use that in Intl::CLDR for adding aliases via traits: github.com/alabamenhu/Intl-CLDR/bl...akumod#L38 | 18:09 | ||
| roguerakudev | Aha, finally got it: gist.github.com/landyacht/1b35ed25...41cff69046 | 18:41 | |
| It took some digging through Rakudo source and many rounds of trial and error, but the result is actually not all that messy | 18:43 | ||
| quite happy with this | |||
| paging lizmat re: "more eyes on code help" | 18:45 | ||
| guifa | so just a heads up: wrapping can be a bit slow. You might consider actually generating the method yourself. I don't do a whole lot with that but lizmat I know has some better experience | 18:47 | |
| roguerakudev | Hm, good point - I didn't go that route b/c the code for generating the method inside Attribute::compose is rather long and uses nqp | 18:49 | |
| guifa | that's fair | ||
| the nice thing is unless it becomes a bottleneck for whatever you're doing, what you have works great | |||
| roguerakudev | But I do want this software I'm writing to be pretty fast, so wrap being slow is a real concern | ||
| I wonder if it's any faster to straight up remove the generated method from the table and add back in one that calls that method in a wrap-y way without actually using .wrap | 18:50 | ||
| lizmat | roguerakudev Am in the middle of 3 things at the moment, and 4 would be at least 1 too many... will look in an hour or so | ||
| roguerakudev | I don't know how much hackage the "remove the method" part entails though :P | 18:51 | |
| guifa is going to try something quickly | 18:53 | ||
| antononcube | @lizmat I wrote the Jupyter notebook with article. Since the images are two big I have to some image export and resizing. I hope to have the Markdwon version within few hours. | ||
| lizmat | antononcube WP is pretty good at resizing | 18:54 | |
| guifa | roguerakudev: how about something like this? | 19:00 | |
| tio.run/##XY9NbsJADIX3c4qHlAVIkAWq...A9K3sq77AA | |||
|
19:00
verzit_ joined
|
|||
| roguerakudev | Oh right, Attribute's composition skips generating if there's already a method there | 19:02 | |
| so mine is overcomplicated haha | 19:03 | ||
| nice, thanks | |||
| I also didn't realize get_value would return something writeable | 19:04 | ||
| Is there a reason you're doing set_rw? | |||
| guifa | it might not be necessary, I just noticed you had it. I'd assume there's some internal machinations to set up the writability part | 19:06 | |
| but it actually seems to work okay without it so | |||
| roguerakudev | I set it because Attribute's compose method looks at it, and I wanted the method it generated to return-rw | 19:07 | |
| since I figured trying to return-rw something that was originally returned as a readonly container wouldn't work | |||
| Awesome, your solution structure works for my use case as well | 19:10 | ||
|
19:12
epony left
19:14
epony joined
|
|||
| lizmat | it appears roguerakudev no longer needs my eyes :-) | 19:27 | |
| Geth | advent/main: 4736296ce5 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | raku-advent-2023/authors.md move vushu's post to the 19th |
19:44 | |
|
20:16
Sgeo joined
|
|||
| librasteve | my 3rd is ready for Scheduling btw | 20:56 | |
| lizmat | librasteve cool, will attend to it nnow | 20:58 | |
| librasteve | ok if you want to shift the Day | 21:10 | |
| lizmat | ok, will make it the 20th then :-) | ||
| El_Che | hi | ||
| librasteve | k | ||
| yo | 21:11 | ||
| Geth | advent/main: 90e529f95a | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | raku-advent-2023/authors.md Move craggy to the 20th |
21:19 | |
|
22:30
MasterDuke left
23:10
verzit_ left
23:18
sena_kun left
|
|||