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 skip
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 cou
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 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
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 exa
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
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
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 option
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
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
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'
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
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 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}"
>
>
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 2>&1 | grep meth
Aha, here's an interesting difference. I've been using single quotes
f
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 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
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
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> h
"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
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 2>&1 | grep meth
leo
36 matches
Mail list logo
