On 21 August 2013 19:19, wrote:
> Rob Pike writes:
>
> OK. How does one match the start/end of dot in a g// or v// regexp?
>
>
... seems like a good question to me
Steve Simon in his Sam command reference card also uses ^ and $
for his TODAY example, so this might actually be wrong.
Ruda
#include
#include
void
f(void)
{
write(1, "hello\n", 6);
}
void (*call)(void) = f;
void
main(void)
{
call();
exits("");
}
the asm is the same when compiled on any arch,
; acid 6.crash4-mips
6.crash4-mips:amd64 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/amd64
a
On 21 August 2013 22:14, Rudolf Sykora wrote:
> I think the pattern in g must match the dot entirely...
Well, sorry, having checked the paper, this is not true.
Ruda
On 21 August 2013 07:11, wrote:
>
> Maybe someone here can help me make sense of this simple sam session:
>
> ,c
> this is a file, one of
> many files with singular
> and/or plurals
> .
> ,y/ / g/.+s$/ p
> plurals
>
> I would expect that to have responded with "thisfilesplurals".
,y/ / g/.+s/ p
> How %p is treated is really upto the implementation but
> it should not crash since p is never dereferenced. Does
> this work?
>
> uintptr q;
> print("%p", q);
no. if i change the print to print an integer, it still fails.
in fact, it's really the indirect call in print that fails
On Aug 21, 2013, at 11:57 AM, erik quanstrom wrote:
>> You're casting a large int into a small int and this seems right.
>> Just as (uchar)0x1234 => 0x34
>>
>>> marshalling a 64-bit pointer in this way will lay down the
>>> bytes with the hi and lo reversed.
>>
>> Perhaps you meant to do *(uch
> You're casting a large int into a small int and this seems right.
> Just as (uchar)0x1234 => 0x34
>
> > marshalling a 64-bit pointer in this way will lay down the
> > bytes with the hi and lo reversed.
>
> Perhaps you meant to do *(uchar*)&x?
you're right. what was i thinking. still, pointer
On Wed, 21 Aug 2013 14:36:40 EDT erik quanstrom wrote:
> uvlong x;
>
> x = 0x012345678abcdefull;
> print("(uchar)x %.2ux\n", (uchar)x);
...
> x = 0012345678abcdef
> (uchar)x ef
You're casting a large int into a small int and this seems right.
Just as (uchar)0x1234 => 0x34
vc vlongs are broken for cast
for example, _v2uc produces the code:
acid; asm(_v2uc)
_v2uc 0x5360MOVWrv+8(FP),R1
_v2uc+0x4 0x5364JMP (R31)
_v2uc+0x8 0x5368AND $0xff,R1
i think this should be
MOVWrv+12(FP),R1
JMP (R31)
AND
On Wed Aug 21 14:23:48 EDT 2013, lu...@proxima.alt.za wrote:
> > what i mean is, the need for fixing it depends on how much
> > havoc this issue causes.
>
> Well, there is also the question of whether anything at all will break
> if the bug is fixed. If not, then the answer is simple.
fortunatel
I think that if there is a generally-accepted standard for the behaviour of
a language's handling of floating-point numbers,
it would be reasonable to try to follow the standard, unless it's stupid,
ill-advised, or impossible (or all three).
That reply to the Stack Overflow post -- and this might b
> what i mean is, the need for fixing it depends on how much
> havoc this issue causes.
Well, there is also the question of whether anything at all will break
if the bug is fixed. If not, then the answer is simple.
++L
> by "this" i ment to refer to -0.
But the subject line says "comparisons with NaN". Start another
thread about signed zero if you like. (I'm not facing a test
suite objecting to those at the moment.)
> On Wed Aug 21 13:43:54 EDT 2013, ba...@bitblocks.com wrote:
>> On Aug 21, 2013, at 9:55 AM, erik quanstrom wrote:
>>
>>> On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone n
On Wed Aug 21 13:43:54 EDT 2013, ba...@bitblocks.com wrote:
> On Aug 21, 2013, at 9:55 AM, erik quanstrom wrote:
>
> > On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
> >>> at least in terms of passing floating point test suites
> >>> (like python's) the NaN issue doesn't come up
> >>
On Aug 21, 2013, at 9:55 AM, erik quanstrom wrote:
> On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
>>> at least in terms of passing floating point test suites
>>> (like python's) the NaN issue doesn't come up
>>
>> Actually it was a test suite that revealed the NaN errors.
>> I woul
Rob Pike writes:
> Nothing. That's exactly what ^ and $ do.
>
OK. How does one match the start/end of dot in a g// or v// regexp?
> -rob
>
Wait, Rob Pike? That "Rob Pike?" As in the guy who wrote the program?
How fortuitous. :)
I read your paper on sam, as well as the tutorial, and I unde
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
> > at least in terms of passing floating point test suites
> > (like python's) the NaN issue doesn't come up
>
> Actually it was a test suite that revealed the NaN errors.
> I wouldn't think it's something anyone needs in normal
> day-to-
> at least in terms of passing floating point test suites
> (like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone needs in normal
day-to-day computation, but sometimes boxes must be ticked.
> how about another option, just a bug.
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
- erik
amd64 does yet something else.
amd64 (a == b) (a >= b) (a > b) (b == a) (b >= a) (b > a)
386 (a < b) (a <= b) (a == b) (b < a) (b <= a) (b == a)
arm (a < b) (a <= b) (a != b) (b < a) (b <= a) (b != a)
mips(a < b) (a <= b) (a != b) (b < a) (b <= a) (b != a)
> mainly the assumption, i
The Plan 9 C compilers do not appear to be compliant with the IEEE floating
point standard when making comparisons with NaN (not a number) values.
The standard says a comparison with one or both operands NaN is "unordered",
ie all relations evaluate to false, except != which is always true.
Testi
22 matches
Mail list logo
