🦋 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.
00:00 reportable6 left 00:01 reportable6 joined 00:05 NemokoschKiwi joined
NemokoschKiwi bisectable: class Test { method gist { 'gist' }; method Str { 'Str' } }; say "ez egy {Test.new}"; 00:05
bisectable6 NemokoschKiwi, Will bisect the whole range automagically because no endpoints were provided, hang tight
NemokoschKiwi, ¦6c (68 commits): «ez egy Str␤» 00:06
NemokoschKiwi, Nothing to bisect!
NemokoschKiwi oh right
m: class Test { method gist { 'gist' }; method Str { 'Str' } }; say "Ez egy ", Test.new;
camelia Ez egy gist
NemokoschKiwi fair
00:07 NemokoschKiwi left 04:57 tbrowder__ left, tbrowder__ joined 06:00 reportable6 left, reportable6 joined
Geth rakudo/main: ebe8322a3d | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: probably last round of de-capturing <sym>
 08:12
lizmat hmmm.. TIL that you cannot pass a hash as an argument in a "use" statement and expect it to be received by an EXPORT sub :-( 08:24
the hash will be interpreted as named arguments, and thus as "tags" 08:25
meh
09:25 greppable6 left, nativecallable6 left, statisfiable6 left, bloatable6 left, sourceable6 left, coverable6 left, bisectable6 left, linkable6 left, benchable6 left, committable6 left, unicodable6 left, tellable6 left, reportable6 left, quotable6 left, notable6 left, releasable6 left, shareable6 left, squashable6 left, evalable6 left, unicodable6 joined 09:26 greppable6 joined, squashable6 joined, bisectable6 joined, nativecallable6 joined, linkable6 joined, releasable6 joined, benchable6 joined, statisfiable6 joined 09:27 bloatable6 joined, evalable6 joined, notable6 joined, tellable6 joined, coverable6 joined, reportable6 joined 09:28 quotable6 joined, committable6 joined, sourceable6 joined, shareable6 joined
nemokosch this is exactly the kind of thing that fuels my anxiety when using Raku, this "do what I mean" except I just wanted to use a user-space data type 10:04
it's not easy to notice as long as you are in but now that I started doing some Javascript again, the difference can be felt 10:07
the confidence that the same thing will always happen regardless the underlying data
Geth rakudo/main: 6771c4ae20 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove valid identifier check for now

  - it's use is limited anyway
  - may interfere with other natural language versions		 11:59
12:00 reportable6 left 12:01 reportable6 joined
Geth rakudo/main: e46425c591 | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/L10N/NL.rakumod
RakuAST: export the translation hash

So that it can be used for other purposes, such as generating the appropriate slang tokens		 12:45
rakudo/main: 8e375870d3 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: add xlation hooks for (cont) and (elem) infixes
 12:53
rakudo/main: 6175970e04 | (Justin DeVuyst)++ | tools/templates/NQP_REVISION
Bump NQP in prep for release
 13:33
[Coke] That time already, wow. 13:57
Question: shouldn't we bump NQP *sooner* so folks using HEAD hit any issues? 13:58
BUmping it just before the release means we're not getting CI tests on it, etc. 13:59
(not getting them as soon as possible, anyway) 14:02
Or do we have a CI pipeline that is testing head/head/head ?
vrurg No, as far as I remember. In my view it makes not so much sense. But NQP bump could have been done as a PR first and PRs are getting their CI. 14:03
[Coke] Ah, good point. 14:25
jdv it was just for a doc update 15:04
i was about to do a blin run but its cranky again. we'll see if we can keep sched. 15:06
[Coke] never did get blin running locally 15:12
jdv yeah, i was workingbon that:( 15:26
16:15 leont left, leont joined
vrurg I was once told that blin wouldn't be running on macOS because it is using pre-build linux images. Though I still wonder what's the problem to implement local caching and build revisions when necessary? It would be slower, but better than nothing. 16:38
Besides, having spare 1TB I wouldn't care about having a lot of local copies. :)
lizmat ( hope to switch to an M2 MacMini in a few months, I will use my current dev MacMini for blin on MacOS 16:41
vrurg I'm totally happy with my m2 mac studio. Not sure when would be able to get 100% CPU load on a real life task. Perhaps, when do some video editing. 16:43
jdv theres a lot of builds. itd be a project to do a whole other arch. 17:08
iirc its 30gb well compressed, maybe 120gb less compressed. 17:09
lizmat is not worried about the disk space 17:14
Geth rakudo/main: f1c6261c46 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: remove special translator actions

These appear to cause problems when mixing in slangs. Since the actions are pretty simple, just run that code in the grammar. This appears to fix the initial teething issues for other natural language versions of Raku.		 17:15
jdv builds arent fast either:) 17:19
if someone has the resources thatd be cool 17:20
18:00 reportable6 left, reportable6 joined
[Coke] we have a few m2s in the wild we could split up the work 18:15
jdv might take a few months:) 19:15
[Coke]: good luck my man! 19:16
i think for the linux buildcwe have from '12 or '14 but just the last year would probably be enough at first 19:17
[Coke] Yah, it's the sort of thing we could autofill. releases first, then nqp bumps, then... 19:18
be nice if we could have a client/server to say "I can build one now..." like the ole distributed.net jobs 19:19
jdv maybe kinda. that coukd take a blin run from hours to weeks:)
blin just runs current and then bisects off last release, then bisects off whole. iirc. 19:20
a build still takes many minutes 19:21
[Coke] ok, so if we're picking ones to build, everything from the last release, then back releases, then bumps, then ... most recent to oldest?
I'm just saying to make the builds, not to run all of blin on each one of those.
but then we'd have them for whateverable 19:22
jdv its somewhere in the code but id build reverse chrono and wed probably be good quickly
"for most cases":( 19:23
:)
github.com/Raku/whateverable/blob/...6#L90:L105 is the core of it iirc 19:27
nemokosch it's good that somebody at least has clues about how it works 19:41
Geth File-Find: tbrowder++ created pull request #44:
Convert to three separate os workflows and badges		 19:58
20:00 linkable6 left, evalable6 left 20:02 linkable6 joined 20:03 evalable6 joined
jdv i have just enuf clue to operate it 20:10
ugexe tbrowder__: i think that is duplicating a lot of things and will make it harder to maintain changes 20:28
it looks like the reason you are doing this is to conditionally do something different on windows, but that can be done without separate workflow files
for example: github.com/ugexe/zef/blob/4bda1a1c...#L104-L106 20:30
tbrowder__ that’s true, but someone looking at the readme can easily see its status. most packages combining all into one show failures now due to bad prove 6 20:31
ugexe i would probably argue that once a distribution is green on all OS, that having separate badges for each one isn't neccesary because changes that break it in the future on other OS shouldn't be getting merged in at all 20:32
but it does appear that if one wants separate badges for different OS on gh actions that you do have to have separate workflow files 20:34
tbrowder__ my main concern is the author who does not have access to other os can fiddle more easily with separate workflow files 20:36
speaking for myself
ugexe maybe, but i think it would be a bigger concern that they now have to manage 3x as many files
you wouldn't write the same function 3 different times and put it in 3 different modules of the same distribution would you? 20:37
i agree having separate badges does make it a bit easier without any real drawback, but having separate nearly identical workflow files (which is what it takes to accomplish the former) does have drawbacks 20:38
tbrowder__ no, but workflow files are not the same kind of animal 20:39
i don’t speak yaml much 20:40
nemokosch let's be frank. There have been like 2 or 3 people in the whole Raku community who could write CI workflows
tbrowder__ check
ugexe the language doesn't really matter. the lesson there is about keeping all the logic in sync between those three files 20:41
nemokosch These files will be probably changed only once: when they break and somebody finally adds a new, working version
tbrowder__ well, it’s a PR and he can enjoy it ot ignore it 20:42
*or
i don’t like clicking on actions to see which os failed 20:43
and why
ugexe i'd put myself in the group of believing they know how to write these CI workflows, and i'd have to reiterate the benefits of reuse. the 'not having to update the files' often part is only really relevant when someone who knows how to write CI workflows does it... for instance in the windows one above it only tests a single file so in the future anyone who adds a new file to t/ has to update that 20:44
nemokosch I'm not really concerned, for one
ugexe workflow (if they even know they need to)
nemokosch that has nothing to do with the file duplication, though 20:45
ugexe it does 20:46
even if someone does think to check the CI, they also need to know to check all three
as well as figure out what the difference is between them 20:47
nemokosch no, regarding the "only tests a single file", that's because of how the testing is implemented in exactly one file, regardless whether that's the only file or there are others
ugexe that was to demonstrate the benefits of code reuse, even for something like yaml 20:48
nemokosch then I don't get how it demonstrated that 20:49
anyway, do as you please, frankly
ugexe i don't think anyone was asking for permission, but thanks
20:49 finanalyst joined
nemokosch then I don't know what is the point of arguing for something that seems to have no relevance to the people seemingly involved 20:50
ugexe oh, you were arguing with me. sorry, i was mostly just babbling on about what i would and would not do in CI since i have some familiarity in this area and people might be interested 20:52
nemokosch the point is, nobody opposes vehemently, if you feel strongly about it, you can surely do it yourself
ugexe oh i understand that. i'm surprised you think that I was not aware of those options though 20:54
nemokosch I was requested a review because nobody seemed to care originally either, except me. And in my opinion, what you say makes perfect sense, except for the fact that there is an estimate of zero individuals who will maintain the workflow, which kind of blows the whole deal away 20:55
20:56 finanalyst left
It's not that surprising really, after all, you kept pushing, as if there was some sort of backlash. I wanted to assure you there is none. It's just worth nothing in my personal opinion. 20:57
ugexe ah, again i was just babbling on to tbrowder to give them some advice in an area they seem to be doing some learning on. i usually like when people describe why they might do things a certain way, but if you feel like you're personally being pressured by it i can refrain from technical discussions when you're active 21:04
nemokosch I don't feel pressured by it, I just assumed that you say it with an immediate outcome in mind 21:18
tbrowder: I changed the Windows workflow to a zef test based version so that the files don't have to be enumerated. Seems working. You can merge if you agree. (I think you have a commit bit?) 21:46
22:06 linkable6 left, evalable6 left, evalable6 joined 22:07 linkable6 joined 23:27 ilogger2 left, ilogger2 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!