subject:"Re\: EVAL\?"


On 06/14/2018 01:13 PM, Trey Harris wrote:

Just a small stylistic thing to mention:

On Thu, Jun 14, 2018 at 1:59 AM Todd Chester > wrote:


p6
        if not $dir.IO.d.bool {}
        for  slice  "\n", $WebStr   ->  $Line { }

   and on and on and so forth.  I know a lot of them by heart now.

By |.bool|, I assume you meant |.Bool|, but in any case, it isn’t 
necessary since the context of a |not| forces it to be boolean.


Indeed!

Exists (directory):
   DIRPATH.IO.d.Bool;
   if not $WorkingDir.IO.d.Bool { mkdir $WorkingDir, 0o766; }




If you want the opposite—a boolean without the sense-negation, you can 
use |so|, but in the context of an |if|, it should rarely, if ever, be 
necessary.


In the same way that |so| is used to explicitly truthify, unary |+| is 
used to explicitly numify.


E.g., once you know that an |IntStr| 
 dual value gives a result 
reminiscent of Perl 5’s string numbers (except that without going to 
crazy lengths, you can easily supply exactly the number and string you 
want):


|my $x = IntStr.new(42, "The Answer"); my $y = IntStr.new(0, "Nothing"); 
for ($x, $y) -> $z { printf "\$z: '%s', so \$z: '%s', +\$z: '%s'\n", $z, 
so $z, +$z; say " Double it: ", $z * 2; say " or 'double' it: ", $z x 2; } |


gives results:

|$z: 'The Answer', so $z: 'True', +$z: '42' Double it: 84 or 'double' it: 
The AnswerThe Answer $z: 'Nothing', so $z: 'False', +$z: '0' Double it: 
0 or 'double' it: NothingNothing |


In case you’re wondering, you’ll usually have no reason to explicitly 
construct a dual value like that; you generally get a NumStr or its 
counterparts like IntStr when reading input or expecting command-line 
arguments.


(Also note that the stringification equivalent to |so| and unary |+| is 
|~|, but it wasn’t necessary above since the |%s| template to |sprintf| 
forces stringification. Also note that using s/printf at all is not 
encouraged—but it was useful above, just to make things explicit.)






Thank you!  Wonderful exposition! I am going to write it down
for later use.

I use "if not" a lot because it is human readable for
me and assists in maintaining the code.

Re: EVAL?


On 06/14/2018 11:10 AM, Elizabeth Mattijsen wrote:

We are all maintainers of the glossary.  Patches / Pull Requests are welcome.


Hi Elizabeth,


My favorite definition I found was:

   http://www.yourdictionary.com/pragma

   (computing, programming) A compiler directive; data embedded
   in source code by programmers to indicate some intention to
   the compiler.

   This pragma stops the compiler from generating those
   warnings we don't care about.

You could use this and add "In Perl, "Pragma" specifically means ..."

-T

Re: EVAL?

2018-06-14 Thread Trey Harris

Just a small stylistic thing to mention:

On Thu, Jun 14, 2018 at 1:59 AM Todd Chester  wrote:

p6
>if not $dir.IO.d.bool {}
>for  slice  "\n", $WebStr   ->  $Line { }
>
>   and on and on and so forth.  I know a lot of them by heart now.
>
By .bool, I assume you meant .Bool, but in any case, it isn’t necessary
since the context of a not forces it to be boolean.

If you want the opposite—a boolean without the sense-negation, you can use
so, but in the context of an if, it should rarely, if ever, be necessary.

In the same way that so is used to explicitly truthify, unary + is used to
explicitly numify.

E.g., once you know that an IntStr 
dual value gives a result reminiscent of Perl 5’s string numbers (except
that without going to crazy lengths, you can easily supply exactly the
number and string you want):

my $x = IntStr.new(42, "The Answer");
my $y = IntStr.new(0, "Nothing");
for ($x, $y) -> $z {
  printf "\$z: '%s', so \$z: '%s', +\$z: '%s'\n",
$z,so $z,+$z;
  say "  Double it: ", $z * 2;
  say "  or 'double' it: ", $z x 2;
}

gives results:

