Re: Monthly Release Schedule

2005-04-07 Thread Bryan C. Warnock
won't be much pure 32-bit left after too long.) The Solaris environment is probably secondary - Solaris headers, paths, tools, compilers, etc. - but it doesn't necessarily matter whether it's SPARC-based or not. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

RE: Bit ops on strings

2004-05-01 Thread Bryan C. Warnock
well. (And may well argue for MMD on string operations, > but I think that makes my head hurt so I'm not going there righ tnow) Good 'nuff. Thanks, -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

RE: Bit ops on strings

2004-05-01 Thread Bryan C. Warnock
e semantics are found in Layers 2 and 3. (Layer 3 could also be merged.) Now I think that's more less what Parrot has, right? Except that the Layer 2 semantics are tracked (and locked in?) at Layer 1? (To prevent the aforementioned bit-shifting of WTF strings.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Bit ops on strings

2004-04-30 Thread Bryan C. Warnock
. Have we[1] finished working out what a string is yet? [1] And by "we", I mean "you"[2]. [2] And by "you", I mean "you" plural. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Strings Manifesto

2004-04-28 Thread Bryan C. Warnock
{snipped, obviously} Hmmm... very good. One question. Does (that which the masses normally refer to as) binary data fall inside or outside the scope of a string? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: One change to the strings document

2004-04-26 Thread Bryan C. Warnock
On Mon, 2004-04-26 at 08:12, Dan Sugalski wrote: > At 9:34 PM -0400 4/25/04, Bryan C. Warnock wrote: > >On Sun, 2004-04-25 at 16:34, Dan Sugalski wrote: > >> Just a heads up, there are two things that have been pointed out. > >> > >> First, the transset op is

Re: One change to the strings document

2004-04-26 Thread Bryan C. Warnock
pefully using a different word'll help people remember that > glyph!=codepoint, though we'll see how well that one works. I don't understand. Substitute grapheme for character, as you're staying away from glyphs, but "getglyph" for "getcharacter"? An

Re: Korean character set info

2004-04-25 Thread Bryan C. Warnock
On Thu, 2004-04-22 at 12:18, Jeff Clites wrote: > Unicode is an actively evolving standard. It's far from legacy. On Thu, 2004-04-22 at 15:07, George R wrote: > I don't agree with the Unicode legacy comment... :-( Creating tomorrow's legacy today. :-) -- Brya

Re: patching Changelog

2004-04-09 Thread Bryan C. Warnock
ection of my previously posted patch.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

[perl #28383] [PATCH] Update WHOIS... er, WHOWAS, info

2004-04-09 Thread Bryan C. Warnock
# New Ticket Created by "Bryan C. Warnock" # Please include the string: [perl #28383] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=28383 > The email address of record has only been defunct for a year and

patching Changelog

2004-04-08 Thread Bryan C. Warnock
a) Is the ChangeLog autogenned? b) Is it kosher/proper to update email references in it? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Happy Anniversary, Parrot

2003-09-11 Thread Bryan C. Warnock
Has it been two years already? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Make mine SuperSized....

2003-06-09 Thread Bryan C. Warnock
d be wasteful/costly to save them. And it's this sort of rumination that made me think that this is all just false economics. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Make mine SuperSized....

2003-06-09 Thread Bryan C. Warnock
ated in the thread - for a new register type (L, long). > > They have the same relation as 32bit ints and 64 bit longs, with the > difference that we guarantee at least these sizes. I'm not an actor, nor do I play one on TV. That being said, if you can handle making Parrot keep

Re: Make mine SuperSized....

2003-06-09 Thread Bryan C. Warnock
? [1] Of course, you know there *has* to be an exception. Currently, Parrot internally provides some direct support routines explicitly for INTVALs, namely stringification as part of the various *printf routines. I consider those type of routines more of an "op support library" than Parrot internals. (Functionally, although certainly not lexically, as it currently stands.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Make mine SuperSized....

2003-06-03 Thread Bryan C. Warnock
On Tue, 2003-06-03 at 03:54, Henrik Tougaard wrote: > On Sat, May 31, 2003 at 09:54:45AM -0400, Bryan C. Warnock wrote: > [snip] Part of what was snipped was this line: (For the sake of using real numbers, I'll assume 32/64.) > > Currently, the flow is,

Re: Make mine SuperSized....

2003-06-02 Thread Bryan C. Warnock
On Sun, 2003-06-01 at 10:08, Gopal V wrote: > If memory serves me right, Bryan C. Warnock wrote: > > > No .. to add large numbers very quickly ... ie split registers and > > > enemies ;-) > > > > Understood. My point was that - to parallel virtual machines with

Re: [perl #22386] [PATCH] Make .constant constantly .const

2003-06-01 Thread Bryan C. Warnock
On Sat, 2003-05-31 at 09:57, Bryan C. Warnock wrote: > On Sat, 2003-05-31 at 09:53, Leopold Toetsch wrote: > > Bryan C. Warnock <[EMAIL PROTECTED]> wrote: > > > > > As mentioned previously. Makes IMCC and PASM constant keywords > > > consistent, with &#x

Re: Make mine SuperSized....

2003-06-01 Thread Bryan C. Warnock
On Sat, 2003-05-31 at 11:43, Leopold Toetsch wrote: > Bryan C. Warnock <[EMAIL PROTECTED]> wrote: > > > The flow *really* is, in value sizes: > > > Opcodes: 32 (constants are limited by the spec) > > In which spec? How would we handle 64 bit INT

Re: Make mine SuperSized....

2003-06-01 Thread Bryan C. Warnock
On Sat, 2003-05-31 at 11:15, Gopal V wrote: > If memory serves me right, Bryan C. Warnock wrote: > > Not to mention all the *other* problems we'll have if we've got more > > than 2^31 different opcodes. (Although that's why there's UUIDs now, > > isn&

Re: [perl #22386] [PATCH] Make .constant constantly .const

2003-06-01 Thread Bryan C. Warnock
On Sat, 2003-05-31 at 09:53, Leopold Toetsch wrote: > Bryan C. Warnock <[EMAIL PROTECTED]> wrote: > > > As mentioned previously. Makes IMCC and PASM constant keywords > > consistent, with '.const'. > > As mentioned previously ;-) this doesn't work

Make mine SuperSized....

2003-06-01 Thread Bryan C. Warnock
f what facilities are available to them, if they so choose. But what of inter-language operability? Will the registers become the crossroads for data conversions between PMCs from difference languages? It doesn't look that way, from the direction that PMCs have gone. Can we simplify interpreter types this much, while still providing extended numerics to hosted languages? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

[perl #22386] [PATCH] Make .constant constantly .const

2003-05-31 Thread Bryan C. Warnock
# New Ticket Created by "Bryan C. Warnock" # Please include the string: [perl #22386] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=22386 > As mentioned previously. Makes IMCC and PASM constant keywords con

Re: Register access

2003-05-31 Thread Bryan C. Warnock
tring_reg.registers[0] = $2; > > No? No. Ha ha, just kidding, of course. I'm all for it, but given my record today, that might be an imminent sign of its rejection. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: IMCC, PASM and constants/macros

2003-05-29 Thread Bryan C. Warnock
On Wed, 2003-05-28 at 11:13, Clinton A. Pierce wrote: > > > >Is there is reason not to s/\.constant/.const/g for consistency's sake? > > And actually, on further consideration, .const isn't what I want > either. Which doesn't invalidate my question.

Re: [perl #22352] PackFile imcc bug

2003-05-29 Thread Bryan C. Warnock
hat someone really is using Parrot in some sort of production mode and schlepping around old PBC files, a standalone format converter would be a nice add-on. Perhaps even based on the add-on Perl-based PBC thingy above. It's way to early to get wrapped up in Parrot's own legacy. -- Bryan C

Re: IMCC, PASM and constants/macros

2003-05-27 Thread Bryan C. Warnock
> It was, but I was looking for the "why" of it. Leo answered that ("IMCC > has .const") so I'm all set now. Is there is reason not to s/\.constant/.const/g for consistency's sake? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: [perl #20597] [PATCH] packfile #6

2003-02-04 Thread Bryan C. Warnock
] An old packfile proposal for supported formats. http:[EMAIL PROTECTED]/msg06918.html [3] Or, how well it does what it should do. I don't think anyone's really addressed how much work to commit to such a thing. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: [CVS ci] packfile #2

2003-01-29 Thread Bryan C. Warnock
yte IEEE doubles. > > This doesn't feel like a good idea. It may be the only practical solution, > but I doesn't mean that I have to like it. Let me dig through my notes. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

RE: [CVS ci] packfile #2

2003-01-29 Thread Bryan C. Warnock
6 bytes Actually, Quads aren't standard. 'long doubles' and the ilk are double extended, and require at least 10 bytes. (Which, coincidentally, is the size of the x86 fp registers.) In memory, they're padded to 12 or 16 bytes to preserve word boundaries. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: C#/Parrot Status

2002-11-25 Thread Bryan C. Warnock
On Mon, 2002-11-25 at 11:04, Nicholas Clark wrote: > Is there any speed advantage in truncating by casting via a C type > [eg a = (int)(short) b] > rather than and on a bitmask > [eg a = b & 0x] > ? > > We're going to have to do that latter to make it work on C

Re: [perl x18078] Patty's login stuff

2002-10-25 Thread Bryan C. Warnock
AM_PHRASE_00_01,TO_EMPTY > version=2.41 > > -R (pondering his next move in the unending war against spam) Nukes. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: 64-bit ints and non-capable hardware

2002-10-21 Thread Bryan C. Warnock
7;t be affected, although user-space values will be. But you can convert to BigInt at 32 bits vice 64. (Assuming that's still the plan.) [1] In My Humble And Oft-Stated But Rarely Patching Opinion ;) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: C# and Parrot

2002-10-20 Thread Bryan C. Warnock
T (and JVM) doe for floating point numbers? Are we still targeting a middle ground for C? (Enough to be able to parse and handle structs natively, and possibly even make calls natively?) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: the getting started guide

2002-10-19 Thread Bryan C. Warnock
the recipients to the list and the person I'm replying to unless there's a noticeable ongoing conversation between multiple people. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Teasing notes

2002-09-05 Thread Bryan C. Warnock
le) 2) How big is *too* big (for the heirarchical vtable) 3) Ops that can't/won't fit are done as a sub call, right? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

RE: Parrot long-term goals/prospects

2002-09-05 Thread Bryan C. Warnock
uilt. To test Parrot, type 'miniparrot > build.pbc test' Ohhh. and you were doing so well! :-) "You want I should test it out? [y]" > at a command prompt; to install it, type 'miniparrot build.pbc > install'. "Are you satisfied enough for me to install it now? Please? Pretty please? [y]" (Or, in the instance of [n]s, "Okay, you can always (test|install) it later by running $command.") Beyond that, I like this glimpse of the future. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Parrot: maximizing the audience

2002-09-04 Thread Bryan C. Warnock
, at the expense of effort by the Perl folks, but there's no guarantee that those people will come. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Parrot: maximizing the audience

2002-09-03 Thread Bryan C. Warnock
s are eyeing us, it's not clear that the amount of work to obliterate that line is going to be worth the cost. If there are going to be changes made, they'll most likely be made incrementally, which, of course, means that by the time the last changes are made, there will be even more to rip

Re: IRIX64 alignment problem

2002-08-31 Thread Bryan C. Warnock
il of a previous allocation, and b) you're going to be wasting some of that space anyway in order to align to the stricter requirements, even when you need to. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Mode a la mode

2002-08-27 Thread Bryan C. Warnock
er.pl ../t/op/debuginfo.t ../t/op/hacks.t ../t/op/interp.t ../t/op/gc.t ../t/op/trans.t -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

[PATCH] POD TITLE blocks

2002-08-26 Thread Bryan C. Warnock
www.parrotcode.org/docs seems to like them, so here they are. This rolls in the byteorder.dev patch previously submitted. (I see in the patch that we're not consistent with what a line ending should be. I've left that alone.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.co

[PATCH?] File deletion

2002-08-26 Thread Bryan C. Warnock
How does one patch a file to delete? docs/a5_draft.html can go away now, thank you for playing. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

[PATCH] byteorder.dev

2002-08-26 Thread Bryan C. Warnock
of things I won't get to.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com) Index: byteorder.dev === RCS file: /cvs/public/parrot/docs/dev/byteorder.dev,v retrieving revision 1.1 diff -u -r1.1 byteorder.dev --- byteorder.

[PATCH] glossary.pod

2002-08-25 Thread Bryan C. Warnock
d2 Warnock's Dillemma +=head2 Warnock's Dilemma -The dillemma you face when posting a message to a public forum about -something and not even getting an acknowledgement of its +The dilemma you face when posting a message to a public forum about +something and not even getting an acknowledgment of its existence. This leaves you wondering if your problem is unimportant or previously addressed, if everyone's waiting on someone else to answer you, or if maybe your mail never actually made it to anyone else in -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

RE: [DRAFT PPD] External Data Interfaces

2002-08-20 Thread Bryan C. Warnock
On Sun, 2002-08-18 at 18:53, Brent Dax wrote: > # And do we need a RFC like definition of should/may/must/mustn't? > > If so, I'd suggest the definition be patched into PDD0, so it's shared > by all PDDs instead of repeating the definitions everywhere. Noted. --

Re: PARROT QUESTIONS: The PDDs

2002-08-04 Thread Bryan C. Warnock
MAIL PROTECTED]/msg08677.html http:[EMAIL PROTECTED]/msg08678.html As you can see, I was dilemma'd about it, too. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

Re: Stacks, stacks, stacks (And frames)

2002-06-11 Thread Bryan C. Warnock
May? That hardly makes that an assumption. :-) > 3) Subs we call might really be coroutines > 4) We want to be fast Is there (as I don't know) anything else in Perl (Parrot?) that is implemented in terms of coroutines or continuations? Or is the only functional programming support

Re: ICU and Parrot

2002-05-30 Thread Bryan C. Warnock
tly does that mean? When I first read this, I thought, "Well, duh! If C++ is a requirement, then anyone wanting to interact with ICU will have a C++ compiler. If they didn't have one, they wouldn't use it." Or do you mean that ICU simply hasn't been approached (oft

Re: Bytecode format redesign

2002-05-13 Thread Bryan C. Warnock
I told Dan awhile ago that I wanted to borrow a page from the PNG folks, he said, "What? We're going to have code with an alpha channel?" :-) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

