. - but it doesn't necessarily matter whether it's
SPARC-based or not.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
? (To prevent
the aforementioned bit-shifting of WTF strings.)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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)
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)
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?
And what about codepoints that *are* glyphs and/but aren't graphemes?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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. :-)
--
Bryan C. Warnock
bwarnock
# New Ticket Created by Bryan C. Warnock
# Please include the string: [perl #28383]
# in the subject line of all future correspondence about this issue.
# URL: 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 half
On Thu, 2004-04-08 at 21:14, Robert Spier wrote:
b) Is it kosher/proper to update email references in it?
Sure.
Disagreement. This makes it harder to find relevant email messages in
the archives.
Excellent point.
(Ignore that section of my previously posted patch.)
--
Bryan C
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)
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
, 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 all the registers straight, I'm not adverse to
this. (What am I saying? Of course *you* can handle that. :-)
--
Bryan C. Warnock
bwarnock
that this is all
just false economics.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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
physical ones - the big drive for 64-bit
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 that simple. Imcc already
has:
.const type ID
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't there?)
I think parrot has already crossed
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 INTVAL constants on 32 bit
systems?
Parrotbyte.pod
.
--
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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22386
As mentioned previously. Makes IMCC and PASM constant keywords
consistent
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. Warnock
bwarnock@(gtemail.net
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. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net
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)
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)
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)
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 Crays anyway
Why?
--
Bryan C. Warnock
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)
a noticeable ongoing conversation between multiple
people.
--
Bryan C. Warnock
bwarnock(gtemail.net|raba.com)
'.
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)
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)
.
--
Bryan C. Warnock
bwarnock(gtemail.net|raba.com)
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 out and redo.
--
Bryan C. Warnock
../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.com)
Index
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.
--
Bryan C. Warnock
bwarnock
. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
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 being provided strictly at the language
level?
--
Bryan C. Warnock
bwarnock(gtemail.net
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 (often) to provide
a C-only implementation?
--
Bryan C. Warnock
bwarnock
, he said, What? We're going to have
code with an alpha channel? :-)
--
Bryan C. Warnock
bwarnock(gtemail.net|capita.com)
, and not for general opcode
use.)
--
Bryan C. Warnock
bwarnock(gtemail.net|capita.com)
as INTVAL in that case.
--
Bryan C. Warnock
bwarnock(gtemail.net|capita.com)
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)
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)
the cruft that's accumulated since
the beginning of the current sub is the responsibility of other code.
I'll take this opportunity to repoint to a thread we had last September
in re sub and method prototyping.
The thread starts here:
http:[EMAIL PROTECTED]/msg08182.html
--
Bryan C. Warnock
, 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]
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]
/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]
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]
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]
the current ones?
--
Bryan C. Warnock
[EMAIL PROTECTED]
these levels of
indirection confuses me to no end as to what's inside and what's not.
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
. 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]
( ;boundary)
ten-- save ( ;boundary)
eleven--saved (endproc)
--
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]
];
- }
+for (j=0; j1000; j++) {
+k += a[j][i];
+}
}
This all boils down to: keep things near to each other that get
--
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]
on top of stack!
--
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 sidetracked by typedeffing pointers
. (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]
. ;-)
--
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
consensus. (We got sidetracked
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]
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]
, 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]
of the GC going exponential.
--
Bryan C. Warnock
[EMAIL PROTECTED]
((start_stack != cur_stack) || (chunks_traced == 0))) {
-for (i = 0; i STACK_CHUNK_DEPTH; i++) {
+for (i = 0; i cur_stack-used; i++) {
if (STACK_ENTRY_STRING == cur_stack-entry[i].flags) {
buffer_lives((Buffer *)cur_stack-entry[i].entry.string_val);
}
--
Bryan C
= { # stack[43]
num_val = 1.0955949148585e-307
int_val = 3387912
pmc_val = 0x33b208
string_val = 0x33b208
generic_pointer = 0x33b208
}
..
..
..
--
Bryan C. Warnock
[EMAIL PROTECTED]
Rolled into stack fix patch.
--
Bryan C. Warnock
[EMAIL PROTECTED]
== cur_stack-entry[i].entry_type) {
buffer_lives((Buffer *)cur_stack-entry[i].entry.string_val);
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
== cur_stack-entry[i].entry_type) {
buffer_lives((Buffer *)cur_stack-entry[i].entry.string_val);
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
*/
if (type entry-entry_type != type) {
@@ -189,8 +197,6 @@
(*entry-cleanup) (entry);
}
-/* Now decrement the SP */
-chunk-used--;
/* Sometimes the caller doesn't care what the value was */
if (where == NULL)
--
Bryan C. Warnock
[EMAIL PROTECTED]
, 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]
?
--
Bryan C. Warnock
[EMAIL PROTECTED]
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]
. :)
Immortal sounds a little scary. What are you *really* doing?
--
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]
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]
is
busted, I'd prefer the segfault. It makes tracking the problem so much
easier,
Logically speaking, I don't think any Parrot string function should 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
, did anyone read the Is Java's 'new' harmful? article in
DDJ?
--
Bryan C. Warnock
[EMAIL PROTECTED]
-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]
regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
--
Bryan C. Warnock
[EMAIL PROTECTED]
and
cleanup. No new functionality added.
As usual, if there's anything that you think REALLY MUST HAPPEN before
release, speak now or forever hold thy peace.
A quick run through the docs/README/etc to make sure they are up-to-date.
--
Bryan C. Warnock
[EMAIL PROTECTED]
/* We're using the prederef runops */
-#define PARROT_JIT_FLAG 0x20 /* We're using the jit runops */
-
-#endif
+#endif /* header guard */
/*
* Local variables:
--
Bryan C. Warnock
[EMAIL PROTECTED]
= numhandles * sizeof(ParrotIO *);
+size_t size = numhandles * sizeof(ParrotIO *);
newhandles = (ParrotIOTable)mem_sys_allocate(size);
return newhandles;
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
@@
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]
trying to do this as one comprehensive patch, but it has gotten
way too big and involved, so I'm going to do it piecemeal.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Thursday 28 February 2002 01:12, Bryan C. Warnock wrote:
(Starts off at 90 recovered entries, then 88, 86, ..., 4, 2, 1, 128, 126,
etc.) The number of entries before decreasing seems to increase. I'll
see if I can extract a pattern.
It's similar to the previous patterns, albeit a little
On Thursday 28 February 2002 08:32, Bryan C. Warnock wrote:
The second call to new_string_header() in each generation loses one entry
in the string header pool during DOD. The twelfth call to
new_string_header() in each generation loses the second. *That* should be
enough info to track
@@
restore I1
restore I0
dumpend:
- ret
\ No newline at end of file
+ ret
Here're the new generation results:
Generations DOD GC
5 118 10
100 2,347204
500 11,730 1,020
1000 23,459 2,041
You're now linear again.
--
Bryan C. Warnock
-bufused
+(memcmp(s1-bufstart,s2-bufstart,(size_t)s1-bufused)==0));
}
void set_integer (PMC* value) {
--
Bryan C. Warnock
[EMAIL PROTECTED]
(interpreter, NULL, 0, NULL, 0, NULL);
}
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
@@
testparrotfuncptr.c
testparrotsizes_c.in
trace.c
+types/bignum.c
+types/bignum.h
+types/bignum_atest.pl
+types/bignum_test.pl
vtable.tbl
vtable_h.pl
warnings.c
--
Bryan C. Warnock
[EMAIL PROTECTED]
. [177]b968c: nop
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Wednesday 27 February 2002 20:19, Bryan C. Warnock wrote:
Yowza, you aren't kidding.
mark_buffers_unused() and free_unused_buffers() are a minute each in a
three minute-and-change run.
I'm guessing you're overiterating, but I haven't found where yet.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Thursday 28 February 2002 00:17, Bryan C. Warnock wrote:
On Wednesday 27 February 2002 23:34, Bryan C. Warnock wrote:
I did a graphical mapping of the DOD and GC calls, and the GC pattern
was interesting. (Indicative of a leak. I'm going to patch the output
to show a generation loop
file, though that's the subject of another message.
Good, because Huh?
--
Bryan C. Warnock
[EMAIL PROTECTED]
.
--
Bryan C. Warnock
[EMAIL PROTECTED]
1 - 100 of 288 matches
Mail list logo
