On Sep 12, 2004, at 11:29 PM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
And again, I don't so much object to the idea of nested namespaces--I
just feel that they'll slow down symbol lookups, without giving us
much
in return. I'm afraid we're adding complexity we don't
On Sep 13, 2004, at 6:38 AM, Timm Murray wrote:
On Sunday 12 September 2004 10:08 pm, Jeff Clites wrote:
I'd say that the language-level namespaces should get nice reverse-DNS
names, like [com.perl.perl5], or whatever's appropriate.
No, no, no, no. Bad Java programmer! :)
Ha, it's actually one
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have [foo; bar; baz] for a namespace. Woo hoo and all
that. It'd map to the equivalent perl namespace of foo::bar::baz.
How does this hierarchical nature manifest? I ask because I don't know
of any languages
On May 26, 2004, at 2:02 AM, Nicholas Clark wrote:
On Tue, May 25, 2004 at 07:48:32PM -0700, Jeff Clites wrote:
On May 25, 2004, at 12:26 PM, Dan Sugalski wrote:
Yup. UTF8 is Just another variable-width encoding. Do anything with
it
and we convert it to a fixed-width encoding, in this case UTF32
On May 25, 2004, at 12:26 PM, Dan Sugalski wrote:
At 12:30 PM +0100 5/25/04, Nicholas Clark wrote:
I may be misremembering what I've read here but I thought that Dan
said
that for variable length encodings (such as shift-JIS) parrot would
store
the byte(s) in memory in constant size 16 or 32 bit
On May 17, 2004, at 8:49 AM, Jon Shapcott wrote:
On Mon, May 17, 2004 at 03:51:48PM +0200, Jerome Quelin wrote:
On Monday 17 May 2004 15:14, Nicholas Clark wrote:
So the new parrotbug works? :-)
Not yet, but I finally found some tuits to work on it! :-)
And sorry for the noise, I forgot to put the
On May 16, 2004, at 2:05 AM, Peter Gibbs (via RT) wrote:
# New Ticket Created by Peter Gibbs
# Please include the string: [perl #29618]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29618
While investigating the test
On May 16, 2004, at 6:58 PM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites wrote:
+local $/;
+return if FROM eq TO;
I hope none of these files are too big. Otherwise, that'll be a
painfully huge slurp...
Yeah, I know, but I opted to not loop line-by-line, since
On May 14, 2004, at 3:30 PM, Ron Blaschke wrote:
Friday, May 14, 2004, 11:48:00 PM, Andy Dougherty wrote:
IMHO, we are currently talking C only, so that shouldn't be a
problem. I
hope anybody tells me if I'm wrong.
Still, I am curious. Why would the linker need to know about C or
C++?
I
On May 14, 2004, at 9:04 AM, Dan Sugalski wrote:
Today's project is to get all the MMD things actually using MMD. I've
put in the first wave of changes (well, OK, second if you consider
Leo's BXOR test as the first) and should get the rest of the stuff in
today.
This part's a bit hackish but,
On May 12, 2004, at 1:26 PM, Ron Blaschke wrote:
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am
going
to implements this if there are no objections. ;-)
- Targets shared and static are provided, to
On May 10, 2004, at 7:31 AM, Dan Sugalski wrote:
At 10:34 AM +0100 5/10/04, Tim Bunce wrote:
On Sat, May 08, 2004 at 04:59:52PM -0700, Jeff Clites wrote:
On May 8, 2004, at 10:30 AM, Dan Sugalski wrote:
(Note that, regardless of anything else, we do need to separate
out
stream IO and record
On May 8, 2004, at 3:40 AM, Nicholas Clark wrote:
The problem came down to me storing not the PMC pointer, but the 1's
complement
of it in the perl SV.
...
However, I forgot to do the 1's complement on the value passed to the
unregister PMC call
...
(As for all its inherent horrors, perl's
On May 8, 2004, at 10:30 AM, Dan Sugalski wrote:
Do we want to make a distinction between record reads and just plain
read me X (bytes|codepoints|graphemes) requests on filehandles and,
if so, do we think it's worth distinguishing between fake records
(line-oriented things) and real records
On May 6, 2004, at 6:58 AM, Nicholas Clark wrote:
On Tue, May 04, 2004 at 02:55:25PM +0200, Leopold Toetsch wrote:
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
'libnci.so' is used for testing the native call interface. However I
noticed
that the tests in t/pmc/nci.t were skipped, because
On May 7, 2004, at 1:13 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
... which is trashing the strings we've just made (and are
in the middle of using) in build_call_func:
2925if (!string_compare(interpreter, signature,
2926 string_from_cstring(interpreter
On May 7, 2004, at 5:04 AM, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
However, I still have to make libnci.dylib by hand. I'm not sure of
the best
way to integrate things for that into the Configure system.
Your patch is almost ok. But I think dependencies are still wrong -
On May 7, 2004, at 11:48 AM, chromatic wrote:
On Fri, 2004-05-07 at 11:13, Leopold Toetsch wrote:
Larry Wall [EMAIL PROTECTED] wrote:
[I'm assuming that these internal signatures contain actual type
No. They are really internal, denoting C data types: 'i' = int, 'd'
=
double and so on. These
On May 4, 2004, at 5:34 AM, Dan Sugalski wrote:
The right way to fix this is to have a file with the acceptable
exportable symbols and a fix to the link stage to convince the linker
that it should *only* export these symbols.
I have this working locally on Mac OS X--I expect it will be rather
On May 5, 2004, at 12:06 PM, Dan Sugalski wrote:
At 7:57 PM +0100 5/5/04, Nicholas Clark wrote:
On Wed, May 05, 2004 at 08:59:03AM -0400, Dan Sugalski wrote:
Yeah, that's what I'm figuring. The symbols themselves should be
cross-platform, modulo the odd prefix character, or so I hope. The
On May 4, 2004, at 9:02 AM, Dan Sugalski wrote:
While Parrot will do async IO, we are making ordering guarantees for
reads and writes (though reads and writes will be considered separate
and ordered separately). That is, if you issue two or more reads or
writes, they will be satisfied in order
On May 4, 2004, at 6:55 AM, Joshua Gatcomb wrote:
Is it possible that parrot is coredumping for
some other reason? The parrot.exe is around 3MB. I
know that it isn't dying immediately upon execution
because if the data file isn't in the directory it is
supposed to be, invoking parrot.exe will
On Apr 28, 2004, at 10:59 AM, Larry Wall wrote:
All in all, very well written.
Thanks.
I do, of course, have a few quibbles:
On Wed, Apr 28, 2004 at 04:22:07AM -0700, Jeff Clites wrote:
: As it turns out, people find it convenient to programmatically
represent a
: character by an integer
On Apr 19, 2004, at 12:06 AM, Luke Palmer wrote:
Therefore, the first syntax can be redefined to evaluate the code block
and assign the result to $0.
Would you ever want to leave $0 unaltered? That's the only concern
which comes to mind.
My argument for using this notation stems from the fact
Two more things to keep in mind:
On May 1, 2004, at 4:54 PM, Aaron Sherman wrote:
If Perl defaults to UTF-8
People need to realize also that although UTF-8 is a pretty good
interchange format, it's a really bad in-memory representation. This is
for at least 2 related reasons: (1) To get to the
On May 2, 2004, at 7:38 AM, Andrew E Switala wrote:
Jeff Clites [EMAIL PROTECTED] 2004-05-01 18:23:02
[Finishing this discussion on p6i, since it began here.]
Good point. However, the more general usage seems to have largely
fallen out of use (to the extent to which I'd forgotten about it
until
On May 1, 2004, at 8:26 AM, Jarkko Hietaniemi wrote:
So it seems to me that the obvious way to go is to have all bit-s
operations first convert to raw bytes (possibly throwing an exception)
and then proceed to do their work.
If these conversions croak if there are code points beyond \x{ff}, I'm
On May 1, 2004, at 12:00 PM, Aaron Sherman wrote:
On Sat, 2004-05-01 at 14:18, Jeff Clites wrote:
Exactly. And also realize that if you bitwise-not (or shift or
something similar) the bytes of a UTF-8 serialization of something,
the
result isn't going to be valid UTF-8, so you'd be hard-pressed
[Finishing this discussion on p6i, since it began here.]
On Apr 28, 2004, at 5:05 PM, Larry Wall wrote:
On Wed, Apr 28, 2004 at 03:30:07PM -0700, Jeff Clites wrote:
: Outside. Conceptually, JPEG isn't a string any more than an XML
: document is an MP3.
I'm not vehemently opposed to redefining
On Apr 28, 2004, at 5:01 AM, Dan Sugalski wrote:
At 3:17 AM -0700 4/28/04, Jeff Clites wrote:
On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
For example, consider the following:
use Unicode;
open FOO, foo.txt, :charset(latin-3);
open BAR, bar.txt, :charset(big5);
$filehandle = 0;
while
On Apr 28, 2004, at 11:25 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Apr 28, 2004, at 4:57 AM, Bryan C. Warnock wrote:
Does (that which the masses normally refer to as) binary data
fall inside or outside the scope of a string?
Some languages make this very clear
On Apr 30, 2004, at 9:35 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Yes, my intention there was for read-as-strings, you'd push a
string-ification layer onto the stack. For byte-wise IO, you wouldn't.
Ok. I/O maintainers, please jump in.
And my thoughts in this regard
On Apr 30, 2004, at 10:22 AM, Dan Sugalski wrote:
At 2:57 AM +1000 5/1/04, Andre Pang wrote:
Of course Parrot should have a function to reinterpret something of a
string type as raw binary data and vice versa, but don't mix binary
data with strings: they are completely different types, and raw
On Apr 30, 2004, at 9:02 AM, Larry Wall wrote:
On Fri, Apr 30, 2004 at 08:38:18AM -0700, Jeff Clites wrote:
: On Apr 28, 2004, at 5:01 AM, Dan Sugalski wrote:
:
: At 3:17 AM -0700 4/28/04, Jeff Clites wrote:
: On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
:
: For example, consider
On Apr 27, 2004, at 10:25 AM, Dan Sugalski wrote:
At 9:40 AM -0700 4/27/04, Jeff Clites wrote:
On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
CHARACTER SET - Contains meta-information about code points. This
includes both the meaning of individual code points
(65
In light of ongoing discussions of Parrot's string model, I've decided
to prepare a document spelling out my general viewpoint on the subject
of strings. It's intended also to supply a self-consistent set of
terminology. It will frame my future comments. Some notes:
1) This is explicitly
On Apr 28, 2004, at 4:57 AM, Bryan C. Warnock wrote:
{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?
Outside. Conceptually, JPEG isn't a string any more than an XML
document is an
On Apr 26, 2004, at 5:12 AM, Dan Sugalski wrote:
At 9:34 PM -0400 4/25/04, Bryan C. Warnock wrote:
And what about codepoints that *are* glyphs and/but aren't graphemes?
Where do we have those? (I'm getting tempted instead to just call them
fred--it'll at least avoid some of this confusion...)
On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
CHARACTER SET - Contains meta-information about code points. This
includes both the meaning of individual code points
(65 is capital A, 776 is a combining diaresis) as
well as a set of categorizations
On Apr 27, 2004, at 6:57 AM, Dan Sugalski wrote:
So, are we otherwise set on the plan, such that it can be implemented
and we can work on some of the parts that haven't been specified?
I have several questions/comments/concerns, and I'm splitting them up
into bite-sized pieces. I've just sent
On Apr 25, 2004, at 11:01 PM, Piers Cawley wrote:
Jeff Clites [EMAIL PROTECTED] writes:
On Apr 23, 2004, at 11:04 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does $foo = 12 in that context actually mean in Perl6?
Another interesting question is in Perl 6, are variables
On Apr 25, 2004, at 11:59 PM, Luke Palmer wrote:
Jeff Clites writes:
I don't (right off) know of any other language which has something in
between variables and objects. That is, containers. They're feeling a
bit artificial.
Well... Perl 5.
Well, there's that. :)
But--how does that manifest itself
On Apr 23, 2004, at 5:42 AM, Dan Sugalski wrote:
At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
my Joe $foo;
emits the code that, at runtime, finds the class ID of whatever
Joe's
in scope, instantiates a new object of that class
Uh, is that right?
On Apr 23, 2004, at 8:54 AM, Larry Wall wrote:
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: Since any type potentially has assignment behaviour, it has to be a
: constructor. For example, if you've got the Joe class set such that
: assigning to it prints the contents to
On Apr 23, 2004, at 11:04 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does $foo = 12 in that context actually mean in Perl6?
Another interesting question is in Perl 6, are variables typed,
values typed,
or a little of both?
It seems that Parrot has been working
On Apr 21, 2004, at 7:33 PM, Dan Sugalski wrote:
At 11:17 AM -0700 4/21/04, Jeff Clites wrote:
On Apr 21, 2004, at 10:20 AM, Dan Sugalski wrote:
Just to make sure... we're making sure the strings are always
properly decomposed before comparing, right?
Nope, this is a literal equal comparison
On Apr 21, 2004, at 4:52 PM, kj wrote:
- there are (of course) some character sets that don't work well with
Unicode -- for example, Big5HKSCS doesn't encode in UCS2 (though I
didn't find out why)
UCS-2 is limited--it can only address the BMP (that is, only 2^16
characters). It has been
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I do
know it is a legacy charset, but I don't know how much it is still
used. Technically, ASCII is legacy, too. :)
Ah, at this point Unicode's
On Apr 22, 2004, at 9:01 AM, Dan Sugalski wrote:
At 8:51 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I
do know it is a legacy charset, but I don't know
On Apr 20, 2004, at 11:22 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Here's another tiny patch, to let us fast-fail string_equal if we have
cached hashval's which don't match.
What about a hash value collision?
If the hash values are equal, it proceeds on to do the full
On Apr 19, 2004, at 3:41 PM, Marcus Thiesen wrote:
As I'm currently at my fathers place I had the time and resources to
do some cygwin and native win32 testing.
Great!
I can't get it to work under Cygwin since the ICU changes because it
tries to
do some linking stuff that fails
...
Next I
On Apr 20, 2004, at 3:06 PM, Leopold Toetsch wrote:
hyper
Px += 4 # add 4 to each column in data base
How does this look in pasm? Is it supposed to be:
hyper
add P0, 4
or is it:
hyperadd P0, 4
If it's the former, it seems really odd to have an op which modifies
the
On Apr 21, 2004, at 4:05 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Here's another tiny patch, to let us fast-fail string_equal if we have
cached hashval's which don't match.
Tested and applied now. I've also adoped JIT/i386 to use string_equal
for Ceq and Cne string ops
On Apr 21, 2004, at 9:05 AM, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
I'm drawing the distinction between an operation
on the container and an operation on all the
container's contents here. I think it's the right
distinction.
Sure. But the prefix Chyper just is the
On Apr 21, 2004, at 10:14 AM, Leopold Toetsch wrote:
The equal case was missing one thing: if both strings are COWed
copies,
the compare can be avoided too - it's equally fast then, as not
equal.
That makes sense, as long as we never optimize substring via a COW copy
with a different strlen.
On Apr 21, 2004, at 10:20 AM, Dan Sugalski wrote:
At 9:22 AM -0700 4/21/04, Jeff Clites wrote:
On Apr 21, 2004, at 4:05 AM, Leopold Toetsch wrote:
... a factor ~14 performance increase for the not equal case.
Ah, great! (And the not equal case is the only one which should be
showing a speed up
On Apr 19, 2004, at 2:25 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
This change speeds up the attached benchmark by a factor of 1.86 in
the
optimize case (via --optimize, so -Os), or 3.73 in the unoptimized
case
(on Mac OS X):
Wheee, that's a lot.
Here's another tiny patch
The attached patch adds 2 Configure.pl options, to help with the
process of getting ICU to build on platforms which are having
difficulties with it:
% perl Configure.pl --help
...
ICU Options:
--icuplatform=(platform) Platform name to pass to ICU's
runConfigureICU
On Apr 18, 2004, at 8:06 AM, Leopold Toetsch wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote:
[ initial proposal ]
I've now checked in a working version.
* c2str.pl generates a .str header from a .c file
* c2str.pl --all generates $(INC)/string_private_cstring.h
* this us used in string_init()
On Apr 17, 2004, at 1:47 PM, Nicholas Clark (via RT) wrote:
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #28916]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28916
You must use
On Apr 17, 2004, at 6:18 PM, Gordon Henriksen wrote:
Dan Sugalski wrote:
Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
3) Parrot itself (the main executable) has a static, global 1K
buffer in it that starts and ends with some recognizable string
(like, say, ***+++***START| and
On Apr 19, 2004, at 2:25 AM, Leopold Toetsch wrote:
We still can precalculate for these constant strings and save some
extra
cylces (the precalculated value isn't used yet, but ...) And we can
precalculate hash values for the string constants in the constant table
during compilation (and write
On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote:
With all current optimizations[1] I now have these timings:
$ ./bench -b=^oo[234f]
Numbers are relative to the first one. (lower is better)
p-j-Oc perl-th perlpython ruby
oo2 100%182%152%90% 132%
oo3 100%
On Apr 16, 2004, at 11:19 PM, Jeff Clites wrote:
BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's
related:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/gc.t
On Apr 17, 2004, at 12:41 PM, Leopold Toetsch wrote:
This scheme with constant strings in constant memory doesn't work - at
least not with ARENA_DOD_FLAGS enabled, which assumes *all* objects are
coming from arenas. These string headers live outside of any arena.
Oh, yes--darn.
It could work w/o
On Apr 14, 2004, at 11:16 AM, Larry Wall wrote:
I think the idea of tagging complete strings with language is not
terribly useful. If it's to be of much use at all, then it should
be generalized to a metaproperty system for applying any property to
any range of characters within a string, such
On Apr 14, 2004, at 10:20 PM, Jarkko Hietaniemi wrote:
Finding stuff relative to the executable/DLL would be coolest scheme,
but that is admittedly somewhat tricky to get working cross-platform.
Excellent idea. Pretty much every single resource in Cocoa applications
and frameworks on Mac OS X is
On Apr 15, 2004, at 7:24 AM, Dan Sugalski wrote:
Sound sane? I can see splitting up the library base path into
sections, but I'm not sure it's worth it. Now'd be the time to argue
that, though :)
Makes sense to me to just store the path--keep it simple. As long as
we've stored it away,
On Apr 15, 2004, at 8:41 AM, Dan Sugalski wrote:
At 8:35 AM -0700 4/15/04, Jeff Clites wrote:
On Apr 15, 2004, at 7:24 AM, Dan Sugalski wrote:
Sound sane? I can see splitting up the library base path into
sections, but I'm not sure it's worth it. Now'd be the time to argue
that, though
On Apr 15, 2004, at 9:36 AM, Dan Sugalski wrote:
At 8:54 AM -0700 4/15/04, Jeff Clites wrote:
On Apr 15, 2004, at 8:41 AM, Dan Sugalski wrote:
At 8:35 AM -0700 4/15/04, Jeff Clites wrote:
On Apr 15, 2004, at 7:24 AM, Dan Sugalski wrote:
Sound sane? I can see splitting up the library base path
On Apr 15, 2004, at 9:05 AM, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
3) Parrot itself (the main executable) has a static, global 1K buffer
in it that starts and ends with some recognizable string (like, say,
***+++***START| and |END***+++***) so we can find it and
overwrite the
On Apr 15, 2004, at 9:41 AM, Dan Sugalski wrote:
Actually, one thing I'd like to see is if it wasn't the library's base
path hardcoded in, but the base path of a frozen data structure or
program that encoded Parrot's settings. That would allow it to carry
the runtime library path, the paths to
On Apr 15, 2004, at 10:30 AM, Jeff Clites wrote:
And semantically, I think of it not as the executable's path--that
just happens to be something that's 1:1 with a particular copy of
parrot. And definitely not libparrot's path--embedded cases would have
to specify the path explicitly, though
On Apr 15, 2004, at 11:12 AM, George R wrote:
I couldn't help but notice that you were talking about ICU on this
mailing list. Let me interject with some suggestions.
Thanks much for the message.
I should mention that ICU 2.6 can build a static data library. I
recommend that ICU be built
On Apr 15, 2004, at 10:48 AM, Dan Sugalski wrote:
At this point I can say I don't honestly care all that much, and most
of my worries are based on vague feelings that there are platforms out
there where finding the actual executable name is somewhere between
hard and impossible. I will, then,
On Apr 14, 2004, at 7:49 AM, Dan Sugalski wrote:
Just came across an interesting quirk with the current usage of
ICU--if you do it, you can't run parrot unless your current directory
is the base parrot directory. Trying it from elsewhere throws a
string_set_data_directory: ICU data files not
On Apr 12, 2004, at 9:54 AM, Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #28494]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28494
Attached patch:
*
BTW, it doesn't compile on any platform at the moment, after a
realclean on
the first make it complains about
../data/locales/ja.txt:15: parse error. Stopped parsing with
U_INVALID_FORMAT_ERROR
couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR
make[1]: ***
On Apr 12, 2004, at 4:40 AM, Marcus Thiesen wrote:
Another thing, which is not really bad but I run into at the moment is
that on
the system where I run my Cygwin tests the homedir actually is named
/home/Gerd Jutta, which are the names of my father and his
girlfriend who
own the machine and
On Apr 13, 2004, at 7:18 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
1) My version handles the case of code points 0x as well.
It's simple now to change that code to include this. I've not done it
yet to keep this patch smaller, which includes #28473 too. My version
On Apr 13, 2004, at 8:35 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
One other thing occurred to me, to save a few bytes: When upscaling,
rather than passing clength, we can pass (result-strlen + number of
bytes left in cstring).
If I read that correctly, s-strlen (or clength
On Apr 11, 2004, at 7:05 PM, Jeff Clites wrote:
On Apr 11, 2004, at 4:52 PM, Jonathan Worthington wrote:
On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote:
I'm having a crack at getting the ICU changes building on Win32.
--
Failed Test Status Wstat Total Fail Failed List
On Apr 12, 2004, at 5:33 AM, Jonathan Worthington wrote:
snip
See if you have a .dat file (or a bunch of individual files) in
blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then
that's what's going on. Right now, I have that path hard-coded--of
course I need to pull that out
On Apr 12, 2004, at 6:37 AM, Dan Sugalski wrote:
I'll try and get patches to use the system ICU install if there is one
done today.
Also take a look at my [perl #28473], which I don't think has made it
to the list yet. That's a patch to make the location of ICU's data
directory configurable,
That's really funny--I wrote almost exactly the same code w.r.t.
string_unescape_cstring last night, and I also always use U+212b for
testing any time I need to come up with a readable character outside of
the Latin range. Strange coincidences.
I'll take a look and see if there is anything
I'm going to write up some information on my view of strings, and the
rationale behind it, so that there's a clear explanation that we can
use for discussion. That will give us something more organized to talk
about. It will probably take a day or two for me to get that done.
I'll also respond
On Apr 12, 2004, at 10:23 AM, Dan Sugalski wrote:
At 10:14 AM -0700 4/12/04, Jeff Clites wrote:
I'm going to write up some information on my view of strings, and the
rationale behind it, so that there's a clear explanation that we can
use for discussion. That will give us something more
On Apr 11, 2004, at 7:12 AM, Alberto Manuel Brandao Simoes wrote:
If it's still failing, then something else is going on.
If it is, then there's one more thing to try:
1) cd into icu/source/data/out/build
2) Execute this (which will create ja.res in /var/tmp if it succeeds):
On Apr 11, 2004, at 12:17 PM, Will Coleda wrote:
This is with a checkout post-ICU, on an OSX with a 1/2 gig of RAM.
bash-2.05a$ make test
SNIP
Failed Test Stat Wstat Total Fail Failed List of Failed
---
On Apr 11, 2004, at 12:38 PM, Alberto Manuel Brandao Simoes wrote:
Some more info...
Thanks!
Jeff Clites wrote:
Hmm, strange indeed. Looking at the ICU code, it appears that it's
not finding a data file it needs at this stage (the error message is
misleading)--I wonder if something failed
On Apr 11, 2004, at 1:54 PM, Alberto Manuel Brandao Simoes wrote:
Jeff,
I am a little lost in that code as you might imagine :-)
I am a bit as well--I basically went looking for the error message, and
have been trying to figure out where in the code the error is actually
originating.
On Apr 11, 2004, at 3:15 PM, Alberto Manuel Brandao Simoes wrote:
Here we go,
It's probably okay. It's alright to close the fd after the mmap, and
it's not really calling mmap twice--it's just the debugger trying to
follow the optimized code.
OK, Just my ignorance :-)
Nope--normally one tries
On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote:
I'm having a crack at getting the ICU changes building on Win32.
Great--thanks!
Here's the first step. string.c did some C99 stuff:-
* Declared variables at places other than the top of a block
Sorry about that.
* Used uint8_t, uint16_t,
On Apr 10, 2004, at 1:12 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Apr 9, 2004, at 7:19 AM, Leopold Toetsch wrote:
So internally, strings don't have an associated encoding (or chartype
or anything)
How do you handle EBCDIC?
I'll use pseudo-C to illustrate:
string
On Apr 10, 2004, at 2:40 AM, Leopold Toetsch wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
Not used *yet* - what about:
use German;
print uc(i);
use Turkish;
print uc(i);
That is implementable (and already implemented by ICU) but by
something
higher level than a string.
So the
On Apr 10, 2004, at 3:19 AM, Jarkko Hietaniemi wrote:
We'll basically need 4 levels of string support:
,--[ Larry Wall
]
| level 0 byte == character, use bytes basically
| level 1 codepoint == character, what we seem to be aiming for,
On Apr 10, 2004, at 6:04 AM, Leopold Toetsch wrote:
Michael Scott [EMAIL PROTECTED] wrote:
I notice that on OS X t/native_pbc/number.t is no longer skipped and
is
failing. I'm wondering if this is intentional?
It's already disabled. Changed string PBC format makes native_pbc tests
failing as
On Apr 10, 2004, at 3:54 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Apr 10, 2004, at 1:12 AM, Leopold Toetsch wrote:
use German;
print uc(i);
use Turkish;
print uc(i);
Perfect example. The string i is the same in each case. What you've
done is implicitly
On Apr 10, 2004, at 12:21 PM, Jeff Clites wrote:
On Apr 10, 2004, at 3:54 AM, Leopold Toetsch wrote:
Ok. I want to uppercase the strings - no sorting (yet). I've an array
of
Vienna's Kebab boothes. Half of these have turkish names (at least)
the
rest is a mixture of other languages. I'd like
On Apr 10, 2004, at 6:13 AM, Leopold Toetsch wrote:
2) String PBC layout. The internal string type has changed. This
currently breaks native_pbc tests (that have strings) as well as some
parrot xx.pbc tests related to strings.
These are working for me (which tests are failing for you?)--I did
101 - 200 of 321 matches
Mail list logo
