Re: Is Parrot 1.0 too late?
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 they'll have to support dynamic languages to compete. But, it would be a little silly to throw in the towel just when others are beginning to follow your lead. (And I do mean beginning. They're making great strides, but I still hear strange comments like We support all features of dynamic languages. Of course some features, like multiple inheritance, may be slow, but we don't encourage the use of those features. from the JVM team.) The plan to run Perl, Python, PHP, Ruby, etc. is not the only innovative feature of Parrot. To list a few: - PGE provides parsing tools that are light years ahead of what's in common use today (what's commonly used today hasn't seen much in the way of technological advances in the past 20 years). - TGE is a powerful tool for manipulating trees of data, like the output of a parse, or an abstract syntax tree (think of it as XSLT on steroids). - Those parsing and transformation tools are valuable both for writing compilers and for data processing tasks (handling database output, screen scraping, combination and modification of Atom streams in an AJAXian way, etc.), giving a big boost in ease of use for both areas. - Parrot is a register-based virtual machine instead of stack-based like .NET, Mono, JVM. Register-based machines require fewer instructions to complete the same operations (no need to push and pop the stack), eliminating some unnecessary overhead. JIT-ed code is also register-based (since the actual machine under the virtual machine is register-based), so the register-based bytecode makes that transformation simpler. - Parrot moves beyond the fragile stack-based control flow common to virtual machines today, to a continuation-based control flow. (I can recommend a few good books and articles if you're curious.) While the other VMs are catching up to supporting the features of dynamic languages from 10-40 years ago, we plan to open the way for a whole new breed of dynamic languages. Will others follow our example? I won't complain if they do. Imitation is the sincerest form of flattery. Allison
Re: Is Parrot 1.0 too late?
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 have (obvious) patent issues. I have commit access. Okay, that last one isn't a serious reason either way, -- c
Re: Is Parrot 1.0 too late?
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 is. This one's especially important to me, as I still work with Mac OS 9. Parrot supports more dynamic features than only find method by name at runtime. Unix user shells have had that for decades. It's called 'execvp()'. :-) Josh
New version of Perl6::Perldoc uploaded
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 sources. - Add embedded-CSS support to to_xhtml() - [BACKWARDS INCOMPATIBLE CHANGE] Refactored 'full_doc' option with 'DTD', 'title', and 'style' suboptions - Added stylesheet to bin/perldoc2xhtml to improve rendering of tables in Firefox, Safari, and Explorer - Added -toc option to bin/perldoc2xhtml to autogenerate a table of contents for the document being converted - Added 'text_to_entities' option to to_xhtml() (see bin/perldoc2xhtml_enhanced for an example) This will be the last update for (at least) a few weeks, as I will be preoccupied with other projects. Thanks again to everyone for the valuable feedback. Please keep it coming. Damian
Re: Is Parrot 1.0 too late?
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 their VMs to progress very fast. I'm also afraid they have the resources to create compiler tools comparable to PGE and TGE (you know that MS can always steal). I think in 2-3 years CLR and JVM will be a serious competition to Parrot and I just hope people won't say uh, another VM for dynamic languages about Parrot 1.0. 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 think that has to change. Allison Randal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 they'll have to support dynamic languages to compete. But, it would be a little silly to throw in the towel just when others are beginning to follow your lead. (And I do mean beginning. They're making great strides, but I still hear strange comments like We support all features of dynamic languages. Of course some features, like multiple inheritance, may be slow, but we don't encourage the use of those features. from the JVM team.) The plan to run Perl, Python, PHP, Ruby, etc. is not the only innovative feature of Parrot. To list a few: - PGE provides parsing tools that are light years ahead of what's in common use today (what's commonly used today hasn't seen much in the way of technological advances in the past 20 years). - TGE is a powerful tool for manipulating trees of data, like the output of a parse, or an abstract syntax tree (think of it as XSLT on steroids). - Those parsing and transformation tools are valuable both for writing compilers and for data processing tasks (handling database output, screen scraping, combination and modification of Atom streams in an AJAXian way, etc.), giving a big boost in ease of use for both areas. - Parrot is a register-based virtual machine instead of stack-based like .NET, Mono, JVM. Register-based machines require fewer instructions to complete the same operations (no need to push and pop the stack), eliminating some unnecessary overhead. JIT-ed code is also register-based (since the actual machine under the virtual machine is register-based), so the register-based bytecode makes that transformation simpler. - Parrot moves beyond the fragile stack-based control flow common to virtual machines today, to a continuation-based control flow. (I can recommend a few good books and articles if you're curious.) While the other VMs are catching up to supporting the features of dynamic languages from 10-40 years ago, we plan to open the way for a whole new breed of dynamic languages. Will others follow our example? I won't complain if they do. Imitation is the sincerest form of flattery. Allison
Re: Is Parrot 1.0 too late?
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
Re: Is Parrot 1.0 too late?
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 PLATFORMS, so I wasn't sure. No -- I haven't even attempted it yet. I'm still developing the Unix emulation layer, Lamp (Lamp Ain't Mac POSIX) on which it will run, including the kernel and prerequisite userland utilities -- one of which is perl. Just this weekend I ported Lamp to 68K, and after a little assembly hacking and refactoring yylex() into small enough chunks, perl made the trip as well. Once I get perl further along (as right now it's only miniperl -- I haven't written dlopen() yet) and add some missing features to the shell, I'll take on building parrot. Chances are, if it works on CygWin, I can make it run in traditional Mac OS -- on both architectures. Josh
Re: [svn:perl6-synopsis] r14382 - doc/trunk/design/syn
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 non-associative, so this is a syntax error: +The Cdoes infix operator is non-associative, so this is a syntax error: $fido does Sentry does Tricks does TailChasing does Scratch; Given the second example, should the first have a trailing semicolon? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH
Re: [perl #42616] Parrot won't build with perl-5.6.
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 at /home/doughera/src/parrot/parrot-andy/tools/build/../../lib/Parrot/Pmc2c/PC CMETHOD.pm line 8 What is the actual intent? Requiring builders to run at least perl-5.8 does not seem unreasonable to me, but neither would requiring developers to stick with perl-5.6 seem unreasonable. Parrot should, however, be consistent. It looks like we could replace that longmess call in the WARN handler with Carp::cluck() instead without changing the intent. I had already tried that and immediately ran into a bunch of other little things. Before diving in (or encouraging others to dive in) I thought it prudent to ask the more general question. But, since you ask, on to details: Fixing lib/Parrot/Pmc2c/PCCMETHOD.pm, the next relevant message I see is (I have folded the long lines) perl5.6 tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stack.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops Bareword found where operator expected at lib/Parrot/Ops2pm/Utils.pm line 536, near $MODULE Data::Dumper (Missing operator before Data::Dumper?) Naturally, the resulting lib/Parrot/OpLib/core.pm file is not correct. A diff between core.pm and and one generated by perl-5.8 runs to over 40,000 lines. Yet, amazingly, the build continued! Somehow the tools/build/ops2pm.pl script still managed to return a successful status. Ignoring that problem for the moment, the next problem shows up with pmc2c.pl: perl5.6 tools/build/pmc2c.pl --vtable Global symbol %decl requires explicit package name at /home/doughera/src/parrot/parrot-perl5.6/tools/build/../../lib/Parrot/Pmc2c/delegate.pm line 99. Compilation failed in require at /home/doughera/src/parrot/parrot-perl5.6/tools/build/../../lib/Parrot/Pmc2c.pm line 1220. Compilation failed in require at /home/doughera/src/parrot/parrot-perl5.6/tools/build/../../lib/Parrot/Pmc2c/Library.pm line 29. BEGIN failed--compilation aborted at /home/doughera/src/parrot/parrot-perl5.6/tools/build/../../lib/Parrot/Pmc2c/Library.pm line 29. Compilation failed in require at /home/doughera/src/parrot/parrot-perl5.6/tools/build/../../lib/Parrot/Pmc2c/Utils.pm line 9. BEGIN failed--compilation aborted at /home/doughera/src/parrot/parrot-perl5.6/tools/build/../../lib/Parrot/Pmc2c/Utils.pm line 9. Compilation failed in require at tools/build/pmc2c.pl line 12. BEGIN failed--compilation aborted at tools/build/pmc2c.pl line 12. pmc2c.pl --dump fails with the same error message. Working around those problems by building those files with perl-5.8, the next problem is with the 3-arg open() in lib/Test/Builder.pm: t/configure/01-options...Unknown open() mode '' at /home/doughera/src/parrot/parrot-perl5.6/t/configure/../../lib/Test/Builder.pm line 1217. Compilation failed in require at /home/doughera/src/parrot/parrot-perl5.6/t/configure/../../lib/Test/More.pm line 6. BEGIN failed--compilation aborted at /home/doughera/src/parrot/parrot-perl5.6/t/configure/../../lib/Test/More.pm line 6. Compilation failed in require at t/configure/01-options.t line 15. BEGIN failed--compilation aborted at t/configure/01-options.t line 15. t/configure/01-options...dubious Test returned status 255 (wstat 65280, 0xff00) 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 README and Configure.pl) should simply be changed to perl-5.8.whatever. I'll be happy to help anyone who wants help getting perl-5.6 installed. -- Andy Dougherty [EMAIL PROTECTED]
Re: Is Parrot 1.0 too late?
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 think that has to change. Do you have any ideas on how to achieve this? 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. I know that Perl 5's build system attempts to get a minimal Perl 5 binary bootstrapped as early as possible, and then does the rest of the build using Perl 5 programs running on it. I've just tried out Ruby, Python and Lua. Akin to Perl, Ruby builds a miniruby, and then uses that to build the extensions. Python doesn't build a minipython, but does use the Python binary as part of the extension build process. Lua is the odd one out - it doesn't ship with a Configure script, just a Makefile, and doesn't appear to build anything outside the main source directory. 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. Nicholas Clark
Re: [perl #42620] PGE 'Out of memory' panics.
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. The rsync server at svn.perl.org is still down, and the snapshot on svn.perl.org hasn't picked up that patch yet. Here's the patch (before I added comments); it should apply cleanly to anything in the past week or two. Thanks. That indeed does help. Without this patch, ./parrot t/compilers/pge/p5regex/p5rx.t would only get to test 185. Today, I made it to test 227. Granted, it took 22 minutes to get there, but it did get there! So, good detective work. I think you've plugged an important leak. Alas, there are still (at least) two problems: 1. It's still leaking memory badly for me. It improved from test 185 to 227, but that's a long way from completing all 960 tests. 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. Still, keep up the good work! -- Andy Dougherty [EMAIL PROTECTED]
Re: Is Parrot 1.0 too late?
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-independent VM, while the examples you mention are very specifically tied to one single language? So it wouldn't be unexpected that it's the odd out? - A nitpicking lurker.
Re: [perl #42616] Parrot won't build with perl-5.6.
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. Otherwise, the requirements (in README and Configure.pl) should simply be changed to perl-5.8.whatever. My take: our long term goal is to eliminate the dependency we have on perl. Let's not spend more time making it work with 5.6, but instead, devote that time to furthering the the long term goal. I vote we just up the (temporary!) requirement. I'll be happy to help anyone who wants help getting perl-5.6 installed. -- Andy Dougherty [EMAIL PROTECTED]
Re: Is Parrot 1.0 too late?
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
Re: [perl #42620] PGE 'Out of memory' panics.
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 of this code for about an hour. I was none the wiser afterwards, but I was trying to work out arenas and allocation stuff and so on. 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 looping through was *huge* (like, from 0 to a six figure number) and I think it maybe was an n^2 algorithm, which amplified the effect further. Recent mentions of a lack of memory pool compaction kinda resonates with what I analyzed; I always meant to return to look a bit more, but never had time to dig deeper. I think re-discovering where it's spending so much time during GC would be a good start, though. And just randomly breaking into the program did it for me, usually first time. Jonathan
Re: Is Parrot 1.0 too late?
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 and CLI in this regard, in that it's a theoretically language-independent VM, while the examples you mention are very specifically tied to one single language? So it wouldn't be unexpected that it's the odd out? Not entirely Perl 5 is really Perl 5/Perl 5, Java is Java/Java, in the sense of C#/.NET The distribution provides both a language and a virtual machine, although that virtual machine is not really accessible apart from via the language of the same name. Java toolchains are written in Java, although I admit that I don't know how early Java is used during the building of a Java VM from source. But I don't see a fundamental reason not to write more of the Parrot build system toolchain in a language that runs atop the Parrot VM, rather than the Perl 5 VM, over the long term. (In the shorter term, the Perl 5 code works, and change for the sake of change itself is make-work, and a distraction from progressing other areas, such as implementing PDDs, and exterminating bugs) Nicholas Clark
Re: Is Parrot 1.0 too late?
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 the dynamic features in their VMs to progress very fast. I'm also afraid they have the resources to create compiler tools comparable to PGE and TGE (you know that MS can always steal). That's a possibility, but what are you afraid of? This is how open source software works. We develop in the open to promote the greater advance of all technology. We don't hoard our advances in the fear that others will use them (that's what proprietary companies do). One of the greatest advantages of the open source model is the fact that Parrot isn't tied to a particular company's profit strategy. This gives us a much greater flexibility to take bold risks on new technology. I expect that this will keep Parrot consistently ahead of the CLR and the JVM. They have more resources to throw at it, but they also have strong motivations not to radically change their architecture. But, there's really no way to be certain how the game will play out until we play the game. If poker players all threw in their cards as soon as they were dealt, it would make for a pretty boring game. Maybe we have to search harder for new ways to advertise Parrot to other communities and get new developers and supporters to the project. On that I completely agree, but as a simple matter of practicality, not some desperate bid for market dominance. If you want to recruit new C developers, you go where C developers hang out. (chromatic and I are speaking at a Linux conference this weekend.) Currently, Parrot looks too Perlish On that I completely disagree. Parrot looks very Perlish because it's highly dynamic and intended to be easy to use (which happen to also be goals of Perl). This is an advantage. and is mainly supported by the Perl community. That's not really an advantage or disadvantage, it's an accident of history. And, probably also a sympathy of vision. Allison
Re: Is Parrot 1.0 too late?
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 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). I don't think PIR is the thing to translate them to though - Configure and the build tools are fairly big things. You don't want to be doing that in an intermediate language. Well, I sure don't anyway, and I'm sure I'm not alone in feeling this way. One option would be a HLL that maps very closely down to the features of Parrot, but really is a high level language. I say maps down closely because then you don't have to worry about matching the semantics of some existing language, making it somewhat simpler to Get Done. Another option is for any of the HLLs in languages/ to get to the stage where we can port Configure to them. OK, well, not BF. ;-) But then you have the advantage of it being a language that some people already know. Of course, we may run into the fun of we should do it in X because it's my favorite language kinda things, if we have multiple Parrot-targeting HLLs in shape by then. Though the simple answer to that is to make a decision and tell people to put up with it. :-) IMHO, etc. Jonathan
Re: Is Parrot 1.0 too late?
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 is pure ANSI C or something. Long day... Jonathan
Re: Is Parrot 1.0 too late?
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 a PBC). Whoa. I meant, have some kinda miniparrot that can run a PBC but is pure ANSI C or something. Long day... I like this approach. It feels viable. Nicholas Clark
Re: [perl #42620] PGE 'Out of memory' panics.
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 looping through was *huge* (like, from 0 to a six figure number) and I think it maybe was an n^2 algorithm, which amplified the effect further. This reminds me of the subtitle of a terrible Star Trek movie: Generations. I wonder if we performing smaller collections and compacting only up to a certain threshold would perform better. -- c
Re: [perl #42620] PGE 'Out of memory' panics.
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 the allocated memory.
I remember tracing through a load of this code for about an hour. I was
none the wiser afterwards, but I was trying to work out arenas and
allocation stuff and so on.
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 looping through was *huge* (like, from 0 to a six
figure number) and I think it maybe was an n^2 algorithm, which
amplified the effect further.
Recent mentions of a lack of memory pool compaction kinda resonates with
what I analyzed; I always meant to return to look a bit more, but never
had time to dig deeper. I think re-discovering where it's spending so
much time during GC would be a good start, though. And just randomly
breaking into the program did it for me, usually first time.
yep, in src/gc/dod.c, i end up inside Parrot_dod_sweep()
cur_arena-used is 137910 at present, which is where i broke in at test 177.
there's a loop that looks like:
for (i = nm = 0; i cur_arena-used; i++) {
if (PObj_on_free_list_TEST(b))
; /* if it's on free list, do nothing */
else if (PObj_live_TEST(b)) {
total_used++;
PObj_live_CLEAR(b);
PObj_get_FLAGS(b) = ~PObj_custom_GC_FLAG;
}
else {
/* it must be dead */
i set a breakpoint at
total_used++;
the first time this line is executed is when i = 134459 -- that's the
first live object. that seems odd. when i get up around 137700, just
about every object is live.
and that is just for one arena. counting through the chain of
cur_arena-prev, it seems there are ten arenas. i'm in over my head
here--but it seems to me that both this chain of arenas and the size
of each is much bigger than i imagine it should be.
~jerry
Re: Is Parrot 1.0 too late?
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 (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 is pure ANSI C or something. Long day... I like this approach. It feels viable. this has been my vision for some time. miniparrot (or parrotlet, whatever it will be called) will be c89 at it's core, with the minimum of platform-specific extensions (only where neccessary.) one thing we must do is get away from using perl 5's configure information. this is something we can do now--we just need somebody with knowledge of perl 5's configure system and somebody with knowledge of parrot's configure system to get together and Just Do It. any volunteers? i'd be happy to be the parrot coder. i know enough about parrot's configure system to be dangerous; i know nothing of perl's configure system, however. ~jerry
Re: Is Parrot 1.0 too late?
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 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
Re: Is Parrot 1.0 too late?
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, etc, and try to get a miniparrot that's works with a fairly default makefile for bootstrapping. Type make, then whatever configure script, then make again to build a full parrot? It would help our external dependancies go down to what's an expected dependency, make, and cc. The main things to consider is how much we'd need inside miniparrot. On Apr 25, 2007, at 12:24 PM, 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 a PBC). Whoa. I meant, have some kinda miniparrot that can run a PBC but is pure ANSI C or something. Long day... Jonathan
Re: Is Parrot 1.0 too late?
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 way of doing it is to take the sources to the ANSI C microparrot, linearise the dependencies on a machine with a running parrot, and write out a C program that uses system() to execute commands in order in the source directory to build that microparrot. A slightly more sophisticated version would check whether the target exists first, and skip until a target does not. However, having a make like utility is easier. Lua seems to go for that approach. Nicholas Clark
Re: [perl #42692] install error with output
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. Do you have gdb installed? Would you mind running through this script and pasting the output? rm runtime/parrot/include/config.fpmc gdb ./miniparrot.exe (within gdb) run config_lib.pasm runtime/parrot/include/config.fpmc (when it crashes) bt It might be interesting to see your config_lib.pasm file too. Thanks, -- c
Re: Is Parrot 1.0 too late?
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 mention: With Parrot, you have the Perl community's legendary sense of humor. Hey, at least Mac OS 9 uses ASCII... *ducks* Josh On Apr 25, 2007, at 4: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 PLATFORMS, so I wasn't sure.
Re: Is Parrot 1.0 too late?
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 languages and as I know there's no other VM like it. Well... since now. Check this article: http://blogs.zdnet.com/microsoft/?p=404 Microsoft announces a dynamic layer for CLR, so they will be able to support dynamic languages on their VM. And JVM 1.6 already has this, plus it's opensource and has support for the mainstream platforms. So, is one of parrot's biggest strengths gone? Are we too late? Why would the developers use Parrot instead of JVM/CLR/Mono? I think the role Parrot aims to fill is remains unfilled, although it is being approached from both sides. Check out this LLVM presentation, for example: http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html Look towards the ends of the slides: http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf An excerpt: Call for help! OSS community needs to unite work on various scripting languages Common module to represent/type infer an arbitrary dynamic language Who will provide this? pypy? parrot? llvm itself someday (hlvm)? HLVM is actually in progress: http://hlvm.org/ 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...) -John
Re: Is Parrot 1.0 too late?
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
Re: Is Parrot 1.0 too late?
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)
[perl #42300] [PATCH] t/pmc/sub.t: test for creation of lex by clone op
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 overwritten by the lexical environment created for the +# second closure (where out = not ok) + +$P10 = makebar_clone(ok) +$P20 = makebar_clone(not_ok) +$P10() +.end + +.sub makebar_clone +.param pmc out +.lex 'out', out +.const .Sub s = 'bar' +$P0 = clone s +.return($P0) +.end + +.sub bar :outer(makebar_clone) +$P0 = find_lex 'out' +say $P0 +.end (This prints not ok. The test in the patch expects ok.) You're arguing that the different copies of bar that are returned from makebar_clone should have different lexical environments. I'm pretty sure that this is not the case. Without using newclosure, there's no closure so the lexical environments are the same. What the :outer does in this case is rearrange the lexical stack so that makebar_clone appears in the lexical stack for bar. So we're using the lexical environment from the last time that makebar_clone was called. It's bizarre that this even works because without the closure, I'd think that the lexical environment would have destroyed. I'm not sure how intentional this is. The PDD isn't clear (to me) about what :outer means in the absence of newclosure. I'd definitely be interested in seeing why this would be a useful feature. More detail in the PDD would be nice. Thanks for the interesting patch. -- Matt Diephouse
