On Sat, 2004-04-10 at 20:13, Jeff Clites wrote:
(accidentally sent only to Jeff earlier)
> Since the ICU static libs (".a"s) have C++ inside, we need to link with
> a C++-aware linking. Try setting:
>
>link => 'c++'
>
> in config/init/hints/linux.pl and see if that fixes it. The error
> y
>>This is GCC on Gentoo: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4
>>3.2.3-r4, propolice).
>
>
> Since the ICU static libs (".a"s) have C++ inside, we need to link with
> a C++-aware linking. Try setting:
>
>link => 'c++'
>
> in config/init/hints/linux.pl and see if that fixes it.
Yeah,
This patch seems both harmless and helpful.
I give it a thumbs up.
--
Will "Coke" Coledawill at coleda
dot com
# New Ticket Created by Will Coleda
# Please include the string: [perl #28449]
# in the subject line of all future correspondence about this issue.
# 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 in m
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 lexica
"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, c
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
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, propo
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
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 configu
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
U_INVALID_FORMAT_ERR
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 widespr
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 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
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: par
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 to
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 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 implicit
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 value
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 w
On Monday, March 15, 2004, at 11:05 , Larry Wall wrote:
On Mon, Mar 15, 2004 at 07:54:09PM -0700, Luke Palmer wrote:
Larry Wall writes:
And basically because I decided :foo('bar') is too ugly for something
that will get used as often as switches are on the unix command line.
The %hash syntax
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
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, Leopol
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 notic
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 r
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
> What is a list reference?
> What is an array?
...
> What is a list?
Hi Juerd,
There was a thread on this not long ago. I forgot it's name.
Apo 2 said:
[1,2,3]
is syntactic sugar for something like:
scalar(list(1,2,3))
... suggesting that lists could have references taken to them, much
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
> 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 C where it's needed?
>
> e.g.
>
> use German;
> my $gi = "i";
> use Turkish;
> my $ti =
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 th
>
> (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.)
> 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 logica
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.
> >
>
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,
va
> 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/.
>>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
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".
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 = str
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:
>>
>
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
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
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 ov
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 Parrot
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 loo
> 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
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? UTF8 for Ponie?
>> - Where is string->language?
> I removed it from the string struct beca
FWIW, the change sounds all good to me. The O(1) is the most important
property of a string, the 8/16/32 gives us that and space savings too,
going all Unicode at the heart of it is the only sensible thing to do
(anything else leads into combinatorial explosion and instant insanity),
"encodings" a
47 matches
Mail list logo