RE: Subroutines...

2002-05-11 Thread Bryan C. Warnock
eptember in re sub and method prototyping. The thread starts here: http:[EMAIL PROTECTED]/msg08182.html -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

Re: entrytype OP is broken?

2002-05-11 Thread Bryan C. Warnock
On Mon, 2002-04-29 at 11:04, Ilya Martynov wrote: {snip} Has this question and patch been addressed? -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

Re: Bytecode format redesign

2002-05-11 Thread Bryan C. Warnock
teresting idea of the opcode_type, where we store > the flavor of the opcode, whether it is Perl, or transformed opcodes from > another VM (Java, Python, .NET). Might make for some interesting discussion, > especially given Leon Brocard's JVM experimentation. The PBC metadata should indicate the source language and compiler, for sure. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

Re: Bytecode storage of floats

2002-05-11 Thread Bryan C. Warnock
so I'd appreciate anything you wish > to contribute. If its code you have and you want it used, you can > shoot it to me and I'll try to integrate, and credit you of course; > otherwise, I'm going to keep moving forward I hope. I'll post non-code first. (I've legal issues that haven't been hammered out yet. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

Re: Many problems with 'long long' INTVALS

2002-05-11 Thread Bryan C. Warnock
t opcode_t to be the same size as INTVAL in that case. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

Re: Internal integral types

2002-05-11 Thread Bryan C. Warnock
rnal exceptions, or you're going to need to resort to all opcodes dealing solely with PMCs. (That's actually how Parrot was originally designed - the INS registers were *only* for the internals' use, and not for general opcode use.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)

Re: [PATCH] Disable GC at startup

2002-04-12 Thread Bryan C. Warnock
rring to the pathetic situation where initialization really would run out of memory. (Not simply fill up the initial allocation buffer, but is unable to allocate any more memory from the system.) Going back and DOD/GC may then give you enough room to finish initialization, but probably not enough to do anything useful, so I don't see that as a reason to run GC then, either. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Disable GC at startup

2002-04-12 Thread Bryan C. Warnock
ms a collection run, and > tries again. If not, it tries allocationg a new block of memory, and > returns that. If that fails, it gives up. I thought the point of the discussion was turning off the GC until such time that it was ready to go. I know what it *does* - what should it *do*? {Rest of the comments snipped.} -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Disable GC at startup

2002-04-11 Thread Bryan C. Warnock
ory allocator and the GC subsystem. If it needs more memory to do so, it should simply be given more memory. After the GC is up and running, the interpreter/bootstrapping process can trigger a GC run to free up as much memory as it can. The remainder of the interpreter can then start up, running through the GC. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Patches, patches, patches...

2002-04-10 Thread Bryan C. Warnock
x27;t know when. It could have been applied recently.) Did I sneak one in somewhere else that I can't find? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-04 Thread Bryan C. Warnock
#x27;t know. In order to stay within (or resize) the allocated buffer, you either have to peek at the guts yourself, or pass them to something that will do it for you. The first is ugly, the second slow. If life was all strings, I'd say hide it, and we'd slap it in as part of Parrot's string libs. But I don't think we can abstract that far. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Bryan C. Warnock
hings outside the memory manager, like with XStrings. But then again, all these levels of indirection confuses me to no end as to what's inside and what's not. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Bryan C. Warnock
ys_realloc versus realloc, etc). Why add new functions instead of patching the current ones? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Re: Definition of a null string?

