Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (John Siracusa) writes: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It *could* do this, but loading bytecode in Perl 5 is slower than loading and compiling source, so there's not really much point. What's so magic about bytecode, anyway? Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. In what way? How have you managed to break it? -- I would have more respect for Ruby if its docs were not in ALL YOUR BASE format. - Dennis Taylor
Re: Synopsis 9 draft 1
Larry Wall [EMAIL PROTECTED] wrote: On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote: : Honestly I don't see the point why all normal array usage should be : slowed down just for the sake of some rare usage patterns. Does it have to? Couldn't it have a different vtable? (Which argues that such a shape ought to be considered an parameterization of the implementation type. (Which argues that it should be of shape rather than is shape...).) A different vtable implies some kind of a derived class. The question is, if an of shape or is shape already causes a new class of arrayish objects. The question probably is: how much of this class code is done directly by Parrot. But given that shapes can be fully dynamic too my gut feeling is that some glue code will be in the Perl6 library. Larry leo
Re: S4: Can PRE and POST be removed from program flow?
As it stands, though, perl6-internals isn't about perl, but Parrot ... so of the two lists, language is arguably more appropriate... On Sun, 5 Sep 2004 22:37:04 -0400, Matt Diephouse [EMAIL PROTECTED] wrote: I may be completely off base here, but I think this whole discussion would be better suited for perl6-internals. A packaging system would not be a feature of the language itself, but of its implementation. Don't confuse Perl and perl. -- matt -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: S4: Can PRE and POST be removed from program flow?
On Sat, 2004-09-04 at 17:59, John Siracusa wrote: Actually, the other day I was thinking about how I tend to create any useful perl program that I plan to distribute in the form of a big, monolithic script. Take the distribution out of the equation and I'd write a series of generic modules, blah blah, the usual nicely factored design. But the headaches of trying to get users to install modules before they can run my wonderful program always leads me to flatten it all into a tradition Big Honkin' Script (ah, the days of Perl 4...) Actually, I think at least 80% of your concern melts away with Perl 6, not for any technical reason, but because the culture is GOING to change. Right now, compilation isn't really seen as a step for Perl programs, and that's why people expect to be able to just go. Come Perl 6, if your Makefile.pl can (perhaps as a configurable option like MONOLITHIC=1) build a single byte-coded program that includes everything as well as seperately installing your modules, then the user can make the call as to how they want to use it. Heck, you could include a pre-built monolithic compiled version that would get replaced if the user compiled it themselves. So, while the rest of this thread is useful, I'm not sure it's as pertinent as you thought. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
This week's Summary
The Perl 6 Summary for the week ending 2004-09-03 Another week, a free weekend, and still I haven't started writing the summary until Monday. Still, I don't actually start at college 'til next week, so that's all right then. We start with perl6-internals. Compile op with return values The discussion of how to return something from dynamically compiled code continued with Leo, Dan and Steve Fink all working to clarify and address the issues. http://xrl.us/cybq Library loading Dan started the process of nailing down Parrot's dynamic loading API so that it can be added to the embedding interface. Steve Fink and Aaron Sherman had suggestions. http://xrl.us/cybr Pathological register allocation scenarios Gregor N Purdy had asked Dan if his work compiler could be made to spit out structurally equivalent C code to the Parrot code that was breaking IMCC. His idea being that we could then see how C compilers dealt with such nastiness. Dan thought that, whilst this was a good idea, it would be too much work to implement. Gregor wasn't so sure. http://xrl.us/cybs Dan and Leo demonstrate comic timing. Again. 14:17:09 GMT Dan: PerlHash test 20 is failing? Anyone know what's up so we can fix it? 15:30:41 GMT Leo: It stopped failing at 15:55 CEST (13:55 GMT) 16:32:29 GMT Dan: D'oh! We love it when a patch comes together. http://xrl.us/cybt PMC Instantiation Leo had raised issues with the current scheme for PMC instantiation. This week Dan came through with some design which got discussed and (I think) implemented. http://xrl.us/cybu Last bits of the basic math semantics If you believe Barbie, Math is hard. She's right, up to a point. The list's spent a couple of weeks now sorting out the design of Parrots underlying mathematical and numeric systems to make sure that maths works right (for sufficiently useful values of 'right'). This particular line of discussion covers rotations and stuff, where you're actually treating a number as a bit field. http://xrl.us/cybv Cross-compiling parrot And you thought compiling Parrot on a Win32 box was hard. Robert Schwebel wants to cross compile Parrot and isn't having a good time. Dan wasn't surprised because the Parrot build process still gets most of its information from the local perl installation which will generally be wrong when you're cross compiling. Dan noted that part of the problem is that we don't have people on the team with a need or the experience of doing cross compilation and added that he'd be thrilled if this were to change. Any patches to make things better for cross compilers will, of course, be gratefully received. http://xrl.us/cybw Proposal for a new PMC layout and more Leo's concerned that the current PMC layout isn't the Right Thing, and laid out a proposal describing some changes he thinks would be worthwhile. In essence, he argues for removing the requirement for fixed sized PMC headers and separate variable sized buffers in favour of unifying buffers and PMCs so that PMCs become variable sized, thus eliminating some time consuming indirection, and space consuming overheads. Nicholas Clark thought the proposal was interesting, but said that, since the proposed changes would be invisible to the user, he'd be far happier with a functionally complete implementation of parrot with stable, useful APIs. Dan rejected the proposal (both for technical reasons and because he agreed with Nicholas). I don't think Leo was convinced by the technical reasons, but the Let's get the interfaces finished! argument clinched it. http://xrl.us/cybx http://xrl.us/cyby -- Dan explains why not. Semantics for regexes Dan appears to have opened an entertaining can of worms when he outlined his view of the minimum string semantics required to support a regular expression engine and asked for comments. Boy did he get them. And boy did they run off in all sorts of strange directions. Interesting directions mind. Anyway, further down the thread, Dan, Chip Salzenburg and Patrick Michaud seemed to reach something approximating agreement about the low level semantics required. http://xrl.us/cybz TODOs and calls for volunteers Leo came up with a list of things that need fixing/implementing and asked for volunteers. These include sorting out what happens with the experimental ops, implementing new_extended for every PMC class and finishing up BigInt's MMD and vtable functions. He also had some proposals for how we should get the Integer classes properly implemented now we know what the semantics will be. http://xrl.us/cyb2 http://xrl.us/cyb3 http://xrl.us/cyb4 http://xrl.us/cyb5 Meanwhile, in perl6-language Roles trying to
Re: S4: Can PRE and POST be removed from program flow?
On Mon, 6 Sep 2004 11:48:59 +, Herbert Snorrason [EMAIL PROTECTED] wrote: As it stands, though, perl6-internals isn't about perl, but Parrot ... so of the two lists, language is arguably more appropriate... perl6-internals is about perl the implementation (which is parrot). perl6-language is about Perl the language. perl != Perl Code packaging is a matter of perl, not Perl, I believe. -- matt
Re: What Requires Core Support (app packaging)
On 9/6/04 3:48 AM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It *could* do this, but loading bytecode in Perl 5 is slower than loading and compiling source, so there's not really much point. What's so magic about bytecode, anyway? Don't you think it's preferable to temp-expanding and compiling at runtime? I'd rather not have to write files to disk just to launch... Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. In what way? How have you managed to break it? The slides about the internals do start with Here begins the scary part and claim that PAR invokes four areas of Perl arcana, some of which were, or still are, undocumented. As for breaking it, I suppose all I'd have to do is try to use it on a platform that has perl but is not supported by PAR. Don't get me wrong, PAR is a great, impressive collection of code. But part of the reason that it's so impressive is that it's not easy to get Perl 5 to do this type of thing without a lot of clever tricks. I'd like it if this kind of thing doesn't have to be quite so clever in the Perl 6 age :) -John
Re: S4: Can PRE and POST be removed from program flow?
On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote: Finally, platform independent execution of any packaged or precompiled single file will *require* cooperation (core support) from the perl executable itself. PAR is neat, but it doesn't even match up that well with JAR, which allows the same file to work everywhere Java works. I just don't I'm confused here - specifically what can cause a PAR file not to run anywhere? The only reason I can think of is that it contains bundled up platform-specific shared libraries. Which means non-core C code. As long as perl lets you link in C code it's going to have to be pre-compiled for your platform. I can't see how JAR could avoid this problem if JAR were used for anything other than pure Java bytecode. Nicholas Clark
Re: What Requires Core Support (app packaging)
On Sun, Sep 05, 2004 at 10:40:24AM -0400, John Siracusa wrote: 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. (Well, I suppose it could try to #! boostrap as well, but then you'd have to inline a bytecode interpreter or find some way to feed the bytecode to the right part of perl 6, which seems like it also leads to some sort of core support.) There is core support for this in perl5. use ByteLoader puts a source filter module in place that reads the rest of the file in as perl5 bytecode. But as Simon says in another message, this bytecode is bigger and slower to load than perl source. needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. Or in perl 5. The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do this better. The perl 6 core needs to be designed with this type of stuff in mind. Parrot is being designed with this stuff in mind. This is far more a parrot issue. Parrot has directly serialisable bytecode, and can run bytecode from disk. I think packaging has the same characteristics. But unlike CPAN, packaging does require some minimum amount of core support to meet what I consider to be the minimum standard of elegance. I think that this is true. I'm not sure what the minimal list is, and I suspect that really it's more a parrot issue than a perl 6 syntax issue. Nicholas Clark
Re: S4: Can PRE and POST be removed from program flow?
On 9/6/04 12:13 PM, Nicholas Clark wrote: On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote: Finally, platform independent execution of any packaged or precompiled single file will *require* cooperation (core support) from the perl executable itself. PAR is neat, but it doesn't even match up that well with JAR, which allows the same file to work everywhere Java works. I just don't I'm confused here - specifically what can cause a PAR file not to run anywhere? The only reason I can think of is that it contains bundled up platform-specific shared libraries. Which means non-core C code. As long as perl lets you link in C code it's going to have to be pre-compiled for your platform. I can't see how JAR could avoid this problem if JAR were used for anything other than pure Java bytecode. I guess its kind of apples and oranges since Java has all its own libs, whereas Perl tends to piggyback on existing C libs (or include its own C parts) for certain things. -John
Re: What Requires Core Support (app packaging)
On 9/6/04 12:21 PM, Nicholas Clark wrote: I think packaging has the same characteristics. But unlike CPAN, packaging does require some minimum amount of core support to meet what I consider to be the minimum standard of elegance. I think that this is true. I'm not sure what the minimal list is, and I suspect that really it's more a parrot issue than a perl 6 syntax issue. Hm, well, features of the perl6 executable itself aren't really fodder for the parrot lists (are they?)...although I forget where they've been discussed in the past. Anyway, the long-suffering internals guys are still hashing out whether or not to have a STRING type or use PMCs for that, yada yada, so I think this is an issue to save for a bit later on... :) -John
Re: What Requires Core Support (app packaging)
On Mon, Sep 06, 2004 at 12:28:16PM -0400, John Siracusa wrote: Hm, well, features of the perl6 executable itself aren't really fodder for the parrot lists (are they?)...although I forget where they've been discussed in the past. Anyway, the long-suffering internals guys are still hashing out whether or not to have a STRING type or use PMCs for that, yada yada, so I think this is an issue to save for a bit later on... :) I think that that problem comes down to a lack of Rule 1 for Dan. Nicholas Clark
Re: What Requires Core Support (app packaging)
(not on the list, please Cc me in replies.) On Sun, Sep 05, 2004 at 08:49:20PM -0400, John Siracusa wrote: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It's closest to item #2 in my feature list, but it's something very different than compiling down to bytecode. Minor nitpick: pp -f Bytecode does precompile to bytecode. But as we know, Perl5 bytecode is platform-dependent, slow, and somewhat fragile. Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. Well, PAR largely depends on the @INC-hook mechanism to do what it does, although in the pure exe-only mode it could also do without that, depending on extracting to temp and adding the temp dir to @INC instead. I suspect the PAR author would love to list the things he needs in the perl 6 core to implement PAR6 in a reliable, straight-forward manner. Well, having a core inflate() (or maybe the whole Archive::Zip API) would be a very good start. Compiling Zlib into core is perhaps a Parrot problem instead of a Perl6 one. Co-existence of multiple versions of loaded modules on the same machine. This is probably already in Perl6. Core support for reading (and seeking) HTTP/FTP sources would be pretty cool, but not required. Thanks, /Autrijus/ pgpRle6yihF0l.pgp Description: PGP signature
Re: Roles trying to be nice
On Mon, Aug 30, 2004 at 12:17:57PM -0500, Abhijit Mahabal wrote:
Another example to clarify what I am getting at:
Role Log2File [: $filename] { method do_the_logging {...}; ... }
Role Log2Email [: $address ] { method do_the_logging {...}; ... }
Role Log2Tk[: $widget ] { method do_the_logging {...}; ... }
Role SimpleLog {
method log( $msg ) { .do_the_logging( $msg ) }
}
Role PoeticLog {
my sub make_into_poem {...}
method log( $msg ) {
.do_the_logging( make_into_a_poem( $msg ) );
}
}
Class Poem does PoeticLog does [EMAIL PROTECTED] {...}
[ deletia ]
In the example above, PoeticLog does not want to define the method
.do_the_logging, but needs it to have been defined by somebody anyway.
To reiterate my question with this new example, Can PoeticLog somehow
ensure that somebody has defined .do_the_logging?
Hmm. So you want to check immediately after class/object composition
time that the class/object has a do_the_logging routine?
I didn't see any mention of this in a quick search through the
Apocalypses, but surely you can apply PRE and POST to roles. I.e.
role PoeticLog {
...
POST { exists do_the_logging }
}
would fire at class/object composition time. (PRE would fire just
before composition, POST immediately after). I seem to recall
something like this for classes too (though I may have imagined it)
where PRE blocks would fire immediately upon instantiation, and POST
blocks immediately after instantiation. Er, perhaps the terminology
is wacky there. The instantiation process goes PRE,BUILD,POST and
doesn't actually happen unless all of those happen.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (John Siracusa) writes: Don't you think it's preferable to temp-expanding and compiling at runtime? Not if it's slower, no. The choice was made not to go with bytecode because of a deficiency in Perl. If that deficiency wasn't there, then sure, go with bytecode. But you're missing the point, so I'll say it again: IT DOESN'T MATTER. The slides about the internals do start with Here begins the scary part For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't trust things which are self-declared scary hackery to be stable, you probably shouldn't be using Perl until Perl 6 comes out. And probably not until then. Look, we're not going to agree on this. Should we just drop the subject? -- Though a program be but three lines long, someday it will have to be maintained. -- The Tao of Programming
Re: Synopsis 9 draft 1
On Mon, Sep 06, 2004 at 10:13:56AM +0200, Leopold Toetsch wrote: : A different vtable implies some kind of a derived class. The question : is, if an of shape or is shape already causes a new class of : arrayish objects. : The question probably is: how much of this class code is done directly : by Parrot. But given that shapes can be fully dynamic too my gut feeling : is that some glue code will be in the Perl6 library. Okay, I'll try to make it clear in S9 that non-0-based arrays are not to be implemented in such a way that the base array class is slowed. If that means they're not in 6.0.0 at all, that's okay. I'm mostly just trying to keep the syntactic space open for them by allowing ranges in shape parameters, which implies that the parameters are lists rather than scalars, which implies they have to be separated by semicolons rather than commas. Larry
Re: Synopsis 9 draft 1
On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote:
: Honestly I don't see the point why all normal array usage should be
: slowed down just for the sake of some rare usage patterns.
Another possibility is that .[] always forces the normal view of an
array as 0-based, and if you want non-0-based arrays you have to use
the .{} interface instead, on the assumption that strange subscripts
are more like hash keys than ranges of integers. Certainly if
you have a sparse array with keys like 1,2,4,8,16,32... you have a
situation that's more like a hash than an array. A sparse array
might not even give you the .[] interace. The presence of a .[]
interface might signal the ability to process contigous ranges,
even if those ranges are offset from the .{} range.
Such an approach would have the benefit that a module could simply
treat all its arrays as 0-based .[] arrays, and if you happened to
pass a non-0-based .{} array in, it would still work, albeit with
0-based indexes instead of whatever shape the .{} interface uses.
Anyway, it's an idea that might or might not make sense. It seems
to me, though, that either you're interested in treating all the
dimensions of a subscript as non-0-based, or none of them. I think
people will rarely want to mix those in the same subscript.
On the other hand, it opens up the possibility of mixing up .[] with .{}
and getting off-by-n errors, unless a declared shape of non-0-based
turns off the .[] interface entirely.
Larry
Re: The last shall be last
On Sun, 5 Sep 2004, Matt Diephouse wrote: Am I the only one that thinks that -1st should return the last element in an array under the nth scheme? 1st should mean the first element. -1st should mean the first element of the reversed array. Don't say -1st is the first from last. If last is the opposite of first, I would expect 1st to mean first from first, which would mean the second. Say first from the end. It matches up with perl5 C$array[-1] and is a workable interpretation of negative ordinals. So I could think that way too. @ary[ 1st .. -1st ]# hmm...