$z: 'The Answer', so $z: 'True', +$z: '42'
  Double it: 84
  or 'double' it: The AnswerThe Answer
$z: 'Nothing', so $z: 'False', +$z: '0'
  Double it: 0
  or 'double' it: NothingNothing

In case you’re wondering, you’ll usually have no reason to explicitly
construct a dual value like that; you generally get a NumStr or its
counterparts like IntStr when reading input or expecting command-line
arguments.

(Also note that the stringification equivalent to so and unary + is ~, but
it wasn’t necessary above since the %s template to sprintf forces
stringification. Also note that using s/printf at all is not encouraged—but
it was useful above, just to make things explicit.)

Re: EVAL?

2018-06-14 Thread Elizabeth Mattijsen

We are all maintainers of the glossary.  Patches / Pull Requests are welcome.

> On 14 Jun 2018, at 20:03, Brandon Allbery  wrote:
> 
> I'm trying to not second-guess whoever maintains the glossary. And by that 
> message also pointing up the omission.
> 
> On Thu, Jun 14, 2018 at 2:01 PM The Sidhekin  wrote:
> On Thu, Jun 14, 2018 at 7:57 PM, Brandon Allbery  wrote:
> You can never be certain in *any* case. Check if you're not sure what it 
> means. Because sometimes languages use some term in a way you don't expect, 
> whether because they drew it from some specific discipline (Haskell uses a 
> lot of terminilogy from abstract mathematics, for example) or for some reason 
> (I've hit a few cases where the language author didn't know the actual 
> meaning of some term and used it "oddly" as a result).
> 
> https://docs.perl6.org/language/glossary
> 
> Which doesn't have "pragma" in it, probably because it's not specific to 
> Perl. It's been around, and used in this sense, since at least the 1960s and 
> probably earlier.
> 
>   ... but does have "whitespace" and "variable" in it, neither of which is 
> specific to Perl. :-P
> 
>   Isn't the lack of "pragma" there an omission to be corrected?
> 
>   Particularly if the term is required for the reading of error messages?
> 
> 
> Eirik
> 
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?

I'm trying to not second-guess whoever maintains the glossary. And by that
message also pointing up the omission.

On Thu, Jun 14, 2018 at 2:01 PM The Sidhekin  wrote:

> On Thu, Jun 14, 2018 at 7:57 PM, Brandon Allbery 
> wrote:
>
>> You can never be certain in *any* case. Check if you're not sure what it
>> means. Because sometimes languages use some term in a way you don't expect,
>> whether because they drew it from some specific discipline (Haskell uses a
>> lot of terminilogy from abstract mathematics, for example) or for some
>> reason (I've hit a few cases where the language author didn't know the
>> actual meaning of some term and used it "oddly" as a result).
>>
>> https://docs.perl6.org/language/glossary
>>
>> Which doesn't have "pragma" in it, probably because it's not specific to
>> Perl. It's been around, and used in this sense, since at least the 1960s
>> and probably earlier.
>>
>
>   ... but does have "whitespace" and "variable" in it, neither of which is
> specific to Perl. :-P
>
>   Isn't the lack of "pragma" there an omission to be corrected?
>
>   Particularly if the term is required for the reading of error messages?
>
>
> Eirik
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?

On Thu, Jun 14, 2018 at 7:57 PM, Brandon Allbery 
wrote:

> You can never be certain in *any* case. Check if you're not sure what it
> means. Because sometimes languages use some term in a way you don't expect,
> whether because they drew it from some specific discipline (Haskell uses a
> lot of terminilogy from abstract mathematics, for example) or for some
> reason (I've hit a few cases where the language author didn't know the
> actual meaning of some term and used it "oddly" as a result).
>
> https://docs.perl6.org/language/glossary
>
> Which doesn't have "pragma" in it, probably because it's not specific to
> Perl. It's been around, and used in this sense, since at least the 1960s
> and probably earlier.
>

  ... but does have "whitespace" and "variable" in it, neither of which is
specific to Perl. :-P

  Isn't the lack of "pragma" there an omission to be corrected?

  Particularly if the term is required for the reading of error messages?


Eirik

Re: EVAL?

Not to mention "language designer isn't from your culture, and the word has
different connotations in theirs". The eastern (or for that matter western)
US does not define the world.