2002-04-03 Thread Bryan C. Warnock
not sure how much or little he wants to change (now that he's thought about it for a while). I'd say, let's fix the bug with the buflen not representing the actual allocation size (which it looks like Mike Lambert's roll-up patch does) so we have the option of shipping 0.0.5 out the door, and then we'll address the larger questions later. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Re: Definition of a null string?

2002-04-02 Thread Bryan C. Warnock
eturns a size already rounded to 16 would cause everything to be already aligned, eliminating the need to have to round when walking. Again, it's probably best to bury this within the alloc calls themselves, so that the algorithm is best encapsulated. Thoughts? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Added macros for interpreter->flags

2002-04-02 Thread Bryan C. Warnock
On Tuesday 02 April 2002 01:48, Josh Wilmes wrote: > (apparently the enum type is signed by default). Implementation defined. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Definition of a null string?

2002-04-02 Thread Bryan C. Warnock
0 bytes. Since allocating 0 bytes is rather useless, I agree with the rounding up to 16. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Coding standards (was Re: typedefs)

2002-03-22 Thread Bryan C. Warnock
"C" { shenanigans) And I'd be surprised if the latter worked without a lot of hackery. (Not that it's not a valid scenario. I've worked on a couple projects like that.) Is this something we should at least look at? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
ight wanna check that, though... wchar_t, size_t, off_t, dirent_t, pid_t, uid_t, gid_t, socklen_t, etc. Dunno how many are actually POSIX, but > > Besides, what's the probability it'll be a problem if we prefix all > struct names with 'parrot_'? You don't really want to do that, do you? -- Bryan C. Warnock [EMAIL PROTECTED]

