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
Chromatic [EMAIL PROTECTED] wrote:
Method 'layou' not found
in file '(unknown file)' near line -1
Did you turn on debugging? Most of these name mangling and string
constant stuff should be covered, e.g.:
$ parrot -d /tmp/object-meths_15.pasm 21 | grep meth
leo
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 resource in Cocoa
Aaron Sherman [EMAIL PROTECTED] wrote:
So, why is that:
my dog Fiffi:language(blah) eq my dog Fi\x{fb03}:langauge(blah)
and not
use language blah;
my dog Fiffi eq my dog Fi\x{fb03}
What, if this is:
$dog eq my dog Fi\x{fb03}
and C$dog hasn't some language info
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 chdir,
On 14 Apr 2004, at 20:16, 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 that
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
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.
Well,
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
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
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 Thu, 2004-04-15 at 00:58, Leopold Toetsch wrote:
Did you turn on debugging? Most of these name mangling and string
constant stuff should be covered, e.g.:
$ parrot -d /tmp/object-meths_15.pasm 21 | grep meth
Aha, here's an interesting difference. I've been using single quotes
for
On Thu, 2004-04-15 at 05:00, Leopold Toetsch wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
So, why is that:
my dog Fiffi:language(blah) eq my dog Fi\x{fb03}:langauge(blah)
and not
use language blah;
my dog Fiffi eq my dog Fi\x{fb03}
What, if this is:
$dog
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 :)
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
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
chromatic wrote:
emit set P16['height], 100
Ah. Relikt of Jeff's patch. If that constant got reused elsewhere, e.g.
as a method name, it were one too short.
Fixed.
leo
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.
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
On Thu, 2004-04-15 at 09:18, Leopold Toetsch wrote:
Ah. Relikt of Jeff's patch. If that constant got reused elsewhere, e.g.
as a method name, it were one too short.
Confirmed. Thanks, Leo!
Would a test patch such as the following be good to catch regressions,
or should it go elsewhere? If
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
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,
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
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: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
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?
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
Hello Perl6 people,
I couldn't help but notice that you were talking about ICU on this
mailing list. Let me interject with some suggestions.
I should mention that ICU 2.6 can build a static data library. I
recommend that ICU be built without the --with-data-packaging=archive
configure
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
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 or
Chromatic [EMAIL PROTECTED] wrote:
On Thu, 2004-04-15 at 09:18, Leopold Toetsch wrote:
Ah. Relikt of Jeff's patch. If that constant got reused elsewhere, e.g.
as a method name, it were one too short.
Confirmed. Thanks, Leo!
Good.
Would a test patch such as the following be good to catch
Aaron Sherman [EMAIL PROTECTED] wrote:
On Thu, 2004-04-15 at 05:00, Leopold Toetsch wrote:
$dog eq my dog Fi\x{fb03}
and C$dog hasn't some language info attached?
Looks good to me. Great example!
Seriously, why is that a problem?
Dan's problem to come up with better examples--or
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,
At 11:55 PM +0200 4/15/04, Leopold Toetsch wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
On Thu, 2004-04-15 at 05:00, Leopold Toetsch wrote:
$dog eq my dog Fi\x{fb03}
and C$dog hasn't some language info attached?
Looks good to me. Great example!
Seriously, why is that a problem?
Dan's
On Sat, 2004-04-10 at 01:49, Leopold Toetsch wrote:
This initializer is available as first param in the init method.
I'm happy with this.
Good.
What needs to be done before making it the default? I'm anxious to
remove CALL__BUILD=1 from my parrot alias.
We don't have it yet. We could use
On Thu, 2004-04-15 at 23:13, Dan Sugalski wrote:
Nah, that turns out not to be the case. It's my plan, and it's
reasonable to say I'm OK with it. :) While I'd prefer to have
everyone agree, I can live with it if people don't.
Perhaps, as usual, I've been too verbose and everyone just
37 matches
Mail list logo
