Nikolay Ananiev wrote:
So, is one of parrot's biggest strengths gone? Are we too late?
Why would the developers use Parrot instead of JVM/CLR/Mono?
We're certainly pleased that we kicked off a revolution in virtual
machines, and that others are beginning to catch on to the fact that
On Tuesday 24 April 2007 15:31, Nikolay Ananiev wrote:
Why would the developers use Parrot instead of JVM/CLR/Mono?
Parrot is open source today, not *mumble* down the road like the JVM will be.
Parrot supports more dynamic features than only find method by name at
runtime.
Parrot doesn't
On Apr 24, 2007, at 11:21 PM, chromatic wrote:
On Tuesday 24 April 2007 15:31, Nikolay Ananiev wrote:
Why would the developers use Parrot instead of JVM/CLR/Mono?
Parrot is open source today, not *mumble* down the road like the
JVM will be.
Parrot is also widely portable, much like perl
Perl6::Perldoc v0.0.5 just hit the CPAN.
Apart from several important bug-fixes, notable new features include:
- Enhanced Perl6::Perldoc::Parser::parse() so that it now accepts either
a filename, a filehandle, or a reference to a string containing Pod6,
as alternative data
Yes I know about Parrot's great features, but Parrot is still not
ready for the mainstream and won't be ready in the next two years (maybe?).
That's a lot of time for commercial projects like CLR and JVM and
the competition between MS and Sun is quite serious, so I expect
the dynamic features in
On Tue, Apr 24, 2007 at 11:43:48PM -0700, Joshua Juran wrote:
Parrot is also widely portable, much like perl is. This one's
especially important to me, as I still work with Mac OS 9.
Parrot builds on Mac OS 9? Cool
It's not listed in PLATFORMS, so I wasn't sure.
Nicholas Clark
On Apr 25, 2007, at 2:06 AM, Nicholas Clark wrote:
On Tue, Apr 24, 2007 at 11:43:48PM -0700, Joshua Juran wrote:
Parrot is also widely portable, much like perl is. This one's
especially important to me, as I still work with Mac OS 9.
Parrot builds on Mac OS 9? Cool
It's not listed in
Minor typo?
On Apr 25, 2007, at 1:06 , [EMAIL PROTECTED] wrote:
Run-time mixins are done with Cdoes and Cbut. The Cdoes binary
operator is a mutator that derives a new anonymous class (if
necessary)
and binds the object to it:
$fido does Sentry
-The Cdoes operator is
On Thu, 19 Apr 2007, chromatic via RT wrote:
On Thursday 19 April 2007 11:24, Andy Dougherty wrote:
But if you actually try it with perl-5.6.2, the build proceeds for a
while and then dies with
perl5.6 tools/build/pmc2c.pl --vtable
longmess is not exported by the Carp module
On Wed, Apr 25, 2007 at 11:48:07AM +0300, Nikolay Ananiev wrote:
Maybe we have to search harder for new ways to advertise Parrot to other
communities and get new developers and supporters to the project.
Currently, Parrot looks too Perlish and is mainly supported by the Perl
community.
I
On Tue, 24 Apr 2007, chromatic wrote:
On Tuesday 24 April 2007 13:30, Andy Dougherty wrote:
Andy, could you update to r18323, remove the -G's, and see if it
now runs to completion on your Solaris box?
Thanks for the heads-up. I'm afraid testing will have to wait until
tomorrow.
On 25.4.2007, at 15:06, Nicholas Clark wrote:
So Parrot is the odd one out here, for relying on an external
language for
its extended build process. I'm not sure if this is significant.
Isn't Parrot more comparable to JVM and CLI in this regard, in that
it's a theoretically
Andy Dougherty writes:
SNIP of much useful detail
At this point, I stopped.
Executive summary: There are a lot of little things. Each one is
probably fixable without too much effort, but it's not worth the effort
unless someone else cares enough to routinely test with perl-5.6.
Nicholas Clark wrote:
I guess that the most obvious current thing that ties Parrot to the Perl
community is that Parrot requires a copy of Perl to bootstrap, and all the
build tools are written in Perl 5.
This is slated to change before the 1.0 release.
Allison
Andy Dougherty wrote:
2. Garbage collection really slows the program down (I observed factors of 10
difference in speed with and without -G), and I have a vague unsupported
suspicion that the slowdown grows faster than linearly with the allocated
memory.
I remember tracing through a load
On Wed, Apr 25, 2007 at 03:32:54PM +, Herbert Snorrason wrote:
On 25.4.2007, at 15:06, Nicholas Clark wrote:
So Parrot is the odd one out here, for relying on an external
language for
its extended build process. I'm not sure if this is significant.
Isn't Parrot more comparable to JVM
Nikolay Ananiev wrote:
Yes I know about Parrot's great features, but Parrot is still not
ready for the mainstream and won't be ready in the next two years (maybe?).
That's a lot of time for commercial projects like CLR and JVM and
the competition between MS and Sun is quite serious, so I expect
Allison Randal wrote:
Nicholas Clark wrote:
I guess that the most obvious current thing that ties Parrot to the Perl
community is that Parrot requires a copy of Perl to bootstrap, and
all the
build tools are written in Perl 5.
This is slated to change before the 1.0 release.
I guess that
Jonathan Worthington wrote:
I guess that doing so will involve re-writing a lot of the current
Configure system and build tools into something that compiles down to
PBC (and then just ship something very basic that can run a PBC).
Whoa. I meant, have some kinda miniparrot that can run a PBC but
On Wed, Apr 25, 2007 at 06:24:28PM +0100, Jonathan Worthington wrote:
Jonathan Worthington wrote:
I guess that doing so will involve re-writing a lot of the current
Configure system and build tools into something that compiles down to
PBC (and then just ship something very basic that can run
On Wednesday 25 April 2007 10:00, Jonathan Worthington wrote:
Basically, if you run the program without -G and then break it, it will
usually break inside the GC routine. What I do remember is that it was
looping through some kinda memory pool, or arena, or whatever. However,
the thing it was
On 4/25/07, Jonathan Worthington [EMAIL PROTECTED] wrote:
Andy Dougherty wrote:
2. Garbage collection really slows the program down (I observed factors of
10 difference in speed with and without -G), and I have a vague unsupported
suspicion that the slowdown grows faster than linearly with
On 4/25/07, Nicholas Clark [EMAIL PROTECTED] wrote:
On Wed, Apr 25, 2007 at 06:24:28PM +0100, Jonathan Worthington wrote:
Jonathan Worthington wrote:
I guess that doing so will involve re-writing a lot of the current
Configure system and build tools into something that compiles down to
PBC
Aiming to be as ANSI C compatible as possible will help to make it
build on a PDP-10, although I haven't tried it yet in an emulator. Of
course, some tweaking may be necessary, but that would only increase
portability!
On Apr 25, 2007, at 4:06 AM, Nicholas Clark wrote:
On Tue, Apr 24, 2007
I think that would be more work than truly necessary. We have an
obvious dependency on having a make that can read a generic makefile,
and a c compiler that can compile to the running architecture
successfully(cross compiling would come later). We can limit what goes
into parrot, which
On Wed, Apr 25, 2007 at 02:27:35PM -0500, Joshua Isom wrote:
I think that would be more work than truly necessary. We have an
obvious dependency on having a make that can read a generic makefile,
No.
It is possible to bootstrap without any make-like utility.
The lowest common denominator
On Tuesday 24 April 2007 03:50, [EMAIL PROTECTED] wrote:
Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your
fing ers
./miniparrot.exe config_lib.pasm runtime/parrot/include/config.fpmc
make: *** [runtime/parrot/include/config.fpmc] Error 53
Hm, that's interesting.
On Apr 25, 2007, at 11:46 AM, Joshua Isom wrote:
Aiming to be as ANSI C compatible as possible will help to make it
build on a PDP-10, although I haven't tried it yet in an emulator.
Of course, some tweaking may be necessary, but that would only
increase portability!
Oh, and I forgot to
On 4/24/07 6:31 PM, Nikolay Ananiev wrote:
As we all know, parrot has been in development for 7 years now. That's a lot
of time and many things have changed since then. From my point of view one of
the biggest strengths of Parrot is that it's a target for many (and why not
all?) dynamic
On Wednesday 25 April 2007 16:58, John Siracusa wrote:
Judging by how fast LLVM has progressed since Apple's been backing it
(almost two years now) LLVM/HLVM may be something to watch (or work
with...)
A couple of Parrot committers have a pretty good contact with an LLVM
hacker
-- c
Parrot has @larry?
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
VOICE: (608) 261-5738 FAX 264-5932
So it goes
Kurt Vonnegut, Jr. (November 11, 1922 ? April 11, 2007)
First, the test (rearranged to include only the relevant parts):
+.sub main :main
+.local string ok, not_ok
+ok = ok
+not_ok = not ok
+
+# if 'not ok' is printed, it means that the lexical environment
+# for the first closure in each pair, (where out = ok)
+# was
32 matches
Mail list logo
