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
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)
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
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)
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]
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]
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-&
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]
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]
Rolled into stack fix patch.
--
Bryan C. Warnock
[EMAIL PROTECTED]
(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]
_lives((Buffer *)cur_stack->entry[i].entry.string_val);
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
clone
that was a cause of the GC going exponential.
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
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]
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]
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]
,
> 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]
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]
to object if you've a better option. :)
Immortal sounds a little scary. What are you *really* doing?
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
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]
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]
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]
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 - 100 of 384 matches
Mail list logo