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,
Jeff Clites [EMAIL PROTECTED] wrote:
On Apr 9, 2004, at 7:19 AM, Leopold Toetsch wrote:
I'm replying for Jeff since I've been burned by the same questions
over and over again :-)
So internally, strings don't have an associated encoding (or chartype
or anything)
How do you handle
Chromatic [EMAIL PROTECTED] wrote:
On Fri, 2004-04-09 at 04:56, Leopold Toetsch wrote:
new Pobj, Iclass, PInit
This initializer is available as first param in the init method.
I'm happy with this.
Good.
... A similar scheme will work nicely for
deconstructors.
(I looked for where
Dan Sugalski wrote:
Done. It'll guaranteed kill half the tinderboxen--I think my first thing
to do on monday is to patch up the build procedure to use the system ICU
if it's available.
Thanks for checkin. And yes. What about building without ICU? I can
imagine that some embedded usage of
Andy Dougherty wrote:
On Fri, 9 Apr 2004, Leopold Toetsch wrote:
$ parrot parrot-config.imc --summary
could provide it.
It was my intent that the 'myconfig' file (currently written by
Configure.pl) would contain this sort of information
I think we need:
- myconfig (bug reports, quick textual
Jens Rieks wrote:
I vote for:
- runtime/parrot/library
- t/library
Ok.
If parrot is modified to search files in runtime/parrot, everything should
continue to work with the paths currently in use.
I'll have a look at that.
I can have a look at it after the 16th, have to learn for two written
Jonathan Worthington wrote:
* Used uint8_t, uint16_t, uint32_t, which we don't exists in MS VC++
Thanks applied. C99ish decls were alredy fixed.
Jonathan
leo
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
How do you handle EBCDIC? UTF8 for Ponie?
All character sets (like EBCDIC) or encodings (like UTF-8) are
normalized to the Unicode (character set) (and our own *internal*
encoding, the 8/16/32 one.)
Ok.
Not used *yet* - what about:
use
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
We'll basically need 4 levels of string support:
,--[ Larry Wall
]
| level 0byte == character, use bytes basically
| level 1codepoint == character, what we seem to be aiming for,
vaguely
| level 2grapheme == character,
So the first question is: Where is this higher level? Isn't Parrot
responsible for providing that? The old string type did have the
relevant information at least.
I think we can't say it's a Perl6 lib problem. HLL interoperability
Right. It's a Parrot lib problem. But it's not a .c/.cpp
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 Fri, Apr 09, 2004 at 03:02:00PM +0200, Jens Rieks wrote:
Hi,
On Thursday 08 April 2004 23:49, Tim Bunce wrote:
On Thu, Apr 08, 2004 at 08:28:49PM +0200, Jens Rieks wrote:
Data::Replace replaces every occurrence of one PMC in a nested data
structure with another PMC.
I'm not sure
Another example could be that at level 2 (and 3), maybe eq
automatically normalizes before doing string comparisons, and at levels
1 and 0 it doesn't.
Exactly. People wanted implicit eq normalization for Perl 5 Unicode.
The problem always is where does it end?, because the logical
(We've learnt the hard way with Perl5 modules names that more words are good.
And more words that mean something... Data ranks right up there as the
worst possible names for anything.
Keeping module names very short is a false economy.)
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 supplied a locale argument to the uc()
Ok. Now when the identical string i (but originating from different
locale environmets) goes through a sequence of string operations later,
how do you track the locale down to the final Cuc where it's needed?
e.g.
use German;
my $gi = i;
use Turkish;
my $ti = i;
$gi
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?
Looking into this I noticed that 'make pdump' fails because it needs
ICU.
Here's a patch for config/gen/makefiles/root.in.
root_in.patch
Description: Binary data
Mike
They used to be there after make test. Gone. Which isn't good. After a
failed test I'd like to run the PASM or PIR manually through parrot.
leo
1) Allow usage of installed libicu. Needs some config support to locate
the necessary includes. Libraries should be found automatically.
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
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 well as make testr.
Looking into this I noticed
That'd be my fault.
The files are probably currently in /tmp. The offending lines are 273
- 276 in lib/Parrot/Test.pm, cvs latest. I peeled off the file name of
the generated .pasm, and stuck the file in the temp directory.
Sorry about that.
On Saturday, April 10, 2004, at 08:45 AM, Leopold
On 10 Apr 2004, at 15:04, Leopold Toetsch wrote:
Not only pdump. All utils built by make world. I'd suggest to include
an $(ALL_PARROT_LIBS) to each target.
+ $(LIBPARROT) $(LIBICUCORE) $(LIBICUDATA) $(C_LIBS)
instead of that.
Ok. I'll do that and commit it.
Mike
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
Hi,
I am writing a PerlPair PMC and I have a problem with an
optimization. BTW: probably a modified PerlPair could be used
to implement lisp cons pairs and the optimization will be even
more useful because of the widespread use of pairs.
The optimization: I want to avoid storing a key or or
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
Hi
I am not needing parrot (just checking its state) but compilation
failed. Don't know if it is expected or not. In any case, this might be
useful:
../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
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
Le Sat, Apr 10, 2004 at 08:33:04PM +0100, le valeureux mongueur Alberto Manuel Brandao
Simoes a dit:
Hi
I am not needing parrot (just checking its state) but compilation
failed. Don't know if it is expected or not. In any case, this might be
useful:
../data/locales/ja.txt:15: parse
On Apr-09, Will Coleda wrote:
Subject: [perl #16414] [PATCH] Interpreter PMC
Created: 2004-04-09 02:59:29
Content: There is now a ParrotInterpreter class which seems to provide
most of this functionality
- Is there anything you feel is still missing, or can we resolve the
call?
Seems good
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
On Sat, Apr 10, 2004 at 09:08:22PM -0400, Stéphane Payrard wrote:
Hi,
I am writing a PerlPair PMC and I have a problem with an
optimization. BTW: probably a modified PerlPair could be used
to implement lisp cons pairs and the optimization will be even
more useful because of the widespread
On Apr 10, 2004, at 12:33 PM, Alberto Manuel Brandao Simoes wrote:
I am not needing parrot (just checking its state) but compilation
failed. Don't know if it is expected or not. In any case, this might
be useful:
../data/locales/ja.txt:15: parse error. Stopped parsing with
I'm unable to build Parrot with the new ICU changes. It appears to fail
in the linking step. I've attached the error output as well as myconfig
and my Perl 5 config.
This is GCC on Gentoo: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4
3.2.3-r4, propolice).
-- c
Summary of my parrot 0.1.0
My understanding of the semantic of pairs as in A6:
A pair in a given scalar context should return its first element
coerced to match the said context.
This seems to be a prerequisite to use pairs as function arguments.
Example with the boolean context:
bool $b = a = 10; # $b == 1
On Apr 10, 2004, at 5:43 PM, chromatic wrote:
I'm unable to build Parrot with the new ICU changes. It appears to
fail
in the linking step. I've attached the error output as well as
myconfig
and my Perl 5 config.
This is GCC on Gentoo: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4
3.2.3-r4,
On Apr 10, 2004, at 1:12 PM, Jeff Clites wrote:
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
They tried and failed?
No, they tried and died.
Ok, it's not that bad, but it doesn't seem to work. I moved the .pmcs
(same files in previous attachment) over to ./dnyclasses, updated the
Makefile as directed in dynclasses/README.
To undo their previous inclusion, I did a make realclean,
On Sat, Apr 10, 2004 at 01:19:39PM +0300, Jarkko Hietaniemi wrote:
: I'm no Larry, either :-) but I think Larry is *not* saying that the
: localeness or languageness should hang off each string (or *shudder*
: off each substring). What I've seen is that Larry wants the level to
: be a lexical
# New Ticket Created by Will Coleda
# Please include the string: [perl #28449]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28449
This is most assuredly an incomplete patch - but since src/dynext.c is
searching
This patch seems both harmless and helpful.
I give it a thumbs up.
--
Will Coke Coledawill at coleda
dot com
42 matches
Mail list logo
