Re: [perl #27465] [PATCH] Library to access configuration info
Brent Dax [EMAIL PROTECTED] wrote: The attached patch creates a Parrot-level library similar to Parrot::Config. Wow. Fine. The first real application of freeze/thaw. And thanks for the optical changes in Configure.pl - looks really great now. leo
Re: A Perl Task - Benchmarking
Sebastian Riedel [EMAIL PROTECTED] wrote: objective-ook? - SCNR Attached is a quick'n dirty parrotbench, instead of a complicated test harness it uses bash to make time measurements, so that new languages are very simple to add. bash isn't really available on all systems, so it should better use one of the time functions. Currently it's just a proof of concept but if you like it i will make a better version with pretty printing, extended reports and stuff. Good. Please have a look at lib/Parrot/Test.pm:_run_command and Config.pm for executable names. Maybe a config file could simplify the task (user can put in executable names once). Here's an example run: $ perl tools/dev/parrotbench.pl -regex '(oo|str|mops).*' \ -parrot='./parrot -j' -perl=`which perl` -python=`which python` \ -ruby=`which ruby` parrot perlpython ruby mops0.260 96.140 9.830 9.860 oo1 1.700 0.820 0.510 - oo2 8.410 4.602.400 - stress 0.980 0.640 - - stress1 13.970 12.400 - - stress2 1.670 2.450 - - stress3 10.540 - - - (Python and Ruby mops are running 1/10th of loops - files linked into examples/benchmarks) Nice. Yes please. Any one out there, who speaks ruby and can translate tests, for which we have a '.pl' file?. Thanks, leo
Re: A Perl Task - Benchmarking
Leopold Toetsch wrote: Sebastian Riedel [EMAIL PROTECTED] wrote: objective-ook? - SCNR :) Attached is a quick'n dirty parrotbench, instead of a complicated test harness it uses bash to make time measurements, so that new languages are very simple to add. bash isn't really available on all systems, so it should better use one of the time functions. Attached is a new version using times() Currently it's just a proof of concept but if you like it i will make a better version with pretty printing, extended reports and stuff. Good. Please have a look at lib/Parrot/Test.pm:_run_command and Config.pm for executable names. Maybe a config file could simplify the task (user can put in executable names once). Working on it Here's an example run: $ perl tools/dev/parrotbench.pl -regex '(oo|str|mops).*' \ -parrot='./parrot -j' -perl=`which perl` -python=`which python` \ -ruby=`which ruby` parrot perlpython ruby mops0.260 96.140 9.830 9.860 oo1 1.700 0.820 0.510 - oo2 8.410 4.602.400 - stress 0.980 0.640 - - stress1 13.970 12.400 - - stress2 1.670 2.450 - - stress3 10.540 - - - (Python and Ruby mops are running 1/10th of loops - files linked into examples/benchmarks) Nice. Yes please. Any one out there, who speaks ruby and can translate tests, for which we have a '.pl' file?. Thanks, leo Cheers, Sebastian parrotbench.patch.gz Description: application/tgz
Re: cvs commit: parrot/src objects.c
At 8:22 AM +0100 3/5/04, Leopold Toetsch wrote: 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. Nah, I'm seeking a factor of 7 or 8. This was just a quick bug-fix. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
reparenting during destruction
Okay, I've been thinking about this as I dig through object stuff. (Whee!) What I'm thinking is that when we're in a DESTROY method (of any type, I don't care) we tag the object as partially destroyed as soon as control leaves DESTROY and if code outside that first DESTROY tries to reparent the object, we throw an exception. That way we allow the first DESTROY we call to reparent the object (if it has some reason to) but once we've left that first DESTROY and therefore may have a partially dead object it's too late and we can't. This does require tracking pointer stores and generations, unfortunately. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: parrotbug working...
At 10:38 AM + 3/5/04, Rafael Garcia-Suarez wrote: Jerome Quelin wrote in perl.perl6.internals : But what should those addresses do when receiving a message? - parrotbug: should open a RT ticket? - status-ok: ? - status-nok: should open a RT ticket? Excuse me from stepping in, but I don't see why three adresses are necessary. From my (limited) knowledge of RT, I thing that the parrot bug address could create a ticket in the parrot queue, or add the mail body to the appropriate ticket if the subject contains [perl #X] -- then, it could close the ticket automatically if the subject matches an OK report. The big reason is to potentially reduce the load on the receiving end of things. The OK and NOK messages may or may not go into an RT ticket--it's perfectly reasonable to have them go to a custom front end processor that picks out just the interesting bits, logs them, and tosses the mail. (Tossing any mail that doesn't meet the criteria we need) Mail to the bug address, OTOH, should open a ticket, which means a lot more front-end processing, despamming, virus checking, and whatnot. Not that this *has* to be the way things are done, just that if we split it out it *can* be done that way. Robert and Ask can direct all three addresses to the same spot if they want. With the split they just have more options available. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cygwin
At 2:42 AM +0200 3/6/04, Dmitry Nikolayev wrote: Did Somebody try to assemble parrot on CygWin? I tried... perl configure.pl - ok make - and error ocured: gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt blib/lib/libparrot.a(io_unix.o)(.text+0x8f7): In function `PIO_sockaddr_in': /inst/parrot/io/io_unix.c:626: undefined reference to `_inet_pton' collect2: ld returned 1 exit status make: *** [parrot.exe] Error 1 What is the problem? Some of the new networking stuff, I think. I started up a cygwin tinderbox run on oni, so if we can get the tinderbox to actually notice it we'll be in a position to do something about it. (I can only do indirect work on the XP box here -- the remote desktop's a little too slow and sluggish to be usable for much dev work on my iBook) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
At 12:55 PM -0800 3/4/04, Robert Spier wrote: 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. Exactly. Which is the count that the system C RTL returns when you ask it, normally claimed to be GMT or something very much like it. If the local system returns localtime, I can see adjusting to GMT or UTC, or whatever, as that ought to be a trivial transform. Past that libraries can deal with it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: OO benchmarks
At 9:04 AM -0800 3/4/04, Larry Wall wrote: 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? Only if I can return the favor if it goes the other way. :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vtables as collectable objects
At 4:51 PM +0100 3/4/04, Leopold Toetsch wrote: 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. That works for one-off vtables, but doesn't work in the case of shared vtables. Those may happen if we allow unloading of classes, but I think I've a way around that one. I think. -- 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 4:45 PM +0100 3/4/04, 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. It's an ongoing fight between the go get the libs and install them folks and the self-contained distribution folks. I'm in the latter category. :) So, do I just leave Pod::Simple there? Depends on when Pod::Simple showed up in the standard perl distribution. If it can be reasonably expected to be there and working back to 5.6.0, *and* we gracefully fail if it's not there, we can leave it out. If not, it stays in. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: subclassing bug
At 10:20 PM +0100 3/2/04, Jens Rieks wrote: The following code results in a clone() not implemented in class 'ParrotClass' error: .sub _main .local pmc a .local pmc b .local pmc c newclass a, A subclass b, a, B subclass c, b, C end .end Steve was right -- the clone I was using was getting in the way. (And flat-out busted, honestly) Only a shallow copy of the parent class' array is needed here, so I put in a bit of custom code rather than use the clone and it works properly now. -- 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 11:49 AM -0800 3/4/04, Robert Spier 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. Huh? Dan, what are you smoking? Real Good Crack. And I'm going to keep on smoking it. What we have right now is essentially a user distribution of Parrot. It's self-contained. It's a pain. It *should* be a pain--that pain is what keeps the dependency count down. The rule, as it stands (and will continue to stand) is that anything that's needed to get a parrot build from distribution to installable executable ships with parrot. Period. Things that *aren't* needed don't have to be in the tarball, and its up to the source pumpking to decide if it's acceptable. Rebuilding the grammar source for IMCC requires lex and yacc. We don't ship 'em, you have to have them installed, that's fine. We don't *need* them to build parrot from a distribution or checkout. I said way back when that the only thing anyone will need to build parrot from a release is a C compiler and *maybe* a make tool. (ICU may require us to open that up to a C++ compiler too) That's it, and it hasn't changed. Unless, of course, you'd rather we generally distribute binaries rather than source. That'd certainly make our lives a lot easier, but I'd really rather not go that route. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: OO benchmarks
At 8:20 PM +0100 3/4/04, Leopold Toetsch wrote: 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 Well, I just committed a change to the system that should speed up object creation a bunch, as it doesn't need to allocate a vtable for each object any more. Still not great, but better. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #27391] parrot -t crash
At 4:03 PM +0100 3/5/04, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: Hi, The following code crashes parrot if run with -t (trace). Some more notes: - it happens with or w/o ARENA_DOD_FLAGS - it happens with the copying GC or with --gc=libc - it does not happen with DOD/GC disabled - It's been happening for quite a while. There have been a number of times when I haven't been able to run with -t with code that uses ncurses.pasm or postgres.pasm. (Though sometimes it works as well, which is darned annoying) Never took the tiem to track it down, though. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] library/dumper.imc t/pmc/dumper.t
At 7:14 PM +0100 3/4/04, Jens Rieks 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, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
On 3/4/04 5:09 PM, Dan Sugalski wrote: If the local system returns localtime, I can see adjusting to GMT or UTC, or whatever, as that ought to be a trivial transform. Er, I'm not so sure about that. That means you'd have to be 100% sure that you can determine the local timezone without any ambiguity. That has not proven to be the case if the DateTime.pm project is any indication... -John
Re: Compile-time undefined sub detection
At 8:47 AM +1100 3/6/04, Damian Conway wrote: Larry wrote: Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with Perl 5 and with software engineering jargon. How 'bout we make these properties on the subs instead of custom sub names? There are some times when its useful to have a sub callable by name as well as at a specified time in the startup sequence. (Which is what parrot'll be doing *anyway*--BEGIN blocks will be subs with bogus names with the :begin property on them, or something like that) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: subclassing bug
On Thu, 4 Mar 2004, Dan Sugalski wrote: At 10:20 PM +0100 3/2/04, Jens Rieks wrote: The following code results in a clone() not implemented in class 'ParrotClass' error: .sub _main .local pmc a .local pmc b .local pmc c newclass a, A subclass b, a, B subclass c, b, C end .end Steve was right -- the clone I was using was getting in the way. (And flat-out busted, honestly) Only a shallow copy of the parent class' array is needed here, so I put in a bit of custom code rather than use the clone and it works properly now. Which leads me to ask a question that I've been pondering for a while -- do we actually need to use a fullblown Array PMC to hold the object meta-information and attributes? Couldn't we save a level of indirection (and one PMC header per object) by using a List structure directly? Simon
A note WRT constants in PASM/PIR
Explicit constants to opcodes like warnings{on,off} and errors{on,off}
are likely to change in the future. Please use the constants from
warnings.pasm or errors.pasm.
so don't do:
errorsoff 1
but
.include errors.pasm
errorsoff .PARROT_ERRORS_GLOBALS_FLAG
leo
Re: OO benchmarks
Dan Sugalski [EMAIL PROTECTED] wrote: Well, I just committed a change to the system that should speed up object creation a bunch, as it doesn't need to allocate a vtable for each object any more. Please cvs update and have a look at benchmarks/oo*. I'v speeded object creation up by a factor of 3 - after your patch. leo
Re: vtables as collectable objects
Dan Sugalski [EMAIL PROTECTED] wrote: At 4:51 PM +0100 3/4/04, Leopold Toetsch wrote: 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. That works for one-off vtables, but doesn't work in the case of shared vtables. Those may happen if we allow unloading of classes, but I think I've a way around that one. I think. The we'll make the flag bigger and call it refcount :) Shared (COWed) resources *have* a refcount during DOD anyway. Dan leo
Re: [perl #27391] parrot -t crash
Dan Sugalski [EMAIL PROTECTED] wrote: - It's been happening for quite a while. This one is fixed already. I've here two more fixed - one (the final) is still sitting around. leo
Re: [perl #27391] parrot -t crash
At 7:23 PM +0100 3/7/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: - It's been happening for quite a while. This one is fixed already. I've here two more fixed - one (the final) is still sitting around. Yeah, I saw that. I do apologize for the recent flood of e-mail--what I wrote is actually relatively old (day or so) but got caught in my queue for some reason. I unblocked it and things went flooding out, though I don't quite know why. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cygwin
[Sorry if you get this twice--Thunderbird botched the mail sending.] Dan Sugalski wrote: Some of the new networking stuff, I think. I started up a cygwin tinderbox run on oni, so if we can get the tinderbox to actually notice it we'll be in a position to do something about it. (I can only do indirect work on the XP box here -- the remote desktop's a little too slow and sluggish to be usable for much dev work on my iBook) Depending on the version of XP, you might have a telnet service lying around on your hard drive and/or install disk. (I know that 2000 Pro had one--I've enabled it once or twice, usually back in high school when I wanted to access it in AP Computer Science.) And with Cygwin tools around, it wouldn't be hideously painful to use the command line. Come to think of it, you might be able to find a telnetd or sshd for Cygwin... -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: A Perl Task - Benchmarking
Sebastian Riedel wrote: Leopold Toetsch wrote: Sebastian Riedel [EMAIL PROTECTED] wrote: objective-ook? - SCNR :) Attached is a quick'n dirty parrotbench, instead of a complicated test harness it uses bash to make time measurements, so that new languages are very simple to add. bash isn't really available on all systems, so it should better use one of the time functions. Attached is a new version using times() Currently it's just a proof of concept but if you like it i will make a better version with pretty printing, extended reports and stuff. Good. Please have a look at lib/Parrot/Test.pm:_run_command and Config.pm for executable names. Maybe a config file could simplify the task (user can put in executable names once). Working on it The attached version should do most of the things you wanted. [EMAIL PROTECTED]:~/parrot$ tools/dev/parrotbench.pl -regex oo -conf ../parrotbench.conf parrot perlpython ruby oo1 100%39% 23% - oo2 100%40% 22% - I studied the config system, and now i wonder if it would make sense to write a configure step to probe for enemies, or is that overkill? Here's an example run: $ perl tools/dev/parrotbench.pl -regex '(oo|str|mops).*' \ -parrot='./parrot -j' -perl=`which perl` -python=`which python` \ -ruby=`which ruby` parrot perlpython ruby mops0.260 96.140 9.830 9.860 oo1 1.700 0.820 0.510 - oo2 8.410 4.602.400 - stress 0.980 0.640 - - stress1 13.970 12.400 - - stress2 1.670 2.450 - - stress3 10.540 - - - (Python and Ruby mops are running 1/10th of loops - files linked into examples/benchmarks) Nice. Yes please. Any one out there, who speaks ruby and can translate tests, for which we have a '.pl' file?. Thanks, leo Cheers, Sebastian Cheers, Sebastian parrotbench.patch.gz Description: application/tgz
[perl #27491] [PATCH] speling error: DECSRIPTION
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27491] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27491 Hi, this patch fixes a speling error in some of the test files: DECSRIPTION - DESCRIPTION. CU, Bernhard -- /* [EMAIL PROTECTED] */ +++ NEU bei GMX und erstmalig in Deutschland: TV-geprfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz decsription_20040308.patch Description: Binary data
Re: [perl #27491] [PATCH] speling error: DECSRIPTION
On Sun, 2004-03-07 at 15:25, Bernhard Schmalhofer wrote: this patch fixes a speling error in some of the test files: DECSRIPTION - DESCRIPTION. Thanks, applied. Now 'DECSRIPTION' appears nowhere in the source directory. -- c
Re: A Perl Task - Benchmarking
Sebastian Riedel wrote: I studied the config system, and now i wonder if it would make sense to write a configure step to probe for enemies, or is that overkill? Overkill doesn't even begin to describe it. It ought not to be too difficult to look for enemies at the beginning of your little script. I'd imagine that you could reasonably stipulate that the interpreters have to be in your PATH or specified on the command line somehow. (And Perl's location should be in Parrot::Config anyway.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