Coding standards (was Re: typedefs)

2002-03-22 Thread Bryan C. Warnock
king like. (One exception is the exceptions.) Folks, take a peek, and identify the stuff you've a grief with now. Let's make whatever changes to the coding standards that we need to do, and move on from there. We need to start cracking the whip now. I'll take responsbility for refactoring the old code. -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] base types (was Re: typedefs)

2002-03-22 Thread Bryan C. Warnock
def UINTVAL UIntval +typedef FLOATVAL Floatval +typedef VTABLE VTable +typedef DPOINTER DPointer +typedef SYNC Sync + /* typedef INTVAL *(*opcode_funcs)(void *, void *) OPFUNC; */ #define FRAMES_PER_CHUNK 16 -- Bryan C. Warnock [EMAIL PROTECTED]

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 11:36, Dan Sugalski wrote: > At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote: > >We're still all over the place with typedef name formats. We've FOO, Foo, > >and foo_t. We tried to hash this out before, but we didn't come to a clear >

Re: [PATCH] Misc PDD 07 nits

2002-03-22 Thread Bryan C. Warnock
udes) would > end up indented in every header file. You, too, can patch this document. ;-) -- Bryan C. Warnock [EMAIL PROTECTED]

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
#x27;t want to stare at a page of variable types yelling at me. (function pointers, enums, simple type pointers, etc.), and would just assume change *everything* from FOO to something else. Although I'd be happy with leaving the big four in all caps. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Problems with strings on the stack (small, concise example)

