Re: [perl #38217] r11124: Cygwin build fails
In message <[EMAIL PROTECTED]>, "Jonathan Worthington" writes: : Ugh. I'm currently doing a lot of stuff to get rid of .def files and : replace them with decorations in the code instead. You may have got : caught up in this (or maybe the changes have hurt cygwin in a way I : didn't anticipate). Anyway, please grab the latest source, make : realclean and have another go at building it. I've put in a whole load : more changes tonight. Not quite. At r11144 on Cygwin, I see [...] gcc -o miniparrot.exe -s -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:124: undefined reference to `_Parrot_revision' /home/gbacon/src/parrot/compilers/imcc/main.c:128: undefined reference to `_Parrot_config_revision' compilers/imcc/main.o: In function `main': /home/gbacon/src/parrot/compilers/imcc/main.c:475: undefined reference to `_imcc_init' /home/gbacon/src/parrot/compilers/imcc/main.c:500: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:557: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:585: undefined reference to `_yyin' compilers/imcc/main.o:/home/gbacon/src/parrot/compilers/imcc/main.c:596: more undefined references to `_yyin' follow 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 Greg
.const & HLL improvement
=head1 DESCRIPTION
This test file describes an improvement for the directive .const
when an HLL is using.
In Lua, all types are implemented as PMC,
no Lua type is mapped with Parrot primitive type.
Lua PMC are derived from existing PMC, for example :
pmclass LuaNumber extends Float does float dynpmc group lua_group hll Lua
maps Float
pmclass LuaFunction extends Sub does sub dynpmc group lua_group hll Lua
maps Sub
But the directive .const seems to support only Parrot PMC.
In Lua, functions are "first class values".
So, it's important to instanciate and initialize them
with the PMC LuaFunction.
Is it a dream ?
Is it a future & planned feature ?
Or is it possible with an other syntax ?
(Lua supports closure & coroutine, it's allow to check their implementation
in Parrot with another language.)
François Perrad.
=cut
use strict;
use Parrot::Test tests => 3;
use Test::More;
pir_output_is(<<'CODE', <<'OUT', '.const with Parrot PMC' );
.sub foo :main
.const .Integer i = "12"
$S0 = typeof i
print $S0
print "\n"
print i
print "\n"
.const .Sub _test = "_test"
$S0 = typeof _test
print $S0
print "\n"
$P0 = _test
$P0()
print "ok\n"
.end
.sub _test
print "test\n"
.end
CODE
Integer
12
Sub
test
ok
OUT
TODO: {
local $TODO = "my expected behavior";
pir_output_is(<<'CODE', <<'OUT', '.const with Lua PMC' );
.HLL "Lua", "lua_group"
.sub foo :main
.const .LuaNumber n = "12.34"
$S0 = typeof n
print $S0
print "\n"
print n
print "\n"
.const .LuaFunction _test = "_test"
$S0 = typeof _test
print $S0
print "\n"
$P0 = _test
$P0()
print "ok\n"
.end
.sub _test
print "test\n"
.end
CODE
number
12.34
function
test
ok
OUT
}
pir_output_is(<<'CODE', <<'OUT', 'my current usage with Lua' );
.HLL "Lua", "lua_group"
.sub foo :main
new $P0, .LuaNumber
$P0 = 12.34
$S0 = typeof $P0
print $S0
print "\n"
print $P0
print "\n"
.const .Sub _test = "_test"
new $P0, .LuaFunction # useless
$P0 = _test
$S0 = typeof $P0
print $S0
print "\n"
$P0()
print "ok\n"
.end
.sub _test
print "test\n"
.end
CODE
number
12.34
Sub
test
ok
OUT
Re: [perl #38217] r11124: Cygwin build fails
"Greg Bacon" <[EMAIL PROTECTED]> wrote: Not quite. At r11144 on Cygwin, I see [...] gcc -o miniparrot.exe -s -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:124: undefined reference to `_Parrot_revision' /home/gbacon/src/parrot/compilers/imcc/main.c:128: undefined reference to `_Parrot_config_revision' compilers/imcc/main.o: In function `main': /home/gbacon/src/parrot/compilers/imcc/main.c:475: undefined reference to `_imcc_init' These ones surprise me a bit. I'll have to have a poke around at where these are exported from and how they are (or maybe aren't) decorated. /home/gbacon/src/parrot/compilers/imcc/main.c:500: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:557: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:585: undefined reference to `_yyin' compilers/imcc/main.o:/home/gbacon/src/parrot/compilers/imcc/main.c:596: more undefined references to `_yyin' follow These however suggest that the .def file is maybe being ignored. Which is...odd. Info: resolving _yydebug by linking to __imp__yydebug (auto-import) Info: resolving _line by linking to __imp__line (auto-import) This is good to see. collect2: ld returned 1 exit status make: *** [miniparrot.exe] Error 1 I'll be cleaning up some more of this stuff later on today. Sorry about the breakage and thanks for testing. Jonathan
Re: declaration of 'clone'
Joshua Hoblitt wrote: On Thu, Jan 12, 2006 at 04:53:26PM +0100, Leopold Toetsch wrote: Klaas-Jan Stol wrote: Hi, I'm trying to implement some functions into the Lua PMCs, but I'm having trouble to compile them. I want to add a clone method to the LuaNil PMC (which should extend Null.pmc, not None.pmc, as it does currently; changed that already) However, I get the following error: luanil.c:343: error: conflicting types for `clone' /usr/include/bits/sched.h:72: error: previous declaration of `clone' compile luanil.c failed (256) clone is a standardized vtable function. But it's name is never a bare 'clone', it's always prefixed by 'Parrot__. This is also true for METHOD PMC* clone() # dunno if that works, if vtable exists You must have some bug in your PMC code. On Linux clone() is a syscall with a wraper function in the the standard library that is defined in sched.h. On my laptop types.h includes pthreadtypes.h which includes sched.h. You should *probably* use a different function name. ;) -J I got the bug already, thank! (stupid error in PMC file) Works perfectly now. -kj
Re: Changing argv to be a ResizableStringArray complications
On Jan 13, 2006, at 3:44, Joshua Isom wrote: With the attached patch, which changes argv to be a ResizableStringArray instead of an SArray, when argv reaches the pir execution, four null strings are prepended to argv. The SArray needs presizing (line 467), but still does push_string from the start. The ResizableStringArray is more regular, you just push items onto it. This was discussed some time ago. The main problem is that set_integer_native on arrays may have 2 different meanings: reserve storage or set the real size. leo
Re: .const & HLL improvement
On Jan 13, 2006, at 10:20, François PERRAD wrote: =head1 DESCRIPTION This test file describes an improvement for the directive .const when an HLL is using. Not really - see below. .const .Integer i = "12" The Integer PMC implements the constructor "new_from_string", which is called at compile time to create a possibly constant PMC item with the given value. PMC constants are frozen/thawed as usual, and above just works. The .const pmc directive is just sugar for set_p_pc Px, .const .Sub _test = "_test" A .Sub is a bit special, as the Sub PMC is already created, when a .sub directive is encountered during codegen. So this is again just a C opcode. .const .LuaNumber n = "12.34" I presume LuaNumber doesn't have new_from_string (Float hasn't either). .const .LuaFunction _test = "_test" Creation of Sub PMCs currently doesn't honor HLL mappings. There are a few hardcoded references of "Sub", "Closure", and "Coroutine" in the compiler and in packfile.c. These should be easily to spot. Explicit tests against enum_class_Sub need to be replaced by VTABLE_isa or _does. leo
[PATCH] Add new_from_string() to LuaNumber (was: Re: .const & HLL improvement)
.const .LuaNumber n = "12.34"
I presume LuaNumber doesn't have new_from_string (Float hasn't either).
Attached is a patch that implements new_from_string() for LuaNumber.
In my opinion it's handy to say:
.const .LuaNumber n = "12.34"
kind regards,
klaas-jan
--- languages/lua/classes/luanumber.pmc 2006-01-13 13:58:04.0 +0100
+++ languages/lua/classes/newluanumber.pmc 2006-01-13 14:02:49.0
+0100
@@ -67,6 +67,31 @@
return 1;
}
+/*
+
+=item C
+
+Return a LuaNumber PMC created from a string. Implementation
+is based on new_from_string() from Integer PMC.
+
+=cut
+
+*/
+
+PMC* new_from_string(STRING *rep, INTVAL flags) {
+INTVAL type;
+PMC *res;
+
+type = SELF->vtable->base_type;
+if (flags & PObj_constant_FLAG)
+res = constant_pmc_new(INTERP, type);
+else
+res = pmc_new(INTERP, type);
+
+PMC_num_val(res) = string_to_num(INTERP, rep);
+return res;
+}
+
}
/*
[PROPOSAL] named arguments
Below are some thoughts, syntax mainly, how it could look like.
leo
Proposal: Named Arguments
pdd03 is already mentioning named arguments, but a concrete syntax
is still missing, as well as how it could work.
First a snippet of the proposed syntax:
.sub named_test :main
.local pmc a, b, c, h
a = new .Integer
a = 1
b = new .Integer
b = 2
b = new .Integer
c = 3
# all these calls do the same
foo(a, "c" => c, "b" => b)
bar(a, c :named('c'), b :named('b'))
baz(a, "c" => c, "b" => b)
h = new .Hash
h['c'] = c
h['b'] = b
foo(a, h :named :flat) # **kw
.end
.sub foo
.param pmc a# 1
.param pmc berta :named('b')# 2
.param pmc 'c' => c # 3
.end
.sub bar
.param pmc a
.param pmc berta :named('b')# 2
.param pmc h :named :slurpy # slurpy hash **kw / %_
# { 'c' => 3 }
.end
.sub baz
.param pmc a
.param pmc d :optional # positionell
.param int has_d :opt_flag # 0
.param pmc berta :named('b') # 2
.param pmc c :named('c') # 3
.param pmc e :named('e') :optional# Null
.param int has_e :opt_flag # 0
.end
Some remarks:
- 'name' => var is the same as: var :named('name')
(we can implement one of these or both)
- the semantics are roughly these of Python 5.3.4 Calls
http://docs.python.org/ref/calls.html
More detailed semantics will probably emanate from a reference
implementation.
At argument opcodes level, a named argument are 2 items: name, var,
where the String 'name' is marked with the :named bit, e.g.:
set_args '(0, 0x80, 0, 0x80, 0)', a, 'c', c, 'b', b
A keyword or slurpy hash is just a pmc argument with both the
:flat/:slurpy bit and the :named bit set.
set_args '(0, 0x88)', a, h
Comments welcome,
leo
[PATCH] changes for LuaNil
This patch changes LuaNil PMC, it used to be a singleton, this patch
makes it a normal PMC.
some other methods are implemented for morphing into other Lua types
(LuaString, LuaNumber, LuaBoolean).
regards,
klaas-jan
--- languages/lua/classes/luanil.pmc2006-01-13 16:34:42.0 +0100
+++ languages/lua/classes/newluanil.pmc 2006-01-13 16:37:36.0 +0100
@@ -1,130 +1,184 @@
-/*
-Copyright: 2005 The Perl Foundation. All Rights Reserved.
-$Id: luanil.pmc 10933 2006-01-06 01:43:24Z particle $
-
-=head1 NAME
-
-classes/luanil.pmc - Lua Nil
-
-=head1 DESCRIPTION
-
-C extends C to provide a class with the behaviour of
-the Lua C value.
-
-=head2 Overloaded Methods
-
-=over 4
-
-=cut
-
-*/
-
-#include "parrot/parrot.h"
-
-static STRING *string_representation;
-static PMC *Lua_Nil;
-
-pmclass LuaNil
-singleton
-extends None
-dynpmc
-group lua_group
-hll Lua {
-
-/* Class initialization. Caches constant strings that will be used later.
-*/
-void class_init() {
-if (pass) {
-string_representation = const_string(INTERP, "nil");
-}
-}
-
-/*
-
-=item C
-
-Return the string "nil".
-
-=cut
-
-*/
-STRING* name () {
-return string_representation;
-}
-
-/*
-
-=item C
-
-Return the string "nil".
-
-=cut
-
-*/
-STRING* get_string () {
-return string_representation;
-}
-
-/*
-
-=item C
-
-Return the string "nil".
-
-=cut
-
-*/
-STRING* get_repr () {
-return string_representation;
-}
-
-/*
-
-=item C
-
-=item C
-
-These two functions are part of the singleton creation interface. For more
-information see F.
-
-=cut
-
-*/
-void* get_pointer() {
-return Lua_Nil;
-}
-
-void set_pointer(void* ptr) {
-Lua_Nil = (PMC*)ptr;
-}
-
-/*
-
-=item C
-
-Return always true.
-
-=cut
-
-*/
-PMC* logical_not (PMC* dest) {
-if (!dest)
-dest = pmc_new(INTERP, Parrot_PMC_typenum(INTERP, "LuaBoolean"));
-VTABLE_set_integer_native(INTERP, dest, 1);
-return dest;
-}
-
-}
-
-/*
-
-=back
-
-=head1 AUTHORS
-
-Original code by Klaas-Jan Stol.
-
-=cut
-
-*/
-
+/*
+Copyright: 2005 The Perl Foundation. All Rights Reserved.
+$Id: luanil.pmc 10933 2006-01-06 01:43:24Z particle $
+
+=head1 NAME
+
+classes/luanil.pmc - Lua Nil
+
+=head1 DESCRIPTION
+
+C provides a class with the behaviour of the Lua C value.
+Implementation is based on the Undef PMC. LuaNil is no longer a singleton;
+this would be a problem, as all uninitialized values in Lua are LuaNil.
+If some value is assigned, the LuaNil should morph into the correct type,
+and so a new PMC is constructed anyway. Therefore, we may as well create
+a new PMC right away. Also, creating a new PMC from a singleton class is
+troublesome (if not possible?).
+
+
+
+=head2 Overloaded Methods
+
+=over 4
+
+=cut
+
+*/
+
+#include "parrot/parrot.h"
+
+static STRING *string_representation;
+static INTVAL dynclass_LuaNumber;
+static INTVAL dynclass_LuaString;
+static INTVAL dynclass_LuaBoolean;
+
+pmclass LuaNil
+dynpmc
+group lua_group
+hll Lua {
+
+/*
+* Class initialization. Caches constant strings that will be used later.
+*/
+void class_init() {
+if (pass) {
+string_representation = const_string(INTERP, "nil");
+ dynclass_LuaNumber = Parrot_PMC_typenum(INTERP, "LuaNumber");
+ dynclass_LuaString = Parrot_PMC_typenum(INTERP, "LuaString");
+ dynclass_LuaBoolean = Parrot_PMC_typenum(INTERP, "LuaBoolean");
+}
+}
+
+/*
+
+=item C
+
+Return the string "nil".
+
+=cut
+
+*/
+STRING* name () {
+return string_representation;
+}
+
+/*
+
+=item C
+
+Return the string "nil".
+
+=cut
+
+*/
+STRING* get_string () {
+return string_representation;
+}
+
+
+
+
+
+
+/*
+
+=item C
+
+Return the string "nil".
+
+=cut
+
+*/
+STRING* get_repr () {
+return string_representation;
+}
+
+
+PMC* clone () {
+PMC* dest = pmc_new(INTERP, SELF->vtable->base_type);
+memcpy(&PMC_union(dest), &PMC_union(SELF), sizeof(UnionVal));
+return dest;
+}
+
+
+
+/*
+
+=item C
+
+Return always true.
+
+=cut
+
+*/
+PMC* logical_not (PMC* dest) {
+if (!dest)
+dest = pmc_new(INTERP, dynclass_LuaBoolean);
+VTABLE_set_integer_native(INTERP, dest, 1);
+return dest;
+}
+
+/*
+
+=item C
+
+"nil" in Lua is always undefined.
+
+=cut
+
+*/
+INTVAL defined() {
+return 0;
+}
+
+/*
+
+=item C
+
+=item C
+
+=item C
+
+Methods to set a new value to this LuaNil PMC. First,
+this PMC is morph'ed into the correct Lua type.
+
+=item C
+
+Morph to another Lua type.
+
+=cut
+
+*/
+void set_number_native(FLOATVAL value) {
+VTABLE_morph(INTERP, SELF, dynclass_LuaNumber);
+VTABLE_set_number_native(INTERP, SELF, value);
+}
+
+void set_string_native(STRING *value) {
+VTABLE_morph(INTERP, SELF, dynclass_LuaString);
+VTABLE_set_st
[PATCH] Changes for LuaTable
this patch changes the behaviour of the LuaTable PMC.
changes have to do with the reference semantics that PMCs have, and
LuaTables should not have.
Setting and getting a value now will set (and get) a copy of the value.
Clone() returns a reference to itself, as clone() should be used for
register to register copying (due to the by-value semantics of Lua values)
regards,
klaas-jan
--- languages/lua/classes/luatable.pmc 2006-01-13 16:34:42.0 +0100
+++ languages/lua/classes/newluatable.pmc 2006-01-13 16:37:42.0
+0100
@@ -68,6 +68,31 @@
return Parrot_sprintf_c(INTERP, "table: %08X", SELF);
}
+
+/*
+
+=item C
+
+PMCs are always handled by-reference in Parrot. So, copying register contents
only copies
+the reference to the PMC. For LuaString, LuaNumber, LuaBoolean, this is not
correct,
+as Lua has by-value semantics for these types. In order to be able to handle
register
+"move" instructions, this should be implemented using clone(). However,
LuaTable and LuaFunction
+do have by-reference semantics. As you don't know the type during compile-time
of an object,
+just always use clone() to copy register contents. LuaTable and LuaFunction
should therefore
+only clone the reference to themselves, not make a deep copy.
+
+=cut
+
+*/
+
+ PMC* clone() {
+ return SELF;
+ }
+
+
+
+
+
/*
=item C
@@ -90,6 +115,13 @@
C accessor.
+A copy of the value is retrieved, otherwise, this could happen:
+
+ temp = table[key]
+ temp =
+ temp2 = table[key]
+ # temp2 is now due to the by-reference semantics of
PMCs
+
=cut
*/
@@ -97,9 +129,10 @@
PMC *retval = SUPER(key);
if (enum_class_None == retval->vtable->base_type) {
-return Lua_Nil;
+return Lua_Nil; /* should we create a New LuaNil object every
time? Or is returning the same LuaNil over and over again ok? */
}
-return retval;
+ PMC *newcopy = retval->vtable->clone(INTERP, retval);
+return newcopy;
}
/*
@@ -108,22 +141,36 @@
C mutator.
+A copy of the value is stored, otherwise, this could happen:
+
+ table[key] = value
+ value =
+ temp = table[key]
+ # temp is now due to the by-reference semantics of
PMCs
+
=cut
*/
void set_pmc_keyed (PMC* key, PMC* value) {
-if (key == Lua_Nil) {
+
+ /* XXX should check for "isa", not equality with "==", since LuaNil is
no singular anymore */
+
+ if (key == Lua_Nil) {
real_exception(INTERP, NULL, 1, "table index is nil");
}
+
if (value == Lua_Nil) {
Hash.SELF.delete_keyed(key);
-} else {
-SUPER(key, value);
+}
+ else {
+
+ PMC *newcopy = value->vtable->clone(INTERP, value);
+ SUPER(key, newcopy);
}
}
/*
-
+0
=item C
Return always false.
@@ -150,6 +197,8 @@
return (PMC*)0;
}
+/* TODO: Implement the Metamethod mechanism, see the Lua ref.man. */
+
PMC* subtract (PMC* value, PMC* dest) {
return (PMC*)0;
}
Re: [perl #38217] r11124: Cygwin build fails
On 1/13/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote: > "Greg Bacon" <[EMAIL PROTECTED]> wrote: > > Not quite. At r11144 on Cygwin, I see > > > > [...] > > gcc -o miniparrot.exe -s -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:124: undefined reference to > > `_Parrot_revision' > > /home/gbacon/src/parrot/compilers/imcc/main.c:128: undefined reference to > > `_Parrot_config_revision' > > compilers/imcc/main.o: In function `main': > > /home/gbacon/src/parrot/compilers/imcc/main.c:475: undefined reference to > > `_imcc_init' > These ones surprise me a bit. I'll have to have a poke around at where > these are exported from and how they are (or maybe aren't) decorated. > > > /home/gbacon/src/parrot/compilers/imcc/main.c:500: undefined reference to > > `_yyin' > > /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to > > `_yyin' > > /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to > > `_yyin' > > /home/gbacon/src/parrot/compilers/imcc/main.c:557: undefined reference to > > `_yyin' > > /home/gbacon/src/parrot/compilers/imcc/main.c:585: undefined reference to > > `_yyin' > > compilers/imcc/main.o:/home/gbacon/src/parrot/compilers/imcc/main.c:596: > > more undefined references to `_yyin' follow > These however suggest that the .def file is maybe being ignored. Which > is...odd. > > > Info: resolving _yydebug by linking to __imp__yydebug (auto-import) > > Info: resolving _line by linking to __imp__line (auto-import) > This is good to see. > Strange, my version of cygwin links, but pops up a Windows dialog box with the first unresolved symbol when run. Same ultimate problem though. Out of interest, given that cygwin can export all symbols or just specified ones, does anyone have any strong feelings which it should do? It looks like it's possible to remove the sym_export/sym_import hints to complete the build. Unless someone wants this done urgently, it might be worth holding back so that we can see symbols that might otherwise be missed. Nick
Building tcl fails on darwin (undefined symbol in parrot)
I tried building tcl today but got a failure in parrot, undefined symbol. It happens when first outputting the first pbc. I did a distclean and reconfigured without optimize or using ccache, but that didn't help. 'make dynclasses-test' tests dynlexpad and foo without problems(I did have to edit the Makefile to change the cwd to the right directory), but only pybuiltin.pmc uses Parrot_PMC_typenum. perl tools/gen_lib.pl tcl.pir_template > lib/tcllib.pir ../../parrot --output=lib/tcllib_temp.pbc lib/tcllib.pir dyld: ../../parrot Undefined symbols: _Parrot_PMC_typenum make: *** [lib/tcllib_temp.pbc] Trace/BPT trap
Re: [PROPOSAL] named arguments
On Fri, 2006-01-13 at 14:29 +0100, Leopold Toetsch wrote:
> Proposal: Named Arguments...
Your proposal covers all the functionality that I need for Amber,
thanks.
> b = new .Integer
> c = 3
I'm sure everyone realised, but just for the sake of completeness: the
first identifier above should be 'c'.
> - 'name' => var is the same as: var :named('name')
> (we can implement one of these or both)
Either syntax is fine for me. Might also want:
'name' => 'var' -or- 'var' :named('name')
for cases where 'var' has the same name as a PIR keyword.
On Nov 30, Chip wrote:
> Leo, would you be so kind as to rescind the parameter passing error
> flags, and make mismatches always throw? ...
> users can use :slurpy on an unused register to mean "extra params OK".
Any chance of making the above change first? Or at least making argument
count mismatch detection work with '.param'? (We're always being told
that compilers should emit PIR not PASM, and - although it's not a big
deal - I'll need a second pass through my argument lists to generate the
'get_params' version).
Regards,
Roger Browne
Re: [PROPOSAL] named arguments
On 1/13/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Below are some thoughts, syntax mainly, how it could look like. > > Proposal: Named Arguments > [snip proposal] > > Comments welcome, > leo > it's not stated explicitly in your proposal, but what is the proper location for named params in a sub call? i expect something like "named arguments must follow all positional (required and optional) arguments in a sub or method call". also, will nci support named arguments, or is this strictly for method and sub calls? i suspect not, but it's worth asking. ~jerry
Re: [PROPOSAL] named arguments
jerry gay wrote: it's not stated explicitly in your proposal, but what is the proper location for named params in a sub call? i expect something like "named arguments must follow all positional (required and optional) arguments in a sub or method call". You pass arguments to a function. That receives params. But yes, basically like above and like stated in the mentioned Python doc. also, will nci support named arguments, or is this strictly for method and sub calls? i suspect not, but it's worth asking. No, I've no plans for supporinting named args for C code ~jerry leo
argument count mismatch
On Fri, 2006-01-13 at 17:01 +0100, Leopold Toetsch wrote: > ... making argument > > count mismatch detection work with '.param'? > > That's as easy as emitting one instruction in main: > >errorson 0x0C Wow, it really does work. Thanks! Although it misses the case where the called sub has zero .params: .sub 'main' :main errorson 0x0C foo(5) .end .sub foo print "Not OK\n" .end > 885/4851 subtests failing, 81,76% okay. Wow, that's a lot of tests affected by this one thing. Regards, Roger Browne
Re: [PROPOSAL] named arguments
Roger Browne wrote: On Fri, 2006-01-13 at 14:29 +0100, Leopold Toetsch wrote: Proposal: Named Arguments... Your proposal covers all the functionality that I need for Amber, thanks. Great. Leo, would you be so kind as to rescind the parameter passing error flags, and make mismatches always throw? ... users can use :slurpy on an unused register to mean "extra params OK". Any chance of making the above change first? Or at least making argument count mismatch detection work with '.param'? That's as easy as emitting one instruction in main: errorson 0x0C But yes, we should make that the default after at least the test suite is fixed. 885/4851 subtests failing, 81,76% okay. Regards, Roger Browne leo
Re: argument count mismatch
Roger Browne wrote: Wow, it really does work. Thanks! Although it misses the case where the called sub has zero .params: .sub 'main' :main errorson 0x0C foo(5) .end .sub foo print "Not OK\n" .end Yep. There is currently just one reason for that and it's in your code too :-) .sub main :main .param pmc argv # implicitely very :optional That is, if no '.param' is present, currently no get_params is emitted alas no error checking and no exception. This could be fixed by special-casing the initial call to ':main', and then turn on param count checks if wanted. I'll have a look at it tomorrow, if no one beats me. Regards, Roger Browne leo
Re: argument count mismatch
On 1/13/06, Roger Browne <[EMAIL PROTECTED]> wrote: > On Fri, 2006-01-13 at 17:01 +0100, Leopold Toetsch wrote: > > > 885/4851 subtests failing, 81,76% okay. > > Wow, that's a lot of tests affected by this one thing. > most of them are in the PGE tests. since there are over 1,300 PGE tests, and and about 750 of these test failures are PGE failures, this is more limited that it may look. but i can say that this feature is definitely well tested, however indirectly that may be :) i'll fix PGE, which will leave only about 135 failures, many of which are in library code (no surprise there.) with a little help, i think we can squash these failures in no time. who's up for some bug hunting? ~jerry
Re: argument count mismatch
On 1/13/06, jerry gay <[EMAIL PROTECTED]> wrote: > i'll fix PGE, which will leave only about 135 failures, many of which > are in library code (no surprise there.) with a little help, i think > we can squash these failures in no time. > on second thought... before i go diving into PGE to fix something that's still unclear to me, why don't i back up a bit and get things cleared up. applying the attached patch, rebuilding, and running 'prove -v t/compilers/imcc/syn/pcc.t' should show you some failing TODO tests where i'm unclear as to what the results should be. i believe after all these tests are passing, we'll have a full test of what the specification for mismatched parameter handling should be for regular subs. i think there's still something missing from mismatched parameter handling with coroutines (please see pcc.t test 7,) but let's handle one thing at a time. ~jerry
[perl #38225] Building tcl fails on darwin (undefined symbol in parrot)
# New Ticket Created by Joshua Isom # Please include the string: [perl #38225] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38225 > I tried building tcl today but got a failure in parrot, undefined symbol. It happens when first outputting the first pbc. I did a distclean and reconfigured without optimize or using ccache, but that didn't help. 'make dynclasses-test' tests dynlexpad and foo without problems(I did have to edit the Makefile to change the cwd to the right directory), but only pybuiltin.pmc uses Parrot_PMC_typenum. perl tools/gen_lib.pl tcl.pir_template > lib/tcllib.pir ../../parrot --output=lib/tcllib_temp.pbc lib/tcllib.pir dyld: ../../parrot Undefined symbols: _Parrot_PMC_typenum make: *** [lib/tcllib_temp.pbc] Trace/BPT trap
Pattern matching and "for" loops
Today I wrote some perl5 code for the umpteenth time. Basically:
for( my $i=0; $i< $#ARGV; $i++ )
{
next unless $ARGV[$i] eq "-f";
$i++;
$ARGV[$i] = absolute_filename $ARGV[$i];
}
chdir "foo";
exec "bar", @ARGV;
I'm trying to work out if there's a clever perl6 way to write this using
pattern matching:
for @*ARGV -> "-f", $filename {
$filename .= absolute_filename;
}
Would this actually work, or would it stop at the first elem that
doesn't match ("-f", ::Item)?
Is there some way to associate alternate codeblocks for different
patterns (i.e. local anonymous MMD)?
Dave.
(ps. if anyone on this list is looking for a $perl_job in Santa Clara,
CA, please contact me by email: dwhipp at nvidia -- no promises, but we
might even pay you to work on p6)
Re: Pattern matching and "for" loops
Dave Whipp wrote:
> Today I wrote some perl5 code for the umpteenth time. Basically:
>
> for( my $i=0; $i< $#ARGV; $i++ )
> {
> next unless $ARGV[$i] eq "-f";
> $i++;
> $ARGV[$i] = absolute_filename $ARGV[$i];
> }
> chdir "foo";
> exec "bar", @ARGV;
>
> I'm trying to work out if there's a clever perl6 way to write this
> using pattern matching:
>
> for @*ARGV -> "-f", $filename {
> $filename .= absolute_filename;
> }
>
> Would this actually work, or would it stop at the first elem that
> doesn't match ("-f", ::Item)?
>
> Is there some way to associate alternate codeblocks for different
> patterns (i.e. local anonymous MMD)?
>
>
That's given/when. I seem to recall that C and C do not
topicalize the same way, by design, but my recollection may be dated.
If I'm wrong, then:
for ... { when "-f" { ... }}
If I'm right, then there is probably an argument for a standalone "when"
that uses the default topic, or for some sort of shorthand to coerce a
unified topicalization.
=Austin
Re: [perl #38225] Building tcl fails on darwin (undefined symbol in parrot)
"Joshua Isom (via RT)" <[EMAIL PROTECTED]> wrote: I tried building tcl today but got a failure in parrot, undefined symbol. It happens when first outputting the first pbc. I did a distclean and reconfigured without optimize or using ccache, but that didn't help. 'make dynclasses-test' tests dynlexpad and foo without problems(I did have to edit the Makefile to change the cwd to the right directory), but only pybuiltin.pmc uses Parrot_PMC_typenum. perl tools/gen_lib.pl tcl.pir_template > lib/tcllib.pir ../../parrot --output=lib/tcllib_temp.pbc lib/tcllib.pir dyld: ../../parrot Undefined symbols: _Parrot_PMC_typenum make: *** [lib/tcllib_temp.pbc] Trace/BPT trap Recently we stopped linking extend.obj into dynclasses. The meaning behind this is that functions in extend.c should not be used in dynclasses; leo explained on IRC that "these functions are just wrappers around existing other APIs and shouldn't be used inside Parrot code". Parrot_PMC_typenum has already been removed, thus why you got undefined symbols warning - the symbol doesn't exist any more. I've just ci'd changes to the tcl PMCs not to use Parrot_PMC_typenum and Parrot_call_sub, and they now build again here (and should elsewhere). (Note to Coke/mdiep: hope I fixed it right...) If you could verify that it now builds on darwin, this can be closed up. Thanks, Jonathan
Re: Pattern matching on arrays and "for" loops
On 1/13/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I'm trying to work out if there's a clever perl6 way to write this using
> pattern matching:
>
>for @*ARGV -> "-f", $filename {
> $filename .= absolute_filename;
>}
There is, but it's a different kind of pattern matching:
if @*ARGV ~~ / <,> -f <,> (.*?) <,> / {
$0 .= absolute_filename;
}
Of course, that only works if you're allowed to modify the source
through the $# variables. I think you are, but I'm not certain.
This is a good example of how silly the current array matching
semantics are. You'd get a match for this call, because of
"carelessness" in writing the rule.
davesprog foo - f file
Because elements are implicitly concatenated together. The "correct"
way to write the rule is:
/ <,> - f <,> (.*?) <,> /
Isn't that dumb?
Here's what I counterpropose: matching against arrays treats each
element of the array as a single character. <()>-assertions make the
current character their topic. There is no <,>; it's implicit in the
character-element unification. Here's the new regex:
/ <( $_ eq '-f' )>. (.) /
This method makes more sense for a list of tokens, too.
We could shuffle around the special assertions to give shorthands for
these presumably common constructs:
<( ... )>.
<( $_ eq ... )>.
<( $_ ~~ /.../ )>.
The last one is the most important. It allows you to connect regexes
on a stream to regexes on an element of the stream. Possible
shorthands for those, respectively:
<+( ... )> # treating an assertion as a char class
<'...'> # hmm, already takes, maybe we could
# make a special case because it
# doesn't make much sense for
# nonstrings
# obvious
> Would this actually work, or would it stop at the first elem that
> doesn't match ("-f", ::Item)?
If by "stop" you mean "die", yes it would stop.
> Is there some way to associate alternate codeblocks for different
> patterns (i.e. local anonymous MMD)?
As Austin points out, that's called "given". I'll also point out that
if we have lookahead in "for" (a feature that I think is best reserved
for third-party modules):
for @*ARGV -> $cur, ?$next is rw {
if $cur eq '-f' {
$next .= absolute_filename;
}
}
Which isn't as slick as a pattern matching approach, but it gets the
job done without having to use indices.
Luke
Array Holes
In perl 5: my @a = (1,2,3); delete $a[1]; print exists $a[1]; This is false, whereas $a[0] and $a[2] do exist. This is creepy. Not only is it creepy, it raises a whole bunch of questions with nontrivial answers: * does [EMAIL PROTECTED] include nonexistent elements? * does map iterate over nonexistent elements? * how do you store nonexistence for native packed arrays And, what I always say, if the proper abstractions are being used, then all decisions become obvious truths. Since the answers to these are not obvious truths, proper abstractions must not be in use. Anyway, I want this behavior to die. Maybe we should get rid of .delete() on arrays, or maybe we should equate it with .splice($idx,1). Luke
[svn ci] Languages fixes
Hi, * Fixed the Lua PMCs to no longer use the now-deprecated Parrot_PMC_typenum, so it builds. Also tested out how Lua handles on Win32 - basically it builds but all the tests give something like this:- -- lua\t\while...NOK 2# Failed test (lua\t\while.t at line 37) # got: 'Can't locate object method "bsstr" via package "Math::BigFloat" (perhaps you forgot to load "Math::BigFloat"?) at languages/lua/Lua/build.pm line 79, <$__ANONIO__> line 1. # Error reading source file languages/lua\t\while_2.pir. # ' # expected: 'one # two # three # ' # 'perl -Ilanguages/lua languages/lua/luac.pl languages/lua\t\while_2.lua && .\parrot.exe languages/lua\t\while_2.pir' failed with exit code 7. -- * m4 will now build on Win32. Get a 96% test rate. Jonathan
Re: [perl #38225] Building tcl fails on darwin (undefined symbol in parrot)
Well it fixed part of the parrot problem... Now I get a syntax error for tcl.pir, line 18, unexpected dot, so I'm guessing that .DynLexPad isn't set. I guess the little comment at the top, "therefore the .DynLexPad constant is already available" isn't quite true. Joshua On Jan 13, 2006, at 2:27 PM, Jonathan Worthington via RT wrote: "Joshua Isom (via RT)" <[EMAIL PROTECTED]> wrote: Recently we stopped linking extend.obj into dynclasses. The meaning behind this is that functions in extend.c should not be used in dynclasses; leo explained on IRC that "these functions are just wrappers around existing other APIs and shouldn't be used inside Parrot code". Parrot_PMC_typenum has already been removed, thus why you got undefined symbols warning - the symbol doesn't exist any more. I've just ci'd changes to the tcl PMCs not to use Parrot_PMC_typenum and Parrot_call_sub, and they now build again here (and should elsewhere). (Note to Coke/mdiep: hope I fixed it right...) If you could verify that it now builds on darwin, this can be closed up. Thanks, Jonathan
Re: Pattern matching on arrays and "for" loops
Luke Palmer wrote:
On 1/13/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
Would this actually work, or would it stop at the first elem that
doesn't match ("-f", ::Item)?
If by "stop" you mean "die", yes it would stop.
not what I wanted :-(
Is there some way to associate alternate codeblocks for different
patterns (i.e. local anonymous MMD)?
As Austin points out, that's called "given". I'll also point out that
if we have lookahead in "for" (a feature that I think is best reserved
for third-party modules):
for @*ARGV -> $cur, ?$next is rw {
if $cur eq '-f' {
$next .= absolute_filename;
}
}
Which isn't as slick as a pattern matching approach, but it gets the
job done without having to use indices.
What happens if I simply abandon the attempt at anonymous MMD and use a
named multi-sub, instead:
{
my multi sub process_arg("-f", Str $f is rw) {
$f .= absolute_filename
}
my multi sub process_arg("--quux", Str arg1, Str arg2) { ... }
...
my multi sub process_arg(Str _) {} # skip unrecognised args
for @*ARGV: &process_arg;
}
Re: Array Holes
On Fri, Jan 13, 2006 at 10:33:23PM +, Luke Palmer wrote:
> In perl 5:
>
> my @a = (1,2,3);
> delete $a[1];
> print exists $a[1];
>
> This is false, whereas $a[0] and $a[2] do exist. This is creepy. Not
> only is it creepy, it raises a whole bunch of questions with
> nontrivial answers:
>
> * does [EMAIL PROTECTED] include nonexistent elements?
> * does map iterate over nonexistent elements?
> * how do you store nonexistence for native packed arrays
>
> And, what I always say, if the proper abstractions are being used,
> then all decisions become obvious truths. Since the answers to these
> are not obvious truths, proper abstractions must not be in use.
>
> Anyway, I want this behavior to die. Maybe we should get rid of
> .delete() on arrays, or maybe we should equate it with
> .splice($idx,1).
I'm not sure if it came in as a side effect of pseudohashes. Sadly I no
longer have access to the AIX box where I built perl 5.000, so I can't
check what really old perl 5 makes of it. I have this hunch that
using exists on an array element is not legal syntax.
I have this vague memory that there's an even weirder piece of emergent
behaviour with arrays and exists, but I can't remember what it is. Possibly
something to do with extending arrays, but checking the source for av_exists
I can't work out any way to make it do even stranger things. Maybe it was
just this:
#!perl -w
use strict;
sub check {
my $array = shift;
printf "%d:", scalar @$array;
foreach (0..9) {
print exists $array->[$_] ? " Y" : " n";
}
print "\n";
}
my @a;
check [EMAIL PROTECTED];
my @b = @a;
check [EMAIL PROTECTED];
$#a=5;
check [EMAIL PROTECTED];
@b = @a;
check [EMAIL PROTECTED];
__END__
0: n n n n n n n n n n
0: n n n n n n n n n n
6: n n n n n n n n n n
6: Y Y Y Y Y Y n n n n
Some undefs are more equal than others.
Nicholas Clark
Re: Pattern matching on arrays and "for" loops
On 1/13/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
> What happens if I simply abandon the attempt at anonymous MMD and use a
> named multi-sub, instead:
>
> {
>my multi sub process_arg("-f", Str $f is rw) {
> $f .= absolute_filename
>}
>my multi sub process_arg("--quux", Str arg1, Str arg2) { ... }
>...
>my multi sub process_arg(Str _) {} # skip unrecognised args
>
>for @*ARGV: &process_arg;
> }
Oh, that's a clever way to process arguments. A module could probably
turn that into a nice declarative option parsing library.
Unfortuately, it the form you've written above, that doesn't work.
That's because process_arg does not have a well-defined arity, so
"for" doesn't know how many elements to pull of the list each time.
In order to do that correctly, there would have to be some very fine
communication between for and the signature pattern matcher.
I could definitely see a library doing this though:
getopts @*ARGV,
-> '-f', Str $f is rw {...},
-> '--quux', Str $arg1, Str $arg2 {...},
-> $ { }; # ignore
It is likely doable without any magic too wicked, too.
Luke
[svn ci]+ No more .def files
Hi, Today I've essentially completed the work on moving us from working with .def files, which list symbols to be exported, to just decorating them in the code. That includes the Parrot core, PMCs (core and dynamic) and ops (core and dynamic). One result of this is that functions that can be used in dynamic PMCs and dynops without expecting things to break on platforms (aka Win32) that need to explicitly mark what to export are now all marked in the header files with "PARROT_API". If you want to use a function that isn't marked with this, please mark it or consider whether it belongs in the Parrot extensions API. One day, when we get to a stable release I guess these labels will determine what extenders can use and expect to work in future versions. I will also write a script in the next couple of days to generate a list of symbols marked with PARROT_API, to make life easier if there are platforms that don't handle symbol decoration and do need an export list. Chip mentioned something about AIX needing this, but I don't think we have anyone building there at the moment? Thanks for your patience while I've been modifiying lots of header files and config stuff. Jonathan
Re: Pattern matching on arrays and "for" loops
On Fri, Jan 13, 2006 at 11:42:13PM +, Luke Palmer wrote:
: On 1/13/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
: > What happens if I simply abandon the attempt at anonymous MMD and use a
: > named multi-sub, instead:
: >
: > {
: >my multi sub process_arg("-f", Str $f is rw) {
: > $f .= absolute_filename
: >}
: >my multi sub process_arg("--quux", Str arg1, Str arg2) { ... }
: >...
: >my multi sub process_arg(Str _) {} # skip unrecognised args
: >
: >for @*ARGV: &process_arg;
: > }
:
: Oh, that's a clever way to process arguments. A module could probably
: turn that into a nice declarative option parsing library.
:
: Unfortuately, it the form you've written above, that doesn't work.
: That's because process_arg does not have a well-defined arity, so
: "for" doesn't know how many elements to pull of the list each time.
: In order to do that correctly, there would have to be some very fine
: communication between for and the signature pattern matcher.
:
: I could definitely see a library doing this though:
:
: getopts @*ARGV,
: -> '-f', Str $f is rw {...},
: -> '--quux', Str $arg1, Str $arg2 {...},
: -> $ { }; # ignore
:
: It is likely doable without any magic too wicked, too.
That doesn't seem sufficiently general. I'd rather see some context
that can apply a signature to the head of a list and treat the
"unslurped" part as unmatched. Maybe a "for" loop could be taught
to supply such a context, or a "when". Or maybe it's just the result
of embedding a sig inside a rule, or of matching a sig using ~~.
Basically, we just have to find a way to treat the sig as a pattern
that isn't anchored at the end.
Larry
Patch to have parrot use ResizableStringArray instead of SArray
With some recent additions to resizablestringarray.pmc, a perhaps very old todo can now be taken care of. It makes the proper changes to src/embed.c, and some necessary changes to tcl.pir(shift to a string instead of a pmc) and m4.pir(remove the work arounds, part for SArray, part for a fixed problem with Getopt/Obj.pir). With these changes, make test for parrot, m4, and tcl all pass. I'm not sure about other languages, but the biggest difference(without a patch to resizablestringarray.pmc) is that "$P0 = shift argv" won't work. Comments? SArray2ResizableStringArray.patch Description: Binary data
Re: Pattern matching and "for" loops
On 13/01/06 20:36, Dave Whipp wrote: Is there some way to associate alternate codeblocks for different patterns (i.e. local anonymous MMD)? Is it possible to have an anonymous multi sub? This would seem to require new syntax for combining two anonymous definitions. Of course we want everything to be first class, at least for feature bragging rights. Lexically scoped multi subs wouldn't require more syntax but I'm not sure how two multis of different scope types are combined. What counts as a fully redefinition, as partial redefinition and as an extension? It's 2am so ignore all gibberish, Brad -- In the words of the ancients, one should make his decisions within the space of seven breaths. Lord Takanobu said, "If discrimination is long, it will spoil." -- Hagakure
[PATCH] Restrict clear_eh to handlers in the current context
From: Bob Rogers <[EMAIL PROTECTED]> Date: Fri, 6 Jan 2006 23:22:19 -0500 If sub A pushes an error handler and then calls B, B can do a 'clear_eh' to get rid of A's handler. This seems to work until B returns, at which point the control stack unwinding done by RetContinuation destroys the rest of the stack looking for the missing handler. The patch detects the problem in clear_eh, and signals a real_exception . . . You could also argue that the stack unwinding in RetContinuation.invoke is broken. I tend to agree, but any such fix would be superceded by an implemention of rezipping. This pop_exception fix might also have to change, but probably only in detail. Just in case this patch is still under consideration, I would like to withdraw it; I think it's better to include it as part of the rezipping-related control stack cleanup (the design rev for which is still in progress). Unless somebody would like to see a patch with just the test cases, both marked 'TODO'? -- Bob Rogers http://rgrjr.dyndns.org/
Re: Array Holes
On Fri, Jan 13, 2006 at 10:33:23PM +, Luke Palmer wrote: : In perl 5: : : my @a = (1,2,3); : delete $a[1]; : print exists $a[1]; : : This is false, whereas $a[0] and $a[2] do exist. This is creepy. Not : only is it creepy, it raises a whole bunch of questions with : nontrivial answers: : : * does [EMAIL PROTECTED] include nonexistent elements? : * does map iterate over nonexistent elements? The answer in Perl 5 is "yes", but Perl 6 doesn't have to have the same default. In many ways you'd want a sparse array to behave more like a hash. But then how often do you ask a hash only for its values? Whatever the answer, it probably has to apply to my @a; @a[0] = '1'; @a[2] = '3'; print exists $a[1]; as well as the explicit delete case. Are we going to pitch an exception for writing beyond the end of an array? That seems a bit anti-Perlish. : * how do you store nonexistence for native packed arrays Well, packed arrays aren't the default, but obviously if you want to support sparseness in packed arrays you'd have to do something like one of: 1) Distinguish a value that doesn't "exist" (NaN, for instance). 2) Record the existence out-of-band, say, in a bitmap. 3) Only store "runs" of existing packed data. Approach #2 has the advantage that you can track definedness along with existence for native types that don't contain the Maybe concept. However, I think our default stance was that the user probably uses native types because they want things to run fast, so it's okay to pitch an exception if you ask a native type to remember something it's incapable of remembering. But "smart" native types are still a possibility. : And, what I always say, if the proper abstractions are being used, : then all decisions become obvious truths. Since the answers to these : are not obvious truths, proper abstractions must not be in use. Yeah, well... Abstractions are complete hypocrites--they make other things obvious while refusing to be obvious themselves. : Anyway, I want this behavior to die. Maybe we should get rid of : .delete() on arrays, or maybe we should equate it with : .splice($idx,1). Or maybe we support sparse arrays as one container type. I actually used a crowbar last week. It wasn't pretty, but it got the job done. Well, okay, it got the job started...I still have a hole in my living room wall, but my chief interest at the time was to make sure my house wasn't going to burn down. That's about as much abstraction as you could wish for in real life. Larry
