Re: [svn:perl6-synopsis] r14494 - doc/trunk/design/syn
> BEGIN (right now at compile time) > UNITCHECK (at end of this compilation unit) > CHECK (at end of main compilation) >(compile time finishes) >...time passes... >(run time starts) > INIT > (main starts running) > ENTER (every block entry) > START (first time through only) > LEAVE (every block exit) > (main finishes running) > END > > See S04 for when the other more specialized closure blocks get called. "Code that is generated at run time can still fire off CHECK and INIT blocks, though of course those blocks can't do things that would require travel back in time." Could you specify [at least some examples of] which things would require travel back in time when eval'd?
[perl #50186] [PATCH] range check in Env PMC
# New Ticket Created by Christoph Otto
# Please include the string: [perl #50186]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50186 >
The Env PMC doesn't check whether integer indicies are smaller than the number
of elements. This allows the following PIR code to cause a segfault:
$P0 = new .Env
$S0 = $P0[999]
The patch only affects src/pmc/env.pmc.
Index: src/pmc/env.pmc
===
--- src/pmc/env.pmc (revision 25181)
+++ src/pmc/env.pmc (working copy)
@@ -138,7 +138,7 @@
STRING *get_string_keyed(PMC *key) {
if ((PObj_get_FLAGS(key) & KEY_type_FLAGS) == KEY_integer_FLAG) {
-if (PMC_int_val(key) < 0) {
+if (PMC_int_val(key) < 0 || PMC_int_val(key) >= DYNSELF.elements()) {
return CONST_STRING(interp, "");
}
else {
Re: [PCT] PAST nodes for goto and friends, labels.
On Sat, Jan 19, 2008 at 12:24:37PM +0100, Klaas-Jan Stol wrote:
> as far as I could tell there's no support for goto statements in PCT (that
> is, special nodes or something).
> I don't know whether there are any plans to add special support for it, but
> here's an idea I was thinking about. It would be rather helpful, instead of
> having this handle by each language implementer, by manually generating
> (:inline) statements that result in a label and the relating "goto"/"jump"
> statements; it's a pretty common feature.
>
> Statements like "break", "next", "last", "continue" typically take a label
> as an argument (or it's implicit like for "continue").
You're correct that PCT doesn't have support for 'goto' yet, and
yes, it will. However, the typical model for this is likely to
be based on control exceptions instead of using branches and labels.
To borrow from your example:
> while ($x < 10) {
>$x++;
>next if $x < 5;
>print $x;
> }
In Perl, the { ... } represents a new lexical scope, and in the
general case that means it's a separate Parrot sub with an
:outer flag. Thus when we determine that we need to invoke 'next',
we can't do it with a simple branch, we need to throw an exception
that gets caught by the while loop in the outer Parrot sub and
handled there.
The same is true for labels on the control exceptions, such as
"next LABEL" -- in this case the control exception propagates
outward until it reaches the construct having the corresponding
label.
A similar situation exists for 'return': because it's possible
to invoke a return inside of a nested lexical block, it needs to be
treated as a control exception that can propagate outward through
outer lexical Parrot subs until it reaches the outer block of
the higher-level sub and gets returned from there.
I haven't completely figured out how we'll handle 'goto' statements,
but I'm suspecting it will also need to be based on control
exceptions as opposed to simple PIR branches.
It's possible that some HLLs or situations may warrant optimizing
control statements to use branches instead of control exceptions --
e.g., when the body of a loop isn't a nested lexical block.
But I think we're better off saving that as a later optimization
than trying to resolve it now.
So, the next step on this issue will likely be for PCT to define a
relatively standard interface for its control exceptions, and then
adjust its node types to be able to throw and catch the control
exceptions as appropriate.
Thanks!
Pm
Re: [PCT] PAST nodes for goto and friends, labels.
Sorry if I'm missing something here, since I haven't dived into the innards of Parrot, but I thought control flow in Parrot was based on continuations? Presumably 'control exceptions' are really just lexicaly-scoped exceptions, and exceptions are in turn just outgoing-only continuations. If you have first-class continuations, goto should be pretty straightforward to implement... Given which, since Perl6 also has first-class continuations at the HLL (albeit tucked off where some . . . what was it . . . "benighted pilgrim" won't run into them unexpectedly), goto might be implemented at that level instead, and come into Parrot already translated into continuation-speak (CPS, or not that far into la-la-lambda?)
Re: [PCT] PAST nodes for goto and friends, labels.
On Thu, Jan 24, 2008 at 11:58:02AM -0500, Mark J. Reed wrote:
> Sorry if I'm missing something here, since I haven't dived into the
> innards of Parrot, but I thought control flow in Parrot was based on
> continuations? Presumably 'control exceptions' are really just
> lexicaly-scoped exceptions, and exceptions are in turn just
> outgoing-only continuations. If you have first-class continuations,
> goto should be pretty straightforward to implement...
You're probably correct about this... as I mentioned, I just hadn't
thought about it too heavily yet. At the moment, 'goto' is way
down on the list of things I've been thinking about ('return', 'next',
'last', etc. are much higher).
Pm
Re: [PCT] PAST nodes for goto and friends, labels.
On Jan 24, 2008 9:02 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 11:58:02AM -0500, Mark J. Reed wrote:
> > Sorry if I'm missing something here, since I haven't dived into the
> > innards of Parrot, but I thought control flow in Parrot was based on
> > continuations? Presumably 'control exceptions' are really just
> > lexicaly-scoped exceptions, and exceptions are in turn just
> > outgoing-only continuations. If you have first-class continuations,
> > goto should be pretty straightforward to implement...
>
> You're probably correct about this... as I mentioned, I just hadn't
> thought about it too heavily yet. At the moment, 'goto' is way
> down on the list of things I've been thinking about ('return', 'next',
> 'last', etc. are much higher).
>
and 'warn', which is not an outgoing-only continuation.
~jerry
Re: [PCT] PAST nodes for goto and friends, labels.
In addition to what Patrick said, which is all right on the mark, I'd like to point out a few additional subtleties. Perl borrows an important idea from Lisp and separates the notion of stack unwinding from that of exception handling; when you throw an exception (including a control exception) you look for a handler without unwinding the stack. Only after you have determined which handler handles the exception do you decide what to do with the stack. (Among other things, this lets you treat warnings as merely a resumable form of exception, which lets you use exception handlers to trap warnings propagating outward instead of inventing a separate mechanism for that. Non-destructive control flow also tends to be friendlier to concurrency.) Another things that's going on here is that Perl typically defines the scope of a control exception to be first lexical if possible, and dynamic otherwise. What this comes down to practically is that next LABEL will return from the loop you think it will return from, and not some loop embedded in the call stack that happens to have the same label. But if there is no such label in your lexical outer scope, it goes ahead and looks for it by chasing up the dynamic scopes. Other control forms may suppress the dynamic lookup entirely. For example, return will always return from the lexically surrounding sub or method, and never even try to return from some inner dynamic sub. Because the control flow can in most cases be determined lexically, the compiler can know when the branch target is in the same lexical scope as the branch, and can optimize it to a simple branch if there is no intermediate dynamic scoping that has to be unwound. Even goto prefers a lexically scoped label over a dynamically scoped on. There are two wrinkles for implementing goto the way Perl wants it. First, you have to collect the labels in each lexical scope and store them somewhere (along with their addresses) in case someone wants to goto them from some inner dynamic scope. (You can't just assume goto will come from an inner lexical scope, unless the dynamic scoping is pragmatically suppressed. Likewise a next or last from a dynamic scope could be suppressed.) The other wrinkle is a bit more subtle; for each lexical scope that does not require initialization, you propagate the label set outward to its outer scope, so that you can do a goto into any scope that won't get confused by skipping its initialization (such as into a conditional, or into the next branch of a switch). Throwing a goto exception then mostly just means searching the lexical scopes in the right order for one that knows the label, then transferring the "real" control flow to that lexical scope so that it can dispatch to the address associated with the label. Again, these rules are such that goto (and next and last and return and continue and break) can be optimized to a simple branch when it's known that there's no dynamic interference. One more caveat: since we're in CPS-land, when I say "unwinding the stack", that is of course just shorthand for switching continuations; it's really up to the GC to eventually destroy any unreferenced stack bits. Anyway, just trying to get everyone thinking the same things when we use terms that could be misunderstood for historical reasons. Perl 6 exceptions have very little resemblance to Perl 5 exceptions, so it's easy to get muddled in terms. Larry
Re: [perl #41508] [BUG] Configure losing flags...
On Jan 23, 2008 11:15 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Wed Feb 14 09:09:14 2007, coke wrote:
> > Trying to build with GMP support on OSX intel. I have libgmp in
> > /opt/local/bin/
> >
> > if I run:
> >
> > CC="ccache gcc-4.0"
> > CX="ccache g++-4.0"
> > perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" --ld="$CX"
> > --ccflags="-L/opt/local/lib -I/opt/local/include"
> > --ldflags="-L/opt/local/lib" --step=auto::gmp --verbose=auto:gmp
> >
>
> Coke: I happened to re-read the first post to this ticket, now nearly a
> year old. I want to make sure that you're *not* calling Configure.pl
> these days in the manner above.
Yes, I noticed that it didn't work, so I stopped that.
Part of the original ticket was that running the step by itself seemed
to work, but running it as part of the whole failed; so it seemed that
something that happened in Config land before the GMP step was
throwing out something crucial.
>The --step option is now only used with
> tools/dev/reconfigure.pl; it's used when you want to rerun just one
> config step after Configure.pl has completed. Also, if you want to run
> a particular step with verbose output, the phrasing is now:
> --verbose-step=auto::gmp.
Here's my current Config script:
CCACHE="ccache "
CC="${CCACHE}gcc-4.0"
CX="${CCACHE}g++-4.0"
perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" --ld="$CX"
--ccflags="-L/opt/local/lib -I/opt/local/include"
--ldflags="-L/opt/local/lib" --verbose-step=auto::gmp $@
Running this step verbosely shows as the attached. Notice that the
flags that I specified on the command line for Configure for
cclflags/ldflags are missing, so the build fails, and GMP is reported
as not available.
> Does that clear up any of your problems?
I think this helps verify my original claim, but how to address it?
--
Will "Coke" Coleda
config.out
Description: Binary data
Re: Definition of Order in S29
Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? Joe Gottman The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. =thom -- I wanna hang a map of the world in my house. Then I'm gonna put pins into all the locations that I've traveled to. But first, I'm gonna have to travel to the top two corners of the map so it won't fall down. -- Mitch Hedberg
[perl #50212] Configure step fails on Windows
# New Ticket Created by Alan Rocker # Please include the string: [perl #50212] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50212 > Using the "Strawberry Perl" installed on Windows XP resulted in the following failure output from the Configure step: Determining if your platform supports GMP...Can't spawn ".\test.exe": Bad file descriptor at lib/Parrot/Configure/Utils.pm line 85. no. (Windows wanted to 'phone home about test.exe too.) Might there be some obscure connection with [perl #41508] [BUG] Configure losing flags... ? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: Definition of Order in S29
At 11:37 AM -0700 1/24/08, Thom Boyer wrote: Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. Thom, I don't think you understood Joe's more obvious question. AFAIK, the Order values are supposed to numify like this: Order::Increase -> -1 Order::Same -> 0 Order::Decrease -> +1 The above quoted text shows the numify in the order [-1,0,1], but the Order values are not in the corresponding sequence. To fix the problem, the S29 text should probably say: returns |Order::Increase|, |Order::Same|, or |Order::Decrease| (which numify to -1, 0, +1) That way, reading the S29 text makes more sense. This is, I believe, what Joe was pointing out needed to be fixed. -- Darren Duncan
[perl #50218] Uninitialized svk install hangs postconfig/03-revision.t and Parrot::Revision usage
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #50218] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50218 > Hope this is helpful - I haven't been able to solve this but 03-revision.t and 04-revison.t in postconfigure both use Parrot::Revision and $Parrot::Revision::current. To get that value Parrot::Revision sub _analyze_sandbox tries an "info" command via svn, git and then svk, one after the other, to check for a findable revision number, as they fail, that is; if there's no revision number available, all 3 are tried. If you have svk installed but never been used, svk comes up and asks (via Term::ReadKey) if you want to create the ~/.svk/local repository. However, during make test, you don't see this output and the test appears hung (you can type an 'n' to go on). I've made this happen on linux; Red Hat and Ubuntu and Mac Leopard (rev 25207). Due to the way svk and Term::ReadKey work, I can't find a way to redirect an answer (e.g. svk info <<<'n' etc.) as that crashes svk (Term::ReadKey::GetControlChars fails) w/o running the "info" cmd. svk checks for a couple ENV vars and then builds the path for the local rep to look for, so we could test that, but I gather that's more mucking w/ the internals than you want Revision.pm to do. On the other hand, there may be a way to require the appropriate SVK modules and try the 'info' command w/o needing the 'local' rep. Or maybe not. a Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] VOICE: (608) 261-5738 FAX 264-5932 "The Microsoft Exchange Information Store service depends on the Microsoft Exchange Directory service which failed to start because of the following error: The operation completed successfully." (actual MSE error msg)
Re: Definition of Order in S29
On 2008-01-24 Thom Boyer <[EMAIL PROTECTED]> wrote: > Joe Gottman wrote: > > In the definition of cmp, S29 says the function "returns > > |Order::Increase|, |Order::Decrease|, or |Order::Same| (which > > numify to -1, 0, +1)". Shouldn't the enumerations and their > > numerical values be listed in the same order? > > > > Joe Gottman > The enumerations and the numerical values are both in correct order. > Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked > with its arguments in increasing order, So it returns > Order::Increase. That numifies to -1 because that's how "less-than" > is usually encoded. Correct about Increase. But would ::Decrease numify to 0, and ::Same to +1? :) -- Dakkar - GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 That's one small step for a man; one giant leap for mankind. -- Neil Armstrong signature.asc Description: PGP signature
[perl #50216] [PATCH] Add approx() function to perl6 Test.pm library
# New Ticket Created by Cosimo Streppone
# Please include the string: [perl #50216]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50216 >
Recently I've been working on the perl6 test suite
that lives in pugs/t/spec repository.
Several test scripts in the "math" category use
an `approx()' function to compare two floating point
numbers with approximation, but they defined it
every time in each test script.
So I wrote and tested this patch against r24953
which adds approx() to languages/perl6/Test.pm.
--
Cosimo
Index: Test.pm
===
--- Test.pm (revisione 24953)
+++ Test.pm (copia locale)
@@ -17,6 +17,13 @@
## test functions
+# Compare numeric values with approximation
+sub approx ($x, $y) {
+my $epsilon = 0.0001;
+my $diff = abs($x - $y);
+($diff < $epsilon);
+}
+
sub plan($number_of_tests) {
$testing_started = 1;
$num_of_tests_planned = $number_of_tests;
[perl #50214] Maybe not a bug, but....
# New Ticket Created by Alan Rocker # Please include the string: [perl #50214] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50214 > Using the "Strawberry Perl" on Windows XP to install Parrot resulted in the attached warnings output from the make step. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #50220] patch implementing get_string for rakudo junctions
# New Ticket Created by Zach Morgan
# Please include the string: [perl #50220]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50220 >
severity: medium
category: languages
hello, all. Attached (hopefully) is a patch to implement get_string for
perl6's junctions. I looked in synopsis 9 and saw nothing about any
get_string, so I decided on the simplest, most straightforward approach.
Admittedly, I don't know enough about junctions to say for certain whether
this will actually be used. Should say 4&5 call say for both 4 and 5 or just
once for the junction? At the moment however, it looks for get_string for
the junction type. I suspect that it will at least aid in debugging, at the
very least.
Zach Morgan
Index: languages/perl6/src/classes/Junction.pir
===
--- languages/perl6/src/classes/Junction.pir (revision 25207)
+++ languages/perl6/src/classes/Junction.pir (working copy)
@@ -27,6 +27,47 @@
.end
+=item get_string()(vtable method)
+
+Return the elements of the junction joined by commas, identified by junction type.
+
+=cut
+
+.sub 'get_string' :vtable :method
+
+# Now go by juction type.
+.local int type
+.local pmc values
+.local string res
+.local string tmp
+type = self.'!type'()
+if type == JUNCTION_TYPE_ALL goto all
+if type == JUNCTION_TYPE_ANY goto any
+if type == JUNCTION_TYPE_ONE goto one
+if type == JUNCTION_TYPE_NONE goto none
+
+all:
+res = 'all'
+goto okay
+any:
+res = 'any'
+goto okay
+one:
+res = 'one'
+goto okay
+none:
+res = 'none'
+goto okay
+okay:
+values = self.'values'()
+tmp = join ',', values
+concat res, '('
+concat res, tmp
+concat res, ')'
+.return (res)
+.end
+
+
=item values()
Get the values in the junction.
Re: [perl #50220] patch implementing get_string for rakudo junctions
Hi, Zach Morgan (via RT) wrote: hello, all. Attached (hopefully) is a patch to implement get_string for perl6's junctions. I looked in synopsis 9 and saw nothing about any get_string, so I decided on the simplest, most straightforward approach. That looks to me more like an implementation of the .perl method, not the get_string vtable method. So it's the Right Thing, for the Wrong Thing. ;-) If you change: .sub 'get_string' :vtable :method To: .sub 'perl' :method Then that would appear to be a useful patch, which I'll be happy to apply with that change (don't bother sending a replacement). Also, I probably won't get to applying this until after the weekend, since I'm heading to Madrid tomorrow and need to sleep now. Should say 4&5 call say for both 4 and 5 or just once for the junction? For both 4 and 5. At the moment however, it looks for get_string for the junction type. I suspect that it will at least aid in debugging, at the very least. The .perl method on Junctions will certainly aid debugging, and is good to have. So thanks, and I'll do the tweak and apply this shortly. Take care, Jonathan
[perl #50216] [PATCH] Add approx() function to perl6 Test.pm library
On Thu Jan 24 14:28:29 2008, cosimo wrote: > On Gio. 24 Gen. 2008 14:13:20, cosimo wrote: > > > So I wrote and tested this patch against r24953 > > > which adds approx() to languages/perl6/Test.pm. > > > > Applies also for r25206. > > Extended to provide also a `is_approx()'. > This is also more convincing and consistent to me. > Patch revised. Thanks, applied by TimToady in r25207
[perl #50218] Uninitialized svk install hangs postconfig/03-revision.t and Parrot::Revision usage
Some data questions: 1. Are you working from a checkout from the repository or from a Parrot monthly release tarball? 2. If the former, which VCS did you use to make the checkout? (By implication, which VCS do you expect to be exercised in _analyze_sandbox()?) I ask because if you are working from a tarball, Parrot::Revision::_get_revision() should never be triggered -- though the code to preclude that triggering I've now removed from the module itself and placed in its various callers. I may have missed one of the callers. kid51
[perl #50212] Configure step fails on Windows
On Thu Jan 24 12:52:34 2008, ajr wrote: > Using the "Strawberry Perl" installed on Windows XP resulted in the > following failure output from the Configure step: > > Determining if your platform supports GMP...Can't spawn ".\test.exe": Bad > file descriptor at lib/Parrot/Configure/Utils.pm line 85. > no. > (1) Do you know whether you actually have GMP on this box? (2) What results do you get if you configure without GMP? perl Configure.pl --without-gmp ... or, for good measure, with verbose output on that step: perl Configure.pl --without-gmp --verbose-step=auto::gmp kid51
Re: [perl #50212] Configure step fails on Windows
Hi, Alan! What kind of CPU do you have? If you have an AMD Athlon XP
(or something of similar lineage), I think I know what the problem is.
On Thu, 24 Jan 2008 12:52:35 -0800
Alan Rocker (via RT) <[EMAIL PROTECTED]> wrote:
> Determining if your platform supports GMP...Can't spawn ".\test.exe":
> Bad file descriptor at lib/Parrot/Configure/Utils.pm line 85.
> no.
>
> (Windows wanted to 'phone home about test.exe too.)
Yeah, I get that on Strawberry Perl too. It surprised me, and it
pauses the configure process until you click "Don't send report".
> Might there be some obscure connection with
> [perl #41508] [BUG] Configure losing flags... ?
Nah, I think the test app just broke for whatever reason. The mingw32
environment packaged with Strawberry Perl does include a libgmp.a and
libgmp.la, so the test app was built properly, but failed to run.
I reproduced it by copying config/auto/gmp/gmp.in to gmp.c, and
compiling with:
> gcc -O2 -Wall -g -ggdb -o gmp.exe gmp.c -lgmp
The resulting gmp.exe crashes and Windows prompts if I want to send an
error report to microsoft.com.
I poked around a bit with gdb, and discovered its barfing on an SSE2
instruction ("pmuludq") in libgmp.a (at __gmpn_divrem_1+266), which my
CPU (an athlon XP) can't handle. So I'm going to ask the Strawberry
Perl guy about this.
For the record, here's what GDB says:
Program received signal SIGILL, Illegal instruction.
0x00405aaa in __gmpn_divrem_1 ()
(gdb) bt
#0 0x00405aaa in __gmpn_divrem_1 ()
#1 0x00401ae8 in mpn_sb_get_str ()
#2 0x0001 in ?? ()
#3 0x003d2680 in ?? ()
#4 0x0022fc1b in ?? ()
#5 0x0011 in ?? ()
#6 0x12e0be82 in ?? ()
#7 0x0002 in ?? ()
#8 0x003d in ?? ()
#9 0x4161 in ?? ()
#10 0x7c91056d in ntdll!RtlFreeThreadActivationContextStack ()
from C:\WINDOWS\system32\ntdll.dll
#11 0x in ?? ()
And the relevant disassembly:
0x00405aa4 <__gmpn_divrem_1+260>: paddd %mm0,%mm2
0x00405aa7 <__gmpn_divrem_1+263>: punpckldq %mm0,%mm1
0x00405aaa <__gmpn_divrem_1+266>: pmuludq %mm4,%mm2
0x00405aad <__gmpn_divrem_1+269>: paddq %mm2,%mm1
0x00405ab0 <__gmpn_divrem_1+272>: pxor %mm2,%mm2
Mark
Re: [perl #41508] [BUG] Configure losing flags...
> On Thu Jan 24 10:31:46 2008, coke wrote:
>
> >
> > Here's my current Config script:
> >
> > CCACHE="ccache "
> > CC="${CCACHE}gcc-4.0"
> > CX="${CCACHE}g++-4.0"
> > perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" --ld="$CX"
> > --ccflags="-L/opt/local/lib -I/opt/local/include"
> > --ldflags="-L/opt/local/lib" --verbose-step=auto::gmp $@
> >
> > Running this step verbosely shows as the attached. Notice that the
> > flags that I specified on the command line for Configure for
> > cclflags/ldflags are missing, so the build fails, and GMP is reported
> > as not available.
This sounds like a problem in the hints file. I don't know what platform
this is, but I'd look in the hints file to see if it unconditionally
sets ccflags and ldflags without checking the command line options.
On Thu, 24 Jan 2008, James Keenan via RT wrote:
> *without* GMP on Darwin. Here's my regular script (with configuration
> step tests):
>
> #!/bin/sh
> CC="/usr/bin/gcc-3.3"
> CX="/usr/bin/g++-3.3"
> /usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
> --ld="$CX" --without-icu --without-gmp \
> --test \
> --configure_trace \
> $@
Note that this test doesn't try setting ccflags or ldflags, so it is
irrelevant to the problem at hand.
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #50218] Uninitialized svk install hangs postconfig/03-revision.t and Parrot::Revision usage
On Thu, 24 Jan 2008, James Keenan via RT wrote: > Some data questions: > > 1. Are you working from a checkout from the repository or from a Parrot > monthly release tarball? > > 2. If the former, which VCS did you use to make the checkout? (By > implication, which VCS do you expect to be exercised in _analyze_sandbox()?) Note that it's also easily possible to do neither of these. When it works, I usually use rsync to fetch the source. Other times, I have used svn on one computer to check out the source, and exported the source via NSF. Then I can build on other systems that don't have any version control system available. Of course the version control checks fail in such cases, but I usually just ignore them. -- Andy Dougherty [EMAIL PROTECTED]
[perl #41508] [BUG] Configure losing flags...
On Thu Jan 24 17:43:06 2008, doughera wrote:
>
> This sounds like a problem in the hints file. I don't know what platform
> this is, but I'd look in the hints file to see if it unconditionally
> sets ccflags and ldflags without checking the command line options.
>
It's Darwin, whose hints file does indeed make no check of command-line
options. By analogy with the hints files for Linux and Win32, I propose
the patch attached: hints.darwin.patch.txt
>
> Note that this test doesn't try setting ccflags or ldflags, so it is
> irrelevant to the problem at hand.
>
True enough. So since I don't try setting the flags, the most I can
prove is that checking them with option_or_data() in init::hints::darwin
does no harm. Coke will have to try it and see if it actually benefits him.
Index: config/init/hints/darwin.pm
===
--- config/init/hints/darwin.pm (revision 25207)
+++ config/init/hints/darwin.pm (working copy)
@@ -9,7 +9,10 @@
sub runstep {
my ( $self, $conf ) = @_;
-my ( $ccflags, $ldflags, $libs ) = $conf->data->get(qw(ccflags ldflags
libs));
+#my ( $ccflags, $ldflags, $libs ) = $conf->data->get(qw(ccflags ldflags
libs));
+my $ccflags = $conf->option_or_data( 'ccflags' );
+my $ldflags = $conf->option_or_data( 'ldflags' );
+my $libs = $conf->option_or_data( 'libs' );
my $OSVers = `uname -r`;
chomp $OSVers;
[perl #50212] Configure step fails on Windows
On Thu Jan 24 17:38:33 2008, [EMAIL PROTECTED] wrote: > > Yeah, I get that on Strawberry Perl too. It surprised me, and it > pauses the configure process until you click "Don't send report". > > > > Might there be some obscure connection with > > [perl #41508] [BUG] Configure losing flags... ? > > Nah, I think the test app just broke for whatever reason. The mingw32 > environment packaged with Strawberry Perl does include a libgmp.a and > libgmp.la, so the test app was built properly, but failed to run. > > I reproduced it by copying config/auto/gmp/gmp.in to gmp.c, and > compiling with: > > > gcc -O2 -Wall -g -ggdb -o gmp.exe gmp.c -lgmp > [snip] A very good research effort on such short notice! Thanks.
Re: Definition of Order in S29
Thom Boyer wrote:
> The enumerations and the numerical values are both in correct order.
> Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with
> its arguments in increasing order, So it returns Order::Increase. That
> numifies to -1 because that's how "less-than" is usually encoded.
Others have pointed out Joe's actual intent in asking the question; so
I won't belabor the point.
Instead, I'll say that the idea that Order::Increase numifies to -1 is
going to take some getting used to. While I understand the reasoning
behind it, my intuition would have been to numify it to +1 for an
increase and -1 for a decrease.
If C<"abc" cmp "xyz"> must numify to -1, could we please choose
something like 'Order::Before' and 'Order::After' instead of
'Order::Increase' and 'Order::Decrease'? Not only does this make more
intuitive sense, but it also pairs the Order values more closely with
the type-neutral comparison operators ('before' and 'after').
(Which brings up another point, which I'll freely admit I'm too lazy
to look up at the moment: do we already have a type-neutral operator
that corresponds to 'Order::Same'? I suspect that '===' is it; but my
grasp of the plethora of equivalence operators is somewhat shaky. If
not - and possibly even if so, depending on which paradigm is the most
important one to reinforce - I might recommend using 'same' to
complete the 'before'/'after' set of operators.)
--
Jonathan "Dataweaver" Lang
Re: Definition of Order in S29
At 7:20 PM -0800 1/24/08, Jonathan Lang wrote:
Instead, I'll say that the idea that Order::Increase numifies to -1 is
going to take some getting used to. While I understand the reasoning
behind it, my intuition would have been to numify it to +1 for an
increase and -1 for a decrease.
I don't see this as being a problem since I expect very few users
deal directly with the numbers anyway, and they're just a background
implementation and/or legacy detail.
The main place I would understand the actual numbers having any
semantic effect is if you want to chain comparators such as "$^a.foo
<=> $^b.foo or $^a.bar <=> $^b.bar" (I may have spelled wrong), sort
first by .foo then by .bar; that's counting on the result boolifying
to false when the 2 comparands are equal, and boolifying to true when
not; this isn't different in your suggestion vs otherwise.
So I recommend not changing this.
If C<"abc" cmp "xyz"> must numify to -1, could we please choose
something like 'Order::Before' and 'Order::After' instead of
'Order::Increase' and 'Order::Decrease'? Not only does this make more
intuitive sense, but it also pairs the Order values more closely with
the type-neutral comparison operators ('before' and 'after').
By contrast, at least looking at Order on its own, I think
Increase|Decrease works better than Before|After. Part of the reason
is that the first 2 work well for both prefix and infix notations,
while the second 2 just work for infix. Take for example "there is
an increase from foo to bar" or "foo increases to become bar", versus
"foo is before bar". At least this aspect is a preference of mine,
as I prefer standardizing on prefix notation for all routine/operator
calls where possible. Still, I suppose I may not complain too loudly
if the change you suggest was made.
I'd be more interested in hearing what precedents if any exist in
this regard. What do other languages call the same concepts?
-- Darren Duncan
Re: Definition of Order in S29
On Jan 24, 2008, at 23:23 , Darren Duncan wrote: I'd be more interested in hearing what precedents if any exist in this regard. What do other languages call the same concepts? data Ord = LT | EQ | GT -- Haskell -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: [PCT] PAST nodes for goto and friends, labels.
From: Larry Wall <[EMAIL PROTECTED]> Date: Thu, 24 Jan 2008 09:52:16 -0800 In addition to what Patrick said, which is all right on the mark, I'd like to point out a few additional subtleties. Perl borrows an important idea from Lisp and separates the notion of stack unwinding from that of exception handling; when you throw an exception (including a control exception) you look for a handler without unwinding the stack. Only after you have determined which handler handles the exception do you decide what to do with the stack. (Among other things, this lets you treat warnings as merely a resumable form of exception, which lets you use exception handlers to trap warnings propagating outward instead of inventing a separate mechanism for that. Non-destructive control flow also tends to be friendlier to concurrency.) One of those other things (which I hope you don't mind me adding) is that search-before-unwind also supports default exception handlers with an elegantly simple idiom: In the default handler, resignal the error; if it returns, it's all yours. The "Default Handling" section of [1] has a fuller explanation in the context of Lisp dialects and their influences. -- Bob Rogers http://rgrjr.dyndns.org/ [1] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
Re: [svn:parrot] r25208 - trunk/src
On Thursday 24 January 2008 19:11:37 [EMAIL PROTECTED] wrote: > Author: petdance > Date: Thu Jan 24 19:11:36 2008 > New Revision: 25208 > > Modified: >trunk/src/exceptions.c > > Log: > Added missing break to switch statement (!!!). Added checks for NULL > pointers > --- trunk/src/exceptions.c(original) > +++ trunk/src/exceptions.cThu Jan 24 19:11:36 2008 > @@ -664,8 +666,10 @@ > case PARROT_CGP_CORE: > case PARROT_CGP_JIT_CORE: > offset = dest - (const opcode_t *)interp->code->prederef.code; > +break; > default: > offset = dest - interp->code->base.data; > +break; > } > return offset; > } Did you test this with make testC and make testj? I seem to recall removing a break to fix one of these cores in a similar situation several months ago. -- c