On Thu, Jun 14, 2018 at 1:57 PM Brandon Allbery  wrote:

> You can never be certain in *any* case. Check if you're not sure what it
> means. Because sometimes languages use some term in a way you don't expect,
> whether because they drew it from some specific discipline (Haskell uses a
> lot of terminilogy from abstract mathematics, for example) or for some
> reason (I've hit a few cases where the language author didn't know the
> actual meaning of some term and used it "oddly" as a result).
>
> https://docs.perl6.org/language/glossary
>
> Which doesn't have "pragma" in it, probably because it's not specific to
> Perl. It's been around, and used in this sense, since at least the 1960s
> and probably earlier.
>
> So also check various CS glossaries.
> Such as FOLDOC: http://foldoc.org/pragma
>
> On Thu, Jun 14, 2018 at 1:52 PM ToddAndMargo 
> wrote:
>
>> On 06/14/2018 10:49 AM, Brandon Allbery wrote:
>> > That's actually the origin of it: pragmatic / real-world behavior, as
>> > opposed to idealized situations.
>>
>> I can't always tell when things are English and when
>> things are Perl.
>>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?

On Thu, Jun 14, 2018 at 7:46 PM, ToddAndMargo  wrote:

> On 06/14/2018 10:43 AM, The Sidhekin wrote:
>
>>
>>More relevant, Perl 6 documentation: https://docs.perl6.org/languag
>> e/pragmas
>>
>
> You are presuming I knew the word was a Perl word.
> I though it was English, as in pragmatic
>

  Not my intention.  This was just informing you where it is documented,
not presuming any prior knowledge.

  (The next line may be more presumptuous: "Now, I'm not sure how I would
have responded to such an error message if I wasn't already familiar with
the term.  Search the web for Perl6 + pragma, perhaps?"

  ... but also uncertain ... and in any case referring to my own self
specifically.)

Eirik

Re: EVAL?

You can never be certain in *any* case. Check if you're not sure what it
means. Because sometimes languages use some term in a way you don't expect,
whether because they drew it from some specific discipline (Haskell uses a
lot of terminilogy from abstract mathematics, for example) or for some
reason (I've hit a few cases where the language author didn't know the
actual meaning of some term and used it "oddly" as a result).

https://docs.perl6.org/language/glossary

Which doesn't have "pragma" in it, probably because it's not specific to
Perl. It's been around, and used in this sense, since at least the 1960s
and probably earlier.

So also check various CS glossaries.
Such as FOLDOC: http://foldoc.org/pragma

On Thu, Jun 14, 2018 at 1:52 PM ToddAndMargo  wrote:

> On 06/14/2018 10:49 AM, Brandon Allbery wrote:
> > That's actually the origin of it: pragmatic / real-world behavior, as
> > opposed to idealized situations.
>
> I can't always tell when things are English and when
> things are Perl.
>

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?


On 06/14/2018 10:49 AM, Brandon Allbery wrote:
That's actually the origin of it: pragmatic / real-world behavior, as 
opposed to idealized situations.


I can't always tell when things are English and when
things are Perl.

Re: EVAL?

That's actually the origin of it: pragmatic / real-world behavior, as
opposed to idealized situations.

On Thu, Jun 14, 2018 at 1:47 PM ToddAndMargo  wrote:

> On 06/14/2018 10:43 AM, The Sidhekin wrote:
> >
> >More relevant, Perl 6 documentation:
> > https://docs.perl6.org/language/pragmas
>
> You are presuming I knew the word was a Perl word.
> I though it was English, as in pragmatic
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?


On 06/14/2018 10:43 AM, The Sidhekin wrote:


   More relevant, Perl 6 documentation: 
https://docs.perl6.org/language/pragmas


You are presuming I knew the word was a Perl word.
I though it was English, as in pragmatic

Re: EVAL?

That's just a different variant of an old shell "hack": drop a program
named "test" somewhere where root might run a shell script.

Which is why root's path no longer includes the current directory, and
these days nothing outside the system directories.

On Thu, Jun 14, 2018 at 1:37 PM ToddAndMargo  wrote:

