Re: split on empty string

[Jonathan Scott Duff]

On Tue, Jan 17, 2006 at 12:35:57PM -0500, Mark Reed wrote:
> On 2006-01-17 12:24 PM, "Gaal Yahas" <[EMAIL PROTECTED]> wrote:
> 
> > While cleaning up tests for release:
> > 
> > "".split(':')=>
> > 
> >()# Perl 5
> >("",) # pugs
> > 
> > Which is correct? It doesn's seem to be specced yet.
> 
> I would prefer the current pugs behavior; it's consistent with the general
> case, in which a string which does not match the splitting regex results in
> a single-item list containing the original string.  This is the Python
> behavior.
> 
> I find the Perl5 (and, surprisingly, Ruby) behavior rather counterintuitive.

FWIW, I agree with Mark.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

[perl #38260] [BUG] Parrot::Config contains invalid info

[via RT]

# New Ticket Created by  jerry gay 
# Please include the string:  [perl #38260]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38260 >


attached is my lib/Parrot/Config.pm file generated from r11223, on
windows using msvc. inside you'll find a few things, like keys given
unix file path values,
 'bin_dir' => '/usr/local/bin',

an invalid key,
 'Parrot::Configure::Data=HASH(0x193a650)' => '   ',

and unexpanded values,
 'libparrot' => '$(LIBPARROT_STATIC)',
 'libparrot_ldflags' => '$(LIBPARROT_STATIC)',
 'libparrot_shared' => 'libparrot$(SHARE_EXT)',


these should be fixed as appropriate.
~jerry

[perl #38261] Re: [PATCH] struct Parrot_Context doesn't need a 'prev' field.

[via RT]

# New Ticket Created by  Matt Fowles 
# Please include the string:  [perl #38261]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38261 >


Bob~

On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Jan 14, 2006, at 21:28, Bob Rogers wrote:
>
> >I had thought this field was being used, but it turns out to be
> > irrelevant.  I offer this patch so that no one else is fooled (and
> > because I had to test it anyway to prove that this is the case).
>
> Thanks, applied - r11199

Why leave it in as a placeholder at all?

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

[perl #38264] Bug in compute_dominance_frontiers?

[via RT]

# New Ticket Created by  Bob Rogers 
# Please include the string:  [perl #38264]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38264 >


   The attached code compiles to byte code OK in r11235, until you
comment out the push_eh indicated by the patch, which makes
compute_dominance_frontiers take forever.  (Sorry; I wish I had time to
try to make it smaller.)  TIA,

-- Bob Rogers
   http://rgrjr.dyndns.org/


## Eval, apply, and all that.
##
## [created.  -- rgr, 10-Jan-05.]
##
## $Id: toy-lisp.imc,v 1.68 2005/12/28 15:56:15 rogers Exp $
##
## To do:
##
##   Support package-use-list, exported vs. internal symbols, use to
## print symbol package prefixes correctly.  [done.  -- rgr, 4-Feb-05.]
##
##   ** Escaping lowercase symbol and package names.
##
##   Define simple conditional special forms (if, cond, and, or).  [done.  --
## rgr, 6-Mar-05.]
##
##   ** Add more arithmetic and list functions.
##
##   ** Read #-macros.  [e.g. #';  can't read "(* (reduce #'foo bar) 3)"
## without #-macros; must do "(* (reduce (function foo) bar) 3)" instead.
## -- rgr, 30-Jan-05.]
##
##   * Read backquote.
##

### Higher-level stuff for symbols and packages.

.namespace ["ParrotCL::Common_Lisp"]

## Define the NIL symbol.  It will get stuffed into the COMMON-LISP package
## later (since we need NIL to create the package).
.sub _symbol_setup
.local pmc nil
nil = new Undef
## Store something in these now so that symbol creation/interning work.
store_global "ParrotCL::Common_Lisp", "NIL", nil
store_global "ParrotCL::Common_Lisp", "keyword_package", nil
$P30 = new PerlHash
$P1 = new String
$P1 = "NIL"
$P30["NAME"] = $P1
find_type $I0, "ParrotCL::Common_Lisp::Symbol"
nil = new $I0, $P30
nil."_set_symbol_value"(nil)
## nil."_set_property_list"(nil)
store_global "ParrotCL::Common_Lisp", "NIL", nil
.end

.namespace ["ParrotCL::Common_Lisp::Symbol"]

## This is mostly for debugging.
.sub __get_string method
.local string result
result = self."symbol_name"()
.return (result)
.end

.namespace ["ParrotCL::Common_Lisp::Package"]

## [bug:  this must also search nicknames.  -- rgr, 19-Jan-05.]
.sub package_name_equalp method
.param pmc package_name
.local pmc name
.local pmc tail
.local int result

name = self."package__name"()
result = iseq name, package_name

.return (result)
.end

.sub print_object method
.local pmc package_name
print "#"
.end

.sub _make_symbol
.param pmc pname
.local pmc sym

## create a new symbol.
$P30 = new PerlHash
$P30["NAME"] = pname
find_type $I0, "ParrotCL::Common_Lisp::Symbol"
sym = new $I0, $P30

.return (sym)
.end

.sub _package_intern method
.param pmc symbol_or_name

.local pmc nil
.local int base
classoffset base, self, "ParrotCL::Common_Lisp::Package"
nil = find_global "ParrotCL::Common_Lisp", "NIL"

.local pmc symbol_name
.local pmc sym
.local int symbolp

symbolp = isa symbol_or_name, "ParrotCL::Common_Lisp::Symbol"
if symbolp goto intern_symbol
symbol_name = symbol_or_name
goto intern_thing
intern_symbol:
symbol_name = symbol_or_name."symbol_name"()

intern_thing:
.local pmc hash
hash = self."package_external_symbols"()
sym = hash[symbol_name]
defined $I0, sym
if $I0 goto intern_ret
hash = self."package_internal_symbols"()
sym = hash[symbol_name]
defined $I0, sym
if $I0 goto intern_ret

## add a new symbol.
if symbolp goto intern_have_sym
## make a new symbol.
$P0 = new String
set $P0, symbol_name
sym = _make_symbol($P0)
goto intern_stuff_sym
intern_have_sym:
sym = symbol_or_name
intern_stuff_sym:
## update symbol_package.
sym."_set_symbol_package"(self)
## see if we need to export and hack the value for keywords.
.local pmc keyword_package
keyword_package = find_global "ParrotCL::Common_Lisp", "keyword_package"
ne_addr self, keyword_package, intern_not_kwd
sym."_set_symbol_value"(sym)
hash = self."package_external_symbols"()
intern_not_kwd:
$I34 = isa sym, "ParrotCL::Common_Lisp::Symbol"
if $I34 goto intern_normal
print "[intern of non-symbol '"
_print(sym)
print "'.]\n"
die 5, 1
intern_normal:
hash[symbol_name] = sym
intern_ret:
.return (sym)
.end

.sub _package_export method
.param pmc symbol

.local pmc ext_hash
.local pmc int_hash
.local pmc symbol_name
symbol_name = symbol."s

[perl #38263] Re: [PATCH] struct Parrot_Context doesn't need a 'prev' field.

[via RT]

# New Ticket Created by  Bob Rogers 
# Please include the string:  [perl #38263]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38263 >


   From: Matt Fowles <[EMAIL PROTECTED]>
   Date: Tue, 17 Jan 2006 16:29:55 -0500

   Bob~

   On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
   >
   > On Jan 14, 2006, at 21:28, Bob Rogers wrote:
   >
   > >I had thought this field was being used, but it turns out to be
   > > irrelevant.  I offer this patch so that no one else is fooled (and
   > > because I had to test it anyway to prove that this is the case).
   >
   > Thanks, applied - r11199

   Why leave it in as a placeholder at all?

   Matt

Good question.  I did so because of the "common header with
Interp_Context" comment in struct Parrot_Context.  It didn't seem to be
vestigial, and in any case I wasn't sure how to test that, so I left it
alone.

-- Bob

[perl #38262] get external modules out of the parrot repo

[via RT]

# New Ticket Created by  jerry gay 
# Please include the string:  [perl #38262]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38262 >


perl modules necessary for parrot configuration, development, and
testing have been either committed to the parrot repo, assumed to be
installed by the user, or (in some cases) checked for in code that
uses them.

this mish-mash is causing confusion for developers, testers, and end
users of parrot. all of them are left asking the same question, "what
external modules do i need to use parrot?"

we should have a better answer than "run it and see."

i think that better answer should be in the form of CPAN bundles. a
development bundle (Bundle::Parrot::Devel), a test bundle (::Test),
perhaps a seperate smoke bundle (::Smoke), and perhaps a bundle for
end users (::Install.)

installation of the necessary modules should be checked at configure
time, and an informative message should be given to the user if there
are missing dependencies.

i'm sure i've left things out, so please fill in details where you
deem appropriate. the sooner this task is specified and implemented,
the easier it will be for others to use/develop/test parrot.

~jerry

Re: Indeterminate forms for the Num type.

[Darren Duncan]

At 9:50 AM +0800 1/18/06, Audrey Tang wrote:

However, I think one of P6's idea is that the user should not have
to care between 0 and 0.0's behaviours, so maybe it makes sense to
do the same thing (be it NaN or exception) both ways.

I'm not sure that IEEE 754/854 still applies if we want to merge the
behaviours of int/num/complex/bigint/bigrat/bignum under a Num banner.

(There is always the worse-is-better option of going with whatever
the underlying runtime does, usually determined by hardware/libm.)


I think the best situation is that, at least with boxed types like 
Num, behaviour should be well defined, user friendly, and identical 
everywhere Perl 6 runs.  There's no good reason to have different 
behaviour on different platforms; that allows implementation to leak 
through to the user when the user shouldn't have to know.  And its 
also a very good source of bugs.  Leave different behaviours to 
things that are explicitly connections to external resources, where 
it is reasonable for them to change.


As for unboxed types, I'm on the fence here, but you should probably 
let the implementation show through here, to an extent, since 
presumably the point of using unboxed types is to get bleeding edge 
maximum performance, and abstraction would take away from this then, 
maybe.  Or maybe not.  But if anything bleeds through, it should be 
the hardware, and not other programming languages.


-- Darren Duncan

Re: [PATCH] struct Parrot_Context doesn't need a 'prev' field.

[Bob Rogers]

   From: Matt Fowles <[EMAIL PROTECTED]>
   Date: Tue, 17 Jan 2006 16:29:55 -0500

   Bob~

   On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
   >
   > On Jan 14, 2006, at 21:28, Bob Rogers wrote:
   >
   > >I had thought this field was being used, but it turns out to be
   > > irrelevant.  I offer this patch so that no one else is fooled (and
   > > because I had to test it anyway to prove that this is the case).
   >
   > Thanks, applied - r11199

   Why leave it in as a placeholder at all?

   Matt

Good question.  I did so because of the "common header with
Interp_Context" comment in struct Parrot_Context.  It didn't seem to be
vestigial, and in any case I wasn't sure how to test that, so I left it
alone.

-- Bob

Re: punie.g observation

[Allison Randal]

On Jan 17, 2006, at 18:01, Andrew Rodland wrote:


Doesn't that imply that "print print print print 1;" is a valid Punie
program?  Is that intentional?  It seems to me that the gprint rule
should instead contain "cexpr":
   rule gprint  { (print) \s*  }


"print print print print 1;"  is certainly a valid Perl 5 program;  
it prints a
1 followed by 3 other things (which are defined to be true, and  
which happen
to also be the number 1). Digging on retroperl.cpan.org shows that  
it did

exactly the same thing on perl 1.0.0. So to answer your question, it's
probably intentional :)


Yup, that part of the punie grammar is pretty direct translation of  
the original perl.y.


Allison

Re: Indeterminate forms for the Num type.

[Audrey Tang]

Audrey Tang wrote:
> That seems to follow from the standard (ruby, ocaml, mzscheme currently
> does that), but some may also argue for NaN bothways (ghc, js) or an
> exception bothways (perl5, python).

Er, wait, ghc also raises an exception for (div 0 0), because it
distinguishes integer (div) with fractional (/).

However, I think one of P6's idea is that the user should not have
to care between 0 and 0.0's behaviours, so maybe it makes sense to
do the same thing (be it NaN or exception) both ways.

I'm not sure that IEEE 754/854 still applies if we want to merge the
behaviours of int/num/complex/bigint/bigrat/bignum under a Num banner.

(There is always the worse-is-better option of going with whatever
the underlying runtime does, usually determined by hardware/libm.)

Audrey



signature.asc
Description: OpenPGP digital signature

Re: how to detect that we're running under CPAN::Testers?

[Adam Kennedy]

OK, I'll make sure there's some level of tagging about that in the reports.

Adam K

Barbie wrote:

On Tue, Jan 17, 2006 at 06:06:50AM +1100, Adam Kennedy wrote:
At the moment all our output is structured XML files, so at some point I 
need to write an XSL to translate it back down into something CPAN 
Testers can deal with, and I can add whatever you want me to at that time.


Do you want the tag saying it's PITA-XSL-generated content, or the owner 
of the testing system? (because I imagine we'll end up with a number of 
those)


The fact that the report is generated using PITA. For me personally it
would be interesting to see where reports are generated from. At the
moment it's difficult to know which reports are manually produced.

There are several reports still that are getting misfiled, as it either
doesn't include the version number of the distribution or other
attributes are missing. It makes it easier to spot which mechanisms for
testing and reporting are getting it wrong, if the automated apps tag
the report.

Barbie.

Re: punie.g observation

[chromatic]

On Tuesday 17 January 2006 15:01, Andrew Rodland wrote:

> "print print print print 1;"  is certainly a valid Perl 5 program; it
> prints a 1 followed by 3 other things (which are defined to be true, and
> which happen to also be the number 1).

Nit: print doesn't *always* return a true value.  It's a system call.  It can 
fail.

At least, that's how Punie should eventually handle it, if it doesn't yet.

-- c

Re: Indeterminate forms for the Num type.

[Audrey Tang]

Luke Palmer wrote:
> I believe we've been through this before.  We go with a standard,
> probably IEEE, horridly mathematically unappealing though it may be.
> It will be easier to implement and it will be more predictable, both
> because most other language follow standards, too.

"The good thing about standards is that there are so many to choose
from".  Which IEEE standard are we following?  754-1985? 854-1987?
754r-2006 (still under discussion)?

Also, would you be happy with different treatments of Int/Int versus
Num/Num?

0/0 # fail "illegal division by zero"
0.0/0.0 # NaN

That seems to follow from the standard (ruby, ocaml, mzscheme currently
does that), but some may also argue for NaN bothways (ghc, js) or an
exception bothways (perl5, python).

Audrey



signature.asc
Description: OpenPGP digital signature

Re: punie.g observation

[Andrew Rodland]

On Tuesday 17 January 2006 16:50, Chris Dolan wrote:
> Allison et al.,
>
> I was looking at languages/punie/lib/punie.g in the current SVN head
> and got confused.  I see:
>rule gprint  { (print) \s*  }
> and
>rule expr{  |  }
>
> Doesn't that imply that "print print print print 1;" is a valid Punie
> program?  Is that intentional?  It seems to me that the gprint rule
> should instead contain "cexpr":
>rule gprint  { (print) \s*  }

"print print print print 1;"  is certainly a valid Perl 5 program; it prints a 
1 followed by 3 other things (which are defined to be true, and which happen 
to also be the number 1). Digging on retroperl.cpan.org shows that it did 
exactly the same thing on perl 1.0.0. So to answer your question, it's 
probably intentional :)

Andrew

punie.g observation

[Chris Dolan]

Allison et al.,

I was looking at languages/punie/lib/punie.g in the current SVN head  
and got confused.  I see:

  rule gprint  { (print) \s*  }
and
  rule expr{  |  }

Doesn't that imply that "print print print print 1;" is a valid Punie  
program?  Is that intentional?  It seems to me that the gprint rule  
should instead contain "cexpr":

  rule gprint  { (print) \s*  }

Sorry if these are dumb questions.  I've been following Parrot for a  
while, but I'm new to the code...


Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Re: [PATCH] struct Parrot_Context doesn't need a 'prev' field.

[Matt Fowles]

Bob~

On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Jan 14, 2006, at 21:28, Bob Rogers wrote:
>
> >I had thought this field was being used, but it turns out to be
> > irrelevant.  I offer this patch so that no one else is fooled (and
> > because I had to test it anyway to prove that this is the case).
>
> Thanks, applied - r11199

Why leave it in as a placeholder at all?

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

[perl #38235] [TODO] Rename (dyn)?classes to (dyn)?pmc

[Bernhard Schmalhofer via RT]

> [jonathan - Sa 14. Jan 2006, 09:57:37]:

> > I propose to rename 'src/classes' to 'src/pmc' as IMHO it makes
> > more sene. 't/pmc' is already named 'pmc'.
> >
> Yes, and for consistency please also rename dynclasses to dynpmc and the 
> t/dynclass to t/dynpmc.

The first step, renaming 'src/dynclasses' to 'src/dynpmc' is done.
Please do a 'svn up' and 'perl Configure.pl'.

The second step. renaming 'src/classes' to 'src/pmc' should follow tomorrow.

Mit freundlichen Grüßen,
  Bernhard

-- 
/* [EMAIL PROTECTED] */

[TODO] tools/dev/genrpt.pl is obsolete

[Bernhard Schmalhofer]

It looks like the script 'tools/dev/genrpt.pl' does basically the same as
'parrotbug'.
In order to decrease the level of confusion I propose to remove 
genrpt.pl and the associated make targets 'ok', 'okfile', 'nok', 'nokfile'.


CU, Bernhard

Re: [perl #38217] r11124: Cygwin build fails

[Larry Wall]

On Tue, Jan 17, 2006 at 08:28:37AM -0600, Greg Bacon wrote:
: I'm still seeing a link failure with r11221.
: 
: A confusing bit: I stopped the stripping of libparrot.dll, and nm
: seems to see the symbols that the linker's complaining about:
: 
: [...]
: Compiling with:
: xx.c
: gcc -I./include -pipe -I/usr/local/include -g -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align 
-Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare 
-Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization 
-Wno-shadow -falign-functions=16 -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -I. -o 
xx.o -c xx.c
: gcc -o miniparrot.exe -L/usr/local/lib   compilers/imcc/main.o \
:  -L/home/gbacon/src/parrot/blib/lib -lparrot  -lcrypt src/null_config.o
: compilers/imcc/main.o: In function `imcc_version':
: /home/gbacon/src/parrot/compilers/imcc/main.c:118: undefined reference to 
`_Parrot_revision'
: /home/gbacon/src/parrot/compilers/imcc/main.c:122: undefined reference to 
`_Parrot_config_revision'
: compilers/imcc/main.o: In function `main':
: /home/gbacon/src/parrot/compilers/imcc/main.c:469: undefined reference to 
`_imcc_init'
: Info: resolving _yydebug by linking to __imp__yydebug (auto-import)
: Info: resolving _line by linking to __imp__line (auto-import)
: collect2: ld returned 1 exit status
: make: *** [miniparrot.exe] Error 1
: 
: $ nm blib/lib/libparrot.dll | egrep 'Parrot_(config_)?revision|imcc_init'
: 1007c7c0 T _Parrot_config_revision
: 1007c7b0 T _Parrot_revision
: 10175380 T _imcc_init
: 10166320 T _imcc_init_tables
: 
: Phbt!

Looks like the same problem we were having before.  If we have to have
-L/usr/local/lib in there, it should probably come after your personal
-L/home/gbacon/src/parrot/blib/lib so that -lparrot prefers the one
you just built.  You ran nm on a different libparrot than the one
the linker used.

Larry

Re: Indeterminate forms for the Num type.

[Luke Palmer]

On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
> I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript),
> but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them...

I believe we've been through this before.  We go with a standard,
probably IEEE, horridly mathematically unappealing though it may be.
It will be easier to implement and it will be more predictable, both
because most other language follow standards, too.

Luke

Re: Indeterminate forms for the Num type.

[Rob Kinyon]

On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
> But putter on #perl6 reports "1" on his amd64.  I'd be happy we spec it
> has to have to return 1 always for boxed Num types, even though it means
> additional cycles for boxed numeric types.

Isn't the point of boxing to provide a hardware-independent dependable
solution at the cost of additional cycles?

Rob

Re: Indeterminate forms for the Num type.

[Audrey Tang]

Doug McNutt wrote:
>> - - Specify them to return some definite value.
> Only on a machine that doesn't do it in hardware or in some special perl 
> function that's unlikely.

This question arises as different platform answer things differently for
the native calculation of eg. 1**Inf.
> 
>> At this moment, Pugs defines them ad-hocly to:
>>
>>  0/0   == die "Illegal division by zero" <--- wrong. 1/0 should not 
>> die either.

I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript),
but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them...

>>  0*Inf == NaN <--- reasonable but don't re-invent the NaN bit pattern
>>  Inf/Inf   == NaN <--- reasonable but don't re-invent the NaN bit pattern
>>  Inf-Inf   == NaN <--- reasonable but don't re-invent the NaN bit pattern

The NaN as used in Pugs is already a double-precision NaN bit pattern. :-)

>>  0**0  == 1 <--- Not indeterminate. Answer is correct.
>>  Inf**0== 1 <--- Not indeterminate. Answer is correct.
>>  1**Inf== 1 <--- Not indeterminate. Answer is correct.

On my machine (Pentium-M, FreeBSD), 1**Inf yields NaN, as demonstrated
by this Parrot program:

.sub main
$N1 = 1/0
print $N1 # inf
$N2 = 1 ** $N1
print $N2 # nan
.end

But putter on #perl6 reports "1" on his amd64.  I'd be happy we spec it
has to have to return 1 always for boxed Num types, even though it means
additional cycles for boxed numeric types.

Audrey



signature.asc
Description: OpenPGP digital signature

Re: [perl #38217] r11124: Cygwin build fails

[Greg Bacon]

I'm still seeing a link failure with r11221.

A confusing bit: I stopped the stripping of libparrot.dll, and nm
seems to see the symbols that the linker's complaining about:

[...]
Compiling with:
xx.c
gcc -I./include -pipe -I/usr/local/include -g -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align 
-Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare 
-Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization 
-Wno-shadow -falign-functions=16 -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -I. -o 
xx.o -c xx.c
gcc -o miniparrot.exe -L/usr/local/lib   compilers/imcc/main.o \
 -L/home/gbacon/src/parrot/blib/lib -lparrot  -lcrypt src/null_config.o
compilers/imcc/main.o: In function `imcc_version':
/home/gbacon/src/parrot/compilers/imcc/main.c:118: undefined reference to 
`_Parrot_revision'
/home/gbacon/src/parrot/compilers/imcc/main.c:122: undefined reference to 
`_Parrot_config_revision'
compilers/imcc/main.o: In function `main':
/home/gbacon/src/parrot/compilers/imcc/main.c:469: undefined reference to 
`_imcc_init'
Info: resolving _yydebug by linking to __imp__yydebug (auto-import)
Info: resolving _line by linking to __imp__line (auto-import)
collect2: ld returned 1 exit status
make: *** [miniparrot.exe] Error 1

$ nm blib/lib/libparrot.dll | egrep 'Parrot_(config_)?revision|imcc_init'
1007c7c0 T _Parrot_config_revision
1007c7b0 T _Parrot_revision
10175380 T _imcc_init
10166320 T _imcc_init_tables

Phbt!

Greg

Re: Indeterminate forms for the Num type.

[Doug McNutt]

Physicist here. One who believes -2**2 is negative.

At 23:26 +0800 1/17/06, Audrey Tang wrote:
>Several options:
>- - Use whatever the underlying "num" semantics available

That's likely to be in hardware. It might even be hard to detect without 
looking at the NaN returned and that would be a waste of time. Some formulas 
can accept a NaN argument and still provide a correct result. At the worst they 
return a NaN to be tested for later

>- - Always "fail"
>- - Always "die"

Those are non-conforming options See below.

>- - Specify them to return some definite value.

Only on a machine that doesn't do it in hardware or in some special perl 
function that's unlikely.

>At this moment, Pugs defines them ad-hocly to:
>
>   0/0   == die "Illegal division by zero" <--- wrong. 1/0 should not 
> die either.
>   0*Inf == NaN <--- reasonable but don't re-invent the NaN bit pattern
>   Inf/Inf   == NaN <--- reasonable but don't re-invent the NaN bit pattern
>   Inf-Inf   == NaN <--- reasonable but don't re-invent the NaN bit pattern

>   0**0  == 1 <--- Not indeterminate. Answer is correct.
>   Inf**0== 1 <--- Not indeterminate. Answer is correct.
>   1**Inf== 1 <--- Not indeterminate. Answer is correct.





>The IEEE floating-point standard, supported by almost all modern processors, 
>specifies that every floating point arithmetic operation, including division 
>by zero, has a well-defined result.

I can't seem to find the actual assigned NaN bit patterns for the above cases,

is helpful but doesn't get there. There may be multiple inf/inf returns in some 
cases depending on just which inf is involved. There are also NaN's for 
functions implemented in hardware like atan and exp.

-- 

--> In Christianity, man can have only one wife. This is known as monotony. <--

Re: split on empty string

[Mark Reed]

On 2006-01-17 12:24 PM, "Gaal Yahas" <[EMAIL PROTECTED]> wrote:

> While cleaning up tests for release:
> 
> "".split(':')=>
> 
>()# Perl 5
>("",) # pugs
> 
> Which is correct? It doesn's seem to be specced yet.

I would prefer the current pugs behavior; it's consistent with the general
case, in which a string which does not match the splitting regex results in
a single-item list containing the original string.  This is the Python
behavior.

I find the Perl5 (and, surprisingly, Ruby) behavior rather counterintuitive.

Re: how to detect that we're running under CPAN::Testers?

[Barbie]

On Tue, Jan 17, 2006 at 06:06:50AM +1100, Adam Kennedy wrote:
> 
> At the moment all our output is structured XML files, so at some point I 
> need to write an XSL to translate it back down into something CPAN 
> Testers can deal with, and I can add whatever you want me to at that time.
> 
> Do you want the tag saying it's PITA-XSL-generated content, or the owner 
> of the testing system? (because I imagine we'll end up with a number of 
> those)

The fact that the report is generated using PITA. For me personally it
would be interesting to see where reports are generated from. At the
moment it's difficult to know which reports are manually produced.

There are several reports still that are getting misfiled, as it either
doesn't include the version number of the distribution or other
attributes are missing. It makes it easier to spot which mechanisms for
testing and reporting are getting it wrong, if the automated apps tag
the report.

Barbie.

split on empty string

[Gaal Yahas]

While cleaning up tests for release:

"".split(':')=>

   ()# Perl 5
   ("",) # pugs

Which is correct? It doesn's seem to be specced yet.

-- 
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/

Re: Indeterminate forms for the Num type.

[Jonathan Lang]

Audrey Tang wrote:
> Assuming "num" uses the underlying floating point semantic (which may
> turn 0/0 into NaN without raising exception), what should the default
> "Num" do on these forms?
>
> 0/0
> 0*Inf
> Inf/Inf
> Inf-Inf
> 0**0
> Inf**0
> 1**Inf
>
> Several options:
> - - Use whatever the underlying "num" semantics available
> - - Always "fail"
> - - Always "die"

Given a choice between the latter two, I'd rather go with Always
"fail" (i.e., return "undefined").  This lets people handle matters
with error-trapping if they like, without removing the possibility of
handling it by testing the result for "definedness".

> - - Specify them to return some definite value.
>
> At this moment, Pugs defines them ad-hocly to:
>
> 0/0   == die "Illegal division by zero"

See above; besides, math classes generally teach that 0/0 is undefined.

> 0*Inf == NaN
> Inf/Inf   == NaN
> Inf-Inf   == NaN

These expressions are no more NaN than Inf is.  I'd handle them as:

0*Inf == undef
Inf/Inf == Inf
Inf-Inf == Inf

> 0**0  == 1
> Inf**0== 1

I know that x**0 == 1 if x is anything other than 0 or Inf; meanwhile,
0**y == 0 if y is anything other than 0, and Inf**y == Inf if y is
anything other than 0.  I'd say that these two should normally be
undef.

> 1**Inf== 1

1**y == 1 when y is anything but Inf; x**Inf == Inf if |x| is greater
than 1; and x**Inf == 0 if |x| is less than 1.  Again, 1**Inf ==
undef.

> But I'd like to seek a more definite ruling.

Ditto.

--
Jonathan "Dataweaver" Lang

Indeterminate forms for the Num type.

[Audrey Tang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Assuming "num" uses the underlying floating point semantic (which may
turn 0/0 into NaN without raising exception), what should the default
"Num" do on these forms?

0/0
0*Inf
Inf/Inf
Inf-Inf
0**0
Inf**0
1**Inf

Several options:
- - Use whatever the underlying "num" semantics available
- - Always "fail"
- - Always "die"
- - Specify them to return some definite value.

At this moment, Pugs defines them ad-hocly to:

0/0   == die "Illegal division by zero"
0*Inf == NaN
Inf/Inf   == NaN
Inf-Inf   == NaN
0**0  == 1
Inf**0== 1
1**Inf== 1

But I'd like to seek a more definite ruling.

Thanks,
Audrey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDzQyitLPdNzw1AaARApaEAKChw0bHNA3M7OBLoeoRpootIjpy0QCfYtvT
/vNWF8SkS7MMXWDsZrDCp8I=
=vI/b
-END PGP SIGNATURE-