[perl #61282] 'make fulltest' failures

[via RT]

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


Parrot r33793 has has two failures in 'make fulltest', in the last bunch
of the test runs. (I don't see how to find out which runcore that is).

Test Summary Report
---
t/op/pushaction(Wstat: 256 Tests: 7 Failed: 1)
  Failed test:  6
  Non-zero exit status: 1
t/pmc/sub  (Wstat: 256 Tests: 64 Failed: 1)
  Failed test:  63
  Non-zero exit status: 1
Files=248, Tests=8209, 257 wallclock secs ( 2.34 usr  0.32 sys + 147.01
cusr 36.98 csys = 186.65 CPU)
Result: FAIL
make[1]: *** [testr] Error 1

In more detail:


#   Failed test 'pushaction as closure'
#   at t/op/pushaction.t line 100.
# Exited with error code: 1
# Received:
# main
# at popmark, flag = 0
# a = Null PMC in say
# current instr.: 'exit_handler' pc 32
(/home/moritz/src/parrot/t/op/pushaction_6.pir:22)
# called from Sub 'main' pc 15
(/home/moritz/src/parrot/t/op/pushaction_6.pir:11)
#
# Expected:
# main
# at popmark, flag = 0
# a = 42
#
# Looks like you failed 1 test of 7.


   Failed test ':outer with identical sub names'
#   at t/pmc/sub.t line 1462.
# Exited with error code: 1
# Received:
# ABC::outer
# ABC::inner
# Null PMC in say
# current instr.: 'parrot;ABC;inner' pc 47
(/home/moritz/src/parrot/t/pmc/sub_63.pir:20)
# called from Sub 'parrot;ABC;outer' pc 37
(/home/moritz/src/parrot/t/pmc/sub_63.pir:14)
# called from Sub 'main' pc 9 (/home/moritz/src/parrot/t/pmc/sub_63.pir:3)
#
# Expected:
# ABC::outer
# ABC::inner
# ABC lex
# DEF::outer
# DEF::inner
# DEF lex
#
# Looks like you failed 1 test of 64.

Platform is Debian GNU/Linux 4.0 "Etch" on i386 32bit dual core CPU,
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


Moritz

[perl #61286] [PATCH][PROPOSAL] box complements

[via RT]

# New Ticket Created by  François PERRAD 
# Please include the string:  [perl #61286]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=61286 >


The new opcode 'box' is limited by its 3 signatures that target Float,
Integer & String.
I propose the 3 following new opcodes :
 - true
 - false
 - undef or nil (less Perlish)

After some experiments with bytecode translation,
in WMLScript (r33655) and in Lua (r33760),
it seems obvious that we need them.

François.
Index: src/ops/pmc.ops
===
--- src/ops/pmc.ops	(revision 33750)
+++ src/ops/pmc.ops	(working copy)
@@ -607,6 +607,29 @@
 VTABLE_set_string_native(interp, $1, $2);
 }
 
+=item B(out PMC)
+
+=item B(out PMC)
+
+=item B(out PMC)
+
+Create a literal HLL-mapped PMC.
+
+=cut
+
+op true(out PMC) {
+$1 = pmc_new(interp, Parrot_get_ctx_HLL_type(interp, enum_class_Boolean));
+VTABLE_set_bool(interp, $1, 1);
+}
+
+op false(out PMC) {
+$1 = pmc_new(interp, Parrot_get_ctx_HLL_type(interp, enum_class_Boolean));
+}
+
+op undef(out PMC) {
+$1 = pmc_new(interp, Parrot_get_ctx_HLL_type(interp, enum_class_Undef));
+}
+
 =back
 
 =head1 COPYRIGHT
Index: t/op/box.t
===
--- t/op/box.t	(revision 33750)
+++ t/op/box.t	(working copy)
@@ -16,13 +16,15 @@
 
 =cut
 
-.const int TESTS = 24
+.const int TESTS = 34
 
 # must set these up before the .HLL_map statements later
 .sub '__setup' :immediate
 $P0 = subclass 'Integer', 'MyInt'
 $P0 = subclass 'String',  'MyString'
 $P0 = subclass 'Float',   'MyFloat'
+$P0 = subclass 'Boolean', 'MyBoolean'
+$P0 = subclass 'Undef',   'MyUndef'
 .end
 
 .sub 'main' :main
@@ -33,6 +35,9 @@
 'box_int'()
 'box_num'()
 'box_string'()
+'true_'()
+'false_'()
+'undef_'()
 
 .local pmc box_int_hll
 box_int_hll = get_root_global [ 'for_test' ], 'box_int'
@@ -43,9 +48,21 @@
 .local pmc box_string_hll
 box_string_hll = get_root_global [ 'for_test' ], 'box_string'
 
+.local pmc true_hll
+true_hll = get_root_global [ 'for_test' ], 'true_'
+
+.local pmc false_hll
+false_hll = get_root_global [ 'for_test' ], 'false_'
+
+.local pmc undef_hll
+undef_hll = get_root_global [ 'for_test' ], 'undef_'
+
 box_int_hll()
 box_num_hll()
 box_string_hll()
+true_hll()
+false_hll()
+undef_hll()
 .end
 
 .sub 'box_int'
@@ -92,14 +109,37 @@
 isa_ok( $P0, 'String', 'string boxed to appropriate base type from reg' )
 .end
 
+.sub 'true_'
+$P0 = true
+$I0 = $P0
+is( $I0, 1, 'good value' )
+
+isa_ok( $P0, 'Boolean', 'good base type' )
+.end
+
+.sub 'false_'
+$P0 = false
+$I0 = $P0
+is( $I0, 0, 'good value' )
+
+isa_ok( $P0, 'Boolean', 'good base type' )
+.end
+
+.sub 'undef_'
+$P0 = undef
+$I0 = $P0
+isa_ok( $P0, 'Undef', 'good base type' )
+.end
+
 .HLL 'for_test'
 
 .HLL_map 'Integer' = 'MyInt'
 .HLL_map 'String'  = 'MyString'
 .HLL_map 'Float'   = 'MyFloat'
+.HLL_map 'Boolean' = 'MyBoolean'
+.HLL_map 'Undef'   = 'MyUndef'
 
 .sub 'box_int'
-.include 'include/test_more.pir'
 $P0 = box -100
 $I0 = $P0
 is( $I0, -100, 'value preserved when boxing int in HLL' )
@@ -144,6 +184,27 @@
 isa_ok($P0, 'MyString', 'string boxed to appropriate type for HLL from reg')
 .end
 
+.sub 'true_'
+$P0 = true
+$I0 = $P0
+is( $I0, 1, 'good value in HLL' )
+
+isa_ok( $P0, 'MyBoolean', 'good base type for HLL' )
+.end
+
+.sub 'true_'
+$P0 = true
+$I0 = $P0
+is( $I0, 1, 'good value in HLL' )
+
+isa_ok( $P0, 'MyBoolean', 'good base type for HLL' )
+.end
+
+.sub 'undef_'
+$P0 = undef
+isa_ok( $P0, 'MyUndef', 'good base type for HLL' )
+.end
+
 # Local Variables:
 #   mode: cperl
 #   cperl-indent-level: 4

[perl #61278] perl6 build errors on Debian stable "Etch" (parrot svn trunk rev 33776 and before)

[via RT]

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


Hi folks,

in the last days I tried several times with the respective latest svn trunk of 
parrot to build perl6 to play with it, but always the build failed. I use 
Debian stable vanilla Linux, no strange configurations. I can  verify this 
with a fresh install in a virtual machine if that helps.

I tried it with perl 5.8.8 (Debian package) and 5.10.0 (installed 
in /opt/perl/ ).

What I did (here using perl-5.10.0):

svn up
svn export . /tmp/parrot
cd /tmp/parrot
/opt/perl/bin/perl Configure.pl
make
make -C languages/perl6/ perl6

Error message:
==
error:imcc:syntax error, unexpected VAR, expecting '(' ('var')
in file 'src/builtins/op.pir' line 430
included from 'src/gen_builtins.pir' line 25
included from 'perl6.pir' line 1
==

Did I miss something?

Cheers,

Jochen

What does a Pair numify to?

[Carl Mäsak]

Pugs and Elf currently numify a Pair object to 2, and Rakudo currently
dies of despair.

My guess is that the semantics of Pugs and Elf falls out naturally
form a pair being treated as a list of two elements, or something. The
question still deserves to be raised whether always-2 is a good
semantics, or whether one would prefer some other default.

// Carl

Re: What does a Pair numify to?

[TSa]

HaloO,

Carl Mäsak wrote:

Pugs and Elf currently numify a Pair object to 2, and Rakudo currently
dies of despair.

My guess is that the semantics of Pugs and Elf falls out naturally
form a pair being treated as a list of two elements, or something. The
question still deserves to be raised whether always-2 is a good
semantics, or whether one would prefer some other default.


My idea is to let a pair numify to whatever the value numifies to.
Same thing with stringification. In general I think that a pair should
hide its key as far as possible if used as non-pair.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

[svn:parrot-pdd] r33798 - trunk/docs/pdds

[kjs]

Author: kjs
Date: Thu Dec 11 05:39:13 2008
New Revision: 33798

Modified:
   trunk/docs/pdds/pdd19_pir.pod

Log:
[pdd19] removed deprecated and removed stuff.

Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod   (original)
+++ trunk/docs/pdds/pdd19_pir.pod   Thu Dec 11 05:39:13 2008
@@ -359,9 +359,6 @@
 the PIR code is generated from some source PIR files, and error messages
 should print the source file's name, not the name of the generated file.
 
-{{ DEPRECATION NOTE: was C<<#line  >>. See [RT#45857],
-[RT#43269], and [RT#47141]. }}
-
 =item .annotate  
 
 Makes an entry in the bytecode annotations table. This is used to store high
@@ -390,33 +387,6 @@
 
 Then you're asking for a bigger bytecode file as a result.
 
-=item .namespace  [deprecated: See RT #48737]
-
-{{ DEPRECATION NOTE: this variation of C<.namespace> and
-C<.endnamespace> are deprecated.  They were a hackish attempt at
-implementing scopes in Parrot, but didn't actually turn out to be
-useful.}}
-
-Open a new scope block. This "namespace" is not the same as the
-.namespace [  ] syntax, which is used for storing subroutines
-in a particular namespace in the global symbol table.
-This directive is useful in cases such as (pseudocode):
-
-  local x = 1;
-  print(x);   # prints 1
-  do  # open a new namespace/scope block
-local x = 2;  # this x hides the previous x
-print(x); # prints 2
-  end # close the current namespace
-  print(x);   # prints 1 again
-
-All types of common language constructs such as if, for, while, repeat and
-such that have nested scopes, can use this directive.
-
-=item .endnamespace  [deprecated: RT #48737]
-
-Closes the scope block that was opened with .namespace .
-
 =back
 
 =head3 Subroutine flags
@@ -480,7 +450,7 @@
 This code is run at compile time, and the returned C is stored
 in the bytecode file in place of the sub.  Other subs may then do:
 
-.const .Sub tr_00 = 'tr_00_init'
+.const 'Sub' tr_00 = 'tr_00_init'
 
 in order to fetch the constant.
 
@@ -812,10 +782,6 @@
 Note that this only works for opcodes that have have a leading C
 parameter. [this restriction unimplemented: RT #36283]
 
-=item global "string" =  [deprecated: RT #48016]
-
-=item  = global "string" [deprecated: RT #48018]
-
 =item ([ [: ...], ...]) = ([ [: ...], ...])
 
 This is short for:

[svn:parrot-pdd] r33799 - trunk/docs/pdds

[kjs]

Author: kjs
Date: Thu Dec 11 05:43:56 2008
New Revision: 33799

Modified:
   trunk/docs/pdds/pdd19_pir.pod

Log:
[pdd19] add bits on implementation

Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod   (original)
+++ trunk/docs/pdds/pdd19_pir.pod   Thu Dec 11 05:43:56 2008
@@ -965,7 +965,7 @@
 
  EOS
 
-{{ NOTE: This is likely because the parsing of heredocs happens later than the
+{{ NOTE: This is because the parsing of heredocs happens later than the
 preprocessing of macros. Might be nice if we could parse heredocs at the macro
 level, but not a high priority. compilers/pirc/new can do this. }}
 
@@ -1136,7 +1136,7 @@
 
 =head2 Subroutine Call
 
-  .const .Sub $P0 = "_sub_label"
+  .const "Sub" $P0 = "_sub_label"
   $P1 = new 'Continuation'
   set_addr $P1, ret_addr
   ...
@@ -1178,7 +1178,7 @@
 a NCI sub, and on invocation will do the Right Thing.
 Instead of the label a subroutine object can be used too:
 
-   find_global $P0, "_sub_label"
+   get_global $P0, "_sub_label"
$P0(args)
 
 
@@ -1278,7 +1278,28 @@
 =head1 IMPLEMENTATION
 
 There are multiple implementations of PIR, each of which will meet this
-specification for the syntax.
+specification for the syntax. Currently there are the following
+implementations:
+
+=over 4
+
+=item * compilers/imcc
+
+This is the current implementation being used in Parrot.
+
+=item * compilers/pirc
+
+This is a new implementation which will fix several of
+IMCC's shortcomings. It will replace IMCC in the not too
+distant future.
+
+=item * languages/PIR
+
+This is a PGE-based implementation, but needs to be updated
+and completed.
+
+=back
+
 
 =head1 ATTACHMENTS
 

[perl #61290] [BIG] can't peek on stdin

[via RT]

# New Ticket Created by  François PERRAD 
# Please include the string:  [perl #61290]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=61290 >


Since the merge of the branch ppd22io, the mode of the stdin stream has changed.
Currently, it isn't possible to peek on stdin.

$ cat peek.pir
.sub 'main'
 $P0 = getstdin
 $S0 = peek $S0
.end

$ ./parrot peek.pir < peek.pir
Can't peek at unbuffered I/O

The issue was detected with I/O library of Lua (see languages/lua/t/io.t#17).

François.

Re: [perl #61286] [PATCH][PROPOSAL] box complements

[François Perrad]

2008/12/11 Will Coleda via RT <[EMAIL PROTECTED]>:
> On Thu Dec 11 01:51:23 2008, fperrad wrote:
>> The new opcode 'box' is limited by its 3 signatures that target Float,
>> Integer & String.
>> I propose the 3 following new opcodes :
>
>>  - true
>>  - false
>
> These can be approximated with:
>
> $P0 = box 1
> $P0 = box 0

No.

On Lua, LuaNumber maps Float & Integer, LuaBoolean maps Boolean.
So, with the current signature of box :
  $P0 = box 1
is equivalent to
  $P0 = new 'LuaNumber'
  set $P0, 1
but I want a LuaBoolean, because I want respect the precise rules of
coercion for arithmetic operations.
The expected behavior with a LuaNumber containing 1 and with a
LuaBoolean containing 1 is not same.

On WMLScript, WmlsInteger maps Integer, WmlsBoolean maps Boolean
So,
  $P0 = box 1
is equivalent to
  $P0 = new 'WmlsInteger'
  set $P0, 1
but I want a WmlsBoolean.


>
> I know you'll end up with an Integer (or, perhaps, a LuaInt) instead of
> a Boolean here. That doesn't work?
>
>>  - undef or nil (less Perlish)
>
> undef and null are two different things in parrot, but we do have an
> opcode for one of them, at least:
>
> $P0 = null
>
>> After some experiments with bytecode translation,
>> in WMLScript (r33655) and in Lua (r33760),
>> it seems obvious that we need them.
>
> Can you explain why?
>

With the opcode 'box', I could rewrite the generation of :
 - ConstantInteger
 - ConstantFloat
 - ConstantString
but not :
 - ConstantBoolean
 - ConstantNil

That's seems not homogene.

>> François.
>
>
> --
> Will "Coke" Coleda
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

Re: [perl #61242] [FTBFS] build fails with --optimize on 64bit linux

[Nicholas Clark]

On Tue, Dec 09, 2008 at 03:43:59PM -0800, Moritz Lenz wrote:

> After a 'make realclean' I ran 'perl Configure --optimize && make'. It
> dies like this:
> 
> ../../parrot -o PGE.pbc --output-pbc PGE.pir
> ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir
> --output=PGE/bui
> ltins_gen.pir PGE/builtins.pg
> FixedIntegerArray: Can't resize!
> current instr.: 'parrot;P6metaclass;new_class' pc 95
> (runtime/parrot/library/P6o
> bject.pir:126)
> make[1]: *** [PGE.pbc] Error 1
> make[1]: Leaving directory `/home/moritz/src/parrot/compilers/pge'
> make: *** [compilers.dummy] Error 2

> This is a 64bit Debian Lenny install with gcc 4.3.2. Building without
> --optimize is no problem.

I believe that Parrot will continue to have obscure problems such as this,
much as Perl 5 used to do, until it implements the equivalent of

http://public.activestate.com/cgi-bin/perlbrowse/p/33291

and fixes the problems that it shows up.

(Yes, it's big. Search for the section starting
 //depot/perl/embed.pl#366 (xtext) 
for the Perl code that generates the assertion macros from embed.fnc. This
is the equivalent to Parrot's headerizer)


Summary - I infer that some "not null" annotations in Parrot are not correct.

Perl 5's experience was that these are like landmines, and lay dormant until
someone tries with a newer compiler, that happens to add a bit more
optimisation. Of course, this can happen months after you release code, code
that "works" and is thought to be stable. IIRC we had 3 separate end user bugs
found with this as the cause, before I realised that we were never going to
find them by hand, so made the above changes to make the compiler find them.

What you don't see in *that* change was the half dozen or so that it found
and I fixed, that I committed before I was able to add that. See here:
http://public.activestate.com/cgi-bin/perlbrowse?top=33291&show_recent=Show+Change+Log


Nicholas Clark

Re: [perl #61286] [PATCH][PROPOSAL] box complements

[Will Coleda]

On Thu, Dec 11, 2008 at 11:10 AM, François Perrad
<[EMAIL PROTECTED]> wrote:
> 2008/12/11 Will Coleda via RT <[EMAIL PROTECTED]>:
>> On Thu Dec 11 01:51:23 2008, fperrad wrote:
>>> The new opcode 'box' is limited by its 3 signatures that target Float,
>>> Integer & String.
>>> I propose the 3 following new opcodes :
>>
>>>  - true
>>>  - false
>>
>> These can be approximated with:
>>
>> $P0 = box 1
>> $P0 = box 0
>
> No.
>
> On Lua, LuaNumber maps Float & Integer, LuaBoolean maps Boolean.
> So, with the current signature of box :
>  $P0 = box 1
> is equivalent to
>  $P0 = new 'LuaNumber'
>  set $P0, 1
> but I want a LuaBoolean, because I want respect the precise rules of
> coercion for arithmetic operations.
> The expected behavior with a LuaNumber containing 1 and with a
> LuaBoolean containing 1 is not same.
>
> On WMLScript, WmlsInteger maps Integer, WmlsBoolean maps Boolean
> So,
>  $P0 = box 1
> is equivalent to
>  $P0 = new 'WmlsInteger'
>  set $P0, 1
> but I want a WmlsBoolean.
>
>
>>
>> I know you'll end up with an Integer (or, perhaps, a LuaInt) instead of
>> a Boolean here. That doesn't work?
>>
>>>  - undef or nil (less Perlish)
>>
>> undef and null are two different things in parrot, but we do have an
>> opcode for one of them, at least:
>>
>> $P0 = null
>>
>>> After some experiments with bytecode translation,
>>> in WMLScript (r33655) and in Lua (r33760),
>>> it seems obvious that we need them.
>>
>> Can you explain why?
>>
>
> With the opcode 'box', I could rewrite the generation of :
>  - ConstantInteger
>  - ConstantFloat
>  - ConstantString
> but not :
>  - ConstantBoolean
>  - ConstantNil
>
> That's seems not homogene.
>
>>> François.

As I understand it, box is designed to deal /only/ with promoting the
3 basic register types (SIN) to PMCs of the appropriate HLL type (just
like autoboxing in PCC), not to provide a way to promote literal
values for arbitrary core PMCs. So the discontinuity is that not every
core PMC has a corresponding register type.

I think a more general approach might be to have an opcode that
combined 'new' and 'assign'. You could even have it respect the HLL
mappings if present.

$P1 = new_init 'LuaBoolean', 1   # explicitly pick a type.
$P3 = new_init 'String, 'good luck' # this type is overridden by the
HLL, get a LuaString as a result.

But ISTR this was shot down by Chip some time ago, and what little
support there is for it (new_from_string) is slated to be removed.

(IAN The Architect)

-- 
Will "Coke" Coleda

Re: Smooth numeric upgrades?

[TSa]

HaloO,

Darren Duncan wrote:

Michael G Schwern wrote:

TSa (Thomas Sandlaß) wrote:

I want to stress this last point. We have the three types Int,
Rat and Num. What exactly is the purpose of Num? The IEEE formats
will be handled by num64 and the like. Is it just there for
holding properties? Or does it do some more advanced numeric
stuff?


"Int", "Rat" [1] and "Num" are all human types. They work like
humans were taught numbers work in math class. They have no size
limits. They shouldn't lose accuracy. [2]

As soon as you imply that numbers have a size limit or lose
accuracy you are thinking like a computer. That's why "num64" is
not a replacement for "Num", conceptually nor is "int64" a
replacement for "Int". They have limits and lose accuracy.


All agreed.


I also agree. But I want to work out a bit more of the semantics
of Num. Int and Rat are easy insofar as there are arbitrary precision
implementations. This is not the case for irrational numbers. One
route here is to go into symbolic math. But this is at best the task
of add-on modules.

The concept I have in mind is the subtype chain Int <: Rat <: Num
with automatic upgrades and non-automatic downgrades. That is

my Int $i = 2/3;
my Rat $r = sqrt(2);

are conceptually failures and result in exceptions which can of course
be converted to warnings or automatic conversions by pragmas. I see
the Complex type as a parametric type that replicates the above subtype
chain as Complex[Int] <: Complex[Rat] <: Complex[Num]. This should be
the general scheme for other types that implement numeric operations.

The Num type is basically an arbitrary precision float as Duncan has
proposed together with an .irrational flag that marks it as non-Rat.
E.g. the Num implementation of sqrt might even flag sqrt(4) as non-Rat
and actually not even achieve 2 numerically. This can be remedied as
follows

   subset SqrInt of Int where { $_ == any(1..* »**» 2) }

   multi sub sqrt (SqrInt $i --> Int)
   {
  # calculate approximate result that will be almost an Int
  # cast is needed to avoid endless dispatch
  return round( sqrt( Num $i ) );
   }

   subset SqrRat of Rat where { .numerator ~~ SqrInt &&
.denominator ~~ SqrInt }

   multi sub sqrt (SqrRat $r --> Rat)
   {
  # dispatches to sqrt:(SqrInt --> Int)
  return round( sqrt( $r.numerator ) ) /
 round( sqrt( $r.denominator ) );
   }

The latter implementation has the drawback that it needs to produce
two possibly large Ints as intermediate results. So we could instead
call the approximate sqrt with $r directly with appropriately set
precision demands.

The specced behavior of / for two Ints falls out naturally because it
returns a Num that simply doesn't happen to have the non-Rat flag set
and as such is assignable to a variable with a Rat constraint. It's
also easy to get typesafe assignments of Rats with .denominator == 1
to Int variables. That is we have the conceptual subsets

  subset Rat of Num where { !.irrational }

  subset Int of Rat where { .denominator == 1 }

Functions like sin are not required to flag sin(pi/6) == 1/2
as rational. They might not even achieve the numeric equality
unless some additional definitions are made for the equality
of Nums with some epsilon.



[2] "Num" should have an optional limit on the number of decimal places
it remembers, like NUMERIC in SQL, but that's a simple truncation.


I disagree.


I disagree as well. But Num should provide an interface to access the
underlying approximations made by functions that operate on Nums. The
default will be a relative error i.e. a ratio between the difference
to the exact value and the exact value---note that this error itself is
approximate. This means that the absolute error can be quite large for
large numbers. This estimation strategy allows an implementation of Num
on top of Rat.

For starters, any "limit" built into a type definition should be defined 
not as stated above but rather with a simple subtype declaration, eg 
"subtype of Rat where ..." that tests for example that the Rat is an 
exact multiple of 1/1000.


The interesting thing that occurred to me is that constraints on
variables are known at compile time. If we define that the point
in a computation where the rounding takes place is the moment when
it comes to storing a value in a variable then the parser can
propagate the accuracy of the constraint to all functions called
in the expression tree. This means we need a definition language
how the Num type performs its approximations. This is then used
in the where clause of subset declarations of Num.

This means that we have an extensible set of operators and functions
that do numerics. All these functions have an approximation interface
that the compiler generates input for. If the programmer wishes she
can also use that interface directly, of course.

Second, any truncation should be done at the operator level not at the 
type level; for example

Re: [perl #61282] 'make fulltest' failures

[chromatic]

On Wednesday 10 December 2008 23:20:22 Moritz Lenz wrote:

> Parrot r33793 has has two failures in 'make fulltest', in the last bunch
> of the test runs. (I don't see how to find out which runcore that is).

It's the run-from-PBC runcore.

> Test Summary Report
> ---
> t/op/pushaction(Wstat: 256 Tests: 7 Failed: 1)
>   Failed test:  6
>   Non-zero exit status: 1
> t/pmc/sub  (Wstat: 256 Tests: 64 Failed: 1)
>   Failed test:  63
>   Non-zero exit status: 1
> Files=248, Tests=8209, 257 wallclock secs ( 2.34 usr  0.32 sys + 147.01
> cusr 36.98 csys = 186.65 CPU)
> Result: FAIL
> make[1]: *** [testr] Error 1

[testr] gives the answer.

This should mean that you can run t/op/pushaction_6.pbc and see the same 
error, for example (or parrot -r t/op/pushaction_6.p(ir|asm)).

-- c

Re: [perl #61286] [PATCH][PROPOSAL] box complements

[chromatic]

On Thursday 11 December 2008 08:20:06 Will Coleda wrote:

> As I understand it, box is designed to deal /only/ with promoting the
> 3 basic register types (SIN) to PMCs of the appropriate HLL type (just
> like autoboxing in PCC), not to provide a way to promote literal
> values for arbitrary core PMCs. So the discontinuity is that not every
> core PMC has a corresponding register type.

Yes.

> I think a more general approach might be to have an opcode that
> combined 'new' and 'assign'. You could even have it respect the HLL
> mappings if present.

If Lua has dynops, this is easy.  If Lua doesn't have dynops, this could 
easily be a function.

-- c

Re: [svn:parrot-pdd] r33751 - trunk/docs/pdds/draft

[Nicholas Clark]

On Wed, Dec 10, 2008 at 12:58:54AM -0800, chroma...@cvs.perl.org wrote:

> Log:
> [PDD] Reviewed Numbers PDD; minor edits to formatting and phrasing.  Sadly,
> IBM's Standard Decimal Arithmetic Standard is no longer available from IBM's
> site.  It's unclear how to include this within Parrot as it stands anyway.
> This PDD needs more thinking in the next few days.

> -IBM's Standard Decimal Arithmetic, with tests
> -L
> +IBM's Standard Decimal Arithmetic, with tests (sadly, link appears to have
> +disappeared)

This? http://download.icu-project.org/ex/files/decNumber/decNumber-icu-361.zip

The prominent page has gone, but it seems to be referenced here still:
http://secure.alphaworks.ibm.com/tech/decnumber

Nicholas Clark

Roles and IO?

[Leon Timmermans]

Hi all,

I've been thinking about how the IO interface should be organized in
perl6. It seems that part of S16 has received little attention so far.

One main problem with filehandles is that are rather diverse. The only
operation that all of them have in common is close. Reading versus
writing is a obvious difference, there are many more differences. One
can't seek a socket or a pipe, and likewise one can't accept on a
file. A listening socket can't even be read or written to. At the same
time, they all do have some parts in common with some other types of
handles.

Perl 5's solution is to use a fat interface, and raise an error if an
unsupported action is tried. I think that approach is needlessly
fragile. Another solution is to make a separate class for every
variety of handle, but IMO that's a plain fugly solution that simply
doesn't scale up very well.

What I propose is using role composition for *everything*. Most
importantly that includes the roles Readable and Writable, but also
things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered
(does Readable), Socket, Acceptable (does Pollable), and more.

That may however make some interfaces is a bit wordy. I think that can
be conveyed using a subset like this (though that may be abusing the
feature).

subset File of Mapable & Pollable & Statable & Ownable;

In this case, these calls:

open($filename, :w);

would return a Writable & File, and

Socket::connect($remote_host, $port, :type);

would return a Socket & Buffered & Pollable & Writable


Regards,

Leon Timmermans

Re: Roles and IO?

[Jon Lang]

Leon Timmermans wrote:
> What I propose is using role composition for *everything*. Most
> importantly that includes the roles Readable and Writable, but also
> things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered
> (does Readable), Socket, Acceptable (does Pollable), and more.
>
> That may however make some interfaces is a bit wordy. I think that can
> be conveyed using a subset like this (though that may be abusing the
> feature).
>
> subset File of Mapable & Pollable & Statable & Ownable;

subset is the wrong approach: a subset is about taking an existing
role and restricting the range of objects that it will match.  What
you're really asking for are composite roles:

  role File does Mappable does Pollable does Statable does Ownable {}

One of the things about roles is that once you have composed a bunch
of them into another role, they're considered to be composed into
whatever that role is composed into.  So "does File" would be
equivalent to "does Mappable does Pollable does Statable does Ownable"
(barring potential conflicts between Mappable, Pollable, Statable, and
Ownable which File would presumably resolve).

-- 
Jonathan "Dataweaver" Lang

Re: Roles and IO?

[Brandon S. Allbery KF8NH]

On 2008 Dec 11, at 20:16, Leon Timmermans wrote:

One main problem with filehandles is that are rather diverse. The only
operation that all of them have in common is close. Reading versus


Be glad Xenix is dead.  There were filehandles which didn't even  
support close() (they were actually handles for shared memory and  
semaphores).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Roles and IO?

[Mark J. Reed]

On Thu, Dec 11, 2008 at 8:16 PM, Leon Timmermans  wrote:

> What I propose is using role composition for *everything*. Most
> importantly that includes the roles Readable and Writable, but also
> things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered
> (does Readable), Socket, Acceptable (does Pollable), and more.


"Mapable" is better spelled "Mappable" in English.  Arguably, it should be
"Stattable" as well; "statable" means "state-able".


> That may however make some interfaces is a bit wordy. I think that can
> be conveyed using a subset like this (though that may be abusing the
> feature).
>
> subset File of Mapable & Pollable & Statable & Ownable;


As Jonathan said, I think composition makes more sense here... but what if
you have an interface that expects an IO object and does nothing with it but
pass it into some other interface?  How does it declare that?  It seems like
there still needs to be a generic superrole that means "some non-empty but
unspecified subset of these roles" - maybe "Closable" would work, but it's
not real clear.





-- 
Mark J. Reed 

Perl as a better web language ?

[howard chen]

Hello, I love perl for its rich set of modules but PHP is a better
template language for
web developments. Wouldn't it be great to see if Perl6 support it?

E.g.



as contrast to




Howard

Re: Perl as a better web language ?

[Brandon S. Allbery KF8NH]

On 2008 Dec 11, at 23:55, howard chen wrote:

Hello, I love perl for its rich set of modules but PHP is a better
template language for
web developments. Wouldn't it be great to see if Perl6 support it?



It can be done as a library, take a look at Perl6 grammars.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Perl as a better web language ?

[Henk van Oers]

On Thu, 11 Dec 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Dec 11, at 23:55, howard chen wrote:

Hello, I love perl for its rich set of modules but PHP is a better
template language for
web developments. Wouldn't it be great to see if Perl6 support it?



It can be done as a library, take a look at Perl6 grammars.


It has been done for perl5. See PLP on CPAN.

--
Henk