Re: A note on constant strings
Dan Sugalski wrote: Or, rather, the const_string function. Simple thing, looks like: STRING *foo = const_string(interpreter, c-style string constant); Easy, right? Yeah. Easy. Well, the real constant string is constructed like so: STRING *foo = CONST_STRING(interpreter, cstring); These strings get folded into a constant table (interpreter-const_cstring_table). The drawback is that it needs a bit of work per file (include the .str file, adapt Makefile build rules). See e.g. src/objects.c for usage patterns. leo
Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Generator-0.22.tar.gz
Thomas Klausner sent the following bits through the ether: On issue I'd like to ask is: We (Gabor Szabo and I) are thinking of renaming the distribution from Module::CPANTS to CPANTS. Do you think that this is a good idea? I see no advantage and quite a bit of pain in renaming. However, it is your module ;-) Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... But my little voice TOLD me to do it!
Re: No Autoconf, dammit!
While I am generally in favor of this idea (and I did get the first miniparrots to work, pretty much as proof of concept), I do think it's likely to be rather challenging (and interesting): Remember, _pure_ C89 provides only these headers: assert.h complex.h ctype.h errno.h fenv.hfloat.h inttypes.hiso646.h limits.h locale.h math.hsetjmp.h signal.h stdarg.h stdbool.h stddef.h stdio.h stdlib.h string.h tgmath.h time.h wchar.h wctype.h This leaves out a number of things that one would really like to have to do system probing, most notably: - file info (stat, fstat) - executing programs in any kind of sophisticated way (fork/exec, pipes) My only real point is that, while I think pure c89 is a nice goal, in practice we will need to relax this just a bit, to include at the very least, things like unistd and bits of posix that are likely to be everywhere.Should be interesting. Probably isn't going to really gain momentum until we get some of the build system written in something that compiles down to run on parrot.. How's that perl 6 compiler coming? ;-) --Josh At 18:20 on 09/07/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: This argument's old. Very old, so it may be unfamiliar to many people. The subject generates enough heat that I don't want to go there again. We are not using autoconf. Period. Parrot's build process, when shipped will be: *) Person building runs platform-specific script *) Script builds miniparrot, which assumes ANSI C89 functionality only *) Miniparrot runs provided configure program, which is in bytecode *) Configure probes environment *) Full parrot is built *) Full parrot is then invoked to complete the build process, which is driven by a program written in a parrot language and provided as bytecode -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Bundles
On Tue, Sep 07, 2004 at 07:39:49PM -0400, Dan Sugalski wrote: : You've got things a bit turned around I think. Parrot's the engine. : It provides the services, runs the code, handles the environment, and : generally manages stuff. If you want, think of it as a combination : CPU, OS, low-level debugging tools, and standard system libraries : that compilers for all the languages use. Since you're likely going : to want to package up bytecode, resources, library modules, and : possibly multi-language source, it's Parrot's problem to make it work : right, and set up a base so that everyone does it the same way. Which explains, of course, why Unix has 58 ways to do it. :-) Larry
Current state?
Since this list has been started, I'd assume that means work on the final Perl6 compiler is about to start. (Although, with this crowd, you never do know...) In the interest of a layman's curiosity: What's the current status? (And I already wonder if this won't make the summaries even more irregular. ;) -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: more ordinal discussion
Michael Homer skribis 2004-09-08 15:54 (+1200): I think (correct me) what he's getting at here is a sparse array 1=a, 3=b, 4=c where 2nd is 'b' (the second item) but 1st+1 is undefined (there is no index 2). I don't know how well that scheme works from a comprehension point of view though, it seems a little confusing. Oh my, sparse arrays. Isn't that what we have hashes for? Juerd
Re: GC bug triggered in examples/streams?
Jens Rieks wrote: Hi, the examples in examples/streams are not working with --gc-debug, FileLines.imc crashes even without it. Any idea why? Nasty. After spending some hours with gdb and thinking up, down, and in circles, I could eventually boil it down to the code below. The continuation created in sub2 has in its context a snapshot of the register backing stacks. After returning from sub2, this context is still alive in the continuation. Now when calling another sub, the interpreter's context changes. The register preserving code is attaching different register backing stacks to the context (simulated by pushi below). Now, when these new stack chunks happen to have the same address as the stack saved in the context of the continuation, Bad Things happen. In this case (and in FileLines.imc) the piece of stack is an IntReg stack, which gets marked by Continuation mark as a PMC stack. But 0x1 or 0x2 isn't a good looking pointer ;) The primary reason is of course the immediate reusal of stack chunks (the pushi get's the popped of PMC reg chunk of the function return). But not reusing register stacks could cause the problem too, only a DOD run later and still much harder to track down, because it would be more unlikely that a certain chunk address gets reused in that way. The real problem is that the Continuation holds a snapshot of an interpreter context that just doesn't exist any more. I don't know how to fix this, though. But the proposed change in calling conventions (swapping in and out interpreter structures) should not have this very problem. There are no register backing stacks any more, the interpreter structure is it's own context. A continuation that exists somwhere should therefore always point to a valid context aka interpreter, because the continuation would mark that context as being alive. Only if the continuation goes out of scope, that context would be invalidated and possibly reused. .sub main @MAIN print main 1\n sub1() print main 2\n sub3() .end .sub sub1 prototyped print sub1 1\n $P5 = sub2() P25 = $P5 print sub1 2\n .end .sub sub2 prototyped print sub2 1\n .local pmc cont cont = new .Continuation .pcc_begin_return .return cont .pcc_end_return .end .sub sub3 prototyped pushi print sub3 1\n sweep 1 popi .end leo
Re: [perl #31424] [RESOLVED] PATCH: Fix for parrot linking issue on Solaris 8
Clayton O'Neill [EMAIL PROTECTED] wrote: This adds support for setting triggers on specific config variables. Thanks, applied finally, except the order of calling gcc.pl, which already changed in the meantime and is (hopefully) correct already. leo
Re: GC bug triggered in examples/streams?
At 2:10 PM +0200 9/8/04, Leopold Toetsch wrote: Jens Rieks wrote: Hi, the examples in examples/streams are not working with --gc-debug, FileLines.imc crashes even without it. Any idea why? Nasty. After spending some hours with gdb and thinking up, down, and in circles, I could eventually boil it down to the code below. The continuation created in sub2 has in its context a snapshot of the register backing stacks. After returning from sub2, this context is still alive in the continuation. Now when calling another sub, the interpreter's context changes. The register preserving code is attaching different register backing stacks to the context (simulated by pushi below). Now, when these new stack chunks happen to have the same address as the stack saved in the context of the continuation, Bad Things happen. This shouldn't happen--we're apparently doing wrong things with the backing stacks. (This was working properly at one point) If a continuation's taken then the backing stacks should all be marked COW. Pushes to partially filled stack chunks should result in the chunk getting cloned with the original chunk left for anything holding onto it. There are two simple answers here (the proposal for the change in the way interpreter context structs are handled isn't it -- we'll have the same problem because we'll still have backing stacks). Either get COW working on the backing stacks as it ought, or switch to a one-frame-per-chunk scheme. Both will work out just fine. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A note on constant strings
At 8:52 AM +0200 9/8/04, Leopold Toetsch wrote: Dan Sugalski wrote: Or, rather, the const_string function. Simple thing, looks like: STRING *foo = const_string(interpreter, c-style string constant); Easy, right? Yeah. Easy. Well, the real constant string is constructed like so: STRING *foo = CONST_STRING(interpreter, cstring); These strings get folded into a constant table (interpreter-const_cstring_table). The drawback is that it needs a bit of work per file (include the .str file, adapt Makefile build rules). Right, that was the partial solution I mentioned. Still not a full solution, unfortunately, but not a bad one for the core code. We probably ought to work up a list of the places it's valid and deploy it more. It'd certainly cut down on the number of string headers created. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
At 7:26 PM -0400 9/7/04, Josh Wilmes wrote: While I am generally in favor of this idea (and I did get the first miniparrots to work, pretty much as proof of concept), I do think it's likely to be rather challenging (and interesting): Remember, _pure_ C89 provides only these headers: assert.h complex.h ctype.h errno.h fenv.hfloat.h inttypes.hiso646.h limits.h locale.h math.hsetjmp.h signal.h stdarg.h stdbool.h stddef.h stdio.h stdlib.h string.h tgmath.h time.h wchar.h wctype.h This leaves out a number of things that one would really like to have to do system probing, most notably: - file info (stat, fstat) Yep, these are a pain. Luckily the simple stuff (like Does the file even exist?) can be done with open and its return status. - executing programs in any kind of sophisticated way (fork/exec, pipes) We do get system and popen, though. My only real point is that, while I think pure c89 is a nice goal, in practice we will need to relax this just a bit, to include at the very least, things like unistd and bits of posix that are likely to be everywhere.Should be interesting. Yeah, there's no reason that the basic system can't have some #ifdefs for the really common things. Probably isn't going to really gain momentum until we get some of the build system written in something that compiles down to run on parrot.. How's that perl 6 compiler coming? ;-) I'm more than happy to start writing the remaining environment probes in pir. :) At 18:20 on 09/07/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: This argument's old. Very old, so it may be unfamiliar to many people. The subject generates enough heat that I don't want to go there again. We are not using autoconf. Period. Parrot's build process, when shipped will be: *) Person building runs platform-specific script *) Script builds miniparrot, which assumes ANSI C89 functionality only *) Miniparrot runs provided configure program, which is in bytecode *) Configure probes environment *) Full parrot is built *) Full parrot is then invoked to complete the build process, which is driven by a program written in a parrot language and provided as bytecode -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Integer PMCs
At 2:21 PM +0200 9/3/04, Leopold Toetsch wrote:
[ resent ]
Date: Thu, 26 Aug 2004 09:17:52 +0200
Subject: Integer PMCs
Fog around integer PMC semantics is lifting, so we should start bringing
classes/*.pmc into shape.
Currently PerlInt is the most complete implementation of the proposed
semantics. Some vtable methods like Csubtract still need work, though.
Anyway, I'd do:
1) cp perlint.pmc integer.pmc
2) pmclass PerlInt extends Integer {}
3) pmclass Py_int extends Integer {}
ad 1)
IIRC the class name of Parrot types should be mangled to __Integer or
some such. Last time I tested the PMC-compiler didn't really support to
define class names that differ from the filename.
ad 2) PerlInt is basically empty.
ad 3) almost empty except for invoke() as constructor. Class name could
be Python_int too, Pythonint doesn't really look good.
I'd skip everything but #1 and fixing up integer.pmc to express the
semantics we've worked out. We can work on extending to the perl and
python integers after that.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: No Autoconf, dammit!
At 7:22 AM +0200 9/8/04, Robert Schwebel wrote: Dan, sorry, although I'm a long term perl user I'm not that familiar with the internals of the perl development process that I know all the old stories ;) The plan looks good, but some things are still unclear to me: *) Person building runs platform-specific script Platform specific means also cross-platform specific? Not in this case, and I was being a bit broad. There are (or will be) two different ways to build parrot. The first is with a platform-specific script. That means shell scripts for the various Unix (and Unix-ish, like Cygwin) platforms, a .BAT file for windows, a .COM file for VMS, and so on. Whether there's a per-platform shell script for the Unices or one generic one that'll work well enough to bootstrap to the Use parrot because it's nicer phase of the build's up in the air. This way assumes the user has a command-line prompt of some sort and a C compiler. One of the big reasons I want a non-make make tool is so we can teach it to generate these scripts for us from the dependency lists. The second is the 'developer' way, which will assume more tools -- a working perl, make tool (maybe), possibly a working python or ruby (or parrot with all three), possibly lexyacc or the closest equivalent. The first method is for people who want to get the source tarball and build it for installation. The second is for people who want to do development work on parrot. Folks doing cross-platform stuff will presumably use the second way. (I don't think this is too unreasonable :) *) Configure probes environment How do you probe a cross environment? The build process will in this case run on i686. Since I've minimal (which is to say, absolutely no) cross-environment build experience, this bit's a bit dodgy. For building parrot itself, I'm assuming we can get away with a configuration file holding all the info we need to build parrot -- basically everything parrot's configure will probe for. Building the ancillary stuff will be a bit problematic, since to do so will need parrot, but the parrot you'll have won't run on the platform you're on. So... I'm kinda at a loss there. I'm *more* than happy to take suggestions or wholesale direction here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
At 9:44 AM -0400 9/8/04, Josh Wilmes wrote: At 9:23 on 09/08/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: - executing programs in any kind of sophisticated way (fork/exec, pipes) We do get system and popen, though. Well, system at least. popen is not part of the c89 spec as far as I know. Bah. :( I was working on the assumption that it was, since popen requires stdio.h. This URL is a fairly handy reference: http://www.unix.org/version3/inttables.pdf Now *that* is a really useful table. Cool! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current state?
On Wed, Sep 08, 2004 at 10:48:05AM +, Herbert Snorrason wrote: In the interest of a layman's curiosity: What's the current status? We're in the beginning stages of building a basic perl 6 grammar engine (i.e., probably without p6 closures) that compiles to parrot and handles basic optimizations. Concurrent with that I'm working on a Perl 6 grammar. I'm expecting a working basic grammar engine in a little over a month. We'll test it on a few simple languages, and then start using it to build the Perl 6 parser and code generator. Pm
Re: No Autoconf, dammit!
At 9:23 on 09/08/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: - executing programs in any kind of sophisticated way (fork/exec, pipes) We do get system and popen, though. Well, system at least. popen is not part of the c89 spec as far as I know. This URL is a fairly handy reference: http://www.unix.org/version3/inttables.pdf --Josh
Re: Semantics for regexes - copy/snapshot
According to [EMAIL PROTECTED]:
So how many stores do we expect for
($a = xxx) =~ s/a/b/g
and which of the possible answers would be more useful?
I think it depends on C($a = aaa) =~ s/a/b/g.
* If the s/// operator stores once after all substitutions,
then having it alway store whether the subst happened
or not makes sense. One = one STORE; one =~ one STORE.
* If the s/// operator stores once for each match/subst,
then if no matches happen then no STOREs happen.
Minimal stores are also relevant for this oddity:
($a = aaa) =~ s{a}
{ $x++ ? substr($a,0,1) : 'b' }e;
Now, should that produce bbb or baa? I favor baa, because I
think minimal stores are too important to compromise them just for
this bizarre use case.
--
Chip Salzenberg - a.k.a. -[EMAIL PROTECTED]
Persistence in one opinion has never been considered
a merit in political leaders. --Marcus Tullius Cicero
Constant strings, part two (A simple perl task!)
So, Leo's got a tool to handle turning CONST_STRING macros into real constant strings. Which is cool. (build_tools/c2str.pl) The tool could use a bit of thumping, though. Right now it does per-file scanning, and only of .c files. What I'd like to do is to teach it to scan through multiple files and extract out the CONST_STRING info, to build up a single master header and initializer. This'll let strings be shared across source modules and make for a single pass over the source as part of the build phase. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 09:51:35AM -0400, Dan Sugalski wrote: Whether there's a per-platform shell script for the Unices or one generic one that'll work well enough to bootstrap to the Use parrot because it's nicer phase of the build's up in the air. This way assumes the user has a command-line prompt of some sort and a C compiler. One of the big reasons I want a non-make make tool is so we can teach it to generate these scripts for us from the dependency lists. Is my impression correct that nobody has ever tried crosscompiling perl, and that nobody is really interested in doing it in the future? I assume that, if you don't take this into account from the beginning it is not very probable that it will ever work before Perl 7 :-) Folks doing cross-platform stuff will presumably use the second way. (I don't think this is too unreasonable :) Ack. Since I've minimal (which is to say, absolutely no) cross-environment build experience, this bit's a bit dodgy. For building parrot itself, I'm assuming we can get away with a configuration file holding all the info we need to build parrot -- basically everything parrot's configure will probe for. I'm still not sure what you mean with probe. When doing cross builds you cannot probe anything in the sense of run some test code and look at it's output, because (in my scenario) the build process is done on i686, whereas the final code has to run on ARM. So you have to put all the intelligence about which CPU core / plattform / libc / binary format variant has which properties into some predefined magic: definitely something one doesn't want to do without quite a lot of cross compiling experience. Building the ancillary stuff will be a bit problematic, since to do so will need parrot, but the parrot you'll have won't run on the platform you're on. So... I'm kinda at a loss there. I'm *more* than happy to take suggestions or wholesale direction here. Well, I still don't understand what the _technical_ arguments against autotools are, besides not being written by LW ;) Some pro arguments: - runs on about all available platforms today, configure written in sh - does proper cross compiler handling - c89 handling is no problem - everyone is used to configure/make/make install Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Re: Current state?
Patrick R. Michaud wrote: We're in the beginning stages of building a basic perl 6 grammar engine (i.e., probably without p6 closures) that compiles to parrot and handles basic optimizations. Concurrent with that I'm working on a Perl 6 grammar. Where can one get a look at these wonderful things? tinderbox.perl.org would be my guess, but it does not seem to be working.
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 04:46:28PM +0200, Robert Schwebel wrote: On Wed, Sep 08, 2004 at 09:51:35AM -0400, Dan Sugalski wrote: Whether there's a per-platform shell script for the Unices or one generic one that'll work well enough to bootstrap to the Use parrot because it's nicer phase of the build's up in the air. This way assumes the user has a command-line prompt of some sort and a C compiler. One of the big reasons I want a non-make make tool is so we can teach it to generate these scripts for us from the dependency lists. Is my impression correct that nobody has ever tried crosscompiling perl, and that nobody is really interested in doing it in the future? No. The WinCE port of perl (in the Perl 5 source) is a cross compile on Win32, as I understand it. The Zaurus packages are built as a cross compile on another Linux, and should be repeatable based on the instructions in the directory Cross/ Well, I still don't understand what the _technical_ arguments against autotools are, besides not being written by LW ;) Some pro arguments: - runs on about all available platforms today, configure written in sh sh doesn't run on all platforms that perl has done historically. (platforms where perl is built natively, but not using the Configure script) And sh is unlikely to get ported to them. While parrot might. Parrot doesn't rely on a fork()/exec() process model and interprocess pipelines, whereas I'm under the impression that sh does. And these are hard to emulate if they are absent. - does proper cross compiler handling Which is really useful. - c89 handling is no problem Which is good. - everyone is used to configure/make/make install On Unix. There is more to Perl than Unix. Nicholas Clark
Re: No Autoconf, dammit!
Robert Schwebel wrote: Is my impression correct that nobody has ever tried crosscompiling perl, and that nobody is really interested in doing it in the future? I assume that, if you don't take this into account from the beginning it is not very probable that it will ever work before Perl 7 :-) Sounds like some of us with cross-compiling experience need to get our hands dirty, once the basic build system is in place. I do think Dan's plan to use a special configuration file that needs to perform no probing will work that is more or less what non-autoconf cross compilation entails anyway. It is a pain you have to know _everything_ about your target. What category is this problem: easy or possible? Cross-compiling is never easy. It should definitely be possible. Keeping enough information around in a fancy cross-compiling perl script could be ... quiet nasty. Frameworked properly, however, such a script could work both for unknown and known targets. (Robert is likely screaming: Your re-inventing autoconf!!!) Gregory Keeney
Re: GC bug triggered in examples/streams?
Dan Sugalski wrote: There are two simple answers here (the proposal for the change in the way interpreter context structs are handled isn't it -- we'll have the same problem because we'll still have backing stacks). No. As layed out my scheme doesn't need any register backing stacks. ... Either get COW working on the backing stacks as it ought, or switch to a one-frame-per-chunk scheme. Both will work out just fine. Err. Ehem. We already switched to an one-frame-per-chunk scheme. Stacks aren't COWed anymore since quite a time[1]. See e.g. Perl 6 Summary posted on Mar 29th: Dan ... made the decision to switch to single item per frame, immutable, non COW stacks. Leo implemented it. This was the outcome of a longer discussion, where Piers had troubles with continuations. COWed stacks wouldn't help, AFAIK, anyway. The problem is the invalid context the continuation is holding. Please reread rethink the problem. [1] end of March leo
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 04:03:03PM +0100, Nicholas Clark wrote: No. The WinCE port of perl (in the Perl 5 source) is a cross compile on Win32, as I understand it. The Zaurus packages are built as a cross compile on another Linux, and should be repeatable based on the instructions in the directory Cross/ I've tried to follow the instructions but they are done for a very special Zaurus environment and not really generic. But I'll try again with the recent versions, perhaps something has changed to the better recently. sh doesn't run on all platforms that perl has done historically. On which platforms shall perl run _today_ which is not able to run sh? And sh is unlikely to get ported to them. While parrot might. Parrot doesn't rely on a fork()/exec() process model and interprocess pipelines, whereas I'm under the impression that sh does. And these are hard to emulate if they are absent. This is fine, especially for example for uCLinux systems. But hold on: does somebody really _compile_ parrot on such a system? There are not that much systems left today which have this needs and I doubt that somebody will do a complete perl build on something like my 30 MHz ARM7 :-) It seems to be a little bit strange to me that the ability to be compiled on prehistoric systems seems to be more important than a correct cross compiler environment. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Re: No Autoconf, dammit!
Robert Schwebel wrote: On which platforms shall perl run _today_ which is not able to run sh? VMS. Just because you don't use it doesn't mean that nobody uses it. -garrett
Re: Current state?
On Wed, 8 Sep 2004 07:33:45 -0600, Patrick R. Michaud [EMAIL PROTECTED] wrote: We're in the beginning stages of building a basic perl 6 grammar engine (i.e., probably without p6 closures) that compiles to parrot and handles basic optimizations. Concurrent with that I'm working on a Perl 6 grammar. The system described in Apocalypse 5, I take it? (Don't hurt me, I just like to be certain...) I'm expecting a working basic grammar engine in a little over a month. We'll test it on a few simple languages, and then start using it to build the Perl 6 parser and code generator. Cool. Any estimate for a working version? And any way for an overeager newbie to help? :D -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 08:07:52AM -0700, Gregory Keeney wrote: Sounds like some of us with cross-compiling experience need to get our hands dirty, once the basic build system is in place. I suppose I can do quite some testing in this case: with PTXdist I can easily build complete Linux userland systems for quite a lot of strange embedded processors (ARM, PPC, MIPS) and test if it works under these circumstances. I do think Dan's plan to use a special configuration file that needs to perform no probing will work ??? that is more or less what non-autoconf cross compilation entails anyway. It is a pain ??? you have to know _everything_ about your target. Hmm, can somebody specify which special parameters one needs to know? Normally things work quite fine if C code ist only compiled with the right cross compiler; some things like endianess have to be taken into account, what else? What category is this problem: easy or possible? Cross-compiling is never easy. Well, it depends. With autoconf (done right) it works right out of the box, but let's end this here. It should definitely be possible. Keeping enough information around in a fancy cross-compiling perl script could be ... quiet nasty. Frameworked properly, however, such a script could work both for unknown and known targets. (Robert is likely screaming: Your re-inventing autoconf!!!) How did you know :-) It's just my experience that people normally start with thinking that they can do it much easier than autoconf, and in the end there come more and more requirements, scripts become more and more compilcated and in the end you have something like autoconf but without the huge ammount of experience which went into the system, so working in less situations and being incompatible. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Re: No Autoconf, dammit!
At 5:16 PM +0200 9/8/04, Robert Schwebel wrote: sh doesn't run on all platforms that perl has done historically. On which platforms shall perl run _today_ which is not able to run sh? No offense, but it *doesn't* *matter*. We're not using autoconf, as the subject of this thread makes clear. That's not negotiable. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: GC bug triggered in examples/streams?
At 4:41 PM +0200 9/8/04, Leopold Toetsch wrote: Dan Sugalski wrote: There are two simple answers here (the proposal for the change in the way interpreter context structs are handled isn't it -- we'll have the same problem because we'll still have backing stacks). No. As layed out my scheme doesn't need any register backing stacks. If you're cloning the context every time someone pushes a register frame... that's a bit excessive. If you're tossing the backing stacks, that's not an option. ... Either get COW working on the backing stacks as it ought, or switch to a one-frame-per-chunk scheme. Both will work out just fine. Err. Ehem. We already switched to an one-frame-per-chunk scheme. Stacks aren't COWed anymore since quite a time[1]. See e.g. Perl 6 Summary posted on Mar 29th: Dan ... made the decision to switch to single item per frame, immutable, non COW stacks. Leo implemented it. This was the outcome of a longer discussion, where Piers had troubles with continuations. Which is swell, but this stuff tends to change every few months. (Yesterday's leak hunt gave me a chance to dig into the interesting abomination the allocation/GC/DOD system's turned into since I last looked) COWed stacks wouldn't help, AFAIK, anyway. The problem is the invalid context the continuation is holding. Nonsense. If the continuation's got a hold of a chunk of the backing stacks then those stacks aren't invalid, chunks should get reclaimed by the DOD, and shouldn't get reused until they've been reclaimed. This *shouldn't* be happening. If it is then we're missing something straightforward that needs fixing. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 11:23:36AM -0400, Dan Sugalski wrote: No offense, but it *doesn't* *matter*. We're not using autoconf, as the subject of this thread makes clear. That's not negotiable. A really convincing argumentation. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Re: No Autoconf, dammit!
Robert Schwebel wrote: It seems to be a little bit strange to me that the ability to be compiled on prehistoric systems seems to be more important than a correct cross compiler environment. On which platforms shall perl run _today_ which is not able to run sh? For a particular project I am considering using Parrot on a custom system based on Texas Instuments DSP processor - this class of systems is described as weird rather than prehistoric. I hope that Parrot might be the option for me in this project - and with my minimal (understand zero) cross-compiling experience, I still feel that going without sh and the like would be easier for me and the idea of just providing c89 functionality (and possibly a couple of more functions) is very attractive. Adam Herout
Re: No Autoconf, dammit!
On Wed, 8 Sep 2004 17:34:50 +0200, Robert Schwebel [EMAIL PROTECTED] wrote: On Wed, Sep 08, 2004 at 11:23:36AM -0400, Dan Sugalski wrote: No offense, but it *doesn't* *matter*. We're not using autoconf, as the subject of this thread makes clear. That's not negotiable. A really convincing argumentation. I suggest we institute a Rule One for Dan. (And number two, too, while we're at it.) It'd be easier that way. The autoconf argument is contentious. That's why the thread was started; to avoid the argument, as the decision has already been made. Unfortunately, that seems impossible; it's a pandora's box. -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: No Autoconf, dammit!
Herbert Snorrason wrote: I suggest we institute a Rule One for Dan. (And number two, too, while we're at it.) It'd be easier that way. Ooh, ooh, I know, I know! Rule Number One: No one wants the [interrobang if your email client or font doesn't like utf-8] Rule Number Two: Dan gets the Oh, ok. Sorry.
Re: No Autoconf, dammit!
On Wed, 08 Sep 2004 08:57:22 -0700, Gregory Keeney [EMAIL PROTECTED] wrote: Rule Number One: No one wants the [interrobang if your email client or font doesn't like utf-8] Rule Number Two: Dan gets the I was thinking more along the lines of Dan is always right and Dan is right, even if he changed his mind, but sure. Those might work too. In what context, though, I don't know... -- Schwche zeigen heit verlieren; hrte heit regieren. - Glas und Trnen, Megaherz
Re: No Autoconf, dammit!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 delurk I searched the list archives on groups.google.org to try to get more context for this discussion, but didn't come up with much that seems relevent. Can somebody point me to an old thread where Autoconf is discussed? One other thing: *) Person building runs platform-specific script If that script is going to be platform-specific anyway, why not use Autoconf for the platforms that can handle it? You'd cover a rather large number of platforms that way, and the ones you don't are going to need their own script regardless. /delurk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBPzOfbMnv87GOcv0RAgSLAJ9pH30rdHqR8mVxFuV9Q4uQJb40FwCcCS2z I3QOuGrEcHdd+3WO83x4CMQ= =Ltsg -END PGP SIGNATURE-
Current state?
[Herbert == [EMAIL PROTECTED] on Wed, 8 Sep 2004 15:18:27 +] Herbert And any way for an overeager newbie to help? The classic answer is write tests. There's thousands of code snippets that have been tossed out to the various perl6-* lists over the last few years. Many are bogus, but woven into most threads are examples of this should work real Perl6 code. Just by browsing lists archives, in a few days, you could probably write a few dozen placeholder tests. You couldn't be very confident of them, given you don't have a language implementation to test them with. But they would make great fodder for the team, and would either get morphed into final tests in the distribution, or morphed into conversations where the final syntax does get hashed out. Few things will get the syntax nailed down like throwing out erroneous test cases. Think very simple tests. Maybe 3 tests for each of the operators thus far defined. Tests to check that the unicode and plain ascii versions of operators both give the same results. Little object tests. Etc. If the first thing implemented is the grammar engine, Patrick/et al will need test code to parse. -- [EMAIL PROTECTED] One cannot mark the point without marking the path.
Re: No Autoconf, dammit!
According to Robert Schwebel: It seems to be a little bit strange to me that the ability to be compiled on prehistoric systems seems to be more important than a correct cross compiler environment. Anyone doing cross-compilation should know enough about their target environment to build a config file by hand. IMO. And yes, I *have* done cross-compilation myself. -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] Persistence in one opinion has never been considered a merit in political leaders. --Marcus Tullius Cicero
Re: No Autoconf, dammit!
On Wed, 8 Sep 2004 15:46:17 +, Herbert Snorrason [EMAIL PROTECTED] wrote: I suggest we institute a Rule One for Dan. (And number two, too, while we're at it.) It'd be easier that way. That rule already exists, but I think Dan still feels insecure about it ;) The Larry Way(tm) is to include the decision in the middle of a mind-numbing, globe trotting spew of information. That way, there are plenty of jucier tidbits to distract people. He also usually gives a one or two sentence reason, which might help here too. An example: No Autoconf because Autoconf assumes the existence of more things than Parrot can. Parrot has to build anywhere that has C89 support, but Autoconf requires sh, among other things. I don't even know if that's accurate, but in lieu of Larry's Where's Waldo Hidden Decree technique, I think there needs to be something more than because I said so to keep the natives from becoming restless :) -John
Re: No Autoconf, dammit!
At 5:34 PM +0200 9/8/04, Robert Schwebel wrote: On Wed, Sep 08, 2004 at 11:23:36AM -0400, Dan Sugalski wrote: No offense, but it *doesn't* *matter*. We're not using autoconf, as the subject of this thread makes clear. That's not negotiable. A really convincing argumentation. It wasn't an argument, though -- it was a statement of fact and intent. Someone's got to decide this stuff, and in this case it's me. (There are significant downsides to this, though, since I also get the blame/crap/browbeatings when things don't work out, amongst other things) More importantly, this is an old decision we're not going to revisit. Now, having said that, the other part of this, on cross-compilation, *is* very interesting, and needs addressing, so I will. In a different thread, so we can separate the flames. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 11:30:19AM -0500, Timm Murray wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 delurk I searched the list archives on groups.google.org to try to get more context for this discussion, but didn't come up with much that seems relevent. Can somebody point me to an old thread where Autoconf is discussed? One other thing: *) Person building runs platform-specific script If that script is going to be platform-specific anyway, why not use Autoconf for the platforms that can handle it? You'd cover a rather large number of platforms that way, and the ones you don't are going to need their own script regardless. Because the plan is to build a minimal parrot first, then use it to do the probing. The platform specific script that gets run isn't going to do any probing, so a straight generated bourne shell script will do the trick. The probing is going to *have* to get written in something that compiles down to parrot bytecode to work on the autoconf-deprived systems, so with that as a given there's no need for autoconf ahead of that. Nicholas Clark
Re: No Autoconf, dammit!
On Wed, Sep 08, 2004 at 05:41:33PM +0200, Adam Herout wrote: : For a particular project I am considering using Parrot on a custom : system based on Texas Instuments DSP processor - this class of systems : is described as weird rather than prehistoric. : I hope that Parrot might be the option for me in this project - and with : my minimal (understand zero) cross-compiling experience, I still feel : that going without sh and the like would be easier for me and the idea : of just providing c89 functionality (and possibly a couple of more : functions) is very attractive. In principle, cross-compile configuration is drop-dead easy. All you need is a database of what the probe program *would* have answered had you been able to run it on the other machine. (Getting someone to write that database entry for you is the tricky part.) You also have to be careful to separate architectural parameters from policy parameters. An architectural parameter says your integers are 32 bits. A policy parameter says you want to install the documentation in the /foo/bar/baz directory. Cross compilation has to nail down the architectural parameters while potentially deferring decisions on policy to a later installation step. An interesting question would be whether we can bootstrap a Parrot cross-compile database using autoconf's *data* without buying into the shellism of autoconf. Or give someone the tool to extract the data from the autoconf database themselves, so we don't have to ship it. Larry
Re: Current state?
On Wed, Sep 08, 2004 at 07:53:07AM -0700, Gregory Keeney wrote: Patrick R. Michaud wrote: We're in the beginning stages of building a basic perl 6 grammar engine (i.e., probably without p6 closures) that compiles to parrot and handles basic optimizations. Concurrent with that I'm working on a Perl 6 grammar. Where can one get a look at these wonderful things? tinderbox.perl.org would be my guess, but it does not seem to be working. They're not even that far along yet. :-) They should begin appearing there soon (announcements will be made to this list). Pm
Re: GC bug triggered in examples/streams?
Dan Sugalski wrote: At 4:41 PM +0200 9/8/04, Leopold Toetsch wrote: No. As layed out my scheme doesn't need any register backing stacks. If you're cloning the context every time someone pushes a register frame... that's a bit excessive. There are no register stacks, no register stack opcodes, nada. ... If you're tossing the backing stacks, that's not an option. Why? They are only used to preserve registers over function calls, which is done differently in my scheme. Err. Ehem. We already switched to an one-frame-per-chunk scheme. Which is swell, but this stuff tends to change every few months. Yes. No. The last discussion in March WRT continuations had that result. No changes every few month. It was your decision :) COWed stacks wouldn't help, AFAIK, anyway. The problem is the invalid context the continuation is holding. Nonsense. If the continuation's got a hold of a chunk of the backing stacks then those stacks aren't invalid, chunks should get reclaimed by the DOD, and shouldn't get reused until they've been reclaimed. Yep. That's the theory. We had that, when the one-frame-per-chunk stacks got introduced. The right thing to do is: #define DISABLE_RETC_RECYCLING 1 which also properly collects stack frames then. *But* this drops function calling speed by a factor of three, or it makes it about 6 times slower then Python[1]. In the presence of one Continuation created somewhere, we'd have to pay that price. That makes the interpreter unbearable slow and non-competitive. That's the reason for my alternate calling scheme proposal. BTW you didn't comment, why it's a no-go. leo [1] examples/benchmarks/fib.imc, estimated a bit because I timed it with a debug build.
Re: No Autoconf, dammit!
Larry Wall wrote: In principle, cross-compile configuration is drop-dead easy. All you need is a database of what the probe program *would* have answered had you been able to run it on the other machine. (Getting someone to write that database entry for you is the tricky part.) You also have to be careful to separate architectural parameters from policy parameters. An architectural parameter says your integers are 32 bits. A policy parameter says you want to install the documentation in the /foo/bar/baz directory. Cross compilation has to nail down the architectural parameters while potentially deferring decisions on policy to a later installation step. Easy thing. An interesting question would be whether we can bootstrap a Parrot cross-compile database using autoconf's *data* without buying into the shellism of autoconf. Or give someone the tool to extract the data from the autoconf database themselves, so we don't have to ship it. Possible thing.
Re: No Autoconf, dammit!
At 4:02 PM + 9/8/04, Herbert Snorrason wrote: On Wed, 08 Sep 2004 08:57:22 -0700, Gregory Keeney [EMAIL PROTECTED] wrote: Rule Number One: * No one wants the ? [interrobang if your email client or font doesn't like utf-8] Rule Number Two: * Dan gets the ? I was thinking more along the lines of Dan is always right and Dan is right, even if he changed his mind, but sure. Those might work too. In what context, though, I don't know... While Dan is always right has that nice ego-stroke effect, I don't think too many people would or, really, should, stand for it. We'd be better served with The designer makes the final call, for better or worse as a rule one. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
On Wed, 8 Sep 2004 12:37:52 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: While Dan is always right has that nice ego-stroke effect, I don't think too many people would or, really, should, stand for it. We'd be better served with The designer makes the final call, for better or worse as a rule one. Maybe it's just me, but I interpreted that as the meaning in Larry's version as well. For better or worse, someone eventually has to decide. Let's just have that someone defined, so we don't run into too much unneeded trouble. -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: No Autoconf, dammit!
According to Robert Schwebel: On Wed, Sep 08, 2004 at 11:23:36AM -0400, Dan Sugalski wrote: No offense, but it *doesn't* *matter*. We're not using autoconf, as the subject of this thread makes clear. That's not negotiable. A really convincing argumentation. Robert, you seem not to understand that Dan -- or anyone else actually running a project -- is not obligated to convince you. If you don't like the decisions when they're made, you have the right and privilege to take your ball and go home. The captain can be right, and the captain can be wrong, but the captain cannot be indecisive. PS: Splunge. -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] Persistence in one opinion has never been considered a merit in political leaders. --Marcus Tullius Cicero
Re: Current state?
On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote: On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote: : We're in the beginning stages of building a basic perl 6 grammar engine : (i.e., probably without p6 closures) that compiles to parrot and handles : basic optimizations. I wonder whether, in the absence of closures, we'll have to have some similar way to embed syntax-tree building code (PIR?) as actions in the grammar. We may indeed need this. I think the easiest way would be to build some sort of special-purpose assertions or rules that fire off some PIR code. Or, perhaps we can just find a way to do a funky sort of replacement whereby p6 source code gets replaced by its equivalent PIR code as soon as the compiler think it has a rule matched. Naaah, scratch that. Perhaps most of the grammar can rely on the built-up tree of $0 nodes, but we'll at least have to have an escape down into the operator precedence parser. [...]But I'm just a little scared that operator precedence will be one of those optimizations that's always the project after this one... [...] No, I'm expecting that we'll go ahead and build something to deal with operator precedence early on, at least for bootstrapping purposes. This is part of the reason why I was eager to see the precedence tables get nailed down a bit more. Pm
Re: Current state?
At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote: On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote: On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote: : We're in the beginning stages of building a basic perl 6 grammar engine : (i.e., probably without p6 closures) that compiles to parrot and handles : basic optimizations. I wonder whether, in the absence of closures, we'll have to have some similar way to embed syntax-tree building code (PIR?) as actions in the grammar. We may indeed need this. Or we could just get closures working... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current state?
- Original Message - From: Jared Rhine [EMAIL PROTECTED] Date: Wednesday, September 8, 2004 12:19 pm Subject: Current state? [Herbert == [EMAIL PROTECTED] on Wed, 8 Sep 2004 15:18:27 +] Herbert And any way for an overeager newbie to help? The classic answer is write tests. There's thousands of code snippets that have been tossed out to the various perl6-* lists over the last few years. If you want to write tests, I would say the best place to start is the A5 stuff, for two reasons: a.) Grammar/Regex tests would be really useful in testing the Grammar engine. b.) The A5 stuff is definitely the most stable part of the Perl6 design. As far as I know, it hasn't really changed much at all over the past 2 years. You could probably work directly off of A5 and S5 without having to worry if the reality is much different from the document. - Joe
Re: Current state?
- Original Message -
From: Dan Sugalski [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 1:56 pm
Subject: Re: Current state?
At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote:
On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud
wrote: : We're in the beginning stages of building a basic perl
6 grammar engine
: (i.e., probably without p6 closures) that compiles to parrot
and handles
: basic optimizations.
I wonder whether, in the absence of closures, we'll have to
have some
similar way to embed syntax-tree building code (PIR?) as
actions in
the grammar.
We may indeed need this.
Or we could just get closures working...
To get closure assertions working, you need
something that compiles the code in the
closure assertion, and so there is a bit of a
bootstrapping problem. (:
Maybe some sort of compromise/hack solution would
work, where closure assertions would be allowed but
only contain simple assignments:
rule hack {
(\d)([a-z])\2
{ $0 = $1 }
}
Re: Current state?
On Wed, Sep 08, 2004 at 02:18:38PM -0400, JOSEPH RYAN wrote: : b.) The A5 stuff is definitely the most stable part of the Perl6 : design. As far as I know, it hasn't really changed much at all over : the past 2 years. You could probably work directly off of A5 and : S5 without having to worry if the reality is much different from : the document. The main change we've made since then is that $?foo variables are scoped to the current rule, while $foo must be declared outside the rule (presuming Cuse strict). The other change we've made since then is that named rules aren't remembered as named fields unless you put a ? inside, so that after you've done /?foo ws ?bar/ there are potentially $0«foo» and $0«bar» fields, but no $0«ws». That is, the above is equivalent to /$?foo:=foo ws $?bar:=bar/ Larry
Re: Current state?
On Wed, 08 Sep 2004 14:18:38 -0400, JOSEPH RYAN [EMAIL PROTECTED] wrote: If you want to write tests, I would say the best place to start is the A5 stuff, for two reasons: a.) Grammar/Regex tests would be really useful in testing the Grammar engine. b.) The A5 stuff is definitely the most stable part of the Perl6 design. As far as I know, it hasn't really changed much at all over the past 2 years. You could probably work directly off of A5 and S5 without having to worry if the reality is much different from the document. Certainly good points. And, as stated, that'll be the first part made to run, as it's requisite for the Perl6 compiler proper. (Read: We aren't getting Perl6 until it's working.) The operators, particularly, would be a pest. The synopses are kept up to date, though, aren't they? -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: Current state?
- Original Message - From: Patrick R. Michaud [EMAIL PROTECTED] Date: Wednesday, September 8, 2004 1:21 pm Subject: Re: Current state? On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote: On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote: : We're in the beginning stages of building a basic perl 6 grammar engine : (i.e., probably without p6 closures) that compiles to parrot and handles : basic optimizations. I wonder whether, in the absence of closures, we'll have to have some similar way to embed syntax-tree building code (PIR?) as actions in the grammar. We may indeed need this. I think the easiest way would be to build some sort of special-purpose assertions or rules that fire off some PIR code. That's probably the best solution for now. Or, perhaps we can just find a way to do a funky sort of replacement whereby p6 source code gets replaced by its equivalent PIR code as soon as the compiler think it has a rule matched. Naaah, scratch that. We tried that as an optimization in the prototype Perl6 compiler. It ended up being a really really really bad idea because the grammar backtracked like a madman. It might be workable if we can infuse commit's in every location possible... - Joe
Re: Current state?
On Wed, Sep 08, 2004 at 06:37:20PM +, Herbert Snorrason wrote: : The synopses are kept up to date, though, aren't they? That's the theory, though some of them have aged a bit. Updates are in the works, along with various new synopses, including some for apocalypses that haven't been written. See Synopsis 9 in p6lang for a recent example. At the moment I'm working on S11 and S12. S4 and S9 should show up on dev.perl.org pretty soon. Larry
Re: Config parameter files
Dan Sugalski wrote: The only problem I can forsee when doing cross-compilation is in the building of the library files. Parrot itself... no big. We build miniparrot for the platform you're on, then use the config file to rebuild for the target platform. That part works out OK, but the resulting full parrot won't be runnable on the platform you're actually on, to build the library files for the platform you want. It's that library building that's the tricky bit, unless we want to use miniparrot to do all the library building. While that'll work, it'll likely be a bit limited. (Unless we do a three step deal -- build miniparrot, build parrot for your current platform, then use that parrot to build the parrot and library for your target platform) This is some weird step cousin of Canadian Cross [http://www.objsw.com/CrossGCC/FAQ-4.html#CanadianCross]. I think the three step version is required in order to get this right. You don't want to loose anything in the end libraries just to save some pain in the cross compilation. One expects the cross compilation to be mind-numbingly painful. As it is, it looks as cross-compiling parrot may be simpler than doing a canadian cross on gcc. We don't need to worry about compiling a complete suite of cross platform tools: once we have a VM and it's libraries, we are done. Gregory
Re: Current state?
On Wed, Sep 08, 2004 at 02:47:24PM -0400, JOSEPH RYAN wrote: : We tried that as an optimization in the prototype : Perl6 compiler. It ended up being a really really : really bad idea because the grammar backtracked like : a madman. It might be workable if we can infuse : commit's in every location possible... I presume you mean the lower-level backtracking controls. A commit can only cause you to fail completely, and then only if you backtrack over it. (Or are you referring specifically to efficient error recovery?) Anyway, we'll try to write the grammar to minimize (and hopefully eliminate) backtracking on any successful parse. Might have to generate some junctive parse states by hand until we can bring some yacc-like analysis tools to bear on Perl grammars. Backtracking may turn out to be quite useful for trying to figure out what they *should* have said so we can emit useful diagnostics, but we won't fall into the PL/I trap of trying to fix their program on the fly for them. So what we probably need is some commit-like thing that latches to a bogus-compile state but continues to try to parse for a while. Probably want a variant that also just throws away everything to the end of the current statement if we can't figure anything useful out by backtracking. Even if the backtracking doesn't improve the primary error message, it could usefully figure out that you were *trying* to declare something of the name foo, and maybe some of its traits, so you don't get a mess of bogus cascaded errors based on the missing declaration. But let's crawl first. Larry
Re: Current state?
At 2:35 PM -0400 9/8/04, JOSEPH RYAN wrote: - Original Message - From: Dan Sugalski [EMAIL PROTECTED] Date: Wednesday, September 8, 2004 1:56 pm Subject: Re: Current state? At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote: On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote: On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote: : We're in the beginning stages of building a basic perl 6 grammar engine : (i.e., probably without p6 closures) that compiles to parrot and handles : basic optimizations. I wonder whether, in the absence of closures, we'll have to have some similar way to embed syntax-tree building code (PIR?) as actions in the grammar. We may indeed need this. Or we could just get closures working... To get closure assertions working, you need something that compiles the code in the closure assertion, and so there is a bit of a bootstrapping problem. (: Ah, OK. I thought the problem was that parrot's closure stuff wasn't working right. (which I think it might not be :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Config parameter files
At 12:03 PM -0700 9/8/04, Gregory Keeney wrote: Dan Sugalski wrote: The only problem I can forsee when doing cross-compilation is in the building of the library files. Parrot itself... no big. We build miniparrot for the platform you're on, then use the config file to rebuild for the target platform. That part works out OK, but the resulting full parrot won't be runnable on the platform you're actually on, to build the library files for the platform you want. It's that library building that's the tricky bit, unless we want to use miniparrot to do all the library building. While that'll work, it'll likely be a bit limited. (Unless we do a three step deal -- build miniparrot, build parrot for your current platform, then use that parrot to build the parrot and library for your target platform) This is some weird step cousin of Canadian Cross [http://www.objsw.com/CrossGCC/FAQ-4.html#CanadianCross]. I think the three step version is required in order to get this right. You don't want to loose anything in the end libraries just to save some pain in the cross compilation. One expects the cross compilation to be mind-numbingly painful. As it is, it looks as cross-compiling parrot may be simpler than doing a canadian cross on gcc. We don't need to worry about compiling a complete suite of cross platform tools: once we have a VM and it's libraries, we are done. Hrm, this'd also argue that we really, really want to do alternate destinations for builds too. Besides being handy for places that want a single source tree compiled on multiple systems, it'd make the cross-compilation easier. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: more ordinal discussion
Juerd wrote: Michael Homer skribis 2004-09-08 15:54 (+1200): I think (correct me) what he's getting at here is a sparse array 1=a, 3=b, 4=c where 2nd is 'b' (the second item) but 1st+1 is undefined (there is no index 2). I don't know how well that scheme works from a comprehension point of view though, it seems a little confusing. Oh my, sparse arrays. Isn't that what we have hashes for? In theory, yes; but there are some aspects of sparse arrays that hashes simply don't capture - the most notable being that the elements of a sparse array are implicitly ordered, whereas the elements of a hash are implicitly unordered (you have to explicitly coerce them into an order whenever you want that factor). = Jonathan Dataweaver Lang __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Re: No Autoconf, dammit!
On Thursday 09 September 2004 02:40 am, Larry Wall wrote:
An interesting question would be whether we can bootstrap a Parrot
cross-compile database using autoconf's *data* without buying into the
shellism of autoconf. Or give someone the tool to extract the data
from the autoconf database themselves, so we don't have to ship it.
What autoconf database? Autoconf uses probing for cross-compilation as well.
i.e. it runs the cross-compiler and sees what succeeds and what fails. Some
things are tricky, like detecting type sizes and endianness, because you
cannot run a program to printf the answer. But there are ways around that
described in the autoconf macro archive:
http://www.gnu.org/software/ac-archive/
As an example, the size of a type can be determined by cross-compiling several
test programs that contain this:
switch (0)
{
case 0: case (sizeof ($type) == $size):;
}
where $size is iterated over 1 2 4 8 16, etc. All compilations will fail
with a duplicate case error except the size you are looking for.
Essentially, you use the cross-compiler's knowledge of the platform to act as
the database. You just need to be clever in how you format the query.
Just an FYI. It's possible that Parrot's probe system could use a similar
mechanism for cross-compilation to avoid the need for platform databases.
Cheers,
Rhys Weatherley.
Autoconf victim for 5 years now.
multiple languages clarification - newbie
Hi, newbie Can someone provide clarification on what mixing languages will look like in practice, or point me to where its explained? Can you really do this: #!/usr/bin/perl6 use __Python::sys;# whatever syntax sys.stdout.write( 'hi there');# perl6 syntax matches python syntax here, I think And this: #!/usr/bin/ponie use __Python::sys; use __Python::string; my $hi = __Python::string-upper( 'hi' ) sys-stdout-write( $hi ); # HI my $upper_func = __Python::string-upper # does this call the # function with no args (perlish) # or return it (pythonish) Please let me know if this is all wrong. I just can't visualize it. Thanks, Richard
Probing for Configurations
Rhys Weatherley wrote:
What autoconf database? Autoconf uses probing for cross-compilation as
well.
i.e. it runs the cross-compiler and sees what succeeds and what fails. Some
things are tricky, like detecting type sizes and endianness, because you
cannot run a program to printf the answer. But there are ways around that
described in the autoconf macro archive:
http://www.gnu.org/software/ac-archive/
As an example, the size of a type can be determined by cross-compiling several
test programs that contain this:
switch (0)
{
case 0: case (sizeof ($type) == $size):;
}
where $size is iterated over 1 2 4 8 16, etc. All compilations will fail
with a duplicate case error except the size you are looking for.
Essentially, you use the cross-compiler's knowledge of the platform to act as
the database. You just need to be clever in how you format the query.
Just an FYI. It's possible that Parrot's probe system could use a similar
mechanism for cross-compilation to avoid the need for platform databases.
I don't think Parrot's probe system can help us here. Autoconf (as
described above) uses the target architecture compiler's knowledge of
the target system. We don't have anything equivalent, as we want to
bootstrap the cross compiler through Parrot, not the C compiler.
Maybe we can harvest some data from gcc's target database (though I am
not sure what licensing issues may be involved) for Parrot that may be
more work than it is worth, however. I dug down in there once. It's kind
of scary.
I feel like I am missing something here, but I am not sure what
Gregory Keeney
Re: multiple languages clarification - newbie
At 11:02 PM +0100 9/8/04, Richard Jolly wrote: Hi, newbie Can someone provide clarification on what mixing languages will look like in practice, or point me to where its explained? It's not explained anywhere. Besides, it's syntax, and we don't do syntax. :) It'll likely be something like: #! /usr/bin/perl $foo = EOP for foo in range(10): print foo EOP $bar = eval $foo, Python; give or take. I doubt you'll see people mixing languages in source files that often -- more likely you'll use library modules, and those modules will be in perl 5 /perl 6/ python/ ruby/ tcl/ cola/ assembly/ forth/ postscript/ befunge/ intercal/ applescript/ whatever. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Probing for Configurations
On Thursday 09 September 2004 08:32 am, Gregory Keeney wrote: I don't think Parrot's probe system can help us here. Autoconf (as described above) uses the target architecture compiler's knowledge of the target system. We don't have anything equivalent, as we want to bootstrap the cross compiler through Parrot, not the C compiler. I suppose it depends upon what you mean by cross-compilation: (a) compiling the C parts of parrot on platform A so it can run on platform B, to JIT and run platform-independent bytecode. (b) compiling the C parts of parrot to run on platform A, but when run the parrot engine generates platform-dependent code for platform B. The autoconf thing I described helps with (a), but maybe not (b). I had assumed that you meant (a). Apologies if I was mistaken. Cheers, Rhys.
Re: Probing for Configurations
At 3:32 PM -0700 9/8/04, Gregory Keeney wrote:
Rhys Weatherley wrote:
What autoconf database? Autoconf uses probing for cross-compilation as well.
i.e. it runs the cross-compiler and sees what succeeds and what
fails. Some things are tricky, like detecting type sizes and
endianness, because you cannot run a program to printf the answer.
But there are ways around that described in the autoconf macro
archive:
http://www.gnu.org/software/ac-archive/
As an example, the size of a type can be determined by
cross-compiling several test programs that contain this:
switch (0)
{
case 0: case (sizeof ($type) == $size):;
}
where $size is iterated over 1 2 4 8 16, etc. All compilations
will fail with a duplicate case error except the size you are
looking for. Essentially, you use the cross-compiler's knowledge
of the platform to act as the database. You just need to be
clever in how you format the query.
Just an FYI. It's possible that Parrot's probe system could use a
similar mechanism for cross-compilation to avoid the need for
platform databases.
I don't think Parrot's probe system can help us here. Autoconf (as
described above) uses the target architecture compiler's knowledge
of the target system. We don't have anything equivalent, as we want
to bootstrap the cross compiler through Parrot, not the C compiler.
Right, but we'll be using the C compiler. The only way to probe for
this sort of stuff is to emit little test programs and compile them.
(Which can be problematic when cross-compiling, thought the tricks in
the archive are pretty nifty)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: multiple languages clarification - newbie
- Original Message -
From: Richard Jolly [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 6:02 pm
Subject: multiple languages clarification - newbie
Hi,
newbie
Can someone provide clarification on what mixing languages will
look
like in practice, or point me to where its explained?
I think you mean mixed language libraries/modules
rather than mixed languages (to mix languages, you'd
need to do a multi-arg eval like in Dan's example).
Using another language's module, however, would not
pay attention to the other language's syntax at all.
You would Cuse the module in your code, and
then interface with it just as if it were written in
the language that you were writing in (and not in the
language that the module was written in).
So this:
#!/usr/bin/perl6
use __Python::sys;# whatever syntax
sys.stdout.write( 'hi there');# perl6 syntax matches python
syntax
here, I think
would become this: (Apologies, I don't know Python,
well, at all, so I'll state what assumptions I make)
#!/usr/bin/perl6
use __Python::sys;
# I'm assuming that C$stdout is some sort of
# global object in the Csys namespace.
$*sys::stdout.write('hi there');
And this:
#!/usr/bin/ponie
use __Python::sys;
use __Python::string;
my $hi = __Python::string-upper( 'hi' )
sys-stdout-write( $hi ); # HI
my $upper_func = __Python::string-upper # does this call the
# function with no args
(perlish)
# or return it (pythonish)
#!/usr/bin/ponie
use __Python::sys;
use __Python::string;
use UNIVERSAL qw(can);
# here I'm assuming that C$string is a global
# object in the C__Python namespace.
my $hi = $__Python::string-upper('hi') # Hi;
my $hi_func1 = \__Python::string::upper;
my $hi_func2 = can($__Python::string,'upper');
The idea is that after compilition, everything is
just PMCs and PIR, and so everything (hopefully)
plays nice together.
- Joe
Re: multiple languages clarification - newbie
Joseph Ryan wrote:
Can someone provide clarification on what mixing languages will
look like in practice, or point me to where its explained?
delurk Warning. This is perl 7 and a half:
#!/usr/bin/perl -w
use prolog;
prolog: # prolog tells us:
needs_support_of(Db, Da):-
designer(A, Da),
designer(B, Db),
needs(A, B).
designer(perl, larry).
designer(parrot, dan).
needs(perl, parrot).
prolog. ;# or some other end-quote
for needs_support_of {
print; # prints 1st in the signature of the unification,
# predicate, 2nd .. nth in the signature of the
# match (for one member of the result).
}
__END__
/delurk
Re: multiple languages clarification - newbie
- Original Message -
From: mAsterdam [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 8:31 pm
Subject: Re: multiple languages clarification - newbie
Joseph Ryan wrote:
Can someone provide clarification on what mixing languages will
look like in practice, or point me to where its explained?
delurk Warning. This is perl 7 and a half:
#!/usr/bin/perl -w
use prolog;
prolog: # prolog tells us:
needs_support_of(Db, Da):-
designer(A, Da),
designer(B, Db),
needs(A, B).
designer(perl, larry).
designer(parrot, dan).
needs(perl, parrot).
prolog. ;# or some other end-quote
for needs_support_of {
print; # prints 1st in the signature of the unification,
# predicate, 2nd .. nth in the signature of the
# match (for one member of the result).
}
__END__
/delurk
You could do that in Perl6 (or any Parrot based language) as:
eval
needs_support_of(Db, Da):-
designer(A, Da),
designer(B, Db),
needs(A, B).
designer(perl, larry).
designer(parrot, dan).
needs(perl, parrot).
, prolog;
for needs_support_of() {
print; # prints 1st in the signature of the unification,
# predicate, 2nd .. nth in the signature of the
# match (for one member of the result).
}
Assuming, of course, that there exists a prolog-parrot compiler.
You could even have your syntax if you use a macro:
macro prolog is parsed(/
\: ([
[^p]+ ::
| !before ^^prolog\.\s*$$ p
]+)
/) {
eval($_, prolog);
}
- Joe
Re: Current state?
- Original Message - From: Larry Wall [EMAIL PROTECTED] Date: Wednesday, September 8, 2004 3:09 pm Subject: Re: Current state? On Wed, Sep 08, 2004 at 02:47:24PM -0400, JOSEPH RYAN wrote: : We tried that as an optimization in the prototype : Perl6 compiler. It ended up being a really really : really bad idea because the grammar backtracked like : a madman. It might be workable if we can infuse : commit's in every location possible... I presume you mean the lower-level backtracking controls. A commit can only cause you to fail completely, and then only if you backtrack over it. (Or are you referring specifically to efficient error recovery?) Well, I meant in the sense of Ok, since we're commiting here, we should assume that everything we've already parsed is ok (i.e., we're not going to backtrack over it). Its now ok to translate it into PIR without wasting our time. The idea was to reduce/eliminate the translation of code that might get backtracked over. - Joe
RT, closing patches
http://rt.perl.org:80/rt3//Ticket/Display.html?id=31229 Dan replied with Applied, Thanks, but the ticket wasn't marked applied. Is this some magic that could/should happen? Is there another way to invoke it? (By the time you see this, I will have manually marked it applied and resolved.)
Re: Current state?
On Wed, Sep 08, 2004 at 09:19:51AM -0700, Jared Rhine wrote: [Herbert == [EMAIL PROTECTED] on Wed, 8 Sep 2004 15:18:27 +] Herbert And any way for an overeager newbie to help? The classic answer is write tests. [...] Just by browsing lists archives, in a few days, you could probably write a few dozen placeholder tests. Indeed, and I'd say that in the immediate future we'll be wanting rules/grammar tests (to test the grammar engine) more than we'll need perl 6 code, although we'll certainly take that as well. You couldn't be very confident of them, given you don't have a language implementation to test them with. In the case of p6 rules, you can at least test them against Perl6::Rules from CPAN. Think very simple tests. Maybe 3 tests for each of the operators thus far defined. Exactly. If the first thing implemented is the grammar engine, Patrick/et al will need test code to parse. I'm sure many people on this list know this already, but it's worth pointing out to newbies that the grammar engine doesn't directly parse Perl 6; the grammar engine will parse/compile the Perl 6 grammar (still being written using perl 6 rules), and the output of *that* becomes the Perl 6 compiler (running in Parrot) which then compiles Perl 6 source code into Parrot (or PIR or AST or whatever). So, in addition to having Perl 6 code to test the compiler, we also need a good set of Perl 6 rules to test the grammar engine. :-) Pm
Re: Current state?
On Wed, Sep 08, 2004 at 02:35:21PM -0400, JOSEPH RYAN wrote: From: Dan Sugalski [EMAIL PROTECTED] Or we could just get closures working... To get closure assertions working, you need something that compiles the code in the closure assertion, and so there is a bit of a bootstrapping problem. (: Maybe some sort of compromise/hack solution would work, where closure assertions would be allowed but only contain simple assignments: Indeed, after Dan's suggestion I was thinking that we might proceed along the lines of limited closures, where we do some quick-and-dirty processing of simple closure assertions until we do have a Perl 6 compiler lying around that can handle it for us. :-) But I'd like to first get to where we're parsing rules and matching them in parrot before I dive fully into handling closures. Pm
Re: No Autoconf, dammit!
At 11:30 on 09/08/2004 CDT, Timm Murray [EMAIL PROTECTED] wrote:
*) Person building runs platform-specific script
If that script is going to be platform-specific anyway, why not use Autoconf
for the platforms that can handle it? You'd cover a rather large number of
platforms that way, and the ones you don't are going to need their own script
regardless.
It's very likely that the unix version of the platform specific script
WILL include some very minimal probing to do things like find the
compiler. But that's really all it needs to do- remember, the goal here
(as proposed) is to build miniparrot, not to build parrot. That means
you don't *need* autoconf.
The latter part of the build process, where we actually build the real
parrot, is a different issue. Dan's ruled out autoconf, so we get to
reinvent that wheel. FWIW, i'm not sure that I would have gone this
route, but dan's made a choice, and the best thing to do (IMHO) is to
follow that road and see where it leads. If it turns out to be dumb, we
move on. If it works, great.
So far, parrot's environmental probing needs really aren't terribly
sophisticated- most of the work has already been done in the current
Configure system- the test programs exist, and the mechanism to compile
and run them is well understood.
The remaining work to build the parrotconf system is mostly tedious rather
than complex. Some of the harder bits (IMHO) will revolve around
figuring out how to compile and link things, dynamic loading, and
architecture detection ($Config{archname}, osname, osvers, etc). If you
look at autoconf or metaconfig, those tasks are inevitably full of wacky
system-specific stuff. But since this is perl, porting metaconfig's units
for seting those variables to something that can run on parrot is probably
the way things will go.
It's not TERRIBLY hard but it isn't very glamorous either :) I did start
looking into converting the archname code into perl, as a starting point,
a while back. I may still have that somewhere and could probably finish
it up- my reasoning was that if I could get it from shell code into perl
code, i could understand it better and then rewrite it from scratch again
in some form that we could compile to PIR. Some sort of OOish language
with a working compiler for parrot would be nice. I'm not too keen on the
idea of maintaining nasty little probing code in assembly. :)
--Josh
Re: Probing for Configurations
Gregory Keeney wrote: Rhys Weatherley wrote: What autoconf database? Autoconf uses probing for cross-compilation as well. Essentially, you use the cross-compiler's knowledge of the platform to act as the database. You just need to be clever in how you format the query. I don't think Parrot's probe system can help us here. Autoconf (as described above) uses the target architecture compiler's knowledge of the target system. We don't have anything equivalent, as we want to bootstrap the cross compiler through Parrot, not the C compiler. Couldn't we split the probing into two phases ? Let's asume for a moment that it's easy to build a miniparrot for ethier the host or the target. The first phase would run on the host and prepare the tests and a miniparrot for the target, but not run them. The seconde phase would run on the target and run the actual test, while populating a Configuration file. Host Phase: - Build host version of miniparrot - Build target version of miniparrot (use cross compiler) - Build all probing programms and test cases (use cross-compiler) - Populate a sub-directory with target miniparrot and the remaining test programms Target Phase: - Copy that directory to the target - Run the configuration phase and get the Config file The challange would be to get the miniparrot running on the target. All the rest should be covered by the normal Parrot Configuration Probing. This is about as general as it can get, or am I missing something ? Thomas Seiler
Current state?
[Patrick == [EMAIL PROTECTED] on Wed, 8 Sep 2004 11:51:18 -0600] Patrick ...in the immediate future we'll be wanting rules/grammar Patrick tests (to test the grammar engine) more than we'll need Patrick perl 6 code, although we'll certainly take that as well. If you wanted to describe the form such tests might take, maybe Herbert will get excited enough to pitch in with such tests. I grok the difference between the grammar engine and the actual compiler, but I'm blanking on how to describe the process of writing tests that aren't simple Perl 6 code snippet style tests at this early stage. -- [EMAIL PROTECTED] We suffer primarily not from our vices or our weaknesses, but from our illusions. We are haunted, not by reality, but by those images we have put in place of reality. - Daniel J. Boorstin
Re: multiple languages clarification - newbie
- Original Message -
From: JOSEPH RYAN [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 8:58 pm
Subject: Re: multiple languages clarification - newbie
macro prolog is parsed(/
\: ([
[^p]+ ::
| !before ^^prolog\.\s*$$ p
]+)
/) {
eval($_, prolog);
}
Woops, actually, that would need to be:
macro prolog is parsed(m:w/
\: ([
[^p]+ ::
| !before ^^prolog \. ;$$ p
]+)
prolog \. ;
/) {
eval($_, prolog);
}
But, this is perl6-language stuff anyways. (:
- Joe
Re: RT, closing patches
Even if there is no special syntax, it'd be helpful if the person applying the patch fired off a Thanks, Applied or some such. Saves the bugadmins the trouble of checking the source to see if it's actually been applied or not. Will slogging through RT Coleda. William Coleda wrote: http://rt.perl.org:80/rt3//Ticket/Display.html?id=31229 Dan replied with Applied, Thanks, but the ticket wasn't marked applied. Is this some magic that could/should happen? Is there another way to invoke it? (By the time you see this, I will have manually marked it applied and resolved.)
Re: Current state?
- Original Message -
From: Jared Rhine [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 5:22 pm
Subject: Current state?
[Patrick == [EMAIL PROTECTED] on Wed, 8 Sep 2004 11:51:18 -0600]
Patrick ...in the immediate future we'll be wanting rules/grammar
Patrick tests (to test the grammar engine) more than we'll need
Patrick perl 6 code, although we'll certainly take that as well.
If you wanted to describe the form such tests might take, maybe
Herbert will get excited enough to pitch in with such tests. I grok
the difference between the grammar engine and the actual compiler, but
I'm blanking on how to describe the process of writing tests that
aren't simple Perl 6 code snippet style tests at this early stage.
Test::More with Parrot::Test would probably be good enough. For an example, take a
look at:
http://xrl.us/cy66
Except that in this case, it would just be something like:
##
# to test $0
output_is('CODE', 'OUT', Description.);
a string on which to test the pattern =~ /(pattern)/
CODE
pattern
OUT
- Joe
Re: Semantics for regexes - copy/snapshot
On Wed, 8 Sep 2004, Chip Salzenberg wrote: According to [EMAIL PROTECTED]: So how many stores do we expect for ($a = xxx) =~ s/a/b/g and which of the possible answers would be more useful? I think it depends on C($a = aaa) =~ s/a/b/g. I would agree with you in general, but since we're generally after speed, surely we want to allow for optimisations such as don't store unless something's changed; this would also be compatible with the boolean context value of s///. -Martin -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
