FWIW
Since release 2023.02, there's a Unicode class, with a class method .version:
$ raku -e 'say Unicode.version'
v15.0
> On 9 Dec 2024, at 15:36, William Michels wrote:
>
> Nudging this conversation, ...to follow progress since 2020.
>
> Anyone want to chime it?
>
> Is a $*UNICODE dynamic
Nudging this conversation, ...to follow progress since 2020.
Anyone want to chime it?
Is a $*UNICODE dynamic variable a possibility?
Related: I'm re-reading Matéu's comment, which (I think) says to let ICU live
in a module somewhere.
Best Regards, Bill.
> On Sep 29, 2020, at 21:19, Matthew
In #raku it was mentioned that it would be nice to have a $*UNICODE variable of
sorts that reports back the version, but not sure how that would be from an
implementation POV.
I'm also late to the discussion, so pardon me jumping back a bit. Basically,
ICU is something that lets you quickly ad
Thank you, Samantha!
An outstanding question is one posed by Joseph Brenner--that
is--knowing which version of the Unicode standard is supported by
Raku. I grepped through two files, one called "unicode.c" and the
other called "unicode_db.c". They're both located in rakudo at:
/rakudo/rakudo-2020.
So MoarVM uses its own database of the UCD. One nice thing is this can
probably be faster than calling to the ICU to look up information of each
codepoint in a long string. Secondly it implements its own text data
structures, so the nice features of the UCD to do that would be difficult to
use.
On Fri, Sep 25, 2020 at 12:37:49PM +0200, Elizabeth Mattijsen wrote:
> > On 25 Sep 2020, at 04:25, Brad Gilbert wrote:
> > Rakudo does not use ICU
> >
> > It used to though.
> >
> > Rakudo used to run on Parrot.
> > Parrot used ICU for its Unicode features.
>
> I do remember that in the Parrot
> On 25 Sep 2020, at 04:25, Brad Gilbert wrote:
> Rakudo does not use ICU
>
> It used to though.
>
> Rakudo used to run on Parrot.
> Parrot used ICU for its Unicode features.
Ah, the days.
I do remember that in the Parrot days, any non-ASCII character in any string,
would have a significant n
Rakudo does not use ICU
It used to though.
Rakudo used to run on Parrot.
Parrot used ICU for its Unicode features.
(Well maybe the JVM backend does currently, I don't actually know.)
MoarVM just has Unicode as one of its features.
Basically it has something similar to ICU already.
---
The pur
I think more to the point is which version of Unicode is supported,
rather than the ICU libraries. It might be worth writing some tests
that check that Raku's unicode handling matches the ICU libraries.
On 9/24/20, William Michels wrote:
> Thanks everyone for the replies. I guess the two questi
Thanks everyone for the replies. I guess the two questions I have
pertain mainly to 1) lineage and 2) versioning:
Regarding lineage, I'm interested in knowing if
Pugs/Parrot/Niecza/STD/Perlito/viv/JVM/Rakudo ever used the ICU
Libraries--even if now that data has been extracted into a Raku-native
d
Elizabeth Mattijsen wrote:
> https://www.codesections.com/blog/raku-unicode/
Thanks, yes I was just reading through that. It makes it clear that
the "Unicode Character Database" is built-in to the MoarVM, but I'm
not that clear what the ICU libraries do for you, and I thought there
might be some
https://www.codesections.com/blog/raku-unicode/
> On 24 Sep 2020, at 20:00, Joseph Brenner wrote:
>
> I'm not sure myself, but my first guess would be probably not...I
> *think* Raku is doing it's own Unicode thing, and isn't using any
> system ICU libraries (but I'm willing to stand corrected
I'm not sure myself, but my first guess would be probably not...I
*think* Raku is doing it's own Unicode thing, and isn't using any
system ICU libraries (but I'm willing to stand corrected on that).
As far as perl (the-language-formerly-known-as-perl5) is concerned:
That page http://site.icu-pro
Jarkko Hietaniemi wrote:
3) we could probably lift the restriction that we link with c++
I replaced LINK = c++ with LINK = cc in the Makefile and it works.
Maybe I'm missing some previous discussion but as long as we are linking
ICU in, there is no way that any other linker than the C++ compiler
w
--- Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > ICU libs are in /usr/local/lib
>
> > /usr/local/lib is in my path
>
> Which "path"? Do you mean LD_LIBRARY_PATH or do
> you mean PATH?
>
> PATH is irrelevant. That's the set of directories
> used by /bin/sh
> (or equivalent) to find executable
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> >> All tests pass normally, but I get 3 tests
> failing
> >> under JIT
> >>
> >> t/op/interp.t #7
> >> t/pmc/coroutine.t #10
> >> t/pmc/exception.t #19
>
> > ok, so I did investigate a little further.
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
>> All tests pass normally, but I get 3 tests failing
>> under JIT
>>
>> t/op/interp.t #7
>> t/pmc/coroutine.t #10
>> t/pmc/exception.t #19
> ok, so I did investigate a little further. make testj
> works fine (all tests pass) if I don't pass the
> --o
--- Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
> ok, so I did investigate a little further. make
> testj
> works fine (all tests pass) if I don't pass the
> --optimize flag to Configure.pl.
Ok, so optimizations break things - why not add more.
Interestingly, adding more aggressive options mak
--- Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
>
> --- Joshua Gatcomb <[EMAIL PROTECTED]>
> wrote:
>
> >
> > 1. Transfer ICU 3.0 and build from source
> > 2. Do a fresh CVS checkout of parrot, transfer
> and
> > build
> >
> > $ perl Configure.pl --optimize
> >
> >
> > $ make
> >
> >
> >
--- Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
>
> 1. Transfer ICU 3.0 and build from source
> 2. Do a fresh CVS checkout of parrot, transfer and
> build
>
> $ perl Configure.pl --optimize
>
>
> $ make
>
>
> c++ -o parrot -L/usr/local/lib -Wl,-E -g imcc/main.o
> blibl/lib/libparrot.a -lnsl
On Oct 8, 2004, at 9:24 AM, Jeff Clites wrote:
On Oct 8, 2004, at 9:03 AM, Steve Fink wrote:
If I just do
perl Configure.pl
make
right now, it builds the parrot executable ok but then fails when it
tries to compile the library .imc files. It's looking for the icu data
dir in $(prefix)/blib/lib/
Steve Fink <[EMAIL PROTECTED]> wrote:
> If I just do
> perl Configure.pl
> make
> right now, it builds the parrot executable ok but then fails when it
> tries to compile the library .imc files. It's looking for the icu data
> dir in $(prefix)/blib/lib/2.6.1. It works if I do
Well, that's an
On Oct 8, 2004, at 9:03 AM, Steve Fink wrote:
If I just do
perl Configure.pl
make
right now, it builds the parrot executable ok but then fails when it
tries to compile the library .imc files. It's looking for the icu data
dir in $(prefix)/blib/lib/2.6.1. It works if I do
perl Configure.pl --p
At 4:40 PM +0200 8/9/04, Paolo Molaro wrote:
If people are interested, we might be able to cooperate to develop a
library which does just that (unicode string collation) and which
could be imported and used both in mono and parrot (with minimal or no
changes).
From the mono point of view, the licen
On 08/03/04 Leon Brocard wrote:
> IIRC the mono people wrote their own, but with the ICU data files.
> Apart from license issues, this might be an interesting thing to look
> at.
We use some of the ICU data files for locale info like day/month names,
date/time formats etc. We have a tool that take
On Tue, Aug 03, 2004 at 11:32:33PM +0100, Alex Gough wrote:
> For what it's worth, I checked a parrot out for the first time in ages
> a couple of days ago (the Shub-tuit gives, as the Shub-tuit takes
> away...), but got all stuck failing to work out how to get icu not to
> be a problem, and so get
Josh Wilmes wrote:
If someone's got the time and I spec out the encoding and charset
APIs, I'd be thrilled if ICU became optional again. Wouldn't hurt my
feelings at all. We need it, because we need Unicode, but it doesn't
have to be required.
We'll need something that isn't ICU if we're going t
At 18:46 on 08/03/2004 EDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If someone's got the time and I spec out the encoding and charset
> APIs, I'd be thrilled if ICU became optional again. Wouldn't hurt my
> feelings at all. We need it, because we need Unicode, but it doesn't
> have to be req
At 7:22 PM +0100 8/3/04, Alberto Manuel Brandao Simoes wrote:
Although I sent this ideas to this list, with another subject, here
they go again to enter in the correct thread.
I think that to have ICU included both in CVS and tarballs created
for parrot is not the best way. I know Dan (and maybe
Although I sent this ideas to this list, with another subject, here they
go again to enter in the correct thread.
I think that to have ICU included both in CVS and tarballs created for
parrot is not the best way. I know Dan (and maybe some others) do not
want to depend on too much libraries. Th
[Tue, Aug 03, 2004 at 07:45:57PM +0100: Nicholas Clark]
> On Tue, Aug 03, 2004 at 03:09:02PM +0100, Leon Brocard wrote:
> > Dan Sugalski sent the following bits through the ether:
> >
> > > If someone's tempted to do 3) Write our own Unicode system, I'm OK
> > > with that too. The string int
On Tue, Aug 03, 2004 at 03:09:02PM +0100, Leon Brocard wrote:
> Dan Sugalski sent the following bits through the ether:
>
> > If someone's tempted to do 3) Write our own Unicode system, I'm OK
> > with that too. The string internals doc needs writing, and I can get
> > that done.
>
> IIRC the m
Joshua Gatcomb wrote:
> Dan Sugalski wrote:
> > ... and therefore ICU will continue to stay in CVS as part of
> > parrot. Period.
> >
> > The alternative here is the same alternative as with GMP and big
> > numbers--we can yank ICU *if* someone writes an alternate Unicode
> > implementation for
Dan Sugalski sent the following bits through the ether:
> If someone's tempted to do 3) Write our own Unicode system, I'm OK
> with that too. The string internals doc needs writing, and I can get
> that done.
IIRC the mono people wrote their own, but with the ICU data files.
Apart from license
At 6:20 AM -0700 8/3/04, Joshua Gatcomb wrote:
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
... and therefore ICU will continue to stay in CVS
as part of parrot. Period.
The alternative here is the same alternative as with
GMP and big numbers--we can yank ICU *if* someone
writes an alternate Un
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... and therefore ICU will continue to stay in CVS
> as part of parrot. Period.
>
> The alternative here is the same alternative as with
> GMP and big numbers--we can yank ICU *if* someone
> writes an alternate Unicode implementation for us.
> --
>
At 9:58 AM +0200 8/1/04, Leopold Toetsch wrote:
Jerry Gay <[EMAIL PROTECTED]> wrote:
Leopold Toetch wrote:
Both ways - or better three stages: Its optional. If its
there, we *can* link against it. If you want/need it, and
your OS doesn't have it, well, then install it.
and if you don't want
Jerry Gay <[EMAIL PROTECTED]> wrote:
> Leopold Toetch wrote:
>> Both ways - or better three stages: Its optional. If its
>> there, we *can* link against it. If you want/need it, and
>> your OS doesn't have it, well, then install it.
>>
> and if you don't want it you get... what?
> no unicode supp
Leopold Toetch wrote:
> Both ways - or better three stages: Its optional. If its
> there, we *can* link against it. If you want/need it, and
> your OS doesn't have it, well, then install it.
>
and if you don't want it you get... what?
no unicode support? a hand-rolled solution?
just what is th
Joshua Gatcomb wrote:
For some reason (likely because it was friday), what I
was thinking in my head was not what was coming out on
the screen in front of me. The "make ICU optional"
was supposed to read "make ICU like GMP" - autodetect
it if present, but do not force it upon the user.
Both ways -
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> > All:
> > The ICU that is bundled with Parrot is old.
>
> > George Rhoten, an ICU developer, has suggested we
> > start shipping version 3.0 because:
>
> > B. Make ICU optional.
>
> Yes. And I'll vot
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> All:
> The ICU that is bundled with Parrot is old.
> George Rhoten, an ICU developer, has suggested we
> start shipping version 3.0 because:
> B. Make ICU optional.
Yes. And I'll vote for just tossing icu/* from Parrot CVS. If one wants
to build Parro
On Sat, 26 Jun 2004, Nicholas Clark wrote:
> What's the task list for being able to upgrade ICU to something current?
> This is pissing me off sufficiently that I WILL DO IT once I know what it is.
>
> The one we've got is an albatross. It can't build with g++ on AIX
> (because it has IBM compiler
On Mon, 3 May 2004, Dan Sugalski wrote:
> At 4:00 PM +0200 5/2/04, Marcus Thiesen wrote:
> >it seems as if the ICU makefiles don't work that well with BSD style makes
> >like the one in OpenBSD core and NetBSD. As I'm no makefile expert it's quite
> >hard for me to fix this, don't know if it is po
Ron Blaschke wrote:
> Did just that some time ago, but with version 2.8. It's as simple as
In case anyone was wondering - this doesn't work on Cygwin. It was among
the many things I have tried. It links but then coredumps when ./parrot
config_lib.pasm is executed. Oh, and using the latest deve
Dan Sugalski wrote:
> Okay, folks, our base ICU as we ship with parrot just flat-out
> doesn't seem to work with cygwin
I figured I would add my lessons learned here so that people don't have to
start from scratch.
ICU's static only implementation (Win32) has not been completed and likely
will
On Mon, 03 May 2004 10:32:33 -0700, Chromatic wrote:
>> BTW, current test results on win32 are:
>> Failed 1/102 test scripts, 99.02% okay. 3/1519 subtests failed, 99.80%
> Can you run these outside of the harness and post the results? Here's
> the command I'd use on Unix with the path separators
On Mon, 2004-05-03 at 10:08, Ron Blaschke wrote:
> BTW, current test results on win32 are:
> Failed 1/102 test scripts, 99.02% okay. 3/1519 subtests failed, 99.80%
> okay.
> Failed Test Stat Wstat Total Fail Failed List of Failed
>
On Mon, 3 May 2004 11:25:30 -0400, Dan Sugalski wrote:
> Okay, folks, our base ICU as we ship with parrot just flat-out
> doesn't seem to work with cygwin, and it seems somewhat spotty with
> basic windows.
Things get really messy with Visual Studio 2003.
> The answer would seem to be "Use a s
At 4:00 PM +0200 5/2/04, Marcus Thiesen wrote:
it seems as if the ICU makefiles don't work that well with BSD style makes
like the one in OpenBSD core and NetBSD. As I'm no makefile expert it's quite
hard for me to fix this, don't know if it is possible in a platform
independent manner.
This is a k
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 tri
Your concerns are valid for versions of ICU before 3.0. ICU 3.0 will
allow you to build with Cygwin with gcc or MSVC's cl compiler.
The toolutil library is located in icu/source/tools/toolutil. If you
used the --disabled-shared configure option as Parrot's README states
(not ICU's readme), yo
At 9:18 PM -0400 4/17/04, 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 "|END***+++
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 "|END**
On Thursday, April 15, 2004, at 02:25 , Jeff Clites wrote:
For Unix platforms at least, you should be able to do this:
executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
That absolutely does not work, as already pointed out. Ths looks like a
reasonable reference implementation (L
On Saturday, April 17, 2004, at 02:17 , Gordon Henriksen wrote:
On Thursday, April 15, 2004, at 02:25 , Jeff Clites wrote:
For Unix platforms at least, you should be able to do this:
executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
That absolutely does not work, as already poin
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 "|END***+++***") so we can find it and
overwrite the content
On Saturday, April 17, 2004, at 10:35 , Gordon Henriksen wrote:
Which suggests to me a linked list of resource resolvers. First one in
the chain to return a file handle to the data or PBC wins. The head of
parrot's own "system" chain would be available to be appended to any
other chains that wa
On Thursday, April 15, 2004, at 01:48 , 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 wil
On Apr-14, Jeff Clites wrote:
> For Unix platforms at least, you should be able to do this:
>
> executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
Nope.
sub executablePath {
return dirname($0) if isAbsolute($0);
return cwd().dirname($0) if hasSlash($0);
foreach
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, d
Jeff Clites wrote:
On Apr 15, 2004, at 11:12 AM, George R wrote:
I went with the --with-data-packaging=archive initially for 3
pragmatic reasons: (1) it seems to take a really, really long time to
build them into a library, and (2) once parrot "ships", if we use
--with-data-packaging=archive o
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 with
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 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 IC
At 10:23 AM -0700 4/15/04, Jeff Clites wrote:
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
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
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>> "***+++***START|" and "|END***+++***") so we can find it and overwrite
> That's pretty disgusting, but I don't know that I have a better idea.
Same scheme as with fingerprint.c?
leo
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 in
> Well, yeah, but... where the executable is ought, honestly, to be
> irrelevant. If I've stuck Parrot in /usr/bin it seems unlikely that
> I'll have parrot's library files hanging off of /usr/bin.
Bah. BAH, I say. The /usr/bin/parrot is of course a symlink
to, say, /platform/os/version/parrot
Dan Sugalski wrote:
#3, I should point out, will *only* be used on those platforms that
don't have a better scheme, and only by the
Parrot_get_base_library_path() function.
System registry on Windows? /etc file on Unixen?
That's global. Bad idea, it messes up multiple installs of the same
versi
At 9:05 AM -0700 4/15/04, 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 cont
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 into
sections, but I'm not sure it's worth it. Now'
Dan Sugalski wrote:
1) We add a Parrot_set_library_base(char *lib_path, int length) function
to set the base library path
2) We add a Parrot_get_base_library_path() function to the
platform-specific interface so platforms can return the base path
Works for me...
3) Parrot itself (the main execut
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 :)
Makes sense to me to just store the path--keep it simpl
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 :)
Makes
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, anything
On Apr 15, 2004, at 3:03 AM, Nicholas Clark wrote:
But all this is from memory, and in turn for #! invocation one can
always
parse the #! line to work out where the interpreter was (mmm. race
condition)
And a race isn't too bad here actually--even if we know the path
reliably, it's always possib
At 6:23 PM +0300 4/15/04, Jarkko Hietaniemi wrote:
Dan Sugalski wrote:
At 8:20 AM +0300 4/15/04, Jarkko Hietaniemi wrote:
TT (Tangentially Topical): it would be nice if Parrot could avoid as
many hardcoded paths as possible for configs, libraries, and such, so
that the Parrot installation could b
Dan Sugalski wrote:
> At 8:20 AM +0300 4/15/04, Jarkko Hietaniemi wrote:
>
>>TT (Tangentially Topical): it would be nice if Parrot could avoid as
>>many hardcoded paths as possible for configs, libraries, and such, so
>>that the Parrot installation could be relocated as freely as possible.
>
>
>
At 8:20 AM +0300 4/15/04, Jarkko Hietaniemi wrote:
TT (Tangentially Topical): it would be nice if Parrot could avoid as
many hardcoded paths as possible for configs, libraries, and such, so
that the Parrot installation could be relocated as freely as possible.
Well, then...
Given that everyone's w
On Wed, Apr 14, 2004 at 11:25:22PM -0700, Jeff Clites wrote:
> For Unix platforms at least, you should be able to do this:
>
> executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
>
> (to mix a bunch of syntaxes)
>
> during initialization before you've had a chance to c
"Jeff Clites" <[EMAIL PROTECTED]> wrote:
> 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 resour
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
> 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 found" error.
>
> Symlinking parrot's blib
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 f
At 8:46 PM +0100 4/12/04, Jonathan Worthington wrote:
I've attached the patches, and (fingers crossed) this will get Parrot going
on Win32 again.
Applied, thanks.
--
Dan
--"it's like this"---
Dan Sugalski
OK, make clean != make realclean :-)
Passed that problem.
Thanks
Alberto
Dan Sugalski wrote:
At 5:21 PM +0100 4/12/04, Alberto Manuel Brandao Simoes wrote:
ICU_DATA=../data/out/build
LD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../layoutex:../extra/ustdio:../tools/ctestfw:../data
At 5:21 PM +0100 4/12/04, Alberto Manuel Brandao Simoes wrote:
ICU_DATA=../data/out/build
LD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../stubdata/:$LD_LIBRARY_PATH
../tools/genrb/genrb -k -q -p icudt26l -s ../data/
ICU_DATA=../data/out/build
LD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../stubdata/:$LD_LIBRARY_PATH
../tools/genrb/genrb -k -q -p icudt26l -s ../data/locales -d
../data/out/build it_IT_PREEURO.txt
ICU_DATA=../da
At 5:14 PM +0100 4/12/04, Alberto Manuel Brandao Simoes wrote:
Dan,
as soon as you put the patch in, say so I can update cvs and re-test.
It's in. :)
Dan Sugalski wrote:
According to the IBM website, ICU triggers a GCC bug in the gcc 3.x
series--you can't compile with the -O2 optimization settin
Dan,
as soon as you put the patch in, say so I can update cvs and re-test.
Thanks
Alberto
Dan Sugalski wrote:
According to the IBM website, ICU triggers a GCC bug in the gcc 3.x
series--you can't compile with the -O2 optimization setting. -O3 works.
I'll put a patch in.
On Monday 12 April 2004 17:46, Dan Sugalski wrote:
> I see you've a selection of machines there. Any reason to not just
> drop them into the current tinderbox system?
Most of the machines don't run 24/7 and I didn't really understand the
existing system, so I did it my way(TM). I didn't really li
At 5:23 PM +0200 4/12/04, Marcus Thiesen wrote:
On Monday 12 April 2004 17:01, Dan Sugalski wrote:
I just checked in a patch for the problems building the data files.
If the folks having problems could try it out that'd be great. (Works
for me locally, but...)
Seems to work, I get now an all tes
On Monday 12 April 2004 17:01, Dan Sugalski wrote:
> I just checked in a patch for the problems building the data files.
> If the folks having problems could try it out that'd be great. (Works
> for me locally, but...)
Seems to work, I get now an all test successfull on Linux, for details see
www.
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 9, 2004, at 7:19 AM, Leopold Toetsch wrote:
>> - What happenend to external constant strings?
> They should still work (or could). But the only cases in which we can
> optimize, and actually use "in-place" a buffer handed to string_make,
> is for a
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,
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
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
1 - 100 of 152 matches
Mail list logo
