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)
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)
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)
.
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)
{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)
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
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
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
ection of my previously posted patch.)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
# 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
a) Is the ChangeLog autogenned?
b) Is it kosher/proper to update email references in it?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Has it been two years already?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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)
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
?
[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)
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,
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
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
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
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&
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
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)
# 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
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)
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.
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
> 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)
] 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)
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)
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)
ins
references to arrays which hold code references? Circular referencing?
You could hold forth Data::Dumper as an example, but people don't really
use that for stringification.
(BTW, direct mail to you, from me, never gets through. Times out.)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
On Thu, 2002-11-28 at 18:47, Bryan C. Warnock wrote:
> Yes, but the first digit is 0. Or, more accurately, 0 * 16**2.
Hmmph. Some accuracy. 0 * 16**1
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
out of it.
The design team shouldn't need to oversee day-to-day, just tweak the
docs you produce. The summaries shouldn't need to report on the weekly
discussions, just report on what you've released. Much like the old
sub-lists would step away to discuss some particular topic h
#14
16#1:14 == 10#30
>
> Presumably the compiler can determine that 16#141312 means
> 16#1:4:1:3:1:2 because of the length, so its only 2 character numbers
No. It can determine that because it doesn't have a colon. Keeps the
rule set small, simple, and consistent.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
e
> Parrot people think, since they're closer to the action.
It might help the Parrot people if they knew what their target languages
wanted. (Not that they can guarantee delivery of said requests, of
course. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
to quit asking rhetorical
questions.
Be kind to Piers. Be kind to the readers. Don't have separate but
equal discussions in two different lists. Weed out the cruft, fill in
the gaps.
Interpolate, don't extrapolate.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
e of questions and proposals
> re-examining issues covered in previous A&E's following each new release,
> p6d hopes to annotate its documentation to include the various trade-offs
> involving alternative syntax, semantics, implementation impacts, ideological
> ax grinding, etc. s
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
On Mon, 2002-11-25 at 20:00, Joseph F. Ryan wrote:
> I agree; perhaps before the argument begins, we should have something to
> argue over? :) (i.e., a first draft of these sections)
Sure. On perl6-language. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
al notation ('e')
>
> - can't have runtime radix, e.g. 2**8#10, because # binds tighter.
> - can't say (2**8)#10, because not a literal.
>
The examples are good and extrapolate nicely, but has the grammar been
defined somewhere (in one form or another)?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
s that can typecast
> to/from str, int, bool, etc. This gets into Perl6 OO, but we may need
> to request some preliminary decisions before then, because the
> implications are substantial.
and again...
>
> Let's open these for discussion. Questions/proposals/issues,
?
Given that this group is a) mostly only summarizing the decisions made
elsewhere, and b) producing its own documentation, the occasional call
to action and a list of what new and updated docs have been released -
or the occasional reminder of where to find the new and updated docs -
should be sufficient.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
ed a
> license:
>
> David Storrs
And what of the people you don't know? :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
On Mon, 2002-11-18 at 10:08, Erik Steven Harrison wrote:
>
> --
>
> On 17 Nov 2002 11:09:53 -050
> Bryan C. Warnock wrote:
> >On Wed, 2002-11-13 at 13:26, Angel Faus wrote:
> >>
> >> There are many ways to specify literal numeric values in perl, but
<\N{...}> notation and put the official
> Unicode character name within the braces, such as C<\N{WHITE SMILING
> FACE}>.
>
> See the L section for a full explanation of the interpolation
> mechanism and a list of special characters in double-quoted strings.
>
> =section ** String as vector of ordinals
>
> Literals of the form C are parsed as a string composed of
> characters with the specified ordinals. This is an alternative, more
> readable way to construct (possibly unicode) strings instead of
> interpolating characters, as in C<\x{1}\x{2}\x{3}\x{4}>. The leading
> C may be omitted if there are more than two ordinals, so C<1.2.3>
> is parsed the same as C.
See numerical comment above about the implied radix.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
256:-234.254; # error
Why?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
n base-2 and base-16.
Not that that should, by any means, justify core functionality to
do so.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
On Mon, 2002-10-28 at 14:41, Larry Wall wrote:
> And maybe:
>
> A bitwise operator is just a logic operator scoped to a set of bits.
Hypo-operators. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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)
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)
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)
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)
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)
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)
, 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)
iform
width, in which case it is only going to match one thing and one thing
only. Whether that will be an issue with variable-width characters in a
class is largely going to rely on the semantics that are dictated.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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
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)
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)
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
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)
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.
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)
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.
--
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)
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
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
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)
eptember
in re sub and method prototyping.
The thread starts here:
http:[EMAIL PROTECTED]/msg08182.html
--
Bryan C. Warnock
bwarnock@(gtemail.net|capita.com)
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)
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)
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)
t opcode_t to
be the same size as INTVAL in that case.
--
Bryan C. Warnock
bwarnock@(gtemail.net|capita.com)
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)
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]
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]
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]
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]
#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]
;$i is rw>, why, it
> should work find. :-)
>
> : (Or, more generally, given a for loop with a "my", how sould perl52perl6
> : deal with it?
>
> Probably just by slapping an extra set of curlies around it.
Umm. didn't you say bare blocks were going away?
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
ys_realloc versus realloc, etc).
Why add new functions instead of patching the current ones?
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
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]
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]
0 bytes.
Since allocating 0 bytes is rather useless, I agree with the rounding up to
16.
--
Bryan C. Warnock
[EMAIL PROTECTED]
"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]
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]
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]
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]
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
>
udes) would
> end up indented in every header file.
You, too, can patch this document. ;-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
#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]
<-- 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]
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
string (S1).
> end
>
> With error message: Wrong type on top of stack!
>
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
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]
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]
- save ( ;boundary)
eight<-- save ( ;boundary)
nine<-- save ( ;boundary)
ten<-- save ( ;boundary)
eleven<--saved (endproc)
--
Bryan C. Warnock
[EMAIL PROTECTED]
1 - 100 of 503 matches
Mail list logo
