Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:22 PM +0200 4/13/04, Leopold Toetsch wrote:
>>Marcus Thiesen wrote:
>>>. Seems as if something doesn't get cleaned up in icu with a parrot
>>>realclean.
>>
>>Yep. I've removed cleaning icu from clean/realclean[1].
> I think we need to put that back fo
At 6:22 PM +0200 4/13/04, Leopold Toetsch wrote:
Marcus Thiesen wrote:
. Seems as if something doesn't get cleaned up in icu with a parrot
realclean.
Yep. I've removed cleaning icu from clean/realclean[1].
I think we need to put that back for a bit, but with this:
[1] If anyone puts that in again
Marcus Thiesen wrote:
. Seems as if something doesn't get cleaned up in icu
with a parrot realclean.
Yep. I've removed cleaning icu from clean/realclean[1].
$ make help | grep clean
...
icu.clean: ...
And there is always "make cvsclean".
Have fun,
Marcus
leo
[1] If anyone puts that in
On Tuesday 13 April 2004 13:28, luka frelih wrote:
> just a confirmation...
> my i386 debian linux gives the same error repeatedly after make
> realclean,
> if i make again, it compiles a broken parrot which fails (too) many
> tests...
>
> also it seems (to me) that parrot's configured choice of co
just a confirmation...
my i386 debian linux gives the same error repeatedly after make
realclean,
if i make again, it compiles a broken parrot which fails (too) many
tests...
also it seems (to me) that parrot's configured choice of compiler,
linker, ... is not used in building icu?
does icu ha
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]: *** [../data/out/build/icudt26l_
On Saturday 10 April 2004 15:13, Leopold Toetsch wrote:
> There is of course still the question: Should we really have ICU in the
> tree. This needs tracking updates and patching (again) to make it build
> and so on.
In the sake of platform independence I'd say to keep it there. It's far easier
i
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Here's a patch to src/pf_items.c, and a ppc t/native_pbc/number_3.pbc.
Works.
> If it's working correctly, the attached strings-and-byte-order.* should
> both do the same thing--output the Angstrom symbol. If it's wrong, then
> the pbc version should outp
Jeff Clites <[EMAIL PROTECTED]> 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 workin
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 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
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
12 matches
Mail list logo