> On 06/14/2018 10:30 AM, Brandon Allbery wrote:
> > In short, pragmas are all-same-case "use" names; instead of loading
> > code, they tell the compiler to change its behavior.
> >
> > The MONKEY-* pragmas generally control various kinds of unsafe or
> > dangerous behavior, including direct access to the mechanisms underneath
> > / "supporting" Rakudo and things like EVAL. Other all-uppercase names
> > also generally represent "dangerous" actions or options.
> >
> > There are a few pragmas that are all lowercase instead of all uppercase;
> > they also change the compiler's behavior, but are safer than the
> > all-uppercase ones. "use lib" is one of them. (This is why modules are
> > generally mixed-case names.)
>
>
> Thank you!
>
> Speaking of dangerous, go find a perl program being run by root,
> inject some code into one of its modules, and ...
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?

On Thu, Jun 14, 2018 at 7:21 PM, ToddAndMargo  wrote:

> 2) what the heck is a "pragma"?  Way to obscure.
>

  I thought you knew.  From the Perl 5 documentation: "A pragma is a module
which influences some aspect of the compile time or run time behaviour of
Perl, such as strict or warnings."

  More relevant, Perl 6 documentation:
https://docs.perl6.org/language/pragmas

  Now, I'm not sure how I would have responded to such an error message if
I wasn't already familiar with the term.  Search the web for Perl6 +
pragma, perhaps?

  Just thinking out loud: This hint ("use the MONKEY-SEE-NO-EVAL pragma to
override this error, but only if you're VERY sure your data contains no
injection attacks") is rather terse for those who need it ... might it be
better if the error message instead referenced documentation?

Eirik

Re: EVAL?


On 06/14/2018 10:30 AM, Brandon Allbery wrote:
In short, pragmas are all-same-case "use" names; instead of loading 
code, they tell the compiler to change its behavior.


The MONKEY-* pragmas generally control various kinds of unsafe or 
dangerous behavior, including direct access to the mechanisms underneath 
/ "supporting" Rakudo and things like EVAL. Other all-uppercase names 
also generally represent "dangerous" actions or options.


There are a few pragmas that are all lowercase instead of all uppercase; 
they also change the compiler's behavior, but are safer than the 
all-uppercase ones. "use lib" is one of them. (This is why modules are 
generally mixed-case names.)



Thank you!

Speaking of dangerous, go find a perl program being run by root,
inject some code into one of its modules, and ...

Re: EVAL?

In short, pragmas are all-same-case "use" names; instead of loading code,
they tell the compiler to change its behavior.

The MONKEY-* pragmas generally control various kinds of unsafe or dangerous
behavior, including direct access to the mechanisms underneath /
"supporting" Rakudo and things like EVAL. Other all-uppercase names also
generally represent "dangerous" actions or options.

There are a few pragmas that are all lowercase instead of all uppercase;
they also change the compiler's behavior, but are safer than the
all-uppercase ones. "use lib" is one of them. (This is why modules are
generally mixed-case names.)

https://docs.perl6.org/language/pragmas for more information.

On Thu, Jun 14, 2018 at 1:22 PM ToddAndMargo  wrote:

> On 06/13/2018 12:27 PM, Brandon Allbery wrote:
> > Exactly what it says: eval is a code injection attack waiting to happen.
> > If you actually need it, you get to do your own data sanitization, and
> > you tell Perl 6 you did so with "use MONKEY-SEE-NO-EVAL;".
>
> Hi Brandon,
>
> Thank you for clarifying.  My hand up with the error message
> was its wording:
>
> "use the MONKEY-SEE-NO-EVAL pragma to override this error"
>
> 1) I did not realize the the word "use" mean the Perl "use".
> I though it meant the English usages as in go do something.
>
> 2) what the heck is a "pragma"?  Way to obscure.
>
> Your response cleared up the misunderstanding nicely.
>
> -T
>

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: EVAL?


On 06/13/2018 12:27 PM, Brandon Allbery wrote:
Exactly what it says: eval is a code injection attack waiting to happen. 
If you actually need it, you get to do your own data sanitization, and 
you tell Perl 6 you did so with "use MONKEY-SEE-NO-EVAL;".


Hi Brandon,

