Re: NetBSD 1.6 - need to define _STRUCT_TIMESPEC
If to define _STRUCT_TIMESPEC, then compilation is successfully. Does NetBSD have pthread? Can you try to create a hint file netbsd.pl. NetBSD 1.6 do not have pthread, native thread support has been added into NetBSD 2.0. Can one use http://www.gnu.org/software/pth/pth.html (as mysql :-) ). Where may one define _STRUCT_TIMESPEC in config/*? It's need for include/parrot/thread.h . Can one use config/gen/platform/netbsd/thread.h ? Wiil Configure.pl have options to build with or with out threads? And how can one detect that parrot has been built with threads from /t/pmc/threads.t? s. config/init/hints/*.pl % make test All tests successful, 2 tests and 69 subtests skipped. Good. % make testexec ./hello Hello World Even better. leo
Re: Dates and Times
Interesting -- so the planet's finally gotten its act together and settled on a rotational speed, huh? Cool. :) Nobody said anything about a planet. A clock should tell you how much time has gone by. If I get a time, sleep(1), and get another time, time 2 should be about time1 + 1 second, regardless of leap seconds, what planet I'm on, etc. Translating a timestamp into a date is a separate issue from keeping track of time itself, and should be handled separately. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
[DOCS] hyperlinks
Fpath/file and CPerl::Module now become links in the HTML docs, if the target file contains POD. make html-clean make html Mike
Re: NetBSD 1.6 - need to define _STRUCT_TIMESPEC
Nick Kostirya [EMAIL PROTECTED] wrote: Can one use http://www.gnu.org/software/pth/pth.html (as mysql :-) ). PTH is better then nothing, albeit it's lacking preemption. Can one use config/gen/platform/netbsd/thread.h ? Yes. The configure system copies these file together, *if* they exist for the platform. If not fallbacks in generic/ are used. For 1.6 vs 2.0 you might need some additional work e.g. hack platform.pl to select files from either netbsd/1.6/ netbsd/2.0 or common code in netbsd. Wiil Configure.pl have options to build with or with out threads? If threads are avaiable they are used. Not using threads buys us nothing except less functionality. With threads compiled into Parrot doesn't get slower (not like Perl5's 10%-30% speed penalty). And how can one detect that parrot has been built with threads from /t/pmc/threads.t? Enable your platform in the list near the top of the file and run the tests. If they succeed (and not all are skipped) all is fine. leo
Re: [perl #27369] [PATCH] pretty-print for library/dumper.imc
On Thursday 04 March 2004 06:38, Will Coleda wrote:
When dumping a PMC type that isn't one dumper knows about, this small
patch changes it to print out a name in addition to the number, so we
get:
(Honestly, I'd prefer just the name, but I presume the original author
wanted the number for a reason)
Shame on me, I didn't know that there is a typeof_s_p OP... :-)
bash-2.05a$ cat foo.imc
.pcc_sub main prototyped
$P1 = new ParrotIO
_dumper($P1)
end
.end
.include library/dumper.imc
bash-2.05a$ ./parrot foo.imc
VAR1 = unknown-type(pmc #26:ParrotIO)
This can know be changed to print something like
VAR1 = ParrotIO { ... }
Then its possible to remove the special handling of the Sub object.
My next plan is to implement some optional parameters like a maximum recursion
deep and an array of PMCs not to recursively dump, in order to ease the
usesage with large data structures.
Printing some more information for ParrotIO, ParrotClass, ParrotObject,
OrderedHash, ManagedStruct and UnManagedStruct is also on my TODO list.
I have no idea how to dump the last three types, can anyone give me a hint?
jens
Re: [perl #27369] [PATCH] pretty-print for library/dumper.imc
Jens Rieks wrote: My next plan is to implement some optional parameters like a maximum recursion deep and an array of PMCs not to recursively dump, in order to ease the usesage with large data structures. How about the possibility to dump PASM, which can be read in by Parrot? Also the ability to dump, and read, YAML would be nice to have. Thinking about it, i think that there are many more formats we can think about. Printing some more information for ParrotIO, ParrotClass, ParrotObject, OrderedHash, ManagedStruct and UnManagedStruct is also on my TODO list. I have no idea how to dump the last three types, can anyone give me a hint? I have been looking into the dumping of OrderedHash. However I got confused with the different get_- and next- methods. I think the basic problem was that accessing a PerlArray with a PMC as a key didn't work. Even when the PMC was a PerlInt. CU, Bernhard -- ** Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Re: status update
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote: follow the scheme used in t/src/basic_3, i.e. run your code via Parrot_run_native(). Tried this, I think the interface to Parrot_run_native() is wrong, it should most likely be void* Parrot_run_native(Parrot, func, void*) ; so you can pass in arguments and return them Cheers Arthur
Re: [perl #27369] [PATCH] pretty-print for library/dumper.imc
On Thursday 04 March 2004 13:41, Bernhard Schmalhofer wrote: Jens Rieks wrote: My next plan is to implement some optional parameters like a maximum recursion deep and an array of PMCs not to recursively dump, in order to ease the usesage with large data structures. How about the possibility to dump PASM, which can be read in by Parrot? Good idea. Also the ability to dump, and read, YAML would be nice to have. Thinking about it, i think that there are many more formats we can think about. I can modifiy the dumper to be object orientated. Then one can subclass from it and override just the printing functions. As a side note, I am working on an EBNF parser generator, it might be usful for reading data dumps (http://parrot.jensbeimsurfen.de/library/EBNF/). Printing some more information for ParrotIO, ParrotClass, ParrotObject, OrderedHash, ManagedStruct and UnManagedStruct is also on my TODO list. I have no idea how to dump the last three types, can anyone give me a hint? I have been looking into the dumping of OrderedHash. However I got confused with the different get_- and next- methods. I think the basic problem was that accessing a PerlArray with a PMC as a key didn't work. Even when the PMC was a PerlInt. This has been corrected if i remember correctly. A possible workaround is of course to use an integer register, but being able to use a PMC as key is indeed nicer. Where can I find the methods? CU, Bernhard jens
Re: Dates and Times
At 7:30 PM -0800 3/3/04, TOGoS wrote: Interesting -- so the planet's finally gotten its act together and settled on a rotational speed, huh? Cool. :) Nobody said anything about a planet. Actually, they did. UTC (which was the original reference) is defined such that noon is within .9 seconds of the sun being as directly overhead as it can be, and is thus directly tied to the behaviour of the planet. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
OO benchmarks
I've run these 2 tests below.
Results don't look really good.
- Parrot consumes ever increasing memory, so it can't even run up to 10
- its slow (unoptimized build for now - but that doesn't matter yet)
- Parrot is leaking a vtable per new class and worse per new instance
- I'm currently trying to avoid the vtable_clone for new objects with
some success - I still have some test errors related to can or type.
Are these 2 programs somehow equivalent?
leo
$ cat o1.pl
#! perl -w
use strict;
for my $i (1 .. 10) {
my $o = new Foo();
}
my $o = new Foo();
print $o-[0], \n;
package Foo;
sub new {
my $self = ref $_[0] ? ref shift : shift;
return bless [ 10, 20 ], $self;
}
1;
$ cat o1.pasm
newclass P1, Foo
find_global P2, init
store_global Foo, __init, P2
addattribute P1, .i
addattribute P1, .j
set I10, 0
set I11, 2
loop:
find_type I1, Foo
new P3, I1
inc I10
#sleep 0.0001
lt I10, I11, loop
find_type I1, Foo
new P3, I1
classoffset I0, P3, Foo
getattribute P2, P3, I0
print P2
print \n
end
.pcc_sub init:
classoffset I0, P2, Foo
new P10, .PerlInt
set P10, 10
setattribute P2, I0, P10
inc I0
new P10, .PerlInt
set P10, 20
setattribute P2, I0, P10
invoke P1
Re: status update
Arthur Bergman wrote: On 3 Mar 2004, at 08:09, Leopold Toetsch wrote: follow the scheme used in t/src/basic_3, i.e. run your code via Parrot_run_native(). Tried this, I think the interface to Parrot_run_native() is wrong, it should most likely be void* Parrot_run_native(Parrot, func, void*) ; so you can pass in arguments and return them Its a run-loop. So it follows Parrot calling conventiosn (or should do so). on entry P5 ... Argv array on exit I5 ... status or P5 ... complex status like an exception or such Parrot does provide P5 (the argv array), the tests don't - no need to. Cheers Arthur leo
Re: [perl #27369] [PATCH] pretty-print for library/dumper.imc
Will Coleda [EMAIL PROTECTED] wrote: When dumping a PMC type that isn't one dumper knows about, this small patch changes it to print out a name in addition to the number Thanks, applied. leo
Re: [DOCS] Documentation tools
On 7 Feb 2004, at 00:53, Michael Scott wrote: On 6 Feb 2004, at 22:32, Leopold Toetsch wrote: - icu - lib/Test/* - lib/Pod/* are all standard thingys. I'm not thinking that we are gonna reinventing wheels nor that we are gonna copying existing wheels, so I'd vote for just removing all that from CVS. yep All non-trivial packages have some preliminaries. Some prominent notes in README and INSTALL can provide the necessary steps, how to get that source. I'd like to see Configure.pl say what's needed, and do what it can to help if requested. I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. I have a version here which works, but I remember from experience it can be tricky to set up CPAN.pm to work behind firewalls, so I'm wondering what collective wisdom has to say. Should we run CPAN.pm from Configure.pl or rely on prominent notes? Mike
Re: OO benchmarks
At 3:36 PM +0100 3/4/04, Leopold Toetsch wrote: I've run these 2 tests below. Results don't look really good. - Parrot consumes ever increasing memory, so it can't even run up to 10 - its slow (unoptimized build for now - but that doesn't matter yet) - Parrot is leaking a vtable per new class and worse per new instance - I'm currently trying to avoid the vtable_clone for new objects with some success - I still have some test errors related to can or type. Damn. Okay, I'm going to spend today digging into the object stuff to try and track down the leaks. Something's not right in there, as the DOD and GC ought to be reclaiming the dead memory. Are these 2 programs somehow equivalent? Yeah, they're about the same, though the class lookup is cached so it shouldn't have to be done every time through. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [DOCS] Documentation tools
At 3:40 PM +0100 3/4/04, Michael Scott wrote: On 7 Feb 2004, at 00:53, Michael Scott wrote: On 6 Feb 2004, at 22:32, Leopold Toetsch wrote: - icu - lib/Test/* - lib/Pod/* are all standard thingys. I'm not thinking that we are gonna reinventing wheels nor that we are gonna copying existing wheels, so I'd vote for just removing all that from CVS. yep All non-trivial packages have some preliminaries. Some prominent notes in README and INSTALL can provide the necessary steps, how to get that source. I'd like to see Configure.pl say what's needed, and do what it can to help if requested. I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
vtables as collectable objects
It'd be simple enough to do--prepend a PObj front to the vtables and allocate the vtables themselves out of a separate managed arena, and do a bit of custom mark noting. This'd make collecting up unused vtables easy enough. The downside to this is it means we add in a *lot* of extra pointer traversal, as we add in an extra live pointer for every live PMC in the system. It's a lot of extra work for the DOD. I'm up for it if we have to, but I'd prefer to not do it if we don't have to. Opinions, folks? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [DOCS] Documentation tools
On 4 Mar 2004, at 15:51, Dan Sugalski wrote: [...] I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. Which is how I originally looked at it when I added Pod::Simple. But then Robert asked why are we including CPAN modules that we are not likely to change into the parrot repository?, and Leo suggested the prominent notes approach, which left me with the impression that this was something that had to be dealt with. So, do I just leave Pod::Simple there? Mike
Re: vtables as collectable objects
Dan Sugalski wrote: It'd be simple enough to do--prepend a PObj front to the vtables and allocate the vtables themselves out of a separate managed arena, and do a bit of custom mark noting. This'd make collecting up unused vtables easy enough. The downside to this is it means we add in a *lot* of extra pointer traversal, as we add in an extra live pointer for every live PMC in the system. It's a lot of extra work for the DOD. I'm up for it if we have to, but I'd prefer to not do it if we don't have to. Rather not. But if we have to allocate a separate vtable, we should set a flag in the vtable-flags, mark the PMC as special, so that destroy can free the vtable. leo
Re: Dates and Times
Interesting -- so the planet's finally gotten its act together and settled on a rotational speed, huh? Cool. :) Nobody said anything about a planet. Actually, they did. UTC (which was the original reference) is defined such that noon is within .9 seconds of the sun being as directly overhead as it can be, and is thus directly tied to the behaviour of the planet. My point remains. Don't use UTC, then :) That's why we want to ignore leap seconds. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
Re: [DOCS] Documentation tools
On Mar 4, 2004, at 7:45 AM, Michael Scott wrote: On 4 Mar 2004, at 15:51, Dan Sugalski wrote: [...] I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. Which is how I originally looked at it when I added Pod::Simple. But then Robert asked why are we including CPAN modules that we are not likely to change into the parrot repository?, and Leo suggested the prominent notes approach, which left me with the impression that this was something that had to be dealt with. So, do I just leave Pod::Simple there? Personally, I think it's worth a few KB for the convenience we currently have, of being able to grab the parrot source and build without additional installation. (All of lib is only 187 KB compressed, and that includes the Parrot:: modules.) JEff
Re: OO benchmarks
On Thu, Mar 04, 2004 at 09:58:02AM -0500, Dan Sugalski wrote: : Damn. Okay, I'm going to spend today digging into the object stuff to : try and track down the leaks. Something's not right in there, as the : DOD and GC ought to be reclaiming the dead memory. Can I hit you with a cream pie at OSCON if Perl 5 runs faster than Parrot? :-) Larry
Re: Dates and Times
On Thu, Mar 04, 2004 at 09:12:47AM -0500, Dan Sugalski wrote: : At 7:30 PM -0800 3/3/04, TOGoS wrote: : Interesting -- so the planet's finally gotten : its act together and settled on a rotational : speed, huh? Cool. :) : : Nobody said anything about a planet. : : Actually, they did. UTC (which was the original reference) is defined : such that noon is within .9 seconds of the sun being as directly : overhead as it can be, and is thus directly tied to the behaviour of : the planet. The basic problem is that there are times you need to know exactly how many seconds have passed between two timestamps, and times you need to know exactly how many days have passed between two timestamps, and the two are in conflict. However, I think the more basic problem of the two is the first one. If you ignore that problem, you get all sorts of breakage down in random routines that you don't want breakage in, and this will only get worse as computers get faster, and try to syncronize more low level things. In contrast, the other problem tends to manifest in user interfaces, where it can typically be solved by some snap-to-grid semantics at the minute, hour, and day boundaries, at least until the second timer and the Earth drift apart by 30 seconds or so. Which will take a while. And anyone who needs greater UTC accuracy than that should probably be tracking TAI-UTF offsets anyway, or have some other way of resyncing their clock at least semiyearly. So anyway, I don't care whether Parrot builds in support for complicated time systems like UTC. (Well, I do care some--it should probably be a library in any event.) But I do care that Ctime - $^T be accurate. (In fact, I'd like $^T to change to a floater too, on systems that can support it. It's way past time for hi-res timing to be the default, I think.) Larry
Re: [perl #27369] [PATCH] pretty-print for library/dumper.imc
On Thu, 2004-03-04 at 04:17, Jens Rieks wrote: Printing some more information for ParrotIO, ParrotClass, ParrotObject, OrderedHash, ManagedStruct and UnManagedStruct is also on my TODO list. I have no idea how to dump the last three types, can anyone give me a hint? With *Struct, I'd like to see the layout. It'd be something like: Struct Type: - element offset (and name, if it exists) - size (probably datatype, like INT or NUM) - array (if it's an array) - padding, if any - value I'm not sure if there's access to the names from PASM, though. -- c
[perl #27391] parrot -t crash
# New Ticket Created by Jens Rieks # Please include the string: [perl #27391] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27391 Hi, The following code crashes parrot if run with -t (trace). It seems to be due to an unused .param, see line marked with XXX. jens .sub main __create_class( A ) __create_class( B ) find_type I0, A print type1: print I0 print \n new P0, I0 typeof I0, P0 print type2: print I0 print \n end .end .sub _A::__init .local pmc temp print _A::__init()\n find_type I0, B new temp, I0 __add_method( A, f1 ) __add_method( A, f2 ) __add_method( A, f3 ) .pcc_begin_return .pcc_end_return .end .sub _B::__init print _B::__init()\n __add_method( B, f1 ) .pcc_begin_return .pcc_end_return .end .sub _A::f1 .pcc_begin_return .pcc_end_return .end .sub _A::f2 .pcc_begin_return .pcc_end_return .end .sub _A::f3 .pcc_begin_return .pcc_end_return .end .sub _B::f1 .pcc_begin_return .pcc_end_return .end .sub __add_method .param string class .param string method .local string tmp .local pmc sub # construct the class'es method name set tmp, _ concat tmp, class concat tmp, :: concat tmp, method # find the sub find_global sub, tmp # store it as the method sub store_global class, method, sub .pcc_begin_return .pcc_end_return .end .sub __create_class .param string name .param pmc base .local pmc ret # XXX: it works if you remove the (unused) parameter base newclass ret, name # add the constructor __add_method( name, __init ) .pcc_begin_return .return ret .pcc_end_return .end
[PATCH] library/dumper.imc t/pmc/dumper.t
Hi,
this patch adds support for dumping of ParrotObjects.
If an object can __dump, this method is called on the object which then
is responsible for dumping itself.
A test that shows the new functionality in action is included.
jens
Index: library/dumper.imc
===
RCS file: /cvs/public/parrot/library/dumper.imc,v
retrieving revision 1.7
diff -u -w -r1.7 dumper.imc
--- library/dumper.imc 4 Mar 2004 12:44:45 - 1.7
+++ library/dumper.imc 4 Mar 2004 18:10:46 -
@@ -313,15 +313,23 @@
if exist, CALL_HELPER
typeof type_str, dump
-print unknown-type(pmc #
-print :
+print PMC '
print type_str
-print type
-print )
+print '
+can I0, dump, __dump
+if I0 goto CAN_DUMP
+print { ... }
branch DONE
+CAN_DUMP:
+# XXX method calling needs some work
+P2 = dump
+find_global cb, type_str, __dump
+branch DO_CALL_HELPER
+
CALL_HELPER:
cb = helper[type]
+DO_CALL_HELPER:
.pcc_begin prototyped
.arg name
.arg indent
Index: t/pmc/dumper.t
===
RCS file: /cvs/public/parrot/t/pmc/dumper.t,v
retrieving revision 1.4
diff -u -w -r1.4 dumper.t
--- t/pmc/dumper.t 23 Feb 2004 10:18:43 - 1.4
+++ t/pmc/dumper.t 4 Mar 2004 18:10:47 -
@@ -18,7 +18,7 @@
use strict;
-use Parrot::Test tests = 11;
+use Parrot::Test tests = 12;
# no. 1
output_is('CODE', 'OUT', dumping array of sorted numbers);
@@ -511,5 +511,61 @@
},
\VAR1[0].properties(),
\VAR1[1].properties()
+]
+OUT
+
+# no. 12
+output_is('CODE', 'OUT', dumping objects);
+##PIR##
+.sub _main
+.local pmc temp
+.local pmc array
+
+newclass temp, TestClass
+
+find_global temp, _TestClass::__dump
+store_global TestClass, __dump, temp
+
+find_type I0, TestClass
+new array, .PerlArray
+new temp, I0
+push array, temp
+new temp, I0
+push array, temp
+
+_dumper( array )
+end
+.end
+.sub _TestClass::__dump
+.param string name
+.param pmc dump
+.param pmc cache
+.param string indent
+
+print {\n
+
+print indent
+print this is\n
+
+print indent
+print _TestClass::__dump\n
+
+print indent
+print }
+
+.pcc_begin_return
+.pcc_end_return
+.end
+.include library/dumper.imc
+CODE
+VAR1 = PerlArray (size:2) [
+PMC 'TestClass' {
+ this is
+ _TestClass::__dump
+},
+PMC 'TestClass' {
+ this is
+ _TestClass::__dump
+}
]
OUT
Re: OO benchmarks
Leopold Toetsch [EMAIL PROTECTED] wrote: - its slow (unoptimized build for now - but that doesn't matter yet) Some more remarks to that. - Python is around at double the speed of perl here - Parrot seems to take too much time in delegate.pmc: - register preserving - method lookup - reentering run-loop Creating 100.000 new objects on a P600: PerlInt 0.15 s delegate 1.6 delegate, __init 2.9 The last one calls an empty __init sub and returns leo
Re: www.parrotcode.org/ points to 0.0.10
In a similar(?) vein, www.parrotcode.org/faq/ currently has a number of broken links, including apocalypses, PDD6, and Java bytecode to Parrot bytecode. This is because the links are funny. The best way to get proper links is to do something like: LThis is CNN|http://www.cnn.com That's not great.. but it tends to render better. Our official Pod renderer is Pod::Simple::HTML, so you can test it out. I'm throwing this back to p6i, so somebody can fix it, and maybe take another pass through the FAQ, addming more F.. A... Q...s ;) -R
Re: [DOCS] Documentation tools
I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. Huh? Dan, what are you smoking? Every project has dependencies. For now, perl5 and a handful of modules are one of parrot's prereqs. That's quite reasonable. If someone can't install a few perl5 modules, they probably shouldn't be building parrot. There's no reason to include large, independently maintained modules like Pod::Simple in the parrot CVS tree and tarball. It just turns into a maintenance nightmare, should we ever start modifying these things. And while the parrot tree is relatively small right now - it won't always be. Might as well keep it small while we can. I don't understand why you are insisting on including these things. Please clarify. -R
Re: Debian on parisc: Parrot 0.1.0 fails
On Wednesday 03 March 2004 19:50, Leopold Toetsch wrote: Daniel Grunblatt [EMAIL PROTECTED] wrote: When updating the old version I had at the TD machine to the current cvs version I realize that it fails right after start running, entering in an eternal loop, I could not find out exactly what is the problem but I think it's related to threads. It's Debian 3.0 on parisc using gcc 3.0.4 Any idea how to solve it? Provide more informatiion? $ cat myconfig Summary of my parrot 0.1.0 configuration: configdate='Wed Mar 3 12:56:25 2004' Platform: osname=HPUX, archname=PA-RISC1.1-thread-multi jitcapable=1, jitarchname=hppa-HPUX, jitosname=HPUX, jitcpuarch=hppa execcapable=0 perl=perl Compiler: cc='cc', ccflags='-DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -mpa-risc-1-1 -fPIC -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -lnm -lmalloc -ldld -lm -lpthread -lndir -lcrypt -lsec' Dynamic Linking: so='.so', ld_shared='-b -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=4321, nv=double, numvalsize=8, doublesize=8 Does it run: print hi\n end No If not, does it use threads? What does ps/top/whatever have? Where does it hang? Run it with s?trace or such. Or attach a debugger... spe170 gdb parrot GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa-linux... (gdb) r t.pasm Starting program: /house/grunblat/hp-ux/parrot/parrot t.pasm -- I press ^C after some time -- Program received signal SIGINT, Interrupt. 0x401e2d54 in ?? () (gdb) bt #0 0x401e2d54 in ?? () (gdb) So it's not so usefull. In top it has the R stat. I think it fails at: (gdb) b pmc.c:40 Breakpoint 2 at 0x5b5c8: file src/pmc.c, line 40. (gdb) r Starting program: /house/grunblat/hp-ux/parrot/parrot Breakpoint 1, pmc_init_null (interpreter=0x205030) at src/pmc.c:40 40 LOCK(init_null_mutex); (gdb) n Program received signal SIGINT, Interrupt. 0x401e2d54 in ?? () (gdb) bt #0 0x401e2d54 in ?? () (gdb) Could 3.0.4 be too old? Too many questions ... I'll try to install 3.3.3, but I'm not sure if it will compile given it's a TD machine. Daniel. leo
Re: Dates and Times
On Thu, 4 Mar 2004, TOGoS wrote: Actually, they did. UTC (which was the original reference) is defined such that noon is within .9 seconds of the sun being as directly overhead as it can be, and is thus directly tied to the behaviour of the planet. UTC may stop tracking UT1 and stop having [new] leap-seconds. Even if this happens we'll still have to take leap-seconds into account for dates prior to 1999. My point remains. Don't use UTC, then :) That's why we want to ignore leap seconds. I agree. That's why I'd like to see TAI be the default seconds since some epoch. -J --
Re: [DOCS] Documentation tools
On Thu, Mar 04, 2004 at 03:40:27PM +0100, Michael Scott wrote: : I'd like to remove non-modified, non-parrot Perl modules from lib and : install them via CPAN.pm. I have a version here which works, but I : remember from experience it can be tricky to set up CPAN.pm to work : behind firewalls, so I'm wondering what collective wisdom has to say. : Should we run CPAN.pm from Configure.pl or rely on prominent notes? The only sane course forward is to separate the notion of developer distribution from user distribution. The developer codebase should have no fat, and can have external dependencies out the wazoo. The user distribution (and there can be more than one--see Linux) provides all the bells and whistles that the distributor sees fit, and should generally shield the user from having to download anything commonly in use. Ideally, the developer codebase should be completely *unusable* by mere mortals, to prevent ISPs from installing that and claiming they support Perl. They need to be forced to install a user-oriented distribution. Just like you can't merely install the Linux kernel and say you're done. I think this is one of those situations where having our cake and eating it too is not just an option, but a requirement. Larry
Re: [DOCS] Documentation tools
Dan Sugalski [EMAIL PROTECTED] wrote: No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. What about ICU. There is already a new version pending (again). leo
Re: www.parrotcode.org/ points to 0.0.10
I just reported this as a bug on Pod::Simple::HTML. The problem is in line 168-9 my $out = $to if defined $to and length $to; $out .= # . $section if defined $section and length $section; One of those Deprecated use of my() in conditional cases they've been talking about on perl5-porters. my $out; $out = $to if defined $to and length $to; $out .= # . $section if defined $section and length $section; fixes it. Looks like we'll be modifying Pod-Simple after all. Mike On 4 Mar 2004, at 20:33, Robert Spier wrote: In a similar(?) vein, www.parrotcode.org/faq/ currently has a number of broken links, including apocalypses, PDD6, and Java bytecode to Parrot bytecode. This is because the links are funny. The best way to get proper links is to do something like: LThis is CNN|http://www.cnn.com That's not great.. but it tends to render better. Our official Pod renderer is Pod::Simple::HTML, so you can test it out. I'm throwing this back to p6i, so somebody can fix it, and maybe take another pass through the FAQ, addming more F.. A... Q...s ;) -R
Re: [DOCS] Documentation tools
No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. What about ICU. There is already a new version pending (again). Since we haven't actually used ICU yet, I see no reason to integrate the new version until we use the old one. And personally, I'd rather rip it out of the tree and say we're just going to link against the installed version -R
Re: OO benchmarks
Dan Sugalski wrote:
At 3:36 PM +0100 3/4/04, Leopold Toetsch wrote:
I've run these 2 tests below.
Results don't look really good.
Damn. Okay, I'm going to spend today digging into the object stuff to
try and track down the leaks. Something's not right in there, as the DOD
and GC ought to be reclaiming the dead memory.
I've a patch now (attached) - runs all tests. Please have a look at it.
- GC was blocked during list.c:allocate_chunk(). I've removed that -
it's very likely unneeded and wrong
- Parrot_new_class - class_register allocates now a ParrotObject vtable
- with this the cloning during instantiation isn't needed anymore
- so the huge memory leak (~100 MB) for loop count 100.000 is gone
- not cloing the vtable saves about 10% execution time
Are these 2 programs somehow equivalent?
Yeah, they're about the same, though the class lookup is cached so it
shouldn't have to be done every time through.
Good, makes it faster ;)
leo
--- parrot/classes/parrotclass.pmc Thu Mar 4 08:47:45 2004
+++ parrot-leo/classes/parrotclass.pmc Thu Mar 4 15:25:28 2004
@@ -84,7 +84,7 @@
*/
-INTVAL isa(STRING * classname) {
+INTVAL isa(STRING* classname) {
PMC *class;
if (SUPER(classname))
return 1;
--- parrot/classes/parrotobject.pmc Thu Mar 4 08:47:45 2004
+++ parrot-leo/classes/parrotobject.pmc Thu Mar 4 16:10:38 2004
@@ -104,10 +104,41 @@
*/
PMC* find_method(STRING* name) {
-PMC *class = VTABLE_get_pmc_keyed_int(INTERP, (PMC *)PMC_data(SELF), 0);
-return Parrot_find_method_with_cache(INTERP, class, name);
+if (PObj_is_class_TEST(SELF))
+return SUPER(name);
+pmc = VTABLE_get_pmc_keyed_int(INTERP, (PMC *)PMC_data(SELF), 0);
+return SUPER(name);
}
+INTVAL type() {
+if (PMC_data(SELF)) {
+PMC *class = VTABLE_get_pmc_keyed_int(INTERP,
+(PMC *)PMC_data(SELF), 0);
+pmc = class;
+return SUPER();
+}
+return enum_class_ParrotObject;
+}
+
+INTVAL can(STRING* name) {
+if (PObj_is_class_TEST(SELF))
+return SUPER(name);
+pmc = VTABLE_get_pmc_keyed_int(INTERP, (PMC *)PMC_data(SELF), 0);
+return SUPER(name);
+}
+
+INTVAL isa(STRING* classname) {
+if (PObj_is_class_TEST(SELF)) {
+/* newclass returns a PMC with a ParrotObject vtable
+ * but this object isn't yet an objects so:
+ */
+if (string_equal(INTERP,
+const_string(INTERP, ParrotObject),
+classname) == 0)
+return 0;
+}
+return SUPER(classname);
+}
}
/*
--- parrot/src/list.c Thu Mar 4 13:08:54 2004
+++ parrot-leo/src/list.c Thu Mar 4 16:25:00 2004
@@ -230,7 +230,7 @@
List_chunk *chunk;
Parrot_block_DOD(interpreter);
-Parrot_block_GC(interpreter);
+/*Parrot_block_GC(interpreter); - why */
chunk = (List_chunk *)new_bufferlike_header(interpreter, sizeof(*chunk));
chunk-items = items;
chunk-n_chunks = 0;
@@ -239,7 +239,7 @@
chunk-prev = NULL;
Parrot_allocate_zeroed(interpreter, (Buffer *)chunk, size);
Parrot_unblock_DOD(interpreter);
-Parrot_unblock_GC(interpreter);
+/*Parrot_unblock_GC(interpreter); */
return chunk;
}
@@ -769,17 +769,17 @@
chunk = chunk_list[ idx / MAX_ITEMS ]
idx = idx % MAX_ITEMS
done.
-
+
chunk = first
repeat
if (index chunk-items)
done.
-
+
if (index = items_in_chunk_block)
index -= items_in_chunk_block
chunk += chunks_in_chunk_block
continue
-
+
calc chunk and index in this block
done.
@@ -1942,7 +1942,7 @@
Greater threshold before Cdo_sparse(). Setting initial size to avoid
sparse
-=item * 1.33
+=item * 1.33
04.07.2003 Use a SArray for user_data
--- parrot/src/objects.cWed Mar 3 15:18:05 2004
+++ parrot-leo/src/objects.cThu Mar 4 16:29:04 2004
@@ -366,7 +366,15 @@
* good base to work from
* XXX we are leaking this vtable
*/
+#if 0
new_vtable = Parrot_clone_vtable(interpreter, new_class-vtable);
+#else
+/* use a ParrotObject vtable so that cloning it in instantiate
+ * can be avoided
+ */
+new_vtable = Parrot_clone_vtable(interpreter,
+Parrot_base_vtables[enum_class_ParrotObject]);
+#endif
/* register the class */
VTABLE_set_pmc_keyed_str(interpreter, interpreter-class_hash,
@@ -406,19 +414,27 @@
INTVAL attrib_count;
PMC *class_array;
PMC *class;
+#if 0
INTVAL class_enum;
+#endif
PMC *class_name;
class = object-vtable-data;
/* * remember PMC type */
+#if 0
class_enum = object-vtable-base_type;
/* put in the real vtable
* XXX we are leaking ths vtable
+ * the vtable currently only differs from ParrotObject's
Re: Dates and Times
I agree. That's why I'd like to see TAI be the default seconds since some epoch. It seems like we want the default to be the simplest and fastest one we can support. If someone wants something different, they can do the moral equivalent of: use Time::TAI; or use Time::UTC; or use Time::MacEpoch; -R
Re: [DOCS] Documentation tools
There's no reason to include large, independently maintained modules like Pod::Simple in the parrot CVS tree and tarball. It just turns into a maintenance nightmare, should we ever start modifying these things. [...] I don't understand why you are insisting on including these things. One reason might be reducing uncertainty. Including modules otherwise available from CPAN lets us control the versions used for parrot testing. We've already seen bugs resulting from using one version of perl rather than another. They are a pain to track down. Will myconfig start reporting on module version numbers too? Including modules insulates the parrot distribution from the vagaries of CPAN, and the enormously greater vagaries of peoples' local module installations. I can test parrot against any of my perl installs, without worrying about what is or isn't installed in them. I wonder how many potential testers we might lose if testing becomes an involved, site modifying exercise, rather than the current simple one? As you point out, these modules are not there to be edited. In a sense, they are there to prevent others from editing them, and thus affecting our users, without our being able to test them with the distribution first. Bundling modules when delivering software to a machine one doesn't control is actually quite common. Though admittedly something other languages (eg Tcl) have focused more on (and are better at;). The determinism seems perhaps worth the bloat. It's quite localize bloat after all. Mitchell (Though I certainly sympathize with the desire to scrub some of the accumulated cruft out the distribution... :)
parrotbug working...
... or at least for some definition of working.
The mails are indeed sent to parrotbug, parrotstatus-ok and
parrotstatus-nok (at parrotcode.org) for resp. bug reports, ok reports
or nok reports. And since I don't think those addresses are set up...
parrotbug -h will give you some indications on how to use it, but
basically you can do one of the following 4 actions:
- parrotbug -ok = report a successful build
- parrotbug -nok = report a failed build
- parrotbug -d = dump your config and environment
- parrotbug = prompts for questions and send
TODO:
- clean up / factorise code in send_msg
- allow for user to review what will be sent
- tests with various flavours of perl (and especially perl 5.005)
- tests with various OS
- change the flags set (and maybe use Getopt::Long)
Leopold Toetsch wrote:
Jerome Quelin [EMAIL PROTECTED] wrote:
- should we include myconfig in ok reports?
No IMHO. But *if* possible, enough information to keep PLATFORMS (or
a better variant of that) up to date - which still needs a bit more
inside tests but I think that we should go towards such a system.
perlbug do send config information on ok reports...
- should we include more than myconfig in nok / bug reports?
OS-Version, compiler-version. $PConfig{} is lacking some info here.
The reports include os name, os version, arch name and cc version.
*But* those information are all taken from Perl's Config module...
There are still a lot of issues:
- make test runs now the slow core only
- make fulltest tries to run all cores, but might fail if e.g. JIT or
CGoto isn't avaiable, and we get several results
- EXEC core is untested except for make testexec
Yup, but what to do? It's not the goal of parrotbug to automatically run
make insert-here-your-favorite-test-target...
And an ok report is ok, if make testC fails on windows/msc, but is
really nok, if it fails on gcc based systems.
Erm. I'm not this far in the work :-)
Jerome
--
[EMAIL PROTECTED]
Re: parrotbug working...
The mails are indeed sent to parrotbug, parrotstatus-ok and parrotstatus-nok (at parrotcode.org) for resp. bug reports, ok reports or nok reports. And since I don't think those addresses are set up... Not yet. I'm nudging Ask regularly about this. -R
Re: [DOCS] Documentation tools
The determinism seems perhaps worth the bloat. It's quite localize bloat after all. I disagree. We _want_ a heterogeneous environment -- a homogeneous environment doesn't exist in the real world -- most of your concerns were with tracking down the issues. Since we have parrotbug now (or real soon) we can take a better snapshot of whats going on. If we want to require certain versions, that becomes a problem ot some people. But we can do it by providing URL's to where people can download the specific versions and instructions on how to set that up for parrot's use only. But we don't need to bundle it _with_ Parrot. -R
Re: [PATCH] library/dumper.imc t/pmc/dumper.t
Hi, On Thursday 04 March 2004 19:14, I wrote: this patch adds support for dumping of ParrotObjects. If an object can __dump, this method is called on the object which then is responsible for dumping itself. A test that shows the new functionality in action is included. applied by Dan, thanks! jens
MANIFEST problems (was: Re: cvs commit: parrot parrotbug)
Hi, On Thursday 04 March 2004 00:53, Robert Spier wrote: parrotbug is missing in MANIFEST which causes a make test error. Now lib/Parrot/Docs/HTMLPage.pm is missing in MANIFEST. This kind of bug shouldn't happen if people actually read the messages the cvs commit spits out. It will tell you that the manifest check it runs on every commit fails. Please don't ignore it. Maybe a silly proposal, but nevertheless: Why are files not added to MANIFEST automatically on cvs add? Removing them from there should be less troublesome than having to add entries by hand. -R jens
Re: MANIFEST problems (was: Re: cvs commit: parrot parrotbug)
This kind of bug shouldn't happen if people actually read the messages the cvs commit spits out. It will tell you that the manifest check it runs on every commit fails. Please don't ignore it. Maybe a silly proposal, but nevertheless: Why are files not added to MANIFEST automatically on cvs add? Removing them from there should be less troublesome than having to add entries by hand. It's generally considered bad (and difficult) to modify things on the server after a commit. Also, then you don't find accidental checkins. Maybe I should have it start emailing the committer when the manifest check fails. -R
Re: [DOCS] Documentation tools
But once we start expecting people in the real world to compile this thing on their boxes in order to install perl, it would be extremely foolish to make them manually download and install perl6 + parrot + icu + perl5 + cpan modules 1 through 10, all from different sources. Try building any other large system. We don't know what this is going to look like when perl6 is done. One thing we can always do is create a tarball of tarballs, or a web page that says: 1. click _here_ to download perl 5.12.1 2. click _here_ to download parrot 1.3 3. click _here_ to download perl 6.0.14 we've had enough trouble with ICU, keeping it up to date, and we're not even using it. (And I'd wager we never use it.) there are already existing, well known, methods for distributing all these things. Maybe I'm old school, but I'd rather download 5 small or medium sized things than one huge thing. It also makes it a lot easier to change/upgrade just one piece. Why are we reinventing wheels? Why are we shipping extra bits around? IMHO, the releases better include everything necessary to build the application, within reason. Consistency and simplicity counts for a lot. Why create headaches we don't need? within reason. Thats where we're way off right now. The development environment can of course be more fluid. Ok. So lets rip all the crap out, and in two years when it comes time to release 1.0, we can re-think what needs to go in. -R
Re: Debian on parisc: Parrot 0.1.0 fails
Daniel Grunblatt [EMAIL PROTECTED] wrote: $ cat myconfig Nothing special here AFAIK. spe170 gdb parrot When it hangs: - run parrot in one console - open a 2nd console - get the pid(s) of parrot $ ps -C parrot - start debugger $ gdb parrot the_pid $ bt Breakpoint 1, pmc_init_null (interpreter=0x205030) at src/pmc.c:40 40 LOCK(init_null_mutex); (gdb) n So something is definitely wrong with your pthread library. Look at your pthread documentation and compare the macros with include/parrot/thr_pthread.h. leo
Re: cvs commit: parrot/src objects.c
Dan Sugalski [EMAIL PROTECTED] wrote: Speed up object creation by a factor of two That *would* be nice. *But* it's only slightly faster. You might have had a speed up due to less memory consumption, not swapping or such, because the leaking vtable memory is fixed. We are still seeking a factor of 4. leo
