🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
guifa well, actually, I’m not sure how the use Test makes it happen. The monkey scoping stuff is supposed to be lexically scoped, at least as far as I knew 00:00
00:01 DarthGandalf left 00:03 aborazmeh joined, aborazmeh left, aborazmeh joined
guifa oh. whoa 00:04
sub MONKEY-SEE-NO-EVAL() is export { 1 } is apparently all that’s needed 00:05
00:20 DarthGandalf joined 00:36 hungryd19 joined, hungrydonkey left 00:53 thundergnat joined
thundergnat You really want to be disquieted? 00:55
m: my $a = 1; say EVAL("$a + 1"); # yay!
camelia 5===SORRY!5=== Error while compiling <tmp>
EVAL is a very dangerous function!!! (use the MONKEY-SEE-NO-EVAL pragma
to override this error but only if you're VERY sure your data contains
no injection attacks).
at <tmp>:1
------> 3my $a =…
thundergnat m: my $a = 1; say "$a + 1".EVAL; #boo
camelia 2
thundergnat m: my $e = &CORE::EVAL; my $a = 2; say &$e("$a + 1"); # boo-hoo 00:56
camelia 3
codesections Oh yikes and/or wow
So, I'd drafted a Rakudo issue re: the `use Test` behavior, but I guess I shouldn't open it but should instead open a docs issue to add warnings for the Test module? 00:58
00:59 thundergnat left, fooist joined
codesections Or, actually, maybe I'll open it so there's a record/tracking issue. Even if that behavior is *known*, it could still be buggy 01:05
(a known bug is still a bug, after all)
01:08 _jrjsmrtn joined, __jrjsmrtn__ left
Geth doc: e72e190595 | Coke++ | xt/pws/code.pws
add word