Thank you for clarifying.  My hand up with the error message
was its wording:

   "use the MONKEY-SEE-NO-EVAL pragma to override this error"

1) I did not realize the the word "use" mean the Perl "use".
I though it meant the English usages as in go do something.

2) what the heck is a "pragma"?  Way to obscure.

Your response cleared up the misunderstanding nicely.

-T

Re: EVAL?


On 06/14/2018 09:11 AM, Timo Paulssen wrote:

If it's literally just the name of a sub that you'll immediately invoke,
you can side-step EVAL completely

     ::('&' ~ $RunSpecific)()

should do the trick.

::("") will give you the sub object, and putting () after it will
immediately call it.

It will allow access to all subs, even from the core, so subs like "die"
and "exit" are reachable, but it's less dangerous than accepting any
random code. For one, it will only work with subs that don't take arguments.

HTH
   - Timo




Perfect!  Thank you!

Re: EVAL?

2018-06-14 Thread Elizabeth Mattijsen




> On 14 Jun 2018, at 18:19, The Sidhekin  wrote:
> 
> On Thu, Jun 14, 2018 at 6:11 PM, Timo Paulssen  wrote:
> If it's literally just the name of a sub that you'll immediately invoke,
> you can side-step EVAL completely
> 
> ::('&' ~ $RunSpecific)()
> 
> should do the trick.
> 
>   I haven't been much into Perl 6 lately, but isn't this just the same as
> 
> &::($RunSpecific)()
> 
> ... which is easier on these old eyes?

Indeed it is.

Re: EVAL?

On Thu, Jun 14, 2018 at 6:11 PM, Timo Paulssen  wrote:

> If it's literally just the name of a sub that you'll immediately invoke,
> you can side-step EVAL completely
>
> ::('&' ~ $RunSpecific)()
>
> should do the trick.
>

  I haven't been much into Perl 6 lately, but isn't this just the same as

&::($RunSpecific)()

... which is easier on these old eyes?


Eirik

Re: EVAL?

2018-06-14 Thread Timo Paulssen

If it's literally just the name of a sub that you'll immediately invoke,
you can side-step EVAL completely

    ::('&' ~ $RunSpecific)()

should do the trick.

::("") will give you the sub object, and putting () after it will
immediately call it.

It will allow access to all subs, even from the core, so subs like "die"
and "exit" are reachable, but it's less dangerous than accepting any
random code. For one, it will only work with subs that don't take arguments.

HTH
  - Timo

Re: EVAL?

> wrote:

On 06/13/2018 12:27 PM, Brandon Allbery wrote:

use MONKEY-SEE-NO-EVAL;

Thank you. Someone had fun with that name!

Do I presume there is not other way around the issue?

On 06/14/2018 05:21 AM, The Sidhekin wrote:

On Thu, Jun 14, 2018 at 8:01 AM, Todd Chester That depends on your use case. EVAL/eval is powerful enough it could
be pretty much anything, so bird's-eye view here:

If $RunSpecific is sufficiently non-generic (i.e. couldn't be any
code whatsoever), an approach with dispatch tables or similar (dynamic
method lookup, giant switch ...) might be an alternative. Optionally
parsing the code (Perl subset, DSL?) yourself.

For use with any code whatsoever though, you need that kind of power,
and as Brandon wrote: You get to do your own data sanitization, and you
tell Perl 6 you did so with "use MONKEY-SEE-NO-EVAL;".

Eirik

Hi Eirik,

The program goes out and checks for new updates to programs I carry
with me to support my customers. To debug a sub individually,
I place the sub's name on the command line. This way I don't
have to run them all at once to debug one sub. $RunSpecific
is the name of a particular sub. (If I misspell the sub name, I
get ignored.)

This is especially useful when adding a new program to check or
when someone changes their web page.

Chuckle: I catch a lot of boo-boos when they change their
web pages.

On one program, I can't get the vendor to place the program's
revision on the web. But he does place a check sum to for
the download. So, I download the checksum and compare it to
the previous checksum, if they don't match, I download the
actual program. Then do an unzip list and find the revision
from one of the files inside the zip. With the revision,
I name the zip file properly. And yes, I have caught boo-boos
in his zip file before.

-T

Re: EVAL?