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")
+# wa
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)
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
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 lan
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 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 interestin
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 w
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 pmc's,
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
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
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 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
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 c
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
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 doi
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
t
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
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 o
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 writes:
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.
Otherwise, the requirements (in REA
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 language-indepen
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
> >
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.
>
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
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 PLATFO
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
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 th
27 matches
Mail list logo
