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 Nicholas
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
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #31744]
# in the subject line of all future correspondence about this issue.
# URL: 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
* 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
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
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
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 a
# New Ticket Created by Jens Rieks
# Please include the string: [perl #31601]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 specifically
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 appropriate
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
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
@@
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 Y20040928
tru64-alpha-gcc
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 for the
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,
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 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 goes
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 names
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I'm a bit confused
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace
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
append
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
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables = { Foo = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I think I get it. You're replacing sigil characters and associated
name mangling, turning
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 leave its
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-()'
prints 012
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I think I get it. You're replacing
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo =
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 to
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #31752]
# in the subject line of all future correspondence about this issue.
# URL: 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.
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 object.
--- 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 much sense as
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 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). In
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
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
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
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, foreign
delurk
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
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:
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 = PerlScalar PMC
41 matches
Mail list logo
