Re: Standard library for perl6? (graphical primitives)
Bryan Burgers wrote: On 10/15/05, Luke Palmer <[EMAIL PROTECTED]> wrote: On 10/14/05, Markus Laire <[EMAIL PROTECTED]> wrote: Perl does have CPAN, but the problem is that there are no standard modules, and so there can be several modules doing the same thing. And what is the problem with that? The problem may be that it doesn't work everywhere. What I find exciting about parrot is that (it sounds like to me) you'll be able to run a perl6 file anywhere that has parrot, much like Java. I think what Markus is getting at is for there to be a way to display graphics through parrot everywhere parrot runs as well. Yes, different modules are extremely important, because the programmer deserves a choice, but some modules run someplaces, others run other places - it'd be a good thing to have the absolute bare essentials run everywhere. Yes, I forgot to mention why I think it's a problem to have several modules to do the same thing - there's likely no single module which works everywhere. I'm not completely sure if it would be worth the trouble to support only most primitive graphical commands "in core", (no windows, etc..), and leave the rest to the modules (or to the programmer). In this case the program could test for the existence of a certain module (wxWidgets, SDL_perl, whatever) and use that if it's available, and to use more primitive routine based on supported commands in core for those cases where better module is not available. Currently, in perl5, if there is no graphical module available (either platform not (yet) supported, or module not installed), the program can't do anything but to use text-mode console. -- Markus Laire
Re: Copyrights in file headers
Has any FOSS developer ever been found liable (or even sued)? Not that I have any objections to this plan but it might be worth considering that it's much easier to sue a single entity then it is to file a tort against a few tens or hundreds of contributors. Yes, the guy who wrote an open source DVD player for Linux was sued by the consortium of companies that own the IP for DVD's. I don't remember the result, but the EFF archives should have something on it. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Checklist for resolving a [PATCH] bug
On Mon, Oct 17, 2005 at 07:57:16PM +0200, Leopold Toetsch wrote: > > On Oct 12, 2005, at 4:28, Joshua Hoblitt wrote: > > >- add correspondence to the bug stating that the patch was applied AND > > the svn revision number. > >- make sure that the bugs 'Tag' includes 'Patch' > >- set the bugs 'Patch Status' to 'Applied' > >- set the bugs 'Status' to 'resolved' > > ... this list looks for sure like stuff a computer can do. We have svn > (which can run action scripts), RT (which is scriptable afaik). I think > it should be possible to properly close PATCHes automatically. Integrating svn with RT would likely involve getting everyone to set an rt client locally and I'd worry about synchronization issues when a commit fails/etc.. Scripting RT sounds like a better solution but I lack the privileges needed to do this. A 'patch applied' link similar to the 'resolve' link would be great. Cheers, -J -- pgpU3iqDeS078.pgp Description: PGP signature
Re: Copyrights in file headers
On Mon, Oct 17, 2005 at 04:34:50PM +0200, Allison Randal wrote: > On Oct 17, 2005, at 12:26, Joshua Hoblitt wrote: > > >Which is what I've been doing > >but It's my understanding that copyright can only be transfered by a > >written argument. > > Yes, and in fact we won't be doing copyright *transfers* at all. When > you sign the contributor agreement, you'll be signing a copyright > *license*, which still leaves you with the right to use the code > elsewhere. TPF holds the "compilation copyright", that is the > copyright on the distributed collection of code. The individual files > say "Copyright The Perl Foundation" to reflect that fact. Individual > copyrights on included pieces of code are irrelevant from perspective > of the distribution (except that the contributors agree to give TPF > the license to distribute them). Sounds reasonable and well thought out. > >This next statement isn't intending to stir up a > >flame-war but does TPF holding the copyrights really matter? AFAIK - > >The only value in having a single party holding _all_ the > >copyrights is > >to be able to change the licensing. > > The advantage is down-stream, for the people and companies that use > Perl/Parrot. If there isn't a single source of ownership on the > distribution, then legally users need to negotiate with every single > individual contributor to Perl/Parrot to ensure that they have the > right to use it. No-one will do that. If that was true nobody would be using the Linux kernel. How do you explain that? That only examples I can think of where 'users' negotiate anything with an open source project is to be granted a license exception and I'd imagine that the terms of the "contributor agreement" would forbid that. Is that the case? > So, with Perl 5, Larry is the compilation owner. The problem with > that is it makes Larry personally liable for any action brought > against Perl (not that that would ever happen, we hope), and a > successful suit could take his house, his car, his savings, etc. (not > that that would ever happen, we hope). With Perl 6/Parrot we decided > putting the burden of liability on the foundation is a better way to > do it. That way the worst that can happen in a legal action is that > someone can take the (limited) resources of TPF (not that that will > ever happen, we hope). Has any FOSS developer ever been found liable (or even sued)? Not that I have any objections to this plan but it might be worth considering that it's much easier to sue a single entity then it is to file a tort against a few tens or hundreds of contributors. Cheers, -J -- pgpGIuJrIn1qk.pgp Description: PGP signature
Re: UUIDs for PBC headers
On Mon, 17 Oct 2005, Chip Salzenberg wrote: > Any problems here? Any suggestions for UUID code that's licensed > appropriately for use in Parrot? the UUID library in e2fsprogs might be appropriate. e2fsprogs is GPL, but lib/uuid has a separate and much more flexible BSD-style license. http://e2fsprogs.sourceforge.net/ > -- > Chip Salzenberg <[EMAIL PROTECTED]> > -jeff
Re: Translitteration and combining strings and array references
On 16 Oct 2005 03:46:25 -, David Formosa (aka ? the Platypus) < [EMAIL PROTECTED]> wrote: > > On Fri, 14 Oct 2005 08:38:55 +0200, Peter Makholm <[EMAIL PROTECTED]> > wrote: > > Yesterday I spend some hours getting pugs to understand > > translitterations with multiple ranges in each pair. E.g. > > > > "foobar".trans( "a-z" => "n-za-n" ); > > > > By accident I tested something like: > > > > "foobar".trans( ['a' .. 'z'] => "n-za-m" ); > > > > and it didn't work. > > It's a bug. When Pugs gets anyhashes that bug will go away. Can you > add it in to the errors. > > > -- > Please excuse my spelling as I suffer from agraphia. See > http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. > Free the Memes. > Actually its been fixed already. Of course i think the whole thing was then broken again, i was planning on checking it out sometime tonight after someone else figures out the current $?SELF being undeclared bug. ;) BTW it doesn't need any hash i just needed pairs which it had for about an hour before things changed again. lol. so is development on pugs I guess, here today, gone tomorrow, back again another day. -- -- __ Eric Hodges
Patches floating and accumulating ...
Patches floating and accumulating and I've not much time in the foreseeable future to have a look at all. Fellow committers, please apply locally, test, and possilby checkin patches. Thanks, leo
Re: [PATCH] libgdbm and Darwin...
Well, here goes a stupid patch. Just removes the fprintf to the stderr.
If the function returns NULL on failure, callers should verify result.
Can't remember the name of someone who suggested right this. I just
needed to look a little more to the code to be sure it was the right(??)
thing to do.
Apply, or not, it :->
Cheers,
Alberto
Alberto Simões wrote:
Ok, more details on this bug...
on src/dynext.c...
PMC *Parrot_init_lib(Interp *interpreter,
PMC *(*load_func)(Interp *),
void (*init_func)(Interp *, PMC *))
{
PMC *lib_pmc = NULL;
fprintf(stderr, "Called..\n");
if (load_func)
lib_pmc = (*load_func)(interpreter);
if (!load_func || !lib_pmc) {
/* seems to be a native/NCI lib */
[...]
lib_pmc = pmc_new(interpreter, enum_class_ParrotLibrary);
}
Basically, 'load_func' is true, but loading fails (twice, don't know why
yet). Then, code enter in the second if, and it *seems* to work.
Now, if there are two different options to load the library, the code
used to load it can't just write to stdout the error message.
Cheers
The newby-bug-hunter.
Alberto Simões wrote:
gdbmhash.pmc class_init is being called more than once... first time
the load fails, second time it fails... and is not called any more.
Something very weird around :)
Alberto Simões wrote:
It's me again. Linked with gdbm (compiled with fink) and got these
errors.
They are kind weird because they complain about not being able to
load the library, but the tests run correctly. If they run correctly
without loading the library one of two things happens:
1) the tests do not test the library
2) the error message should not be issued because the library is
being loaded
Well, kind of :)
Cheers
Alberto
t/dynclass/gdbmhashNOK 1
# Failed test (t/dynclass/gdbmhash.t at line 43)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# GDBMHash
# '
# expected: 'GDBMHash
# '
t/dynclass/gdbmhashNOK 2
# Failed test (t/dynclass/gdbmhash.t at line 56)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# 0
# 1
# 0
# '
# expected: '0
# 1
# 0
# '
t/dynclass/gdbmhashNOK 3
# Failed test (t/dynclass/gdbmhash.t at line 76)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# An unitialized GDBMHash has size 0.
# An GDBMHash for a new file has size 0.
# After one assignment GDBMHash has size 1.
# After two assignments GDBMHash has size 2.
# After 15 assignments GDBMHash has size 15.
# '
# expected: 'An unitialized GDBMHash has size 0.
# An GDBMHash for a new file has size 0.
# After one assignment GDBMHash has size 1.
# After two assignments GDBMHash has size 2.
# After 15 assignments GDBMHash has size 15.
# '
t/dynclass/gdbmhashNOK 4
# Failed test (t/dynclass/gdbmhash.t at line 129)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# An uninitialized GDBMHash is not.
# An GDBMHash for a new file is not.
# After one insert the GDBMHash is.
# '
# expected: 'An uninitialized GDBMHash is not.
# An GDBMHash for a new file is not.
# After one insert the GDBMHash is.
# '
t/dynclass/gdbmhashNOK 5
# Failed test (t/dynclass/gdbmhash.t at line 161)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert urspruenglich
# Wert geaendert
# Wert nocheinmal geaendert
# Wert urspruenglich
# '
# expected: 'Wert urspruenglich
# Wert geaendert
# Wert nocheinmal geaendert
# Wert urspruenglich
# '
t/dynclass/gdbmhashNOK 6
# Failed test (t/dynclass/gdbmhash.t at line 189)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# 0
# 1
# 0
# 1
# '
# expected: '0
# 1
# 0
# 1
# '
t/dynclass/gdbmhashNOK 7
# Failed test (t/dynclass/gdbmhash.t at line 223)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 8
# Failed test (t/dynclass/gdbmhash.t at line 254)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 9
# Failed test (t/dynclass/gdbmhash.t at line 288)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 10
# Failed test (t/dynclass/gdbmhash.t at line 321)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
Re: [perl #37461] [TODO] handle ARM mixed-endian doubles
On Mon, Oct 17, 2005 at 12:48:32PM -0700, Leopold Toetsch wrote: > 0 ... 8 byte IEEE double > 1 ... 12 byte IEEE double (both according to endianess) > > We need additionally (at least and AFAIK): > > 2 ... 8 byte (ARM) mixed-endian > > which is according to Nicholas a LE double with 2 BE arranged words. and totally legal IEEE. (Mozilla thought that it could cheat. And it was wrong) The mixed endian is the old soft float, as I understand it, and will be replaced by something less surprising, but that's a C ABI change. Nicholas Clark
Re: UUIDs for PBC headers
On Mon, Oct 17, 2005 at 03:36:04PM -0400, Jeff Horwitz wrote: > On Mon, 17 Oct 2005, Chip Salzenberg wrote: > > I'm planning to require a UUID in the pbc header which would make each > > pbc distinguishable from every other pbc. > > i know mod_parrot would benefit from this. one question though -- if a > redundant UUID is found, will the internals make the decision to load/not > load or will that be up to the HLL/embedding code? The internals would make the decision. Speaking Perl 5 momentarily, the semantics would be like 'require' rather than 'do'. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: libgdbm and Darwin...
Ok, more details on this bug...
on src/dynext.c...
PMC *Parrot_init_lib(Interp *interpreter,
PMC *(*load_func)(Interp *),
void (*init_func)(Interp *, PMC *))
{
PMC *lib_pmc = NULL;
fprintf(stderr, "Called..\n");
if (load_func)
lib_pmc = (*load_func)(interpreter);
if (!load_func || !lib_pmc) {
/* seems to be a native/NCI lib */
[...]
lib_pmc = pmc_new(interpreter, enum_class_ParrotLibrary);
}
Basically, 'load_func' is true, but loading fails (twice, don't know why
yet). Then, code enter in the second if, and it *seems* to work.
Now, if there are two different options to load the library, the code
used to load it can't just write to stdout the error message.
Cheers
The newby-bug-hunter.
Alberto Simões wrote:
gdbmhash.pmc class_init is being called more than once... first time the
load fails, second time it fails... and is not called any more.
Something very weird around :)
Alberto Simões wrote:
It's me again. Linked with gdbm (compiled with fink) and got these
errors.
They are kind weird because they complain about not being able to load
the library, but the tests run correctly. If they run correctly
without loading the library one of two things happens:
1) the tests do not test the library
2) the error message should not be issued because the library is
being loaded
Well, kind of :)
Cheers
Alberto
t/dynclass/gdbmhashNOK 1
# Failed test (t/dynclass/gdbmhash.t at line 43)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# GDBMHash
# '
# expected: 'GDBMHash
# '
t/dynclass/gdbmhashNOK 2
# Failed test (t/dynclass/gdbmhash.t at line 56)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# 0
# 1
# 0
# '
# expected: '0
# 1
# 0
# '
t/dynclass/gdbmhashNOK 3
# Failed test (t/dynclass/gdbmhash.t at line 76)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# An unitialized GDBMHash has size 0.
# An GDBMHash for a new file has size 0.
# After one assignment GDBMHash has size 1.
# After two assignments GDBMHash has size 2.
# After 15 assignments GDBMHash has size 15.
# '
# expected: 'An unitialized GDBMHash has size 0.
# An GDBMHash for a new file has size 0.
# After one assignment GDBMHash has size 1.
# After two assignments GDBMHash has size 2.
# After 15 assignments GDBMHash has size 15.
# '
t/dynclass/gdbmhashNOK 4
# Failed test (t/dynclass/gdbmhash.t at line 129)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# An uninitialized GDBMHash is not.
# An GDBMHash for a new file is not.
# After one insert the GDBMHash is.
# '
# expected: 'An uninitialized GDBMHash is not.
# An GDBMHash for a new file is not.
# After one insert the GDBMHash is.
# '
t/dynclass/gdbmhashNOK 5
# Failed test (t/dynclass/gdbmhash.t at line 161)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert urspruenglich
# Wert geaendert
# Wert nocheinmal geaendert
# Wert urspruenglich
# '
# expected: 'Wert urspruenglich
# Wert geaendert
# Wert nocheinmal geaendert
# Wert urspruenglich
# '
t/dynclass/gdbmhashNOK 6
# Failed test (t/dynclass/gdbmhash.t at line 189)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# 0
# 1
# 0
# 1
# '
# expected: '0
# 1
# 0
# 1
# '
t/dynclass/gdbmhashNOK 7
# Failed test (t/dynclass/gdbmhash.t at line 223)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 8
# Failed test (t/dynclass/gdbmhash.t at line 254)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 9
# Failed test (t/dynclass/gdbmhash.t at line 288)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 10
# Failed test (t/dynclass/gdbmhash.t at line 321)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# Wert
# Wert
# Wert
# Wert
# '
# expected: 'Wert
# Wert
# Wert
# Wert
# '
t/dynclass/gdbmhashNOK 11
# Failed test (t/dynclass/gdbmhash.t at line 358)
# got: 'Couldn't load 'libgdbm': unknown reason
# Couldn't load 'libgdbm': unknown reason
# -11012005
# -11012005
# -11012005
# -11012005
# '
# expected: '-11012005
# -11012005
# -11012005
# -11012005
# '
t/dyn
[perl #37461] [TODO] handle ARM mixed-endian doubles
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #37461] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37461 > Parrot bytecode (PBC) is designed to be portable. Therefore we need some code to convert ARM-generated PBCs to machine-native doubles and ARM architectures must be able to read other already supported float types. A PBC header has a 'floattype' field, which identifies known FLOATVAL layouts. We have currently: 0 ... 8 byte IEEE double 1 ... 12 byte IEEE double (both according to endianess) We need additionally (at least and AFAIK): 2 ... 8 byte (ARM) mixed-endian which is according to Nicholas a LE double with 2 BE arranged words. See also: src/packf*.c, pf/pf_items.c, t/native_pbc/number.t ... Takers welcome, leo
Re: UUIDs for PBC headers
On Mon, 17 Oct 2005, Chip Salzenberg wrote: > In the use case where the same pbc exists in multiple places in a > filesystem (or is renamed during run, or lives on a filesystem without > a good definition of "same place"), it's necessary to detect when a > load is redundant. > > I'm planning to require a UUID in the pbc header which would make each > pbc distinguishable from every other pbc. This would have no privacy > issues if it's done right, because the pbcs are identified, not the > parrot installations that create them. > > Any problems here? Any suggestions for UUID code that's licensed > appropriately for use in Parrot? i know mod_parrot would benefit from this. one question though -- if a redundant UUID is found, will the internals make the decision to load/not load or will that be up to the HLL/embedding code? > -- > Chip Salzenberg <[EMAIL PROTECTED]> > -jeff
UUIDs for PBC headers
In the use case where the same pbc exists in multiple places in a filesystem (or is renamed during run, or lives on a filesystem without a good definition of "same place"), it's necessary to detect when a load is redundant. I'm planning to require a UUID in the pbc header which would make each pbc distinguishable from every other pbc. This would have no privacy issues if it's done right, because the pbcs are identified, not the parrot installations that create them. Any problems here? Any suggestions for UUID code that's licensed appropriately for use in Parrot? -- Chip Salzenberg <[EMAIL PROTECTED]>
[PROPOSED PATCH] Generate src/extend.c
Hi there,
Here's a proposed patch (for review, not application) to generate
src/extend.c from vtable.tbl. It has some limitations:
- I'm not sure if the Makefile magic is perfect
- it doesn't pick up all of the C types used in vtable.tbl
- it makes everything it understands in that file available
- it doesn't include behavioral documentation
I think the correct approach is to annotate vtable.tbl with more
information -- including the documentation strings -- to make generating
files easier.
Comments welcome.
-- c
Index: MANIFEST
===
--- MANIFEST (revision 9501)
+++ MANIFEST (working copy)
@@ -42,6 +42,7 @@
build_tools/pbc2c.pl [devel]
build_tools/pmc2c.pl []
build_tools/revision_c.pl [devel]
+build_tools/vtable_extend.pl []
build_tools/vtable_h.pl []
charset/ascii.c []
charset/ascii.h []
Index: config/gen/makefiles/root.in
===
--- config/gen/makefiles/root.in (revision 9501)
+++ config/gen/makefiles/root.in (working copy)
@@ -235,7 +235,8 @@
$(SRC_DIR)/parrot_config.c \
$(SRC_DIR)/null_config.c \
$(SRC_DIR)/install_config.c \
-$(SRC_DIR)/exec_cpu.c
+$(SRC_DIR)/exec_cpu.c \
+$(SRC_DIR)/extend.c
GEN_MODULES = \
lib/Parrot/OpLib/core.pm
@@ -896,6 +897,9 @@
$(SRC_DIR)/exec_cpu$(O) : $(GENERAL_H_FILES) ${TEMP_exec_h} ${TEMP_jit_h} $(INC_DIR)/jit_emit.h
+$(SRC_DIR)/vtable.h : vtable.tbl $(BUILD_TOOLS_DIR)/vtable_extend.pl lib/Parrot/Vtable.pm
+ $(PERL) $(BUILD_TOOLS_DIR)/vtable_extend.pl
+
$(SRC_DIR)/exec_start$(O) : $(GENERAL_H_FILES) ${TEMP_exec_h}
$(SRC_DIR)/exec_save$(O) : $(GENERAL_H_FILES) ${TEMP_exec_h}
Index: lib/Parrot/Vtable.pm
===
--- lib/Parrot/Vtable.pm (revision 9501)
+++ lib/Parrot/Vtable.pm (working copy)
@@ -293,6 +293,8 @@
{
my $vtable = shift;
+my $funcs = '';
+
for my $entry (@$vtable)
{
my ($return_type, $name, $params, $section, $mmd) = @$entry;
@@ -302,28 +304,45 @@
my @sig = ( 'Parrot_INTERP interp', 'Parrot_PMC pmc' );
my @args = ( 'interp', 'pmc' );
+
while (my ($type, $name) = splice( @params, 0, 2 ))
{
-push @sig, find_type( $type ) . ' ' . $name;
-push @args, $name;
+ eval
+ {
+ push @sig, find_type( $type ) . ' ' . $name;
+ push @args, $name;
+};
}
+next if $@;
+
my $signature = join( ', ', @sig );
my $arguments = join( ', ', @args );
my $ret_type = find_type( $return_type );
-printf
-"%s Parrot_PMC_%s( %s )
+$funcs .= sprintf
+"/*
+
+=item C<%s
+%s(%s)>
+
+=cut
+
+*/
+
+%s Parrot_PMC_%s( %s )
{
%s retval;
PARROT_CALLIN_START( interp );
retval = VTABLE_%s( %s );
PARROT_CALLIN_END( interp );
return retval;
-}\n\n", $ret_type, $name, $signature, $ret_type, $name, $arguments;
+}\n\n", ($ret_type, $name, $signature) x 2, $ret_type, $name, $arguments;
}
+
+return $funcs;
}
sub find_type
@@ -339,6 +358,7 @@
'FLOATVAL' => 'Parrot_Float',
'void' => 'void',
'UINTVAL' => 'Parrot_Int',
+'size_t' => 'size_t',
);
die "Unknown type $type\n" unless exists $typemap{ $type };
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ build_tools/vtable_extend.pl 2005-10-17 11:16:00.0 -0700
@@ -0,0 +1,113 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use lib 'lib';
+use Parrot::Vtable;
+
+my $vtable = parse_vtable( 'vtable.tbl' );
+
+open OUT, ">src/extend.c" or die $!;
+
+print OUT <<'EOF';
+/*
+** !!! DO NOT EDIT THIS FILE !!!
+**
+** This file is generated automatically from 'vtable.tbl' by
+** build_tools/vtable_extend.pl
+*/
+
+/*
+Copyright: 2001-2003, 2005 The Perl Foundation. All Rights Reserved.
+
+=head1 NAME
+
+src/extend.c - Parrot extension interface
+
+=head1 DESCRIPTION
+
+These are the functions that Parrot extensions (that is, Parrot subroutines
+written in C, or some other compiled language, rather than in Parrot
+bytecode) may access.
+
+There is a deliberate distancing from the internals here. Don't go
+peeking inside -- you've as much access as bytecode does, but no more,
+so we can provide backwards compatibility for as long as we possibly
+can.
+
+=head2 Functions
+
+=over 4
+
+=cut
+
+*/
+
+/* Some internal notes. Parrot will die a horrible and bizarre death
+ if the stack start pointer's not set and a DOD run is
+ triggered. The pointer *will* be set by the interpreter if the
+ interpreter calls code which calls these functions, so most
+ extension code is safe, no problem.
+
+
Re: Checklist for resolving a [PATCH] bug
On Oct 12, 2005, at 4:28, Joshua Hoblitt wrote: Hi Folks, As part of my RT 'clean-up' project I've been trying to get bug metadata into a consistent state. Maybe someday we'll be able to generate some worthless statistics that will look pretty in a presentation. :) I appreciate this ver much, but ... - add correspondence to the bug stating that the patch was applied AND the svn revision number. - make sure that the bugs 'Tag' includes 'Patch' - set the bugs 'Patch Status' to 'Applied' - set the bugs 'Status' to 'resolved' ... this list looks for sure like stuff a computer can do. We have svn (which can run action scripts), RT (which is scriptable afaik). I think it should be possible to properly close PATCHes automatically. Cheers, -J leo
Re: Revision 9500 not passing tests on i386/Linux
On Oct 17, 2005, at 18:37, Alberto Manuel Brandão Simões wrote: t/op/debuginfo.NOK 7# Failed test (t/op/debuginfo.t at line 165) Yep I saw that too. I'll investigate it further after more variable-sized reg frame patches are in (if no one is faster at least ;-) leo
Re: Re(vised): Proposal to make class method non-inheritable
On Oct 17, 2005, at 12:32 PM, TSa wrote: This also means that they would not (directly) be inheritable since inheritence moves along superclass lines, and not with @ISA. I am also not sure what you mean about multi-methods either, could you please explain more? Symmetric MMD at least has the meaning that the above mentioned asymmetry doesn't exist for infix ops on the syntactic level: $x foo $y; which neither means ($x foo) $y; # calculated prefix op from postfix foo nor $x (foo $y); # calculated postfix op from prefix foo. I can't speak for metric MMD, though. But IIRC, the metric is 'sum of superclass hops'. -- Okay, I think I understand now. So if all class methods were multis, then we would not need inheritance. The MMD would use the (super|sub) class relationships, and be able to call (super|sub)classes automagically. However, IIRC, the "everything is a multi-method" proposal was not accepted. Could this then be just a restricted case of multi-methods? So all class methods would just use MMD dispatch rules on the invocant parameter, therefore allowing an implicit pseudo-inheritence to take place? Larry, is this what you were thinking? Stevan
Re: Re(vised): Proposal to make class method non-inheritable
HaloO,
Stevan Little wrote:
Now, as for class methods, I suppose it is possible to just stash then
in the classes symbol table like with variables. However, do we then
loose the method call syntax?
I think not. But the current notion seems to drift closer to my
idea of "free methods" versus "slot calls". To express that in therms
of your initial equation
object == state + behavior
would be expressed on the first meta level as
class == data(structure) + code(structure)
which means that the compiler syntactically splits the class
definition into an active and a passive part. Call this symmetry
breaking if you like. The same asymmetry exist in the method call
syntax
$foo .action;
because the compiler compiles that into a lookup of 'action' from
the method part of the MIR (Meta Information Repository, World in Russian)
followed by a dispatch on the actual runtime type referred to by $foo.
In other words, the name that connects the compile and runtime is 'action'.
If this name shall be retrieved from the instance at runtime without going
through the method dispatcher I have proposed to wrap-up the name as
$foo :action;
Without the $ sigil a bare foo is interpreted as a name lookup in the code
part of the MIR which is the union of all subs and methods---subs beeing
nullary methods so to speak. That gives
foo .action; # dispatch action on retval of foo
and
foo :action; # bind named param in the call to foo.
These two things are on the tightest precedence level, which in my eyes
makes . and : meta sigils or some such.
We could actually combine these with the idea of the current name beeing
a sigilled underscore and '_._' denoting the current method on the current
topic, and '_:_' the current key from the current topic :)
Hmm, these would make {_} the closure of the current continuation or so.
This also means that they would not
(directly) be inheritable since inheritence moves along superclass
lines, and not with @ISA. I am also not sure what you mean about
multi-methods either, could you please explain more?
Symmetric MMD at least has the meaning that the above mentioned asymmetry
doesn't exist for infix ops on the syntactic level:
$x foo $y;
which neither means
($x foo) $y; # calculated prefix op from postfix foo
nor
$x (foo $y); # calculated postfix op from prefix foo.
I can't speak for metric MMD, though. But IIRC, the metric is
'sum of superclass hops'.
--
Revision 9500 not passing tests on i386/Linux
t/op/debuginfo.NOK 7# Failed test (t/op/debuginfo.t at line 165) # 'maximum recursion depth exceeded # current instr.: 'main' pc 7 (/home/ambs/tmp/parrot/t/op/debuginfo_7.pir:2) # called from Sub 'main' pc 7 (/home/ambs/tmp/parrot/t/op/debuginfo_7.pir:2) # ' # doesn't match '/^maximum recursion depth exceeded # current instr\.: 'main' pc (\d+|-1) \(.*?:(\d+|-1)\) # called from Sub 'main' pc (\d+|-1) \(.*?:(\d+|-1)\) # \.\.\. call repeated 99[89] times/ # ' t/op/debuginfo.ok 8/8# Looks like you failed 1 test of 8. -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Re: graphing packages
-BEGIN PGP SIGNED MESSAGE- Moin, On Monday 17 October 2005 16:45, Tels wrote: > Moin, > > I haven't had any feedback on this message: > > http://groups.google.com/group/perl.qa/msg/7daba8b786b58838?dmode=sourc >e&hl=en Aaargl, I mean of course this message: http://groups.google.com/group/perl.qa/msg/52e0a93e0f425be4?dmode=source&hl=en Te"need more coffee"ls > Did I miss it while I was away, or did nobody have to say anything > about it? :) > > Best wishes, > > Tels - -- Signed on Mon Oct 17 16:47:05 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Duke Nukem Forever is a 1999 game and we think that timeframe matches very well with what we have planned for the game." - George Broussard, 1998 (http://tinyurl.com/6m8nh) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ1O5gncLPEOTuEwVAQHlSwf+OmiVXpzbWUJ3rPYuIfawxfs9dD+nv0WY rK4k2aBRwOnlRmM16EMZeXUiXdVd420dqYFBRqVapnU5M+C25tjJFfJcD99i5G9n gNyGBWjyFORQyoXR1VYLfK3sRXoBuuICICXTE7I10X2KRRo8enrl6uiP3O4p0mzX 2JHc3JDZ+ot+nBRAP6UFG7QnCz13PblQVFOv9VvfBha26EhWVirykV6oaPFj7s/A HyPDD35xyL1tAdeaasq9jB8pVgQN8BhgNLdUDMI1FbNFbnf9kvIr3BEEzBg8OxPQ sMQM7aAFnQfyjdfKSh9RvzM+9AlnR6U6qiFy/UM1nxvmayd21l03xQ== =m6vv -END PGP SIGNATURE-
graphing packages
-BEGIN PGP SIGNED MESSAGE- Moin, I haven't had any feedback on this message: http://groups.google.com/group/perl.qa/msg/7daba8b786b58838?dmode=source&hl=en Did I miss it while I was away, or did nobody have to say anything about it? :) Best wishes, Tels - -- Signed on Mon Oct 17 16:44:03 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "My wife is just a slow brain, running up the bill.." -- Often misheard song lyrics #149 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ1O5E3cLPEOTuEwVAQFrHwf/S14f1R37RUiqpN1JB2qokprhio4d9U/r eE+x3RmnCi4v6+Udm/StLXM0OGdITHS7x0EYljmzDJ+ZFh0iqW6rK7oZaE9X43jK 3KnOKrM6QYPPOn6wACF0/1Ohq5iTLG7uFtzzOFZS4nwaxfcCbMk7q+psDl79RVcW hA8XAQCgz/RlT95ZrCOeRsy4vNvpQUzD7LaXfRD8cIpWGPEjaXlqluDRfnX5MSmb 3msvbC+uz5nELtxW08NEsE61thyTlTiguzN1Tsxrp2rZQnZD6ZQN76VntGX96lod OIWorfgBH94hayE4KnbG/p2Ioqhjbq7nNO9jxUpgXU/B60ct4uYlhw== =etkv -END PGP SIGNATURE-
Re: 'self' and .foo (was: Re: Re(vised): Proposal to make class method non-inheritable)
On 2005-10-15 15:28, "Ilmari Vacklin" <[EMAIL PROTECTED]> wrote: > On Sat, Oct 15, 2005 at 09:49:30AM -0700, Larry Wall wrote: >> On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote: >> : IMHO just call it "self" (by default) and be done with it. :) >> >> Let it be so. > > Somewhat off-tangent: does this mean that .foo is always $_.foo? INCOMING!! . . . Hunh. Who'da thunk - apparently even *flame* wars can trigger post-traumatic stress disorder...
Re: Copyrights in file headers
On Oct 17, 2005, at 12:26, Joshua Hoblitt wrote: Does sticking "Copyright The Perl Foundation" at the top of a file constitute a legal transfer of copyright? No, there's no such thing as an implicit transfer of copyright rights. Which is what I've been doing but It's my understanding that copyright can only be transfered by a written argument. Yes, and in fact we won't be doing copyright *transfers* at all. When you sign the contributor agreement, you'll be signing a copyright *license*, which still leaves you with the right to use the code elsewhere. TPF holds the "compilation copyright", that is the copyright on the distributed collection of code. The individual files say "Copyright The Perl Foundation" to reflect that fact. Individual copyrights on included pieces of code are irrelevant from perspective of the distribution (except that the contributors agree to give TPF the license to distribute them). This next statement isn't intending to stir up a flame-war but does TPF holding the copyrights really matter? AFAIK - The only value in having a single party holding _all_ the copyrights is to be able to change the licensing. The advantage is down-stream, for the people and companies that use Perl/Parrot. If there isn't a single source of ownership on the distribution, then legally users need to negotiate with every single individual contributor to Perl/Parrot to ensure that they have the right to use it. No-one will do that. So, with Perl 5, Larry is the compilation owner. The problem with that is it makes Larry personally liable for any action brought against Perl (not that that would ever happen, we hope), and a successful suit could take his house, his car, his savings, etc. (not that that would ever happen, we hope). With Perl 6/Parrot we decided putting the burden of liability on the foundation is a better way to do it. That way the worst that can happen in a legal action is that someone can take the (limited) resources of TPF (not that that will ever happen, we hope). Allison
Re: [perl #37455] make hello fails
"François PERRAD (via RT)" <[EMAIL PROTECTED]> wrote: $ ./parrot -V This is parrot version 0.3.0-devel (r9493) built for i386-linux. $ make hello ./parrot -o examples/assembly/hello.o examples/assembly/hello.pbc make EXEC=examples/assembly/hello exec c++ -o examples/assembly/hello -L/usr/local/lib -Wl,-E examples/assembly/hello.o src/exec_start.o src/parrot_config.o blib/lib/libparrot.a -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm -ldl -lm -lpthread -lcrypt -lrt c++: examples/assembly/hello.o: No such file or directory parrot doesn't produce hello.o from hello.pbc make should probably terminate earlier, though as for why it doesn't produce the object file, look in myconfig and check if it contains something like "execcapable=1"; if it does not, Configure doesn't think Parrot can produce native objects for your platform (which it may be wrong about). Jonathan
Re: Re(vised): Proposal to make class method non-inheritable
Miroslav
On Oct 17, 2005, at 7:35 AM, Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
I think what bothers me most about this is that it seems there is
no way to tell the difference between class methods and instance
methods. That the distinction is only made when the body of the
method does something which is is not supposed to do (method
called with a class invocant attempts to access an instance
variable, etc).
This is one of the major problems that I have always had with Perl
5 OO. That there is a very fuzzy fuzzy line between the
responsibilities of a class and an instance.
I can see the notion of "a class which is not yet instantiated",
this makes sense in many contexts. But I don't think that in
order to have this, we need to bring back this element of Perl 5
OO. I think we can still have all the behaviors you have been
describing, and still keep classes and their instances as
distinct entities.
It just recently occured to me that Class is a Package.
Actually, to be precise, Class is a Module, and Module is a Package.
Modules add the version and authority portions to the name of a
Package, and it seems that exporting (as traits?) are Module things,
and not Package things.
So, on the object model level, class methods/attributes belong to
the Package part of a class, while instance methods/attributes
belong to the Class part of a class - insofar as they're made
distinct by use of my/our.
Well, currently in the prototype, class attributes defined with "our"
are stored in the Classes symbol table (which is inherited from
Package). Discussions with autrijus lead me to not address class
attributes defined by "my", since he felt they would be better
addressed as "normal" variables within the scope of the class body.
This is somewhat of an implementation detail, however, I think it may
also play a part in how these things work. For instance, in the
following example, is "$.foo" a class attribute? or just a local
variable for the inner block?
class Bar {
our $.bar;
{
my $.foo;
}
}
I assume that the leading "$." is what makes the difference, however,
IIRC the "$." is just part of the name, and no more special than
that. Which means that I can choose that name (yes, it is evil, but I
assume I can still do it).
But given that the variable will be accessible to all methods via the
closure mechanism, the only thing missing I think is the ability to
get at the variable via introspection.
Now, as for class methods, I suppose it is possible to just stash
then in the classes symbol table like with variables. However, do we
then loose the method call syntax? This also means that they would
not (directly) be inheritable since inheritence moves along
superclass lines, and not with @ISA. I am also not sure what you mean
about multi-methods either, could you please explain more?
Thanks,
Stevan
Re: [perl #37303] [PATCH] Relaxing parrot dependency on parrot_config
Let me try reposting the patch, which gives me the opportunity to bit
twiddle a bit more:
* Removed the mmap nonsense which was sent by accident
* Renamed config.c to config_string.c to make it less generic
* Moved a couple externs from a core parrot library into the main
executable, where they sit better
Thanks for considering this patch,
Nick
On 10/17/05, Joshua Hoblitt via RT <[EMAIL PROTECTED]> wrote:
> I'm guessing that this change in src/embed.c wasn't intended to be included
> in the patch:
>
> -mmap(0, program_size, PROT_READ, MAP_SHARED, fd, (off_t)0);
> +mmap(0, program_size, PROT_READ, MAP_PRIVATE, fd, (off_t)0);
Index: build_tools/parrot_config_c.pl
===
--- build_tools/parrot_config_c.pl (revision 9496)
+++ build_tools/parrot_config_c.pl (working copy)
@@ -7,7 +7,7 @@
=head1 NAME
-build_tools/parrot_config_c.pl - Create src/parrot_config.c
+build_tools/parrot_config_c.pl - Create src/parrot_config.c and variants
=head1 SYNOPSIS
@@ -41,46 +41,46 @@
*
*/
+EOF
+
+if ($mini_parrot) {
+
+print << "EOF";
#include "parrot/parrot.h"
+const char* parrot_config_ptr = NULL;
+unsigned int parrot_config_size = 0;
+EOF
+}
+else
+{
+print << "EOF";
static const char parrot_config[] = {
EOF
-if ($mini_parrot) {
-print "0\n";
-}
-else {
my $image_file = $install_parrot ?
- 'install_config.fpmc' : 'runtime/parrot/include/config.fpmc';
+'install_config.fpmc' : 'runtime/parrot/include/config.fpmc';
open F, $image_file or die "Can't read '$image_file': $!";
my $image;
local $/;
- binmode F;
+binmode F;
$_ = ;
close F;
my @c = split '';
printf '';
my $i;
for (@c) {
- printf "0x%02x", ord($_);
- ++$i;
- print ', ', if ($i < scalar(@c));
- print "\n" unless $i % 8;
+printf "0x%02x", ord($_);
+++$i;
+print ', ', if ($i < scalar(@c));
+print "\n" unless $i % 8;
}
print "\n";
-}
print << "EOF";
}; /* parrot_config */
-STRING*
-parrot_get_config_string(Interp* interpreter)
-{
-if (sizeof(parrot_config) <= 1)
- return NULL;
-return string_from_const_cstring(interpreter,
- parrot_config, sizeof(parrot_config));
+const char* parrot_config_ptr = parrot_config;
+unsigned int parrot_config_size = sizeof(parrot_config);
+EOF
}
-EOF
-
-
Index: src/config_string.c
===
--- src/config_string.c (revision 0)
+++ src/config_string.c (revision 0)
@@ -0,0 +1,63 @@
+/*
+ Copyright: 2005 The Perl Foundation. All Rights Reserved.
+ $Id$
+
+=head1 NAME
+
+src/config_string.c - Register configuration bundle with parrot runtime
+
+=head1 DESCRIPTION
+
+The routines in this file can be used to set and retrieve the embedded
+configuration data for the parrot runtime.
+
+There are currently three runtimes:
+
+=over 4
+
+=item * a dummy stub used in minparrot during and other utilities. No
+explicit set is required for this
+
+=item * the default config used during the build
+
+=item * a config profile suitable once parrot has been installed system-wide
+
+=back
+
+=cut
+
+*/
+
+#include "parrot/parrot.h"
+
+static const char *parrot_config_private_ptr = NULL;
+static unsigned int parrot_config_private_size = 0;
+
+void
+Parrot_set_config_string(const char* new_parrot_config_ptr,
+ unsigned int new_parrot_config_size)
+{
+parrot_config_private_ptr = new_parrot_config_ptr;
+parrot_config_private_size = new_parrot_config_size;
+}
+
+STRING*
+parrot_get_config_string(Interp* interpreter)
+{
+if (!parrot_config_private_ptr)
+return NULL;
+
+return string_from_const_cstring(interpreter,
+ parrot_config_private_ptr,
+ parrot_config_private_size);
+}
+
+/*
+ * Local variables:
+ * c-indentation-style: bsd
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ *
+ * vim: expandtab shiftwidth=4:
+ */
Index: MANIFEST
===
--- MANIFEST(revision 9496)
+++ MANIFEST(working copy)
@@ -1728,6 +1728,7 @@
src/exec_save.c []
src/exec_start.c []
src/exit.c[]
+src/config_string.c []
src/extend.c []
src/gc_gms.c []
src/gc_ims.c []
Index: imcc/main.c
===
--- imcc/main.c (revision 9496)
+++ imcc/main.c (working copy)
@@ -26,6 +26,9 @@
static char optimizer_opt[20];
extern FILE *yyin;
+extern const char* parrot_config_ptr;
+extern unsigned int parrot_config_size;
+
s
Re: Re(vised): Proposal to make class method non-inheritable
[EMAIL PROTECTED] wrote: I think what bothers me most about this is that it seems there is no way to tell the difference between class methods and instance methods. That the distinction is only made when the body of the method does something which is is not supposed to do (method called with a class invocant attempts to access an instance variable, etc). This is one of the major problems that I have always had with Perl 5 OO. That there is a very fuzzy fuzzy line between the responsibilities of a class and an instance. I can see the notion of "a class which is not yet instantiated", this makes sense in many contexts. But I don't think that in order to have this, we need to bring back this element of Perl 5 OO. I think we can still have all the behaviors you have been describing, and still keep classes and their instances as distinct entities. It just recently occured to me that Class is a Package. So, on the object model level, class methods/attributes belong to the Package part of a class, while instance methods/attributes belong to the Class part of a class - insofar as they're made distinct by use of my/our. Larry's proposal is to remove that difference for multimethods. Personally I can't think of a good objection to that idea (except if it may be bad for performance - is there a plan to infer types and auto-inline? I that case, declaring that you don't care about instance part of the object's functionality can really help). Miro
[perl #37439] [PATCH] Skip two nci tests on HP-UX
Applied as r9496. Thanks. -J
Re: [perl #37303] [PATCH] Relaxing parrot dependency on parrot_config
I promptly sent a follow-up after I spotted this, but it didn't seem to make it into RT. Well spotted! (I'd been checking that an HP-UX-related patch didn't break things) I also think that it would also be cleaner to move the lines const char* parrot_config_ptr; unsigned int parrot_config_size; from library.h into the parrot harness itself. All things considered, I think it's best if I repost the patch this evening (UK time) and fix my botch. Cheers, Nick On 10/17/05, Joshua Hoblitt via RT <[EMAIL PROTECTED]> wrote: > > I'm guessing that this change in src/embed.c wasn't intended to be included > in the patch: > > -mmap(0, program_size, PROT_READ, MAP_SHARED, fd, (off_t)0); > +mmap(0, program_size, PROT_READ, MAP_PRIVATE, fd, (off_t)0); >
[perl #37458] [PATCH] add check_progs() to Parrot::Configure::Step
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37458]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37458 >
This transaction appears to have no contentThis patch adds a new function named check_progs(), rather similar to
Autoconf's AC_CHECK_PROGS macro, to Parrot::Configure::Step. Nothing
will be using it immediately but I've have some patches coming RSN that
will depend on this. Those patches may require some discussion (while
this small hopefully won't) so I've split this function out.
Cheers,
-J
--
Step.pm | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
Index: lib/Parrot/Configure/Step.pm
===
--- lib/Parrot/Configure/Step.pm(revision 9496)
+++ lib/Parrot/Configure/Step.pm(working copy)
@@ -26,7 +26,10 @@
use strict;
use Exporter;
use Carp;
+use File::Basename qw( basename );
use File::Copy ();
+use File::Spec;
+
use vars qw(@ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
@ISA = qw(Exporter);
@@ -34,11 +37,13 @@
@EXPORT = ();
@EXPORT_OK = qw(prompt genfile copy_if_diff move_if_diff integrate
-cc_gen cc_build cc_run cc_clean cc_run_capture capture_output);
+cc_gen cc_build cc_run cc_clean cc_run_capture capture_output
+check_progs);
%EXPORT_TAGS = (
inter => [qw(prompt integrate)],
-auto => [qw(cc_gen cc_build cc_run cc_clean cc_run_capture)],
+auto => [qw(cc_gen cc_build cc_run cc_clean cc_run_capture
+ capture_output check_progs)],
gen => [qw(genfile copy_if_diff move_if_diff)]
);
@@ -463,6 +468,44 @@
return $output;
}
+=item C
+
+Where C<$programs> may be either a scalar with the name of a single program or
+an array ref of programs to search the current C for. The first matching
+program name is returned or C on failure. Note: this function only
+returns the name of the program and not it's complete path.
+
+This function is similar to C's C macro.
+
+=cut
+
+sub check_progs {
+my $progs = shift;
+
+$progs = [$progs] unless ref $progs eq 'ARRAY';
+my $verbose = Configure::Data->get('verbose');
+
+print "checking for program: ", join(" or ", @$progs), "\n" if $verbose;
+foreach my $prog (@$progs) {
+# try relative path first in case it's not in the path
+return $prog if -x $prog;
+
+$prog = basename($prog);
+foreach my $dir (File::Spec->path) {
+my $path = File::Spec->catfile($dir, $prog);
+
+if ($verbose) {
+print "trying: $path\n";
+print "$path is executable\n" if -x $path;
+}
+
+return $prog if -x $path;
+}
+}
+
+return undef;
+}
+
=back
=head1 SEE ALSO
pgpHDZzmSRkaS.pgp
Description: PGP signature
[perl #37457] Re: [PATCH] number formatting
# New Ticket Created by Simon Vogl
# Please include the string: [perl #37457]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37457 >
This seems to solve it - the tests now run successfully:
"
[EMAIL PROTECTED]:/var/tmp/parrot-0.3.0# /usr/bin/perl5.8.4 t/harness
--gc-debug --running-make-test t/pmc/integer.t
t/pmc/integerok
All tests successful.
Files=1, Tests=11, 12 wallclock secs ( 6.30 cusr + 3.87 csys = 10.17 CPU)
"
And - as expected - complex.t revolts because it does not get "-0.0" any
more
Simon
Leopold Toetsch wrote:
> Simon Vogl wrote:
>
> [ ... ]
>
> Here are some relevant snippets auf Parrot on ARM (see also
> http://use.perl.org/~koobla/journal/ )
>
>> [EMAIL PROTECTED]:/var/tmp/parrot-0.3.0# ./parrot -t
>> t/pmc/perlint_40.pasm
>> 0 new P0, 35 - P0=PMCNULL,
>> 3 new P1, 35 - P1=PMCNULL,
>> 6 set N0, 4000.04 - N0=0.00,
>> 9 set P0, 123 - P0=PerlInt=PMC(0x348ea0 Num:0 Int:0),
>> 12 multiply P1, P0, N0 - P1=PerlInt=PMC(0x348e88 Num:0
>> Int:0), P0=PerlInt=PMC(0x348ea0 Num:123 Int:123), N0=4000.04
>> 17 print P1 - P1=PerlNum=PMC(0x348e88 Num:492005 Int:492004)
>> 19 print "\n"
>> -492004.92
>
>
> There are 2 problems. The trace dump truncates numbers and more
> importantly PerlNum.get_string() is very likely failing due to our
> 'signbit' hack that exists merely for the darn -0.0 negative zero.
>
> I think it's time to rewrite this code once again. Attached is a patch
> that should correct above error type. Unfortunately it causes
> different errors (of course +- 0.0) in t/pmc/complex.t. But it might
> very well be that the expected output of the test is bogus.
>
> The code in src/spf_render.c is also rather weird. At line 663 a
> STRING is created just to be converted back to a cstring in the next
> statement. This is probably not the most efficient way to strdup the
> format string ;-)
>
> Commenents & testers very welcome,
> leo
>
>
>
>Index: src/trace.c
>===
>--- src/trace.c(revision 9481)
>+++ src/trace.c(working copy)
>@@ -107,7 +107,7 @@
> else if (pmc->vtable->base_type == enum_class_PerlUndef
> || pmc->vtable->base_type == enum_class_PerlInt
> || pmc->vtable->base_type == enum_class_PerlNum) {
>-PIO_eprintf(interpreter, "%S=PMC(%#p Num:%Pg Int:%Pd)",
>+PIO_eprintf(interpreter, "%S=PMC(%#p Num:%Pf Int:%Pd)",
> VTABLE_name(interpreter, pmc), pmc, pmc, pmc);
> }
> else if (pmc->vtable->base_type == enum_class_RetContinuation
>Index: src/spf_render.c
>===
>--- src/spf_render.c (revision 9481)
>+++ src/spf_render.c (working copy)
>@@ -658,7 +658,7 @@
> thefloat = obj->getfloat
> (interpreter, info.type, obj);
> /* turn -0.0 into 0.0 */
>-if( thefloat == 0.0 ) { thefloat = 0.0; }
>+/* WTF if( thefloat == 0.0 ) { thefloat = 0.0; }
>*/
> gen_sprintf_call(interpreter, tc, &info, ch);
> ts = cstr2pstr(tc);
> /* XXX lost precision if %Hg or whatever
>Index: classes/perlnum.pmc
>===
>--- classes/perlnum.pmc(revision 9481)
>+++ classes/perlnum.pmc(working copy)
>@@ -35,12 +35,20 @@
> */
>
> STRING* get_string () {
>+#if 0
> double d = (double) PMC_num_val(SELF);
> const char *sign = "-";
> if (!signbit(PMC_num_val(SELF)))
> sign = "";
> d = fabs(d);
> return Parrot_sprintf_c(INTERP, "%s" FLOATVAL_FMT, sign, d);
>+#else
>+ /* XXX signbit isn't portable and as we are calling Parrot_sprintf_c
>+ * anyway, we can use the builtin number formatting too
>+ * this might still be a problem with -0.0
>+ */
>+return Parrot_sprintf_c(INTERP, "%Pf", SELF);
>+#endif
> }
>
>
>
>
--
___
Dr. Simon Vogl
ARC Seibersdorf research GmbH
Research Studios Austria, Studio Pervasive Computing Applications
Altenberger Straße 69, A-4040 Linz, Austria
Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: [EMAIL PROTECTED]
[perl #37455] make hello fails
# New Ticket Created by François PERRAD # Please include the string: [perl #37455] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37455 > $ ./parrot -V This is parrot version 0.3.0-devel (r9493) built for i386-linux. $ make hello ./parrot -o examples/assembly/hello.o examples/assembly/hello.pbc make EXEC=examples/assembly/hello exec c++ -o examples/assembly/hello -L/usr/local/lib -Wl,-E examples/assembly/hello.o src/exec_start.o src/parrot_config.o blib/lib/libparrot.a -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm -ldl -lm -lpthread -lcrypt -lrt c++: examples/assembly/hello.o: No such file or directory parrot doesn't produce hello.o from hello.pbc François Perrad
TODO bugs
Hi Folks, As part of my RT cleanup, I've decided that TODO bugs should have there status set to 'open'. The rational behind this is two fold: a) if it's really a valid TODO item then it is an open issue (where as new TODO item would theoretically be pending review) and b) to reduce the number of 'new' bugs. I'm hoping b) will encourage devs to look at 'new' bugs on a regular basis (yes, you can view new bugs while excluding TODO bugs but this takes an extra step as long as the version of RT we're using won't let you save queries). I've also been trying (slowly) to get the subject line for all TODO items into this format: [TODO] - Robert has changed the online TODO list so that it is sorted alphabetically by subject (THANKS Robert!). http://www.parrotcode.org/TODO.html This causes all TODO items for the same subsystem/component/topic to be clustered together. For example, all of the IMCC TODOs now appear contiguously: (37244) [TODO] IMCC - cleanup grammar (37248) [TODO] IMCC - create a compiler API (32667) [TODO] IMCC - documentation needs updating (37245) [TODO] IMCC - fix symbol handling (37243) [TODO] IMCC - generate exact location info (24251) [TODO] IMCC - improve error messages (34669) [TODO] IMCC - make imcc.l compatible with modern flex (37247) [TODO] IMCC - remove globals (32391) [TODO] IMCC - remove lexer's identifier length restrictions (37246) [TODO] IMCC - remove stack calling conventions (37242) [TODO] IMCC - separate PASM and PIR parsers It would be a great help if TODO submitters would adopt this new subject line format. Cheers, -J -- pgpNaGbap0mY1.pgp Description: PGP signature
Re: [perl #37303] [PATCH] Relaxing parrot dependency on parrot_config
On Sun, Oct 16, 2005 at 11:56:16PM +0100, Nick Glencross wrote: > Here's an updated version of a patch to change how parrot picks up its > built-in configuration values. They are currently picked up by the > parrot library through globals linked against the executable. > > This patch changes the API so that the parrot environment starts without > a config (which makes linking pdb, disassemble et al. cleaner) and then > the executable can call Parrot_set_config_string to register the > environment. I'm guessing that this change in src/embed.c wasn't intended to be included in the patch: -mmap(0, program_size, PROT_READ, MAP_SHARED, fd, (off_t)0); +mmap(0, program_size, PROT_READ, MAP_PRIVATE, fd, (off_t)0); ??? -J -- pgpaQIwXq6vR8.pgp Description: PGP signature
Re: [perl #36197] [PATCH] make install fails with MinGW32
On Sun, Oct 16, 2005 at 11:46:25AM +0200, Fran?ois PERRAD wrote:
> At 21:09 04/10/2005 -0700, you wrote:
> >> [EMAIL PROTECTED] - Mon Jun 06 23:49:58 2005]:
> >>
> >>
> >> The following problem is the same that in [perl #35388],
> >> so the patch for root.in tries to generalize the solution.
> >>
> >> $ make install
> >> Invoking Parrot to generate install_config.fpmc
> >> ./parrot.exe config_lib.pasm --install > install_config.fpmc
> >> '.' is not recognized as an internal or external command, operable
> >program
> >> or batch file.
> >>
> >> Francois Perrad.
> >>
> >
> >Hi,
> >
> >Can you provide an explanation of what ${slash_exec} is?
>
> Now, ${slash_exec} is useless.
> The following patch removes it.
Can anybody confirm that this patch doesn't break MinGW?
-J
--
pgpVsSwcQOMXA.pgp
Description: PGP signature
Re: Copyrights in file headers
Does sticking "Copyright The Perl Foundation" at the top of a file constitute a legal transfer of copyright? Which is what I've been doing but It's my understanding that copyright can only be transfered by a written argument. This next statement isn't intending to stir up a flame-war but does TPF holding the copyrights really matter? AFAIK - The only value in having a single party holding _all_ the copyrights is to be able to change the licensing. Cheers, -J -- On Sun, Oct 16, 2005 at 06:24:56PM +0100, Nicholas Clark wrote: > On Sun, Oct 16, 2005 at 02:21:38PM +0100, Jonathan Worthington wrote: > > Hi, > > > > I keep running accros files that at the top of the file say they are > > copyrighted to individual people, then adding stuff to the code as surely > > many others have. Am I right in thinking that everything is supposed to be > > "Copyright The Perl Foundation"? This is what I've done with any new files > > I've added, but what is the policy on this? If there's some doc I should > > read, just point me at it. > > > > Just wondering. :-) > > I believe that Allison's answer from 3 months ago is still valid: > > On Tue, Jul 05, 2005 at 08:03:13PM -0700, Allison Randal wrote: > > On Jul 3, 2005, at 7:42, Will Coleda wrote: > > > > >I was under the impression that for any code to be included in the > > >parrot repository, that the copyright had to be assigned to the Perl > > >Foundation. But there are exceptions to this throughout the > > >repository, even in core files like imcc/main.c (Copyright Melvin > > >Smith). We have a file with a Microsoft copyright in the repository. > > > > > >What's the official policy? Is it documented somewhere in the > > >repository? (If not, can we get it documented?) > > > > The simple answer is yes, everything should be designated as copyright > > The Perl Foundation. > > > > But don't worry about it too much right now. After 12 months of work, > > we just about have the standard policy hammered out with the legal > > folks, and we'll do one big sweeping change sometime in the next few > > months. > > > > Thanks, > > Allison > > ( http://www.nntp.perl.org/group/perl.perl6.internals/30255 ) > > Nicholas Clark pgpa4Xm4mUoW2.pgp Description: PGP signature
Re: [perl #37336] [RESOLVED] [BUG] Parrot 0.3.0 t/pmc/io.t assert core dump
On Sat, Oct 15, 2005 at 11:09:38AM +0300, Jarkko Hietaniemi wrote: > Joshua Hoblitt via RT wrote: > > According to our records, your request regarding > > "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump" > > has been resolved. > > According to my records, it's a TODO test and therefore not quite > yet resolved :-) It's a test failure for unimplemented feature(s). There is already a TODO ticket (bug #31178) that ruffly covers this. Can you make a case for why it needs to be to tracked as a software defect? Cheers, -J -- pgp30ususpY4Y.pgp Description: PGP signature
