On Mon Nov 08 19:57:18 2004, coke wrote:
> I was talking with Dan on IRC about what we're going to do as a
> replacement for macros. Talk turned to implementing a registered
> 'compile'r for "pre parsed PIR".
>
> For this to be useful, of course, we'd need to be able to run it from
> the command l
Robert has implemented this change on the smokeserver, which is now
displaying smoke report times in UTC as the home page has always claimed
to do. Resolving ticket.
Just a note: snprintf is problematic on older Solaris systems (x86 anyway),
for one. At least through 2.7 (2.8?) it's no included in any lib. So
other apps needed to test and bring in their own version.
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932
On Tuesday 05 February 2008 11:36:00 Andy Lester wrote:
> Ignoring the length
> parameter leaves those platforms without snprintf() exactly where they
> are today.
... the PIT of VILE DESPAIR!
When the inevitable revolution comes, I'm going to put their maintainers up
against the wall and f
On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote:
(He sent this to me directly by mistake)
snprintf is problematic on older Solaris systems, for one. At least
through 2.7 (2.8?) it's not included in any lib. So other apps
needed to
test and bring in their own version.
This is covered
On Feb 5, 2008 11:08 AM, Andy Lester <[EMAIL PROTECTED]> wrote:
> Constructions like this give me the willies:
>
>char * const buf = (char *)mem_sys_allocate(16);
>sprintf(buf, "%d", type);
>
i saw this code the other day, and thought, "gee, malloc's just gonna
grab 64 anyway. that's silly.
Constructions like this give me the willies:
char * const buf = (char *)mem_sys_allocate(16);
sprintf(buf, "%d", type);
Yes, I know that 16 characters is more than enough, but I still don't
like it. I'd prefer it if we were using instead
snprintf(buf, 16, "%d", type);
I suspect there
I had removed the PARROT_API from ld() in list.c because we don't need
to offer as a public function to the user a function that computes
logs base 2. fperrad reverted that because it broke "make hello".
It seems to me that this is backwards, just like my PARROT_APIing some
other something
On Wed Aug 16 23:09:16 2006, mdiep wrote:
> I don't know how to write a test for this off the top of my head, but
> Iterator and DynLexPad don't play well together atm. When I tried, I
> got this error:
>
> elements() not implemented in class 'DynLexPad'
>
> Is there an easy way to make