Re: 99 problems in Perl6: 32 and a question on number coercion
Hi! gabriele renzi [EMAIL PROTECTED] writes: Hi everyone! I solved the (easy) problem 32, implementing gcd($a,$b). You can check the code in the repository or on the web[1] I looked at [1]. What's the purpose of multi in this case? (Maybe you wanted to write it as more than one subs, did you?) But while writing this I noticed that a function written as sub gcd(Int $a, Int $b) still accepts float/rational values in input. I think I read once that a variable of type Int would accept these kind of assignment but that the value would be coerced to the new type of the variable, i.e. my Int $a= 10.1 #= 10 Could someone explain me what is the expected behaviour? Last time I experimented with this, the type system in Pugs looked unfinished. Type constraints were syntactically accepted but worked similar to typeless code in Perl5. I'm not sure about the current state. Anyway, in your example I hadn't expected a value coercion (from 10.1 to 10), but something like an error if the type doesn't match. But I can't find the right place in the synopses to verify it. Anyone with a clue here? Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/ Deutscher Perl-Workshop http://www.perl-workshop.de/
[svn:parrot-pdd] r16397 - trunk/docs/pdds
Author: allison Date: Wed Jan 3 01:44:16 2007 New Revision: 16397 Modified: trunk/docs/pdds/pdd22_io.pod Log: [pdd]: Add exception throwing to the API of the async I/O status object. Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podWed Jan 3 01:44:16 2007 @@ -260,6 +260,13 @@ Returns a boolean status for the status object, Ctrue for successful completion or successful work in progress, Cfalse for an error. +=item return + + $P0 = $P1.return() + +Retrieves the return value of the asynchronous operation from the status +object. + =item error $P0 = $P1.error() @@ -270,11 +277,11 @@ was no error, or the asynchronous operation is still running, returns a null PMC. -=item return +=item throw - $P0 = $P1.return() + $P0 = $P1.throw() -Retrieves the return value of the asynchronous operation from the status +Throw an exception from the status object if it contains an error object. =back
I/O PDD - ready for implementation
I've just moved pdd22 out of the clip directory, marking it as ready for beginning implementation efforts. Comments on the pdd are welcomed. A few things worth highlighting: - I/O layers will be replaced with role composition. - Parrot's concurrency model for async I/O is a modified form of the callback function model, combined with a central concurrency scheduler (see recent comments added to PDD 25). - One question still under discussion is error handling. Should all errors be exceptions? Integer status codes? More details in the PDD. Allison
Re: [perl #41158] [BUG] Here Docs in test Ccmp cause t/op/cmp-nonbranch.t abnormal exit
On Tue, Jan 02, 2007 at 06:52:14AM -0800, jerry gay wrote: these tests pass on windows, so i didn't catch it when i added this file. it seems there's something funny with parrot heredocs and CRLF. i don't know if this is expected behavior or not (it's untested.) i'll have to look further. I think it's a bug, and I have fixed it in [perl #41165]. Can you test it on Windows? Thanks Lee
[perl #41165] [PATCH] appropriate handle CRLE in Here Docs
# New Ticket Created by Lee Duhem
# Please include the string: [perl #41165]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41165
Current parrot(in fact, lexical analyzer of PIR) don't play well
with CRLE in Here Docs on Unix-like box such as Linux, you will
get syntax error when feed parrot DOS fileformat(i.e. use CRLF line
terminators) source(include Here Docs, of course) on Linux. And
this is the *real* reason of bug [perl #41158] Here Docs in test
Ccmp cause t/op/cmp-nonbranch.t abnormal exit.
These attached patches fix this, and I think it's a better fix
for [perl #41158].
I have test it on Linux, it just works fine. Can someone test it
on Windows? Thanks
If you want to test this patch, you need to apply imcc_l.patch first,
and then apply root_in.patch (this will refresh compilers/imcc/imclexer.c
for you, current config/gen/makefiles/root.in will not do that). Then
reconfigure your parrot use option --maintainer (you need working lex,
at least), and make.
BTW, If you use bison and have uninitialized value warning when you
reconfigure parrot, you can apply patch in [perl #41163], this fix it.
Lee
Index: compilers/imcc/imcc.l
===
--- compilers/imcc/imcc.l (revision 16381)
+++ compilers/imcc/imcc.l (working copy)
@@ -100,7 +100,7 @@
STRINGCONSTANT {SQ_STRING}|{DQ_STRING}
SQ_STRING \'[^'\n]*\'
RANKSPEC\[[,]*\]
-EOL\r?\n
+EOL \r?\n
WS [\t\f\r\x1a ]
SP [ ]
@@ -141,11 +141,15 @@
heredoc2{EOL} {
/* heredocs have highest priority
- * arrange them befor all wildcard state matches
+ * arrange them before all wildcard state matches
*/
/* Newline in the heredoc. Realloc and cat on. */
IMCC_INFO(interp)-line++;
+if (yytext[yyleng - 2] == '\r') {
+yytext[yyleng - 2] = '\n';
+YYCHOP();
+}
IMCC_INFO(interp)-heredoc_content =
mem_sys_realloc(IMCC_INFO(interp)-heredoc_content,
strlen(IMCC_INFO(interp)-heredoc_content) +
@@ -154,7 +158,7 @@
strlen(IMCC_INFO(interp)-heredoc_content), yytext);
}
-heredoc2.* {
+heredoc2[^\r\n]* {
/* Are we at the end of the heredoc? */
if (strcmp(IMCC_INFO(interp)-heredoc_end, yytext) == 0)
{
Index: config/gen/makefiles/root.in
===
--- config/gen/makefiles/root.in(revision 16381)
+++ config/gen/makefiles/root.in(working copy)
@@ -1198,6 +1198,8 @@
$(IMCC_O_FILES) : $(IMCC_H_FILES) $(ALL_H_FILES)
+$(IMCC_DIR)/main$(O) : $(IMCC_O_FILES)
+
###
#
# Documentation targets:
Re: 99 problems in Perl6: 32 and a question on number coercion
Steffen Schwigon ha scritto: Hi! gabriele renzi [EMAIL PROTECTED] writes: Hi everyone! I solved the (easy) problem 32, implementing gcd($a,$b). You can check the code in the repository or on the web[1] I looked at [1]. What's the purpose of multi in this case? (Maybe you wanted to write it as more than one subs, did you?) look the comment: # Yet, it should be possible to define it even for commutative rings # other than Integers, so we use a multi sub. I think that in these examples we should respect the old good programmin' habits, including the stay open for extension idea. If we'd use a normal sub we would limit all the future user of gcd (which I expect to be legions ;) to using Int. snip Could someone explain me what is the expected behaviour? Last time I experimented with this, the type system in Pugs looked unfinished. Type constraints were syntactically accepted but worked similar to typeless code in Perl5. I'm not sure about the current state. I see Anyway, in your example I hadn't expected a value coercion (from 10.1 to 10), but something like an error if the type doesn't match. this is what I'd like to see too, since I think it could help avoiding casual errors, and the extensibility of the system is still safe because of the multi things. But I remember reading that, by default, perl6 will try to autocoerce arguments. -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com jabber : rff.rff at gmail dot com
Re: 99 problems in Perl6: 32 and a question on number coercion
gabriele renzi [EMAIL PROTECTED] writes: Steffen Schwigon ha scritto: I looked at [1]. What's the purpose of multi in this case? (Maybe you wanted to write it as more than one subs, did you?) look the comment: # Yet, it should be possible to define it even for commutative rings # other than Integers, so we use a multi sub. Damn, I ignored the comment as if it were my own. :-) Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/ Deutscher Perl-Workshop http://www.perl-workshop.de/
Re: [svn:parrot-pdd] r16036 - trunk/docs/pdds/clip
On Wed, Dec 06, 2006 at 06:30:35PM -0800, [EMAIL PROTECTED] wrote: +Recognizing the fact that ports depend on volunteer labor, the minimum +requirements for the 1.0 launch of Parrot are portability to major +versions of Linux, BSD, Mac OS X, and Windows released within 2 years +prior to the 1.0 release. As we approach the 1.0 release we will +actively seek porters for as many other platforms as possible. There is the potential for satisfying those requirements entirely with x86 ILP32 systems, potentially using only 2 different compilers, which wouldn't be fab for ensuring portability :-( I would think that Sparc Solaris, building 64 bit, would be the best single target to aim for to increase portability spread. Nicholas Clark
[perl #41168] graceful no compiler error message?
# New Ticket Created by Will Coleda # Please include the string: [perl #41168] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41168 It would be nice if configure.pl gracefully handled the error condition of no compiler found. At the moment, it seems to try to stumble through several attempts at compilation for the various config steps, generating a lot of error messages.
Re: [svn:parrot-pdd] r16036 - trunk/docs/pdds/clip
On Wed, Jan 03, 2007 at 03:43:17PM +, Nicholas Clark wrote: On Wed, Dec 06, 2006 at 06:30:35PM -0800, [EMAIL PROTECTED] wrote: +Recognizing the fact that ports depend on volunteer labor, the minimum +requirements for the 1.0 launch of Parrot are portability to major +versions of Linux, BSD, Mac OS X, and Windows released within 2 years +prior to the 1.0 release. As we approach the 1.0 release we will +actively seek porters for as many other platforms as possible. There is the potential for satisfying those requirements entirely with x86 ILP32 systems, potentially using only 2 different compilers, which wouldn't be fab for ensuring portability :-( I would think that Sparc Solaris, building 64 bit, would be the best single target to aim for to increase portability spread. Actually, I was thinking this could be accomplished with gcc only on all of these environments. That, however, would be very bad. Steve Peters [EMAIL PROTECTED]
Re: [svn:parrot-pdd] r16036 - trunk/docs/pdds/clip
On Wednesday 03 January 2007 07:43, Nicholas Clark wrote: I would think that Sparc Solaris, building 64 bit, would be the best single target to aim for to increase portability spread. Porters welcome! -- c
[perl #41171] [PATCH] Fix to t/src/compiler.t so Parrot passes tests on Solaris
# New Ticket Created by Steve Peters # Please include the string: [perl #41171] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41171 The Solaris C compiler really dislikes it when returning a value from a void function. The patch below fixes it. Steve Peters [EMAIL PROTECTED] --- t/src/compiler.t.oldWed Jan 3 14:19:23 2007 +++ t/src/compiler.tWed Jan 3 14:19:58 2007 @@ -221,7 +221,6 @@ interp-resume_offset = dest -interp-code-base.data; /* and go */ Parrot_runcode(interp, argc, argv); -return NULL; } static opcode_t *
Re: [svn:parrot-pdd] r16036 - trunk/docs/pdds/clip
Am Mittwoch, 3. Januar 2007 16:43 schrieb Nicholas Clark: I would think that Sparc Solaris, building 64 bit, would be the best single target to aim for to increase portability spread. During the last few releases I did, I built/tested with gcc and sun cc on the z1.t2000... box, but it seems to be unavailable now. Is it gone? leo
Re: [svn:parrot-pdd] r16036 - trunk/docs/pdds/clip
On Wed, Jan 03, 2007 at 10:19:23PM +0100, Leopold Toetsch wrote: Am Mittwoch, 3. Januar 2007 16:43 schrieb Nicholas Clark: I would think that Sparc Solaris, building 64 bit, would be the best single target to aim for to increase portability spread. During the last few releases I did, I built/tested with gcc and sun cc on the z1.t2000... box, but it seems to be unavailable now. Is it gone? I asked a few days ago, and was told that it's in the rack but currently powered off, and annoyingly refusing to believe that it's connected with the right sort of cable to do a remote power up. As the remote power up isn't working, someone will turn it on when they next visit. Nicholas Clark
[perl #41173] [PATCH] Intel C++ is not really gcc
# New Ticket Created by Steve Peters
# Please include the string: [perl #41173]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41173
The Intel C++ compile defines the __GNUC__ macro. This generally causes
lots of annoying problems since Intel C++ is not completely compatible
with gcc. To avoid this any problem with this, the following patch
should help both Linux and Mac OS X Intel compilers.
Steve Peters
[EMAIL PROTECTED]
--- config/auto/gcc/test_c.in.old 2007-01-03 22:28:24.0 -0600
+++ config/auto/gcc/test_c.in 2007-01-03 22:29:11.0 -0600
@@ -8,7 +8,7 @@
main(int argc, char **argv)
{
puts(();
-#ifdef __GNUC__
+#if defined(__GNUC__) ! defined(__INTEL_COMPILER)
printf(__GNUC__ = %d,\n, __GNUC__);
# ifdef __GNUC_MINOR__
printf(__GNUC_MINOR__ =%d,\n, __GNUC_MINOR__);
[perl #41174] [PATCH] Silence warnings in
# New Ticket Created by Steve Peters
# Please include the string: [perl #41174]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41174
In compilers/imcc/main.c, there are several cases of where 0 is used
as an enum value without being cast. This causes warnings in the
Intel C++ compiler. The patch below silences these warnings.
Steve Peters
[EMAIL PROTECTED]
--- compilers/imcc/main.c.old 2007-01-03 22:51:53.0 -0600
+++ compilers/imcc/main.c 2007-01-03 22:55:53.0 -0600
@@ -153,35 +153,35 @@
#define OPT_RUNTIME_PREFIX 132
static struct longopt_opt_decl options[] = {
-{ '.', '.', 0, { --wait } },
-{ 'C', 'C', 0, { --CGP-core } },
+{ '.', '.', (OPTION_flags)0, { --wait } },
+{ 'C', 'C', (OPTION_flags)0, { --CGP-core } },
{ 'D', 'D', OPTION_optional_FLAG, { --parrot-debug } },
-{ 'E', 'E', 0, { --pre-process-only } },
-{ 'G', 'G', 0, { --no-gc } },
+{ 'E', 'E', (OPTION_flags)0, { --pre-process-only } },
+{ 'G', 'G', (OPTION_flags)0, { --no-gc } },
{ 'O', 'O', OPTION_optional_FLAG, { --optimize } },
-{ 'S', 'S', 0, { --switched-core } },
-{ 'V', 'V', 0, { --version } },
-{ '\0', OPT_DESTROY_FLAG, 0, { --leak-test, --destroy-at-end } },
-{ '\0', OPT_GC_DEBUG, 0, { --gc-debug } },
-{ 'a', 'a', 0, { --pasm } },
-{ 'b', 'b', 0, { --bounds-checks, --slow-core } },
-{ 'c', 'c', 0, { --pbc } },
+{ 'S', 'S', (OPTION_flags)0, { --switched-core } },
+{ 'V', 'V', (OPTION_flags)0, { --version } },
+{ '\0', OPT_DESTROY_FLAG, (OPTION_flags)0, { --leak-test,
--destroy-at-end } },
+{ '\0', OPT_GC_DEBUG, (OPTION_flags)0, { --gc-debug } },
+{ 'a', 'a', (OPTION_flags)0, { --pasm } },
+{ 'b', 'b', (OPTION_flags)0, { --bounds-checks, --slow-core } },
+{ 'c', 'c', (OPTION_flags)0, { --pbc } },
{ 'd', 'd', OPTION_optional_FLAG, { --imcc-debug } },
-{ '\0', OPT_HELP_DEBUG, 0, { --help-debug } },
-{ 'f', 'f', 0, { --fast-core } },
-{ 'g', 'g', 0, { --computed-goto-core } },
-{ 'h', 'h', 0, { --help } },
-{ 'j', 'j', 0, { --jit-core } },
+{ '\0', OPT_HELP_DEBUG, (OPTION_flags)0, { --help-debug } },
+{ 'f', 'f', (OPTION_flags)0, { --fast-core } },
+{ 'g', 'g', (OPTION_flags)0, { --computed-goto-core } },
+{ 'h', 'h', (OPTION_flags)0, { --help } },
+{ 'j', 'j', (OPTION_flags)0, { --jit-core } },
{ 'o', 'o', OPTION_required_FLAG, { --output } },
-{ '\0', OPT_PBC_OUTPUT, 0, { --output-pbc } },
-{ 'p', 'p', 0, { --profile } },
-{ 'r', 'r', 0, { --run-pbc } },
-{ '\0', OPT_RUNTIME_PREFIX, 0, { --runtime-prefix } },
+{ '\0', OPT_PBC_OUTPUT, (OPTION_flags)0, { --output-pbc } },
+{ 'p', 'p', (OPTION_flags)0, { --profile } },
+{ 'r', 'r', (OPTION_flags)0, { --run-pbc } },
+{ '\0', OPT_RUNTIME_PREFIX, (OPTION_flags)0, { --runtime-prefix } },
{ 't', 't', OPTION_optional_FLAG, { --trace } },
-{ 'v', 'v', 0, { --verbose } },
-{ 'w', 'w', 0, { --warnings } },
-{ 'y', 'y', 0, { --yydebug } },
-{ 0, 0, 0, { NULL } }
+{ 'v', 'v', (OPTION_flags)0, { --verbose } },
+{ 'w', 'w', (OPTION_flags)0, { --warnings } },
+{ 'y', 'y', (OPTION_flags)0, { --yydebug } },
+{ 0, 0, (OPTION_flags)0, { NULL } }
};
static int
[perl #41175] [PATCH] Remove unused label
# New Ticket Created by Steve Peters # Please include the string: [perl #41175] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41175 src/inter_call.c has an unused label. The patch below removes it. Steve Peters [EMAIL PROTECTED] --- src/inter_call.c.old2007-01-03 23:24:52.0 -0600 +++ src/inter_call.c2007-01-03 23:25:15.0 -0600 @@ -266,7 +266,6 @@ argument doesn't array); } } -flatten: make_flattened(interp, st, p_arg); return; }
