00:07 reportable6 left 00:08 reportable6 joined
ugexe it does make sense to put zef on fez for update purposes. i've been waiting on 1) unbitrotting all my distribuions [done] 2) creating github releases of all my distributions [done] 3) creating a script to release fez dists from my github releases 01:00
01:08 linkable6 left, evalable6 left 01:10 linkable6 joined, evalable6 joined 01:40 MasterDuke joined 02:00 vrurg joined 02:04 vrurg left 02:34 jmcgnh left 02:56 jmcgnh joined 03:05 xinming joined 04:01 vrurg joined 04:06 vrurg left 04:25 vrurg joined 05:11 vrurg left, vrurg joined 05:12 vrurg left, vrurg joined 05:17 vrurg left 06:07 reportable6 left 06:09 reportable6 joined 06:31 nebuchadnezzar left
Nemokosch Oh right, I wanted to ask about self-upgrade 06:35
06:48 Sgeo left 06:57 abraxxa joined 07:00 abraxxa left, abraxxa joined 07:05 abraxxa left 07:06 abraxxa joined 07:08 jjido joined 07:17 MoC joined 07:37 abraxxa left 07:39 lichtkind_ joined 07:55 abraxxa joined 08:07 jjido left 08:18 nebuchadnezzar joined 08:26 sena_kun joined 08:37 jmcgnh left 08:46 jmcgnh joined 09:00 Nemokosch joined 09:02 Nemokosch left 09:23 m_athias left, nine left, camelia left, nine joined, m_athias joined 09:29 camelia joined 09:40 Nemokosch joined 09:52 MoC left 10:01 jjido joined 10:08 jjido left 10:09 Altai-man joined
Xliff \o 10:28
tellable6 2022-09-18T09:44:54Z #raku-dev <lizmat> Xliff did you re-run the configuration ?
Xliff Is there a way to tell an exception that it is not fatal?
lizmat: Yes. I reran the configuration. It's still taking over 70 seconds to compile CORE.c 10:29
lizmat .resume
10:30 frost joined
lizmat m: CATCH { .resume }; say "before"; die; say "afterlife" 10:30
camelia before
Xliff lizmat: How about in the exceptions declaration? 10:31
lizmat aren't you talking about a warning then, aka a subclass of CX::Warn ? 10:32
Xliff Hmmm... quite possibly. Would that subclass look similar to a subclassed expression? Is there documentation on that? 10:33
s/expression/exception/ - Please forgive me, I have not been caf'd yet. 10:36
lizmat hmmm..... looks like that part of Raku is .... underdeveloped 10:38
Xliff :( 10:39
lizmat looks like nqp::setextype(, nqp::const::CONTROL_WARN) is actually creating a CX::Warn under the hood somehow
:q 10:40
Xliff :)
m: class OOB is CX::Warn { method message { "Out of Bounds!" }; }; my $a; sub setA ($na) { OOB.new.throw unless $a < 5 }; setA(5); setA(10) 10:41
camelia Use of uninitialized value of type Any in numeric context
in sub setA at <tmp> line 1
Use of uninitialized value of type Any in numeric context
in sub setA at <tmp> line 1
Xliff m: class OOB is CX::Warn { method message { "Out of Bounds!" }; }; my $a; sub setA ($na) { OOB.new.throw unless $n < 5 }; setA(5); setA(10)
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$n' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> ; sub setA ($na) { OOB.new.throw unless ⏏$n < 5 }; setA(5); se…
Xliff m: class OOB is CX::Warn { method message { "Out of Bounds!" }; }; my $a; sub setA ($na) { OOB.new.throw unless $na < 5 }; setA(5); setA(10) 10:42
camelia control exception without handler
in sub setA at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat yeah, that one
Xliff :/
Yeah, I remember this one, now. I always have to CATCH and use $*ERR.say in my GLib code.
lizmat but in your example, what would be wrong about "warn "Out of Bounds" unless $a < 5" ? 10:43
Xliff It's up to 780Kloc, now.
lizmat wow 10:44
Xliff lizmat: I was hoping to formalize the "Out of Bounds" condition. "warn" doesn't do that. A CX::Warn would.
lizmat well, it would help if "warn" didn't expect strings
Xliff I would love it if Exception would have a .warn instead of .throw. 10:45
Would that be a difficult thing to implement?
lizmat don't actually think so, lemme see 10:46
Xliff \o/
elcaro Asked on the Discord, but adding here for more eyeballs... 10:47
m: say (class :: { has $!a = 'x'; method gist { $!a } }).new.WHAT;
camelia Cannot look up attributes in a <anon|1> type object. Did you forget a '.new'?
in method gist at <tmp> line 1
in block <unit> at <tmp> line 1
elcaro why doesn't .WHAT like when I refer to an attribute in my gist?
Kaiepi idt it's WHAT as much as gist from say 10:49
m: say (class :: { has $!a = 'x'; method gist { self.DEFINITE ?? $!a !! callsame } }).new.WHAT;
camelia (<anon|1>)
Kaiepi attributes may only exist on an instance
or be referred to
Nemokosch okay, so they cannot exist on type objects at all? 10:50
Kaiepi nope. you need a method or lexically scoped something or other 10:51
Nemokosch that's good to know actually 🙂 10:54
so I suppose gist should be defined in a way that it's prepared to handle type objects 10:56
Xliff m: (class :: { has $!a = 'x'; method gist { $!a } }).new.gist.say 10:57
camelia x
Nemokosch iirc there is a way to put type smileys for "self"
Xliff The problem here isn't the attribute, it's the fact it's an anonymous type. 10:58
Therefore it has no name for WHAT to handle.
Kaiepi gist exists on any object you'd encounter under ordinary circumstances, so this sould just take a `multi method gist(::?CLASS:D:) { $!a }` 10:59
Xliff So .WHAT has a minor bug that needs to be addressed.
m: (class :: { has $!a = 'x'; method gist { $!a } }).new.^name.say
camelia <anon|1>
Xliff m: (class :: { has $!a = 'x'; method gist { $!a } }).new.WHAT,say
camelia ===SORRY!===
Argument to "say" seems to be malformed
at <tmp>:1
------> 'x'; method gist { $!a } }).new.WHAT,say⏏<EOL>
Other potential difficulties:
Unsupported use of bare "say". In Raku please use: .say if you meant
Nemokosch Xliff: elcaro also showed a code example with a named class 11:00
Xliff Nemokosch: Didn't see that in IRC. Did I miss it?
m: (class A { has $!a = 'x'; method gist { $!a } }).new.WHAT,say
camelia ===SORRY!===
Argument to "say" seems to be malformed
at <tmp>:1
------> 'x'; method gist { $!a } }).new.WHAT,say⏏<EOL>
Other potential difficulties:
Unsupported use of bare "say". In Raku please use: .say if you meant
lizmat make sure the gist method is a multi:
m: say (class :: { has $!a = "x"; multi method gist(::?CLASS:D:) { $!a } }).new.WHAT
camelia (<anon|1>)
Nemokosch Xliff: no, moment
lizmat m: say (class :: { has $!a = "x"; multi method gist(::?CLASS:D:) { $!a } }).WHAT
camelia (<anon|1>)
Kaiepi .WHAT is very primitive and literal 11:01
Xliff m: (class :: { has $!a = 'x'; multi method gist (::?CLASS:D: ) { $!a } }).new.WHAT,say
camelia ===SORRY!===
Argument to "say" seems to be malformed
at <tmp>:1
------> t (::?CLASS:D: ) { $!a } }).new.WHAT,say⏏<EOL>
Other potential difficulties:
Unsupported use of bare "say". In Raku please use: .say if you meant
Xliff m: (class :: { has $!a = 'x'; multi method gist (::?CLASS:D: ) { $!a } }).new.WHAT.say
camelia (<anon|1>)
Xliff lizmat++
Nemokosch gist.github.com/2colours/d874683fb...e8d0e021e7 there we go 11:02
Kaiepi because WHAT's not even a method on anything in particular this can happen:
Xliff Nemokosch - See workaround/fix from lizmat
Kaiepi m: say (*.WHAT).DEFINED
camelia No such method 'DEFINED' for invocant of type 'Whatever'. Did you mean
in block <unit> at <tmp> line 1
Kaiepi uhhh
not what i was going for but ok
m: say (*.WHAT).DEFINITE
camelia False
Kaiepi there we go 11:03
if it thunked to WhateverCode:D that'd be different
Nemokosch I think it's worth noting somewhere that type objects cannot have attributes. It makes sense if we think of them as kinda prototypes but still, good to have it written off somewhere. 11:04
Kaiepi that'd belong somewhere on the objects page i think?
Nemokosch the solutions you guys offered are really sensible
Nemokosch oh I'm logged in here, the latency is smaller :D 11:05
Kaiepi: I think this is the closest part: docs.raku.org/language/classtut#in...ype_object 11:06
Kaiepi there's a less glossy page that says it's per-instance state docs.raku.org/language/objects#Attributes
Nemokosch Hmm, again, I think it makes sense if we think about it but it's a bit obscure. Like it's not explicitly mentioned, you can just figure that type objects are not "instances" but more like one object representing the class as data. 11:09
I think type objects themselves are a bit obscure, with relations to object instances and classes. 11:11
Although this may not be a place for the docs per se. Maybe more something for guides and tutorials. 11:12
11:23 jjido joined
lizmat Xliff: github.com/rakudo/rakudo/pull/5065 11:27
11:53 vrurg joined 11:57 vrurg left 12:07 reportable6 left 12:08 reportable6 joined
[Coke] hates 2-space for indent in code, but somehow all his META6.json files across projects seem to be stuck at this level (presumably from the first one I copied ages ago) 12:08
lizmat FWIW, if you use App::Mi6, it will normalize at 2 spaces as well 12:09
[Coke] "ew" 12:12
so, never use that, got it, thanks. :)
12:15 frost left
Nemokosch Can that not be configured or turned off? 12:16
[Coke] Looks like it's using Rakudo::Internals::JSON to emit the JSON, fwiw. 12:18
Nemokosch Yes, I'm also looking at that github.com/skaji/mi6/blob/d96645bd...rakumod#L3 12:20
[Coke] which itself is configurable, but would need a small patch to MI6 to use an env var or something to set it. 12:21
Easy peasy, which I will do if I ever start using mi6 (right now fez itself is fine.)
Nemokosch Where can I find Rakudo::Internals::JSON? 12:22
12:24 Nemokosch left
[Coke] * :watch: [Sep-23] - Inna Bembenok's last day! 12:49
Oops 12:50
13:11 jjido left
Xliff lizmat++! 13:21
lizmat: CORE.c compile time is still - Stage parse : 70.822
I don't know what the hell could be in my environment that would cause this.
tbrowder hi, where is the use of "some-sub($some-arg, |c)" discussed in the docs? ah, yes, in "language|functions"; good reading ... 13:33
13:34 xinming left 13:46 abraxxa left 13:48 lichtkind_ left
tbrowder and also read "types|class Capture"... 14:13
14:30 Tirifto left 14:33 Tirifto joined 14:44 [Coke]_ joined 14:45 [Coke] left 14:48 Sgeo joined 14:58 xinming joined 15:05 [Coke]_ is now known as [Coke]
[Coke] looks at www.reddit.com/r/rakulang/comments...xtensions/ and wonders how that might work 15:05
summary: can we call objective-c using NativeCall
15:11 MoC joined
lizmat twitter.com/marcelpociot/status/15...8074348549 # looks like eminently doable with RakuAST 15:21
SmokeMachine lizmat: Hi! Sorry for interrupting, but it seems rad --editor is struggling to find the columns on regex searches. usercontent.irccloud-cdn.com/file/...8%402x.png 15:32
tellable6 2022-09-15T22:15:38Z #raku <melezhik> SmokeMachine sparkyci moved to ci.sparrowhub.io , please update CI badges, you can find new link from "my repos" page - ci.sparrowhub.io/repos
lizmat SmokeMachine: please make an issue otherwise it might fall through the cracks :-)
SmokeMachine 👍 15:33
lizmat: github.com/lizmat/App-Rak/issues/13 15:38
lizmat thanks!
15:38 Altai-man left 15:39 Altai-man joined, MoC left, MoC_ joined 15:40 MoC_ is now known as MoC
[Coke] 'zef install App::Rak' on windows explodes interestingly. 15:43
lizmat ah? 15:44
[Coke] gist.github.com/coke/b38b3494ebf8c...8f52e97afa 15:45
lizmat is that just for App::Rak, or more general 15:46
[Coke] updating zef, seeing if I can narrow it down.
lizmat zef install hyperize e.g. ? no deps and so on 15:47
[Coke] might be the old "can't install from rea on windows" bug 15:48
updated zef. installed hyperize no problem.
Voldenet i've just installed hyperize on ancient zef (v0.13.4) on windows 15:50
15:50 bigdata joined
Voldenet `zef install App::Rak` also worked, it's fairly surprising considering it's rakudo 2021.12 15:53
[Coke] So the trick seems to be String::Utils. I can install the latest, but something seems to depend on String::Utils:ver<0.0.8> which does complain when I try to install it directly. 15:54
(see the last line of the gist, same error) 15:55
Voldenet that makes sense, I've had string::utils already 15:56
[Coke] All App::Rak deps pinned at specific versions instead of allowing newer? 15:57
looks like String::Utils already up to 0.0.12
(and I can install that version)
lizmat yes, I *always* pin my dependencies completely
so if there is an issue in the pinning, that should be caught by the Github Actions 15:58
and it's still green afaics
[Coke] ok. should I report a bug on App::Rak asking to update the S::U dep? 15:59
lizmat yes, please
I'm very close to releasing 0.97, which has a complete rewrite of all argument handling (at 124 currently supported options, it was needed)
and a load of other fixes... 16:01
[Coke] github.com/lizmat/App-Rak/issues/14 16:03
lizmat thanks!
[Coke] Thanks.
I can 'zef look' that specific version, run the tests, it's OK. weird. 16:08
will add that note.
er... that was on a mac box in a different shell. right, zef look itself fails on windows.
lizmat ok, maybe a new feature of the latest update :-( 16:09
ugexe ^^
[Coke] it was failing on zef 0.13... still failing on 0.14 16:10
doubt it's strictly the "rea has problems on windows due to long paths" because it's the only thing failing here.
lizmat could you run with --/rea ?
[Coke] github.com/Raku/REA/issues/7 16:11
nope, same error
lizmat: let me know if you want, I can try to install from a git clone that has an updated dependency and whatever other new changes before you cut a release. 16:13
... I can try that now with just that dep change if you like.
lizmat [Coke]: normally, I'd say yes... but the changed between the released version and the one I'm about to release, are massive 16:14
16:14 jetchisel left
[Coke] ok 16:14
let me try this one small change locally then.
lizmat so I'd rather release that and see if the problem persists than spend time now on figuring out what is now a 2 week old version :-)
[Coke] github already at 0.0.10 of S::U... 16:15
ugexe if you think it might be path length you can do `SET TMPDIR=C:\tmp` to shorten the length of the temp directory being used and see if it passes
might have to create that directory oo 16:16
see github.com/ugexe/zef/blob/6a14c383...yml#L9-L12
[Coke] lizmat: I can install App::Rak out of github master
but rak --help generates a page of "use of uniti..." 16:17
16:17 jetchisel joined
lizmat [Coke]: hmmm... weird... 16:17
16:22 [Coke]_ joined 16:24 [Coke] left
[Coke]_ lizmat: let me know, happy to test master or run something specific. 16:24
16:25 [Coke]_ is now known as [Coke]
[Coke] raku -Ilib bin/rak -> "No such method 'Version' for invocat of type 'Any'" 16:25
lizmat raku -I. bin/rak ? 16:26
16:29 [Coke]_ joined
[Coke]_ same output whether I add --help, or --version, or test - warnings, no output 16:29
(sorry, just bounced) 16:30
lizmat raku -I. bin/rak ?
in general, -Ilib is a P5ism
16:31 [Coke] left
lizmat you should in Raku really always use -I. in a repo 16:31
[Coke]_ is the lib automatically searched?
lizmat nope, but if you do -Ilib, it doesn't see the META6.json, and that is needed for things like $?DISTRIBUTION and the like 16:32
[Coke]_ (and -Ilib works in all of my modules, weird)
16:32 [Coke]_ is now known as [Coke]
[Coke] raku -I. bin/rak avoids the error, but then all I have are unitialized warnings, and no output, whether I run --help, test, etc. 16:32
lizmat none of your modules use $?DISTRIBUTION or %?RESOURCES
[Coke] Sure 16:33
lizmat I assume :-)
[Coke] Mine are all pretty simple, aye
verified -I. works, mental model updated. 16:34
(for my stuff, App::Rak still busted here.)
m: say +$*USER; #lizmat 16:38
camelia Use of uninitialized value of type Any in numeric context
in block <unit> at <tmp> line 1
[Coke] Weird, I expected something here; that's giving the warning on windows, I think. 16:39
lizmat m: say +$*USER
camelia Use of uninitialized value of type Any in numeric context
in block <unit> at <tmp> line 1
[Coke] from path-utils setup
on my mac I get a number. 16:40
lizmat m: say $*USER
camelia (Any)
lizmat interesting, that's a Rakudo bug
[Coke] maybe because camelia's in some kind of box.
raku -e 'dd $*USER' on windows: Any 16:41
lizmat meh: once if !Rakudo::Internals.IS-WIN
[Coke] want me to open a rakudo ticket?
lizmat m: dd qx/LC_MESSAGES=POSIX id/ 16:42
camelia ""
lizmat [Coke]: what does ^^ do on Win ?
[Coke] lots of warnings and "" 16:43
however, "id" by itself is returning something in git bash
lizmat ok, I guess I will need to add some the docs of --user and --group
that it depends on $*USER and $*GROUP working in your Rakudo 16:44
[Coke] Is there a workaround you can do to avoid all the warning output and have other features work? 16:45
I wouldn't expect to have to have a user id to grep through docs. 16:46
lizmat I'll make sure that 0.97 will just meh out if $*USER or $*GROUP doesn't work
ugexe -Ilib will work with $?DISTRIBUTION, but it will be generated unlike -I. which uses what your META6.json says 16:47
so it might not behave the same as when its installed, hence always use -I.
[Coke] tbrowder: can we close github.com/rakudo/rakudo/issues/5022 ? 16:48
lizmat: what does meh out mean? 16:49
I saw meh in your code, so I'm guessing something specific.
lizmat sub meh($string) { exit note $string }
[Coke] ... ok, so that means we're broken on windows. I'll open a ticket for USER and GROUP on windows on rakudo/rakudo 16:50
github.com/rakudo/rakudo/issues/5066 16:52
Not sure it's reasonable to expect an ID number on windows. 16:55
(I see an id in "whoami" on CMD.exe, but it's more like a GUID) 16:56
lizmat well, that's something I guess :-) 17:02
tonyo tbrowder: deathbykeystroke.com/articles/2022...art-b.html
lizmat tonyo: why didn't you weekly: that ? 17:03
tonyo i just finished it
lizmat ah... but the date seems wrong ?
tonyo oh snap, way wrong
oh - that's the date i started writing it 17:04
lizmat so, will there be a new URL, or should I use that one ? 17:05
tonyo going to fix it, one sec
deathbykeystroke.com/articles/2022...art-b.html 17:06
17:10 Altai-man left 17:14 MoC left 17:17 MoC joined 17:26 japhb left 17:29 melezhik joined
melezhik o/ 17:29
weekly: www.reddit.com/r/rakulang/comments...ci_update/
notable6 melezhik, Noted! (weekly)
17:30 melezhik left 17:33 japhb joined 17:45 simcop2387_ joined 17:46 simcop2387 left 17:47 simcop2387_ is now known as simcop2387 17:59 [Coke]_ joined 18:00 [Coke] left 18:05 [Coke] joined, ProperNoun joined 18:06 ProperN[out] left, reportable6 left 18:07 [Coke]_ left, reportable6 joined 18:19 [Coke]_ joined 18:22 [Coke] left 18:24 [Coke]_ left, [Coke] joined 18:35 [Coke]_ joined 18:38 [Coke] left 18:40 [Coke] joined
Geth raku.org: 1f9a216119 | (Márton Polgár)++ (committed using GitHub Web editor) | source/whatever/index.html
Fixing broken/outdated links on the Whatever site. (#173)

Co-authored-by: Polgár Márton <ersterpleghthome@gmail.com>
18:43 [Coke]_ left 18:45 [Coke]_ joined 18:48 [Coke] left
Geth raku.org: 9748f84b85 | (Márton Polgár)++ (committed using GitHub Web editor) | source/community/index.html
Removing unused mailing lists, actualizing year (#172)

Co-authored-by: Polgár Márton <ersterpleghthome@gmail.com>
19:03 [Coke]_ is now known as [Coke]
Nemokosch huhu 🥳 19:10
19:36 [Coke]_ joined 19:37 [Coke] left 19:38 MoC left 19:43 [Coke] joined 19:44 Nemokosch joined 19:45 [Coke]_ left 20:08 tidux joined
tidux Why is Rakudo on MacOS such a giant piece of shit? 20:08
I opened a bug against homebrew for rakudo-star not having a working zef or readline. The homebrew maintainers said it was an upstream issue, but I can't find it in the documentation or install instructions. 20:09
El_Che rakudo is not rakudo-star 20:12
Nemokosch In fact, many of Rakudo devs use MacOS so it shouldn't be bad at all 20:14
tidux so then why is rakudo-star still the recommended installation package?
El_Che when on macos I get rakudo (not star) with homebrew and get zef using the 3 simple commands on github.com/ugexe/zef
rakudo.org/downloads 20:15
it looks to me they recommend plain rakudo
tidux ok, so it's the homebrew maintainers that are wrong 20:17
that seems plausible
El_Che no, they offer both
rakudo and rakudo-star
tidux El_Che: "that's something that's in rakudo-star" github.com/Homebrew/homebrew-core/issues/102441
El_Che they are right zef is not part of rakudo 20:18
20:18 nebuchadnezzar left
tidux ^ I was told this directly by a maintainer 20:18
El_Che they are technically correct. I include zef in my rakudo package
(but I only support Linux atm)
but I agree it should be distributed with the compiler 20:19
tidux ok, looks like my best bet is to just use rakubrew then 20:22
El_Che I find the rakudo formula + the git checkout pretty easy
Nemokosch definitely
El_Che works for me, but macos is not my main platform 20:23
Nemokosch rakubrew is very comfy on POSIX systems
it may work on Windows as well but that's always a mess
tidux thankfully I own exactly zero Windows systems 20:25
20:27 MARTIMM joined 20:29 MARTIMM left
tidux oh hey this is an actual Raku bug 20:30
Apple changed where the Xcode command line tools install
El_Che mm 21:06
21:14 [Coke] left 21:18 [Coke] joined 21:22 sena_kun left 22:15 Nemokosch left, Nemokosch joined 22:28 Nemokosch left 22:44 Guest4 joined 22:45 Guest4 left
p6steve i think macOS is walking away from unix style dev ... they have certainly broken raku for me a few times - I have switched to docker on ubuntu on vftools (on macOS) 22:51
22:52 [Coke] left 22:55 [Coke] joined
medium.com/carvago-development/my-...886af0ebba 22:56
23:00 [Coke] left, [Coke] joined