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 str
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:
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
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
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 d
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 =
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:
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.
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 platfor
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
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 refer
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
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
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 comman
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" pha
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 :-)
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
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 dir
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
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 userl
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. Tha
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'
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
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 consi
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 conv
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 ge
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 "Da
-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
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 con
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 in
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
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
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
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, na
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
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 alo
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" a
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 datab
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
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
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
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 plat
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
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
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. B
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
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 com
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
- 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
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),
des
- 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
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.)
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
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
- 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($_, "prolo
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.p
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,
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
58 matches
Mail list logo