Originally reported by codesections++		 01:21
[Coke] codesections: did a full 'make xtest' which I only do very rarely today, and saw "falses". 01:23
guessing I was missing a git pull when I did my final aspell tests 01:24
codesections [Coke]++ well that's _one_ minor mystery solved :)
01:40 Tirifto left 02:00 molaf left 02:10 gnufr33dom joined 02:13 molaf joined 02:21 Cabanossi left 02:33 Cabanossi joined 03:08 fooist left 03:16 gnufr33dom left 03:42 aborazmeh left 04:04 fooist joined 04:49 approaching236 joined 05:25 approaching236 left 05:35 kensanata joined 05:36 wamba joined, molaf left
raku-bridge <interwebs> hi 05:50
05:52 interwebs joined
interwebs hello 05:53
raku-bridge <interwebs> alright got in through irc haha
06:00 interwebs60 joined 06:01 interwebs60 left 06:13 fooist left 06:20 billN1VUX left, rindolf joined 06:56 wamba left 06:57 ufobat joined 06:58 JJMerelo joined 07:13 wamba joined 07:19 Sgeo left 07:34 Cabanossi left 07:50 kensanata left, nebuchadnezzar left 07:51 nebuchadnezzar joined 07:52 MasterDuke left 07:54 JJMerelo left 07:55 nebuchadnezzar left 07:57 nebuchadnezzar joined 08:00 hungryd19 left, Xliff left, vrurg left, Util left, shadowpaste left, bocaneri left, Celelibi left, gfldex left, agentzh left, stux|RC-only left 08:02 fvox left, wamba left 08:05 hungryd19 joined, Xliff joined, vrurg joined, Util joined, shadowpaste joined, bocaneri joined, Celelibi joined, gfldex joined, agentzh joined, stux|RC-only joined 08:06 bocaneri left 08:07 bocaneri joined, fvox joined 08:10 JJMerelo joined
JJMerelo We are seven questions short of 1500 in StackOverflow stackoverflow.com/questions/tagged/raku Will we be able to reach 1500 before the end of August? 08:11
08:41 MasterDuke joined 08:54 ambs left 08:55 ambs joined 09:08 JJMerelo left, zakame left 09:09 zakame joined 09:39 kensanata joined 09:53 rindolf left 10:04 rindolf joined 10:05 pecastro joined 10:18 sena_kun joined 10:36 kensanata left 10:40 TreyHarris left 10:46 pecastro left 10:54 pecastro joined 10:59 finanalyst joined 11:45 Altai-man joined 11:48 sena_kun left 12:04 Archenoth joined
tobs What was the idea behind MONEY-SEE-NO-EVAL anyway? To protect naïve users from using it? (re: R#3896) 12:22
linkable6 R#3896 [open]: github.com/rakudo/rakudo/issues/3896 `Cool.EVAL` does not check for the MONKEY-SEE-NO-EVAL pragma
lizmat tobs: from the doc: In case the MONKEY-SEE-NO-EVAL pragma is not activated, the compiler will complain with a EVAL is a very dangerous function!!! exception. And it is essentially right, since that will run arbitrary code with the same permissions as the program. You should take care of cleaning the code that is going to pass through EVAL if you activate the MONKEY-SEE-NO-EVAL pragma. 12:24
tobs My 2¢ on that issue is that a pragma in my understanding should affect code lexically, and since Cool::EVAL is in another lexical scope, it is not subject to the (dynamic) caller's (in)active pragmata.
12:26 AlexDaniel joined
tobs But I have to wonder, given ugexe's example and the availability of the method form, whether the pragma doesn't set false expectations of safety and the ALLCAPS name is warning enough... 12:26
12:26 AlexDaniel left, AlexDaniel joined
tobs (that seemed to kind of go away from the issue on a tangent, so I'm wary of posting it as a comment on GH) 12:27
12:47 TreyHarris joined
codesections tobs: the problem with the ALLCAPS name being warning enough is that Raku has trained users that ALLCAPS == MOP (WHAT, HOW, etc), not ALLCAPS == dangerous 13:18
(I'm with you on the idea of false expectations of safety, though)
13:29 rir joined
rir p6: say DateTime.new( :year(1970)).Instant; 13:30
camelia Instant:10
rir ^ Why 10? I have looked about but not found the reason? 13:31
13:35 gnufr33dom joined
codesections m: say DateTime.new( :year(1970)).Instant.to-posix 13:43
camelia (0 False)
codesections rir: I'm not an expert, but I think the answer is "no reason, really". `Instant` doesn't represent any particular time; it's just a Raku-specific idea of an instant that supports some, but not all math operations 13:44
If you want the seconds in the Unix epoch, you can convert with `to-posix`, as shown above 13:45
Woo, just saw that my first Rakudo PR was merged! (Admittedly, it added two words and had no effect besides causing a Rakudo to throw a slightly clearer error. But still – baby steps!) 13:49
lizmat codesections++ :-)
13:51 MasterDuke left 13:55 aborazmeh joined, aborazmeh left, aborazmeh joined 14:08 MasterDuke joined
Geth doc: 2ed434182c | Coke++ | .gitignore
Add cache dir created by Documentable
 14:13
codesections [Coke]: So _that's_ why `git pull` made `make update-html` misbehave sometimes! 14:16
14:17 Sgeo joined
[Coke] maybe? I find it just sits there, but doesn't get in the way usually. just tired of seeing it in git status 14:17
14:35 billN1VUX joined 14:37 samebchase- left, [ptc] left, Bucciarati left, Bucciarati joined, [ptc] joined 14:40 samebchase-4 joined 14:41 samebchase-4 is now known as samebchase-
codesections m: say $*RAKU.compiler.verbose-config.lines.grep(/Raku/).join("\n") 14:46
camelia Raku::can-language-versions=6.c 6.c 6.d 6.d.PREVIEW 6.d.TEST 6.d.TESTDEPR 6.e 6.e.PREVIEW
Raku::codename=
Raku::implementation=Rakudo
Raku::language-revisions=c mods
Raku::language-version=6.d
Raku::prefix=/home/camelia/rakudo-m-inst-2
Ra…
codesections does any of that info ^^^ let me identify the exact source code for the version of Rakudo I'm running? 14:47
I expected `source-digest` to be the hash for a git commit, but it doesn't seem to be
or is there a different way to match the code up to the version I'm using?
Altai-man codesections, --version is not good enough? 14:48
codesections That would be fine too
Altai-man codesections, what's the use-case?
codesections Is there a way to get from --version to the exact code for that version?
Altai-man codesections, yeah.
If it is a non-git version (a release, like 2020.07), go to rakudo releases page and there is a tag with the same name. If it is git version, number after `ge` part is commit sha. 14:49
E.g. from "2020.08.2-35-g09e4f2333" you know the thing after `g` is sha, so github.com/rakudo/rakudo/commits/09e4f2333 14:50
Will be the exact sources, I believe.
And if you are using release, just go to github.com/rakudo/rakudo/tags and each tag has sources. 14:51
Is it what you wanted or did I misunderstand what you want? :)
codesections Hmmm, that doesn't seem to *quite* work with the tagged release. But maybe something is just miss-tagged? 14:52
14:52 cpan-raku left, cpan-raku joined, cpan-raku left, cpan-raku joined
codesections Yes, that's exactly what I'm looking for – thanks! Now I just need to see why it isn't working ... 14:52
Altai-man codesections, please, specify some details.
codesections, 2020.08 "release" was badly screwed, sorry for that.
So you are supposed to use either 2020.08.1 or 2020.08.2 and it's normal. 14:53
14:53 finanalyst left
codesections I'm checking with the 2020.07 release. `raku -v` shows '... version 2020.02 ...'; 14:53
then, in the /rakudo dir, I run `git checkout tags/2020.07` 14:54
rir Thanks codesections, given how complex and political time is I find your answer unsatisfying: surely reason was applied even it the choice was to punt; and that that would make your answer on the spot. 14:55
p6: say DateTime.new( :year(1970)).Instant
camelia Instant:10
codesections and then some of the lines reported by `.line` don't match the actual source code
rir The Docs say an Instant `is not tied to or aware of any epoch`. To me that implies that 0 is 10 seconds before the unix epoch is not something to rely upon from run to run. Is that right? Off-hand that seems to lack utility at best and to be trappy for casual scripters who might get caught 0.0116 % of the time.
Altai-man codesections, sorry for the dumb question, but do you clean/rebuild after changing branches? 14:56
codesections ... no? I'm not trying to *use* the checked out version of Raku, I'm trying to check out the version of the source code that corresponds to an already-running Raku process. Do I need to clean/rebuild to get the correct source code? 14:57
Altai-man codesections, so you are not running raku executable from rakudo/, but from other place? 14:58
[Coke] codesections: are you looking at rakudo source? or the corresponding nqp/moarvm code?
14:59 gnufr33dom left 15:00 aborazmeh left
codesections Altai-man: right. What I was doing was, in a raku program, running &SOME-CODE.file and &SOME-CODE.line, and then trying to go from that file/line number pair to the source code for whatever version of Rakudo is executing the script (given access to a git repo for Rakudo) 15:00
[Coke]: That's a good question. Let me look into that
Altai-man codesections, this is a pretty serious claim, I think, so someone with free time has to look into that trying to reproduce. 15:01
codesections Well, thanks for the help! At least now I know I'm on the right track :)
[Coke]: The rakudo source files. The first mismatched line number I saw was in Range.pm6 15:05
[Coke] you mentioned two different numbers above. are you sure you're looking at the right tag?
you mention 2020.02 and 2020.06 15:06
er, 07
codesections oh, I see where I said '02'. No, that was a typo. It's been .06 15:08
(except when I tested with a non-release version, which doesn't have the same issue)
but that uses a commit hash, not a tag 15:09
Altai-man codesections, I wonder if this can be a bug in .line/.file implementation. Can you double check your data and create a rakudo ticket please with a simple case where the data is mismatched? 15:12
codesections Altai-man: Will do 15:13
Altai-man codesections++
15:19 molaf joined 15:28 telex left 15:30 telex joined
codesections Altai-man: Actually, no issue is needed; I figured out the problem: when a method is an automatically generated accessor method, `line` points to the class declaration (which isn't a bug, but is worth documenting -- I'll open an issue/PR for the `lines` docs). I got confused because I was looking at a method that had changed, and thus didn't show up the way I expected. 15:31
Altai-man codesections, oh yes, good catch! Thanks for investigating this. :) 15:33
Geth doc: codesections self-assigned document behavior of `line` method for auto-generated accessor methods github.com/Raku/doc/issues/3606
codesections++ created pull request #3607: Expand Code.line documentation
 15:35
15:46 sena_kun joined, fooist joined 15:47 Altai-man left 15:52 andrzejku joined 15:53 MasterDuke left
guifa So I tracked down a rakudo, eh, bug?(ish) last night. Trick was that a gist method used cmp, which stringifies, and so failed on things that can’t be stringified. 15:57
I get why Nil doesn’t have a Str method (even gist sort of violates the idea of Nil begetting Nil for everything), but for Regex it seems of an issue 15:58
15:58 aluaces left
guifa If I had typed my $a = /a/; say “The regex $a matches a”, I think the DWIM expectation is to produce “The regex /a/ matches a” 15:59
codesections Having not run that code, I agree that's basically the output I would have expected 16:01
guifa m: my $a = /a/; say “The regex $a matches a”
camelia Regex object coerced to string (please use .gist or .raku to do that)
The regex matches a
in block <unit> at <tmp> line 1
guifa Instead, it stringifies to the empty string, and produces the warning 16:02
Now, in that case, it makes total sense but…
say /a/ cmp /b/
evalable6 Regex object coerced to string (please use .gis…
guifa, Full output: gist.github.com/bb4a46899fee5e5674...1142daddb2
guifa or more telling
say /this is a really long regex that will probably never match anything/ cmp ‘’ 16:03
m: say /this is a really long regex that will probably never match anything/ cmp ‘’
camelia Potential difficulties:
Space is not significant here; please use quotes or :s (:sigspace) modifier (or, to suppress this warning, omit the space, or otherwise change the spacing)
at <tmp>:1
------> 3say /this7⏏5 is a really lon…
guifa say /thisisareallylongregexwithoutspacestoavoidthatannoyingwarningandwillnevermatchanything/ cmp ‘’ 16:04
m: say /thisisareallylongregexwithoutspacestoavoidthatannoyingwarningandwillnevermatchanything/ cmp ‘’
camelia Regex object coerced to string (please use .gist or .raku to do that)
Same
in block <unit> at <tmp> line 1
16:25 ufobat left 16:34 approaching236 joined 16:35 rir left 17:04 domidumont joined 17:39 zacts joined 17:44 mowcat joined 17:46 zakame left 17:51 zakame joined 17:56 fooist left 18:13 natrys joined 18:21 aluaces joined 18:22 molaf left 18:29 bocaneri left 18:46 orinthe left, orinthe joined 19:05 kensanata joined 19:10 finanalyst joined 19:12 domidumont left
Geth ¦ problem-solving: vrurg assigned to jnthn Issue Coercion reconsidered and unified github.com/Raku/problem-solving/issues/227 19:17
19:21 nebuchadnezzar left 19:22 nebuchadnezzar joined 19:30 zacts left
Geth doc: e539502c0e | (Daniel Sockwell)++ (committed by Juan Julián Merelo Guervós) | doc/Type/Code.pod6
Expand Code.line documentation

Code.line's documentation previously just stated that it returns the
  line of the code object's declaration. This is *usually* true, but
isn't true for auto-generated code objects, which don't have a declaration. This commit explains how the method works in that case.		 19:37
linkable6 Link: docs.raku.org/type/Code
Geth doc: 4b94178870 | (Daniel Sockwell)++ (committed by Juan Julián Merelo Guervós) | doc/Type/Code.pod6
Add example for Code.line with automatic accessor
19:40 cpan-raku left 19:41 cpan-raku joined, cpan-raku left, cpan-raku joined 19:42 molaf joined 19:45 Altai-man joined 19:48 sena_kun left
lizmat Extra Edition of the Rakudo Weekly News: rakudoweekly.blog/2020/08/31/new-h...mentation/ 20:09
codesections «Reports so far indicate 10% to 15% improvements in core setting compilation, as well as in roast testing.» \o/ 20:12
sjn nice! 20:15
20:26 kensanata left
[Coke] nwc10++ lizmat++ 20:35
lizmat And another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/08/31/2020-...ndidacies/ 20:52
21:02 finanalyst left
sjn lizmat: $rwn ~~ s/Rake/Raku/g 21:06
21:09 rir joined 21:11 finanalyst joined 21:15 AlexDaniel left
timotimo what the heck, whenever i click the link to the sparrowdo proposal thing, the tab immediately crashes 21:15
lizmat que? 21:16
lizmat checks
works for me :-(
21:16 AlexDaniel joined
timotimo huh, now i copypasted the url and paste&go in a new tab, now the browser UI is unresponsive 21:16
even in other windows
lizmat wow 21:17
21:17 AlexDaniel left, AlexDaniel joined
lizmat so, does sparrowdo.wordpress.com/2020/08/28...-proposal/ work for you? 21:17
timotimo no
maybe nothing works
lizmat uses Safari
timotimo perhaps updating the system in the background was the cause of my issue 21:19
now i can load the page
21:20 AlexDaniel left
mendel rir: i guess the Instant with the value 0 is in TAI (en.wikipedia.org/wiki/Internationa...mic_Time), whereas DateTime.new(:year(1970)) is in UTC, and around that time UTC was 10s behind TAI - see en.wikipedia.org/wiki/Leap_second 21:22
lizmat mendel: indeed, see github.com/rakudo/rakudo/blob/mast...s.pm6#L828 :-) 21:29
sjn lizmat: there's a typo in today's weekly news :-) 21:35
s/Rake userbase/Raku userbase/g
sjn still has the perl regexes in his fingers :-P 21:36
rypervenche I hadn't even thought to replace my "I made a typo" syntax with Raku regexes, haha. 21:39
21:43 natrys left 21:44 finanalyst left 21:58 andrzejku left
lizmat sjn++ # thanks, fixed! 22:00
unclechu hey, is there something in raku to handle managed resourse? like auto close of an opened file?
lizmat unclechu: there is no automatic destruction of objects on scope exit 22:01
one way to fix this is to use a LEAVE phaser
LEAVE .disconnect with $dbh;
unclechu like if i’d do `with open 'file', :r { smth; .close }` but without a need of manually calling `close`? 22:02
lizmat LEAVE .close with $handle 22:03
?
or maybe the modules.raku.org/dist/FINALIZER module is something for you?
rypervenche You could also use slurp, which would take care of the closing, no?
[Coke] nice thing about LEAVE is that it covers exceptional cases too
lizmat rypervenche: yes, indeed, "slurp" will take care of closing 22:06
unclechu lizmat: i’m trying to do `LEAVE .close with 'file'.IO.open: :a { .get.say }` but it fails with `Unexpected block in infix position (missing statement control word before the expression?)` 22:09
is it supposed to work with this kind of syntax? 22:11
lizmat I'm not sure what you're trying to achieve here? 22:12
say the first line of a given file, and make sure it gets closed ?
unclechu lizmat: yes, more or less 22:13
define the resource in the first line which will be automatically released after the block evaluation is done 22:14
lizmat with "file".IO.open { say .get; .close } 22:15
lizmat just realized that IO::Path doesn't have a .get method
Altai-man lizmat, but it shouldn't have one, no? 22:16
lizmat why not? it does have .slurp / .lines / .words ?
unclechu lizmat: it doesn’t define everything i described in the first line
lizmat if you're only interested in the first line ?
unclechu i have to not forget to close it as well as i have to handle exceptions 22:17
Altai-man lizmat, because there is a semantic difference between Path and Handle?
unclechu lizmat: no, i’m aware of all of those, first line was just an example
i need this for more complex scenarios
lizmat with "file".IO.open { say .get; LEAVE .close }
that would close the file whichever way you leave that scope, also with execution errors 22:18
unclechu well, still not the first line, this is more or less what i want: `with 'file'.IO.open: :r { LEAVE { .close; 'closed'.say } .get.say; .get.say; }`
lizmat Altai-man: well, for me it was a WAT just now :-) 22:19
unclechu but i’d really prefer this syntax: `LEAVE .close with stuff ...`
lizmat I'd expected it to be there
Altai-man unclechu, LEAVE just as other phasers can take blocks.
22:19 aluaces left
lizmat Altai-man: I think unclechu already got that :-) 22:19
unclechu Altai-man: okay, i know, what does it change here? 22:20
Altai-man Sorry, I'm sleepy, shouldn't have interrupted you...
lizmat Altai-man: I know the feeling, no worries :-) 22:21
unclechu Altai-man: np 22:22
Altai-man lizmat, if you ask me, a path is a path. It allows you not to worry about directory separators, get content and all that. A handle is a handle. It allows you to stream input/output. Slurp handies are handies, because you can say "Ok, give me everything at this path", I think, but if you start to treat paths like handles, it becomes somewhat weird. 22:23
Like, why even handles in the first place. Just throw more stuff into paths, god objects and all that.
unclechu lizmat: you said “you’d expect it to be there”, expect what? or it isn’t related to my question?
22:23 rindolf left
Altai-man s/directory separators/path separators/ 22:24
lizmat unclechu: no, that was about my discussion with Altai-man, sorry for the confusion
Altai-man: "file".IO.slurp is short for with "file".IO.open(:r) { .slurp; LEAVE .close } right ? 22:25
same for "lines" and "words"
so why not for "get" ? 22:26
Altai-man lizmat, I'd clarify. Do you found absence of getc, say, read for paths odd? 22:28
s/found/find/ 22:29
Ok, just ignore me now, going afk, I guess.
lizmat no 22:30
say would be strange on IO::Path
Altai-man Why?
lizmat I could see usefulness on getc , read
Altai-man It's just a shortcut for `"file".IO.open(:a) { .say "hehe"; LEAVE .close }`
lizmat because they would relieve you from having to worry about closing the handle
the .say (as would a .write or a .put) are write actions, *that* I don't see happening on IO::Path 22:31
but anything that's a read action, totally
IO::Path.read could be handy for checking on magic file markers 22:32
without having to worry about .close
Altai-man lizmat, I don't think we should treat IO::Handle as some unwanted child just because someone can forget something possibly. If that is a real trouble, add a weak warning if DESTROY is called and handle was not closed. Or remove it completely, because it is too dangerous to be left alive. 22:33
Hmmmm. 22:34
OTOH, I can understand your concern.
Less bugs is better than more. What I see odd here is lifting the burden from one concept to something which is kind of not really related to that. 22:35
Paths are paths, abstractions over strings, with handy methods for extensions and all that. They should not bear weight of the world of some different classes.
lizmat well, by that definition, we should probably deprecated IO::Path.lines and the like ? 22:39
Altai-man E.g., say there is a class Divisor which divides numbers and it can cry when a division by zero is asked for. Instead of doing something where the problem applies, we can add method `safe-division` to Int, `42.safe-division(20)` and it kind of resolves the problem, except that now numbers know something they probably should not know.
22:40 zakame left
lizmat Altai-man: I totally understand your point 22:40
it's just that with IO::Path having .lines / .words I sorta expected it also to have .get, and when thinking about also a .read 22:41
that's all
Altai-man lizmat, I appreciate the convenience it has, so it is rather hard to judge here (considering I am not a language designer and just a stranger who thinks aloud too much). 22:42
lizmat Altai-man: but it's late here as well... so I'll sleep on it :-)
Altai-man: you're not a stranger, and you definitely do *not* think aloud too much
vrurg Anyone to share the wisdom of adding a repo to Geth? 22:43
lizmat if anything, too little!
Altai-man lizmat, sure, have a nice rest, you deserve it!
lizmat Altai-man: good night!
(as do you!)
Altai-man vrurg, github.com/Raku/geth ? 22:44
vrurg lizmat: have a good rest!
Geth ¦ problem-solving: landyacht assigned to samcv Issue Coercing a string with a Roman numeral throws an error github.com/Raku/problem-solving/issues/228
vrurg Altai-man: added a webhook but lizmat reported it didn't work. 22:45
22:46 roguelazer left 22:47 roguelazer joined
Altai-man vrurg, dunno, I'd check server logs? 22:49
22:50 Guest21 joined
vrurg Altai-man: I don't have access to Geth server. I never remember who does. 22:52
22:54 Guest21 left
vrurg Heh, github reported 'Internal Server Error!' from Geth side... 22:54
22:55 Guest21 joined, Guest21 left 23:08 aborazmeh joined, aborazmeh left, aborazmeh joined 23:10 fooist joined 23:13 mowcat left 23:17 Altai-man left
guifa vrurg++ 23:22
(for Coercion considerations) 23:23
also lizmat++ for weekly
23:33 pecastro left

Powered by Cro and the Raku® Programming Language.

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

Thank you!