Re: cvs commit: parrot/docs/resources up.gif
On 9 Feb 2004, at 01:49, Nicholas Clark wrote: Have the LZW patents(*) expired everywhere yet google tells me there's one down and seven to go http://www.kuro5hin.org/story/2003/6/19/35919/4079 I just pinched it from parrotcode.org. Does that make me a felon? Mike
Re: cvs commit: parrot/docs/resources up.gif
On Mon, Feb 09, 2004 at 12:08:25AM -, Mike Scott wrote: > cvsuser 04/02/08 16:08:25 > > Added: docs/resources up.gif > Log: > another image for the docs > > Revision ChangesPath > 1.1 parrot/docs/resources/up.gif > > <> Have the LZW patents(*) expired everywhere yet? Nicholas Clark * Remember that those smart, diligent folks at the US Patent Office granted both the Sperry Corporation and IBM a patent on the same algorithm at about the same time.
[PATCH] Re: t/src/io failure
On Jan 26, 2004, at 2:00 AM, Leopold Toetsch wrote:
Michael Scott <[EMAIL PROTECTED]> wrote:
I see that t/src/io is now failing on OS X 10.3.2. Is anyone else
seeing this on another system?
t/src/iook 12/19# Failed test (t/src/io.t at line
395)
# got: '0
# 0
# 0
# '
# expected: '0
# 6
# 6
# '
Does OS X use io_unix.c or io_stdio.c? Can you debug/trace/strace the
code?
Ah, it turns out to be a simple fix. The return value of PIO_tell() is
PIOOFF_T, which ends up being a long long on Mac OS X, and the "%d"
format is only printing out the first word of the return value. The
easiest fix, for the purpose of the test, is just to cast the return
value to an int. (A format string of "%lld" also works, but PIOOFF_T is
just a long on some platforms, so the cast is the most portable fix.)
Patch below.
JEff
Index: t/src/io.t
===
RCS file: /cvs/public/parrot/t/src/io.t,v
retrieving revision 1.10
diff -u -r1.10 io.t
--- t/src/io.t 25 Jan 2004 10:42:38 - 1.10
+++ t/src/io.t 9 Feb 2004 00:36:22 -
@@ -409,11 +409,11 @@
buf = malloc(65536 * sizeof(char));
-printf("%d\n", PIO_tell(interpreter, io));
+printf("%d\n", (int)PIO_tell(interpreter, io));
PIO_read(interpreter, io, buf, 6);
-printf("%d\n", PIO_tell(interpreter, io));
+printf("%d\n", (int)PIO_tell(interpreter, io));
PIO_read(interpreter, io, buf, 65535);
-printf("%d\n", PIO_tell(interpreter, io));
+printf("%d\n", (int)PIO_tell(interpreter, io));
return NULL;
}
Re: Keyed Access to UnManagedStruct?
Chromatic <[EMAIL PROTECTED]> wrote: > Hi there, > What's the best way to access fields within an UnManagedStruct, one > returned from an NCI call? For example, if I call _new_SDL_Screen, how > can I access the w and h fields of the SDL_Surface it returns? > I've tried creating an OrderedHash called layout and then doing: > set screen, layout Above statement just aliases both P-registers to point to the same thing, _new_SDL_screen has a return type of 'p' - that is an UnManagedStruct pointing to that. You know, that the return type is a struct screen *. So you create an initializer for that struct (above layout? - a bad name BTW) and *assign* it to the screen: assign screen, screen_struct_layout w = screen["w"] # presumed your struct initializer defines that s. docs/pmcs/struct.pod > ... I can provide more code if necessary. If its still not clear, yes please. > -- c leo
Keyed Access to UnManagedStruct?
Hi there, What's the best way to access fields within an UnManagedStruct, one returned from an NCI call? For example, if I call _new_SDL_Screen, how can I access the w and h fields of the SDL_Surface it returns? I've tried creating an OrderedHash called layout and then doing: set screen, layout Is there a better way? I can provide more code if necessary. -- c
Re: cvs commit: parrot/classes perlscalar.pmc
Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > From: "Leopold Toetsch" <[EMAIL PROTECTED]> >> That isn't necessary. One rmb() after resetting C ought to be >> enough. It ensures that in all cases the other CPU reads str_val as >> NULL. If the vtable is still pointing to the PerlInt vtable, its a user > Having an only rmb() on the writing CPU hardly assures that. > http://lse.sourceforge.net/locking/wmbdd.html Seems that we got a problem on alphas then. I can see several solutions to accomodate such CPUs: - use only PMCs that don't cross cache lines - insert rmb_if_needed() for all string vtables that don't lock - lock all string vtable access - move string pointer into PMC_EXT > 0x4C56 Thanks for the pointer, leo
