00:36 Manifest left 01:44 kylese left 01:45 kylese joined
tbrowder 👍 02:02
02:15 kylese left 02:17 kylese joined 03:44 guifa left 04:03 Aedil joined 07:13 Aedil left 07:18 wayland76 left, wayland joined 07:40 lucerne left 09:59 sena_kun joined 10:04 lizmat_ joined, xinming_ left 10:06 lizmat_ left 10:10 xinming_ joined 10:14 lizmat_ joined 10:15 lizmat_ left 10:50 Sgeo left 11:25 xinming_ left 11:30 xinming_ joined 11:41 manu_ is now known as eseyman 11:50 Aedil joined
timo alioth-lists.debian.net/pipermail/...02853.html 13:03
13:03 Chanakan left
lizmat timo++ 13:04
timo (same kind of message for nqp and moarvm is also in those archives)
and dod++ for doing the actually difficult parts :D
lizmat so does that mean that Rakudo is back "in" as it were ? 13:05
timo well, there's a lot of places where rakudo can be "in or not", but you're probably refering to the relatively critical situation of rakudo getting dropped from debian? 13:06
lizmat yes 13:10
timo ok so my understanding is that we averted that crisis already a few weeks back 13:11
lizmat ah, ok :-)
timo qa.debian.org/developer.php?login=...debian.org here's a big ol' overview of versions of packages for the different suites / releases 13:12
the "raku" package which is rakudo + a few modules is currently blocked from migrating into testing, and i'm not exactly sure what the implications of that are 13:13
but the problem that prevents the migration is that a few modules are failing to build. at least one of which is giving "invalid or missing version of dependency" 13:18
test-meta6 actually fails some of its tests 13:19
# Cannot unmarshal ${} into type 'Positional' for attribute @!resources of 'Array[META6]+{JSON::Class}': type mismatch
bugs.debian.org/cgi-bin/bugreport....ug=1057611 13:20
14:51 kjp_ left
nijmegenzuigt can MoarVM be tuned or Raku rather that it requests/asks if an object can be destroyed/nilled? assuming shared memory among threads 14:53
lizmat objects will be destroyed at some point in time if they cannot be reached anymore 14:54
timo you can hold an explicit reference manually 14:56
it should not be possible for you to have an object that raku created be destroyed even though you can still somehow refer to it 14:57
nijmegenzuigt hmm better example would be: Roc lang for example (I think) to interface with Ruby/Python makes sure to ref count so memory gets freed 14:58
I kind of want to sidestep this issue with Raku interop
granted I am used to D's GC, despite how bad it is, lets you control when to collect 😛 15:00
timo: well then it wont be an issue 🙂 15:04
timo as soon as you manually call malloc and store the resulting pointer in an integer variable, on the other hand, you'll be on your own 15:09
15:13 xinming_ left
nijmegenzuigt malloc in Pascal, tsk tsk 15:13
timo well, whatever heap memory allocator you want, the issue would be identical 15:16
15:19 xinming_ joined 15:23 xinming_ left 15:25 xinming_ joined 15:43 xinming_ left
nijmegenzuigt 🥲 oh timo you miss the brilliance of some Pascal implementations 15:46
15:48 Tirifto left 15:56 Tirifto joined
librasteve hi all, I have got stuck on a functional coding / chaining issue ... any help over at stackoverflow.com/questions/790595...or-in-raku much appreciated! 16:25
antononcube @librasteve Have you tried multi infix:<xx> ... ? 16:30
librasteve holy crap - you are right (I also stopped stomping on xx) - what a silly oversight! 16:33
you want to post this on SO for me to approve or shall I self answer 16:34
timo aha, i guess with xx you get thunking semantics for the LHS so you get a Code object in $burrito 16:36
antononcube @librasteve Please self answer. I had a recent find on this while developing on "Math::SparseMatrix" and trying to get postcicumfix:<[]> work. 16:40
librasteve my bad for using xx as a placeholder cheat -- got more than I bargained for 16:43
antononcube BTW, lots of people helped with postcicumfix:<[]> . 16:44
timo do you know the o infix operator?
antononcube Well, two -- lizmat and tonyo -- but I am rounding up.
timo m: sub first($a) { say "doing first on $a"; 99 }; sub second($b) { say "doing second on $b"; 1024 }; say (&second o &first)(5432) 16:45
camelia doing first on 5432
doing second on 99
1024
antononcube @timo I was going to suggest o too, but I thought using xx is preferable for whatever reasons.
stackoverflow.com/q/67346926/14163984
nijmegenzuigt well whatever you guys are writing, the AST will make more sense 🥹
17:48 vrurg_ joined 17:50 vrurg left 18:22 Sgeo joined 19:09 abraxxa-home joined 19:19 Aedil left 19:36 abraxxa-home left 19:43 BinGOs left 20:55 bingos joined 20:57 bingos is now known as BinGOs 21:31 guifa joined 21:38 kjp joined 21:59 sena_kun left 22:01 kjp left, kjp joined 22:14 wayland left 22:23 razord joined
razord Hi everyone. After 15 years away from my 1st professional language, I'm back. Albeit back to Raku in addition to Perl. I am drinking through the firehouse as I reconnect. 22:29
I have a question about smartmatch and given. In Perl these have been depracated as having unpredictable behavior. Is the implementation in Raku different than in Perl? 22:31
timo yes, the reason why it works in raku but not in perl5 is because raku's type system is a lot more robust 22:37
well, part of the reason 22:38
and i think the implementation of smartmatch in perl5 was, perhaps only in the beginning, trying to make smartmatch symmetric? i may be misremembering 22:39
razord I read the effective programmer blog and he attributed it to the attempt to incorporate lexical $_, which turned out not to be so lexical. I saw separately a discussion of identical sorted list comparison that failed to evaluate to true because the sequence type was returned and not a list. It looks like that issue was resolved. For context, my personal interest is for best practices/safe code for myself. 23:03
I am new to IRC, so please inform me of etiquette and I will adjust. But smart comparison seems like an ambitious feature because comparison by its very nature is context dependent. An apple and an orange are different and the same depending on context. 23:13
23:32 Chanakan joined
[Coke] "is an apple an orange" is not the same question as "are an apple and an orange both fruit", though. So you'd ask your different question differently. 23:34
23:35 Chanakan left 23:41 Chanakan joined
guifa razord effectively as timo said, smartmatch works because there is a proper type system. Each type defines how it smart matches by defining a method called ACCEPTS 23:51
so I could make a universal matcher by doing
class TakesAnything { method ACCEPTS (\whatever) { True } } 23:52
(and the opposite doing false)
razord That is what I took away from the answer and am satisfied. I just wanted to make sure that if I adopted the usage I wouldn't lose it in a year because it was abandoned. 23:53
Thank you for the answers. Very informative. 23:54
guifa Yeah, it's a very integral / accepted part of the language, use and have fun :) 23:55
(also a cool way to make defining smart matches for custom classes easier: you can set a type on that ACCEPTS parameter, and make it multi. So if you had a JSON class, you could accept a string, convert to JSON, then compare, or just do the comparison directly if you got a JSON object, and do something else with array or hash. lots of freedom there) 23:57
razord The adoption of typing in Raku is a breath of fresh air. The number of ways that I have had to refine my identification schemes that could have been resolved with a simple type comparison is huge. I look forward to coding in Raku. It feels fresh and growing and changing. :) 23:58
That was in comparison to Perl. Sorry if I jump contexts, but I am both old and new. 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!