Re: [perl #24267] Inconsistent behaviour of logical or op
Simon Glover <[EMAIL PROTECTED]> wrote: > I don't think your fix is correct, since: Yep, you are right, sorry. > Having done some more nosing around, I see that PerlString doesn't > actually have its own implementation of logical_or; instead, it falls > back on the scalar.pmc version, which does: So does now PerlInt. The implementation in scalar.pmc is good enough. > Simon Thanks, leo
Re: A less controvertial API addition
Dan Sugalski <[EMAIL PROTECTED]> wrote: > We probably need two API entries. One, a vararg version, that just takes a > bunch of PMC pointers (or some sort of (ick) parameter signature), and a > second that assumes you've set the registers up properly already. Done both now. The (ick) signature variant is Parrot_runops_fromc_args() needs some testing though, and some clarifaction WRT return conventions. It could also preserve registers if a flag is given or setup an exception handler, but its for sure somewhat slower then the direct calls in delegate.pmc. > Dan leo
[PS] obsolete files
Here is a list of files that I consider to be unused: * ops2cgc.pl unused, functionality is in ops2c.pl * make.pl unused?, seems outdated * classes/csub.pmc AFAIK unused, we have NCI, method_util is outdated * classes/pointer.pmc used AFAIK only by rx.ops - should be a ManagedStruct If no one hollers, I'll remove these and change rx.ops to use a ManagedStruct PMC. leo
Re: cvs commit: parrot/classes delegate.pmc
Dan Sugalski <[EMAIL PROTECTED]> wrote: > 1.1 parrot/classes/delegate.pmc > /* These need to be elsewhere */ > #define PARROT_VTABLE_INIT_METHNAME "__init" Done. These defines are now autogenerated by Vtable.pm and live in vtable.h. Hope that's ok. A PASM include vtable_methods.pasm is generated too. leo
Re: Halloween release
On Wed, 22 Oct 2003, Melvin Smith wrote: > I propose a Halloween release. Nothing fancy, just something fun. :) > We should be able to reach some sort of minor milestone to > justify it I'm sure. Oct 31, the screaming pumkin release? :) Sounds good -- lets see where we stand on Monday and go from there. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cvs commit: parrot/classes delegate.pmc
On Thu, 23 Oct 2003, Leopold Toetsch wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > 1.1 parrot/classes/delegate.pmc > > > /* These need to be elsewhere */ > > #define PARROT_VTABLE_INIT_METHNAME "__init" > > Done. These defines are now autogenerated by Vtable.pm and live in > vtable.h. Hope that's ok. A PASM include vtable_methods.pasm is > generated too. That's the right place for them--thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [COMMIT] imcc moves out of languages
Shouldn't imcc/docs (eventually) be docs/imcc, and imcc/t be t/imcc? Mike On Thursday, Oct 23, 2003, at 04:29 Europe/Berlin, Melvin Smith wrote: IMCC has graduated from the parrot/languages/imcc directory to parrot/imcc. Please update your trees. We may still want to move the main up to the parrot directory and possibly do an include/imcc directory, but I'm not sure. Test builds on my machine, so I think everything is back to intact for now. -Melvin
Re: [COMMIT] imcc moves out of languages
On Thu, 23 Oct 2003, Michael Scott wrote: > Shouldn't imcc/docs (eventually) be docs/imcc, and imcc/t be t/imcc? Yeah, but lets deal with the initial aftermat first... > On Thursday, Oct 23, 2003, at 04:29 Europe/Berlin, Melvin Smith wrote: > > > IMCC has graduated from the parrot/languages/imcc directory to > > parrot/imcc. > > Please update your trees. > > > > We may still want to move the main up to the parrot directory and > > possibly do an include/imcc directory, but I'm not sure. > > > > Test builds on my machine, so I think everything is back to intact for > > now. > > > > -Melvin > > > > > Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [COMMIT] imcc moves out of languages
Almost forgot: imcc/examples to be (eventually) examples/imcc. Mike
Re: [COMMIT] imcc moves out of languages
At 08:41 AM 10/23/2003 +0200, Leopold Toetsch wrote: Robert Spier <[EMAIL PROTECTED]> wrote: [ quoting reordered ] > Melvin Smith wrote: >> >> IMCC has graduated from the parrot/languages/imcc directory to parrot/imcc. Arghh[1] Ok guys, let us not make mountains out of molehills. > So much for preserving repository history. Yep. Is the history gone, or are you able to do something for it? Does it really matter at 0.0.11 ?? [1] There was a lot of discussion on the list, how and why we will move files around. Melvin, please (re)read p6i or perl.perl6.internals Leo, there is always a lot of discussion, and my apologies for not reading every last line, I do my best between jobs. We have a snapshot from last night before my change. If it means that much, hopefully Robert can work some magic, or move it back where it was and I'll happily clean up the mess. -Melvin
Re: Almost, but not quite, there
On Thu, 23 Oct 2003, Dan Sugalski wrote:
> At 4:43 PM -0400 10/23/03, Dan Sugalski wrote:
> >And I could certainly do with some help at this point.
> >
> >Parrot is *almost* put back together. There's some weird linking problem
> >that's keeping parrot from working out as it should, and I've not been
> >able to track it down. If anyone feels like syncing up and giving it a
> >shot, I'd not mind it at all.
>
> And now we're fine, and even test good with the JIT. Woohoo!
>
> Time to thump it some and see what I missed.
Well, I've just stumbled across one problem: if you run Configure
with --ask, then it won't accept its own default list of ops files.
The problem is this bit of config/inter/ops.pl:
{
$ops=prompt('Which opcode files would you like?', $ops);
if($ops !~ m{^\s*core\.ops}) {
print "core.ops must be the first selection.\n";
redo;
}
}
}
Configure lists ops/core.ops as the first in the list of default ops
files, but this doesn't match the regex. The patch below fixes this
on Unix, but probably isn't portable to Win32; I imagine there's a
better way to fix it.
Simon
Index: config/inter/ops.pl
===
RCS file: /cvs/public/parrot/config/inter/ops.pl,v
retrieving revision 1.2
diff -u -r1.2 ops.pl
--- config/inter/ops.pl 23 Oct 2003 19:21:30 - 1.2
+++ config/inter/ops.pl 23 Oct 2003 22:19:39 -
@@ -34,7 +34,7 @@
{
$ops=prompt('Which opcode files would you like?', $ops);
- if($ops !~ m{^\s*core\.ops}) {
+ if($ops !~ m{^ops/\s*core\.ops}) {
print "core.ops must be the first selection.\n";
redo;
}
Re: [PS] obsolete files
On Thu, 23 Oct 2003, Leopold Toetsch wrote: > Here is a list of files that I consider to be unused: > * ops2cgc.pl >unused, functionality is in ops2c.pl > * make.pl >unused?, seems outdated > * classes/csub.pmc >AFAIK unused, we have NCI, method_util is outdated > * classes/pointer.pmc >used AFAIK only by rx.ops - should be a ManagedStruct > > If no one hollers, I'll remove these and change rx.ops to use a > ManagedStruct PMC. Can I also suggest: optimizer.pl lib/Parrot/Optimizer.pm They haven't been touched for 20 months / 16 months respectively, I don't know of anybody using them, and I think that IMCC makes them obsolete. Simon
Re: [PS] obsolete files
Simon Glover wrote: On Thu, 23 Oct 2003, Leopold Toetsch wrote: Here is a list of files that I consider to be unused: Can I also suggest: optimizer.pl lib/Parrot/Optimizer.pm They haven't been touched for 20 months / 16 months respectively, I don't know of anybody using them, and I think that IMCC makes them obsolete. Yep, that's right. BTW, what about the perl PackFile stuff, unused and outdated too? Simon Thanks, leo
More file moves
Robert (the great god of CVS) is going to do the final set of big moves later on. Or possibly already has, depending on when you get this. This may, probably will, break things for a while. The scoop is: *.ops and ops.num are in the ops directory, where all ops should go from now on. *.c is in the base directory All the .pl files except for Configure.pl are in the build_tools directory When this is done I'll fix up the MANIFEST and makefile programs to make this all work properly. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PS] obsolete files
docs/parrot_assembly.pod is just an earlier version of PDD 6. On Thursday, Oct 23, 2003, at 18:34 Europe/Berlin, Leopold Toetsch wrote: Simon Glover wrote: On Thu, 23 Oct 2003, Leopold Toetsch wrote: Here is a list of files that I consider to be unused: Can I also suggest: optimizer.pl lib/Parrot/Optimizer.pm They haven't been touched for 20 months / 16 months respectively, I don't know of anybody using them, and I think that IMCC makes them obsolete. Yep, that's right. BTW, what about the perl PackFile stuff, unused and outdated too? Simon Thanks, leo
Re: [COMMIT] imcc moves out of languages
> > So much for preserving repository history. > Yep. Is the history gone, or are you able to do something for it? I've reattached the history to the files. All should be well. Depending on when you last updated, you _may_ see weird warnings on your next update -- they should be harmless. -R
Re: More file moves
> Robert (the great god of CVS) is going to do the final set of big moves > later on. Or possibly already has, depending on when you get this. This > may, probably will, break things for a while. The scoop is: I have done this, and there is blood all over the walls. > When this is done I'll fix up the MANIFEST and makefile programs to make > this all work properly. Dan is off to clean this up now. I hope he's got lots of bleach and rubber gloves. (I recommend not doing a CVS update until Dan says he's reattached the head.) -R
Re: [COMMIT] imcc moves out of languages
Robert Spier <[EMAIL PROTECTED]> wrote: >> > So much for preserving repository history. >> Yep. Is the history gone, or are you able to do something for it? > I've reattached the history to the files. All should be well. Thanks again for keeping the machinery running, leo
Re: More file moves
On Thu, 23 Oct 2003, Dan Sugalski wrote: > *.ops and ops.num are in the ops directory, where all ops should go from > now on. > > *.c is in the base directory Um, it actually appears to be in the src directory; the base directory is empty. Was this an intentional change of plan? Simon
Re: More file moves
On Thu, 23 Oct 2003, Simon Glover wrote: > > On Thu, 23 Oct 2003, Dan Sugalski wrote: > > > *.ops and ops.num are in the ops directory, where all ops should go from > > now on. > > > > *.c is in the base directory > > Um, it actually appears to be in the src directory; the base directory > is empty. Was this an intentional change of plan? Yes. Plans changed between mail and implementation, courtesy of IRC chats. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [COMMIT] imcc moves out of languages
Thanks Robert for the fixup. Nothing like throwing a grenade to get people scrambling. -Melvin -Original Message- From: Robert Spier <[EMAIL PROTECTED]> Sent: Oct 23, 2003 1:33 PM To: [EMAIL PROTECTED] Subject: Re: [COMMIT] imcc moves out of languages > > So much for preserving repository history. > Yep. Is the history gone, or are you able to do something for it? I've reattached the history to the files. All should be well. Depending on when you last updated, you _may_ see weird warnings on your next update -- they should be harmless. -R
Almost, but not quite, there
And I could certainly do with some help at this point. Parrot is *almost* put back together. There's some weird linking problem that's keeping parrot from working out as it should, and I've not been able to track it down. If anyone feels like syncing up and giving it a shot, I'd not mind it at all. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PS] obsolete files
Leopold Toetsch wrote: Here is a list of files that I consider to be unused: Hmmm... obsolete... unused... sounds a lot like languages/perl6 :-P - Joe
Re: Almost, but not quite, there
At 4:43 PM -0400 10/23/03, Dan Sugalski wrote: And I could certainly do with some help at this point. Parrot is *almost* put back together. There's some weird linking problem that's keeping parrot from working out as it should, and I've not been able to track it down. If anyone feels like syncing up and giving it a shot, I'd not mind it at all. And now we're fine, and even test good with the JIT. Woohoo! Time to thump it some and see what I missed. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
IMCC, classes & metadata
I'm working on getting class syntax added to PIR. It appears IMCC's way of emitting instructions as it collects compilation was a mistake (mine) and isn't going to work for metadata that needs to be initialized first. Basically all metadata has to be collected before any code can be emitted. I was thinking of generating an _init routine that creates the classes, so we have several possibilities. Short term: Require all class definitions and other metadata to be declared first in the PIR stream. Upon first non-metadata object (sub, pccsub) we flush the _init sub. Long term: We should parse the whole PIR file before doing any sort of code emission. This means collecting all the compilation units, running the allocator and optimizer on each and then emit all metadata first before emitting the rest of the units. This allows metadata to be throughout the PIR stream. This isn't really so big a deal since high level languages should be able to emit PIR code with all metadata first anyway. Comments? -Melvin
Re: IMCC, classes & metadata
Melvin Smith <[EMAIL PROTECTED]> wrote: > Basically all metadata has to be collected before any code can be emitted. > I was thinking of generating an _init routine that creates the classes, > so we have several possibilities. Why? A class definition should AFAIK end up in the constant table as a class PMC specifying the inheritance and attributes. So a .class directive is from parsing POV a constant definition, like a string constant. > Long term: We should parse the whole PIR file before doing any sort of >code emission. That's true. pbc.c already has most of the necessary structures. These should of course be rearanged, kept inside IMCC_INFO() and so on. But basically it shouldn't be too hard. We have to rearange all imcc globals anyway - there can't be globals or multi-threading will break horribly. > This isn't really so big a deal since high level languages should be able to > emit PIR code with all metadata first anyway. That's not necessary AFAIK. > -Melvin leo
PATCH: (unofficial) Make Devel::Cover use Storable
On 10/22/2003 4:01 AM, Tim Bunce wrote:
> On Tue, Oct 21, 2003 at 03:01:20PM -0700, Ovid wrote:
>> Tim Bunce <[EMAIL PROTECTED]> wrote:
>>>
>>> I'd strongly recommend switching to Storable first. It did have problems
>>> but it's now very robust and far, far, faster than Data::Dumper+eval.
>>> This small change would yield a big gain.
>>
>> the data structure for the coverage [...] is so huge that I run out of
>> memory (and this is on a machine with a couple of gigs of RAM).
>
> Reading and writing Data::Dumper format is much more memory hungry than
> Storable. Switch to Storable will at least ease the problem.
>
> I don't have time in the short term to work on the (albeit fairly trivial)
> change to Storable. If someone can do that and get a new release out then
> I'll look deeper into the performance issues then.
I tried it, and it does help some. In my very unscientific test[1] it ran about
20% faster. The size of the db file (on disk) was about 75% smaller. I don't
have numbers on RAM usage, but I didn't touch the internal representation so
about all that's saved is the eval overhead.
I've included a patch for Devel/Cover/DB.pm in case someone else wants to try
it. It has *not* been sanctioned by Paul (though he's welcome to it) so use at
your own risk. Obviously, the file format for the database is incompatible with
the current version.
[1] roughly 430 tests in 18 *.t files. Timing done with a wristwatch on a
single-user WinXP system.
-mjc
*** DB.pm.old Thu Oct 23 14:58:02 2003
--- DB.pm.new Thu Oct 23 15:00:01 2003
***
*** 18,25
use Carp;
use Data::Dumper;
use File::Path;
! my $DB = "cover.4"; # Version 4 of the database.
sub new
{
--- 18,26
use Carp;
use Data::Dumper;
use File::Path;
+ use Storable;
! my $DB = "cover.5"; # Version 5 of the database.
sub new
{
***
*** 49,65
$self->validate_db;
$file = "$self->{db}/$DB";
return $self unless -e $file;
! open F, "<$file" or croak "Unable to open $file: $!";
! $self->{filehandle} = *F{IO};
}
- $self->read if defined $self->{filehandle};
-
- if (defined $file)
- {
- close F or croak "Unable to close $file: $!";
- }
-
croak "No input db, filehandle or cover" unless defined $self->{cover};
$self
--- 50,58
$self->validate_db;
$file = "$self->{db}/$DB";
return $self unless -e $file;
! $self->read($file);
}
croak "No input db, filehandle or cover" unless defined $self->{cover};
$self
***
*** 70,111
sub all_criteria { @{$_[0]->{all_criteria }} }
sub all_criteria_short { @{$_[0]->{all_criteria_short}} }
! sub read
! {
my $self = shift;
! local $/;
! my $db;
! my $fh = $self->{filehandle};
! eval <$fh>;
! croak $@ if $@;
$self->{cover} = $db->{cover};
$self->{collected} = $db->{collected};
$self->{indent}= $db->{indent};
! $self
}
! sub write
! {
my $self = shift;
$self->{db} = shift if @_;
croak "No db specified" unless length $self->{db};
$self->validate_db;
! my $db =
! {
cover => $self->{cover},
collected => $self->{collected},
indent=> $self->{indent},
};
! local $Data::Dumper::Indent = $self->indent;
! local $Data::Dumper::Sortkeys = 1;
! local $Data::Dumper::Useperl = 1; # TODO - remove this when possible
! my $file = "$self->{db}/$DB";
! open OUT, ">$file" or croak "Cannot open $file\n";
! print OUT Data::Dumper->Dump([$db], ["db"]);
! close OUT or croak "Cannot close $file\n";
! $self
}
sub delete
{
my $self = shift;
--- 63,96
sub all_criteria { @{$_[0]->{all_criteria }} }
sub all_criteria_short { @{$_[0]->{all_criteria_short}} }
! sub read {
my $self = shift;
! my $file = shift;
! my $db = retrieve($file);
!
$self->{cover} = $db->{cover};
$self->{collected} = $db->{collected};
$self->{indent}= $db->{indent};
! return $self;
}
! sub write {
my $self = shift;
$self->{db} = shift if @_;
croak "No db specified" unless length $self->{db};
$self->validate_db;
!
! my $db = {
cover => $self->{cover},
collected => $self->{collected},
indent=> $self->{indent},
};
!
! Storable::nstore $db, "$self->{db}/$DB";
! return $self;
}
+
sub delete
{
my $self = shift;
Alternately named arguments
Presuming you can do:
(who => $name, why => $reason) := (why => $because, who => "me");
(from A6)
Does that imply that you can do:
sub routine (name => $nombre, date => $fecha) {...}
Anyway, I just realized that this is finally an elegant way to do
multiple, unordered return values:
(name => $name, id => $id) := getinfo();
(Or, in this precise case:)
(+$name, +$id) := getinfo();
Luke
