🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:08 reportable6 left
Geth rakudo: e521c8e45b | (Vadim Belman)++ | 2 files
Fix method put failing on junctions

Resolves #4742. Aside of plain throwing `(1|2).put` also fix recursive cases when a junction is an eigenstate of another junction.
rakudo: ba4d233283 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #4743 from vrurg/rakudo-4742

Fix method put failing on junctions
roast: ecb92756c1 | (Vadim Belman)++ | S03-junctions/misc.t
Add tests for basic IO over junctions

Make sure `say`, `put`, `print`, and `note` all work as expected.
roast: dfc4cf7e52 | (Vadim Belman)++ (committed using GitHub Web editor) | S03-junctions/misc.t
Merge pull request #788 from vrurg/rakudo-4742

Add tests for basic IO over junctions
01:14 linkable6 left 03:15 linkable6 joined
Geth rakudo: vrurg++ created pull request #4744:
Do some better job optimizing Junction on RHS
04:01 CIAvash left, AlexDaniel left 04:08 reportable6 joined 04:36 CIAvash joined 04:48 CIAvash left 05:26 rypervenche left 06:07 reportable6 left 06:10 reportable6 joined 07:56 squashable6 left, linkable6 left, reportable6 left, bloatable6 left, coverable6 left, unicodable6 left, statisfiable6 left, notable6 left, tellable6 left, releasable6 left, quotable6 left, committable6 left, nativecallable6 left, bisectable6 left, benchable6 left, shareable6 left, greppable6 left, sourceable6 left, evalable6 left 07:57 tellable6 joined, bisectable6 joined 07:58 evalable6 joined, statisfiable6 joined, coverable6 joined, reportable6 joined 07:59 squashable6 joined, quotable6 joined 08:57 nativecallable6 joined, committable6 joined, releasable6 joined 08:58 benchable6 joined, bloatable6 joined, greppable6 joined 08:59 linkable6 joined
lizmat Files=1351, Tests=117097, 285 wallclock secs (35.05 usr 9.79 sys + 4002.62 cusr 335.68 csys = 4383.14 CPU) 09:48
09:57 unicodable6 joined, notable6 joined 09:58 shareable6 joined 10:09 Xliff joined
Geth rakudo/lizmat-show-precompilation: 0aaed91bfe | (Elizabeth Mattijsen)++ | 2 files
Add "use show-precompilation" as a pragma

Activates the RAKUDO_PRECOMPILATION_PROGRESS environment variable, perhaps making this feature a little more rememberable / accessible.
rakudo: lizmat++ created pull request #4746:
Add "use show-precompilation" as a pragma
10:43 Xliff left
Geth rakudo/lizmat-named-anywhere: 94590f6e55 | (Elizabeth Mattijsen)++ | 2 files
Add "use named-anywhere" as a pragma

