necessary to completely separate
the two would not benefit either Perl, or the stand-alone engine, for both
cases, so why bother? IOW, if you're not going to completely exorcise Perl
from its regexes, why try to exorcise the regexes from Perl?
--
Bryan C. Warnock
[EMAIL PROTECTED]
instead of rolling your own. No need to have locale
handlers for locales you won't use.
Of course, being Unicode neutral, that still leaves some stuff (like case
determination) undefined. So maybe there should be a default locale in
place - the current, or barring that, English, I suppose.
--
Bryan C. Warnock
[EMAIL PROTECTED]
sking the
applications to handle, in an effort to make the hard things easy. (And for
some of these languages, it can be quite hard.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
emedous potential (for pain *and* pleasure), but the idea
should be to foist the burden only on the folks that want it. (And since I
directly support text mungers, I'm one of them.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
thinking more in the sense of the above properties)?
Print direction only when printing. The data itself is unidirectional.
--
Bryan C. Warnock
[EMAIL PROTECTED]
/. rebuttal of the original article at
http://slashdot.org/features/01/06/06/0132203.shtml, for those that haven't
seen it yet.
--
Bryan C. Warnock
[EMAIL PROTECTED]
may signal
something completely different to some other language.
The hooks don't have to be that complicated, or even exist, since it seems
that they are simply being done for the convenience of the user. (To
simplify regexes.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
ng that. We just need to determine how.
--
Bryan C. Warnock
[EMAIL PROTECTED]
do
> you think [a-\N{KATAKANA LETTER KI}] should mean? I think it should
> mean a compile time error. People misuse ranges for classes. Ranges
> also imply some collation, which is, as discussed, really bad.
Yes, ranges are bad, but they're occasionally useful.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Tuesday 12 June 2001 10:58 pm, Bryan C. Warnock wrote:
> On Tuesday 12 June 2001 09:16 pm, Simon Cozens wrote:
> > On Tue, Jun 12, 2001 at 05:41:40PM -0700, Hong Zhang wrote:
> > > We should let external collator to handle all these fancy features.
> >
> > Phew, I
tween every pairs of characters, right (since every character is a
> \w, kinda...)?
Okay. I was on the fence, just fell off on the wrong side.
I also missed... literals. We can't create new literals, (can we?) but can
we override them? Would it make sense to do so? (I can only think of
transliteration of languages that are 1-1 across the character sets.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
uot; with /[a]/, but
> without changing the sort order. "locale" is a bit too much "all or
> nothing" for me.
That would probably be another good use for literal overriding.
use re 'literal a => [aàáâãä]';
my $foo = "abàcádãe";
print $foo =~ /a.a/g;
(after the loader is finished
> with them) while the opcode section has none. This will allow us to
> mmap precompiled code and share at least some of it amongst multiple
> processes.
>
I assume from this description, then, that there's really (3 x number of
compilation units) segments?
--
Bryan C. Warnock
[EMAIL PROTECTED]
*defined* via that.
module Locale::Hawaiian;
use re 'class (\w => [aeiouâêîôûhklmnpw`])';
...
On a side note (and this *will* sound stupid, but there is a reason I'm
asking). Why is there no logical opposite to '.'; that is, a character
which never matches another character? (Besides, of course, that it's
utterly useless from a classic regex perspective.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
me or the regexen that's
aiming, it's still the same foot I'm shooting.
With those limitations in place, it's not really much more dynamic than now,
unless you start getting (??{ crazy, which is just naturally hairy, anyways.
I'm sure this is gross oversimplification, but am I close?
--
Bryan C. Warnock
[EMAIL PROTECTED]
to normalize it to something else. That would cause the big* and the string
value to get out of sync, but you're going to need to address the conversion
back anyway.
--
Bryan C. Warnock
[EMAIL PROTECTED]
iot. I can't even think of what I
may have been thinking of. We have talked about this before. I write the
damn summaries, for crying out loud Arggh!
--
Bryan C. Warnock
[EMAIL PROTECTED]
some different variations of the loop
for efficiency testing and need to know what I can and cannot assume.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Sunday 29 July 2001 12:55 am, Doofus wrote:
> Dan, et al,
> When we say that each opcode handler will return the next opcode, we
> really mean the location within the opcode stream, and not the opcode
> itself, right?
Nebbermime. RTFM. It's in PDD 5.
--
Bryan
sure I could switch Perl 5 from
one to the other, for instance.) And I'm sure there are some things that
I'm not considering. Nick and Dan may have some additional insight.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Monday 30 July 2001 09:34 am, Nick Ing-Simmons wrote:
> Bryan C . Warnock <[EMAIL PROTECTED]> writes:
> >Not that this is the most scientific testing in the world, but I did
> > write a couple variations of an opcode dispatch loop just to see how
> > they compare.
&
they export) being introduced into the calling code lexically. If that is
the case, then you needn't worry about the exporting or the code collision.
Unless you do something bad. The only real difference is that you can
unexport, and essential pop the lexicals before end-of-scope.
--
Bryan C. Warnock
[EMAIL PROTECTED]
e use
(or perhaps, one that we haven't used yet) from within our scripts,
preferrably without having to add explicit code to do so.
GUIDs
Gurusamy, in his discussion about what he feels Perl 6 should be, proposed
GUIDs (Global Unique IDs). Although he didn't go into detail, GUIDs would
be one way to encode both version and authoring details much like what Larry
wanted. But here we have the chicken-and-the-egg problem. GUIDs are
excellent for C2C communications, but horrible for H2C communications. And
you'd still need to derive some sort of structure for the modules to coexist
on disk.
--
Bryan C. Warnock
[EMAIL PROTECTED]
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Saturday 04 August 2001 03:21 pm, Dan Sugalski wrote:
> At 01:04 PM 7/30/2001 -0400, Bryan C. Warnock wrote:
> >I'll also rework my code generator and the logic to ramp it up to four or
> >five hundred opcodes, which would be a little better test, I think.
> >Any
has a callback (to regular Perl code), does the callback's code
(beyond the actual dispatch) run at PRI 4, or 0? At what point do you
revert to the lower priority and allow other events to be handled?)
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Monday 06 August 2001 09:08 am, Bryan C. Warnock wrote:
> It could be that part of the "fixup" is to convert from bytes to wider
> ops, or something similar. If that's the case, I can patch the code and
> rerun it.
Okay. I rewrote the code from scratch. (Rev 2
On Tuesday 07 August 2001 10:48 am, Dan Sugalski wrote:
> BTW, can I get the source to the tests? I'd like to give them a whirl to
> see how the Alphas deal with the various alternatives.
http://members.home.com/bcwarno/Perl6/spool/opcode_test.tgz
--
Bryan C. Warnock
[EMAIL PROTECTED]
e a single default
expression, multiple default expressions, or a default block?
[ LABEL: ] given ( expr_1 ) {
...
expr_n [;]
}
[ LABEL: ] given ( expr_1 ) {
...
expr_n
[; expr_n+1 ... ] [;]
}
[ LABEL: ] given ( expr_1 ) {
...
block
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
particularly to able to mmap code in read only and run straight from that.)
It could be that part of the "fixup" is to convert from bytes to wider ops,
or something similar. If that's the case, I can patch the code and rerun it.
--
Bryan C. Warnock
[EMAIL PROTECTED]
x27;d
> as soon not have to deal with if we can avoid it.
Okay, I may be slow, but I make mistakes. I'll probably rework it tonight.
--
Bryan C. Warnock
[EMAIL PROTECTED]
on? Whuh?
In decimal, 20010401, or 1 April 2001, the "birthday" of Parrot.
--
Bryan C. Warnock
[EMAIL PROTECTED]
s
}
Is this possible? Feasible? Way out there?
[1] Chain? Branch? What's the correct terminology here?
--
Bryan C. Warnock
[EMAIL PROTECTED]
al $OPTIMIZATIONS = not defined tied $thingy;
# A bunch of code that could be optimized.
# If thingy is tied, non-optimal code is forced.
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
articular optimizations invariably end
with, "But we can't do that, because {something} can happen at runtime."
I'm simply suggesting that if we can easily detect that *something* did
happen, there might be a way to not have to reject optimization from the
get-go.
--
Bryan C. Warnock
[EMAIL PROTECTED]
I hereby dub all the individual pieces of the intepreter as Parroty Bits.
--
Bryan C. Warnock
[EMAIL PROTECTED]
, the code-review phase will begin with anonymous read-only access to
the Perl CVS repository, routine snapshots on dev.perl.org, and the
occasional build (if and when it actually does:) on CPAN.
The plan for when development has been opened up is a bridge that we'll
cross once we build i
;d have to code and
maintain. There's no reason you couldn't do that. Yes, it'd be a waste of
space. Yes, it'd be slower, unless there were a lot of lexicals being
introduced. But there's no other reason why it couldn't work.
Brent just went wayward when trying to further explain.
--
Bryan C. Warnock
[EMAIL PROTECTED]
hy use a PMC
> to implement a string? What does it mean to have a PMC that "implements a
> string" and also have a "string type" in Parrot?
An opcode may call a vtable method on a PMC that is string manipulation
intensive. That vtable code could then use the string
I'm sure it will be abused.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote:
> At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
> >Yes, this is akin to redeclaring every lexical variable every time you
> >introduce a new scope. Not pretty, I know. But if you want run-time
> >semant
ns?)
You are going to take into consideration where Perl 6 might take a little
longer just because it has to do something 5.004 doesn't, right? (Like
Unicode Everywhere).
--
Bryan C. Warnock
[EMAIL PROTECTED]
t I meant by "everywhere": source, input, output), we're going to
be a little more hindered than if we didn't have to worry about it at all,
no?
Or will you only compare Granny Smiths with Granny Smiths?
--
Bryan C. Warnock
[EMAIL PROTECTED]
, or n means either a register or constant of the appropriate type
> > (PMC, string, integer, or number)
>
> How many registers are the going to be per type? Unlimited?
Currently 32 per.
--
Bryan C. Warnock
[EMAIL PROTECTED]
etty quick, with the problematic C++ in the
middle, and Java significantly slower.
But that was then...
--
Bryan C. Warnock
[EMAIL PROTECTED]
so often traditionally provided in a language, since it
identifies the proper quadrant.
Others would include abs, floor, ceil, round, mod - don't know if those are
basic or "fancy" to you. I suspect you may have those already
The question arises what do you do as its opcode,
t rolls would be useful :)
Vuja de.
>
> Are there going to be string ops as well, or would add and mul work on
> string registers?
Yes.
--
Bryan C. Warnock
[EMAIL PROTECTED]
cleverly) decides that a "SHL I0,I0,32" clears
> the register.
Previous discussions on bit operators on arbitrarily-sized integers:
http://www.mail-archive.com/perl5-porters@perl.org/msg33402.html
http://www.mail-archive.com/perl5-porters@perl.org/msg29166.html
Executive summary: are you fixing the width of the number or not?
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Monday 10 September 2001 10:28 am, Brian Wheeler wrote:
>
> I was thinking about NOP this morning, and I realized that it might very
> well be necessary. If someone was writing a "simple" assembler for
> parrot, it might be useful for padding.
Pad what?
--
Bryan C. Warnock
[EMAIL PROTECTED]
ring handling, but a
language isn't roped into using them.
Things to keep in mind. (And another reason why it's good to have Namespace
Police :)
--
Bryan C. Warnock
[EMAIL PROTECTED]
ike I said, just things to keep in mind. There's a slight difference
between designing and coding Parrot as an interpreter backend, and coding it
as a backend to Perl that other languages can use. (I'm in favor of the
latter, though public opinion seems to favor the former.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
the whole
> effort from other languages.
>
> So we're proceeding with designing perl6. We're leaving the door open
> for other languages, but we're not going to significantly delay or
> impede perl6 to support them.
Most excellent.
--
Bryan C. Warnock
[EMAIL PROTECTED]
o much easier to walk the correct path from
the start. Since it's all Parrot, it's even easier.
--
Bryan C. Warnock
[EMAIL PROTECTED]
? (I'm very much in favor of such a change, and will
pick it up if no one else is working on it.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
code name... :) The intention is the last _x covers the
> last arg, the next to last covers the next to last arg, and so on. When we
> run out, we repeat the innermost type.
Why are you doing right-to-left instead of left-to-right?
--
Bryan C. Warnock
[EMAIL PROTECTED]
onstants now. Everything else seems to work on the
assembler side.
--
Bryan C. Warnock
[EMAIL PROTECTED]
, because string and integer
constants come down to the guts of the assembler the same way, and I can't
base it off of the destination type.
I think I'll need to do mangling beforehand, or come up with another
mechanism. (One of which I already have in mind.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
't change scope.
Is that a "doesn't" or "won't"?
--
Bryan C. Warnock
[EMAIL PROTECTED]
rint_s S1
chopn_s_ic S1, 1
branch_ic REDO
--
Bryan C. Warnock
[EMAIL PROTECTED]
I1, S1
+REDO: eq_i_ic_ic I1, I2, DONE, NEXT
+NEXT: length_i_s I1, S1
print_s S1
chopn_s_ic S1, 1
branch_ic REDO
A1
--
Bryan C. Warnock
[EMAIL PROTECTED]
.
--
Bryan C. Warnock
[EMAIL PROTECTED]
t; >properly balanced?
>
> I'm not sure what we'll do in that situation. gotos into scopes might not
> be allowed.
That's how it currently is for most scopes, and it certainly saves a whole
lot of trouble and inconsistencies.
--
Bryan C. Warnock
[EMAIL PROTECTED]
ack($pack_type{i},0) x 3; # Flags, encoding, type
+ $output .= pack($pack_type{i},length($_)); # Strlen followed by
that many bytes.
+$output .= $_;
+$output .= "\0" x (length($_) % $sizeof_packi); # Padding;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Tuesday 11 September 2001 04:13 am, Simon Cozens wrote:
> On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote:
> > This patch (temporarily) fixes the missing _ic on comparison opcodes.
>
> Didn't apply cleanly. Can you try again from CVS?
>
> Simon
I
llow you to enter via
goto. (And three of those should be footnoted as well...)
>
> And of course the keywords last, next and redo are just restricted
> gotos. Those are able to leave one or more scopes.
Yes, leaving is okay. I was referring just to entering.
--
Bryan C. Warnock
[EMAIL PROTECTED]
ily tested (ie, opcodes 0-n). Parrot's
performance does seem to differ from my initial testing, though, so you may
want to benchmark it every which way.
--
Bryan C. Warnock
[EMAIL PROTECTED]
I would imagine that those would be handled via the PMC registers instead.
I wouldn't say that CONCAT Sx,Sx should be CONCAT Sx,Sx,Sx, but that CONCAT
Sx,Sx,Sx should be added. I'll patch (if warranted) when I find the time,
unless someone beats me to it.
--
Bryan C. Warnock
[EMAIL PROTECTED]
27;set_i_ic'
>
Except it shouldn't be 31. It should be one less than NUM_REGISTERS as
defined in parrot.h.
--
Bryan C. Warnock
[EMAIL PROTECTED]
stant section, or ensure instructions are assigned on an
> appropriate boundary. I can see pros and cons of both.
I thought Dan already declared non-ints go in the constant section. Let me
see if I can find the reference
http:[EMAIL PROTECTED]/msg04780.html
--
Bryan C. Warnock
[EMAIL PROTECTED]
ething that doesn't work is. :-)
Best bet may be to throw a constant TOC up front, to indicate where N, I,
and S constant sections start. You may then pad each section as necessary
to get your initial alignment.
--
Bryan C. Warnock
[EMAIL PROTECTED]
}
/* I'll check for an event when... */
case (HELL_FREEZES_OVER) {
while (opcode == VALID) { DO_OP4() } break;
}
}
run_ops_type = new_runops_loop(I,opcode);
}
/* yada yada yada */
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
processing.
--
Bryan C. Warnock
[EMAIL PROTECTED]
7;t be optimized into
something less heinous.
An oft-mentioned (most recently by Simon on language-dev) lament WRT Perl 6
is the plethora of uninformed-ness from contributors. So I am now informed.
And so are you, if you weren't already.
--
Bryan C. Warnock
[EMAIL PROTECTED]
x27;t tell quite yet
whether the problems in the assembler or the _unpack function.) In either
case, I know that we'll still have alignment problems once we hit runops
land.
What are we going to do about this?
[1] Why won't gcc allow bit-operands on pointers? Is that illegal?
--
Bry
hree bits per
> register operand...
As long as we're going to allow the builder to specify the opcode size, then
we're going to need to test this. However, if sizeof(opcode) ==
sizeof(opcode arg), that only allows you an 8 bit argument, which isn't a
very big offset into a constant table.
--
Bryan C. Warnock
[EMAIL PROTECTED]
;
opcode_t * code_end;
! opcode_t * pc;
check_fingerprint(interpreter);
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Sunday 30 September 2001 08:46 pm, Simon Cozens wrote:
> It's to do with me being confused between the size of the NV pointer
> (which is an IV)
Not necessarily.
--
Bryan C. Warnock
[EMAIL PROTECTED]
dest->bufused = length;
return dest;
--- 74,81
/* Offset and length have already been "normalized" */
string_grow(dest, length);
! mem_sys_memcopy(dest->bufstart,
! (void *)((char *)src->bufstart + offset), length);
dest->strlen = dest->bufused = length;
return dest;
--
Bryan C. Warnock
[EMAIL PROTECTED]
e pointers coming in to
> optimize the latter to the former.
http:[EMAIL PROTECTED]/msg04600.html
--
Bryan C. Warnock
[EMAIL PROTECTED]
gh, it was more of a size issue. An IV isn't necessarily the same size
as a pointer.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
y, unsigned char.)
To avoid char * where void * is warranted is good. To avoid char * where
char * is warranted is bad.
If you're afraid of causing mental programmer problems with byte-wise data
that isn't character data, then typedef u_char as byte.
--
Bryan C. Warnock
[EMAIL PROTECTED]
e
> epsilon (maybe)
>
(+- infinity)?
--
Bryan C. Warnock
[EMAIL PROTECTED]
tream. Since opcode_t is at least 32 bits this is
> OK.
Inlined as what type? (And I assume, then, that you'll allow mix and match,
where integers are either inlined or in the constant table, depending on
their size - your explanation of "nope" pending, of course.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Holding steady since last report.
--
Bryan C. Warnock
[EMAIL PROTECTED]
/03 14:21:52
@@ -136,7 +136,7 @@
opcode_t * code_start;
INTVAL code_size;
opcode_t * code_end;
-INTVAL * pc;
+opcode_t * pc;
check_fingerprint(interpreter);
--
Bryan C. Warnock
[EMAIL PROTECTED]
hile (pc >= code_start && pc < code_end && *pc) {
do {
y = x[*w]; \
w = (y)(w,z); \
} while (0);
}
slow it down by 6%?
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Wednesday 03 October 2001 10:43 am, Simon Cozens wrote:
> On Wed, Oct 03, 2001 at 10:45:08AM -0400, Bryan C. Warnock wrote:
> > while (pc >= code_start && pc < code_end && *pc) {
> > do {
> > x = z->opcode_funcs; \
> > y =
Is there anything that might alter an operation involving only constants
and/or the constant registers at a time other than compile time (ie, when
the opcode is generated.)?
--
Bryan C. Warnock
[EMAIL PROTECTED]
on-overridable set of opcodes
(namely, the base set of I*, N*, and S* calls) inlined would have on
performance.
(By non-duplicated, meaning that, say, opcodes 0-256, for instance, are
non-overridable, and the opcode numbers 0-256 are also unusable by
extensions.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
ld be
> reordered either way.
Leaving the initial (outer) assignment of opcode_funcs to temp (x), the only
differences in the assembly between the two are the three less operations
within the inner loop that handle the original (inner) assignment. Your
other suggestions were tried and had
On Wednesday 03 October 2001 11:44 am, Andy Dougherty wrote:
> Finally, trying a 32-bit opcode_t and a 64-bit INTVAL, I get
Mixed sizes are completely hosed. But we need to decide how they should
behave before we start randomly applying bandaids.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Whammo 20> test_prog test [12:35]
Iterations: 1
Start time: 1002126954
End time: 1002126966
Count: 1
Elapsed time:12
Estimated ops:3
Estimated ops (numerically):-0.00
Elapsed time:12
Elapsed time:-2.00
Ops/sec:-0.02
--
Bryan C. Warnock
[EMAIL PROTECTED]
criticisms?
Which standard?
--
Bryan C. Warnock
[EMAIL PROTECTED]
sult cannot be represented
in the integer type,
the behavior is undefined. The result need not be in the range of
values of any integer
type.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Thursday 04 October 2001 11:08 am, Bryan C. Warnock wrote:
> In C9x, pointer-integer conversions (except for 0) aren't guaranteed for
> doing pointer arithmetic. (There was a good explanation that I ran across
> the other day, but I can't seem to find it now.)
Found it.
On Thursday 04 October 2001 11:22 am, Dan Sugalski wrote:
> At 11:16 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
> >Since pointers and integers are now considered incommensurate, the only
> >integer that can be safely converted to a pointer is the constant 0.
> > The res
t doing *nearly* enough talking beforehand of some of the
particulars of Dan's overall design.
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Thursday 04 October 2001 12:05 pm, Dan Sugalski wrote:
> At 11:29 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
> >Just the fact that we needed this patch in the first place indicates that
> >we're not doing *nearly* enough talking beforehand of some of the
> >particula
On Thursday 04 October 2001 02:22 pm, Dan Sugalski wrote:
... answers.
Excellent. Thanks for your patience!
--
Bryan C. Warnock
[EMAIL PROTECTED]
I thought it might be
> easier to comment on the patch if it were already coded. If this isn't
> wanted, I will continue to change it until it is :)
I'm still not sure about size_t, but nothing standard had been added until
recently. It's probably universal enough to be safe, but we may want to
just find a type the same size as a pointer and roll our own just to be safe.
--
Bryan C. Warnock
[EMAIL PROTECTED]
gt; >just find a type the same size as a pointer and roll our own just to be
> >safe.
>
> I think size_t will be safe; however, I understand your hesitation. I can
> replace size_t with a typedefed type ( perhaps ptrcast_t ) and then have
> it typedefed with size_t to begin with. That way, we can easily change it
> when we decide what we want to do. Does that sound OK?
Sure, as long as I'm only being paranoid and not stupid about it.
--
Bryan C. Warnock
[EMAIL PROTECTED]
1 - 100 of 384 matches
Mail list logo