2002-03-22 Thread Bryan C. Warnock
<-- save ( ;boundary) seven<-- save ( ;boundary) eight<-- save ( ;boundary) nine<-- save ( ;boundary) ten<-- save ( ;boundary) eleven<--saved (endproc) Str eleven Str ten Str nine Str eight Str seven Str six Str five Str four Str three Str two Str one -- Bryan C. Warnock [EMAIL PROTECTED]

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 10:07, Brent Dax wrote: > Bryan C. Warnock: > # We're still all over the place with typedef name formats. > # We've FOO, Foo, > # and foo_t. We tried to hash this out before, but we didn't > # come to a clear > # consensus. (We got sidet

Re: Problems with strings on the stack (small, concise example)

2002-03-22 Thread Bryan C. Warnock
string (S1). > end > > With error message: Wrong type on top of stack! > -- Bryan C. Warnock [EMAIL PROTECTED]

typedefs

2002-03-22 Thread Bryan C. Warnock
We're still all over the place with typedef name formats. We've FOO, Foo, and foo_t. We tried to hash this out before, but we didn't come to a clear consensus. (We got sidetracked by typedeffing pointers to typedefs.) What's it going to be? -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] Misc PDD 07 nits

2002-03-22 Thread Bryan C. Warnock
ortant for parts of the code which are exposed through @@ -757,9 +754,9 @@ int i,j,k; for (i=0; i<1000; i++) { - for (j=0; j<1000; j++) { - k += a[j][i]; - } +for (j=0; j<1000; j++) { +k += a[j][i]; + } } This all boils down to: keep things near to each other that get -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Problems with strings on the stack (small, concise example)

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 09:37, Joshua Nye wrote: > Works ok up to 15 items on the stack. After that I get screwy results back. Is that with or without my patch? http:[EMAIL PROTECTED]/msg09093.html -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Problems with strings on the stack (small, concise example)

