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
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 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 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
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
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
Something about
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
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
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 mean by a
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
global
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,
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 top
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 more
13 matches
Mail list logo
