Re: EVAL?

On Fri, 15 Jun 2018 at 06:13, Trey Harris wrote: Thanks for the nice examples of IntStr and friends. I was intrigued with this statement at the end: > Also note that using s/printf at all is not encouraged Could you expand on that? > ​ > -- Norman Gaywood, Computer Systems Officer School

Re: RFE: eval documentation

On 06/14/2018 02:52 PM, JJ Merelo wrote: El jue., 14 jun. 2018 a las 23:34, ToddAndMargo (>) escribió: On 06/14/2018 02:20 PM, JJ Merelo wrote: > Can you please open an issue in perl6/doc? It's the best to track it, > and also to check that

Re: RFE: eval documentation

El jue., 14 jun. 2018 a las 23:34, ToddAndMargo () escribió: > On 06/14/2018 02:20 PM, JJ Merelo wrote: > > Can you please open an issue in perl6/doc? It's the best to track it, > > and also to check that it's been solved to everyone's satisfaction. > > > > If you can't for any reason, I can open

Re: RFE: eval documentation

On 06/14/2018 02:20 PM, JJ Merelo wrote: Can you please open an issue in perl6/doc? It's the best to track it, and also to check that it's been solved to everyone's satisfaction. If you can't for any reason, I can open it for you, but I'll have to keep coming back to see if it's OK when

Re: RFE: eval documentation

, ToddAndMargo () escribió: > On 06/14/2018 10:31 AM, ToddAndMargo wrote: > > Dear Perl6 Developers, > > > > https://docs.perl6.org/language/5to6-perlfunc#eval > > > > Would you please consider adding > > > > ::('&' ~ $RunSpecific)() > >

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

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

Re: EVAL?

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

Re: RFE: eval documentation

On 06/14/2018 10:31 AM, ToddAndMargo wrote: Dear Perl6 Developers, https://docs.perl6.org/language/5to6-perlfunc#eval Would you please consider adding ::('&' ~ $RunSpecific)() &::($RunSpecific)() to the documentation, as well as an explanation of the error message when us

Re: EVAL?

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

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

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

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

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 >

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

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: RFE: eval documentation

On 06/14/2018 10:45 AM, Brandon Allbery wrote: I think the message is obscure for a reason: the last thing you want is for someone to make an insecure module look "safe" by just dropping that pragma into it. You want to make them think about what they are doing. I hate always having to ask

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 >

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: RFE: eval documentation

l6 Developers, > > https://docs.perl6.org/language/5to6-perlfunc#eval > > Would you please consider adding > > ::('&' ~ $RunSpecific)() > &::($RunSpecific)() > > to the documentation, as well as an explanation of > the error message when using EVAL >

Re: EVAL?

ious 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

Re: EVAL?

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?

ect 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

Re: EVAL?

kudo 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&qu

RFE: eval documentation

Dear Perl6 Developers, https://docs.perl6.org/language/5to6-perlfunc#eval Would you please consider adding ::('&' ~ $RunSpecific)() &::($RunSpecific)() to the documentation, as well as an explanation of the error message when using EVAL ===SORRY!=== Error while compili

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 clari

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 im

Re: EVAL?

> 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)() > >

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

Re: EVAL?

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 s

Re: EVAL?

<mailto:toddandma...@zoho.com>> 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 Th

Re: EVAL?

On Thu, Jun 14, 2018 at 8:01 AM, Todd Chester 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? > Th

Re: EVAL?

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?

Re: EVAL?

On Wed, 13 Jun 2018 15:23:56 -0700 yary wrote > Pet peeve, "$RunSpecific" with the quotes on either side is exactly the same as $RunSpecific without the quotes. Perl isn't shell. > > -y Hi Yary, Chuckle. Missed one. What?? Or two or three ... This program that I have been

Re: EVAL?

he quotes on either side is exactly the same > as $RunSpecific without the quotes. Perl isn't shell. > > -y > > On Wed, Jun 13, 2018 at 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 t

