Pete Lomax writes:
> There's no file level locals yet either ;-)
>
> Can I ask a stupid question? Guess I'm going to anyway...
>
> Is there much benefit to .const, over sticking a value in a register
> and not modifying it? (which is what I've done to get round this)
Yes. First, if you want mor
On Tue, 9 Dec 2003 16:20:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Just ran across a bug in IMCC.
>
>The .const directive is incorrectly available only within a .sub/.end
>block. Silly. (And wrong) That makes it very difficult to usefully
>use constants--generally they're defined at the
At 8:12 PM + 12/6/03, harry wrote:
Dan Sugalski wrote:
I was mostly thinking that some step or other in the Makefile has a
dependency on that file, and some other step creates it, but the
dependency's not explicit. I'd like to find the step(s) that require it
and make it a dependency for them,
At 07:58 AM 12/10/2003 +0300, Vladimir Lipsky wrote:
From: "Melvin Smith" <[EMAIL PROTECTED]>
> At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote:
> >which is .included) and visible through the rest of the compilation unit.
> >
> Parser will not allow .const outside of a compilation unit and make it
From: "Melvin Smith" <[EMAIL PROTECTED]>
> At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote:
> >which is .included) and visible through the rest of the compilation unit.
> >
> Parser will not allow .const outside of a compilation unit and make it
> global to the
> compilation.
Hmm... What do you
At 10:04 PM 12/9/2003 -0500, Melvin Smith wrote:
AWhen someone gets a chance to patch this one up, I'd much appreciate it.
Fixed.
Parser will not allow .const outside of a compilation unit and make it
global to the
compilation. .const inside a .sub will be local to the sub only (no change
there
At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote:
Just ran across a bug in IMCC.
The .const directive is incorrectly available only within a .sub/.end
block. Silly. (And wrong) That makes it very difficult to usefully use
constants--generally they're defined at the top of a file (or in a file
wh
At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1["Foo\x00i"] # I1 == I2
gets currently the attribute idx (0) of "$Foo::i".
Q: Should the assembler mangle the "Foo::i" to "Foo\0i"
Someth
Just ran across a bug in IMCC.
The .const directive is incorrectly available only within a .sub/.end
block. Silly. (And wrong) That makes it very difficult to usefully
use constants--generally they're defined at the top of a file (or in
a file which is .included) and visible through the rest of
At 12:40 PM -0500 12/9/03, Melvin Smith wrote:
At 11:52 AM 12/9/2003 -0500, Dan Sugalski wrote:
may not branch to OK. (There's no requirement that high-level
comparisons >require a PMC to be equal to itself)
Although committing such a confusing PMC to Parrot is certainly questionable.
I'm not argu
At 11:52 AM 12/9/2003 -0500, Dan Sugalski wrote:
>may not branch to OK. (There's no requirement that high-level
comparisons >require a PMC to be equal to itself)
Although committing such a confusing PMC to Parrot is certainly questionable.
-Melvin
At 9:12 PM + 12/8/03, Pete Lomax wrote:
On Mon, 8 Dec 2003 11:35:59 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Unqualified eq/cmp/lt are OK for two PMC operations,
I'm not convinced at all here. PMC comparison ops, afaict, are based
solely on the pmc instance/address
Well... no.
Here's a
At 4:36 PM -0500 12/8/03, Gordon Henriksen wrote:
On Monday, December 8, 2003, at 10:03 , Dan Sugalski wrote:
At 1:21 PM -0500 12/3/03, Melvin Smith wrote:
We should have 1 recommended way for testing NULL registers.
If we support get_bool() then lets make sure it works for REAL NULL
pmc registe
13 matches
Mail list logo
