00:18 simcop2387 joined 01:09 Aedil left 02:42 hulk joined 02:43 kylese left 03:15 hulk left, kylese joined 04:05 lichtkind left 04:24 kjp left 04:25 kjp joined 04:27 kjp left, kjp joined 05:07 Aedil joined 05:18 derpydoo joined 06:05 sibl joined 08:56 cryosis left 08:58 cryosis joined 09:53 abraxxa joined 10:29 sibl left
lizmat weekly: dev.to/wkusnierczyk/two-bugs-one-symptom-24h3 10:42
notable6 lizmat, Noted! (weekly)
lizmat weekly: rakuforprediction.wordpress.com/20...c-glow-up/
notable6 lizmat, Noted! (weekly)
11:16 sibl joined
nemokosch hm, that article 11:33
is that a server and a client at once?
> It's an emergent property of running a server and client in the same process when both rely on cooperative scheduling 11:35
so apparently yes
lizmat yeah, you could argue that it is a case of DIHWIDT... but on the other hand the (non) error reporting is pretty LTA 11:36
nemokosch yes, perhaps
it's a bit hard, to be honest, like Raku quite deliberately breaks any sort of compatibility with oldschool regex
and yet there is this situation where it seems Raku just has to take oldschool regex into account nevertheless 11:37
/ ^ / for example is a quite idiomatic way to write "match just the beginning" imo, whether that's useful or not 11:38
also, I'm not 100% sure but doesn't ^ indicate "beginning of line" in oldschool regex? 11:39
lizmat I think it depends on the flavour of regex 11:40
11:40 Sgeo left
nemokosch my point is that it feels if we have to report about /^ /, we are very close to outright reporting "WARNING: please be aware that you are using a language with different regex syntax and rules" 11:41
lizmat don't let me stop you :-)
nemokosch and like nobody is really wrong here 11:42
it's a "legitimate conflict of interests" kind of situation 11:43
Let's say one wanted a warning - what would trigger it? 11:52
Zero-length substitutions (especially compile- time known) could 11:53
Something (not sure what) about space placement could 11:54
11:55 oodani left 11:56 oodani joined 11:57 oodani left, oodani joined
lizmat I guess .subst could warn if there is a match, but it didn't match any characters 12:08
12:44 sibl left 12:50 johnjay left
lizmat weekly: dev.to/lizmat/tweak-build-fhg 13:10
notable6 lizmat, Noted! (weekly)
13:36 wayland76 joined 13:37 wayland left
Voldenet cool article about build, but 13:38
>Making an attribute immutable
bind… makes it far from immutable
m: class Foo { has $.bar is built(:bind); }; my $n = 1; my $a = Foo.new(bar => $n); $n = 2; say $a.bar # I mean, it's actually less immutable that way 13:39
camelia 2
lizmat heh.. interesting 13:40
I'd qualify that as a bug, actually
or maybe not....
it wasn't intended that way, let's put it this way
Voldenet the way I understand it is that it does bind a container and the value inside the container changes 13:42
m: class Foo { has $.bar is built(:bind); }; my $n = 1; my $a = Foo.new(bar => $n); $n := 2; say $a.bar # In this case it's still 1
camelia 1
Voldenet to make it truly immutable, the container passed to bind to bar would have to be immutable as well 13:43
m: class Foo { has $.bar is built(:bind); }; my $n := 1; my $a = Foo.new(bar => $n); $n = 2; say $a.bar # Error
camelia Cannot assign to an immutable value
in block <unit> at <tmp> line 1
lizmat in that case $n is *not* a container, but the value 1 13:44
Voldenet yes 13:45
lizmat ok, I guess I'm going to remove that from the post for now :-) 13:46
Voldenet Idk, it's an useful feature actually
a useful, even
lizmat yeah... I would need to think about that .... 13:47
Voldenet though bind is quite difficult to explain easily
lizmat indeed... sometimes I wonder whether a course in Raku shouldn't start with "bind" 13:50
as grokking containers / binding is really a rite of passage in efficient Raku usage
*for
13:54 abraxxa1 joined 13:56 johnjay joined 14:00 abraxxa1 left, abraxxa1 joined
Voldenet maybe not start, because bind is not needed to write code, though if someone comes from java binding is very different mental model 14:01
14:03 johnjay left
nemokosch My argument for starting with binding is that it's the simple primitive operation 14:33
No syntax magic, no semantics magic
SmokeMachine github.com/FCO/ValueClass 14:48
15:47 abraxxa1 left 15:52 abraxxa left
Voldenet yeah so are referencing and dereferencing ;) 16:16
16:18 librasteve_ left
nemokosch of course 16:50
17:26 jgaz joined 19:16 Sgeo joined 19:17 hvxgr left 19:22 hvxgr joined
lizmat weekly: dev.to/lizmat/the-second-two-1k5d 19:30
notable6 lizmat, Noted! (weekly)
19:39 stanrifkin joined 20:18 johnjay joined 20:23 johnjay left 20:25 johnjay joined 20:38 arkiuat joined
arkiuat so I guess the moral of the `is built(:bind)` story is: only initialize immutable attributes with immutable initializers 20:38
21:25 abraxxa joined 21:35 stanrifkin left 21:59 wayland76 left 22:03 arkiuat left 22:05 arkiuat joined, Aedil left 22:15 arkiuat left 22:17 ds7832 joined 22:19 arkiuat joined, oodani left 22:21 oodani joined 22:31 jgaz left 22:45 ds7832 left 22:46 ds7832 joined
lizmat arkiut: still mulling over that actually... 23:19
23:22 abraxxa left 23:43 ds7832 left
arkiuat well, that was my takeaway. If I'm going to configure an immutable attribute using `is built(:bind)`, then I'd want to make sure that anything I feed into .new() for that attribute is a literal, or a container bound to a literal e.g. a constant 23:45
otherwise i'd be opening myself up for spooky action at a distance, if I were to feed it a variable that was subject to later modification elsewhere
so i guess the other option is to make darn sure that any variable i feed to it disappears immediately afterward, so extremely-local lexicals would be okay too, I guess 23:47
23:54 ds7832 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!