In an attempt to make the "use named arguments on the command line at any location" feature more rememberable and accessible.
Sets named-anywhere key in the %*SUB-MAIN-OPTS has if it already exists, or creates it in PROCESS:: with the named-anywhere key set in it.
rakudo: lizmat++ created pull request #4747:
Add "use named-anywhere" as a pragma
11:27 frost joined 11:59 sourceable6 joined 12:09 reportable6 left 12:10 reportable6 joined 12:19 frost left 13:19 benchable6 left, greppable6 left, coverable6 left, unicodable6 left, shareable6 left, committable6 left, releasable6 left, sourceable6 left, quotable6 left, tellable6 left, reportable6 left, evalable6 left, linkable6 left, notable6 left, statisfiable6 left, squashable6 left, nativecallable6 left, bisectable6 left, bloatable6 left, evalable6 joined 13:20 releasable6 joined, tellable6 joined, bloatable6 joined, unicodable6 joined, benchable6 joined, quotable6 joined, greppable6 joined 13:21 sourceable6 joined, statisfiable6 joined 13:22 bisectable6 joined, linkable6 joined, Xliff joined 14:14 carlmasak joined
carlmasak greetings, #raku-dev 14:14
lizmat carlmasak o/ 14:15
so what's up in the far east ? 14:20
14:20 committable6 joined 14:21 squashable6 joined
carlmasak the folks around here don't really "do" Christmas (except in a hilariously misappropriated kind of way), but they do practice Spring Festival. which started (in my case) about five hours ago \o/ 14:25
lizmat ah... good!
carlmasak I foresee some nice coding sessions in my near future, as well as some more-than-decent food, and time with family
how are things in the, uh, middle-distance west? 14:26
lizmat it feels like spring here, but it's very windy and still a tad too cold
carlmasak I feel like the weather this week was very "not yet Spring Festival": rain, clouds, clouds with rain, rain with snow, clouds with rain and snow 14:27
lizmat lockdown is being lifted while the number of young people with Covid in hospital is on the rise
ah, yes, that feels familiar
storm expected for tomorrow here :-)
carlmasak yes, I'm tracking Europe pretty closely. the numbers look... a bit wild
(pandemic/omicron, not storm)
lizmat yeah :-( 14:28
carlmasak half of my family in Sweden, as well as some friends, either just got or just had omicron
lizmat hopefully not too badly 14:29
carlmasak no, seems like a heavy cold, just about
I'm assuming most of those were vaccinated a few times
lizmat well, that's the thing, vaccination below 30 is still pretty low :-( 14:31
carlmasak I'm not surprised. both because of the game theory of it all, and because young people tend to come out of it alright 14:32
lizmat except if they don't
carlmasak right, 'course. just saying that playing the odds in their case does make some sense 14:33
it's a little bit selfish, but it's not irrational 14:34
lizmat well, I'm just thinking about polio: "Years after recovery, post-polio syndrome may occur, with a slow development of muscle weakness similar to that which the person had during the initial infection"
I hope we don't see something like that for Covid
carlmasak I read something similar on Charlie Stross's blog, yes 14:35
it could happen
lizmat yeah :-( and we already know there's a thing called "long covid" 14:36
carlmasak we do 14:37
lizmat well, on the brighter side: there's FOSDEM next Saturday, and I'm happy that my presentation has been recorded and uploaded :-) 14:38
carlmasak ooh! tell me more? what's it about?
lizmat fosdem.org/2022/schedule/track/raku/ 14:39
carlmasak neat 14:41
I've been thinking about something similar lately -- let's see if I can describe it
there's a level of all this where you just import/export between compilation units, and they're a bit isolated from each other in a good way. I call that level "modules", which works quite well with the Raku terminology 14:42
but then there's a level which incorporates that but adds the dimension of time/authors/versions. I call that level "packages", which is not an agreed-on term 14:43
briefly, I believe very few -- maybe zero -- languages get packages "right" 14:44
lizmat yeah I think the META of a distribution should become more introspectable
so, if a module is installed with a META giving an an auth:<zef:lizmat> and a :ver<0.0.14> 14:45
then all use targets installed from that module should:
a. be installed with that meta information embedded in their HOW (the .^ver and .^auth methods on the classes) 14:46
b. any use of a target *without* qualification should automatically have the :ver and :auth added to their requirement 14:47
carlmasak I think golang gets packages the least wrong of all the languages I know about. they do because they spent a really impressive effort thinking it through
lizmat in a distribution with :ver<0.42> and :auth<zef:lizmat>, and use target referring to another use target from the same distribution, should have these added 14:48
ok, need to be afk for linner&
carlmasak I think packages, done right, could look closer to Git commits: immutable, globally unique, and completely reproducible 14:49
nine Incidentally that's how precomp files are 14:50
carlmasak nine! \o/
yes, I could imagine there are some right ideas in there 14:51
nine carlmasak: I'd ask you how you are, but I've already read the answer in the history :) 14:54
carlmasak heh. I'm fine indeed. more exactly, I'm on my first beer, and the night is (relatively) young 14:55
how're you, nine? 14:56
nine I just came home from a week long snowboarding vacation, so couldn't be better :) 14:57
carlmasak npm gets packages wrong, in a way that _has_ affected me: installing modules will automatically choose the newest possible, which is not "stable"/reproducible in the way I mean
nine: no broken thumbs? then it's indeed a good snowboarding vacation :D 14:58
nine No, I'm a....a bit surprised, but I seem to have gotten away without any injuries at all this time :D
carlmasak also, lockfiles seem to be a symptom of getting the reproducibility stuff wrong on a lower level 14:59
golang does without lockfiles, because their dependency system defaults to being reproducible
nine Pick newest and get unreproducible results with constant breakages because developers suck at backwards compatibility or pin versions and get issues because developers suck at keeping dependencies up to date. Feels like a lose-lose. 15:00
carlmasak no, I don't think so
"keeping dependencies up to date" should be a conscious move, not a thing forced on you by the package manager
the truth is, different projects have different preferences on that. it's a spectrum, of sorts 15:01
nine: if you haven't read rsc's series on this, I highly recommend it. it's... opinionated, but I find the opinions interesting 15:03
nine It's also influenced by developer culture. It almost worked in Perl where pinning just isn't a thing and backwards compat was usually maintained. For most time at work we've gotten by with installing latest but at even there we've switched to installing from an internal repository 15:04
carlmasak yeah 15:05
I think I'm just very interested in what the OOP world calls "the fragile base class problem". to me, when you see the extent of that problem, it basically ruins the idea of class inheritance forever. and a very similar situation holds between package dependencies 15:06
the reason Liskov substitutability is hard is that all those laws/properties in our APIs are implicit in the code; they maybe don't change often, but when they do, they mess things up. I haven't seen a good solution to that, except "put the decision to upgrade squarely in the consumer's hands" 15:08
semantic versioning... helps, I guess. but it's also not a perfect solution. there's simply no way to track those implicit laws/invariants 15:09
nine IMHO the underlying problem is that it all depends on humans. We cannot keep a non-trivial codebase at once in our heads lest have a fully accurate model of how it will behave, so we can never judge accurately what effects a change will have. 15:12
carlmasak the thing we expect to get out of abstraction is exactly that, the luxury of not caring about all the details 15:14
on the one hand, it's super-comfortable to just say "I want X, Y, and Z", and your node_modules fills up with literally megabytes of other people's source code that just happen to solve your problems 15:15
on the other hand, you've taken on a definite risk by not caring. I've lost count of how many left-pad incidents we're up to at this point 15:16
both of these perspectives can be true at once
but I think that they're easier to reconcile if you also have reproducible builds (which means no spontaneous upgrading of dependencies) 15:19
15:20 reportable6 joined, notable6 joined 15:21 shareable6 joined
carlmasak maybe the analogy between Git commits and immutable/reproducible packages is not so incidental -- maybe it's more or less literal 15:22
15:22 nativecallable6 joined
ugexe we use github.com/dependabot at work 15:25
carlmasak if I check out the same Git commit, I get _exactly_ the same files. if I build the same package (and its dependencies), I get _exactly_ the same target files
I think dependabot makes sense. it tells people when an upgrade is advisable, and those who have a vested interest in safety over stability tend to heed that 15:26
(by the way, does anyone else feel that "prototype pollution" is the "SQL injection attack" of the JavaScript universe?) 15:27
15:50 Geth left 15:51 Geth joined, RakuIRCLogger__ left 15:52 andinus left 15:53 andinus` joined 16:55 carlmasak left 17:00 carlmasak joined 17:05 carlmasak left 17:07 carlmasak joined 17:22 coverable6 joined 17:29 carlmasak left 18:07 reportable6 left 18:51 AlexDaniel joined 19:03 CIAvash joined 19:09 reportable6 joined 19:19 AlexDaniel left 19:23 CIAvash left
Geth roast: rafaelschipiura++ created pull request #789:
1.Num doesn't produce Int.
roast: 495054fde1 | (Rafael Schipiura)++ (committed using GitHub Web editor) | S02-literals/numeric.t
1.Num doesn't produce Int.
roast: 8436273b77 | MasterDuke17++ (committed using GitHub Web editor) | S02-literals/numeric.t
Merge pull request #789 from rafaelschipiura/patch-1
20:27 linkable6 left, evalable6 left, evalable6 joined
tonyo .tell carlmasak if you haven't, check out haskell's package management. go's isn't great, there are a lot of problems with the way go.mod works, particularly when you're doing stuff inside of containers. haskell's is 22:29
tellable6 tonyo, I'll pass your message to carlmasak
tonyo .tell carlmasak pretty great but also v picky
tellable6 tonyo, I'll pass your message to carlmasak