Re: EVAL?

Pet peeve, "$RunSpecific" with the quotes on either side is exactly the same as $RunSpecific without the quotes. Perl isn't shell. -y On Wed, Jun 13, 2018 at 12:27 PM, Brandon Allbery wrote: > Exactly what it says: eval is a code injection attack waiting to happen. > If y

Re: EVAL?

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;". On Wed, Jun 13, 2018 at 3:22 PM ToddAndMargo wrote: > Hi All, > > I am c

EVAL?

Hi All, I am converting a program from Perl5 to Perl 6. This line else { eval "$RunSpecific"; } became this line else { EVAL "$RunSpecific"; } And threw this error $ perl6 -c GetUpdates.pl6 ===SORRY!=== Error while compiling /home/linuxutil/GetUpdates.pl6 EVAL

Re: [perl #122289] [BUG] unexpected behaviour during EVAL()

: > > Evaling objects won't work if code that eval was preompiled > > independently. In this case class Planet and Class SpaceStation are > > somewhat inaccesible in imported sub. Even though putting slurp $path > > as argument of eval will fail. It was working on parrot but be

Re: [perl #122289] [BUG] unexpected behaviour during EVAL()

: > > Evaling objects won't work if code that eval was preompiled > > independently. In this case class Planet and Class SpaceStation are > > somewhat inaccesible in imported sub. Even though putting slurp $path > > as argument of eval will fail. It was working on parrot but be

[perl #122289] [BUG] unexpected behaviour during EVAL()

Hmmm… Parrot is in the past as of today, and I wish it was possible to try this on MoarVM. What's the way to reproduce this issue? On 2014-07-14 02:31:54, teodozjan wrote: > Evaling objects won't work if code that eval was preompiled > independently. In this case class Planet and

[perl #122256] [NYI] Support EVAL(Buf)

On Wed, 09 Jul 2014 07:10:31 -0700, coke wrote: > S29 says that EVAL should work on Buf in addition to Str; There is one > test in S29-context/eval.t that tests for this but is skipped. > > Could probably use more tests. > Everything is now implemented[^1] with more tests a

[perl #122256] [NYI] Support EVAL(Buf)

On Wed, 09 Jul 2014 07:10:31 -0700, coke wrote: > S29 says that EVAL should work on Buf in addition to Str; There is one > test in S29-context/eval.t that tests for this but is skipped. > > Could probably use more tests. > Everything is now implemented[^1] with more tests a

[perl #130773] [PARSER] Bogus "Useless use" warning for WhateverCode in EVAL

On Sat, 26 Aug 2017 05:20:14 -0700, sml...@gmail.com wrote: > This bug is still present in > > Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 2017.08.1- > 19-g151a2563 > implementing Perl 6.c. Fudged tests preemptively added to S02-types/whatever.t in roast commit 4b2fef409.

[perl #132015] [LTA] Backtraces for errors in EVAL print nonexistent paths (‘foo’.EVAL)

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132015] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132015 > Code: ‘foo’.EVAL Result: ===SORRY!=== Error while compiling /h

[perl #130773] [BUG] Bogus "Useless use" warning for WhateverCode in EVAL

This bug is still present in Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 2017.08.1-19-g151a2563 implementing Perl 6.c.

[perl #130951] [CONC] EVAL is not reentrant

ise.anyof((^2).map: { > > start { > > loop { > > EVAL "True"; > > } > > } > >}); > > } > > ``` > > > 2. *** glibc detected *** ... double free or corruption (fasttop) ... > >

Re: [perl #130951] [BUG] EVAL thread safety

Thanks for the bug report. On Tue, Mar 07, 2017 at 05:12:34PM -0800, J . David Lowe wrote: > > ``` > #!/usr/bin/env perl6 > > use v6.c; > > sub MAIN { >await Promise.anyof((^2).map: { > start { > l

[perl #130951] [BUG] EVAL thread safety

usr/bin/env perl6 use v6.c; sub MAIN { await Promise.anyof((^2).map: { start { loop { EVAL "True"; } } }); } ``` The three failures I've observed are: 1. Segmentation fault 2. *** glibc detected *** ... double free or corruption (fasttop)

[perl #130773] [BUG] Bogus "Useless use" warning for WhateverCode in EVAL

# New Ticket Created by Sam S. # Please include the string: [perl #130773] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130773 > EVAL is usually happy to return the result of its expression without warnings: ➜

Re: [perl #126264] LTA error message for keywords like "eval" or "begin" in lower case

ure correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=126264 > > > > If you absent-mindedly type in keywords that should be capitalized in lower > case, the compiler will not suggest the correct upper case form. For example: > >

[perl #128684] .EVAL as a method call bypasses the MONKEY-SEE-NO-EVAL pragma

# New Ticket Created by Zoffix Znet # Please include the string: [perl #128684] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128684 > The EVAL as a sub shows an error message about MONKEY-SEE-NO-EVAL: m: my $x = '

Re: [perl #128418] [RFC] Deprecate eval-dies-ok/eval-lives-ok in favour of Str arg to dies-ok/lives-ok

html?id=128418 > >> >> >> In Test.pm6, we have throws-like that takes either a Callable or a Str as >> the first arg. The Callable gets called and Str gets EVALed. >> >> However, with dies-ok/lives-ok the implementation rolls out an entirely new >> se

Re: [perl #128418] [RFC] Deprecate eval-dies-ok/eval-lives-ok in favour of Str arg to dies-ok/lives-ok

erl.org/Ticket/Display.html?id=128418 > > > > In Test.pm6, we have throws-like that takes either a Callable or a Str as the > first arg. The Callable gets called and Str gets EVALed. > > However, with dies-ok/lives-ok the implementation rolls out an entirely new > set

[perl #128418] [RFC] Deprecate eval-dies-ok/eval-lives-ok in favour of Str arg to dies-ok/lives-ok

arg. The Callable gets called and Str gets EVALed. However, with dies-ok/lives-ok the implementation rolls out an entirely new set of subs: eval-dies-ok/eval-lives-ok. This RFC proposes the eval-dies-ok/eval-lives-ok subs get deprecated and eventually removed in favour of implementing an interf

[perl #128417] [BUG] eval-dies-ok/eval-lives-ok EVAL code in the wrong context

# New Ticket Created by Zoffix Znet # Please include the string: [perl #128417] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128417 > The results of these tests should be reversed, the eval-dies-ok succeeding and e

[perl #127188] [IMPROVEMENT SUGGESTION] :lang on eval to attempt to use an Inline::FOO module

# New Ticket Created by Zoffix Znet # Please include the string: [perl #127188] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=127188 > Seeing that value of 'Perl5' for the :lang argument to EVAL attempts to load Inl

Re: [perl #127188] [IMPROVEMENT SUGGESTION] :lang on eval to attempt to use an Inline::FOO module

I still think that language modules like Inline::* or v5 need to register itself. Which means, you'd use such a module before doing the EVAL so the EVAL knows what module handles the requested language. Am 06.01.2016 um 14:40 schrieb Zoffix Znet (via RT): # New Ticket Created by Zoffix Znet

[perl #126839] Can't EVAL in a module loaded by a module

# New Ticket Created by Leon Timmermans # Please include the string: [perl #126839] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126839 > Given a Bar.pm containing: EVAL '' And a Foo.pm containing use Bar; W

Re: [perl #126759] AutoReply: [BUG] EVAL not working with custom circumfixes,terms, etc

needs to set a key in EXPORTHOW as well. > > On Sun, Nov 29, 2015 at 4:59 PM perl6 via RT <perl6-bugs-follo...@perl.org> > wrote: > >> Greetings, >> >> This message has been automatically generated in response to the >> creation of a trouble ticket regarding: >

Re: [perl #126759] AutoReply: [BUG] EVAL not working with custom circumfixes,terms, etc

n automatically generated in response to the > creation of a trouble ticket regarding: > "[BUG] EVAL not working with custom circumfixes,terms, etc", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket ha

[perl #126759] [BUG] EVAL not working with custom circumfixes,terms, etc

# New Ticket Created by Lloyd Fournier # Please include the string: [perl #126759] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126759 > presently EVAL doesn't work with custom: - postcirumfix - circumfix - te

[perl #126754] wrong "self" inside class definition inside EVAL inside class

# New Ticket Created by "Brian S. Julin" # Please include the string: [perl #126754] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126754 > Relatively recent regression: (01:22:01 AM) skids: m: class A { meth

[perl6/specs] 9742c3: fossil eval replaced with EVAL

t 2015) Changed paths: M S32-setting-library/Basics.pod Log Message: --- fossil eval replaced with EVAL

[perl #126264] LTA error message for keywords like "eval" or "begin" in lower case

ase, the compiler will not suggest the correct upper case form. For example: $ perl6 > say EVAL "2+2"; 4 > say eval "2+2"; ===SORRY!=== Error while compiling Undeclared routine: eval used at line 1. Did you mean 'val'? > BEGIN {say pi} 3.14159265358979 > begin {say pi}

Should the use of eval recommend EVAL?

Hi, I just tried to use eval "say 19+23"; but I got: ===SORRY!=== Error while compiling a.pl Undeclared routine: eval used at line 3. Did you mean 'val'? Would it be possible to recommend 'EVAL' as well ? Gabor

[perl #126148] [BUG] `<2147483648/8>' gives "Cannot find method 'compile_time_value'", breaks EVAL(Instant.perl)

«===SORRY!===␤Cannot find method 'compile_time_value'␤» That format is the result returned by Instant.perl: carlin m: my $x = now; say $x.perl camelia rakudo-moar f2488e: OUTPUT«Instant.new(<1176079147668/815>)␤» Therefore, EVAL(now.perl) doesn't work: carlin m: my $x = no

[perl #124963] Roast rakudo skip/todo test:./S04-phasers/end.t line:42 reason: 'lexicals and EVAL()'

I rewrote the fudged tests with commit https://github.com/perl6/roast/commit/c48ef39ea4. They pass now. I'm closing this ticket as 'rejected.

[perl6/specs] a1a774: s/evalfile/EVALFILE/, for consistency with EVAL.

) Changed paths: M S29-functions.pod Log Message: --- s/evalfile/EVALFILE/, for consistency with EVAL.

Re: [perl #125292] [BUG] Array of Pairs .perl cannot .EVAL

This was fixed earlier today by masak++ with 37e2c9c0cc6160aae8 . The problem was really that: [:a] was being interpreted like a reduce meta operator like in: [+] 1,2,3,4 The [:a] representation is used by .perl on a Pair. Liz On 30 May 2015, at 19:07, hanenkamp

[perl #125292] [BUG] Array of Pairs .perl cannot .EVAL

# New Ticket Created by hanenkamp # Please include the string: [perl #125292] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=125292 This explodes: % perl6 -e [a = 1].perl.EVAL Type check failed in binding op; expected

[perl #124324] [BUG] cannot use EVAL in a precompiled dependency

# New Ticket Created by Tobias Leich # Please include the string: [perl #124324] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=124324 $ cat eval.pm BEGIN { EVAL 'say 42'; 0 } $ cat use_eval.pm use lib '.'; use eval

[perl #123002] [BUG] NullPointerException when calling a sub which runs EVAL on minimal role declaration

I added a test to S14-roles/basic.t with commit https://github.com/perl6/roast/commit/62ca417fa2 I'm closing this ticket as 'resolved'.

[perl #102478] [BUG] Attributes can't be declared inside of a BEGIN eval in Rakudo

constraint $ perl6 -e 'class A { BEGIN EVAL q[has $.x] }; say A.new(x = 3).x' 3 $ perl6-m -e 'class A { EVAL q[has $.x] }; say A.new(x = 3).x' No such method 'x' for invocant of type 'A' in block unit at -e:1 I added tests to S12-attributes/undeclared.t and S12-attributes/class.t with commit

[perl #77644] memory leak on EVAL

As a status update: An empty EVAL combined with while 1 still seems to consume more and more memory (happens on Moar, Parrot and JVM): $ perl6 -e 'EVAL q[] while 1'

[perl #123002] [BUG] NullPointerException when calling a sub which runs EVAL on minimal role declaration

on JVM $ perl6-j -e sub foo { EVAL 'role R { }' }; foo; say 'alive' ===SORRY!=== java.lang.NullPointerException Using EVAL on the role declaration directly doesn't fail: $ perl6-j -e EVAL 'role R { }'; say 'alive' alive With the help from psch (http://irclog.perlgeek.de/perl6/2014-10-17#i_9527240

[perl6/specs] 7fe418: filling EVAL

paths: M S99-glossary.pod Log Message: --- filling EVAL

[perl6/specs] 32d02f: S99 : name, symbol, EVAL, import, export.

) Changed paths: M S99-glossary.pod Log Message: --- S99 : name, symbol, EVAL, import, export.

[perl #122255] remove eval

On Tue Jul 15 05:41:54 2014, coke wrote: On Wed Jul 09 07:09:04 2014, coke wrote: We tracked the initial spec switch to EVAL, and left eval around to allow folks to switch. Now that a suitable amount of time has passed, we should remove eval and associated spec tests, and probably add

[perl #122255] remove eval

On Wed Jul 09 07:09:04 2014, coke wrote: We tracked the initial spec switch to EVAL, and left eval around to allow folks to switch. Now that a suitable amount of time has passed, we should remove eval and associated spec tests, and probably add a spec test that insures that it dies_ok

[perl #122289] [BUG] unexpected behaviour during EVAL()

# New Ticket Created by Kamil Kułaga # Please include the string: [perl #122289] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=122289 Evaling objects won't work if code that eval was preompiled independently

[perl #122255] remove eval

# New Ticket Created by Will Coleda # Please include the string: [perl #122255] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=122255 We tracked the initial spec switch to EVAL, and left eval around to allow folks

[perl #122256] Support EVAL(Buf)

# New Ticket Created by Will Coleda # Please include the string: [perl #122256] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=122256 S29 says that EVAL should work on Buf in addition to Str; There is one test in S29

[perl #102478] [BUG] Attributes can't be declared inside of a BEGIN eval in Rakudo

On Sat Oct 29 13:09:29 2011, masak wrote: moritz nom: class A { eval 'has $.x' }; say A.new(x = 3).x p6eval nom 9c6aed: OUTPUT«===SORRY!===␤A cannot have attributes at line 1, near ␤» moritz nom: class A { BEGIN eval 'has $.x' }; say A.new(x = 3).x p6eval nom 9c6aed: OUTPUT«===SORRY

[perl6/specs] 0b7df0: rename eval to EVAL to indicate specialness

: M S02-bits.pod M S04-control.pod M S05-regex.pod M S06-routines.pod M S11-modules.pod M S12-objects.pod M S29-functions.pod M S32-setting-library/Exception.pod M S99-glossary.pod Log Message: --- rename eval to EVAL to indicate specialness EVAL

[perl6/specs] f252dc: remove eval-level confusion from / $x / and / @x /

: M S05-regex.pod Log Message: --- remove eval-level confusion from / $x / and / @x /

[perl #115774] Presence of an eval causes internal compiler error

On Wed Jan 30 12:20:46 2013, jn...@jnthn.net wrote: On Sat Nov 17 08:50:26 2012, moritz wrote: 17:49 moritz r: my int $a; eval(''); 17:49 +p6eval rakudo 112307: OUTPUT«===SORRY!===␤Lexical '$a' is of wrong register type in lexical lookup␤» Discovered by Woodi++ Now works just fine

[perl #115774] Presence of an eval causes internal compiler error

# New Ticket Created by Moritz Lenz # Please include the string: [perl #115774] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115774 17:49 moritz r: my int $a; eval(''); 17:49 +p6eval rakudo 112307: OUTPUT

[perl #115344] [BUG] method form of eval is lexically challenged

# New Ticket Created by Edwin Steiner # Please include the string: [perl #115344] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115344 While this works perfectly: $ ./perl6 my $x = '1'; eval '$x' 1

[perl #115344] [BUG] method form of eval is lexically challenged

On Thu Oct 18 12:01:02 2012, lithos wrote: spectest added: commit 6d78c06d948179a75b656a220521169f193771b3 Author: Edwin Steiner edwin.stei...@gmx.net Date: Thu Oct 18 20:53:56 2012 +0200 Added spectest for #115344: [BUG] method form of eval is lexically challenged diff --git

[perl #115134] [BUG] BEGIN { eval ... } Confuses Rakudo

# New Ticket Created by Edwin Steiner # Please include the string: [perl #115134] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115134 eval inside a BEGIN block seems to confuse rakudo: $ ./perl6 -e 'BEGIN

[perl #77644] memory leak on eval

On Thu Sep 02 08:37:25 2010, pmichaud wrote: On Thu, Sep 02, 2010 at 11:20:52AM -0400, Will Coleda wrote: Currently each eval() execution results in compiling and loading at least two additional Parrot subs into memory that represent the eval'ed code. �As far as I can tell, once

[perl #112472] [BUG] Null PMC access when doing eval(:lang) in Rakudo

# New Ticket Created by Carl Mäsak # Please include the string: [perl #112472] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112472 jaffa4 r: eval(:langperl5,'1'); p6eval rakudo 442db9: OUTPUT«Null PMC access

[perl6/specs] 536a48: [S04] note one more that eval does not catch exce...

paths: M S04-control.pod Log Message: --- [S04] note one more that eval does not catch exceptions

[perl #102478] [BUG] Attributes can't be declared inside of a BEGIN eval in Rakudo

# New Ticket Created by Carl Mäsak # Please include the string: [perl #102478] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=102478 moritz nom: class A { eval 'has $.x' }; say A.new(x = 3).x p6eval nom 9c6aed

[perl #77646] [BUG] executing the same eval twice without an enclosing block

On Thu Sep 02 03:17:54 2010, smash wrote: IRC log: 11:07 smash rakudo: eval say 1 for 1..4; 11:07 +p6eval rakudo 27d54d: OUTPUT«1␤Null PMC in copy␤ in 'eval' at line 1117:CORE.setting␤ in main program body at line 22:/tmp/kyKDs6lmfi␤» 11:08 smash !? 11:11 moritz_ rakudo: eval 'say 1

[perl #76596] the .perl method for Seq returns a string that eval to a Parcel

10:43 pmichaud I call obsolete. The meaning of Seq and .perl have changed since that ticket was filed. Rejecting ticket; If you can come up with a similar case against modern- day specs, please open a new ticket. Thanks! -- Will Coke Coleda

Re: eval and try should be separate

, Stefan O'Rear stefa...@cox.net wrote: I intend to change the definition of eval such that it does not catch exceptions.  String eval's role as the catcher of exceptions is a legacy of Perl 1, which had no block eval, and I feel it has no place in Perl 6. The exception catching and associated

Re: eval and try should be separate

Given that try can be used with a statement as well as a block, I'm fine with this. We want to discourage people from using eval anyway, so forcing people to use 'try eval' to get p5 behavior is okay too. Larry

[perl6/specs] e84b11: eval() does not catch exceptions

paths: M S29-functions.pod Log Message: --- eval() does not catch exceptions

  1   2   3   >