2002-03-22 Thread Bryan C. Warnock
- save ( ;boundary) eight<-- save ( ;boundary) nine<-- save ( ;boundary) ten<-- save ( ;boundary) eleven<--saved (endproc) -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] stacks.c

2002-03-21 Thread Bryan C. Warnock
e SP */ +chunk->used--; + +entry = &chunk->entry[chunk->used]; /* Types of 0 mean we don't care */ if (type && entry->entry_type != type) { @@ -189,8 +197,6 @@ (*entry->cleanup) (entry); } -/* Now decrement the SP */ - chunk-&

(Reformatted Resend) [PATCH] resources.c

2002-03-21 Thread Bryan C. Warnock
for (i = 0; i < cur_stack->used; i++) { + if (STACK_ENTRY_STRING == cur_stack->entry[i].entry_type) { buffer_lives((Buffer *)cur_stack->entry[i].entry.string_val); } } -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] resources.c (was Re: Problems with strings on the stack (small, concise example))

2002-03-21 Thread Bryan C. Warnock
for (i = 0; i < cur_stack->used; i++) { + if (STACK_ENTRY_STRING == cur_stack->entry[i].entry_type) { buffer_lives((Buffer *)cur_stack->entry[i].entry.string_val); } } -- Bryan C. Warnock [EMAIL PROTECTED]

Retracted: [PATCH] resources.c

