Re: I need sorting help
On Sat, Mar 9, 2024 at 7:52 PM yary wrote:
> how to sort by alpha & numeric segments (b3b, a1a, c20c) => (a1a, b3b, c2c)
Ahhh. D'oh. Thanks! 💚
Now I see what was required, or at least think I do:
.sort: {m:g/ \d+{make +$/} | \D+{make ~$/} /».made}
That does what was meant, right?
--
love, raiph
Re: I need sorting help
On Tue, Mar 5, 2024 at 7:01 AM ToddAndMargo via perl6-users
wrote:
> >> $ raku -e '.say for .sort(*.split(/\d+/, :kv).map({
> >> (try .Numeric) // $_}).List)'
> >>
> >> Yippee!
> > raku -e '.say for .sort: { .comb(/ \d+ | \D+ /).map({
> > .Int // .self }).cache };'
>
> Awesome! Now I have two different methods!
And now 4:
$ raku -e '.say for .sort: {m/ \d+ /.Int}'
bk1
bk2
bk10
bk34
or, same logic, but spelled differently:
$ raku -e '.say for .sort: +*.match: / \d+ /'
bk1
bk2
bk10
bk34
--
love, raiph
Re: I need sorting help
> @Sorted_List .= sort: *.match: / \d+ /;
> ...
> @Sorted_List .= sort: +*.match: / \d+ /;
Or perhaps easier to understand:
@Sorted_List .= sort: {m/ \d+ /.Str}
vs
@Sorted_List .= sort: {m/ \d+ /.Int}
love, raiph
Re: I need sorting help
On Sat, Mar 2, 2024 at 6:26 AM ToddAndMargo via perl6-users
wrote:
>
> @Sorted_List = @Sorted_List.sort: { .comb(/ \d+ | \D+ /) .map({ .Int // .self
> })};
In case another answer is helpful...
First, a simplified sort that produces the same
result as your code above:
@Sorted_List .= sort: *.match: / \d+ /;
I can explain that in a later comment if you want, but it's
all stuff I recall you figuring out in the past, so for now I'll
just move on to address the change you wanted.
The problem you had was that sort defaults to a string sort.
In string sorting 1, 10, 2 are already sorted, but you instead
want numeric order, which sorts those three into 1, 2, 10.
To do that, coerce the sort value to numeric by inserting a `+`:
@Sorted_List .= sort: +*.match: / \d+ /;
--
love, raiph
Re: Raku IO IceDrive bug
Hi again. :) Let me try again. I'll try cover things more clearly. #1 There was/is a bug in your code, or at least code that you say isn't working on your system. (It works on glot.io. See #3) ``` $WanIpFileName.IO.open(:w); spurt "$WanIpFileName", "New File Opened"; ``` These two lines clash badly. They are a bug waiting to happen. The glot.io system resolves the clash in your favor, so the clash isn't apparent. You are saying that on your Windows system, the code fails. The simplest thing to do is just fix the bug, rather than worry about understanding it. The simplest way to fix the bug is to simply drop the first line. It's redundant at best, and causes the bug at worst, so just get rid of it. If you don't want to understand the bug, but do want to know about the other issues, skip ahead to #2 or #3. In case you *do* want to understand the bug, let's start with another way to fix the bug. You could write: ``` my $handle = $WanIpFileName.IO.open(:w); $handle.spurt: "$WanIpFileName", "New File Opened"; ``` That works, and should work on Windows. This time the code *saves the file handle* corresponding to the first line, and then uses that handle as the invocant of a `.spurt` *method*, thus connecting the handle opened in the first line to the `spurt` done in the second line. Maybe *that* has explained all you need to know. If so, feel free to skip ahead to #2 or #3. Repeating the two lines that clashed: ``` $WanIpFileName.IO.open(:w); spurt "$WanIpFileName", "New File Opened"; ``` The first line opens the file in write mode -- and then leaves it like that and throws away the file handle. That's an issue. If you understand why it's an issue, then great. If you don't, then that's OK too, and I'll move on, because it isn't too important. The second line has no idea the first line opened the very same file it's just about to open, so it tries to open it *again*, write to the file handle, and then close it. Finally, at program exit, the file system tries to clean up an exiting process, eg closing any file handles left open and resolving clashes like your code generates. On some systems the code will succeed. On your system you say it doesn't. See #3 for demo and further discussion. #2 There was/is a doc failure. I now see another one or two. The doc failed to say that `spurt` opens the file. It should. (Then you would presumably have understood you did not need the `open` line.) The doc failed to say `open` returns a file handle. It should. (Then you would presumably have understood that if you used an `open` line, you needed to keep the file handle and use a `.spurt` *method* on that file handle.) The example doc you looked at includes a line that does the equivalent of `touch`. You thought you could use it but chop off the `.close`. (But you didn't realize you needed to keep the file handle, as just explained.) #3 There is a Windows difference. Your code runs fine on glot.io. Please click this link, and then the Run button: https://glot.io/snippets/gpv7tdaca0 That contains your code. And it's working. The difference is it's not Windows. NB. Each time you click Run, glot.io automatically cleans the file system. Every time. That's why it always says 'file does not exist' at the start. Every time. NB. I added the lines declaring the missing variable and sub, and checking the file does not exist at the start, and some commented out stuff and so on. Feel free to edit the code to whatever you want if you want to. If you want to start over, click refresh on your browser and click 'Reload'. love, raiph
Re: Raku IO IceDrive bug
> if not FileExists( $WanIpFileName ) {
> $WanIpFileName.IO.open(:w);
> spurt "$WanIpFileName", "New File Opened";
> }
Afaik, depending on how you choose to look at things,
there's a doc error (doc for `spurt` doesn't mention that
it opens the file it's spurting to), and/or behavior due to
your Windows file system / account settings that leads
to the issue you see, and/or a bug in your code.
Let me explain. Here's what the code does:
1. Opens the file with `$WanIpFileName.IO.open(:w);`
if it doesn't already exist.
2. Opens the file with `spurt` and writes to it.
And that causes the behavior you see.
Presumably, on your system/setup, doing those two things
fails because the second open fails due to the first one.
So it succeeds the second time around because the file
already exists (though blank) and the `spurt` goes ahead.
I'd argue that the bug is ultimately in your code, perhaps
due to you not realizing that `spurt` opens the file it spurts
to, because the doc doesn't say so.
Whichever way one looks at it, there's no bug in Raku(do).
--
love, raiph
Re: Raku regex assert doesn't match
On Sun, Jul 30, 2023 at 5:21 AM Darren Duncan wrote:
>
> match this pattern initially, but
>
> fully declarative
Do you consider `> .*` to be declarative?
If so, what about:
```
my token nonquoted_alphanumeric_text
{
<[ A..Z _ a..z ]> <[ 0..9 A..Z _ a..z ]>*
&
> .*
}
```
--
raiph
Re: Undefine mixed data
I see weaknesses in my attempt to explain Raku's design related to "definedness". (I personally think there would best be a documentation page dedicated to the triumvirate of definiteness, definedness, and truthiness, but here I'm trying to achieve a balance between being short enough for this context -- an email in a thread about the deprecation of `undefine` -- and long enough to outline the key aspects of this carefully designed part of Raku, enough so folk might stop just assuming it is broken in ways that it's not. The issue really is just `undefine`, and where we go next now it is deprecated, not assuming there's some big broad problem due to ignorance of Raku's design.) On Mon, Mar 20, 2023 at 10:42 PM Ralph Mellor wrote: > > Let me first summarize relevant parts of Raku's design. These are not > going to change. They've been in place for 2 decades and work great. That bit I'm confident about. I'm also happy with the "definiteness" paragraph and OK with the "truthiness" paragraph. (Also, the latter is a well known concept in PLs so I don't feel I need to unduly worry about nailing the latter. Hopefully it just makes sense to readers even without me being especially careful.) It's my "definedness" description that seems to me potentially problematic. I feel like I didn't do a good enough job. Here's my attempt to sufficiently fix it: > If a value is indefinite (eg the type object `Tree`) then it is not defined. If an object is indefinite (eg the type object `Tree`) then, if it is treated as a potentially defined value (eg `.defined` is called on it as a test, or one of the constructs that test the `.defined` value is used, such as `with`), then it is considered not defined. > A `Failure` instance is definite (because it's an instance, per the previous > paragraph), yet it is undefined (because it's an instance of a failure). A `Failure` instance is definite (because it's an instance, per the previous paragraph), yet is not defined (so that code that tests its definedness, by calling `.defined`, will know that something is amiss. (At the opposite extreme, if code carelessly treats a value as if it is fine, without making any attempt to check, and it's a failure instance, it will "blow up", throwing an exception.) If anyone reads this I'd appreciate hearing whether they are happy that I wrote this email, even if they disagree with my appreciation of the merits of Raku's design. -- love, ralph
Re: Undefine mixed data
On Sat, Mar 18, 2023 at 6:28 PM Polgár Márton wrote: > > For what it's worth, I think most of these behaviors that sometimes > even contradict each other (like the "freshly undefined" array being > both .defined and .DEFINITE) are just design mistakes from a different time. There are no mistakes here. There is no contradiction of the kind you suggest. The design from a different time was great, and we're lucky enough to enjoy it. But it took until a few years ago to deprecate the wrongly named function `undefine`. That's all. Please don't blow such a small thing up into something it's not. > you cannot reasonably indicate for an array that it doesn't have > valid content, as opposed to being empty by chance If you mean indicate it's undefined, then here's one way: ``` my @array; say @array.elems; # 0 say @array.so; # False say @array.defined;# True say @array := Array:U; # (Array:U) say @array.so; # False say @array.defined;# False ``` If you mean something else, please be specific. > it does no good, ever, that you get to store a Nil value ... in an array Why do you think the `is default(Nil)` idiom for storing `Nil`s in `Scalar`s is OK except when the `Scalar`s are inside an array? I grant that, as jnthn put it in an SO discussing this: > While there is the `is default(Nil)` trick, I'd strongly suggest using some > other value as your sentinel. Trying to use a language feature in a > situation where you don't want the primary behavior it exists to provide > will generally not go smoothly. So, it is not something most Rakoons are likely to ever want. But that's the rule that proves the exception -- on rare occasions *some* Rakoons *do* want to store a `Nil` in an array because it's not a sentinel but a `Nil` representing a `Nil`. For obvious reasons I'm not going to look for examples of this use in `Array`s to share them in this thread. No matter how irritated I get about what you write I would still want to give you a hug if I met you in RL, and would ask that you just eat a hat or something. love, ralph
Re: Undefine mixed data
On Mon, Mar 20, 2023 at 10:42 PM Ralph Mellor wrote: > > * Definiteness or definedness? If you want it indefinite (or undefined), > call `.WHAT` on the argument. That should be "Bind the result of `.WHAT` called on the argument". Similarly: > * Truthiness? Want a fresh false instance? Call `.new` on the argument. and bind it. -- love, ralph
Re: Undefine mixed data
On Mon, Mar 20, 2023 at 12:49 AM rir wrote:
>
> I did, and do, recognize the validity of the problem of 'undefine' not
> not aligning with '.defined'.
But do you understand the problem I was trying to communicate?
What you're writing suggests to me you know some other PL(s) that
have notions of truthiness and definedness that don't match Raku's,
and thus you don't recognize the problem, thinking it's just some trivial
name clash between `undefine` and `.defined`. It isn't. I'll have another
go at explaining. I apologize in advance if I again miss the mark, but I
still hope the penny will drop if I persevere. Wish us luck!
Let me first summarize relevant parts of Raku's design. These are not
going to change. They've been in place for 2 decades and work great.
In Raku, whether or not something is considered definite is determined
by an approach called "definiteness". An instance is definite. A type object
is indefinite. There are no other possibilities. This notion of definiteness
corresponds to the linguistic one that arises in many human languages.
Consider a tree. One either means a definite tree, that large oak at the
corner of the street, or an indefinite one, the idea of a tree. An instance,
that oak, is definite. The idea, the type object `Tree`, is indefinite.
In Raku, whether or not something is considered defined is determined
by an approach called "definedness". If a value is indefinite (eg the type
object `Tree`) then it is not defined. Always. By contrast, definite values
(instances) *are* defined by default, but there are exceptions. A `Failure`
instance is definite (because it's an instance, per the previous paragraph),
yet it is undefined (because it's an instance of a failure).
Finally, in Raku, whether or not something is considered true or false is
determined by an approach called "truthiness". If a value is undefined
then it is false. Always. By contrast, defined values are true by default
but there are exceptions. For example, the integer instance `0` is
definite (it's a particular integer), and defined, but is false (because it's
zero). As another example an array with zero elements is definite (it's
a particular array), and defined, but false (because it's empty).
This is how Raku works. We really aren't going to undo this 2 decade
old design.
Raku's current `undefine` only addresses truthiness, not definedness.
Here's the code in Rakudo (ignoring the proto):
```
multi sub undefine(Mu \x) is raw { x = Nil }
multi sub undefine(Array \x) is raw { x = Empty }
multi sub undefine(Hash \x) is raw { x = Empty }
```
The `Array` and `Hash` subs merely empty their argument. This leaves it
defined but false. As I said, `undefine` is about truthiness, not definedness.
For all other cases the argument is assigned `Nil`. If it's a `Scalar` with a
truthy `is default` value then the `undefine` isn't even going to manage
being about truthiness:
```
my $number is default(42) = 99;
say $number; # 99
undefine $number;
if $number { say $number } # 42
```
Do you really want all this insanity?
It's the wrong name. It does the wrong things. It needs to go.
> The docs indicate that being empty is the definition of undefinedness
> for non-scalar containers.
Wherever they say that they're wrong.
(Please consider filing a doc issue saying where you've seen such nonsense.)
> Keeping 'undefine' as a name of this action is beneficial because
> 'undefined' and 'defined' are mainstream terminology and so enable
> people to find and understand Raku's variant behavior.
I agree, provided `undefine` itself becomes a compile time error, ie we keep
`undefine` as the name of an action someone would expect if they come from
a PL that has an `undefine`, so we can make it an error that explains what to
do instead.
> A name like 'clear' would just be obscure--a great disadvantage.
I'm not happy with the name `clear` because what you really want to
know is what will happen to the argument after the function, whatever
it is called, has finished. Unfortunately, you can't be sure it will be clear,
as my above `is default(42)` example makes clear.
One could imagine renaming `undefine` to `default`:
```
my $number is default(42) = 99;
say $number; # 99
default $number;
if $number { say $number } # 42
my @array = [42,99];
default @array;
say @array; # []
```
But that's still not as good as:
```
my $number is default(42) = 99;
say $number; # 99
$number = 42;
if $number { say $number } # 42
```
or:
```
my $number is default(42) = 99;
say $number; # 99
$number = Nil;
if $number { say $number } # 42
```
The only case that's arguably awkward, or arguably fine though surprising,
is the one you began with, where you don't know if you're getting an `Array`
or `Hash` or something else.
But what is appropriate?
If you get an `Array` or `Hash`, it depends on what you want:
* Definiteness or definedness? If you want it indefinite (or undefined),
call `.WHAT` on the argument. (I note that neither the deprecated `
Re: Undefine mixed data
On Fri, Mar 17, 2023 at 11:11 PM rir wrote: > > Deprecating 'undefine' is just making something easy more difficult. I see a problem with `undefine`: ``` my @bar; say @bar.defined, @bar.DEFINITE; # TrueTrue undefine @bar; say @bar.defined, @bar.DEFINITE; # TrueTrue ``` I think a warning about this is the wrong solution. I think deprecation is the right solution. That said, I'm a bit surprised that the deprecation message isn't something like Please use `foobar` instead (where `foobar` does exactly the same thing as `undefine`, just using a different name). Maybe no one has yet thought of a name that isn't also fraught? Maybe there is no reasonable name? Maybe it's only Perl folk who would want `undefine`? Maybe it's only Perl folk who will see the deprecation message and be unhappy? Maybe, on balance, it's reasonable to consider it an opportunity to remind Perl folk that a fresh uninitialized array or hash is NOT undefined? Dunno. Just keeping an open mind. Onward... I searched Rakudo's sources for "undefine". No useful match?!? Looks like GH search goes from bad to worse. Sigh. `say &undefine.file` got me `SETTING::src/core.d/operators.pm6`: https://github.com/rakudo/rakudo/blob/591157170d29f8a45ef316bb0d065e8437059112/src/core.d/operators.pm6#L1-L9: Git blame led to this commit: https://github.com/rakudo/rakudo/commit/72bac6708002f992952ca93e617435482824b95f The commit message mentions "6.d-prep". A google for that led to: https://github.com/Raku/6.d-prep Results of a GH search included https://github.com/Raku/6.d-prep/search?q=undefine&type=issues I ask that no one here comments on the discussions therein unless they are *very* careful to avoid using inflammatory language. Next I decided to search IRC. That led to this by Larry: > I think we should s/undefine/clear/, because clarity (https://irclogs.raku.org/perl6/2015-07-02.html#17:19-0001 Liz suggested it was perhaps redundant. (A similar argument appeared in the 6d prep issues.) Larry didn't reply. Warnock's dilemma applies though I don't think Larry ever missed anything. I think he always went with his gut; if he felt he'd be repeating himself he said nothing. And so we arrive at 2023 and the same issue arises as ever. Can we be kind to each other even if we don't agree, even if we are upset about some decision? love, ralph
Re: Upcoming documentation meetings
D'oh. Time for sleep. Hopefully see or hear y'all next Sat. On Sat, Feb 4, 2023 at 11:21 PM Will Coleda wrote: > > Yes, Eastern- but the time had already passed, sorry. > > On Sat, Feb 4, 2023 at 18:13 Ralph Mellor wrote: >> >> That's super short notice but if you mean EST, so 5pm UK time, >> it would work for me. >> >> On Fri, Feb 3, 2023 at 7:07 PM Will Coleda wrote: >> > >> > I can do a test tomorrow at noon if there's interest. >> > >> > On Fri, Feb 3, 2023 at 10:27 AM Parrot Raiser <1parr...@gmail.com> wrote: >> > > >> > > I think I had problems finding the audio options on Jitsi, and wasted >> > > a couple of meetings doing so. I'd suggest a "test" setup meeting, >> > > where the whole agenda is ensuring that everyone has all the settings >> > > right. Maybe set up a static video shot with background music to give >> > > feedback? >> > > >> > > On 2/2/23, Elizabeth Mattijsen wrote: >> > > >> On 2 Feb 2023, at 21:11, Ralph Mellor wrote: >> > > >> My internet is flakey when humidity is around 80%+ and the weather >> > > >> forecast suggests it may be but with luck I'll be "there" 5pm UK time >> > > >> (noon EST, 9am US west coast time) Saturday Feb 11. >> > > > >> > > > If you switch off your camera, you will reduce the needed bandwidth >> > > > significantly. But I guess I don't need to tell you that :-) >> > > > >> > > > >> > > > Liz
Re: Upcoming documentation meetings
That's super short notice but if you mean EST, so 5pm UK time, it would work for me. On Fri, Feb 3, 2023 at 7:07 PM Will Coleda wrote: > > I can do a test tomorrow at noon if there's interest. > > On Fri, Feb 3, 2023 at 10:27 AM Parrot Raiser <1parr...@gmail.com> wrote: > > > > I think I had problems finding the audio options on Jitsi, and wasted > > a couple of meetings doing so. I'd suggest a "test" setup meeting, > > where the whole agenda is ensuring that everyone has all the settings > > right. Maybe set up a static video shot with background music to give > > feedback? > > > > On 2/2/23, Elizabeth Mattijsen wrote: > > >> On 2 Feb 2023, at 21:11, Ralph Mellor wrote: > > >> My internet is flakey when humidity is around 80%+ and the weather > > >> forecast suggests it may be but with luck I'll be "there" 5pm UK time > > >> (noon EST, 9am US west coast time) Saturday Feb 11. > > > > > > If you switch off your camera, you will reduce the needed bandwidth > > > significantly. But I guess I don't need to tell you that :-) > > > > > > > > > Liz
Re: Upcoming documentation meetings
On Thu, Feb 2, 2023 at 6:10 AM Bruce Gray wrote: > > On Feb 1, 2023, at 6:00 PM, Elizabeth Mattijsen wrote: > >> On 2 Feb 2023, at 00:53, Ralph Mellor wrote: > >> It required an international phone call. > > ??? I've never had to make *any* phone call to be able to use Jitsi. > To clarify, using Jitsi as normal (for *video* conferencing) is free, > worldwide. Ah. Great! > Jitsi allows you to call a phone number, to listen and speak > (audio-only) on in the video meeting room: > ... > +44.203.885.2179UK > ... The Jitsi "Joining instructions" link vrurg shared showed a list like that. > These numbers are also free, but only if your phone company > considers them free. In other words, you might get charged, > but it is the phone company's charge, not Jitsi's. Right, I was talking about the phone company charge, not Jitsi. But anyhoo, it seems this is moot. Aiui now, I just need to connect via the web and it'll be free. > Hope this helps, It does! Thank u Liz and Bruce (and Polgár Márton / Martin Burger). My internet is flakey when humidity is around 80%+ and the weather forecast suggests it may be but with luck I'll be "there" 5pm UK time (noon EST, 9am US west coast time) Saturday Feb 11. -- raiph
Re: Upcoming documentation meetings
On Tue, Jan 24, 2023 at 9:50 PM Polgár Márton wrote: > > Since there is a public Jitsi link, I don't think this would get cancelled > because of personal problems. This is my "unofficial opinion" but I > think whether the proposed dates (noon Eastern time, second > Saturday of February, March an April respectively) can be followed > is only a matter of reaching the "critical mass" of interest now. There > is plenty of time to plan for it. I looked at Jitsi when vrurg suggested it for their Core class. It required an international phone call. I'm not able/willing to cover such a cost. So I won't be attending despite being interested in doing so if I could do so for free (as would be the case with, for example, google meet). vrurg didn't want to alter their plans and I respect that. Same goes for you guys. Iirc he w/couldn't offer the session for me to watch for free after the event either. (And iirc he cancelled it anyway, but still, my point is that it seemed to me that Jitsi has a double negative in that it is both expensive to join live and does not have a free post-meet replay option either.) -- raiph
Re: pointer confusion
On Tue, Dec 6, 2022 at 11:55 PM ToddAndMargo via perl6-users wrote: > > > Oh, I figured out the "*ppX" double pointer. > "Pointer[Pointer]". Ironically I wrote that in a comment on your SO question before any other comments or the answers were written. But it was just a wild guess. I don't know NativeCall. So I ended up getting cold feet, thinking I might lead you on a wild goose chase, and deleted my comment. It's a bit weird to now read your comment saying that was indeed the solution! -- raiph
Re: Raku opens a notepad when executing a .bat
Please confirm that:
* Entering `ls` at the command line prompt does what it says
on the tin, it does not open notepad.
* A Raku program that consists of the single line `qqx 'ls'` does
what it says on the tin, and does not open notepad.
If those are true, then this code:
```
use lib '.'; use NativeWinUtils :RunCmd; say RunCmd(Q[ls]);
```
is NOT running the code you showed starting `sub RunCmd`.
--
raiph
On Tue, Dec 6, 2022 at 9:44 AM ToddAndMargo via perl6-users
wrote:
>
> Hi All,
>
> Windows Pro Chromebook Edition 22H2 (W11)
> raku -v Welcome to RakudoΓäó v2022.07.
>
> When ever I run the following, it opens
> a Notepad with the text of the calling
> raku program.
>
> raku -e "use lib '.'; use NativeWinUtils :RunCmd; say RunCmd(Q[ls]);"
>
> This is RunCmd
>
> sub RunCmd( Str $CommandStr, Bool $EchoOff = False ) returns Str is
> export( :RunCmd ) {
> my $PathIAm = $?FILE;
> my Str $BatFile = $PathIAm ~ ".bat";
> # print "$BatFile\n";
> my Str $RtnStr;
> my Str $CmdStr = "";
>
> if $EchoOff { $CmdStr = Q[@echo off] ~ "\n"; }
> $CmdStr = $CmdStr ~ $CommandStr ~ "\n";
> # print "$CmdStr";
>
> spurt( $BatFile, $CmdStr );
> $RtnStr = qqx { $BatFile };
> # print "$RtnStr\n";
> }
>
>
> It is the qqx command (it runs the created .bat file)
> that opens the notepad.
>
> The .bat file, which I leave on the disk,
> runs fine manually.
>
> And I did this to myself. I had a pop up that
> asked me what to do with something and I must
> have clicked on it by accident.
>
> -T
>
Re: pointer confusion
On Mon, Dec 5, 2022 at 10:20 PM ToddAndMargo via perl6-users wrote: > > > use NativeCall; > > my Pointer $foo .= new: 42; > > say $foo; # NativeCall::Types::Pointer<0x2a> > > print $foo; # NativeCall::Types::Pointer<5895604297984> `say` concatenates the `.gist`s of each of its arguments. In this case `say` only has one argument, `$foo`, which contains a `Pointer`. The `.gist` of a `Pointer` is a concatenation of: * The full type name (`NativeCall::Types::Pointer`) and * `<...>` enclosing the pointer's value (the address it represents) in HEXADECIMAL literal form. `print` concatenates the `.Str`s of each of its arguments. In this case `print` only has one argument, again `$foo` which contains a `Pointer`. The `.Str` of a `Pointer` is a concatenation of: * The full type name (`NativeCall::Types::Pointer`) as with `say`. and: * `<...>` enclosing some OTHER number (NOT the pointer's value, ie not the address the `Pointer` represents) in DECIMAL literal form. I think this OTHER number is a number associated with the `ObjAt` of the `Pointer`. `ObjAt` is a high level Raku Object ID that's unique to the associated object. See https://docs.raku.org/type/ObjAt The key thing is that the integer number included in the `.Str` of a `Pointer` is NOT the address that that `Pointer` points to. It's something completely unrelated. Unless you know you need to pay attention to its `ObjAt` you are best advised to ignore it. To return to the outputs of the `say`/`.gist` and `print`/`put`/.Str` forms and add the `.raku` at the start: ``` ...Pointer.new(42) ...Pointer<0x2a> ...Pointer<5895604297984> ``` You thought the three numbers should be the same integer. That's part of the problem. It's a surmise that leads to surprise. Your original exploration was in the REPL. By default this REPL line and display uses `.gist`/`say` ``` [3] > my Pointer $Ptr2Ptr = NativeCall::Types::Pointer[BYTES].new($x); NativeCall::Types::Pointer<0xfe45ddcc> ``` (You can change from the default but let's move on.) If a REPL line explicitly writes to STDOUT, then the REPL uses that instead. So this line does NOT use `.gist`/`say`: ``` [4] > print "x = <" ~ $x ~ "> <0x" ~ $x.base(16) ~ "> Ptr2Ptr <" ~ $Ptr2Ptr ~ ">\n"; x = <4265991628> <0xFE45DDCC> Ptr2Ptr > ``` You wrote `print`, and, as explained at the start, if you do that, the REPL accepts its output and displays that as is, no `.gist` involved. In the meantime, the `$Ptr2Ptr` is concatenated with `...<" ` and `">..." either side of it via two `~`s. The `~` op calls `.Str` on its operands. As explained above the `.Str` of a `Pointer` is not its `.gist` and instead returns a string that includes an `ObjAt` integer inside the `<...>` and that integer is not the address the `Pointer` points to. So, factors that are confusing. Please sleep on what you've learned, and perhaps rethink it through the next day before deciding whether you now find it makes sense or if it remains confusing. Then I'll follow up if you still find it confusing. Hth! -- raiph
Re: When to use .new?
I forgot to mention one other shortcut that is always available if you do have to use `.new` (which is the case for most types). You can write: ``` my $foo = 42; ``` The `42` on the RHS of the `=` is the shortest way to create an integer value corresponding to `42`. But you could also write: ``` my $foo = Int.new: 42; ``` It's odd, but you could that. You could also write: ``` my Int $foo .= new: 42; ``` Note the `.=` instead of `=` and the `new` instead of `Int.new`. That is, if you constrain a variable's type, and want to initialize that variable to a value of exactly that type, you don't have to repeat the type name on the RHS of the `=` if you write it as above. For types that have literal forms it's not helpful. And for short type names it's helpful, but only a little. But let's say you really wanted to write out the full `NativeCall::Types::Pointer` and you wanted a variable constrained to that type and initialized to have a value of that type. Now it's a big deal: ``` my NativeCall::Types::Pointer $foo .= new: 42; ``` -- raiph
Re: When to use .new?
On Thu, Dec 1, 2022 at 4:28 AM ToddAndMargo via perl6-users wrote: > > Why can I get away with `my Str $x = "";` > > But I have to use .new here (an other places too) `my $ppSession = > NativeCall::Types::Pointer.new();` There are ways to write the value of some data types with minimum fuss. This is typically the case for oft used types like strings and numbers. Many programming languages have "literals" as the ultimate no fuss way. Raku has them for strings and numbers: ``` "this is a string" 42 # <-- `42` is a number, an integer ``` You create a string by just writing its value inside quote marks. You create a number by just writing its value. The `.new` is implicit, happening behind the scenes. It's not practical to have "literal" short cuts for *all* data types. While code corresponding to pointers (and dereferences of them) is *explicitly* written a LOT in C, explicit pointer coding is almost completely eliminated in Raku. The only exception is in some NativeCall code that makes a lot of use of its `Pointer` type for representing a Raku wrapped C Pointer. Is that enough to justify introducing a "literal" form for `Pointer`s? I doubt it. But if you wanted to explore that, Raku makes it possible. > Is there some rule I can follow that let me know when I have to > use `.new and when I do not? About the only rule there can be for arbitrary Raku code is whether you already know a way to create a value without using `.new`, or have time available to investigate the two approaches. For builtin types that means reading the official Raku doc. For user defined types defined in modules you use that means reading the doc of those modules. But in general the vast majority of types require use of `.new`. The main exceptions I can think of are strings, numbers, pairs, and basic collections. (Untyped lists, captures, positional arrays, and associative arrays -- hashes etc.) > (I am getting tired of figuring it out the hard way.) I found it easy because I didn't *try* to find out but was just delighted each time I realized there was yet another nice and even shorter way to create values. One thing I note in this context here is that one doesn't have to write out the fully qualified type name `NativeCall::Types::Pointer`. One can just write `Pointer`. (NativeCall introduces this short form by default if you write `use NativeCall;`) -- raiph
Re: pointer confusion
On Sat, Dec 3, 2022 at 11:44 AM ToddAndMargo via perl6-users wrote: > > I am confused I think the following is a golf of your confusion: ``` use NativeCall; my Pointer $foo .= new: 42; say $foo; # NativeCall::Types::Pointer<0x2a> print $foo; # NativeCall::Types::Pointer<5895604297984> ``` I can see how someone might be confused by the two numbers: * Decimal `42` which is the same as hex `0x2a`. * Decimal `5895604297984` (or whatever) which isn't `42`/`0x2a`. Why isn't the third number the same as the first two? Am I right in thinking this distills what is confusing to you? -- raiph
Re: Session ID
On Mon, Dec 5, 2022 at 9:45 AM ToddAndMargo via perl6-users wrote: > > Answer 3: > https://stackoverflow.com/questions/74665162/how-do-i-assign-the-value-in-carray-that-contains-a-memory-address-to-a-poi#74674303 > > Håkon Hægland is astonishing good at this stuff. Indeed he is! If one of his answers is acceptable to you, please click its Accept button. Note that your above link is to his second answer, but it seems like it's his third answer that you found most satisfying. If that's right, then the best answer to Accept imo is the third one. -- raiph
Re: Aw: Rakudo for W7?
On Sun, Oct 23, 2022 at 1:18 AM ToddAndMargo via perl6-users wrote: > > Which goes back to my question. What is the last one they published that > supports Windows 7? I would say there isn't one, where "supports" is a present tense meaning. Your question is analogous to asking what is the last book published that contains a poem we know Queen Elizabeth II of England reads aloud each Sunday. There is no such book even if there was one a couple years ago, and even if we've still got that book on our bookshelves. Why? Because she recently passed away. More concretely, if a problem arises with a Rakudo or Raku program, and it's running on a Windows 7 system, then core Raku devs are all but obliged to steer clear of suggesting there is any support of any nature whatsoever. Because if a platform vendor has officially withdrawn support then all vendors targeting that platform must also realistically withdraw *their* support too, at least "officially", and, imo, in practice too. If anyone is crazy enough to tell you or your customers they've your back, or their back, for support of any sort on an unsupported platform, it's important to recognize that legally, and business insurance wise, you'll be on your own unless you have some explicit legal cover for that situation. Just my 2c but I wasn't sure if you understood why folk were being more than reticent to suggest there's more support than was stated. -- love, raiph
Re: Problem defining factorial operator in .rakumod file
On Fri, Oct 14, 2022 at 10:59 PM Joseph Polanik wrote: > > Update: ... all methods are reporting correct results. > > Thanks for the help. Good to see resolution of problems. :) Is everything now resolved or are some things still outstanding? -- love, raiph
Re: Problem defining factorial operator in .rakumod file
On Fri, Oct 14, 2022 at 4:30 AM Joseph Polanik wrote: > > > It works for me. (v2022.02) > > When I use the REPL, the results are the same. The results are the same for ALL of us, for ALL Rakudo versions. Try the program 42!; Note how the error message is the same. The results are the same for ALL of us, for ALL Rakudo versions. Your scenario does not involve the REPL. And it does not occur on the Rakudo versions I've tried it on even though those versions do have the REPL bug. Your scenario is different. Same symptoms. Different root cause. -- love, raiph
Re: Problem defining factorial operator in .rakumod file
On Fri, Oct 14, 2022 at 12:37 AM Joseph Polanik wrote:
>
> I am trying to define '!' as the factorial operator. The following works
> in a .raku script file:
>
>sub postfix: ($n) is export {
> when $n == 0 {return 1}
> default {$n * ($n - 1)!}
>}
>
> However when I tried to move this sub to a .rakumod file,
> it produces an error: Negation metaoperator not followed
> by valid infix.
That's because Raku isn't picking up your `sub`.
I don't know why. It works for me. (v2022.02)
Are you sure you're `use`ing it correctly and the `sub`
has the `is export`?
Can anyone else reproduce Joseph's problem?
> It turns out that this is a known issue, #3774
No, that's specific to the REPL.
The error message is the same; the common thing between
the two cases is that Raku is unaware the postfix has been
defined. The REPL problem is known. But the problem you're
sharing is unrelated to the REPL problem.
--
love, raiph
Re: steps of a path
On Wed, Sep 7, 2022 at 1:20 AM Marc Chantreux wrote: > > Actually what I really like the most from all your answers was the fact > that I learned a lot not only about the langage but also some idoms. That sounds cool. :) I know what *I* think of when I write "idiom" in the context of programming languages. But what do *you* mean? Or, even better, can you identify a few of the many useful suggestions folk have made in this thread which you would count as being, or possibly worthy of being, "idioms"? Wikipedia notes two uses of the term "idiom" in this context (claiming the first is correct but the second isn't, though the distinction seems immaterial here): > code [with a] semantic role, which recurs frequently across software projects > using a programming language in a typical way I know I wasn't particularly aiming at either of those, but instead playing golf in response to what I thought you were after, and focusing on: * First and foremost, Larry's notion of "clean golf" (minimal tokens, not bytes). * Secondarily my notion of "semantic golf" (minimal mental effort when reading). In other words my goal was code requiring minimal reading effort to understand while still appropriately expressing the desired computational result and/or effect. > > Is that because it knows me, or has google started blessing Larry's > > neologisms for the whole planet?!? ) I now think it (gmail and/or my brain; they may or may not have merged) glitched on me. > Why not? new words happens all the time and those one are useful for > programmers. I had done a google for "whipupitude" before I wrote the thought bubble in my previous message. Google claimed it found 300 results. I just tried again; adding -perl shrank their claim to just 8 matches. That said, right now gmail is claiming whipupitude is misspelled... -- raiph > > -- > Marc Chantreux > Pôle de Calcul et Services Avancés à la Recherche (CESAR) > http://annuaire.unistra.fr/p/20200
Re: steps of a path
On Mon, Sep 5, 2022 at 8:07 AM Marc Chantreux wrote: > > I just played again with your solution and got the beauty of it. > > Actually: this is by far the simplest solution. Thanks. Thanks for the follow up. So I'm not going mad! :) Given that the broader picture is file/path related operations, it makes sense to me you're mostly exploring use of `.parent` and `map`s etc. Manipulexity is just as important as whipupitude! .oO ( gmail's spell checker corrected my spelling of whipupitude, letting me know that it considered whipuptitude (with an extra 't') misspelled. Is that because it knows me, or has google started blessing Larry's neologisms for the whole planet?!? ) That said, a big part of my focus was due to: > I thought the raku one could be shorter but for now I'm stuck with a very > long solution. and > I'm pretty sure I saw a very concise and elegant way to... Any help on that ? And when I see that kind of thing I tend to pop my "clean golf" mental hat on. So it was good to hear the lead commentator appreciate my swing at it. :) -- raiph
Re: BEGIN {} question
On Sun, Sep 4, 2022 at 5:07 AM ToddAndMargo via perl6-users
wrote:
>
> For the fun of it, I placed a "booboo;"
>
> Interesting!
You might like to think of `BEGIN` as a signal to the "compiler":
"Please do more than just "compile" this code. Please also run it,
right now, before "compiling" any more code.".
Thus, when the "compiler" "compiles" the code below it will also "run"
enough of it to display "But this does".
say "This doesn't appear";
BEGIN {
say "Nor this";
booboo;
BEGIN say "But this does";
}}^%^& no matter what nonsense is here or below:
BEGIN !& }}!!%^&
The "compiler" will then display "===SORRY!===" as it gets to the end
of the first outer `BEGIN` and realizes `booboo` hasn't been post declared
(so hasn't been declared at all).
At that point the "compiler" has already compiled `say "Nor this";` but it
does not run it. This is so despite that `say` having appeared in a `BEGIN`.
That's because the lack of a `booboo` declaration in that outer `BEGIN`
block is considered so important that the "compiler" immediately gives up
doing anything more whatsoever -- so no more compilation *or* running.
Once you understand it's just the "compiler" going sequentially through
the source code, doing what the code tells it to do, and recognizing that
code like `say 42` is telling the "compiler" to display `42` when that line
of code is supposed to run, and recognizing that `BEGIN say 42` tells
the "compiler" that the time when that code is supposed to run is ASAP,
it'll hopefully all seem as simple and nice as it in fact is.
I've "scare-quoted" "compiler", "compiles", and "run" in the above because:
* The Rakudo "compiler" is actually a combined compiler+runner
* In Raku, "compiles" includes "running" code that "runs" at "compile-time"
* "run" means executing code, but that can happen during "compilation"
(Perl has a similar scheme -- it has a similar `BEGIN` construct.)
(In theory, Raku code that's already been compiled ahead of time, and all
that's left is to run it, should significantly outperform Perl. In
practice, getting
to the point that this is generally true is a work in progress.)
--
raiph
Re: steps of a path
Marc Chantreux wrote:
>
> I got ([^1,^2,^3]) and tried to generalize it with something
> more generic (using * to get the number of elements).
Yeah, I was disappointed that that didn't work, and that what
did was relatively ugly, which is why I didn't bother to share it.
<<. raku -ne '.Str.say for m:ex{^ [:r "/" <-[/]>+]+? }'
The `.Str.say` can be just `.put`.
I'm surprised about your preference.
Is that because you're unfamiliar with Bruce's suggestion
(cumulative concat), or worry others will be unfamiliar with it?
If not, can you see why I'm surprised -- why `m:g{ "/" <-[/]>+ }`
seems simpler to me than `m:ex{^ [:r "/" <-[/]>+]+? }`?
--
raiph
Re: steps of a path
On Sat, Sep 3, 2022 at 9:50 PM Ralph Mellor wrote:
>
> .put for [\~] '/A/B/C' ~~ m:g { '/'? <-[/]>+ }
That won't match just a slash (`/`). Maybe:
.put for [\~] '/A/B/C' ~~ m:g { ('/'? <-[/]>*) }
And it'll treat `/a/b` and `/a/b/` as distinct if the input string is `/a/b/`.
--
raiph
Re: steps of a path
On Sat, Sep 3, 2022 at 9:50 PM Ralph Mellor wrote: > > it makes more sense to do something like Bruce or Michel's solutions. s/Michel/William/ -- raiph
Re: steps of a path
On Sat, Sep 3, 2022 at 6:17 PM Marc Chantreux wrote:
>
> ( A B C ) to ((A) (A B) (A B C)) ?
[^1,^2,^3]
I could share a generalization but it's pretty ugly and I also think
it makes more sense to do something like Bruce or Michel's solutions.
Here's my variation:
.put for [\~] '/A/B/C' ~~ m:g { '/'? <-[/]>+ }
--
raiph
Re: Problems with defining a class
cf https://github.com/rakudo/rakudo/issues/1985
On Wed, Aug 24, 2022 at 2:47 AM Kevin Pye wrote:
>
> Hi,
>
> The following fairly simple code works well:
>
>class A {
> has num $!a is required is built;
> };
>
> dd A.new(a => 1e0);
>
> producing "A.new(a => 1e0)".
>
> However, if we make a slight change:
>
>class A {
> has num $!a is required is built;
> };
>
> dd A.new(a => 0e0);
>
> (i.e. initialising to 0 instead of 1), we get
>
>The attribute '$!a' is required, but you did not provide a value for it.
>in block at test.raku line 5
>
> Any value except 0 seems to work fine.
>
> Am I doing something stupid, or is this a problem with rakudo?
>
> Kevin.
Re: shorter way to set states in -n?
On Sat, Jul 2, 2022 at 5:26 PM Marc Chantreux wrote: > > AFAIK about raku -n, I need 2 lines to setup a state with a default value Does this do what you want: BEGIN my (@o, @f) = 0 xx 3; @o.push: "ok"; say @o; ? love, raiph
Re: probably worth a bug report ?
cf https://www.nntp.perl.org/group/perl.perl6.users/2021/04/msg9883.html
--
love, raiph
On Sun, Jan 2, 2022 at 7:35 AM Marc Chantreux wrote:
>
> hello rakoons,
>
> I got this error message
>
> Too few positionals passed; expected 1 argument but got 0
> in sub xxx at - line 1
> in block at - line 2
>
> Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.09.
> Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
> Built on MoarVM version 2021.09.
>
> by running this:
>
> <<\-. raku; raku -v
> sub xxx ( Pair $test ) { $test.raku.say }
> xxx key => 'value';
>
> and i think it's worth a bug: i don't know if
>
> xxx key => 'value'
>
> should parse but at least it deserve a less
> confusing message, don't you think ?
>
> regards
> marc
Re: update: meta data in Pod Block
On Sun, Jan 2, 2022 at 8:00 PM Richard Hainsworth wrote: > > What does not work (in that 'newkey' is not found in the 'config' part > of the Pod::Block returned by $=pod > > =head1 :key > > = :newkey I just tried that with Rakudo v2031.03 and got a compile time error for this line: = :newkey Preceding context expects a term, but found infix = instead. Did you make a mistake in Pod syntax? > But this does work, and it is a passing test in the Roast suite > > =head1 :key > > = :newkey For me I got the same error as above. This was so for anywhere from zero to 10 spaces between the `=` and `:newkey`. > However, the intent of S26, as stated in the raku documentation, is for > the first variant above to work, and also for the following case > > (this being what is intended as a virtual margin): > > =head1 :newkey > > = :newkey For me I got the same error (for the ` = :newkey` line). > But this does works (and it seems to be two virtual margins) > > =head1 :key > > = :newkey Same error. My results vs yours suggest someone has changed this behavior between v2021.3 and your version. Having looked at commits to Grammar.nqp since 2021.03 I don't understand how that can be if you're using a later version. > I have looked at the grammar for this situation, which I think is at > > https://github.com/finanalyst/rakudo/blob/ae2bf80dae74986c75f9a610f7a25cc1f6cdbb36/src/Perl6/Grammar.nqp#L5093 Blame suggests that code was.last affected (merely moved) 3 years ago: https://github.com/finanalyst/rakudo/blame/ae2bf80dae74986c75f9a610f7a25cc1f6cdbb36/src/Perl6/Grammar.nqp#L5093 > but I cannot see why the actual behaviour occurs, but the documented > (apparently intended) behaviour does not. The behaviour change and blame suggests it's not due to that line. Alternatively I am utterly confused. Either way, happy new year. :) -- love, ralph
Re: Implementation of documented POD6 behaviour
On Thu, Dec 30, 2021 at 12:18 PM Richard Hainsworth wrote: > > "In the future..." > > with a footnote that it is not implemented. > > I am willing to look at the Rakudo code and create a PR to > implement this functionality. Is there any reason not to do this I recommend you take into consideration the tremendous energy being applied to Pod by zagap, the author of Pod6Lite, and align any Rakunian effort with their effort. (As per the reddit thread I linked to in my previous reply to you in the file format thread.) > a POD6 table may not contain a POD6 table. This is a great example. Regardless of whether zagap does or does not intend to implement nested tables, simply *discussing* this issue with them should be very valuable. -- love, raiph
Re: file format extensions
On Thu, Dec 30, 2021 at 11:20 AM Richard Hainsworth wrote: > > It seems to me a short page in the docs.raku.org would > be useful with the various file extensions I'm +1 for this. I'm also +1 for recommending `.rakudoc` instead of `.pod6`. At least, for documentation files related to raku; what I mean by that caveat will become clear if you consider Pod6Lite, as discussed in the reddit comment I link below. > I think that POD6 is neither Plain, nor Old. How about RDM? Please read this related reddit comment (and, optionally, the earlier reddit comment it then links to): https://www.reddit.com/r/rakulang/comments/qwqpag/ podlite_ver_020_autocomplete_and_pod6_snippets/hlzbtfq/ (This latest reddit comment was written in the context of discussing Pod6Lite's name, but it's mostly about Raku's use of Pod6, not Pod6Lite's.) As you'll see, I propose we suitably backronym "Pod". In other words, stick with "Pod", but switch to new words for the P, o, and d. And I strawman propose "Package of docks" for reasons that will become apparent if you read the reddit comment(s) I've linked. -- love, raiph
Re: about binary protocol porting
On Wed, Dec 29, 2021 at 1:32 AM Jon Smart wrote: > > I plan to port a binary protocol client to perl6/raku. > I have zero experience on this. Where should I get started? How well do you know programming, and Raku, and is the protocol a standard one you can link to with several existing implementations? If the main motivation is just getting stuff done, consider using an existing implementation of the protocol. This will of course mean you'll have a dependency on that implementation, plus whatever PL it's written in, plus the Inline for that PL, but that can mean a working solution in a few minutes, maybe a few hours. A complementary or alternate strategy if you're willing to wait until the time is right would be to wait for alatennaub to get far enough with their binary regex effort: https://www.reddit.com/r/rakulang/comments/qqcnzr/binary_regex/ https://www.reddit.com/r/rakulang/comments/rm2tve/ writing_a_snes_assembler_compilerdisassembler_day/hpjziq4/ Then you could (presumably) use that. (And/or you could collaborate with them to accelerate things.) -- love, raiph
Re: Grammar Help
On Wed, Dec 29, 2021 at 5:10 PM Paul Procacci wrote: > > Ralph, > > So Ijust tried comma w/ grammar live view ... and I must say, > I'm blown away. \o/ > This really should be in the docs (it may be, but I didn't go looking for it). I just looked using googles such as: https://www.google.com/search?q=site%3Adocs.raku.org+%22commaide%22 I could not find any mention in the docs. I also looked in raku.org using googles such as: https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fwww.raku.org+%22commaide%22 This shows a mention on its Whatever page. (But not in association with grammars.) > It's really awesome to say the least. Thanks for pointing it out. Thanks for this follow up and have a great 2022. :) -- love, raiph
Re: is 'use v6' still a thing?
On Tue, Dec 28, 2021 at 5:00 PM Marc Chantreux wrote: > > long time ago, there was this 'use v6' line ... Does it still make sense? I think it depends. Let's first ignore Perl. Also, let's first assume your code is not visible online. Imo *not* including a language version statement is an explicit way to say "I explicitly don't care if this program works the next time it gets compiled". (Where, by "works", I mean it compiles and/or runs correctly, or at least as correctly as it did last time.) In some cases that is a perfectly reasonable attitude to have. If you're going to be there when the program is next compiled and/or run, or can easily react if anything doesn't work, and *especially* if you're in control of *updates* to your compiler (presumably Rakudo, at the very least in the next few years), then specifying the language version is mostly redundant. If instead you want your program to run as best it can, then imo an explicit language version `use` statement is needed, even if it's `use v6.d+;` or whatever nails down (or explicitly does *not* nail down) what language version(s) you want to signal are appropriate. Now let's continue to ignore Perl, but assume your program or library may be visible online. (Even if just on github but not intended to be part of the public ecosystem.) Consider those who develop Raku and/or compilers or tools for Raku. Let's say they're considering a change to Raku or a change to a compiler/tool, and the change's impact on any given source code depends on the Raku language version that that source code is presuming. So they decide to do an investigation of code in the ecosystem and in the wild, to get an idea of the practical scope and scale of the impact of the change. If your code does *not* explicitly declare what version it presumes, it may not be possible, or at least viable, to analyze it. Does this matter? Well, it's a bit like climate change. Each little thing we do makes close to no difference at all. But the sum total of what we do just about entirely determines what our future, and our childrens' futures, will be like. In this case it's "just" Raku. Does it matter? Finally, what about Perl? I see consideration of Perl as being pretty much the same as consideration of Raku. So I do, or don't, write a Raku language version statement, without thinking about Perl, feeling that if I do what's right for Raku, it'll be roughly right relative to Perl too. -- love, raiph
Re: Greeting Larry Wall: I will learn to love you new language.
On Sat, Dec 25, 2021 at 4:31 PM Maneesh Sud via perl6-users wrote: > > Merry Christmas and a Happy New Year. Hi. Happy holidays to you too. > Does perl6 or moarvm run on risc-v 32-bit processors. I think a key piece is dyncall/libffi support. Googling suggests dyncall doesn't support risc-v but libffi does. But I really don't know much about such things. I recommend you focus on the IRC channel #moarvm rather than this mailing list for more info/discussion of such matters. The channel is publicly logged and searchable. My search for `risc` draws a blank: https://logs.liz.nl/search.html?query=risc&type=words&nicks=&channel=moarvm&; message-type=&from-mmdd=2013-11-04&to-mmdd=2021-12-26 I suggest you log on there and ask. Here's a web client link: https://kiwiirc.com/nextclient/irc.libera.chat/#moarvm Good luck and happy holidays! -- love, raiph
Re: Grammar Help
On Sun, Dec 26, 2021 at 6:01 AM Paul Procacci wrote: > > Hope everyone had a Merry Christmas and takes likings to corny opening > statements. ;) I love me some corn but it's especially appropriate to share some in winter if you've got hungry mice. :) As others have noted, you need `%%` instead of `%`. Grammar::Tracer isn't always intuitive. Have you tried CommaIDE's Grammar Live View? https://commaide.com/docs/grammar-live-view I wonder if you would have immediately known what the problem was with the latter or if the problem was just that you were thinking `%` did what `%%` does? -- love, raiph
Re: Subscripting, semicolons, and adverbs
TL;DR Raku does not treat a negative index as valid. To specify the index of the last element, write `*-1`. What you're seeing is Raku trying to inform you that you are using invalid indices. On Fri, Dec 10, 2021 at 9:49 PM Sean McAfee wrote: > > @array[-1]:exists is a syntax error, even though it looks like > it should just evaluate to True. In Raku `foo[-N]` is invalid. At compile-time if N is statically known, otherwise at run-time. You must be used to PLs that treat a negative index as an offset from the end. Designers of older PLs considered this a feature. And indeed, for *literal* values it's arguably a reasonable choice, saving a character compared to Raku's alternative (`*-1`). But a mass of empirical evidence has shown that when this idiom is applied to *variables* it becomes a bug magnet. So Raku avoided that mistake, and instead carefully treats any negative indices as errors. These errors are reported at compile-time if the indices are literal, and at run-time if they're variables or expressions. By default run-time errors are reported via `Failure`s that are returned as the (error) value(s) of the failed indexing. `Failure`s are wrapped `Exceptions` that serve as (error) values. If you handle them, they are disarmed, but if you don't, or try to use them as if they were non-error values, they blow up at the first sensible time to do so. That is to say, immediately if you try to use them when unhandled or at their `DESTROY` time if you don't. > Actually, I get a bunch of those errors, as if they were stored > up by all my previous evaluations of @a[$i;$i]:exists. Yes. They are stored up because you ignored them, or at least didn't handle them. If you reread the error messages you'll see that that's what they convey. > If I continue to evaluate the expression repeatedly, I get > a run of Falses, then another batch of errors at some later > point. Exactly as they should. > I wonder if I'm somehow invoking undefined behavior No. You're "just" getting errors, suitably reported given Raku's design. -- love, raiph
Re: why not raku ?
On Mon, Nov 22, 2021 at 3:33 AM Clifton Wood wrote: > > It has two compelling use cases, and it's the ones that > brought me to Raku in the first place: It has compelling use cases for me too, and I agree that grammars and nativecall are both contenders. :) But, fwiw, I didn't say just "compelling use cases" but: > no widely recognized distinctive compelling use case In other words, use cases folk out there know about, and that what they know about them makes them stand out. (Btw, I certainly don't think we should be trying to *promote* them to make them known and stand out. When they're ready, they'll promote themselves.) Imo the primary weakness with grammars for now is speed. Aiui the primary weakness with nativecall is header conversion. > I've written utilities that make much of the work of > porting an .h file as simple as running a single script. That's the ticket! :) > I have to overcome the CURI output limitations first. Right. Needs more polish, or even heavy duty work, is still the case for a lot of what Raku(do) have to offer. I anticipate things will just keep on improving, and newcomers will keep on turning up. > I guess I'll be releasing the first lib sometime soon. Either way -- sooner or later -- it sounds like just the ticket. :) -- love, raiph
Re: why not raku ?
My 2c: On Fri, Nov 19, 2021 at 9:45 AM Marc Chantreux wrote: > > > I like ruby and perl > > so do I but raku is by far my prefered interpreted langage now. Nit. It's compiled, in the same way Java or C# is compiled. Consider: ``` say 42; constant foo = die; ``` If it were interpreted, the `42` would appear, and then the program would die. But instead it dies at compile-time (`constant`s are initialized at compile-time). That said, the usual way of using it is to run a program, which compiles it, and then, if it successfully compiles, immediately runs the compiled program. > I don't raku that much and most of the time, i read the > doc more than i actually write code but when it's writen, > it's always elegant and concise the way i never seen before. Many folk who like Ruby or Python or Lang X say much the same thing about those PLs. > > Maybe perl6 is still not production-ready? Imo it's as production ready as Python. > > but why so few open source projects which were developed by perl6? It's all relative. Compared to most of the thousands of PLs with less projects, there are lots of projects developed in Raku. But you presumably mean in comparison to the likes of Python and Ruby. There are many factors. Some I'd focus on are: * It's unusual. Few folk like that. * It has a large language surface area. Few folk like that. * It's very slow. Very few folk like that. * It has no widely recognized distinctive compelling use case. As a consequence of these and other factors there is minimal interest in it so far, let alone adoption. So now, one can add another factor: * It isn't interesting to most, and has had minimal adoption so far. Almost NO folk are OK with that. So now, one can add another factor: * Almost NO folk want to help develop it. And you can't attract them either. Unless they get it. Because then they fall in love with it. And so it rolls. For now. So, for now, it needs more work, as it has always done. > * raku shines on interpreted langages when people are > moving to compiled langages It's a compiled language, so that's not quite right. Perhaps you meant it's dynamically typed rather than statically typed, but that's not quite right either. If one squints, it's an open source alternative to Oracle's Truffle/Graal/JVM, but it's wy slower. > * raku is that rich it's hard to get it in a first view I'd say it's hard to *ever* get most of it. It's as ambitious as Truffle/Graal/JVM, perhaps even more so. But it should and *will* be easy to get it a little at a time. But we're not there yet. There's a fairly obvious way to make it vastly easier. Which is to create mini languages that aren't Raku but showcase selected parts of its talents. But that will have to wait until RakuAST lands. And perhaps a language version *after* that. So perhaps 3-4 years if we're lucky. > * raku is still way too slow to be taken seriously > by a large audience Yes. For now. > * js or python developpers are legions on the market > now so everyone choose this as an argument Yes. And ts devs too. > * we need more packages on raku.land I don't think that's important. We need better Inlines. We need to deflate the packages/modules/libs argument. > * i really think technologies are massively adopted when they are > packaged in main linux distros because lot of people don't want to > bother compiling an interpreter or adding extra repos to do it. I can see there being an opportunity to create a popular package before this decade is out in the form of (a fresh repackaging of) NQP as a "Raku Rules" engine / latter day PCRE / new alternative to Truffle/Graal/JVM. -- love, raiph
Re: can't make from a S/// ?
On Fri, Nov 19, 2021 at 8:32 AM Marc Chantreux wrote:
>
> [switch `($/)` signature to `($_)` and `make` to `.make:`]
>
> i dug around it but missed it! arggh ...
I've been digging around online doc etc and spotted
that this is covered on the Traps page of the official doc:
https://docs.raku.org/language/traps#Using_regexes_within_grammar's_actions
The Traps page does *not* suggest topicalizing (changing `$/` to `$_`).
I began to wonder if that was due to the concern I raised:
> I've no idea where the `$/` that `S///` clobbers comes from.
But I'm now pretty convinced that each new routine gets its
own writable `$/` initialized to `Nil` which any regex operation
(eg `S///`) is then free to use.
So I tentatively conclude that topicalizing the match object
argument is an appropriate idiomatic way to enable use of
regex operations within an action method.
(But you do need to be clear that you're using `$_` in the
signature, not `$/`. In your exchange with Bill, you've been
talking past each other about the fact you mistakenly wrote
`$/` not `$_` in your method signature, despite saying you
were showing him the topicalization solution I'd shared.)
> > But it draws you into the `$/` dance.
>
> The way I read you is "no" as i can't reassign inside a grammar.
You can't *at the outer level* of *a regex/rule* . That's not quite the
same thing as you've just said. I'll try to explain.
Raku automatically inserts a `$/` *symbol` into each regex or rule.
It always makes it read-only, and you can't do anything about that.
It also always binds a fresh match object to that `$/` symbol. And
match objects are (shallowly*) immutable.
So you can't re-assign or rebind the `$/` symbol at the outer level
of a regex or rule, nor mutate the captures in the match object it's
bound to.
* (You can alter the `.made`/`.ast` attribute by using `make`/`.make`)
When you write an action method, its body is *not* a regex/rule.
So you don't get an *automatically* inserted `$/` symbol. Instead,
you have to introduce it.
The norm is to write `$/` as a parameter, and to do so without an
`is copy` trait. As such, it ends up being read-only, and bound to
a match object, just like it is inside a regex/rule.
But you're in control of declaring `$/` inside *GPL* blocks. Thus
the topicalization approach we both like, or the `$/ is copy` that
the Traps page suggests.
Or you could write:
```
'a' ~~ / . { print $/; $/ = 42; print $/ } / # a42
```
This is why I qualified references to the `$/` symbol with "outer level".
Where the `.` is the `$/` symbol is read-only and is bound to a match
object that can only be altered by writing regex pattern code. But in
the `{...}` block inside the regex, the `$/`, while still initially bound to
the match object, is reassignable/rebindable.
> what i was expecting is to hack the grammar itself.
While you can control what ends up in match objects, you
can only do so by writing regex patterns which capture, or
by hanging extra data off of match objects by using `make`
(or `.make`).
Note that the captures in a match object aren't strings as such.
Instead they're from/to *indexes* into the matched string.
So, whatever parse tree you end up with, all of its captures can
only contain `from`/`to` indexes into the original input string.
So you can't "lie" the way the Perl parser lies, or the way Marpa's
"Ruby Slippers" feature does:
http://blogs.perl.org/users/jeffrey_kegler/2011/11/marpa-and-the-ruby-slippers.html
On the other hand, you *can* "just" create whatever *Alternative Facts*
(Ruby Slipper like) syntax tree you want *on top of* the *Concrete*
Syntax Tree aka parse tree. You can do that today -- as you know --
because that's precisely what `make` allows.
cf the notion *Alternative facts Syntax Transformation* I just
invented as another entry that could be added to the rather
unusual answer to the Computer Science Stack Exchange Question:
> Is "sparse subtree" an appropriate term for what I describe in this question?
at https://cs.stackexchange.com/questions/95759/
is-sparse-subtree-an-appropriate-term-for-what-i-describe-in-this-question/114689#114689
;)
> your solution is really elegant
:)
--
love, raiph
Re: can't make from a S/// ?
On Fri, Nov 19, 2021 at 1:19 AM Marc Chantreux wrote:
>
> method col:sym ($/) { make S:g/'""'/'"'/ with ~$/ }
>
> Cannot assign to a readonly variable or a value
>
> why isn't it working?
1. Even though `S` politely leaves "the current topic" (`$_`)
alone, it still generates a match object, and then binds that
to "the current match object" (`$/`).
2. In your method's signature you include `$/` as a parameter.
Like all such parameters, it defaults to being a read-only one.
See also:
* https://stackoverflow.com/questions/40970080/
perl6-rakudo-2016-11-match-tries-to-assign-to-read-only-variable-why-not-in-201
* https://github.com/rakudo/rakudo/issues/1235
> how to fix it
I'm not saying the following is how to fix it. But I'll show
code that works for your example.
The key thing is that, if you're going to use `S///`, you
need to deal with the fact it will overwrite `$/`.
Note that the answer is NOT to make the `$/` parameter
writable using `is copy` or `is rw`. The first argument that
is passed to a method in an actions class is the match
object that's just been matched. And you need that so
you can hang some data off of it using `make`. You do
not want it clobbered!
Here's what I suggest you consider:
method col:sym ($_) { .make: S:g/'""'/"/ }
What I've done here is to switch from `$/` to `$_`. This:
* Frees up `$/`. So the `S///` can now clobber it.
* Means I have to write `.make:` instead of `make`.
I could have changed the `with ~$/` to `with ~$_` but
it's already the topic (and gets coerced to a string).
> am I right when i feel there is a way to do this
> substitution inside the grammar
As I've shown, yes. But it draws you into the `$/` dance.
> is it a good idea?
First, in a comment in the issue I linked above, jnthn writes:
> using subst [ or `S///`] inside of an action method would
imply re-parsing, which one should think twice about anyway.
Second, I've no idea where the `$/` that `S///` clobbers comes from.
If we could confirm what I wrote is safe, then perhaps it's one
appropriate idiomatic response to the issue.
If not, the following clumsy solution might be the way to go:
method col:sym ($_) { my $/; .make: S:g/'""'/"/ }
--
love, raiph
Re: junctions with given/when
On Thu, Nov 4, 2021 at 7:27 PM Joseph Brenner wrote:
>
> Yes, thanks, I'd managed to forget that we had a go-round
OK. Cool. I wasn't sure if it was the same issue (hence my aiui
qualification). It's helpful to hear confirmation you consider this
to be the same issue.
Btw, I'd say it was not only a go-round, but led to Larry's helpful
wrap up of / response to the discussion.
(And inspired me to research smartmatch/junction bugs already
filed in our existing bug queues, and succinctly document my results.)
So, from my perspective, the main thing was that it was a
particularly *productive* go-round.
In addition, although it *almost* stalled there, with no-one
filing an issue, the process by which issues get resolved,
it has now moved on.
If there are aspects that are worrying, it's that an issue
wasn't filed as a consequence of the discussion, and, as
a related concern, when issues *are* filed the quality of
the filing and follow up is troubling.
> I'm actually finding this one profoundly depressing
Hopefully your attention has now moved on to other things,
but in case that wasn't the case, or the underlying thoughts
haven't gone away, and at the risk of me being the one to
bring you back to them, I will continue.
> but I probably shouldn't get into it.
I think it's healthy to get into it, as I note you did. Feelings
need to be aired in your own mind, and shared with others.
First and foremost, I hear you. Feeling profoundly blue about
Raku is like feeling profoundly blue about anything. It sucks.
Unfortunately -- but also *fortunately* -- feelings, unlike thoughts,
are like waves, tides, seasons -- they come and go and there's
nothing that can (nor should) be done to stop them flowing one
way and then the next.
> My thoughts are running along lines like "how is it possible
> something like this is still up-in-the-air at this date?"
Unlike someone expressing their feelings, which doesn't need
to be rationally understood but just is what it is, thoughts are
are different thing.
This summary of your thoughts suggests that, behind your
feeling of depression, was *confusion*. ("How is it possible...?")
I suspect that that's *not* it, but perhaps it is?
If it *was* confusion, then would it be helpful to discuss how
an issue like this still being up in the air is not only very much
possible but is one of thousands in Raku -- as it is in pretty
much all PLs? (Python's issue tracker contains 57,000 bugs
with 7,000 with status "open", and others "pending", "closed
(wontfix)" and so on.)
(Or was the confusion about it apparently being the case that
no issue had been filed?)
If it *wasn't* about confusion, was it instead a sense that,
while it's reasonable that Python and other mature PLs
(used and developed by relatively huge communities) have
many more such issues still outstanding decades after devs
have first encountered them, Raku is supposed to be a new
PL, so shouldn't have long standing bugs?
Or something else?
> "is this language too complex to be implemented cleanly?"
Perhaps it's worth acknowledging that Python, which is
supposed to be "simple", is far more complex to implement
cleanly than Raku.
> and so on.
When thoughts are entrained to a feeling, there's usually no
stopping them. Hopefully you've had a day or two break from
where you were at and that has helped. And/or my email here
has helped. And/or your Raku study group, presuming you do
continue with that. Then again, perhaps not. Maybe thing to do
is to step away from spending time with Raku, at least for a while?
--
love, raiph
Re: junctions with given/when
On Thu, Nov 4, 2021 at 6:34 PM Ralph Mellor wrote: > > Aiui, until we listen to Larry, accept he's right, and fix Rakudo, > the results when the topic of a smart match is a Junction will > randomly depend on which version of Rakudo you're using. Further, aiui, when we do, there may be a world of pain due to widespread coding that goes against what Larry has said should be the case for sanity. As I note in the issue, I have used the idiom: where .all ~~ foo a LOT. Uhoh. Which is why I filed it as a problem solving issue. Because if things are as I understand Larry is saying they are, then we'd need to go through detailed, calm, measured discussion if we're to minimize the pain it seems we'll inevitably endure pain to dig ourselves out of the hole we'd be in. -- love, raiph
Re: junctions with given/when
Aiui, we discussed this issue in May and Larry explained that this would happen. Larry doesn't speak up much, and I realized a few months later that it seemed no one had done anything about what he had said. So I filed an issue: https://github.com/Raku/problem-solving/issues/297 Aiui, until we listen to Larry, accept he's right, and fix Rakudo, the results when the topic of a smart match is a Junction will randomly depend on which version of Rakudo you're using. -- love, raiph
Re: A nice touch
On Mon, Nov 1, 2021 at 2:38 AM Ralph Mellor wrote: > > `R` reverses associativity, which is *another* way that `R` is a > nicely designed metaoperator, though this latter aspect is not > relevant to why it worked for the solution you came up with? Ah no. Of course it has to do the reversal or it wouldn't work. Got it. Sorry about me being slow to get with the program. (I think my mind had jumped ahead to "Ah, of *course* it reverses the associativity", then got focused on the fact that it *also* requires that `1..0` returns an empty list, and then lost sight that *both* behaviours are needed for your elegant golf to work.) -- love, raiph
Re: A nice touch
On Sun, Oct 31, 2021 at 6:10 PM Sean McAfee wrote: > > the main point of my message was about the R metaoperator and the > associativity of the operator it creates. OK. Fwiw this was something I didn't know, or had forgotten, and I find it delightful. The main point of *my* comment was that I didn't -- and still don't -- understand why the associativity switch is relevant to the result. I'd appreciate you explaining that. > the difference you mention is indeed exactly why .. works but ... doesn't. What I was thinking was that `..` explains why it works, and I couldn't see how associativity was relevant. I wondered how to best convey that, and thought showing `...` as well would make that a bit clearer. Anyhow, as I said, why is associativity relevant to this working? Or were you sharing three things -- first, the joy of discovering an elegant golfing solution, second, that using an `R` with `..` is an important case for the reasons you've demonstrated, and third, that `R` reverses associativity, which is *another* way that `R` is a nicely designed metaoperator, though this latter aspect is not relevant to why it worked for the solution you came up with? -- love, raiph
Re: A nice touch
On Sat, Oct 30, 2021 at 8:38 PM Sean McAfee wrote: > > It worked! But I couldn't quite see how. > > Anyway, pretty cool! I agree it's cool, at least in a golfing sense. But is your explanation right? The *range* operator (`..`), if the rhs is less than the left, yields an empty list rather than iterating between the endpoints. In contrast, the *sequence* operator (`...`) iterates. So, in code: say [*];# 1 say [*] ();# 1 say list 1..0; # () say [*] 1..0; # 1 say list 0..1; # (0 1) say [*] 0..1; # 0 say list 1...0; # (1 0) say [*] 1...0; # 0 say list 0...1; # (0 1) say [*] 0...1; # 0 -- love, raiph
Re: ftp client yet?
Damn but I'm a sucker for punishment. :)
On Sun, Oct 31, 2021 at 12:14 AM ToddAndMargo via perl6-users
wrote:
>
> I think you misunderstand.
Fwiw I think you misunderstand.
If the penny doesn't begin to drop with this email I think
my head will explode. Or maybe my tail.
> The code I want to convert is code that I wrote.
> I want to migrate it to Perl 6 from Perl 5 because
> Perl 5 is 20 times more difficult for me to maintain.
You've already said that (countless times).
So convert it!
> I am getting tired of "what the h--- is this and what the h--- is that"
> when I have to go into my Perl 5 code.
You've already said that.
Then rewrite it in Raku!
> Perl 5's subroutine syntax is an abomination for starters
(You've already said that.)
So don't use it, use Raku's instead!
> I write in Top Down.
(Yep.)
So do that!
> And Perl 5's OOP is a nightmare for me to read
You've already said that countless times.
So write Raku OOP!
> which "Net::FTP" is very fond of.
NOT IF YOU USE IT IN RAKU!
How can you be missing this?
You `use` a package from Perl.
But you WRITE *ordinary* nice Raku code to use its features.
Here's another version of the example I provided a century ago:
my $ftp = Net::FTP.new: "some.host.name";
Can't you see that that's Raku code, not Perl code?
And just in case you're thinking that that's the Raku `Net::FTP`,
it isn't. It's the Perl one. Or maybe it *is* the Raku one. That's
the whole point. You can't tell.
It's only the `use` statement that precedes it that determines
which package you're using.
The subsequent Raku code that uses its features is written
in ordinary Raku code, without regard for whether the `use`d
package is a Perl one or a Raku one.
Raku magically translates between the two languages without
the Rakoon having to care that there's magic going on.
It's analogous to writing this:
say 42;
and running it on a Windows machine.
That USES Windows. But you don't have to READ the C source
code of Windows. (Indeed, you *can't* because it isn't open source.)
All you READ is YOUR code, which is `say 42;`, not C.
If you really can't see that this is Raku code:
my $ftp = Net::FTP.new: "some.host.name";
then my heads *and* tails will explode.
-
But still, I get that you want eventually to stop *depending* on
Windows. (Or Perl packages, even if you pay them no heed.)
I got that from the start, *before* my first comment in this thread.
So hopefully you can understand that even if you were to *start*
`use`ing Perl packages in your Raku code, I'm *not* saying you
would need to *end up* with them.
That is to say, *starting* to `use` Perl packages in your Raku code
can be the best way to *stop* `use`ing them in your Raku code.
You start by `use`ing a Perl module. You write Raku code that
uses the module's features. When it's correctly doing what you
want, you then write a Raku module that replaces the Perl one.
This can happen in a matter of hours. Or can be done bit by bit,
over a longer period, using *both* modules, side-by-side, with
some code using features of the Perl module, other code using
features of the Raku module, and even passing data from one
to the other.
As part of this migration you might have:
use Net::FTP:from;
use Todd's::Raku::FTP;
my $ftp1 = Net::FTP.new: 'foo';
my $ftp2 = Todd's::Raku::FTP.new: 'bar';
...
sub connect-ftps ($ftpa, $ftpb) { ... }
connect-ftps $ftp1, $ftp2;
> And if the ftp module in Perl 6 is not ready yet
Why are you saying that?
The `Net::FTP` which is *written* in Perl can be *used* in Raku.
It's ready.
The `Net::FTP` which is *written* in Raku can be *used* in Raku.
It's ready.
> All I need is how to open and close a network connection.
All you need to do is to `use` a package with ONE LINE OF RAKU
CODE and then use the features of that package by writing some
more simple lines of Raku code.
Why reinvent wheels that are circular by writing half a spoke that's
already available in the wheels being made available to you for free?
> I have to use free hand ftp code where I write the command
> and run string already a few times in my Perl 5 code.
Just translate your Perl code to the equivalent Raku syntax.
Just a mechanical translation. For example, `->` in Perl becomes
`.` in Raku.
Then, at the top, append `:from` to the `use` statement for
`Net::FTP`.
Done.
--
love, raiph
Re: ftp client yet?
On Sat, Oct 30, 2021 at 5:03 AM ToddAndMargo via perl6-users wrote: > > I was trying to get the whole thing in Raku. Why are you rejecting the "whole Raku" solutions that have been suggested to you in this thread? Your original questions were: * ftp client yet? * Do we have a working ftp module yet? The only answers I've seen are "yes". According to you, the answer was "no". Why do you think that? One suggestion was `LibCurl`. Your response was: > I really need access to the full set of FTP commands, especially > when I am drilling down directories renaming things that won't > delete properly. I can't currently see why curl / `LibCurl` wouldn't give you access to "the full set of FTP commands". Aiui it's "just" a wrapper for a range of protocols, including command/response ones like FTP. `LibCurl` looks robust to me. If you know the author and/or browse the README, the PRs, the issues, and the 2K+ LoC, you will see it is a very well stewarded package that's been continuously improved. Have you installed `LibCurl` and tried it? Curt mentions *another* curl package `Net::Curl`. What about that? The other suggestion was `Net::FTP`. If you know the author and/or browse its README, PRs, issues, and the nearly 2KLoC, you will see it was a well stewarded package that was improved over a 3 year timespan before the author moved on to other PLs. You wrote a comment in an issue of `Net::FTP` in 2017 asking if installing it would be fruitful. The author was appropriately non-committal. Did you try it? A PR by Zoffix was merged a year later. Have you tried it since then? I saw nothing to suggest the authors of these packages would not merge PRs if you provide them. I'm unable to retrieve the License for `LibCurl`, but it appears to be very permissive / public domain. I'm confident the author will provide you with a license document if you wish to read it. The `Net::FTP` license is the excellent Artistic 2, and the author has switched the copyright to TPF. Obviously neither of these packages will perfectly cover everything anyone could ever want from them. That would presumably take a lot more than the mere 3 years of work araraloren put into Raku's `Net::FTP` and 5 years Curt Tilmes has so far put into `LibCurl`. But is your use case really so complicated that these packages don't already cover your use case? Even if they don't yet work for your use case for some reason, why aren't you *improving* these existing packages? They work and they are written in Raku. So what's stopping you using and improving them? I then provided a *third* option that *also* doesn't require that you write *any* Perl code, only Raku code. I did that partly because you'd written: > Can you point me to a paper on how to do that? That suggested you thought it was complicated. It isn't. It's dead simple. (Append a `:from` to a `use` statement.) > the "from perl 5" is cool stuff for sure, but I would still be > maintaining 90% of the code in perl 5. No, you wouldn't. You would get stuff *working* in *Raku* in the *fastest and most efficient way possible*. And *then* you would improve things from there. This would let you *start* with a solid development scenario, with a large test suite to code and test against, and a working solution to compare with your own until you can drop the Perl code. How can that be a bad thing? But perhaps you're saying that, forget *writing* Perl code, you can't cope with even *reading* Perl code, even if it's well written. Not even code that would be essentially *guaranteed* to be *tiny fragments* -- almost all just one or two lines each -- each of which is both *well written* and *fully *documented* (because *all* of them would be *only the code in synopses*). If so, if you can't even *read* single lines of well written Perl code, then fair enough, the `use` Perl approach is a bust. > So it is better just to stay in p5. It sounds like you're saying you'd rather keep *all* your code in Perl, because it's too difficult to *migrate* to Raku step by step. That makes no sense to me. But if that's how you see it, fair enough. I don't understand what you are thinking. I get the impression you don't understand what I'm thinking. So it's now *definitely* time for me to give up. Good luck! -- love, raiph -- love, raiph
Re: ftp client yet?
On Fri, Oct 29, 2021 at 7:11 AM ToddAndMargo via perl6-users wrote: > > Which gets back to my original question, which was > is there good FTP support from Raku yet? The answer you got from me was: 1. Install Perl's Net::FTP. 2. Write `use Net::FTP:from;` in your Raku program. In other words, just like you would in Perl, but appending `:from` to the package name. 3. Write ordinary Raku code as if Net::FTP was written in Raku. If you interpret that as "no", then I give up. If you interpret that as "yes", then please do what it says. If you don't understand it, then I give up. -- love, raiph
Re: ftp client yet?
On Thu, Oct 28, 2021 at 7:40 PM ToddAndMargo via perl6-users wrote: > > You would not happen to know how I could directly > write to FTP myself with Raku? Yes. 1. Install a library that implements FTP. 2. Use it. > The RFC for FTP is pretty easy to follow. It's *much* easier to write a `use` statement. love, raiph
Re: ftp client yet?
> On 10/25/21 22:21, Ralph Mellor wrote: > > > > You should be aiming to end up being able to write > > something like the following three line Raku program: > > > > use lib:from 'dir-where-your-new-module-is'; > > use your-new-module:from; > > RmdirAndLoop 'junk', 1, 3; And when that's working, aim at just two lines: use your-new-module:from; RmdirAndLoop 'junk', 1, 3; (ie the `use lib:from 'dir-where-your-new-module-is';` is untidy. You should make that statement redundant by just putting your module in one of your Perl's `@INC` directories.) If you get it down to two lines, you could then reasonably ask how you might reduce it to one: RmdirAndLoop 'junk', 1, 3; That would make sense if you wanted the module (that this function is in) to be automatically loaded each time that Rakudo starts so you don't have to bother to explicitly load it, but instead just always have it, and its functions, available by default. Rather than explain how to do that (it's not as simple as it could be), that refinement can wait until you get it down to two lines first. > love, -T :)
Re: ftp client yet?
> This is what the more complicated stuff I am doing. You can also use *your* Perl code in your Raku code. Just turn your Perl code into a module, making sure to make "public" whatever the module should make public, then `use` it in your Raku code. You should be aiming to end up being able to write something like the following three line Raku program: use lib:from 'dir-where-your-new-module-is'; use your-new-module:from; RmdirAndLoop 'junk', 1, 3; -- love, raiph
Re: ftp client yet?
On Fri, Oct 22, 2021 at 8:45 AM ToddAndMargo via perl6-users
wrote:
>
> >> On 10/21/21 22:03, Kevin Pye wrote:
> >>>
> >>> Why not just use the Perl Net::FTP?
> >>
> >> I use that in Perl 5.
> >> I am trying to divorce myself of Perl 5.
Please consider not divorcing yourself from Perl
stuff you know works until you have hit problems
in Perl code that you absolutely know you cannot
fix OR you KNOW it works in Raku.
Taking the "use Perl" approach will in general be
very helpful to Raku, AND to Rakoons, AND to Perl,
AND for solving problems, AND for your clients,
AND for yourself, even if it feels otherwise at first.
Here's how I suggest you get going. Post back
here if you get stuck.
1. Install Perl's Net::FTP.
2. Write `use Net::FTP:from;` in your
Raku program. In other words, just like you
would in Perl, but appending `:from`
to the package name.
3. Write ordinary Raku code as if Net::FTP
was written in Raku.
For example, here's the start of the synopsis from
https://metacpan.org/pod/Net::FTP#SYNOPSIS
use Net::FTP;
$ftp = Net::FTP->new("some.host.name", Debug => 0)
or die "Cannot connect to some.host.name: $@";
So, to do the same thing, but using Raku instead of Perl,
you'd install the module as usual, and then you'd write
the following in a Raku program:
use Net::FTP:from;
my $ftp = Net::FTP.new("some.host.name", Debug => 0)
or die "Cannot connect to some.host.name: $!";
Note how you have to write Raku code, not Perl code,
even though you're using a Perl module. So I've used:
* `my`. Unlike in Perl, you can't omit that.
* `.` instead of `->`. Raku uses `.` for method calls.
* `$!` instead of `$@`. Raku uses `$!` for exceptions, unlike Perl's `$@`.
I'm not sure if the `debug => 0` is going to work. But
try it and see what happens.
So that's the approach.
You use a Perl module that used to work for you, or that
you think should work for you. You tack a `:from`
onto the end of the `use` statement. Then you write Raku
code, making sure to translate any Perl syntax, special
variables, and so on, to their Raku equivalent.
For your first couple goes at this you might trip up over
simple things, and we might also struggle to help you
even though they're simple things.
But after you/we get two or so simpler uses of existing
Perl modules in Raku under our collective belts, we'll
have a hugely important new thing happening, and the
World will become a much better place because of it. :)
--
love, raiph
Re: I need a better regex with a literal in it
> > You can put any Raku code that produces a string > > into a regex by using the syntax `$(code)`. > > > > my $x ~~ s/ Q[;";] //; > ===SORRY!=== > Unrecognized regex metacharacter ; (must be quoted to match literally) You didn't use the syntax I showed. You need to put your code (in your case `Q[;";]`) where `code` appears in `$(code)`. So: ``` > $x ~~ s/ $( Q[;";] ) // ｢;";｣ ``` > > love, raiph > > Great tutorial. Thank you! (I love you too Raiph.) Thx. Yw. (:))
Re: I need a better regex with a literal in it
> Wish I had a Q[;;;] expression inside a regex You can put any Raku code that produces a string into a regex by using the syntax `$(code)`. So this displays `True`: ``` say so Q[ / ;;; ^&%%$$ ] ~~ / $( Q[ / ;;; ^&%%$$ ] ) / ``` as does: ``` my $string = Q[ / ;;; ^&%%$$ ]; say so $string ~~ / $( $string ) /; ``` > when does regex NOT start reading at the > beginning of the input data stream? Never. It *always* starts at the beginning of the input. > Why does it need the ^ You use `^` when you want a pattern to be *anchored* to the start, so that if it fails at the start then that's it. To understand this, consider an example. Let's say you have an input string 'foo'. An `/ oo /` regex will match, because it doesn't contain an anchor, so the pattern is free to match *anywhere* in the input string. That is, while it *fails* to match *at the start*, because an 'o' does *not* match an 'f', *it keeps going*, and then succeeds when *the next* two input characters *do* match. In contrast, `/ ^oo /` will *not* match, because the `^` "anchors" the match to the *start* of the input string, i.e. immediately before the 'f' in 'foo', and the first 'o' in `^oo` does *not* match the 'f', and given that the match is *anchored* to the start, if it fails at the start, it gives up. I've no idea what was causing your hang, but fwiw it doesn't make sense to me that it happened due to a zero length input or an undefined variable. love, raiph
Re: intermixed types and resulting types
On Sun, Aug 22, 2021 at 4:59 PM yary wrote:
>
> "How would you know what types are compatible for a particular operation?"
>
> inspecting a routine's arguments.
Bingo.
> The first couple candidates raise questions for me
>
> multi($x = 0) - how is there a single-arg candidate for an infix operator?
It's a really nice design for expressing what to do in situations like this:
```
say infix:<+>(42); # 42
my @numbers = 99;
say [+] @numbers; # 99
```
Similarly there are zero parameter candidates to cover zero arg cases:
```
say infix:<+>(); # 0
my @numbers;
say [+] @numbers; # 0
```
See https://en.wikipedia.org/wiki/Identity_function for the related concept
used in mathematics. Raku uses these zero/one parameter signatures to
provide a clean general solution to the general problem of what to do if an
infix operator is passed less than two arguments.
> multi(\a, \b) - does this accept everything, is it a "cleanup"
> candidate for error reporting?
It accepts any call with two arguments (as is the case for most
calls) if none of the other two parameter signatures match.
My guess would be that it's for error reporting. (Ideally one would
be able to call `.WHY` on that candidate to see why it was written,
in this case to see if it was for error reporting.)
> I'm curious about how some candidates bind to bare names
> \a, \b while others use sigilled variables, I'm assuming that's
> due to the original programmer's style preference.
A sigil implies some (rudimentary) type information. For example,
an `@` implies `Positional`, which is pretty generic but not entirely
so. Then there is of course the ultimate generic sigil, namely `$`.
But while it is indeed *very* generic, it still implies some rudimentary
type information that isn't 100% generic. For one thing, it hints that
the value it's bound to probably *isn't* `Positional` or `Associative`.
(Otherwise, why didn't they use `@` or `%`?) For another, it allows
traits to be applied that add other dimensions of type information.
Consider this code:
```
multi foo (\a) { say a }
multi foo ($ is rw) { say '$' }
multi foo (@) { say '@' }
multi foo (%) { say '%' }
foo @; # @
foo %; # %
foo $; # $
foo 42; # 42
```
Slashing the sigil out removes any ambiguity (or, if you prefer,
*maximizes* the ambiguity) of what a variable is bound to. It could
be bound to *anything* -- `Positional`, `Associative`, or otherwise.
So slashing the sigil -- `\foo` -- jumps out as being somehow even
more generic than using `$`.
--
raiph
Re: What's going on with "given (junction) {when (value)...}"
On Wed, Jun 2, 2021 at 11:57 AM William Michels wrote: > > Hi Ralph, Both prefix/postfix 'when' look okay on my Rakudo_2020.10 install: Only postfix in 2021.03: https://replit.com/@RalphMellor/FooACCEPT-junction#main.raku
Re: What's going on with "given (junction) {when (value)...}"
Curiously, it works for postfix `when`:
```
$_ := any(4,3);
{say 'postfix when'} when 3; # 3
when 3 { say 'prefix when' } # (no output)
```
--
love, raiph
Re: What's going on with "given (junction) {when (value)...}"
On Tue, Jun 1, 2021 at 4:02 AM Larry Wall wrote:
>
> In my opinion, the most consistent approach is to disallow any
> autothreading of the argument to .ACCEPTS
That sounds like a really appropriate simplification as I write this.
> All those other smartmatches are sugar for .ACCEPTS, and
> should not introduce special cases either.
Sounds great.
> If you want to make use of a junction like that, you must write
>
> when 3 ~~ $_ {...}
>
> or
>
> when 3 == $_ {...}
>
> or so.
Nice.
In the following, ALG = Applying Larry's Guidance.
Do we need an overhaul of .ACCEPTS methods wrt Any / Mu?
https://github.com/rakudo/rakudo/issues/2676
ALG would resolve this?
Range.ACCEPTS gets some things wrong
https://github.com/rakudo/rakudo/issues/1809
ALG would inform problem 1.
For the following ALG *might* be relevant but I haven't
thought things through at all.
Autothreading gone wrong?
https://github.com/rakudo/rakudo/issues/2814
Change in behavior when (starts-with|ends-with|substr-eq|contains)ing a Junction
https://github.com/rakudo/rakudo/issues/2719
using junctions in grep and split is inconsistent
https://github.com/rakudo/rakudo/issues/3893
Junctions don't autothread some methods correctly
https://github.com/Raku/old-issue-tracker/issues/6183
If anyone wants to dig into one or more of those issues,
and decide whether Larry's guidance here is relevant to
them, and link to his guidance if so, that would be cool.
--
love, raiph
Re: File::Find using a junction with exclude
On Fri, May 21, 2021 at 4:36 PM Ralph Mellor wrote: > > * Things multiply. If *two* function arguments are junctions, and > each junction has, say, three elements, the function is set to be > called *six* times. That should have been *nine* times. > * The combination has to follow precedence rules. I forget what > they are, but the general scheme is that there are two levels > and they do what's most natural. This will of course sound very > odd so I'll leave it as a thing to explore if you explore this. :) I just looked in the doc and didn't see discussion of this. And my investigations began to confuse me. Here's a relatively gentle start focusing on the *operator precedence* of the *junction literal constructor operators*: ``` say 1 & 2 | 3 & 4; # any(all(1, 2), all(3, 4)) say 1 | 2 & 3 | 4; # any(1, all(2, 3), 4) ``` So the `&` junction op has higher operator precedence than `|`. This is covered in the doc, starting at: https://docs.raku.org/language/operators#Junctive_AND_(all)_precedence The compiler rejects mixing of `|` or `&` infix ops with `^` without parens to disambiguate, and there is no `none` infix op, so the above is the only precedence issue to consider for the junction literal creation infix ops. Next comes combining two or more junctions with other ops / functions. The focus now is on "precedence" due to combining junctions with functions (or operators) that aren't themselves junction constructors: So this isn't about *operator* precedence but instead *junction data* precedence. I'll again start with a gentle example, switching to functions (methods) to avoid confusion with *operator* precedence: ``` say(1,2).all le (1, 2).one; # all(one(True, True), one(False, True)) say so (1,2).all le (1, 2).one; # False say(1,2).one le (1, 2).all; # all(one(True, True), one(False, True)) say so (1,2).one le (1, 2).all; # False ``` This indicates that `one` junctions have higher "precedence" than `all`. I'm going to stop at this point because I got confused about the exact "precedence" relationship between the four sorts of junctions and felt this was potentially a good launch point for others. If no one else does look into this I may return to this another day but no promises. -- love, raiph
Re: In regexes with :P5 compatibility turned-on, do embedded modifiers work?
> It's looking to me like perl5's embedded pattern modifiers don't work > when used with raku's :P5 compatibility modifier... The `:P5` modifier only supports a small subset of P5 regexes. I don't think there's any champion who wishes to push it further. (There's been talk of deprecating it though I hope that won't happen.) You can use Perl code in Raku if you `use Inline::Perl5;`. -- love, raiph
Re: File::Find using a junction with exclude
On Sun, May 23, 2021 at 9:15 PM Joseph Brenner wrote: > > Junctions continue to surprise me: That must be either that your mental model doesn't match the default design, or you're being tripped up by DWIMs, or WATs that can't be removed due to the overall DWIM of junctions (which usually work great). > my $junction = any( 'a', 'b', 'c' ); > my $char = 'b'; > say $char ~~ $junction; # True Does that function (`~~`) do the default thing with junctions or is it a special case? As a general point, hopefully you're seeing why we want to *avoid* special casing as far as is reasonable. Each special case needs to really pull far more than its *individual* weight because there's an inevitable *overall* weight as one needs to get a clear mental model of the default situation *and* the special cases. My guess would be that the `ACCEPTS` method for a Junction is special cased to handle the junction as a single thing rather than not doing so. I mean, special case a Junction function to treat itself as a Junction? That makes sense to me! It's the sort of thing I find easy to, er, accept. *This* is OK to me. Especially if it supports functionality that could not be supported without the special case, which applies in this case. > say $char eq $junction; # any(False, True, False) I'd guess that `eq` is just like 99.9% of functions. And so it is: * The `eq` is called three times. * The results are gathered together and a junction of the appropriate kind that combines the results is returned. The special case here is the `say` (or rather the `gist` that `say` calls). > I would've thought that there'd be no difference there Right, because you're not allowing for DWIMs. (Yet, ironically, asking for a DWIM for the `find` case, when the justification for it is on much less firm ground.) > The smartmatch checks that it's comparing string types, > and does something like an eq on them, right? > So why would going straight to an eq be different? Because Larry felt it was a suitable DWIM. worth the WAT you've just experienced. > But then, there are other cases where junction-in, > junction-out is the only thing that makes sense: > > say $junction ~ 'z'; > # any(az, bz, cz) Right. That's `~`, which, like 99.9% of all functions/ops, is not special cased. -- love, raiph
Re: File::Find using a junction with exclude
On Sun, May 23, 2021 at 9:12 PM Joseph Brenner wrote: > > my impression was that junctions, by design aren't supposed to be > treated as compound data structures, they're a *single* thing but > with multiple values that co-exist with each other in "superposition". That's correct. Until they're expanded, they're a single thing. By default, when you call a function (or use an operator, because operators are functions) that isn't special cased to accept an unexpanded junction for a parameter, any argument that's a junction is expanded before calling the function, and the function is applied once per combination of each junction argument's elements. > For example, you can't get a count of the number of elements in a junction: > > my $junction = any( 'a', 'b', 'c' ); > say $junction.elems; # any(1, 1, 1) Right. Like about 99.99% of all functions, `elems` isn't special cased. > But then, this actually works: > > $junction>>.say; > # a > # b > # c Right. Hypers also aren't special cased. So that works as expected (if you expect the very simple rules that drive how it works by default). (It's one hyper call on `a`, one on `b`, one on `c`. The hyper operator does *not* see a junction. It gets call three times, each time with a different invocant.) > So going the other way, using a hyper operator to create a > junction isn't such a silly thing to look at... To *create* one? Sure. But that's unrelated to what's going on in the above. > Though really then this idiom creates an array of multiple any > junctions with single values, which would behave just like the > individual values themselves: > > my $values = < A B C >; > my $junction2 = $values>>.any; > say $junction2; > # (any(A) any(B) any(C)) The `>>` is called three times, once with `A` as its invocant, and so on. The result is a `List` of three `any` junctions, each containing a single element. The variable `$junction2` contains that `List`, not a junction. Now we *do* arrive at the first and only special case among your examples, the `say`, which uses `gist`. The `gist` of a junction is special cased to be a single string providing a human friendly gist of a junction, rather than multiple strings, once for each element of the junction. Thus you get the result you see. This is where some of the *costs* of DWIMs starts to creep in. There are behaviors that don't follow the norm, and thus WATs that need to be explained. Provided the explanations sit well enough with those who experience them for them to get over the shock, all is good, and perhaps even great (one can learn *better* due to a shock than merely things working as expected). The key things are for PL designers and construct/object/function creators to be very judicious about choosing which DWIMS they are willing to be responsible for, valuing WATs as potential teachable moments, and for users to realize that WATs can be a really good thing. -- love, raiph
Re: File::Find using a junction with exclude
On Sun, May 23, 2021 at 3:22 AM Joseph Brenner wrote: > > > That is a large part of the beauty of the junction design. All functions > > (and thus all operators) automatically get a very useful and powerful > > junctional behavior for free. They don't even know junctions exist. > > I can see the point, of course. But then by the same token, > function authors do need to think about junctions if it makes > sense to do it the other way. I'm not sure you've seen the point I hoped you'd see. The point of the design as it is is that: * *Users* of *junctions* should be willing to think about what they're doing when they *call* functions. * *Authors* of *functions* should NOT *need* to think about junctions *unless they WANT to*. And they should think VERY carefully before introducing a DWIM, because for every DWIM there's one or more WATs. > At least in this File::Find exclude case there doesn't > seem to be anything useful about the current behavior. As an overall set of points, Chinese Farmer always applies, all these things are subject to our own perspectives, and our perspectives change over time. What follows is my current perspective. The way it is now is consistent with what something like 99.9% of all functions do. That has a *large* value all of its own. While judicious DWIMs are considered a net positive in Raku culture, injudicious ones are damaging. Here be dragons. And what is the cost of leaving it as it is? There's a teachable moment, one we're going through right now. That has value too. And there are easy ways to express the same thing some other way. And what is the benefit of adding a DWIM? There's no great value. If the sole justification for a DWIM is to whack a WAT, what about new WATs? Consider, for example, the DWIM added to `say` and cousins. One can write `say 42 | 99` and get `any(42,99)`. That's a DWIM. What `say` used to do was write `42` on one line and `99` on the next. This is a WAT and the decision was to make `gist` special case. But at what cost? I currently think it was well worth the cost, but there is a cost. Folk will then expect `say` to work like any other function with junctions, but it's a special case. I think there *is* another aspect that's worth discussing that isn't a DWIM. I'll discuss that in another email. -- love, raiph
Re: File::Find using a junction with exclude
On Fri, May 21, 2021 at 9:39 PM Joseph Brenner wrote:
>
> Thanks, yes the actual result is certainly consistent with the
> junction applied at the top level, and not internally, which is
> what I was expecting.
A junction passed as an argument is immediately expanded unless
a function is specifically coded to handle junctions for that argument.
That is a large part of the beauty of the junction design. All functions
(and thus all operators) automatically get a very useful and powerful
junctional behavior for free. They don't even know junctions exist.
> Is there actually no way to pass a junction in to a function so that
> it can be used later in an internal smartmach?
(This is Raku. The safer bet is to presume there's a way and you
just don't know what it is.)
My guess is that < 0.1% of Raku functions have the additional
code you're suggesting. But it's easy enough. I haven't tested
this but something like should work, doing whatever it is you
think makes sense for the ... bits:
```
sub find (Junction :$exclude, |rest) {
...
... File::find ..., |rest
...
}
```
Explicitly catching the `Junction` type in the signature means the
"autothreading" doesn't happen.
> That's been my rough impression of what junctions are for,
> a way to have a compound value that's treated as a single
> one until it's used.
If Raku did *not* expand junctions by default, then functions
would have to explicitly decide when to "use" them, which
means all of them would have to A) know about junctions,
B) include explicit code to handle them. It would be awful!
--
love, raiph
Re: File::Find using a junction with exclude
Your results are what I would expect.
The hand crafted regex puts the exclusion logic in the *single*
regex that's applied by the *single* call to the `find` function.
The `any` value results in calling the `find` function *twice*,
with 'mothera' excluded one time, and 'camel' excluded the
second time.
Thus the result is an `any` junction, with two lists, one with
two files in it, the other with all three.
Consider a one arg function `function`, a one element junction `junction`,
and the following function call:
function junction
This will execute the function `function` once, using the single element
in the junction `junction`, then return a new junction of the same kind as
`junction` with one element, which will be the result of having called the
function `function` with the single element from the original junction
`junction` as the function `function`'s (only) argument.
Hopefully that makes sense, or hopefully the following example will.
Presume there is a single file in the current directory, `file.txt`. Thus:
say find: dir => '.', type => 'file', exclude => any rx/exe/ #
any("file.txt".IO)
You have provided more than one element for the `any` junction.
So `find` is called multiple times, once for each element of the `any`.
You have provided *two* elements in a junction used for the value
of one argument, namely `any( rx/<|w>mothera$/, rx/<|w>camel$/`.
Therefore `find` is called *twice*, once with each of the `rx`s, and
the result is an `any` containing the results from those two calls.
Hopefully the foregoing has made some sense, though you might
want to get up and go for a walk contemplating what it means for
something to be two things at once.
Assuming the foregoing has made sense, I'll drop in one other
wrinkle to consider. If you pass *multiple* arguments as junctions,
you have to take into account two aspects:
* Things multiply. If *two* function arguments are junctions, and
each junction has, say, three elements, the function is set to be
called *six* times.
* The combination has to follow precedence rules. I forget what
they are, but the general scheme is that there are two levels
and they do what's most natural. This will of course sound very
odd so I'll leave it as a thing to explore if you explore this. :)
--
love, raiph
On Fri, May 21, 2021 at 12:53 AM Joseph Brenner wrote:
>
> The documentation for File::Find says that the exclude argument
> is applied via a smart-match, so I thought that I could use a
> junction, like so:
>
>use File::Find
>my @files = find( dir => $loc, type => 'file', exclude => any(
> @exclude_pats ) );
>
> But instead of getting an array of file names (either strings or
> IO objects would be fine), that returns an any junction of IO
> objects, built-up from a peculiar set of hits.
>
> Does that make sense to anyone?
>
> Here's some code that demos the problem:
>
> use v6;
> use File::Find;
>
> ## create some files to find
> my $loc = "/tmp/monster_island";
> mkdir( $loc );
> chdir( $loc );
> my @monsters = < godzilla mothera rhodan >;
> for @monsters -> $name {
> $name.IO.spurt("The $name attacks!");
> }
>
> ## without exclude, we find all 3 files
> my @files_all = find( dir => $loc, type => 'file' );
> say @files_all.elems; # 3
>
> ## with a handcrafted regex we find only 2, skipping mothera as expected
> my @files_trimmed = find( dir => $loc, type => 'file', exclude =>
> rx/<|w>[mothera|camel]$/ );
> say @files_trimmed.elems; # 2
>
> ## Trying to do the same with an any junction doesn't work:
> my @exclude = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
> my @files = find( dir => $loc, type => 'file', exclude => any(@exclude) );
> say @files;
> # [any(("/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/rhodan".IO),
> ("/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/mothera".IO
> "/home/doom/tmp/monster_island/rhodan".IO))]
> ##
> ## (1) we end up with a single "any" junction in the first element
> ## (2) there are five hits, two redundant rhodan and godzillas, plus
> one mothera slips through (?)
>
> ## but note that this works:
> for @monsters {
> .say unless $_ ~~ any(@exclude)
> }
> # godzilla
> # rhodan
>
>
>
> raku --version
> Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2020.10.
> Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
Re: Comparing Int and Num
On Fri, Apr 16, 2021 at 7:22 AM sisyphus wrote: >> > The conversion from int to num looks sane. Sounds good. :) So presumably our early tentative conclusion of what we hope will pan out is that if one wants precise IEEE float behaviour, one uses `num` instead of `Num`. Right? > However, the second of those integers should assign to the double > 9.223372036854775e+18 (0x1.fp+62) - yet this happens only > for the 'num' case So that's happening in the `Num` type's storage, not its stringification, right? > I don't think it's a big deal if that is deemed to be NOT buggy. OK. `Num` is considered an approximate float, `num` the exact one. > We would just have to be mindful of avoiding Nums when we're > not prepared to accept that the usual "round to nearest, ties to > even" rule might not be enforced. Is that about storage or stringification? Have you seen this active PR by Nicholas Clark?: https://github.com/MoarVM/MoarVM/pull/1472 Do you understand it? One important thing is that Rakudo is quite unlike the `perl` approach as an implementation in the sense that: * Most of the code is Raku, so very high level, and relatively understandable if one knows any of the language. * Another big chunk is nqp, which is essentially just a subset of Raku. So that's approachable too. * The main VM to focus on is MoarVM. An outsider reviewer wrote in 2017 that it they considered it clean code that is well organized, written, documented, and tested. So, I don't know C, and I don't consider NQP especially easy to get into, so it's all a bit intimidating, but I have dipped into the various parts of the compiler, and have never felt "I have zero chance of ever understanding this even if I put in significant effort". So at some point, perhaps during our exchange here, I think it makes sense for me to anticipate me and/or you digging into the compiler's source code, whether it's Raku, nqp, or C (MoarVM is C89), and perhaps you'll find you will understand whatever code I find, or even dig in yourself. > Mind you, it's hard to work out just what rounding rule *is* being > enforced - it's definitely not one that I've ever encountered before. I think a useful objective, to be reached before filing a new issue, is to find out what intent is embodied in the relevant code. It may be that it's appropriate to verify that the intent has been achieved, or there are bugs relative to it, or that the intent needs to change. But it would be appropriate to know that before filing an issue. It might be that what's needed is a *doc* issue, or it might be that it's a MoarVM, or nqp, or Raku, or Rakudo issue. > Though there seems to be a pattern emerging: > 9223372036854775295 - 9223372036854775231 == 64 > and from my initial post in this thread: > (18446744073709551615 - 1024) - (18446744073709551615 - 1088) == 64. > > I suspect some little optimization trick might be doing something unexpected. Perhaps. Hopefully we agree it would be good to know what's going on. And if it can be stated more usefully than "hey, it's approximate, deal", it would be great to distill a pithy explanation and add it to the doc at the very least. Or if it's just a weak implementation, it would be good to at least file an appropriate issue. Maybe also agree to some tests that can be added to roast to ensure it doesn't get worse in the face of any future changes such as optimizations, if indeed that's what's going on. >> I hope to get time to respond to your earlier posts this weekend. > > No rush, and please, don't stress over any of this. Thus far our exchange has been delightful. No stress. :) I love the Perl community, and respect the perl implementation, and acknowledge that Raku and Rakudo aren't yet remotely in the same league with Perl maturity wise. And Raku is much more ambitious and has a much smaller community. (Double understatement!) But Larry long ago persuaded me that what he was trying to pull off could actually be pulled off, and was worth pulling off for the long term sake of the Perl community and/or devs that have a Perl like mindset, even if they won't realize that until it's *extremely* evident, which may not be the case until around the end of this decade. In the meantime, I folk who care about Perl also caring about Raku is a godsend, especially when they're as friendly as you. :) Have a good weekend! -- raiph
Re: slurpy hash signatures
On Wed, Apr 21, 2021 at 2:17 AM Joseph Brenner wrote:
> Ralph Mellor wrote:
>
> [ list of idioms ]
>
> > Learn to use the right idioms as soon as possible.
>
> Okay. Where's the list of preferred idioms?
The list you presented.
If you had or have chosen %h3 as the "right" idiom from
among the four you listed, we win a Raku pair KISS award. :)
By "right", I don't mean what you prefer to use while you are
learning Raku. Because that may well be due to familiarity.
Raku, like Perl, embodies the wisdom of Timtowtdi, and he
of course loves Perl and thinks Perl's one way to do things.
So he has crafted Raku with Perl folk in mind, to ensure it's
not ridiculously hard to get from Perl to Raku.
That said, Raku features a bicarbonate cleanup, and ime it
works best if you go with that flow, i.e. recognize the right
idioms and learn to use them as soon as possible.
> > sometimes nice is:
> >
> > my %h5 = :1week, :2days, :3hours;
>
> Now there I disagree completely.
What would you write?
my %h6 = :17hours, :13days; # "17 hours and 13 days"
my %h6 = hours => 17, days => 13; # "hours 17 and days 13"
I can read and remember the first line at speed as I sub-vocalize
it -- intuitively sound out the code "under my breath" as it were.
The second slows my reading down and worsens my short term
memory of it.
Perhaps a key thing here is whether English is a code reader's
mother tongue; you write English fluently so presumably it is,
but it is different if you were not exposed to a lot of English
under the age of 6 months old, and perhaps that is so for you?
Note that I specifically used keys that were not `ha`, `ho`, `hum`
because the `:1foo` syntax should only be used with keys where
things "sound" nice, which typically means it's where one would
naturally use an integer followed by a unit of measurement (or
an ordinal).
> That's my least favorite pair input syntax
I'm going to guess that that's because you don't know things like:
say my %h5 = pi.:<~>, 42.:<->; # {3.141592653589793 => -42}
Or do you prefer that?!?
> and I'd rather pretend it doesn't exist
Fortunately it's to do with literals syntax, which means tooling
such as CommaIDE can just rewrite (or just display it) in your
preferred syntax without changing its meaning. (If Comma isn't
already supporting that trick, perhaps you could request it.)
That way folk like me who naturally "sound" out code and find
that the `:1day` form makes it easier to read and maintain in
short term memory can have what we want, and you can
pretend our code doesn't exist. :)
> -- it's of limited use
Yes, but when it *is* of use it seems nice to me.
I get that this isn't for hash input, but I much prefer:
say S:3rd /o/O/ with "The quick brown fox jumped over the lazy dog";
# The quick brown fox jumped Over the lazy dog
over:
say (S /o/O/, rd => 3) with "The quick brown fox jumped over the lazy dog";
And once you learn it for ordinals it falls out naturally for
other integer measurement / unit scenarios.
> and it's really not worth torturing newbies with it.
I agree it's not worth torturing anyone!
It's more like a thing to encounter along the way -- to see
`s:3rd /.../.../` or `:7hours, :13days` and wonder what it is.
(But I must say I hadn't thought of it as torturing a newbie when
used in what I consider its appropriate form. So thanks for that
heads up on just how much you hate it even when used in that
form that seems nice to me. While I recall plenty of folk rightly
complaining about its inappropriate use, I don't recall bumping
into someone as 100% anti as you!)
> > ...use `<...>` subscripts.
>
> Well, the way I look at it is that the pointy braces are just
> another style of quoting, albiet without quote marks--
> much like Perl's qw(...).
Maybe looking at it that way is a problem.
Have you tried thinking of them as just another style of
subscripting, albeit without quote marks, much like Perl's `{...}`?
Larry realized he could usefully give Raku both unquoted
and quoted subscript operators to minimize keystrokes and
visual noise and other problems with Perl's approach. I love it.
> Notably they also simplify doing slices, e.g.
>
>say %h1< ha ho >; # (1 2)
Yes. That's really nice, don't you think?
> > If you keep thinking you need to quote keys it's for some other reason.
>
> Again: creating a hash element has different syntax requirements
> than accessing a hash element. You need to worry about quoting
> in one case, but not the other
*You* need to worry because that worry is in your head.
I never worry because I have a different mental m
Re: gather take eager syntax
You've gotten a pile of great answers. :)
I'll add another to the pile, but omit explanation.
say % = ["foo" => "bar"], "baz" => 42; # {foo bar => baz => 42}
say % = ["foo" => "bar"]; # {foo => bar}
say % = ["foo" => "bar"],; # Odd number ... Only saw: $[:foo("bar")]
--
raiph
Re: slurpy hash signatures
Btw, I had misunderstood ERN when, in 2018, I wrote the email message I linked in the Note section of my previous email. ERN is an intuitive sense that some movement you are initiating is in some way a mistake. For example, quoting keys of a pair. It's often unconscious, and, aiui, ignoring it entrenches use of the mistaken action. Conversely, bringing it to consciousness strengthens the signal and the opportunity to "nip it in the bud" so to speak, sharply improving one's performance in the task at hand. That all said, I stand by the rest of what I wrote in that 2018 post, including the sense that folks' ERNs can be positively guided by careful PL design, especially if individuals' attitudes to WATs is a sense they are gifts (which is easiest to sustain if there really are indeed corresponding valuable gifts). And I also stand by what I wrote in my previous email to which this is a reply; I really do consider this named argument "wart" to be a great example of a gift that can be used to positively tune folks' ERNs. And this is why, in my first email, I tried to emphasize that from @Larry's perspective, the "warts" discussed in the original email were part of good design. Talking of which, I forgot to mention a detail of that good design that contrasts with something Joe said: > when you're accessing the hash value, the key *does* need > to be quoted (unlike in perl), As I noted before, one does not need to quote keys, because Raku has the very nice design detail of using `<...>` subscripts along with many other related uses of `<...>`. What I didn't note was how this avoided a "wart" in Perl that if one writes `foo` as a key of a hash subscript it is autoquoted even if one meant it not to be. I recall this being part of @Larry's rationale for the Raku design being as it is. -- raiph
Re: slurpy hash signatures
On Mon, Apr 19, 2021 at 4:03 PM Andy Bach wrote: > > Very impressive and complete explanation, thanks! Thanks for that feedback, it's very helpful. I enjoy trying to help, but it's hard to ensure I've conveyed a tone of respect for whoever I'm replying to, at the same time as trying to keep things sufficiently succinct and clear for them, and for what I'm thinking is the "greater good". > > I'm inclined to view it as pretty good. I also think it > > might be seriously hard to improve. > could this one append of those (my favorite kind) leading questions > "Did you mean to pass ...?" Maybe. But when I thought about that option my intuition was that it would likely end up making the error message weird and noisy for the common case (99.9% of the time?) where the mismatch in args had nothing to do with quoting. And that would imo be a significant negative. Furthermore, the constraints of word count in an error message would inevitably lead to a lost chance to encourage acceptance of the underlying gift, as explained in my Note below. That's why I suggested the as-yet untapped potential of connecting errors to doc pages which can elaborate at length to explain a given message in greater depth, and discuss any gifts that are associated with a given WAT, and maybe link to GH issues discussing it all, etc. Note > As we're looking a known "trap" Imo the first two sentences in the preamble for that page are spot on imo, but the last paragraph is not. To see why I think that, consider what I think is forgotten: * Raku "traps" are mostly beautiful gifts. * It is beautiful that Larry created these beautiful gifts. * It is wise to encourage acceptance of these beautiful gifts. The final paragraph reads as if the writer is not aware of this: > During the making of Raku great pains were taken to get > rid of warts in the syntax. This is one sided thinking, lacking the balance and insight that comes from suitable nuance. cf https://www.reddit.com/r/perl6/comments/8s2vl8/perl_6_colonpairoscopy/e12tf1r/ > When you whack one wart, though, sometimes another pops up. This is an inherently negative take on Larry's neutral waterbed theory. https://en.wikipedia.org/wiki/Waterbed_theory The "whack-a-wart" notion doubles down on the sense that there's been a design failure, and the implication that whack-a-wart is a symptom of this imagined design failure. > So a lot of time was spent finding the minimum number of warts I see this as reflecting good design, and taking care to reach for better. > or trying to put them where they would rarely be seen. Yes and no. In many (most?) cases the opposite is true -- it's often more important to deliberately let them be where they are glaringly obvious and easily encountered as a designed-in teachable moment. You can't make evolved things nice in general without them being warty in particular places. You also have to accept that some gifts will initially be experienced by those who encounter them as warts. And sometimes it's appropriate to choose when to help tune folks' ERN. https://en.wikipedia.org/wiki/Error-related_negativity cf https://www.nntp.perl.org/group/perl.perl6.users/2018/09/msg5418.html > Because of this, Raku's warts are in different places than you may > expect them to be when coming from another language. This is true. :) Who would think that quoting keys would control whether arguments were named or positional? .oO (It's really useful if the compiler can check at *compile-time* if named arguments don't have typo'd keys. And it's really useful that one can write arbitrary strings as keys that do not adhere to the language's rules for named argument names. But if a dev doesn't know Raku, they won't be thinking about those two things. But then again, if they are using Raku, it's arguably a good thing for them to understand about named args sooner rather than later. Also, what to do about interpreting pairs, when used as arguments, as either named arguments or positional arguments? I wonder if a nice DWIM based on whether the key is quoted or not, with a reasonable corresponding WAT, is the way to go?) Aiui, the foregoing thought bubble outlines @Larry's thought process. -- raiph
Re: slurpy hash signatures
On Sun, Apr 18, 2021 at 8:00 PM Joseph Brenner wrote:
>
> Before I get started here, a small point about defining hashes.
> There are various ways that work:
>
>my %h1 = ( 'ha' => 1, 'ho' => 2, 'hum' => 3 );
>my %h2 = ( ha => 1, ho => 2, hum => 3 );
>my %h3 = ha => 1, ho => 2, hum => 3;
>my %h4 = 'ha' => 1, 'ho' => 2, 'hum' => 3;
Idiomatically, %h3 is the clear favorite among those four.
The others are anti-idiomatic.
Raku is forgiving in this case, trying to ease Perl devs into
using Raku, but do not unduly take advantage of Raku's
kindness. Learn to use the right idioms as soon as possible.
Otherwise you'll get outcomes like the perspective you have
on what happens when you pass pairs as arguments.
Btw, another option that's sometimes nice is:
my %h5 = :1week, :2days, :3hours;
(Same as `my %h5 = week => 1, days => 2, hours => 3;`.)
(But generally avoid this idiom when it does not read well,
and note how subs using it will often need to double up
singular and plural versions of named arguments, in this
case week/weeks etc.)
>say join(' ',
> %h1{'ho'}, %h2{'ho'}, %h3{'ho'}, %h4{'ho'}
> );
># Output: 2 2 2 2
Idiomatically, use `<...>` subscripts instead. Again, Raku is
forgiving, but don't take advantage of its kindness. Learn to
use the best idiom.
Maybe even `say join ' ', do . for %h1, %h2, %h3, %h4;`
> Of course, when you're accessing the hash value,
> the key *does* need to be quoted (unlike in perl),
Not at all. As you note yourself, just use `<...>` subscripts.
> And because of this, I keep thinking I need to quote keys
It's not because the key needs to be quoted when you're
accessing keys. Because they don't. You note the solution
yourself.
If you keep thinking you need to quote keys it's for some
other reason.
> I often quote keys without thinking about it
That may get you into trouble if you pass pairs in an argument
list that you intend will be received as named arguments. They
will be received as positional arguments instead.
> genius( 'ha' => 1, 'ho' => 2, 'hum' => 3 );
> ## Error: Too many positionals passed; expected 0 arguments but got 3
Great example.
Fortunately, the error message makes it clear you've passed
3 positional arguments when it expected none, immediately
pinpointing where the problem lies:
* If you thought you were passing 3 named arguments, you
now know you passed 3 positional ones instead.
* If you thought you were passing 3 positional arguments, you
now know the sub doesn't expect them.
> So: when passing pairs to a sub, quoting the key causes things to barf
No, quoting keys when passing pairs to a sub does *not* cause it to barf:
sub church(*%fried, *@frab) { say %fried, @frab }
church( 'ha' => 1, ho => 2, 'hum' => 3 );
## Output: {ho => 2}[ha => 1 hum => 3]
Works beautifully.
Larry deliberately distinguished pairs passed as arguments based
on whether their keys were or weren't quoted. If they're unquoted,
they're named arguments. If they're quoted, they're positional.
He did a similar thing for putting pairs in parens:
sub church(*@frab) { say @frab }
church( 'ha' => 1, (ho => 2, hum => 3) );
## Output: [ha => 1 ho => 2 hum => 3]
> and the messaging is seriously LTA.
Well, it's surprising to you, because you aren't familiar with
named vs positional arguments. If you were, the message
would instantly clue you into the fact your pairs have been
received as positional arguments instead of as named ones.
I'm not convinced the error message is seriously LTA. I'm
inclined to view it as pretty good. I also think it might be
seriously hard to improve. Perhaps a champion (you?)
might step up to the plate to explore how the message
might be improved, but I think it might be really hard to
improve that message alone in a meaningful way.
I can think of one way that would work and have a much
better payoff. It would still require a champion, but there's
a much greater chance of finding and motivating them.
The short version of it is the idea that error messages can
link to doc pages. So if this error message occurs, there's
a link to a doc page matching the error. That page can then
discuss things at length, covering all the various reasons
why the too many positionals or too many nameds messages
might appear, and all the ways to fix things.
> (The pair operator is being demoted to a fat comma?)
The pair syntax is allowing you to express whether you
want to pass a pair as a positional or a named argument.
Both are useful, so it's useful to be able to express both.
Which do you want?
--
raiph
Re: Comparing Int and Num
On Wed, Apr 14, 2021 at 3:10 AM sisyphus wrote: > > Is this a bug that I ought to report ? I'm not yet convinced the issues you showed are classifiable as bugs. Part of my reasoning for my conservatism is per the guidance Larry provided in the design docs. In particular, per design doc S02: > num native floating point > Num number (approximate Real, generally via floating point) Your focus is, aiui, floating point numbers, and Raku handling them as exact doubles, not approximate Reals. As such I think we should switch our focus to `num` for a while, not `Num`, and to initializing `num` variables from `int`s, not `Int`s: my int $i = ...; my num $n = $i; Also, maybe search for 'float' and 'num ' in these documents and read what Larry had to say: * https://design.raku.org/S02.html * https://design.raku.org/S03.html Also, maybe check out roast. A search for 'float' suggests these two as the ones that at first glance seem most worth looking at: * https://github.com/Raku/roast/blob/master/S03-operators/basic-types.t * https://github.com/Raku/roast/blob/master/S03-operators/overflow.t I hope to get time to respond to your earlier posts this weekend. -- ralph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
One last final piece I want to add in while we prepare to document what is worth documenting in issues is what I was trying to get at in this comment: https://www.reddit.com/r/perl/comments/93dabg/perl_6_small_stuff_4_why_perl_isnt_cobol_nor/e3etgvf/ Reviewing it I think I got a couple things wrong in it; I'd appreciate any comment you have about what I wrote. I have long planned to write up one or more related issues and think with your prodding I feel I'll likely be able to coherently write them up. https://design.raku.org/S02.html#Numeric_Types is also worth a read. One bit pertinent to my above comment: > Num.Str and Num.gist both produce valid Num literals, so they must > include the e for the exponential. ... >say 2e2;# 200e0 or 2e2 or 200.0e0 or 2.0e2 (Raku currently displays just `200`). -- raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
Another thing I've bumped into in my travels: > From: Zefram > Sent: Thursday, February 18, 2016 4:08 AM > To: perl5-port...@perl.org > Subject: Re: [perl #127182] One digit short to correctly stringify a double >> To have different NVs stringify identically is surprising; to have the >> closest approximation to 0.1 stringify other than "0.1" is also >> surprising; so I think Steele's rule specifically achieves least surprise >> here. > I keep forgetting that perl has a thing about minimising surprises - and > that's probably a good enough reason for perl to abide by Steele's rule. > So I'll now accept that I can live with that :-) > The hex form of 0.1 is 0x1.ap-4, and whenever that double is > printed, I gather Steele's rule will decree that it be printed out as > '0.1' - irrespective of whether that double was derived as 1/10 or > 10001/1e17. > But there's nothing to object about in that, AFAICS. > Anyway, as I've already noted, one can always resort to printf if need be. Remember that? Am I right in thinking that your view remains that you can live with the above? That all sounds good to me, though there can be different dimensions of surprise, and it may be that Raku's take on having different Nums stringify identically is different from Zefram's/Steele's/your formulation. One thing I'm unclear on as yet is whether Raku has the same or a different position than the above in principle, modulo bugs / weakness in the current sprintf implementation. -- raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
On Thu, Apr 8, 2021 at 3:25 AM Ralph Mellor wrote:
>
> On Wed, Apr 7, 2021 at 2:12 PM sisyphus wrote:
>
> > 2) Update Issue 5013 to better reflect the current state of
> > the bugginess of "%.*g" formatting.
>
> Yeah. I'm focusing on 5519 ("sprintf %f bogus rounding").
Some excerpts from 5519 that shine light on 5013:
Patrick Michaud wrote:
> Nums hold only 15-17 digits of precision
...
> I agree that having sprintf("%f") automatically truncate with zeros
> after 15 digits of precision is perhaps not the best approach here.
> I think it should perhaps be available to at least 17 places, and
> possibly even more in examples like 2**70. But that's a language
> specification call that someone outside of Rakudo probably needs
> to make.
(I'm pretty sure you know who PM is. We need to take that last
sentence to heart. As such it sounds like there's a need to open
a problem-solving ticket if we wish to propose sprintf going beyond
17 digits. It seems plausible we would best first try get consensus
on that as the ultimate goal, or rejection of that, before pursuing
trying to get from 15 plus a buggy 16th as it is now, to just 17.)
Zefram wrote:
> the implementation is first converting to decimal with its default of
> 15 total digits ... and then rounding *that* to the output length ...
> This is double rounding, a classic type of mistake in numerical
> computation.
My guess is that explains the buggy 16th digit which you were
presumably planning to add to 5013.
Zefram also wrote a Raku sprintf implementation of fp conversions
and added it to 5519, saying:
> I believe it to be correct. In addition to the decimal %e, %f, and %g, I
> did the rather useful hexadecimal %a, thus far entirely missing from
> Rakudo's sprintf.
Here it is in an online evaluator:
https://replit.com/@RalphMellor/sprintf#main.raku
Does it work as you expect for all tests you are currently working with?
Also, if there's a decision to switch out to a new implementation
for the fp format tokens (`%`s), then this should be added to the
issue: https://github.com/rakudo/rakudo/issues/2187
--
raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
On Thu, Apr 8, 2021 at 3:25 AM Ralph Mellor wrote: > > On Wed, Apr 7, 2021 at 2:12 PM sisyphus wrote: > > > I also stick to my view that the latter should be the default > > behaviour, as is the case with python3 > ... > I can't imagine making an exception for converting nums into > their exact rational equivalents, with all the negative impact > that a special case brings, including that code like this: > > 0.1 == 1e0 > > which currently returns `True`, would instead return `False`. That should of course have been: 0.1 == 1e-1 > > 1) Open a new issue about the fact that The Num to > > Rat/FatRat conversion cannot be made; > > Well it can. It's just that it's an intelligent coercion, one that > takes into account the nature of a num as an approximate > format, not an exact one, and thus picks a nearest neatly > rounded rational. So this returns `True`: > > 0.1 == 1e0.Rat; # True That should of course have been: say 0.1 == 1e-1.Rat; # True -- raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
On Wed, Apr 7, 2021 at 2:12 PM sisyphus wrote:
>
> I think the important flaw is raku's incapacity to convert a Num
> to its exact Rat/FatRat expression.
My 2c is that I agree that that needs to be addressed.
I currently see that as something to first address via sprintf.
Do you agree? I get the impression you might.
Once that's done, I think it's plausible nothing else need be done
regarding this aspect in terms of built ins in standard Raku.
I get the impression you will *not* agree with that at first,
but I'm hopeful that if so, you'll come around to my way
of thinking after a bit of back and forth. :)
> I think the option to compare Num and Rat/FatRat as
> 2 Rats/FatRats is an option that ought to be available.
If sprintf worked as I presume it ought, that would be doable.
> I also stick to my view that the latter should be the default
> behaviour, as is the case with python3
That's so not Raku.
Last night I mentioned infectiousness and then thought I'd
misread the doc. Tonight I've realized I was right in the first
place, and my original explanation was sound.
Raku's infection system is why you see the behaviour you see.
When you mix integers and rationals, the result is rationals.
When you mix exact and inexact values, the result is inexact.
And so on.
It's a nice system. It's broadly useful, simple to explain, simple
to use, and intuitive.
It's also well established and broadly used.
I can't imagine making an exception for converting nums into
their exact rational equivalents, with all the negative impact
that a special case brings, including that code like this:
0.1 == 1e0
which currently returns `True`, would instead return `False`.
Aiui you are saying we should upend all that nice behaviour
so a value that is by definition approximate, when converted
to a rational, is not set to the nearest rational rounded number
but instead one that will frequently be a hair off that, and thus
a long crazy value. If I'm right that you mean that, well...
> but that's not really an issue.
...I'm glad to hear that! :)
> [sprintf issues]
There are several issues. But I need to go to sleep.
> 1) Open a new issue about the fact that The Num to
> Rat/FatRat conversion cannot be made;
Well it can. It's just that it's an intelligent coercion, one that
takes into account the nature of a num as an approximate
format, not an exact one, and thus picks a nearest neatly
rounded rational. So this returns `True`:
0.1 == 1e0.Rat; # True
I currently think the sensible path for the sake of the sanity
and health of us Rakoons collectively is to first focus on
fixing problems with sprintf so one can generate the precise
rational corresponding to a num via sprintf.
> 2) Update Issue 5013 to better reflect the current state of
> the bugginess of "%.*g" formatting.
Yeah. I'm focusing on 5519 ("sprintf %f bogus rounding").
(Have you looked thru the other issues?)
> Is there any reason that I should not do either/both of those ?
> (I keep wondering if I've missed something.)
It might be best to get rough consensus here on what the issues
really seem to be. No doubt there will be further discussion in the
filed issues themselves, but we can perhaps reduce noise and
confusion there by working thru it here for a few days / week or so.
--
raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
On Wed, Apr 7, 2021 at 3:29 PM Simon Proctor wrote: > > Would =~= be what you're looking for? To quote Wikipedia, "A floating-point number is a rational number". Rob wants to compare a float with its exact equivalent rational and get True if they're exactly the same and False otherwise. -- raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
> 1/10 == 1e1 # True > > Aiui this is correct (and to me intuitive) behaviour described here: Except A) that's not what the doc says, and B) how does one compare numbers *without* infection, if that's what's going on? So it probably makes sense to ignore at least that part of my previous email. Maybe the rest of it too. I shouldn't be writing emails after midnight. Goodnight. -- raiph
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
On Tue, Apr 6, 2021 at 11:54 AM sisyphus wrote: > 1/10 == 1e1 # True Aiui this is correct (and to me intuitive) behaviour described here: https://docs.raku.org/language/numerics#Numeric_infectiousness So if there's a `Num` (float) in a numeric operation (like `==`) then any other number that would behave differently if it were coerced to be a `Num` is coerced to be a `Num` before the operation applies. So the `e0`, which coerces to a Num, coerces the rational `1.0` to be a `Num`, and that in turn means the `0.1` (which is, as I would expect, the exact same as `1/10`) is coerced to a `Num`, and so they compare equal. printf "%.60g\n", 1.0e-1; Aiui the sprintf in Raku code sucks. I just did quick search of the three issue queues for "sprintf". I found several open issues that look closely related (maybe dupes). I'll start with one that not only looked to like a bullseye for your issue but includes what seems to amount to huge and fantastic patches by Zefram that I suspect have never landed: https://github.com/Raku/old-issue-tracker/issues/5519 Other issues that might be relevant: https://github.com/Raku/old-issue-tracker/issues/5013 https://rt-archive.perl.org/perl6/Ticket/Display.html?id=127184 https://github.com/rakudo/rakudo/issues/2187 Perhaps folk who need this to work are using NativeCall and native numerics with the C library sprintf? -- raiph
Re: Objects, TWEAK and return
On Mon, Mar 22, 2021 at 2:12 PM yary wrote: > > It's not good practice to use "map" for side effects only, discarding > the returned value–which happens here I agree. > Would [using `for`] also work-around the lack of sink context in TWEAK? Yes. > I think it is a cause of the unexpected behavior. Perhaps. That said, in response to the issue I filed in which I wrote: > BUILD and TWEAK are not called in sink context by the existing standard > object construction machinery shipping with standard Raku 6.d. Perhaps it > would be best if they were? jnthn has commented: > Yes, with a potential optimization of seeing if the BUILD or TWEAK already > declared its return type as Nil (which is a common practice) so we don't > increase code size of the generated BUILDALL without a need. -- love raiph
Re: Working with a regex using positional captures stored in a variable
On Mon, Mar 22, 2021 at 2:50 PM yary wrote: > > how to get all nested captures worked for me ... not sure I agree with the > design I think the current flattening aspect is awkward in a couple ways: * Having to specify ``. I half like Brad's suggestion. * Having to write `.pairs` to extract the captures. Are your reservations about the design related to the above awkwardnesses? I can see scope for improvement on the above in years to come. Some other commentary: For regexing, it makes sense to return single match objects or flat lists. Devs can then manually add structure to those results if they wish. For parsing, it makes sense to go the other way around, returning nested structures that devs can manually flatten if they wish (as I did). For data structures in general, for some tasks, it makes sense to flatten by default and let devs add structure if they wish, and for other tasks it makes sense to maintain structure by default and let devs flatten if they wish. A PL does have to pick one or the other, either on a general basis, or on a feature-by-feature basis. Perl generally focused on the flat-by-default approach, with regexes fitting in that scheme, and has stayed true to its roots, albeit with some evolution toward improvements for structured data in recent years as devs have contributed additions to the language. Raku generally focused on the structured-data-by-default approach. It also unified regexes and parsing. The natural outcome was a bias toward structure (parse trees). I anticipate there will be improvements for flattening structured data as time passes. -- love raiph
Re: Objects, TWEAK and return
On Sun, Mar 21, 2021 at 9:47 PM wrote:
>
> Waw! :) Following your examples and suggestions, these work:
>
> > class { submethod TWEAK(-->Nil) { Any.map: {say 99} } }.new;
> > class { submethod TWEAK { sink Any.map: {say 99} } }.new;
> > class { submethod TWEAK { eager Any.map: {say 99} } }.new;
>
> I really appreciate your discussion. Let me know if you think it
> is worth to include this issue in the TWEAK Raku documentation.
I think the first step is to see if it's considered a Raku(do) bug.
I've filed an issue: https://github.com/rakudo/rakudo/issues/4260
--
love, raiph
Re: Working with a regex using positional captures stored in a variable
On Wed, Mar 17, 2021 at 7:17 PM William Michels via perl6-users
wrote:
>
> ("If the first character inside is anything other than an alpha it doesn't
> capture").
> It should be added to the Raku Docs ASAP.
Fyi, here's how Larry Wall expressed it 15-18 years ago:
> A leading alphabetic character means it's capturing
(from https://design.raku.org/S05.html#line_1422)
--
love, raiph
Re: Working with a regex using positional captures stored in a variable
On Fri, Mar 19, 2021 at 6:12 PM yary wrote: > > I don't know how to get the result. > DB<1> $word = qr/(\w+)/; > DB<2> $AwithB = qr/$word with $word/ > DB<3> $_ = 'Interpolating regexes with arbitrary captures is fun!' > DB<4> x /$AwithB.*is $word/ A Raku equivalent: my $word = '(\w+)'; my $AwithB = "$word ' with ' $word"; my $regex = "$AwithB .* 'is ' $word"; $_ = 'Interpolating regexes with arbitrary captures is fun!'; .say for m//..pairs; displays: 0 => ｢regexes｣ 1 => ｢arbitrary｣ 2 => ｢fun｣ > Raku example: > > my $word = /(\w+)/; > my $AwithB = /$word' with '$word/; If you interpolate by using `$abc...` or `<$abc...>` instead of ``, Raku will by default not capture. And the non-capturing is nested, so throwing away those captures also throws away the corresponding capture within `$word`. > Where my expectation differs from the behavior in my example > is Raku's discarding the capture groups of the interpolated regexes. It only discards them if you tell it to discard them. If a `<...>` construct begins with a letter, it'll capture. If not, it won't. -- love, raiph
Re: Working with a regex using positional captures stored in a variable
On Thu, Mar 18, 2021 at 12:59 AM yary wrote: > > As it is I get same kinds of errors in the REPL, perhaps it is MacOS > with Linenoise that's mucking that up. I can confirm your new test code also works fine in both program and repl forms in 2020.12. Though obviously the case you mark as "interesting" still doesn't do any sub-capturing. Which is to be expected if you know that aspect of Raku's regex language. > I had hoped that by directly interpolating $rd and $rw they would > fill in the top-level match object and fill in $0, $1 – but it has the > same issue as Joe's original example. Are you just saying that your original expectations were the same as Joe's, but you now understand that's not how Raku regexes work, but it's trivial to get the same result? Or are you saying you don't know how to get the same result? -- love, raiph
Re: Working with a regex using positional captures stored in a variable
> 1. The list you posted is fantastic ("If the first character inside is
> anything other
> than an alpha it doesn't capture"). It should be added to the Raku Docs ASAP.
Not the list, right? Just the rule. (There are dozens of kinds of
assertions. No one
is going to remember the list.) If you were to add just the line you
suggest then
you'd be able to do it ASAP.
> 2. There are some shortcuts that don't seem to follow a set pattern. For
> example
> a named capture can be accessed using $ instead of $/ ;
> the "/' can be elided. Do you have a method you can share for remembering
> these sorts of shortcuts? Or are they disfavored?
I know you're asking Brad, but fwiw my overall method for mnemonics is to stay
creative and bring in visual and audio elements (like images and rhyming) and
weave them into a little made up story that fits in with an overall
adventure story
about Raku. The elements would be ones that work for a given individual for a
given aspect of a given feature of Raku, with the story being made up by the
person doing the learning.
Thus, for example, I might note that the @ symbol looks something like a `0`
and is sounded out as "at" and have a kid tell me a little story they imagine
getting added to the twitter profile of someone they know about programming
that involves the fact that array indexing is `0` based, thus giving
them a strong
reminder of the latter aspect.
Fwiw I'm not seeing much value in developing one for eliding the `/`.
If a dev doesn't
know they can elide the `/` when writing code, then no harm done; just
leave it in.
If a dev is *reading* code and sees syntax of the form `$` and wonders what
it is, they can type `$<` into the search box in the doc and get a
match. I personally
found it really easy to remember because it's so simple and used so
frequently. I
think mnemonics
> 3. Finally, I've never seen in the Perl6/Raku literature the motto you cite:
> "One of the mottos of Raku, is that it is ok to confuse a new programmer,
> it is not ok to confuse an expert."
I think that's a reasonable distillation of Larry's perspective. It's
another way
of expressing that Python is good as a first language, Raku as a last one.
Consider the options:
* Ok to confuse a new programmer or an expert. (Not a good option.)
* Ok to confuse an expert, not Ok to confuse a new programmer. ScratchJr?
* Not Ok to confuse a new programmer or an expert. ScratchJr?
> [ The motto I prefer is from Larry Wall: "...easy things should stay easy,
> hard things should get easier, and impossible things should get hard... ."
I like that one too. I daresay I prefer it too. But for it to work, it
really needs
to be Ok to confuse a new programmer but not Ok to confuse an expert.
Note that easy things being easy does not mean that new programmers
won't get confused. For example, a new Raku programmer who is used
to Perl might be confused that `<$foo>` does not capture in Raku, even
though it does in Perl. But it's still easy to capture; you write ``.
But when *experts* are *systematically* confused, i.e. *all* experts just
keep falling for the same trap, then impossible things won't just be hard,
they'll stop happening.
Note that I say that as a non-expert in many, many areas of Raku. What
I *do* know is that whenever I encounter something that surprises me,
and keep an open mind about what's going on, no matter how annoyed
I am or convinced Raku is being stupid, I almost always eventually arrive
at an interim conclusion it's appropriate as is.
*Almost* always. And always an *interim* conclusion at best. That is to
say, I retain an eternally open mind toward all such things. So if someone
were to add a table to the doc listing all the assertion types, noting which
ones capture and which ones don't, rather than just the one rule ("starts
with an alpha") I'd be open minded about what the outcome would be.
Likewise if Brad reveals some master method he has for coming up with
a mnemonic covering dropping the `/` in `$`. And if it turns out Larry
has never said something directly to the effect that Brad has mentioned,
I'd be surprised but curious why I was surprised.
--
love, raiph
Re: Working with a regex using positional captures stored in a variable
And when I cut/paste from the doc, the number example works too,
in both script and repl.
On Wed, Mar 17, 2021 at 10:33 PM Ralph Mellor wrote:
>
> Er, by wfm I mean it matches ｢Is｣ as the code suggests.
>
> On Wed, Mar 17, 2021 at 10:32 PM Ralph Mellor wrote:
> >
> > Works for me in Rakudo 2020.12.
> >
> > On Wed, Mar 17, 2021 at 9:33 PM yary wrote:
> > >
> > > The "Interpolation" section of the raku docs use strings as the elements
> > > of building up a larger regex from smaller pieces, but the example that
> > > looks fruitful isn't working in my raku. This is taken from
> > > https://docs.raku.org/language/regexes#Regex_interpolation
> > >
> > > > my $string = 'Is this a regex or a string: 123\w+False$pattern1 ?';
> > >
> > > Is this a regex or a string: 123\w+False$pattern1 ?
> > >
> > > > my $regex= /\w+/;
> > >
> > > /\w+/
> > >
> > > > say $string.match: / $regex /;
> > >
> > > Regex object coerced to string (please use .gist or .raku to do that)
> > >
> > > ... and more error lines, and no result when the docs show matching
> > > '123':
> > >
> > > ｢｣
> > >
> > >
> > > $ raku -v
> > >
> > > Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2020.10.
> > >
> > > Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
> > >
> > > Built on MoarVM version 2020.10.
> > >
> > >
> > >
> > > -y
> > >
> > >
> > > On Wed, Mar 17, 2021 at 3:17 PM William Michels via perl6-users
> > > wrote:
> > >>
> > >> Dear Brad,
> > >>
> > >> 1. The list you posted is fantastic ("If the first character inside is
> > >> anything other than an alpha it doesn't capture"). It should be added to
> > >> the Raku Docs ASAP.
> > >>
> > >> 2. There are some shortcuts that don't seem to follow a set pattern. For
> > >> example a named capture can be accessed using $ instead of
> > >> $/ ; the "/' can be elided. Do you have a method you can share
> > >> for remembering these sorts of shortcuts? Or are they disfavored?
> > >>
> > >> > say ~$ if 'abc' ~~ / $ = [ \w+ ] /;
> > >> abc
> > >> >
> > >> [ Above from the example at
> > >> https://docs.raku.org/syntax/Named%20captures ].
> > >>
> > >> 3. Finally, I've never seen in the Perl6/Raku literature the motto you
> > >> cite: "One of the mottos of Raku, is that it is ok to confuse a new
> > >> programmer, it is not ok to confuse an expert." Do you have a citation?
> > >>
> > >> [ The motto I prefer is from Larry Wall: "...easy things should stay
> > >> easy, hard things should get easier, and impossible things should get
> > >> hard... ." Citation: https://www.perl.com/pub/2000/10/23/soto2000.html/
> > >> ].
> > >>
> > >> Best Regards,
> > >>
> > >> Bill.
> > >>
> > >>
> > >>
> > >> On Sat, Mar 13, 2021 at 4:47 PM Brad Gilbert wrote:
> > >>>
> > >>> It makes <…> more consistent precisely because <$pattern> doesn't
> > >>> capture.
> > >>>
> > >>> If the first character inside is anything other than an alpha it
> > >>> doesn't capture.
> > >>> Which is a very simple description of when it captures.
> > >>>
> > >>> doesn't capture because of the ｢?｣
> > >>> doesn't capture because of the ｢!｣
> > >>> <.ws> doesn't capture because of the ｢.｣
> > >>> <&ws> doesn't capture because of the ｢&｣
> > >>> <$pattern> doesn't capture because of the ｢$｣
> > >>> <$0> doesn't capture because of the ｢$｣
> > >>> <@a> doesn't capture because of the ｢@｣
> > >>> <[…]> doesn't capture because of the ｢[｣
> > >>> <-[…]> doesn't capture because of the ｢-]
> > >>> <:Ll> doesn't capture because of the ｢:｣
> > >>>
> > >>> For most of those, you don't actually want it to capture.
> > >>> With ｢.｣ the whole point is that it doesn't
Re: Working with a regex using positional captures stored in a variable
Er, by wfm I mean it matches ｢Is｣ as the code suggests.
On Wed, Mar 17, 2021 at 10:32 PM Ralph Mellor wrote:
>
> Works for me in Rakudo 2020.12.
>
> On Wed, Mar 17, 2021 at 9:33 PM yary wrote:
> >
> > The "Interpolation" section of the raku docs use strings as the elements of
> > building up a larger regex from smaller pieces, but the example that looks
> > fruitful isn't working in my raku. This is taken from
> > https://docs.raku.org/language/regexes#Regex_interpolation
> >
> > > my $string = 'Is this a regex or a string: 123\w+False$pattern1 ?';
> >
> > Is this a regex or a string: 123\w+False$pattern1 ?
> >
> > > my $regex= /\w+/;
> >
> > /\w+/
> >
> > > say $string.match: / $regex /;
> >
> > Regex object coerced to string (please use .gist or .raku to do that)
> >
> > ... and more error lines, and no result when the docs show matching '123':
> >
> > ｢｣
> >
> >
> > $ raku -v
> >
> > Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2020.10.
> >
> > Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
> >
> > Built on MoarVM version 2020.10.
> >
> >
> >
> > -y
> >
> >
> > On Wed, Mar 17, 2021 at 3:17 PM William Michels via perl6-users
> > wrote:
> >>
> >> Dear Brad,
> >>
> >> 1. The list you posted is fantastic ("If the first character inside is
> >> anything other than an alpha it doesn't capture"). It should be added to
> >> the Raku Docs ASAP.
> >>
> >> 2. There are some shortcuts that don't seem to follow a set pattern. For
> >> example a named capture can be accessed using $ instead of
> >> $/ ; the "/' can be elided. Do you have a method you can share for
> >> remembering these sorts of shortcuts? Or are they disfavored?
> >>
> >> > say ~$ if 'abc' ~~ / $ = [ \w+ ] /;
> >> abc
> >> >
> >> [ Above from the example at https://docs.raku.org/syntax/Named%20captures
> >> ].
> >>
> >> 3. Finally, I've never seen in the Perl6/Raku literature the motto you
> >> cite: "One of the mottos of Raku, is that it is ok to confuse a new
> >> programmer, it is not ok to confuse an expert." Do you have a citation?
> >>
> >> [ The motto I prefer is from Larry Wall: "...easy things should stay easy,
> >> hard things should get easier, and impossible things should get hard... ."
> >> Citation: https://www.perl.com/pub/2000/10/23/soto2000.html/ ].
> >>
> >> Best Regards,
> >>
> >> Bill.
> >>
> >>
> >>
> >> On Sat, Mar 13, 2021 at 4:47 PM Brad Gilbert wrote:
> >>>
> >>> It makes <…> more consistent precisely because <$pattern> doesn't capture.
> >>>
> >>> If the first character inside is anything other than an alpha it doesn't
> >>> capture.
> >>> Which is a very simple description of when it captures.
> >>>
> >>> doesn't capture because of the ｢?｣
> >>> doesn't capture because of the ｢!｣
> >>> <.ws> doesn't capture because of the ｢.｣
> >>> <&ws> doesn't capture because of the ｢&｣
> >>> <$pattern> doesn't capture because of the ｢$｣
> >>> <$0> doesn't capture because of the ｢$｣
> >>> <@a> doesn't capture because of the ｢@｣
> >>> <[…]> doesn't capture because of the ｢[｣
> >>> <-[…]> doesn't capture because of the ｢-]
> >>> <:Ll> doesn't capture because of the ｢:｣
> >>>
> >>> For most of those, you don't actually want it to capture.
> >>> With ｢.｣ the whole point is that it doesn't capture.
> >>>
> >>> does capture because it starts with an alpha
> >>> does capture because it starts with an alpha
> >>>
> >>> $0 = <$pattern> doesn't capture to $, but does capture to $0
> >>> $ = <$pattern> captures because of $ =
> >>>
> >>> It would be a mistake to just make <$pattern> capture.
> >>> Consistency is perhaps Raku's most important feature.
> >>>
> >>> One of the mottos of Raku, is that it is ok to confuse a new programmer,
> >>> it is not ok to confuse an expert.
> >
