Re: Is the cosine page wrong?
May I ask if there is any practical perl6 project running? For example, homebrew by ruby, k8s by go, flask by python etc. Thanks.
Re: I need help understanding ".contains" method construction
On 12/23/20 4:39 PM, Ralph Mellor wrote: 1) why is it "$needle" and not "$!needle" on line 338? Is this because it is an internal variable and not a variable from the class declaration? Got it It's a parameter from line 337. If that's what you mean by "an internal variable", then yes. :) Apparently some other programming language do not give your the option of internal variables in side class declarations: everything is visable 2) where is variable ".value" defined on line 338? What kind of variable is .value? I don't see a `.value`, only a `$!value`. But if I did, and had that sort of name, it would typically be a method call that returns an attribute of the same name -- like `$!value`. Is this .self with a better name? 3) the first "Str:D" goes to what on line 337? To .value? No, to the invocant. Would you define "invocant" so I stop guessing? 4) Is .value the default, if there is no name given? I don't see a `.value`, nor what you mean by "name".
Re: Is the cosine page wrong?
Going back to the original question, should not the doc page say? method cos( Cool:D: --> Cool:D ) On 12/23/20 4:28 PM, Ralph Mellor wrote: > If a method does not explicitly specify its invocant type, it is set > to the type of the enclosing class. But it does not specify an invocant. It just leaves it blank > > The `cos` method is declared in the `Cool` class, so that is its > invocant type. > > The doc shows that it's declared in the `Cool` class. > > So, the doc is fine as is for the invocant. I was not asking if you could pick it up by context with other things written on the page. I was specifically asking about the definition line. Once you learn to read them, the definition lines can be really useful. My problem is that they are often incorrect, which put a hammer into learning them. > The returned value is a cosine, which, per the linked doc, > is a real number. The doc could perhaps show a return value > of Real:D. I like it! This look right to me (but keep in mind I don't know what I am doing) method cos( Cool:D: --> Real:D ) These two look wrong to me: method cos() method cos( --> Cool:D ) or --> Real:D Thank you for the wonderful explanation. -T
Re: I need help understanding ".contains" method construction
>1) why is it "$needle" and not "$!needle" on line 338?
>Is this because it is an internal variable and not
>a variable from the class declaration?
It's a parameter from line 337. If that's what you mean by
"an internal variable", then yes. :)
>2) where is variable ".value" defined on line 338?
>What kind of variable is .value?
I don't see a `.value`, only a `$!value`. But if I did, and had that
sort of name, it would typically be a method call that returns an
attribute of the same name -- like `$!value`.
>3) the first "Str:D" goes to what on line 337? To .value?
No, to the invocant.
>4) Is .value the default, if there is no name given?
I don't see a `.value`, nor what you mean by "name".
On Sun, Dec 20, 2020 at 7:05 AM ToddAndMargo via perl6-users
wrote:
>
> Hi All,
>
> https://github.com/rakudo/rakudo/blob/master/src/core.c/Str.pm6
>
> 337:multi method contains(Str:D: Str:D $needle --> Bool:D) {
>
> 338:nqp::hllbool(nqp::isne_i(nqp::index($!value,$needle,0),-1))
> 339:}
>
> I "presume" in
>
> "abcd".contains("bc")
>
> "abcd" is `$!value`, and
>
> "bc" is $needle. Do I presume correctly?
>
>
> Questions:
>
> 1) why is it "$needle" and not "$!needle" on line 338?
> Is this because it is an internal variable and not
> a variable from the class declaration?
>
> 2) where is variable ".value" defined on line 338?
> What kind of variable is .value?
>
> 3) the first "Str:D" goes to what on line 337? To .value?
>
> 4) Is .value the default, if there is no name given?
>
> Many thanks,
> -T
Re: Is the cosine page wrong?
If a method does not explicitly specify its invocant type, it is set
to the type of the enclosing class.
The `cos` method is declared in the `Cool` class, so that is its
invocant type.
The doc shows that it's declared in the `Cool` class.
So, the doc is fine as is for the invocant.
The returned value is a cosine, which, per the linked doc,
is a real number. The doc could perhaps show a return value
of Real:D.
On Mon, Dec 21, 2020 at 12:05 AM ToddAndMargo via perl6-users
wrote:
>
> On 12/20/20 1:18 PM, Bruce Gray wrote:
> >
> >
> >> On Dec 20, 2020, at 2:54 AM, ToddAndMargo via perl6-users
> >> wrote:
> >
> > —snip--
> >
> >> I obviously can't feed it a string.
> >
> > Obviously you cannot, but actually you can!
> >
> > $ raku -e 'say .cos for 42, "42", ("4" ~ "2"), "5421".substr(1,2);'
> > -0.3999853149883513
> > -0.3999853149883513
> > -0.3999853149883513
> > -0.3999853149883513
> >
> > The subroutine form in https://docs.raku.org/routine/cos is declared as:
> > sub cos(Numeric(Cool))
> > and the text specifies:
> > Coerces the invocant (or in sub form, the argument) to Numeric,
> > interprets it as radians, returns its cosine.
> > , so the string “42” is coerced to the number 42 as it is passed to cos().
> > This kind of coercion is not often needed in user code, but the code of the
> > Raku core needs to coerce to maintain a key element of Perl design:
> > * If the coder treats something as a number, then the language acts
> > on it as if it is a number, even if it has to convert a string to a number
> > behind the scenes at runtime.
> > * If the coder treats something as a string, then the language acts
> > on it as if it is a string, even if it has to convert a number to a string
> > behind the scenes at runtime.
> > (BTW, both Perl and Raku use an amazingly efficient auto-caching of this
> > string-vs-number duality; many newcomers think the conversion must be a
> > performance hog, but it is not.)
> >
> > For details on the syntax of automatic coercion during a subroutine call,
> > see:
> > https://docs.raku.org/type/Signature#Coercion_type
> > (Most users never need in their own code, but you saw it by reading the
> > Raku core, so please take that as just for your curiosity and not as a new
> > technique looking for a place in your own designs.)
> >
> >> On Dec 20, 2020, at 2:17 AM, ToddAndMargo via perl6-users
> >> wrote:
> >> https://docs.raku.org/routine/cos
> >> method cos()
> >> Where is the definition of what is fed to the method?
> > —snip—
> > The definition is hiding right in front of us :^)
> > Just like (in another thread) you defined `method BadAdd () {…}`, the `cos`
> > method has open+close parens to show that it has empty Signature. It takes
> > no arguments, and will complain if you try to pass an argument to it.
> > All methods automatically have access to the invoking object, via “self”
> > (and other shortcuts like $.attribute_name).
> > When you call `42.cos`, `42` is the invoking object, and that one value is
> > all that .cos needs.
> >
> >
> >> On Dec 20, 2020, at 2:25 AM, ToddAndMargo via perl6-users
> >> wrote:
> >
> > —snip--
> >
> >> https://github.com/rakudo/rakudo/blob/master/src/core.c/Cool.pm6
> >>
> >> 13: method cos() { self.Numeric.cos }
> >>
> >> Whatever the heck "self” is
> >
> > “self” is the “current” object instance (called the “invocant”).
> > https://docs.raku.org/language/terms#term_self
> > When you define a method in a Class, you are writing sort of abstractly,
> > because at any given time you might have many objects (called “instances”)
> > of that Class, all alive and working in your program at the same time.
> > In most languages that support OO, there is a magic keyword like “this” or
> > “self” that refers to *only* that single instance that called the method.
> > In Raku, “self” is that keyword, but you can override it to a variable name
> > of your choice , if that makes more sense in your code.
> > my Str $a = ’15';
> > my Str $b = '37';
> > say $b.cos;
> > Inside method `cos`, during the .cos call in the code above, “self” is an
> > alias to $b .
> >
> >
> > —
> > Hope this helps,
> > Bruce Gray (Util of PerlMonks)
> >
>
>
> Going back to the original question,
>
> should not the doc page say?
>
> method cos( Cool:D: --> Cool:D )
Re: Continuous testing
You can probably use AppVeyor. It's got good support for Windows, although you'll have to write for it specifically. This one seems to use it, for instance https://github.com/MARTIMM/gnome-native El mié, 23 dic 2020 a las 16:35, Richard Hainsworth () escribió: > Hi to everyone. > > Hope you all have a happy holiday time at the end of the year - > different countries different celebrations, but good will to all. > > Hope 2021 is properous for you all too. > > About continuous testing. I have recently taken on the maintenance of > GTK::Simple. > > The Travis-CI setup was constructed a while ago and tested both OSX and > Linux, but not Windows. > > It was failing for OSX and for one of the Linux environments. > > So I have changed it to the minimal docker image provided by JJ - kudos > that man!!! > > However, that required a removal of OSX - bad. > > In addition, GTK::Simple is difficult to install on Windows, so I'll > need help there, but I would like to know how test a module for Windows > anyway. > > For clarity, I last used a Mac in the naughties, and stopped using > Windows as soon as I could get what I needed from Linux. So basically, I > have minimal recent knowledge of these environments. > > I have two questions: > > a) Could any one provide me with a CI scheme that would cover Linux / > OSX / Windows? > > Not necessarily on the same server environment. > > There is an issue in GTK::Simple to the effect that it would be better > to use github Actions instead of Travis-CI et al. A comment on this > theme would help. > > b) Is there a reasonable link to a blog/tutorial on CI ? > > I think that there should be some basic information on CI in the Raku > documentation on Modules. If anyone answers q1 for me, then I'll write > up the scheme I adopt for the Modules documentation together with a link > to better information. > > When I have asked this question before, I haven't had much response. > Either I have had answers that assume everyone know about CI, or most > often I get a response that the answerer just copies/pastes > configurations from other modules. > > Whilst CI is not a part of Raku, a basic CI scheme that could be adopted > by all Module writers would enhance the robustness of the Raku module > community. > > -- JJ
Continuous testing
Hi to everyone. Hope you all have a happy holiday time at the end of the year - different countries different celebrations, but good will to all. Hope 2021 is properous for you all too. About continuous testing. I have recently taken on the maintenance of GTK::Simple. The Travis-CI setup was constructed a while ago and tested both OSX and Linux, but not Windows. It was failing for OSX and for one of the Linux environments. So I have changed it to the minimal docker image provided by JJ - kudos that man!!! However, that required a removal of OSX - bad. In addition, GTK::Simple is difficult to install on Windows, so I'll need help there, but I would like to know how test a module for Windows anyway. For clarity, I last used a Mac in the naughties, and stopped using Windows as soon as I could get what I needed from Linux. So basically, I have minimal recent knowledge of these environments. I have two questions: a) Could any one provide me with a CI scheme that would cover Linux / OSX / Windows? Not necessarily on the same server environment. There is an issue in GTK::Simple to the effect that it would be better to use github Actions instead of Travis-CI et al. A comment on this theme would help. b) Is there a reasonable link to a blog/tutorial on CI ? I think that there should be some basic information on CI in the Raku documentation on Modules. If anyone answers q1 for me, then I'll write up the scheme I adopt for the Modules documentation together with a link to better information. When I have asked this question before, I haven't had much response. Either I have had answers that assume everyone know about CI, or most often I get a response that the answerer just copies/pastes configurations from other modules. Whilst CI is not a part of Raku, a basic CI scheme that could be adopted by all Module writers would enhance the robustness of the Raku module community.
