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: 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: 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: 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: 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 C 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 lex&yacc 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: 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: 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: 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... -- SchwÃche zeigen heiÃt verlieren; hÃrte heiÃt regieren. - "Glas und TrÃnen", Megaherz
Re: No Autoconf, dammit!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBPzOfbMnv87GOcv0RAgSLAJ9pH30rdHqR8mVxFuV9Q4uQJb40FwCcCS2z I3QOuGrEcHdd+3WO83x4CMQ= =Ltsg -END PGP SIGNATURE-
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 > > > > 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: 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!
Larry, On Wed, Sep 08, 2004 at 09:40:44AM -0700, 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. Sounds perfectly fine. Is there a place in the current parrot code where this information is already available? I could try to provide the necessary bits for ARM to have a proof of concept. 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
Config parameter files
Okay, now that we've gotten past the autoconf thing, time to tackle the cross-compilation thing, as well as the "what exactly did I choose last time when I built this stuff" thing. It seems to me that the sensible thing to do is take the environment probing in two steps. Step 1: We probe, and build a config file (not config.h, mind) with our results. Step 2: We take the config file and build config.h and choose (or build) the right platform.h/platform.c file. Step 3: We build the appropriate platform-specific library files, if there are any. In a cross-compilation scenario, we'd skip step 1 and instead get handed a fully filled-in config file (So it'd be in our best interests to make it sane and easy to figure out) and skip the probing. It's also really handy to feed an old build's config file into a new build so the defaults feed forward. 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) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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: 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: 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: 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, 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, 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 = < 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,
>
>
>
> 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 C 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 C 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?
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__
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?
>
> 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__
>
>
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]>+ ::
| p
]+)
/) {
eval($_, "prolog");
}
- 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: 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
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]>+ ::
> | p
> ]+)
>/) {
>eval($_, "prolog");
>}
Woops, actually, that would need to be:
macro prolog is parsed(m:w/
\: ([
<[^p]>+ ::
| 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: 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.
Re: Semantics for regexes - copy/snapshot
On Sep-09, [EMAIL PROTECTED] wrote: > 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///. I vote for leaving all of these sorts of cases undefined. Well, partially defined -- I'd rather we didn't allow ($a = "aaa") =~ s/a/b/g to turn $a into "gawrsh". At the very least, define the exact number of output and stores for "strict aka slow mode", but have an optional optimization flag that explicitly drops those guarantees. It would allow for more flexibility in implementations.
