Re: junctions and parenthesis
You're quite correct Brad, so maybe I mis-stated my observation: > any( eq any()) any(any(False, False)) > eq any() any(False, False) > Would the first line of code above code (wrapping an 'eq' call inside an any-junction, along with another any-junction) be written by a Raku programmer? If so, what would his/her objective be? Doesn't the second line of code suffice? In Joseph's/Patrick's code, the external 'any' seems to only resolve to a taking a single (internal, nested) any-junction argument, while in your example, the external 'any' takes three internal, nested any-junction arguments. Best, Bill. On Wed, Jun 24, 2020 at 5:57 PM Brad Gilbert wrote: > > It does actually make sense to call any on any > > say (1, 2, 3).any + (4, 5, 6).any > # any(any(5, 6, 7), any(6, 7, 8), any(7, 8, 9)) > > On Wed, Jun 24, 2020 at 6:22 PM William Michels via perl6-users > wrote: >> >> I evaluated Joe's code using Patrick's explanation of parentheses-less >> parsing (in the REPL): >> >> > say(so(any( eq any(; >> False >> > say any( eq any()); >> any(any(False, False)) >> > >> >> Q1. Does it make any sense to call "any" on "any" (i.e. nested "any" >> calls)? Could this anti-pattern be used to generate a warning, i.e. >> 'Useless use of nested any-junctions, did you mean...' or something >> similar? >> >> > say any( eq any()); >> any(any(False, False)) >> > say any( eq any()); >> any(any(False, False, False)) >> > >> >> Q2. Swapping the first argument to the binary infix operator >> 'eq' with the second argument results in two different code >> evaluations (above). Can this be used to alert the user to a potential >> violation of the commutative property of equality? Again, maybe useful >> for generating a warning (at least in the REPL), " Warning: >> Commutativity--code without parentheses evaluates differently based on >> LHS vs RHS ordering of arguments to "eq" operator... ." >> >> (note, the second suggestion won't help if each argument to the "any" >> calls surrounding 'eq' are an equivalent number of elements). >> >> HTH, Bill. >> >> >> >> On Sun, Jun 21, 2020 at 8:12 PM Patrick R. Michaud >> wrote: >> > >> > The "any" function is just like any other function taking an arbitrary >> > list of arguments (including user-defined functions). As such it parses >> > with lower precedence than comparison operators -- so "eq" binds more >> > tightly than "any". >> > >> > Thus >> > >> >say so any eq any ; >> > >> > parses like >> > >> >say(so(any( eq any(; >> > >> > which is indeed False. >> > >> > I'm not exactly sure what sort of warning should go here, or how it'd be >> > detected. But perhaps others have ideas. >> > >> > Pm >> > >> > >> > On Sun, Jun 21, 2020 at 07:00:23PM -0700, Joseph Brenner wrote: >> > > I was just playing around with junctions a bit today, and I >> > > noticed that if you weren't religious about using parenthesis >> > > with them you could get quietly tripped up: >> > > >> > > say so any() eq any(); # True (as expected) >> > > say so any() eq any(); # False (as expected) >> > > say so any eq any ; # False(something's wrong) >> > > >> > > Basically, you need the parens on that first use of any. >> > > >> > > Is there a reason you don't at least get a warning if you don't?
Re: junctions and parenthesis
It does actually make sense to call any on any say (1, 2, 3).any + (4, 5, 6).any # any(any(5, 6, 7), any(6, 7, 8), any(7, 8, 9)) On Wed, Jun 24, 2020 at 6:22 PM William Michels via perl6-users < perl6-us...@perl.org> wrote: > I evaluated Joe's code using Patrick's explanation of parentheses-less > parsing (in the REPL): > > > say(so(any( eq any(; > False > > say any( eq any()); > any(any(False, False)) > > > > Q1. Does it make any sense to call "any" on "any" (i.e. nested "any" > calls)? Could this anti-pattern be used to generate a warning, i.e. > 'Useless use of nested any-junctions, did you mean...' or something > similar? > > > say any( eq any()); > any(any(False, False)) > > say any( eq any()); > any(any(False, False, False)) > > > > Q2. Swapping the first argument to the binary infix operator > 'eq' with the second argument results in two different code > evaluations (above). Can this be used to alert the user to a potential > violation of the commutative property of equality? Again, maybe useful > for generating a warning (at least in the REPL), " Warning: > Commutativity--code without parentheses evaluates differently based on > LHS vs RHS ordering of arguments to "eq" operator... ." > > (note, the second suggestion won't help if each argument to the "any" > calls surrounding 'eq' are an equivalent number of elements). > > HTH, Bill. > > > > On Sun, Jun 21, 2020 at 8:12 PM Patrick R. Michaud > wrote: > > > > The "any" function is just like any other function taking an arbitrary > list of arguments (including user-defined functions). As such it parses > with lower precedence than comparison operators -- so "eq" binds more > tightly than "any". > > > > Thus > > > >say so any eq any ; > > > > parses like > > > >say(so(any( eq any(; > > > > which is indeed False. > > > > I'm not exactly sure what sort of warning should go here, or how it'd be > detected. But perhaps others have ideas. > > > > Pm > > > > > > On Sun, Jun 21, 2020 at 07:00:23PM -0700, Joseph Brenner wrote: > > > I was just playing around with junctions a bit today, and I > > > noticed that if you weren't religious about using parenthesis > > > with them you could get quietly tripped up: > > > > > > say so any() eq any(); # True (as expected) > > > say so any() eq any(); # False (as expected) > > > say so any eq any ; # False(something's wrong) > > > > > > Basically, you need the parens on that first use of any. > > > > > > Is there a reason you don't at least get a warning if you don't? >
Re: junctions and parenthesis
I evaluated Joe's code using Patrick's explanation of parentheses-less parsing (in the REPL): > say(so(any( eq any(; False > say any( eq any()); any(any(False, False)) > Q1. Does it make any sense to call "any" on "any" (i.e. nested "any" calls)? Could this anti-pattern be used to generate a warning, i.e. 'Useless use of nested any-junctions, did you mean...' or something similar? > say any( eq any()); any(any(False, False)) > say any( eq any()); any(any(False, False, False)) > Q2. Swapping the first argument to the binary infix operator 'eq' with the second argument results in two different code evaluations (above). Can this be used to alert the user to a potential violation of the commutative property of equality? Again, maybe useful for generating a warning (at least in the REPL), " Warning: Commutativity--code without parentheses evaluates differently based on LHS vs RHS ordering of arguments to "eq" operator... ." (note, the second suggestion won't help if each argument to the "any" calls surrounding 'eq' are an equivalent number of elements). HTH, Bill. On Sun, Jun 21, 2020 at 8:12 PM Patrick R. Michaud wrote: > > The "any" function is just like any other function taking an arbitrary list > of arguments (including user-defined functions). As such it parses with > lower precedence than comparison operators -- so "eq" binds more tightly than > "any". > > Thus > >say so any eq any ; > > parses like > >say(so(any( eq any(; > > which is indeed False. > > I'm not exactly sure what sort of warning should go here, or how it'd be > detected. But perhaps others have ideas. > > Pm > > > On Sun, Jun 21, 2020 at 07:00:23PM -0700, Joseph Brenner wrote: > > I was just playing around with junctions a bit today, and I > > noticed that if you weren't religious about using parenthesis > > with them you could get quietly tripped up: > > > > say so any() eq any(); # True (as expected) > > say so any() eq any(); # False (as expected) > > say so any eq any ; # False(something's wrong) > > > > Basically, you need the parens on that first use of any. > > > > Is there a reason you don't at least get a warning if you don't?
Re: Access violation when creating class instance
The download page requires an update. You can get 2020.05.1 here:
https://rakudo.org/downloads/star/
On Wed, Jun 24, 2020 at 6:11 AM WFB wrote:
>
> Thanks JJ,
>
> I am using Rakudostar on Windows and 2020.01 is the current released version
> so far.
> I will try to reduce the code a bit more but it is just one class definition
> together with an instantiation. Not sure I can pack that in a one liner, but
> will try.
>
> The access violation comes probably from C code handling some Windows stuff.
>
> On Wed, 24 Jun 2020 at 10:13, JJ Merelo wrote:
>>
>>
>>
>> El mié., 24 jun. 2020 a las 10:05, WFB ()
>> escribió:
>>>
>>> Hi all,
>>>
>>> I have an access violation on Windows for one of my classes and think it is
>>> a bug, but not entirely sure about that.
>>>
>>> Every now and then creating a class instance ended my script with error:
>>> Process finished with exit code -1073741819 (0xC005)
>>>
>>> The class looks like that:
>>>
>>> class KnowledgeKeeper::Note {
>>> has $.title is required;
>>> has $.data is required;
>>> has @.tags;
>>> has @.attachments;
>>> has DateTime $.creation-date = DateTime.now;
>>> has DateTime $.modification-date = DateTime.now;
>>> }
>>>
>>> I first recognized it when a test just ended without dieing. That happens
>>> about in 50% of the test runs.
>>> But I could reproduce it with just a simple line in a script:
>>>
>>> #!/usr/bin/env perl6
>>> use KnowledgeKeeper::Note;
>>>
>>> my $note = KnowledgeKeeper::Note.new(title => "dasd", data => "adsad");
>>> say "OK";
>>>
>>> With this script it is not failing that much but at least reproducible:
>>>
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>> OK
>>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>>>PS C:\dev\repos\KnowledgeKeeper>
>>> $LastExitCode
>>>-1073741819
>>>
>>> OS: Windows 10 1909 x64
>>> Raku: This is Rakudo version 2020.01 built on MoarVM version 2020.01.1
>>> implementing Perl 6.d.
>>>
>>> Should I file a bug?
>>
>>
>> Definitely, yes. Please check first if it's still the same problem with the
>> latest released version. Also, try to golf it down to the minimal amount of
>> code that still produces the same result. Does the LastExitCode make any
>> sense?
>>
>> --
>> JJ
Re: junctions and parenthesis
> I would suggest calling .any on the list, that gives you just the tight > preference you want; even if there were no .any method available on the > object you've got, or you want a different function, you can . That's a good thought. The code wouldn't read as nicely, though (the syntax is less like English): say so .any eq .any; My solution would be just to always use parens on the junction functions: say so any() eq any(); On 6/24/20, Timo Paulssen wrote: > On 22/06/2020 20:12, Joseph Brenner wrote: >> > Speculating wildly: could there be a need for a different type of > > function with different precedence? > I would suggest calling .any on the list, that gives you just the tight > preference you want; even if there were no .any method available on the > object you've got, or you want a different function, you can . > > LMKWYT > - Timo > > >
Re: junctions and parenthesis
On 22/06/2020 20:12, Joseph Brenner wrote: > > Speculating wildly: could there be a need for a different type of > function with different precedence? I would suggest calling .any on the list, that gives you just the tight preference you want; even if there were no .any method available on the object you've got, or you want a different function, you can . LMKWYT - Timo
Re: Access violation when creating class instance
Thanks JJ,
I am using Rakudostar on Windows and 2020.01 is the current released
version so far.
I will try to reduce the code a bit more but it is just one class
definition together with an instantiation. Not sure I can pack that in a
one liner, but will try.
The access violation comes probably from C code handling some Windows
stuff.
On Wed, 24 Jun 2020 at 10:13, JJ Merelo wrote:
>
>
> El mié., 24 jun. 2020 a las 10:05, WFB ()
> escribió:
>
>> Hi all,
>>
>> I have an access violation on Windows for one of my classes and think it
>> is a bug, but not entirely sure about that.
>>
>> Every now and then creating a class instance ended my script with error:
>> Process finished with exit code -1073741819 (0xC005)
>>
>> The class looks like that:
>>
>> class KnowledgeKeeper::Note {
>> has $.title is required;
>> has $.data is required;
>> has @.tags;
>> has @.attachments;
>> has DateTime $.creation-date = DateTime.now;
>> has DateTime $.modification-date = DateTime.now;
>> }
>>
>> I first recognized it when a test just ended without dieing. That happens
>> about in 50% of the test runs.
>> But I could reproduce it with just a simple line in a script:
>>
>> #!/usr/bin/env perl6
>> use KnowledgeKeeper::Note;
>>
>> my $note = KnowledgeKeeper::Note.new(title => "dasd", data => "adsad");
>> say "OK";
>>
>> With this script it is not failing that much but at least reproducible:
>>
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> OK
>> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
>> PS C:\dev\repos\KnowledgeKeeper>
>> $LastExitCode
>>-1073741819
>>
>> OS: Windows 10 1909 x64
>> Raku: This is Rakudo version 2020.01 built on MoarVM version 2020.01.1
>> implementing Perl 6.d.
>>
>> Should I file a bug?
>>
>
> Definitely, yes. Please check first if it's still the same problem with
> the latest released version. Also, try to golf it down to the minimal
> amount of code that still produces the same result. Does the LastExitCode
> make any sense?
>
> --
> JJ
>
Re: Access violation when creating class instance
El mié., 24 jun. 2020 a las 10:05, WFB ()
escribió:
> Hi all,
>
> I have an access violation on Windows for one of my classes and think it
> is a bug, but not entirely sure about that.
>
> Every now and then creating a class instance ended my script with error:
> Process finished with exit code -1073741819 (0xC005)
>
> The class looks like that:
>
> class KnowledgeKeeper::Note {
> has $.title is required;
> has $.data is required;
> has @.tags;
> has @.attachments;
> has DateTime $.creation-date = DateTime.now;
> has DateTime $.modification-date = DateTime.now;
> }
>
> I first recognized it when a test just ended without dieing. That happens
> about in 50% of the test runs.
> But I could reproduce it with just a simple line in a script:
>
> #!/usr/bin/env perl6
> use KnowledgeKeeper::Note;
>
> my $note = KnowledgeKeeper::Note.new(title => "dasd", data => "adsad");
> say "OK";
>
> With this script it is not failing that much but at least reproducible:
>
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> PS C:\dev\repos\KnowledgeKeeper>
> $LastExitCode
>-1073741819
>
> OS: Windows 10 1909 x64
> Raku: This is Rakudo version 2020.01 built on MoarVM version 2020.01.1
> implementing Perl 6.d.
>
> Should I file a bug?
>
Definitely, yes. Please check first if it's still the same problem with the
latest released version. Also, try to golf it down to the minimal amount of
code that still produces the same result. Does the LastExitCode make any
sense?
--
JJ
Access violation when creating class instance
Hi all,
I have an access violation on Windows for one of my classes and think it is
a bug, but not entirely sure about that.
Every now and then creating a class instance ended my script with error:
Process finished with exit code -1073741819 (0xC005)
The class looks like that:
class KnowledgeKeeper::Note {
has $.title is required;
has $.data is required;
has @.tags;
has @.attachments;
has DateTime $.creation-date = DateTime.now;
has DateTime $.modification-date = DateTime.now;
}
I first recognized it when a test just ended without dieing. That happens
about in 50% of the test runs.
But I could reproduce it with just a simple line in a script:
#!/usr/bin/env perl6
use KnowledgeKeeper::Note;
my $note = KnowledgeKeeper::Note.new(title => "dasd", data => "adsad");
say "OK";
With this script it is not failing that much but at least reproducible:
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
OK
PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
PS C:\dev\repos\KnowledgeKeeper>
$LastExitCode
-1073741819
OS: Windows 10 1909 x64
Raku: This is Rakudo version 2020.01 built on MoarVM version 2020.01.1
implementing Perl 6.d.
Should I file a bug?
Thanks,
Wolfgang
