On Sep 28, 2004, at 12:28 PM, Chip Salzenberg wrote:
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):
{
variables => { Foo => },
na
I don't see my followup that I sent from a different account earlier today.
Try this again - you'll need a re-configure as there's a change to the root Makefile
that tcl now requires.
Thanks for checking into this.
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
oolong:~/research/pa
Just a casual question here--how does the concept of shared namespaces
relate to getting and using a bless()ed object in perl from a different
language? Is this something that is dealt with at the Parrot level, or
it it merely an attribute associated with a scalar that some PMC takes
care of?
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
> unnatural interfaces is, well, fo
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.
I think an (until now) seldom-mentioned aesthetic of Parrot is that
all languages get to work in their own way, and don't have to present
unnatur
> 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
> > not more than one)
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 not more than one).
That looks good in static
Chip said:
> ...the "appearance" of a unified namespace *is*
> a unified namespace.
Yup.
> A Perl runtime won't have the necessary information
> to present one.
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 not more than one
According to TOGoS:
> > Ruby apparently has a unified namespace. Perl doesn't have one of
> > those. Pretending it does is just closing your eyes and humming.
>
> Many other languages won't be able to access perl's various
> differently-typed variables, anyway.
Sure they will, with appropriate
--- Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> According to TOGoS:
> > Each namespace should have a
> lowest-common-denominator set of values
> > in it. These are not specified to be functions,
> namespaces, or
> > whatever. They're just pointers to values.
>
> What you write here makes as muc
According to TOGoS:
> Each namespace should have a lowest-common-denominator set of values
> in it. These are not specified to be functions, namespaces, or
> whatever. They're just pointers to values.
What you write here makes as much sense as requesting support for:
"Call some method on this obje
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #31752]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31752 >
Hi,
this patch adds two tests of the opcode 'dlvar' to t/pmc/nci.t.
When a n
> And unfortunately dies a horrible death for
languages
> that don't categorize the same way as perl. :( As
> well as being really inconvenient for those
variables
> that can express multiple classes of behaviours
> simultaneously.
>
> This one, alas, I'm going to shoot down.
> - Dan
OK, I'm going
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):
> >>>{
> >>> variables => { Foo => },
> >>> namespaces => { Foo => }
> >>>}
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):
{
variables => { Foo => },
namespaces => { Foo => }
}
I think I get it. You're replacing sigil characters a
On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables => { Foo => },
namespaces => { Foo => }
}
I think I get it. You're replacing sigil characters and associated
name mangling, turning it into e
On Fri, Sep 24, 2004 at 09:30:22AM -0700, Steve Fink wrote:
> But I agree that it is doing a name lookup in the string eval case.
> Although if you try it, you get puzzling results:
>
> perl -le 'sub x {my $foo = 1; return sub { eval q($foo++) } };$x=x();print
> $x->(), $x->(), $x->()'
>
> print
>
> Yeah, this'll happen, and it's an unintended side-effect of the
> changes in Parrot -- the User stack is essentially sub-local. That's
> good for a lot of things, but really, really messes up stack
> languages like Forth.
>
>
> The only real option here is to maintain your own stack and le
According to Jeff Clites:
> top-level namespace (say this is namespace #1):
> {
> variables => { Foo => },
> namespaces => { Foo => }
> }
I think I get it. You're replacing sigil characters and associated
name mangling, turning it into explicit named categories, thus
avoiding lots o
On Tue, Sep 28, 2004 at 08:58:05AM -0700, Jeff Clites wrote:
: You'd still say a given namespace has different
: "sections" to accommodate different categories of entities.
So what you're basically saying is that symbols should be stored in
some kind of extensible URL-ish space. Something to be
On Tue, 2004-09-28 at 12:05, Jeff Clites wrote:
> On Sep 28, 2004, at 7:02 AM, Aaron Sherman wrote:
>
> > why not have each language do it the way
> > that language is comfortable (e.g. place it in the regular namespace as
> > a "variable" like Python or place it in the regular namespace, but
> >
On Sep 28, 2004, at 9:54 AM, Chip Salzenberg wrote:
According to Jeff Clites:
Let's say that all you have around are $Foo and $Foo::Bar::baz ...
top-level namespace (say this is namespace #1):
{
variables => { Foo => },
namespaces => { Foo => }
}
I'm a bit confused by this example
According to Jeff Clites:
> Let's say that all you have around are $Foo and $Foo::Bar::baz ...
>
> top-level namespace (say this is namespace #1):
> {
> variables => { Foo => },
> namespaces => { Foo => }
> }
I'm a bit confused by this example. Don't you mean:
variables =>
On Sep 28, 2004, at 8:58 AM, Jeff Clites wrote:
And just to close the loop, you'd still express your $Foo::Bar::baz
lookup like:
lookupVariableInNamespace P1, ["Foo"; "Bar"], "baz" # the things in
the [...] are always namespace names
Here are more examples, just to be clear:
(and the actual op n
On Tue, 28 Sep 2004, Leopold Toetsch wrote:
> * document updates, bug fixes, cleanup patches are very welcome
> * patches to PLATFORMS reflecting the current build/test state wanted too
> * especially WRT the state of building with our or system ICU
Here's another small update to README. This go
On Sep 28, 2004, at 7:02 AM, Aaron Sherman wrote:
Rather than trying to shuffle through the keyboard and find that
special
character that can be used, why not have each language do it the way
that language is comfortable (e.g. place it in the regular namespace as
a "variable" like Python or place
On Sep 27, 2004, at 8:55 AM, Dan Sugalski wrote:
Okay, I've come to realize that it really helps if I'm clear about
what I want, which kinda requires being clear about what I want.
There are two things in the namespaces I'm concerned about.
First are the actual objects one grabs out. Variables, s
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-09-28 at 03:53, Leopold Toetsch wrote:
>> We already have the Random PMC with vtables to create random numbers.
>> There's really no need to have opcodes too. If there aren't serious
>> arguments for keeping these opcodes, they'll be removed f
4,7 @@
openbsd YY/5 Y Y - Y Y
openbsd_beta_3.5-vaxY*4 Y/26
os2
-solaris8-sparc-cc B-Y/84 - - - Y Y
+solaris8-sparc-cc B-Y/37 - - - Y Y 20040928
tru64-alpha-
Will Coleda <[EMAIL PROTECTED]> wrote:
> oolong:~/research/parrot coke$ ./parrot languages/tcl/tcl.pbc
[EMAIL PROTECTED]:~/src/parrot-leo/languages/tcl]
$ make
make: *** No rule to make target `lib/commands/unset.imc', \
needed by `lib/tcllib.pbc'. Stop.
leo
On Mon, 2004-09-27 at 13:04, Chip Salzenberg wrote:
> For Perl, I get that. But for Python, AFAICT, namespaces are
> *supposed* to be in the same, er, namespace, as variables. No?
Yes, and what's more the suggestion of using "::" in Parrot won't work
perfectly either (I'm pretty sure that there
On Tue, 28 Sep 2004, Leopold Toetsch wrote:
> So, here's the plan:
> * namespace and calling convention changes are postponed after 0.1.1
> * other major changes to the core ditto
> * document updates, bug fixes, cleanup patches are very welcome
Along those lines, I think it's probably appropriat
On Tue, 2004-09-28 at 03:53, Leopold Toetsch wrote:
> We already have the Random PMC with vtables to create random numbers.
> There's really no need to have opcodes too. If there aren't serious
> arguments for keeping these opcodes, they'll be removed for the release.
Didn't you and I specifical
> # New Ticket Created by Jens Rieks
> # Please include the string: [perl #31601]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31601 >
I've added t/library/streams.t
Test #13 and #19 are marked as TODO because they ar
> > If the generator was used as the primary way to testing the regex
> > engine, do you really think that any of these limitations would
> > exist?
>
> Sigh. [Because] seems to have flown right by you.
Ok, I think this thing has pretty much played itself out, but I hate ending
on
On Sat, 25 Sep 2004, Jonadab the Unsightly One wrote:
to @INC, which implies that @INC needs to be able to contain more than
just directories on the system-level filesystem -- it needs to be able
to contain tied "directories" that are simulated by modules, or
(Unless I've not really understood what
On Thu, 23 Sep 2004, Luke Palmer wrote:
Edward Peschko writes:
I'd say that that's a caveat of implementation, sort of a side effect
of handling an error condition. By your criteria there are very few
inverses - you could say that multiplication isn't an inverse of
division because of zero, for exa
* if there is a snprintf() PARROT_HAS_SNPRINTF gets defined [1]
* if it's C99 compliant, PARROT_HAS_C99_SNPRINTF is defined too
* if it returns -1, PARROT_HAS_OLD_SNPRINTF is defined
* src/spf_render.c did check for HAS_SNPRINTF which is neither tested
nor defined
* I don't know, if we have platfo
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #31744]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31744 >
It would be really nice if we had "make install" in 0.1.1. There is no
need to ha
We already have the Random PMC with vtables to create random numbers.
There's really no need to have opcodes too. If there aren't serious
arguments for keeping these opcodes, they'll be removed for the release.
leo
Jerome Quelin <[EMAIL PROTECTED]> wrote:
> Hi there,
> I'd like to initiate a debate here about parrot's version. I really find
> that a project that moves on so quickly such as parrot does should
> change its version number more often.
Yep, you are right.
> I was suggesting on irc to do as Nich
41 matches
Mail list logo
