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
Austin Hastings writes:
> If you think about it, what we really ought to do is train ourselves
> to "reverse" the numbers row on our keyboards. If we're doing a good
> job about avoiding magic numbers, then " $ % & ( ) are going
> to be much more frequently used than 2 4 5 7 9 0, so why don't we
>
Juerd wrote:
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
We already have two hash dereference syntaxes. That's arguably one too
many as it is. Let's fix the deficiencies in the syntax we have, rather
than adding even more syntax with even more deficienci
> -Original Message-
> From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
>
> On Thu, Apr 15, 2004 at 06:38:34PM -0400, Austin Hastings wrote:
> > The use of % as a modulo operator is purely a legacy from 'C',
> > where it was a failure: in 'C', the only number you care about
> > for
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Austin Hastings writes:
> > > From: Juerd [mailto:[EMAIL PROTECTED]
> > > Austin Hastings skribis 2004-04-15 18:38 (-0400):
> > > > $foo % bar
> > >
> > > " % " is 4 keys: space, shift, 5, space. Too much, IMHO.
> > >
Austin Hastings writes:
> > -Original Message-
> > From: Juerd [mailto:[EMAIL PROTECTED]
> >
> > Austin Hastings skribis 2004-04-15 18:38 (-0400):
> > > $foo % bar
> >
> > " % " is 4 keys: space, shift, 5, space. Too much, IMHO.
> >
> > Typability and readability are both VERY important.
Austin Hastings writes:
>
>
> > -Original Message-
> > From: Abhijit A. Mahabal [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, 15 April, 2004 05:13 PM
> > To: [EMAIL PROTECTED]
> > Subject: Array/Hash Slices, multidimensional
> >
> >
> > As the hash syntax is being worked out, I thought it
> -Original Message-
> From: Juerd [mailto:[EMAIL PROTECTED]
>
> Austin Hastings skribis 2004-04-15 18:38 (-0400):
> > $foo % bar
>
> " % " is 4 keys: space, shift, 5, space. Too much, IMHO.
>
> Typability and readability are both VERY important.
In that case, why not define a Class::H
Ack - well, I was downright antagonistic, so I really earned it.
I can only try to accept criticism as well as the rest of the list has.
Apology accepted of course, and an apology of my own to the list who had to
suffer me and chromatic who didn't take me too seriously ;)
-scott
On 0, chroma
On Thu, Apr 15, 2004 at 06:38:34PM -0400, Austin Hastings wrote:
> The use of % as a modulo operator is purely a legacy from 'C', where it was
> a failure: in 'C', the only number you care about for modulus is some power
> of 2, and you get those using bitwise-and anyway.
I disagree with this comp
Austin Hastings skribis 2004-04-15 18:38 (-0400):
> $foo % bar
" % " is 4 keys: space, shift, 5, space. Too much, IMHO.
Typability and readability are both VERY important.
Juerd
Thomas A. Boyer skribis 2004-04-15 16:22 (-0600):
> But I really hate the idea of removing `...` and leaving qx/.../. That
> would leave qx// in the unenviable position of being the only
> "quote-like operator" that doesn't have a corresponding quote-like
> syntax.
s, rx, tr
> After all, the o
> -Original Message-
> From: Matthijs van Duin [mailto:[EMAIL PROTECTED]
> On Fri, Apr 16, 2004 at 12:14:08AM +0200, Juerd wrote:
> >%foo is a hash. When I see %foo%bar, it feels like that should be a hash
> >too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even mor
On Fri, Apr 16, 2004 at 12:14:08AM +0200, Juerd wrote:
%foo is a hash. When I see %foo%bar, it feels like that should be a hash
too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even more.
Not to mention @[EMAIL PROTECTED] I like ` because it's a small but
recognisable glyph. (
Luke Palmer wrote:
That said, I have mixed feelings about the idea. I am thoroughly
convinced that ` can leave it's current job. Removing qx// would be
going a leap too far.
But I really hate the idea of removing `...` and leaving qx/.../. That
would leave qx// in the unenviable position of
> -Original Message-
> From: Abhijit A. Mahabal [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 15 April, 2004 05:13 PM
> To: [EMAIL PROTECTED]
> Subject: Array/Hash Slices, multidimensional
>
>
> As the hash syntax is being worked out, I thought it'd be a good time to
> ask if the following
Austin Hastings skribis 2004-04-15 18:09 (-0400):
> If we're going to entertain alternatives, why not use % as the hash
> subscriptor?
> To borrow from another thread:
> %foo%monday%food = 10;
> %foo%monday%travel = 100;
> %foo%tuesday%food = 10;
> %foo%tuesday%travel = 150;
There is as fa
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
> -Original Message-
> From: Juerd [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 15 April, 2004 05:09 PM
> To: Dave Mitchell
> Cc: [EMAIL PROTECTED]
> Subject: Re: backticks
>
>
> Dave Mitchell skribis 2004-04-15 21:56 (+0100):
> > If hypothetically we *are* going to have a simplfied consta
On Thu, Apr 15, 2004 at 11:45:27AM +0200, Juerd wrote:
> David Storrs skribis 2004-04-14 22:39 (-0700):
> > Very top row, one space right of the F12 key. Extremely awkward.
> > (This is a US keyboard on a Dell Inspiron 5100 laptop.)
>
> That is inconvenient.
Yup.
> > 1) ` looks like it should b
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 Thu, 2004-04-15 at 13:37, Larry Wall wrote:
> Well, I, for one, think chromatic was right on the money.
No matter how right my thoughts might have been, my tone *was* rude and
that's not right. Apologies to Scott.
-- c
As the hash syntax is being worked out, I thought it'd be a good time to
ask if the following will be supported in some form:
If I have some structure like %foo{"monday"}, %foo{"tuesday"} etc,
I can set their values enmass using:
%foo<> = <>;
What if I had
%foo{"monday"}{"food_ex
Dave Mitchell skribis 2004-04-15 21:56 (+0100):
> If hypothetically we *are* going to have a simplfied constant-index hash
> access syntax, is there any reason why we can't use a single quote (')
> rather than backtick ('), akin to the Perl4-ish package separator,
> ie %foo'bar rather than %foo`bar
I found Luke Palmer's Synopsis 3 on perl.com at
http://www.perl.com/pub/a/2004/03/18/synopsis3.html but didn't see it out at
http://dev.perl.org/perl6/synopsis/.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.
Mark J. Reed skribis 2004-04-15 16:49 (-0400):
> If I might offer a modest counter-proposal - how about a fallback method
> (the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however
> that winds up being spelled in Perl6) that would return the value of the
> key equal to the requested m
On 2004-04-15 at 16:49:28, Mark J. Reed wrote:
> Not sure that JavaScript is relevant here, since the "equivalent"
> syntax there, ".", is the same as the method call syntax. But see my
> proposal below.
Before the nit-pickers jump in, I was oversimplifying above. The
"method call syntax" in Jav
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
On the grounds that personally I hate the backtick
Scott> * %hash`s is an example of a small thing that would be easy to implement
Scott> in core but would be used constantly (if JavaScript is any indication,
Scott> every few lines), giving a lot of bang for the buck
Not sure that JavaScript is relevant here, since the "equivalent"
syntax there
On Thu, Apr 15, 2004 at 01:26:47PM -0700, Scott Walters wrote:
: So, my apologies to who anyone who feels unfairly or excessively criticized,
: except chromatic. There is no forgiveness for someone who seeks out irked people
: with the single goal of further irking them. Since chromatic is so eager
> -Original Message-
> From: Scott Walters [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 15 April, 2004 03:27 PM
> To: [EMAIL PROTECTED] Juerd
> Cc: [EMAIL PROTECTED]
> Subject: Re: backticks
>
>
> Let me summerize my undestanding of this (if my bozo bit isn't already
> irrevocably set):
>
It's you.
* My objection to the Java community process applies in _some_ _small_
part to the Perl community process. I present it as a negative ideal
with the implication that it should be avoided.
* My objection to it being rejected out of hand applies not to the Perl community
process no
On Thu, Apr 15, 2004 at 12:27:12PM -0700, Scott Walters wrote:
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hash<> retains the features of P5 $hash{foo} but does nothing to
counter the damage of removal of barewords
Actually, %hash<> will be like p5
On Thu, 2004-04-15 at 12:27, Scott Walters wrote:
Without commenting on the rest of the proposal, please allow me to clear
up one point:
> * Rather than eliciting public comment on %hash`foo (and indeed %hash<>)
> the proposal is being rejected out of hand
This whole thread *is* public comment.
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hash<> retains the features of P5 $hash{foo} but does nothing to counter the
damage of removal of barewords
* %hash`foo occupies an important nitch, trading features (slice, autovivication)
to optmize for
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
Aaron Sherman skribis 2004-04-15 14:29 (-0400):
> On Wed, 2004-04-14 at 16:56, Juerd wrote:
> > How many of those backticks
> Note, those weren't backticks, those were programs. There were 123
> PROGRAMS that used backticks or equivalent syntax.
I said backticks, and I meant backticks. I'm not sur
On Thu, 2004-04-15 at 13:23, Johan Vromans wrote:
> "Gregor N. Purdy" <[EMAIL PROTECTED]> writes:
>
> > ... that I would be perfectly happy to be required to start all my
> > Perl 6 programs with "#!/usr/bin/perl6" instead of
> > "#!/usr/bin/perl",
>
> Ten years ago I was perfectly happy to start
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
"Gregor N. Purdy" <[EMAIL PROTECTED]> writes:
> ... that I would be perfectly happy to be required to start all my
> Perl 6 programs with "#!/usr/bin/perl6" instead of
> "#!/usr/bin/perl",
Ten years ago I was perfectly happy to start all my perl programs with
/usr/bin/perl5. Today, I would be qui
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
Gregor N. Purdy wrote:
Personally, I view Perl 6 as such a completely new language (although
still Perlish in spirit, it is very different in other respects), that
I would be perfectly happy to be required to start all my Perl 6
programs with "#!/usr/bin/perl6" instead of "#!/usr/bin/perl", just
t
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
On Wed, 2004-04-14 at 21:23, Gregor N. Purdy wrote:
> Lets try that again, since I think you parsed my email in a way I
> didn't intend (and its at least 50% my fault)
Hey! *I* have to step up for 50% of the blame now? Where's my lawyer!
;-)
> In my opinion, starting a script with "#!/usr/bin/per
Aaron Sherman skribis 2004-04-14 16:40 (-0400):
> >From a source tree I work with (which I cannot divulge code from, but I
> think statistics like this are fine):
> $ find . -name \*.pl | wc -l
> 330
> $ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
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.
>
>
>
On Wed, 2004-04-14 at 17:04, Simon Cozens wrote:
> [EMAIL PROTECTED] (Aaron Sherman) writes:
> > `` gets used an awful lot
>
> But that's in Perl 5, which is a glue language.
I'm not sure I fully agree with that. Perl 5 *can* be a glue language,
and so can Perl 6. They are not terribly distinct
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
Luke Palmer <[EMAIL PROTECTED]> writes:
> David Cantrell writes:
>> A few days ago I briefly discussed with Nicholas Clark (current perl 5.8
>> pumpking) about making perl5 code forward-compatible with perl6. A
>> quick look through the mailing list archives didn't turn up anything
>> obvious, an
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
David Storrs skribis 2004-04-14 22:39 (-0700):
> Very top row, one space right of the F12 key. Extremely awkward.
> (This is a US keyboard on a Dell Inspiron 5100 laptop.)
That is inconvenient.
> 1) ` looks like it should be a bracketing operator
I think you means circumfix/balanced operator.
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
Chris skribis 2004-04-14 17:07 (-0700):
> Perhaps this is naive, but couldn't something like this be achieved in a
> manner similar to how I just implemented it in Ruby? Surely Perl will have
> similar capabilities to handle unknown methods.
As explained in <[EMAIL PROTECTED]>, it's not a
questio
"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
78 matches
Mail list logo
