According to Dan Sugalski:
> At 12:25 PM -0400 9/25/04, Chip Salzenberg wrote:
> > my $i is register;
>
> Except that makes things significantly sub-optimal in the face of
> continuations, since registers aren't preserved...
Well, I know I'd be willing to put in a f
xample. Don't you mean:
variables => { '$Foo' => },
i.e. with the '$' in the key?
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I don't really think it is a question of bright people and dumb
people, but rather people who can see the game they're playing and
those who can't." -- Joe Cosby
d categories, thus
avoiding lots of anticipated string tricks.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I don't really think it is a question of bright people and dumb
people, but rather people who can see the game they're playing and
those who can't." -- Joe Cosby
According to Dan Sugalski:
> At 11:58 AM -0700 9/28/04, Jeff Clites wrote:
> >On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
> >
> >>According to Jeff Clites:
> >>>top-level namespace (say this is namespace #1):
> >>>{
> >>
some method on this object. I won't tell you which method to
call. Just pick one. Guess if you have to."
Ruby apparently has a unified namespace. Perl doesn't have one of
those. Pretending it does is just closing your eyes and humming.
--
Chip Salzenberg - a.k.a. -
d the second half of the message you'd know
> that that's what I meant.
I read all of it. I know what you mean. What you are not realizing is
that the "appearance" of a unified namespace *is* a unified namespace.
A Perl runtime won't have the necessary information to
According to TOGoS:
> Chip said:
> > A Perl runtime won't have the necessary information
> > to present [a unified namespace].
>
> I'm not so sure about that. Most of the time, only one variable with
> a name will be defined ($foo, @foo, or &foo, but n
s is somewhat different; it's mapping a C#
language feature (for the CLR wouldn't have had this feature if C#
didn't need it) onto a language that lacks it.
On an even less related note, I'm really quite surprised that J#
doesn't use the bean method names. Or maybe
According to Chip Salzenberg:
> According to TOGoS:
> > Or explicit exports :) that way you only need to define the
> > interface once, and then all unified-namespace languages can use it.
>
> Asking Perl programmers to go out of their way to present foreign and
> unnat
According to Brent 'Dax' Royal-Gordon:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >parrot_alias(a, 'b', # dest: Python is unified, no need for a
> > category here
> > a, 'b', 'scalar') # src
According to Larry Wall:
> If, by the time the entire program is parsed, nobody has said they
> want to extend an interface, then the interface can be considered
> closed.
What with C and its various wrappers, when can the program
be said to be fully parsed? <- anticipating &
in a pond
to me ... but as a means to optimization it's a good idea, AFAICT.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
According to Jonathan Scott Duff:
> Those classes that are "closed" can be opened at run-time and the
> user pays the penalty then when they try to modify the class [...]
The optimization that can be reversed is not the true optimization.
--
Chip Salzenberg
which, out of spite, I will not name,
... and a public relations issue.
Let us not confuse them.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
According to Michael Lazzaro:
> On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
> >... an anecdote ...
> >... and a public relations issue.
> >Let us not confuse them.
>
> I'm not sure I understand which part of that is in conflict.
Speed is
According to Austin Hastings:
> When you consider some of the issues, it's sort of obvious that they're
> trying *real* hard not to say, "Look the Americans solved this problem
> already."
Three words: "Second System Effect".
--
Chip Salzenberg
scratchpad and not have to search outward at
>runtime.
Once you start down that path, forever will it dominate your closure
implementation. I suggest you do lexical scopes right from the start.
Surely they're not that much harder than a trampoline Are they?
PS: I'm back.
t NUM, in NUM) {
+ $1 = 1.0 - cos($2);
goto NEXT();
}
--
Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]>
"It furthers one to have somewhere to go."
While editing *.pmc, I'm inclined to make various style details
consistent. But I don't know whose style rules rule in *.pmc.
If necessary, I'll be glad to create a pmc style guide.
--
Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]>
"It further
. If somebody else wants to take over this
> I'd only be too happy [...]
I'll be glad to. Lots of the PMC subsystems looks Topaz-like to me.
That's almost certainly a case of convergent evolution rather than
derivation, but in any case, the PMCs look really interesti
ting work that I can do over the net in between classes
(hint, hint :-)).
--
Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]>
"It furthers one to have somewhere to go."
uch all of it has been lifted, in one
> form or other, from folks with a lot more experience and talent than
> I have. I just file down the edges and add some putty to make things
> fit together right)
Originality is the art of concealing one's sources.
--
Chip Salzenberg
Is this bug still reproducible this even after removing everything
Parrot-related from /usr/local? (Also /usr/bin and /usr/lib if you
happen to have installed e.g. Debian's parrot packages.)
This ticket now depends on ResizeableBooleanArray rewrite.
Until we know what these I/O ops should do, seg faults aren't
unexpected. Nor are they something we can meaningfully fix.
This ticket now depends on the review of the I/O pdd.
Fixed in svn.
Actual bug was causing malloc(0).
Proximate bug is that, on tru64, malloc(0) fails. :-)
parrot obeys you
when you ask it politely
to halt and catch fire
Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.
first merge done. yeah baby
401 - 429 of 429 matches
Mail list logo