2002-03-21 Thread Bryan C. Warnock
Rolled into stack fix patch. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Problems with strings on the stack (small, concise example)

2002-03-21 Thread Bryan C. Warnock
(nil) } { entry = { # stack[43] num_val = 1.0955949148585e-307 int_val = 3387912 pmc_val = 0x33b208 string_val = 0x33b208 generic_pointer = 0x33b208 } .. .. .. -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] resources.c

2002-03-21 Thread Bryan C. Warnock
_lives((Buffer *)cur_stack->entry[i].entry.string_val); } -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Some updates

2002-03-21 Thread Bryan C. Warnock
clone that was a cause of the GC going exponential. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Fix compile problem under Solaris

2002-03-18 Thread Bryan C. Warnock
tside > the assignment. > > The reason it was UINTVAL is just a matter of taste for > flag values, however one is as good as another here. and both will be going away. (I hope that 0.0.4 and my schedule sync up the way I need it to.)-: -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Reformatting code/coding standards

2002-03-17 Thread Bryan C. Warnock
ototype. > > I vote for non-enforcement of this one. Er, did you mean "removal"? Having rules that aren't enforced is counter-productive in the long run. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: pmc_init

2002-03-17 Thread Bryan C. Warnock
y the existing init). > > Any objections? On a side note, did anyone read the "Is Java's 'new' harmful?" article in DDJ? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [bugs-parrot@netlabs.develooper.com: [netlabs #423] Fwd: Parrot segfaults on substr]

2002-03-17 Thread Bryan C. Warnock
d take a null string - every string should be, at a minimum, empty. So I'd say ditch the guards and let the Parrto squawk its heart out. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [bugs-parrot@netlabs.develooper.com: [netlabs #423] Fwd: Parrot segfaults on substr]

2002-03-17 Thread Bryan C. Warnock
, > but the CPU itself doesn't explode. > > I do see Dan's point, but I also predoct people gravitating > towards the "safe" interpreter because of that extra fuzzy. > I don't. With untested stuff, sure. But with known good code? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Showstopper allocation bug

2002-03-17 Thread Bryan C. Warnock
On Saturday 16 March 2002 07:48, Simon Cozens wrote: > 645 return_me = *foo; On a separate note, metasyntactic variable names aren't the best choice in actual code. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: I'm about to do something really evil

2002-03-17 Thread Bryan C. Warnock
to object if you've a better option. :) Immortal sounds a little scary. What are you *really* doing? -- Bryan C. Warnock [EMAIL PROTECTED]

Re: 64 bit Debian Linux/PowerPC OK but very noisy

2002-03-17 Thread Bryan C. Warnock
long or double. My stomping grounds for after 0.0.4, I think. (Or before, if I can get to them. But I'd rather just caveat that it doesn't work, because, in general, it doesn't. )-: -- Bryan C. Warnock [EMAIL PROTECTED]

Re: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...

2002-03-17 Thread Bryan C. Warnock
cast discards qualifiers from pointer > target type > encodings/utf32.c:54: warning: cast discards qualifiers from pointer target > type > encodings/utf32.c:62: warning: cast discards qualifiers from pointer target > type Is this solvable? -- Bryan C. Warnock [EMAIL PROTECTED]

disappearing

2002-03-09 Thread Bryan C. Warnock
I appear to have been compromised. Am going off-line until I can track the problem and beef up security. -- Bryan C. Warnock [EMAIL PROTECTED]

Re: [PATCH] Two minor warnings

2002-03-06 Thread Bryan C. Warnock
TED]> > @roles=map {"Parrot $_"} qw(embedding regexen Configure) > > #define private public > --Spotted in a C++ program just before a #include -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] Two minor warnings

2002-03-05 Thread Bryan C. Warnock
04:57:09 - @@ -52,7 +52,6 @@ STRING *string; INTVAL index; INTVAL startindex; -BOOLVAL success; rxflags flags; UINTVAL minlength; @@ -64,6 +63,8 @@ opcode_t *substfunc; rxStack stack; + +BOOLVAL success; } rxinfo; -- Bryan C. Warnock [EMAIL PROTECTED]

  1   2   3   4   >