[CVS ci] misc cleanup
I have checked in various changes, cleanups, enhancements: - classes/default.pmc: 2 step hash creation for properties - classes/pmc2c.pl: --tree options prints classes hierarchy, missing constand_FLAG for classnames - list.h/list.c: move flags out of buffer header - remove uninitialized warning for -O3 - key.c: use flag accessor macros - tools/dev/rebuild_miniparrot.pl: when perl6 was built with -Duselongdouble, miniparrot also uses long double, which probably shouldn't be leo
Re: Thoughts on infant mortality...
Dan Sugalski wrote: At 4:17 PM + 1/9/03, Nicholas Clark wrote: On Thu, Jan 09, 2003 at 01:32:57PM +0100, Leopold Toetsch wrote: But I still favor the combination of: - code reordering, like done for pmc_new - DOD/GC disabling (e.g. aggregate clone) - active anchoring to the root set, where above is not applicable Which combined means that there is no stackwalking? While I'd like no stack walking, as it's pricey, I'm not sure it's tenable. As the current clone changes does show, it's possible. BTW current tests do succed w/o stackwalking - its disabled. ... Skipping it makes things rather more fragile, as it means that any code that may potentially trigger a DOD run while holding an unrooted object needs to root it temporarily, and that's a lot of code. Its a bit more fragile, for unchecked or new code. PMCs ought to be already save now. The "new" and "clone" ops do already anchor the newly created object to the root set. Also I was thinking of: trace_system_areas could be run last in marking and if it finds some unanchored objects, it could print a warning, so we could really check, if we ware safe. leo
Re: [perl #19870] Compile failure in jit_cpu.c
On Thu, Jan 09, 2003 at 04:29:19PM +, Matthew Zimmerman wrote: > # New Ticket Created by Matthew Zimmerman > # Please include the string: [perl #19870] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=19870 > > > > A CVS update from about 30 minutes ago is failing to compile > on my Red Hat Linux 7.2/i386 system, with this error: Okay, this is my stupid. This was done in a *copy* of my CVS sandbox, not the original, and I guess I must have had not copied everything or had some stale files lying about or something. Please ignore. -- Matt Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/ Lab: 4-223 Jordan Hall, 1300 Jefferson Park Avenue, Charlottesville, VA 22908 (434)924-2948 Home: 2655-C Barracks Road Charlottesville, VA 22901 (434)244-7989
Re: Objects, finally (try 1)
On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: > #10 We do MI, but we don't instantiate a class' attributes multiple > times if its in the hierarchy for a class more than once. If it is, the > leftmost instance is real, the rest are virtual This will mean we can't support Eiffel, which allows repeated real inheritance of the same class. It does this by allowing renaming at the feature level (thats attributes and methods in perl) when inheritance is declared. Repeated inherited features are shared if they keep the same name (and they really are the same feature), or split if they don't. -- Peter Haworth [EMAIL PROTECTED] Warning! Your Operating System is out of date! It can be replaced by a more memory abusive Operating System. Please contact your System Vendor for details.
cvs server full?
$ ./getparrot can't create temporary directory /tmp/cvs-serv3864 No space left on device
Re: Thoughts on infant mortality...
On Jan-10, Leopold Toetsch wrote: > Also I was thinking of: trace_system_areas could be run last in marking > and if it finds some unanchored objects, it could print a warning, so we > could really check, if we ware safe. That's what defining GC_VERBOSE in parrot.h will give you right now, and it's usually too noisy to be useful. For some reason, it seems to be very common to have old PMC pointers lying around on the stack. (Which is a further argument against it, I guess -- the stackwalk may hang onto significant chunks of memory and cause later allocations to fail unnecessarily. That's true of most of the suggested schemes to some degree, but GC_VERBOSE gives an estimate of how bad it is for stackwalking. A poor estimate, though, since most of the stale pointers it finds are probably not holding onto much memory, but it can only get worse.) I am committing the summary I wrote into parrot/docs/dev/infant.dev, since I see that as the original idea behind the .dev files -- to record the justifications for design decisions along with the other variants, so people don't need to recreate them quite as often. On the other hand, the other part of the impetus for *.dev files was to pair them up with actual source files, but so far that doesn't appear popular enough to actually happen. (I have mixed feelings tending toward the negative about that idea anyway.) The summary should really be updated to reflect some of the further discussions we've had. I ought to add at least a section on hybrid schemes (eg anchor what you can, have a temporary root for the rest), interaction with the (weakened) finalization guarantees needed for Perl6, and the schemes for allowing some of the listed approaches to work in the presence of longjmp() and recursive calls. But I don't have the time at the moment. Anyone else is more than free to update it once it's checked in. [And it isn't yet -- looks like /tmp is full on the cvs server at the moment.]
Re: "Disappearing" code
On Thu, Jan 09, 2003 at 07:55:20PM -0500, John Siracusa wrote:
> Has there been any discussion of how to create code in Perl 6 that's there
> under some conditions, but not there under others? I'm thinking of the
> spiritual equivalent of #ifdef, only Perlish.
>
> In Perl 5, there were many attempts to use such a feature for debugging and
> assertions. What everyone wanted to do was write code like this:
>
> debug("Doing foo with $bar and $baz");
> foo($bar, $baz);
I would assume it to be a compiler hint via subroutine attribute.
sub debug ($msg) is off {
print STDERR $msg;
}
some "this subroutine is a no-op if a flag is set" attribute.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: "Disappearing" code
On Thu, Jan 09, 2003 at 11:15:49PM -0500, John Siracusa wrote:
> On 1/9/03 10:10 PM, Michael G Schwern wrote:
> > I would assume it to be a compiler hint via subroutine attribute.
> >
> > sub debug ($msg) is off {
> > print STDERR $msg;
> > }
> >
> > some "this subroutine is a no-op if a flag is set" attribute.
>
> Hm, not quite as convenient as setting a package global (constant)
> somewhere. Maybe that same "off" bit could be set "from a distance" at
> compile time?
That would be the "if a flag is set" part. Point is, its easily handled
by some sort of subroutine attribute which looks at some flag somewhere.
'off' was a bad name for it.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: L2R/R2L syntax (was Re: Everything is an object.)
> print sort { ... } <~ mymethod(42) <~ @b;
>
> call sort on what comezouta calling mymethod(42) on what comezouta @b.
> I think. Indirect objects are still somewhat confusing. :)
>
> If I'm reading the info right on <~, then we want to make it clear
> that you _don't_ put it between print and stuff you want to print, or
> in other words that "this ain't cout".
If I read the conversations right, I think that line is trying to do:
print (to stream mymethod(@b,42)) sort { ... }
I think to make it work like you wanted, you need ()'s
print (sort { ... } <~ mymethod(42) <~ @b); so that the <~ is directly
associated with the sort; otherwise sort is a param to the print, and
we're comezouta'ing the "where do i print sort"
and sort takes the "how do i sort" first and the "What do i sort"
second, yes? which makes me now wonder about all the sort { ... } <~
examples, and my understanding of the whole "where do <~ and ~> stick
things?" thing ...
OK, looking back, <~ binds to the "indirect object" ... and Damian's
examples use map { ... } and grep { ... } with <~'s, so I guess the
indirect object would work the same for sort { ... }, but now I'm not real
sure on what the indirect object IS in all these calls ...
Could someone explain how to know what's the indirect object? (who knew
the "sentence diagramming" would be USEFUL!!)
--attriel
Re: "Disappearing" code
On 1/9/03 11:27 PM, Michael G Schwern wrote:
> On Thu, Jan 09, 2003 at 11:15:49PM -0500, John Siracusa wrote:
>> On 1/9/03 10:10 PM, Michael G Schwern wrote:
>>> I would assume it to be a compiler hint via subroutine attribute.
>>>
>>> sub debug ($msg) is off {
>>> print STDERR $msg;
>>> }
>>>
>>> some "this subroutine is a no-op if a flag is set" attribute.
>>
>> Hm, not quite as convenient as setting a package global (constant)
>> somewhere. Maybe that same "off" bit could be set "from a distance" at
>> compile time?
>
> That would be the "if a flag is set" part. Point is, its easily handled
> by some sort of subroutine attribute which looks at some flag somewhere.
Well, er, don't we need to decide what the subroutine attribute is, so that
the compiler will know to honor it and make the code "disappear"? It
doesn't seem like a feature that can be added from "userland" after the fact
(but maybe I'm wrong...)
-John
Re: "Disappearing" code
John Siracusa <[EMAIL PROTECTED]> wrote: > > Well, er, don't we need to decide what the subroutine attribute is, so that > the compiler will know to honor it and make the code "disappear"? It > doesn't seem like a feature that can be added from "userland" after the fact > (but maybe I'm wrong...) In Perl 5 that could be done from userland, as you say, by using an optree manipulator (optimizer.pm for example). This could even be lexically scoped. [Once the compiler hints are fixed.] I expect Perl 6 to ship with (Parrot::* ?) modules that allow to examine and to modify the compiled form of the programs. Something that probably Java 6 will not have...
Re: Variable Types Vs Value Types
attriel wrote: AssignmentOK?Because... ======== my Basket $c = $a no $c's type: Basket (of Object) X ^ | | $a's type: Set of Apple my Basket of Apple $c = $aok $c's type: Basket of Apple ^ ^ | | $a's type: Basket of Apple Now, just to be sure I didn't miss a step: That second entry is wrong, sin't it? it should be OK? no b/c: C's Type : Basket of Apple X^ || A's Type : Set of Apple yes? Quite correct. I messed up A's type. :-( Could the Secret Maintainers of Perl 6 Truth please update that for the records. Thanks, Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Andy Wardley wrote: s/~=/=~/ Indeed. And that's precisely why we're changing it to ~~ in Perl 6. ;-) The first 3 all relate to the familiar concept of 'minus', or more precisely a delta between two values. The last uses '-' as 'dash', another familiar concept which doesn't grate against the first usage, IMHO. Just as ~> and <~ use ~ as a "squiggly dash", which doesn't grate either, IMHO. The arrow is a special case. I don't read that first character as '-', I think of the operator as one. I guess the visual cue forces me to see it like that. I'm suggesting that ~> and <~ will be the same. I'm just suggesting the same for the ~ character: This is where I get lost. I see 4 different concepts being overloaded onto '~'. I'd suggest that that's simply because your brain hasn't yet "chunked" the various uses of the ~ character in these four multicharacter symbols, the way it already has with the - character. So you read the ~'s as symbols rather than characters within symbols, which leads to the "matchy" or "stringy" overtones of their appearance to you. But once that chunking does occur for you -- and I'm suggesting it would -- then ~> and <~ will become atomic symbols in your brain, and I think the issue will disappear. Nevertheless, I deeply respect your concerns and your opinions, and appreciate that you look the time to set them out so clearly. So, we're going to have to agree to differ, I suspect. Having presented our respective arguments cogently in this forum, we can happily sit back and let Larry shoulder the burden of deciding this. Thanks, Andy. Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody wrote: I find the normal function call and assignment far more readable than using some weird ugly operator. and later: That's going to be just plain confusing. Arguments to functions are supposed to be on the right. And what's up with using them for assignment? That's making them even more overcomplicated and ugly. Do you care about readability at all? You know, I usually find this kind of unsupported, emotive, ad hominen attack utterly unconvincing. But in this case, I find that your novel approach to our collaborative discussion *has* convinced me of something. *PLONK* Damian
Re: Variable Types Vs Value Types
Damian Conway <[EMAIL PROTECTED]> writes: > attriel wrote: > >> AssignmentOK?Because... >> ======== >> my Basket $c = $a no $c's type: Basket (of Object) >>X ^ >>| | >> $a's type: Set of Apple >> my Basket of Apple $c = $aok $c's type: Basket of Apple >>^ ^ >>| | >> $a's type: Basket of Apple >> Now, just to be sure I didn't miss a step: >> That second entry is wrong, sin't it? it should be OK? no b/c: >> C's Type : Basket of Apple >> X^ >> || >> A's Type : Set of Apple >> yes? > > Quite correct. I messed up A's type. :-( > Could the Secret Maintainers of Perl 6 Truth please update that for > the records. If you want me to doctor the summary you're going to have to do better than a simple 'please' mate. I want personal tuition on making presentation software actually *enhance* the presentation...
Re: DOD patches and some remarks
On Jan-09, Leopold Toetsch wrote: > I have here now ~15 files different to CVS, which I would like to sync > in either direction for easier future changes. > So the question is, should I checked it in / partially / forget it. > > Changes are: > - SPMC (small or scalar PMC) with half the size of a PMC, no promotion > or whatever to a PMC, disabled with one define in pmc.c > - pool flags with aligned pools, disabled in pobj.h > - key.c and list.c flags cleanup > - mark constant PMCs in DOD[1], hash undef PMC changes > - minor cleanups > > The first two are pretty much encapsulated and disabled by default. They > can be easily removed at any time. SPMCs could get really functional > after vtable var/value changes. My personal opinion, worth the paper it's printed on: all of those sound very good except for the first, which makes me nervous. It adds a lot of complexity if those PMCs ever need to be promoted, and I'm not clear on the advantages. The space advantage is obvious, but I would guess not all that large. I don't understand the cache advantage -- is it perhaps doubling the usable size of the cache because the larger PMCs are all aligned similarly, and so half the cache is never used? If so, would staggering the alignment of the PMCs be enough to get the same gain (possibly with reordering the fields)? For example, make every other PMC allocated fall on a different alignment. I haven't been paying much attention recently, so I'm probably just being naive and dumb, but my intuition is concerned about adding this complexity when we're not totally confident of what's going on. Have you tried running cachegrind or something similar on the two versions?
Re: cvs server full?
Leopold Toetsch wrote: > $ ./getparrot > can't create temporary directory /tmp/cvs-serv3864 > No space left on device Oops. Fixed. -R
Re: Objects, finally (try 1)
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: >> #10 We do MI, but we don't instantiate a class' attributes multiple >> times if its in the hierarchy for a class more than once. If it is, >> the leftmost instance is real, the rest are virtual My only question here is: What is leftmost? Is that the same as "closest to the actual class we're looking at" or is it "first time it appears in the inheritance structure, and thus the furthest from the relevant class" ? (or something else entirely?) > This will mean we can't support Eiffel, which allows repeated real > inheritance of the same class. It does this by allowing renaming at the > feature level (thats attributes and methods in perl) when inheritance is > declared. Repeated inherited features are shared if they keep the same > name (and they really are the same feature), or split if they don't. I'll admit to never having gotten to looking at eiffel, just hearing about it from some other folks ... But what is the point of explicitly inheriting from the same class multiple times? I mean, sure, if it's in the inheritance tree multiple times, fine, but then you ignore most of them generally; what benefit/use comes from having it actually be in the tree multiple times as distinct entities? I'm just wondering there ... But if it's renaming the structure anyway, wouldn't it still be possible with the single-MI structure that dan proposed? as in, if B inherits from A and then C inherits from A and B directly (and assuming there's a need to separately retain the individual inheritance directions), wouldn't the compiler then say that B inherits from A and C inherits from A2 and B, to retain them both in the parrot? --attriel (I could, of course, be horribly wrong, had I stated a firm opinion rather than requests for more information :)
Re: Objects, finally (try 1)
At 1:37 PM + 1/10/03, Peter Haworth wrote: On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: #10 We do MI, but we don't instantiate a class' attributes multiple times if its in the hierarchy for a class more than once. If it is, the leftmost instance is real, the rest are virtual This will mean we can't support Eiffel Nope. :) What it means is that the proposed base object system won't work for eiffel. There are very few proposed core changes to support this object system, and if you think about it the expressed program-level semantics are sufficient for eiffel (I think), it's just the behind-the-curtain bits that aren't. And there's nothing to say that a theoretical eiffel implementation couldn't just have a different Attr-style object. (Eiffel's classes, IIRC, are compile-time fixed so it can do the necessary code cloning and renaming magic to make it all work. I suppose we could too, but it's a lot more work to do it since things can change at runtime in perl/python/ruby classes) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 10:37 AM -0500 1/10/03, attriel wrote: > On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: #10 We do MI, but we don't instantiate a class' attributes multiple times if its in the hierarchy for a class more than once. If it is, the leftmost instance is real, the rest are virtual My only question here is: What is leftmost? Is that the same as "closest to the actual class we're looking at" or is it "first time it appears in the inheritance structure, and thus the furthest from the relevant class" ? (or something else entirely?) For attributes it doesn't matter. For methods, well, I'm not sure whether a leftmost depth-first insertion is right or inserting it somewhere else is better. I expect Damian Has The Answer. (Or, if I remember from the last time I asked, several answers of which there wasn't a clear Best Answer) > This will mean we can't support Eiffel, which allows repeated real inheritance of the same class. It does this by allowing renaming at the feature level (thats attributes and methods in perl) when inheritance is declared. Repeated inherited features are shared if they keep the same name (and they really are the same feature), or split if they don't. I'll admit to never having gotten to looking at eiffel, just hearing about it from some other folks ... But what is the point of explicitly inheriting from the same class multiple times? I mean, sure, if it's in the inheritance tree multiple times, fine, but then you ignore most of them generally; what benefit/use comes from having it actually be in the tree multiple times as distinct entities? If you do redispatching of method calls it makes sense, since if there are enough redispatches you may end up redispatching to one class' method more than once because it's in the tree more than once, in which case you'd want to get the correct set of attributes, as each instance of the class in the tree should have a separate set of attributes in that case. (I could, of course, be horribly wrong, had I stated a firm opinion rather than requests for more information :) Ah, go for the bold statement. People are more likely to refute an error that way. :) Also, as I pointed out a little while ago, this is the proposal for the base perl6/ruby/python object scheme, but there's nothing that forbids transparent interoperability with a different object scheme. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[CVS ci] clone, dod stack reporting
I did check in the clone changes. - the clone vtable method get's now a dest ptr of an already created PMC - so the newly created PMC is already anchored, which makes it possible to change clone() code, so that no unanchored objects hang around, which still is a TODO for more complex objects - docs adjusted Further remark: the scratchpad clone code looks dubious, the 2 lists in the data (lex) entry should probably cloned too - and at least the lex ptrs themselves. The destroy method leaks, because we can't cleanup duplicated lex ptrs. Can somone better knowing scratchpads comment on this please. Also in, as discussed with Steve, is the possiblity of reporting unanchored (or bogus) objects after marking all PMC/Buffers. leo
Re: DOD patches and some remarks
Steve Fink wrote: On Jan-09, Leopold Toetsch wrote: So the question is, should I checked it in / partially / forget it. Changes are: - SPMC (small or scalar PMC) with half the size of a PMC, no promotion or whatever to a PMC, disabled with one define in pmc.c - pool flags with aligned pools, disabled in pobj.h - key.c and list.c flags cleanup - mark constant PMCs in DOD[1], hash undef PMC changes - minor cleanups My personal opinion, worth the paper it's printed on: all of those sound very good except for the first, which makes me nervous. key, list and some cleanup is in. ... It adds a lot of complexity if those PMCs ever need to be promoted, and I'm not clear on the advantages. The space advantage is obvious, but I would guess not all that large. Space advantage is 50% which goes almost directly with same speed advantage. Promoting wouldn't be too hard, IMHO, when vtable changes and references are in. We make the original PMC a reference to the bigger promoted type, should work as references work on behalf of the referenced object. ... I don't understand the cache advantage -- is it perhaps doubling the usable size of the cache because the larger PMCs are all aligned similarly, and so half the cache is never used? If so, would staggering the alignment of the PMCs be enough to get the same gain (possibly with reordering the fields)? You get double the amount of PMCs into the cache - used during marking and freeing. It isn't related to alignment, just more throughput. ... Have you tried running cachegrind or something similar on the two versions? No, only stress*.pasm. But: $ time parrot -j stress.pbc A total of 9 DOD runs were made real0m0.708s But this still could go faster: $ parrot -j stress.pbc # w/o pmc->synchronize (-10% size) A total of 9 DOD runs were made real0m0.635s $ time parrot -j stress.pbc # half sized (16 byte PMC) $ make -s && time parrot -j stress.pbc A total of 13 DOD runs were made real0m0.378s leo
Re: Thoughts on infant mortality...
Steve Fink wrote: On Jan-10, Leopold Toetsch wrote: Also I was thinking of: trace_system_areas could be run last in marking and if it finds some unanchored objects, it could print a warning, so we could really check, if we ware safe. That's what defining GC_VERBOSE in parrot.h will give you right now, Gave, until pobject_lives() changes ;-) But I did reintroduce this with above idea. And a local GC_VERBOSE for easier switching. and it's usually too noisy to be useful. For some reason, it seems to be very common to have old PMC pointers lying around on the stack. Yep. Seems so. I'll continue my early anchoring patches, we will see. (Which is a further argument against it, I guess -- the stackwalk may hang onto significant chunks of memory and cause later allocations to fail unnecessarily. That's true of most of the suggested schemes to some degree, but GC_VERBOSE gives an estimate of how bad it is for stackwalking. A poor estimate, though, since most of the stale pointers it finds are probably not holding onto much memory, but it can only get worse.) And it's getting worse with register walking on RISC machines. I am committing the summary I wrote into parrot/docs/dev/infant.dev, Greate, thanks. On the other hand, the other part of the impetus for *.dev files was to pair them up with actual source files, I'd rather have this kind of docu in the source file. leo
Re: Objects, finally (try 1)
Dan Sugalski wrote: > and who's got > questions on how this works? (I can put together examples, but this > is pretty long as it is, and I think it's reasonably > self-explanatory. Besides, assembly language isn't generally the best > way to demonstrate anything... :) Well, as far as I'm concerned, an assembly snippet would be nice. But I can as well wait for implementation and study what will be relevant to objects in the t/ directory. Indeed, once you wrote some Parrot assembly code to support a^Htwo stupid^Wesoteric languages, Parrot assembly is quite a nice and easy way to see how theory behaves in real life... :o) Jerome -- [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- attriel <[EMAIL PROTECTED]> wrote: > Could someone explain how to know what's the indirect object? (who > knew > the "sentence diagramming" would be USEFUL!!) Short version: If there's two people in the sentence, the verb-ee is either the direct or indirect object. If there's two people and a thing, the -ee is indirect. I hit him. (He's the direct object.) I gave the ball to him. (Ind.) In reality, the reference to "indirect object" is a bogus equivalence, because we're really making the SUBJECT of the sentence, as hit him :I becomes I.hit(him) However, the original term was a reference to "Using an OBJECT's method INDIRECTly", hence indirect object notation. Just to make things less simple. =Austin
Re: "Disappearing" code
On Thu, 09 Jan 2003 19:55:20 -0500 John Siracusa <[EMAIL PROTECTED]> wrote: > Has there been any discussion of how to create code in Perl 6 that's > there under some conditions, but not there under others? I'm thinking > of the spiritual equivalent of #ifdef, only Perlish. If the perl6 command-line options are anything like perl5 then you can just use the -P switch if preprocessor commands are your thing. > In Perl 5, there were many attempts to use such a feature for > debugging and assertions. There has also been a proposal for patching perl5 to add assertions which was recently discussed[1] on p5p, which if accepted has implications for assertions in perl6 surely. Dan [1] http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-11/msg00325.html
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway said: > Andy Wardley wrote: >> The arrow is a special case. I don't read that first character >> as '-', I think of the operator as one. I guess the visual cue forces >> me to see it like that. > > I'm suggesting that ~> and <~ will be the same. I think that in part this may depend on the font being used. When I first saw these symbols, via webmail on a browser, the tilde appeared half way down the character, in the same position as the dash. This made it obvious to me that it was an arrow of some sort, and it looked good. When I later saw it using mutt in an xterm, the tilde was at the top of the character, where I was more used to seeing it and it didn't look like an arrow any more, nor did it look very good to me. This is the way it looks on my browser ~> When I get home I'll mail a message showing how it looks in my xterm ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: "Disappearing" code
On 1/10/03 11:11 AM, Dan Brook wrote: > On Thu, 09 Jan 2003 19:55:20 -0500 > John Siracusa <[EMAIL PROTECTED]> wrote: >> Has there been any discussion of how to create code in Perl 6 that's >> there under some conditions, but not there under others? I'm thinking >> of the spiritual equivalent of #ifdef, only Perlish. > > If the perl6 command-line options are anything like perl5 then you > can just use the -P switch if preprocessor commands are your thing. Source filtering is not exactly the solution I'm looking for... :) -John
Re: "Disappearing" code
John Siracusa asked:
Has there been any discussion of how to create code in Perl 6 that's there
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for debugging and
assertions. What everyone wanted to do was write code like this:
debug("Doing foo with $bar and $baz");
foo($bar, $baz);
And then have the entire call to debug() just plain disappear when the
program was run with a certain flag, or when a particular constant was set,
or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
use constant DEBUG => 0;
...
debug("Doing foo with $bar and $baz") if DEBUG;
foo($bar, $baz);
But all those "if DEBUG"s or "DEBUG &&"s were a pain. So I'm wondering what
the solution will be in Perl 6.
Something like this:
module Debug;
my $debugging = 1;
method import ($debug) { $debguuging = $debug }
sub debug is immediate is exported (@message) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
then:
use Debug;
debug("Doing foo with $bar and $baz");
and to deactivate the debug statements:
use Debug 0;
debug("Doing foo with $bar and $baz");
"Immediate" subroutines are executed as soon as they are parsed (i.e. they're
like named BEGIN blocks).
Returning a closure/block from an immediate sub called in a void context
(as C is in the example above) causes the immediate sub call to be
replaced -- during compilation! -- by the returned closure/block.
Voila! Perl 6 is its own macro language.
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Trey Harris raised the spectre of:
shades of C++, how about just
$*STDERR <~ $foo;
Yes. Assuming C were suitably overloaded.
or
$foo ~> $*STDERR;
Yes. Assuming C were suitably overloaded.
Not sure whether that would come "standard", but if not, here's
a first cut of the necessary module for future reference:
module IO::Stroustrupian;
# Output operators...
my infix::<~(IO $fh, $datum) is multi is exported { print $fh: $datum }
my infix::<~(IO $fh, @data) is multi is exported { print $fh: @data }
my infix::~>($datum, IO $fh) is multi is exported { print $fh: $datum }
my infix::~>(@data, IO $fh) is multi is exported { print $fh: @data }
# Input operators...
my infix::<~($var is rw, IO $fh) is multi is exported { $var = <$fh> }
my infix::<~(@var is rw, IO $fh) is multi is exported { @var = <$fh> }
my infix::~>(IO $fh, $var is rw) is multi is exported { $var = <$fh> }
my infix::~>(IO $fh, @var is rw) is multi is exported { @var = <$fh> }
Damian
~> and <~ become |> and <| (was L2R/R2L syntax )
Damian Conway wrote:
Can I suggest that an alternative solution might be the following:
So an L2R array-processing chain is:
@out = @a ~> grep {...} ~> map {...} ~> sort;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~> grep {...} ~> map {...} ~> sort ~> @a;
Further suppose that <~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort <~ map {...} <~ grep {...} <~ @a;
Or, under a special rule for variables on the LHS:
@out <~ sort <~ map {...} <~ grep {...} <~ @a;
That way, everything is still a method call, the ultra-low precedence of
<~ and ~> eliminate the need for parens, and (best of all) the
expressions
actually *look* like processing sequences.
Damian
my knee-jerk reaction,
|> is evocative of pipelines in bash, etc...
<| is somewhat less evocative, but related to <(cat *) as a
sub-process (in csh ??)
yours feels slightly less noisy, but also less familiar/mnemonic.
Re: "Disappearing" code
On 1/10/03 12:24 PM, Damian Conway wrote: > "Immediate" subroutines are executed as soon as they are parsed (i.e. they're > like named BEGIN blocks). > > Returning a closure/block from an immediate sub called in a void context > (as C is in the example above) causes the immediate sub call to be > replaced -- during compilation! -- by the returned closure/block. > > Voila! Perl 6 is its own macro language. Sweet :) -John
Re: Array Questions
On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
Michael Lazzaro asked:
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes.
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed
Great -- then I have only one more question, I think. In the words of
a certain cartoon character, what's *this* button do?
my $b is $a;
My presumption:
1) If C, e.g. $a is set to a class name, it's saying
that $b is implemented by a MyScalar. But I don't know if these two
lines would really have the same result, given rule (2), below:
$a = MyScalar;
$a = 'MyScalar';
2) If C, e.g. it's set to an arbitrary object
instance, it's saying that $b is implemented by the object instance in
$a. So these statements are equiv:
my $a = FileBasedHash.new($path);
my %b is $a;
vs.
my %b is FileBasedHash($path);
If the object in $a doesn't implement the Scalar interface, it's a
runtime error. And note that C would be a runtime error,
one would hope.
MikeL
(My original gut desire was that C be the ultracool perl6
way of achieving prototype-based (classless) OO, such that $b inherits
its base functionality from $a. As inherently cool as that is, I don't
think that can possibly work, and it would conflict *severely* with
these other meanings. Ah, well.)
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- attriel <[EMAIL PROTECTED]> wrote: > Ah. OK, thanks :) I had the basic idea, but I wasn't sure how to > tell in perl which parameter was the indirect object :o Right, "o" in your sentence above is the object. > if I'm following this right, it's the inferred object such that (in > p5) if I called I.hit(him) the sub would receive @_ = I, him; yes? Yep. > and thus it would be hit (him) <~ I; in the current thread? Yep. Henceforth, <~ shall be the "dragon operator", because (1) you're draggin' the object back to the method; and (2) operator:<~ looks like a chinese dragon. Likewise, ~> shall be the "grin operator", because of the smiley in "operator:~>". =Austin
Re: Array Questions
On Fri, Jan 10, 2003 at 10:28:49AM -0800, Michael Lazzaro wrote: > Great -- then I have only one more question, I think. In the words of > a certain cartoon character, what's *this* button do? > >my $b is $a; And no matter what that button does, will this: my $a $b; be illegal? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Objects, finally (try 1)
On Friday, January 10, 2003, at 11:49 AM, Dan Sugalski wrote: At 1:37 PM + 1/10/03, Peter Haworth wrote: This will mean we can't support Eiffel Nope. :) What it means is that the proposed base object system won't work for eiffel. Actually, if you really want Eiffel to compile to Parrot, it might be interesting to work on getting ANSI C to compile to Parrot first, since most Eiffel compilers use compilation to C as an intermediate step. You might lose the ability to reuse an Eiffel-created object with other languages, but if you're using Eiffel, you're probably not going to be happy with object-orientation in any language that doesn't strictly enforce DBC anyway. ;-)
RE: [CVS ci] clone, dod stack reporting
> -Original Message- > From: Leopold Toetsch [mailto:[EMAIL PROTECTED]] > > Further remark: the scratchpad clone code looks dubious, the 2 lists in > the data (lex) entry should probably cloned too - and at least the lex > ptrs themselves. > The destroy method leaks, because we can't cleanup duplicated lex ptrs. > > Can somone better knowing scratchpads comment on this please. > I guess there is a related problem with the way the function scratchpad new works, since it needs to copy lex ptrs from enclosing scopes? I will look into it more in a bit ... -- Jonathan Sillito
Re: Objects, finally (try 1)
Here are some examples from Object Oriented Software Construction (Second Edtion), Chapter 15 (Multiple Inheritance): * Simple multiple inheritance: class PLANE ... class ASSET ... class COMPANY_PLANE inherit PLANE ASSET ... or class TREE [G] ... -- Parametric Polymorphism class RECTANGLE ... class WINDOW inherit TREE[WINDOW] RECTANGLE ... * Renaming: class WINDOW inherit TREE [WINDOW] rename child as subwindow, is_leaf as is_terminal, root as screen, arity as child_count, ... end RECTANGLE ... * Page 548, "Unobtrusive repeated inheritance": Cases of repeated inheritance [...], with duplicated features as well as shared ones, do occur in practice, but not frequently. THey are not for beginners; only after you have reached a good level of sophistication and practice in object technology should you encounter any need for them. If you are writing a straightforward application and end up using repeated inheritance, you are probably making things more complicated than you need to. * Redundant inheritance: class A ... class B inherit A ... class D inherit B A ... -- Forgetting that B inherits from A In Eiffel, the default sharing semantics for multiple inheritance means this misstep doesn't cause weird things to happen. * Other weirdness class DRIVER ... -- violation count, address, etc. class US_DRIVER inherit DRIVER ... class FR_DRIVER inherit DRIVER ... -- Ah, France! class US_FR_DRIVER inherit US_DRIVER rename violations as us_violations, ... FR_DRIVER rename violations as fr_violations. PLEASE NOTE: I'm not a fan of this example. But, it comes from the book. I'd be more likely to model this as DRIVER has-a SET of LICENSEs keyed-by AUTHORITY, where the LICENSE has stuff like licensed address and violation count, etc. But, then, my thinking and modeling habits tend toward the dynamic, and Eiffel tends toward the static. The implications of continuing the pattern of this example in the face of a larger set of authorities (countries) is, well, explosive (speaking combinatorically). In the face of a dynamic set of authorities, its unworkable. Anyway, I know that the Eiffel libraries make plenty of use of Eiffel's inheritance and assertion mechanisms. I don't know how often these more complicated situations arise in practice. The point is, Eiffel does have these mechanisms defined and they are expected to be available, and possibly required just to build mundane applications that use the standard library. Regards, -- Gregor "attriel" <[EMAIL PROTECTED]> 01/10/2003 10:37 AM Please respond to attriel To: <[EMAIL PROTECTED]> cc: Subject:Re: Objects, finally (try 1) > On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: >> #10 We do MI, but we don't instantiate a class' attributes multiple >> times if its in the hierarchy for a class more than once. If it is, >> the leftmost instance is real, the rest are virtual My only question here is: What is leftmost? Is that the same as "closest to the actual class we're looking at" or is it "first time it appears in the inheritance structure, and thus the furthest from the relevant class" ? (or something else entirely?) > This will mean we can't support Eiffel, which allows repeated real > inheritance of the same class. It does this by allowing renaming at the > feature level (thats attributes and methods in perl) when inheritance is > declared. Repeated inherited features are shared if they keep the same > name (and they really are the same feature), or split if they don't. I'll admit to never having gotten to looking at eiffel, just hearing about it from some other folks ... But what is the point of explicitly inheriting from the same class multiple times? I mean, sure, if it's in the inheritance tree multiple times, fine, but then you ignore most of them generally; what benefit/use comes from having it actually be in the tree multiple times as distinct entities? I'm just wondering there ... But if it's renaming the structure anyway, wouldn't it still be possible with the single-MI structure that dan proposed? as in, if B inherits from A and then C inherits from A and B directly (and assuming there's a need to separately retain the individual inheritance directions), wouldn't the compiler then say that B inherits from A and C inherits from A2 and B, to retain them both in the parrot? --attriel (I could, of course, be horribly wrong, had I stated a firm opinion rather than requests for more information :)
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Friday 10 January 2003 11:42 am, Paul Johnson wrote: > Damian Conway said: > > Andy Wardley wrote: > >> The arrow is a special case. I don't read that first character > >> as '-', I think of the operator as one. I guess the visual cue forces > >> me to see it like that. > > > > I'm suggesting that ~> and <~ will be the same. > > I think that in part this may depend on the font being used. True. It looks horrid in misc-fixed-* (what I'm assuming Paul has in his xterm).
RE: Array Questions
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]] > But I don't know if these two > lines would really have the same result, ... > > $a = MyScalar; > $a = 'MyScalar'; Hrmm. Didn't Larry decree that there are no bare words, but that a class name will evaluate to the string representing the spelling of the class name? In otherwords, aren't those two assignments identical by definition? =thom "Never try to out-stubborn a cat." --Lazarus Long
RE: L2R/R2L syntax (was Re: Everything is an object.)
Paul Johnson <[EMAIL PROTECTED]> wrote: > When I later saw it using mutt in an xterm, the tilde was at the top of > the character, where I was more used to seeing it and it didn't look like > an arrow any more, nor did it look very good to me. Well, at least now I understand why some people didn't see the squiggly arrow immediately, as I did. It seemed so obvious to MY eyes, I couldn't understand what the big deal was. I have been (quietly) siding with the "let's use unicode characters as operators" camp. But this little brouhaha has me splitting into two universes: Universe 1 (anti-unicode): "If we have this much trouble seeing a tilde the same way, what are the chances that all these cool new operators will be visually comparable to all P6 coders?" Universe 2 (pro-unicode): "If we had a Unicode 'squiggly arrow' operator, then however it looks on everybody's display, it ought to at least look like some kind of squiggly arrow." We'll say goodbye now. =thom "Delusions are often functional. A mother's opinions about her children's beauty, intelligence, goodness et cetera ad nauseam, keep her from drowning them at birth." --Lazarus Long
RE: L2R/R2L syntax (was Re: Everything is an object.)
Andrew Rodland <[EMAIL PROTECTED]> wrote: > But you're missing the most important part! > I propose that these operators should be named "gozinta" ( ~>) > and "comezouta" ( <~ ), just so that we can say that perl has them. Not to > mention that the names work pretty well, for me. Here, here! All in favor, say "Aye"! 'Course, then I've gotta explain why $x = 7 ~> 63; doesn't evaluate to 9 :-) =thom "Be wary of strong drink. It can make you shoot at tax collectors...and miss." --Lazarus Long
Re: L2R/R2L syntax (was Re: Everything is an object.)
> Date: Fri, 10 Jan 2003 08:12:48 -0800 (PST) > From: Austin Hastings <[EMAIL PROTECTED]> > > --- attriel <[EMAIL PROTECTED]> wrote: > > Could someone explain how to know what's the indirect object? (who > > knew > > the "sentence diagramming" would be USEFUL!!) > > Short version: > > If there's two people in the sentence, the verb-ee is either the direct > or indirect object. If there's two people and a thing, the -ee is > indirect. > > I hit him. (He's the direct object.) > > I gave the ball to him. (Ind.) > > In reality, the reference to "indirect object" is a bogus equivalence, > because we're really making the SUBJECT of the sentence, as And the one we're modeling it after in Perl is: I gave him the ball. In Perl 6: gave him: the ball; But a better sentence to use as an example here would be a command, as most imperative (computer) languages use: Give the ball to him. Or equivalently, Give him the ball. In Perl 6: give him: the ball; And as you can see, it is no longer a misnomer. The subject is implicitly "you" or (in a Star Trek sense) "computer". > hit him :I > > becomes > > I.hit(him) I don't think so. Rather, that becomes: him.hit(I); And to clarify, you should probably format it like this: hit him: I; But computer languages aren't generally used to specify past tense anyway To summarize, the indirect object goes I the verb and the direct object, before the colon. Luke
Re: Array Questions
> From: Thom Boyer <[EMAIL PROTECTED]>
> Date: Fri, 10 Jan 2003 13:57:26 -0700
>
> From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
> > But I don't know if these two
> > lines would really have the same result, ...
> >
> > $a = MyScalar;
> > $a = 'MyScalar';
>
> Hrmm. Didn't Larry decree that there are no bare words, but that a class
> name will evaluate to the string representing the spelling of the class
> name? In otherwords, aren't those two assignments identical by definition?
You're correct in that there are no barewords. But, IIRC, a class
name doesn't just evaluate to a string representing the spelling of
the class name. Classes are first-class objects in Perl 6, just as
subroutines were in Perl 5.
The two variables would only behave the same in certain situations
because of symbolic dereferencing. But, they couldn't go by name,
because then what would $foo be here:
$foo = class { has $.bar is public };
As far as the example:
$a = MyScalar;
$b = $a is $a;
(Or something like that) I would imagine that would only work if $a
was known at compile time:
BEGIN { $a = MyScalar; }
$b = $a is $a;
Maybe. Actually, that's quite a difficult question; is MyScalar a
property or a behavior class? Is there a difference, or is the latter
a subset of the former?
But, AFAIK, the two statements are not equivalent.
Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Paul Johnson wrote: > When I later saw it using mutt in an xterm, the tilde was at the top of > the character, where I was more used to seeing it and it didn't look like > an arrow any more, nor did it look very good to me. Ah yes, that's the problem. On all my fonts, the tilde appears at the top and it doesn't look anything like an arrow. Viewing it on a web browser with the tilde centered vertically does indeed bring out the arrow-ness of it. A
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 10, 2003 at 03:55:30PM -0500, Andrew Rodland wrote: > On Friday 10 January 2003 11:42 am, Paul Johnson wrote: > > Damian Conway said: > > > Andy Wardley wrote: > > >> The arrow is a special case. I don't read that first character > > >> as '-', I think of the operator as one. I guess the visual cue forces > > >> me to see it like that. > > > > > > I'm suggesting that ~> and <~ will be the same. > > > > I think that in part this may depend on the font being used. > > True. It looks horrid in misc-fixed-* (what I'm assuming Paul has in his > xterm). -bitstream-courier-* actually, now that I can check, but the effect is the same. Maybe someone can cook up a Perl font that we can recommend to anyone who needs to see the source? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax (was Re: Everything is an object.)
Let me just chime in here that I have been reading all the messages via mutt in an xterm font in which the tilde is at the top of the space, and this has in no way affected my appreciation of the new operators. I don't want them to look like arrows, because that's reminiscent of ->, which is misleading as to the direction of data flow. Visually, I think of <~ and ~> as modifications of the shell redirect operators, which works very well. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
RE: [PATCH] [CVS ci] clone, dod stack reporting
The attached patch fixes the problem. It changes Scratchpad's data pointer to be a pointer to an array of Parrot_Lexicals (rather than an array of pointers to Parrot_Lexicals). The (name and value) lists are shared but never the actual Parrot_Lexical ptr. So no more leak. Patch touches: -- classes/scratchpad.pmc -- sub.c -- t/pmc/scratchpad.t (adds a test) -- Jonathan Sillito > -Original Message- > From: Jonathan Sillito [mailto:[EMAIL PROTECTED]] > > > -Original Message- > > From: Leopold Toetsch [mailto:[EMAIL PROTECTED]] > > > > Further remark: the scratchpad clone code looks dubious, the 2 lists in > > the data (lex) entry should probably cloned too - and at least the lex > > ptrs themselves. > > The destroy method leaks, because we can't cleanup duplicated lex ptrs. > > > > Can somone better knowing scratchpads comment on this please. > > > > I guess there is a related problem with the way the function > scratchpad new > works, since it needs to copy lex ptrs from enclosing scopes? > > I will look into it more in a bit ... > scratchpad_leak.patch Description: Binary data
Re: DOD patches and some remarks
On Jan-10, Leopold Toetsch wrote: > > You get double the amount of PMCs into the cache - used during marking > and freeing. It isn't related to alignment, just more throughput. Oh. You're right. I was thinking that the unused portion of the PMC wouldn't need to be loaded into the cache, so that only the "active" portions of the PMCs would ever be loaded. Which is a fine argument, if your objects are larger than a cache line. But probably few CPUs we care about have only 32-byte cache lines. Ah! So all we have to do is use discontiguous PMCs -- the first 32 bytes is at offset 0, the second at byte offset 128 or so. Then we can interleave them, so that everything in offset 0..127 gets loaded into the cache, but 128..255 is left untouched. (Just kidding.)
Re: Objects, finally (try 1)
If memory serves me right, Chris Dutton wrote: > Actually, if you really want Eiffel to compile to Parrot, it might be > interesting to work on getting ANSI C to compile to Parrot first, since > most Eiffel compilers use compilation to C as an intermediate step. This won't be too much of stretch We already have an ANSI C compiler working well with DotGNU pnet.. (with a IL output plugin)... [11:31] Dan: to go off on a different tangent now - C support [11:31] Dan: compiling C to Parrot, that is [11:31] Ah, that. Yeah, definitely doable. It'll be rather slow, though [11:31] Our function call overhead's rather large compared to what C needs [11:32] Still, I find the thought of C with native continuations rather interesting. Scary, but interesting [11:32] Dan: I was more thinking of the memory layout issues. C code is very particular about struct layout, array representation, etc. I didn't see any opcodes that would allow one to do "pull an int32 out of offset N from this pointer". [11:33] C's not at all particular about struct layout, unless they changed the standard. [11:33] Still, you can do them either with struct PMCs, whcih'd be slowish, or with the pack/unpack opcodes, which I bet are insufficiently documetned [11:34] Action: Dan apparently can't type this evening [11:35] Still, the packed structures need more thoght. Hrm. [11:35] Dan: I suppose a better question would be "is supporting C a goal, or would it just be a cool hack but otherwise uninteresting?" [11:36] because, as you say, it wouldn't be terribly efficient ... [11:36] Neither, really. It's interesting in the sense that it'd let people use code that they otherwise couldn't, if they don't have a C compiler for. [11:36] But it's definitely not a primary goal [11:36] Consider it both mildly interesting and mildly bemusing :) [11:37] Dan: It could make it very useful as a power tool [11:37] Could someone toss up the Parrot URL so I can find out what it is? :) [11:37] Dan: sort of a "swiss army knife" kind of thing [11:37] True, but I'm not willing to lose sight of the primary goal for it. Was our last conversation about Parrot & C compilers .. We'll be adding a Parrot codegen for the compiler backend , as soon as the Objects are set in stone So possibly there exists a possibility for doing up the C compiler (with codegen tweaking) to develop a C compiler targetting Parrot. Gopal -- The difference between insanity and genius is measured by success
Re: L2R/R2L syntax (was Re: Everything is an object.)
I don't know about *your* font, but in mine the ~> and <~ versions are
at least twice as readable as the |> and <| ones.
Just out of curiosity, how did you measure that? ;-)
Well, obviously, I used the Symbol::Readability module:
module Symbol::Readability;
sub delta_r(Str $a, Str $a) returns Int is exported {
return sum [»ord«split//,$x] »-« [»ord«split//,$y]
}
and then:
#! /usr/bin/perl6
use Symbol::Readability;
print delta_r('~>','|>');
How else?
;-)
Damian
