[ANN] TvmJIT
I am pleased to announce TvmJIT (https://github.com/fperrad/tvmjit), a Virtual Machine derivated from LuaJIT (luajit.org). The only change between LuaJIT and TvmJIT is the frontend language. TvmJIT interprets the TP (Table Processing) language which uses the S-expression syntax. The TP language is a good choice for an intermediate language, it is not an end user language, but it is easy to parse and easy to generate. TvmJIT has all features of LuaJIT like, FFI (Foreign Function Interface), JIT (Just In Time compilation), bytecode generation, Lua 5.1 API/ABI compatible. TvmJIT could use any Lua 5.1 native extension. In order to validate the concept of TvmJIT, I have already written in Lua a small NQP compiler (the AST node are close to the NQP ones), but it is a toy. The next step is to add a TvmJIT backend to https://github.com/perl6/nqp, I need help or/and advice for this. I make some experiment for generate TP from NQP, see https://gist.github.com/fperrad/5946991 Any feedback are welcome. François Perrad Note: At last month, I gave a talk at the French Perl Workshop 2013, the slides are available at https://sites.google.com/site/fperrad/YAP6I.pdf
Re: a more useful srand (was Re: r30369 - docs/Perl6/Spec/S32-setting-library)
2010/4/13 Aaron Sherman : > On Mon, Apr 12, 2010 at 1:55 PM, Larry Wall wrote: > >> On Mon, Apr 12, 2010 at 07:24:37PM +0200, Moritz Lenz wrote: >> : > 1. do all implementations of Perl6 generate the same sequence, given >> the >> : > same initial seed. >> : >> : I don't think they should. If you want that, use confuse a RNG with a >> : sequence generator that it is not. >> >> While I agree that the default should be non-reproducable, the >> approach taken in Perl 5 is nice to the extent that if you *do* >> seed the built-in RNG with a consistent value, you get a reproducable >> result. And reproducable trees of random sequences can be generated >> by controlling the seeds of each node in the tree. >> > > I think that what this conversation is boiling down to is: an RNG is just a > role that wraps an iterator factory and provides some passable defaults, to > be implemented as the default class or classes for Perl's core. That's fine, > but the idea of non-reproducible defaults worries me. If, by this, you mean > that whatever seed is provided to "srand" is to be aggregated with another > source (e.g. XORed with output from the system's entropy source), then I > would love to hear from someone who has experience with the last 10 years of > PRNG work who thinks that's not opening us up to some sort of strange > edge-case risk. > > PRNGs are often misrepresented as frivolous, but as I'm sure you know from > your work at JPL, high quality random sequences are much-prized, and any > language that starts off with some poor assumptions will ultimately pay for > it. > > Some good reading for recent work: > > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/ MT19937 was ported on Parrot/PIR (currently hosted on http://github.com/fperrad/parrot-MT19937). But currently, Parrot lacks an entropy source. François > http://eprint.iacr.org/2006/086 > http://lcamtuf.coredump.cx/oldtcp/tcpseq.html > http://www.avatar.se/python/crng/index.html > > -- > Aaron Sherman > Email or GTalk: a...@ajs.com > http://www.ajs.com/~ajs >
Re: Build Rakudo with Distutils
2010/3/28 Andy Dougherty :
> On Fri, 26 Mar 2010, Fran?ois Perrad wrote:
>
>> Find attached a script 'setup.nqp' for building/testing Rakudo.
>>
>> This library removes the dependences with Makefile & various make
>> utilities, and remove the configure step.
>
> I tried this with today's parrot (r45243) and
> rakudo (8f7d293a6ba3a9ce4efea3278c58a5edf0210edc) on OpenSolaris with
> Sun's compiler. It stopped almost immediately:
>
> perl /export/home/doughera/my/parrot/lib/2.2.0-devel/tools/build/pmc2c.pl --c
> --include /export/home/doughera/my/parrot/src/2.2.0-devel --include
> /export/home/doughera/my/parrot/src/2.2.0-devel/pmc p6lowlevelsig.pmc
> PMC has attributes but no auto_attrs or manual_attrs at
> /export/home/doughera/my/parrot/lib/2.2.0-devel/tools/build/../lib/Parrot/Pmc2c/PMCEmitter.pm
> line 744.
> ccache cc -c -o src/pmc/p6lowlevelsig.o
> -I/export/home/doughera/my/parrot/include/2.2.0-devel
> -I/export/home/doughera/my/parrot/include/2.2.0-devel/pmc
> -I/export/home/doughera/src/parrot/rakudo -DHASATTRIBUTE_CONST
> -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
> -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
> -DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT -I
> /export/home/doughera/my/icu//include -KPIC -DHAVE_COMPUTED_GOTO
> src/pmc/p6lowlevelsig.c
> "./p6lowlevelsig.pmc", line 24: cannot find include file: "../binder/bind.h"
>
> [and then a cascade of C errors based on that one, followed by the
> following odd error message at the end]
>
> current instr.: 'setup' pc 766 (runtime/parrot/library/distutils.pir:337)
> called from Sub 'MAIN' pc 236 (EVAL_1:0)
> called from Sub '_block11' pc 0 (EVAL_1:5)
> called from Sub 'parrot;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1)
> called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1318
> (compilers/pct/src/PCT/HLLCompiler.pir:714)
> called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1504
> (compilers/pct/src/PCT/HLLCompiler.pir:801)
> called from Sub 'parrot;NQP;Compiler;main' pc -1 ((unknown file):-1)
>
> I'm pretty sure this is a recurrence of [perl #66560]. See that ticket
> for the diagnosis and fix currently in use in rakudo.
>
> However, it's not at all obvious to me how someone trying to
> install rakudo could fix it. At least with a Makefile, it's
> often obvious how you can hand-edit the Makefile and try to fix it.
> Here, it's not. Looking at the trace at the end, it refers to a file
> "runtime/parrot/library/distutils.pir" which doesn't exist. (It may have
> existed in the build directory, but that's not around anymore.) There is
> a file distutils.pir in $prefix/lib/2.2.0-dev/library, but editing it
> (assuming you have permission) doesn't appear to change anything. I
> expect that's because the precompiled distutils.pbc file is loaded
> instead.
yes, but you could modify the setup.nqp (line 7)
pir::load_bytecode('distutils.pir');
by this way, you load a distutils.pir file with your alteration.
the attached patch adds the option --no-lines
>
> --
> Andy Dougherty dough...@lafayette.edu
>
>
no-lines.patch
Description: Binary data
Build Rakudo with Distutils
Find attached a script 'setup.nqp' for building/testing Rakudo. The library 'disutils' is shipped with Parrot. See https://trac.parrot.org/parrot/browser/trunk/runtime/parrot/library/distutils.pir This library removes the dependences with Makefile & various make utilities, and remove the configure step. And this library simplifies the job of packager, for example $ parrot-nqp setup.nqp bdist --version 2010.99 produces an Windows installer on Windows and a RPM on Linux. The library 'distutils' is well integrated with Plumage (the Parrot ecosystem). The classic incantations are : $ parrot-nqp setup.nqp update $ parrot-nqp setup.nqp clean $ parrot-nqp setup.nqp build # build is the default target $ parrot-nqp setup.nqp test # or coretest $ parrot-nqp setup.nqp spectest $ parrot-nqp setup.nqp spectest_smolder # or smoke François (Note: I am not a Rakudo committer) setup.nqp Description: Binary data
Another build system for Rakudo
I write another build system for Rakudo (master branch). It is a simple PIR script (setup.pir) which uses a recent library distutils.pbc (installed with Parrot). This library is inspired by the Python Distutils (http://docs.python.org/distutils/). Basically, that removes the Configure step and the generated Makefiles. The standard rules for building/testing/installing/cleaning are coded in the library distutils, and in a simple case the script setup.pir contains only data and a call to the function setup(), in a complex case (like Rakudo) specific rules are added in the script. Others examples of setup.pir are referenced in the head of the source of distutils.pir, see https://trac.parrot.org/parrot/browser/trunk/runtime/parrot/library/distutils.pir Plumage already handles setup.pir Obviously, setup.pir could be rewrite in setup.nqp François. setup.pir Description: Binary data
Re: [perl #60206] [BUG] [MMD] Segfault in Lua exception handler
2009/10/28 Will Coleda via RT : > On Wed Oct 29 10:30:54 2008, alli...@perl.org wrote: >> Original Message >> Subject: Re: Segfault in Lua exception handler >> Date: Sat, 11 Oct 2008 23:49:09 +0200 >> From: François Perrad >> >> 2008/10/8 François Perrad : >> > >> > I try to restore the Lua behavior after ppd27mmd merge. >> > >> > Lua crashes with segmentation fault when the Lua exception handler is >> > called (see subroutine 'docall' in languages/lua/src/lib/luaaux.pir), >> > when function NCI 'traceback' in languages/lua/src/pmc/lua.pmc is called. >> > >> > The following commands reproduce the problem : >> > >> > $ cat add.lua >> > print(true + 42) --> attempt to perform arithmetic on a boolean >> > $ parrot lua.pbc add.lua >> > >> > or >> > $ parrot luap.pir --target=pir add.lua > add.pir >> > $ parrot add.pir >> > >> >> Since hllmagic merge (r31862), the Lua compiler using PCT is broken. >> So, use the old compiler (Perl/yapp based). >> >> $ cat add.lua >> print(true + 42) --> attempt to perform arithmetic on a boolean >> $ perl luac.pl add.lua >> $ parrot add.pir >> >> François. > > François - > > Is this still segfaulting for you? No. See TT #472. François > > -- > Will "Coke" Coleda > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
Re: [perl #58990] [TODO] Design new spec coverage mechanism
2009/9/22 James Keenan via RT : > On Wed Sep 17 16:38:22 2008, jk...@verizon.net wrote: >> We need a way to measure the extent to which Parrot's test suite covers >> the Parrot specification. > > > As with RT #58740, this is a ticket whose functionality is not > absolutely essential to our efforts. No one has spoken up for it in a > year. So, unless there is serious objection, I will close it within 7 days. > FYI, some existing tools (but not Perl) - FIT : http://fit.c2.com/ - FitNesse & Slim : http://fitnesse.org/ But, I don't know Perl equivalent. François > Thank you very much. > kid51 > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > >
Re: Announce: Rakudo Perl 6 development release #21 ("Seattle")
2009/9/19 Moritz Lenz : > Hi, > > François Perrad wrote: >> 2009/9/17 jerry gay : >>> On behalf of the Rakudo development team, I'm pleased to announce >>> the September 2009 development release of Rakudo Perl #21 "Seattle". >>> Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. >>> The tarball for the September 2009 release is available from >>> http://github.com/rakudo/rakudo/downloads . >>> >> >> As usual, binaries for Windows are available on >> http://sourceforge.net/projects/parrotwin32/files/ , >> including the latest Parrot release and many other languages. > > Thanks for the great work! > > Would it be possible to create a permanent link that starts the download > of the latest version? The SourceForge site has a new look since 2 months. AFAIK, I can have only one "Download Now!" button in the summary page http://sourceforge.net/projects/parrotwin32/ If your browser platform is Windows then setup-parrot-xxx.exe otherwise parrot-xxx.chm.zip Currently, I've no idea for Rakudo. François > I'd like to link to such an URL from > <http://rakudo.org/how-to-get-rakudo>, because the current overview > requires you to scroll down all the way to the latest release. > > Cheers, > Moritz > >
Re: Announce: Rakudo Perl 6 development release #21 ("Seattle")
2009/9/17 jerry gay : > On behalf of the Rakudo development team, I'm pleased to announce > the September 2009 development release of Rakudo Perl #21 "Seattle". > Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. > The tarball for the September 2009 release is available from > http://github.com/rakudo/rakudo/downloads . > As usual, binaries for Windows are available on http://sourceforge.net/projects/parrotwin32/files/ , including the latest Parrot release and many other languages. > Due to the continued rapid pace of Rakudo development and the frequent > addition of new Perl 6 features and bugfixes, we recommend building Rakudo > from the latest source, available from the main repository at github. > More details are available at http://rakudo.org/how-to-get-rakudo. > > Rakudo Perl follows a monthly release cycle, with each release code named > after a Perl Mongers group. September 2009 is code named "Seattle" for the > enthusiasm they have shown for Perl 6 during monthly meetings, and the > feedback, encouragement and support given me for the past several years. > > Since the 2009-08 release, Rakudo Perl builds from an "installed > Parrot" instead of using Parrot's build tree. This release of Rakudo > requires Parrot 1.6.0. For the latest information on building and > using Rakudo Perl, see the README file section titled "Building and > invoking Rakudo". (Quick note: the "--gen-parrot" option still > automatically downloads and builds Parrot as before, if you prefer > that approach.) > > Also, unlike previous versions of Rakudo Perl, the "perl6" > (or "perl6.exe") executables only work when invoked from the > Rakudo root directory until a "make install" is performed. > Running "make install" will install Rakudo and its libraries > into the Parrot installation that was used to build it, and then > the executables will work when invoked from any directory. > > Some of the specific major changes and improvements occuring > with this release include: > > * Rakudo is now passing 15,497 spectests, an increase of 3,128 > passing tests since the August 2009 release. With this release > Rakudo is now passing 71.5% of the available spectest suite. > > * Rakudo now supports contextual variables. > > * Rakudo now supports the rational (Rat) data type. > > * Rakudo now supports overloading of many of the builtin operators, > many of which are now defined in the core setting. Many have > also been improved to be more faithful to the specification > with respect to types and coercions. > > * Substantially improved support for trait handling. Most of the > "built-in" traits are now defined in the core setting. > > * The %*ENV variable now works properly for modifying the process environment. > > Since the Perl 6 specification is still in flux, some deprecated features > have been removed from Rakudo. Prominently among those are: > > * '=$handle' is deprecated in favor of '$handle.get' (one line) > and '$handle.lines' (all lines). > > * 'int $obj' is deprecated in favor of '$obj.Int'. > > The development team thanks all of our contributors and sponsors for > making Rakudo Perl possible. If you would like to contribute, > see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org > mailing list, or ask on IRC #perl6 on freenode. > > The next release of Rakudo (#22) is scheduled for October 22, 2009. > A list of the other planned release dates and codenames for 2009 is > available in the "docs/release_guide.pod" file. In general, Rakudo > development releases are scheduled to occur two days after each > Parrot monthly release. Parrot releases the third Tuesday of each month. > > Have fun! > > References: > [1] Parrot, http://parrot.org/ > >
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
2009/9/16 Carl Mäsak : > Tim (>), Raphael (>>): >>> Some XML related stuff: >>> >>> XML parser: >>> http://github.com/fperrad/xml/ No Perl6. Only Parrot & PCT. François Perrad >>> >>> Tree manipulation: >>> http://github.com/wayland/Tree/tree/master >> >> Thanks. Any reason they're not known to proto? > > The latter I wasn't really aware of. It's now added to the list, and > wayland has been given a proto commit bit. > > The former, while apparently a nice effort, doesn't contain any Perl 6 > code as far as I can see. > > // Carl > >
Re: Announce: Rakudo Perl 6 development release #20 ("PDX")
2009/8/20 Kyle Hasselbacher : > On behalf of the Rakudo development team, I'm pleased to announce > the August 2009 development release of Rakudo Perl #20 "PDX". > Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. > The tarball for the August 2009 release is available from > http://github.com/rakudo/rakudo/downloads . > As usual, binaries for Windows are available on http://parrotwin32.sourceforge.net/ , including the latest Parrot release and many other languages. Without the following patch, perl6 dynops cannot link on Windows (with ICU) : --- a/build/Makefile.in +++ b/build/Makefile.in @@ -38,7 +38,7 @@ OPS2C= $(PERL) $(PARROT_TOOLS_DIR)/build/ops2c.pl PMC2C= $(PERL) $(PARROT_TOOLS_DIR)/build/pmc2c.pl PMC2C_INCLUDES = --include src/pmc --include $(PARROT_SRC_DIR) --include $(PARROT_SRC_DIR)/pmc CINCLUDES= -I$(PARROT_INCLUDE_DIR) -I$(PARROT_INCLUDE_DIR)/pmc -LINKARGS = $(LDFLAGS) $(LD_LOAD_FLAGS) $(LIBPARROT) @libs@ +LINKARGS = $(LDFLAGS) $(LD_LOAD_FLAGS) $(LIBPARROT) @libs@ @icu_shared@ # rakudo directories DYNEXT_DIR = dynext > Due to the continued rapid pace of Rakudo development and the > frequent addition of new Perl 6 features and bugfixes, we continue > to recommend that people wanting to use or work with Rakudo obtain > the latest source directly from the main repository at github. > More details are available at http://rakudo.org/how-to-get-rakudo . > > Rakudo Perl follows a monthly release cycle, with each release code named > after a Perl Mongers group. August 2009 is code named "PDX" for the > Portland Perl Mongers. PDX.pm has been home to several Rakudo > contributors (chromatic, Allison Randal, and more) and PDX.pm has > held meetings that have produced feature and bugfix patches for Rakudo. > > Beginning with this release, Rakudo Perl builds from an "installed > Parrot" instead of using Parrot's build tree. This release of Rakudo > requires Parrot 1.5.0. For the latest information on building and > using Rakudo Perl, see the README file section titled "Building and > invoking Rakudo". (Quick note: the "--gen-parrot" option still > automatically downloads and builds Parrot as before, if you prefer > that approach.) > > Also, unlike previous versions of Rakudo Perl, the "perl6" > (or "perl6.exe") executables only work when invoked from the > Rakudo root directory until a "make install" is performed. > Running "make install" will install Rakudo and its libraries > into the Parrot installation that was used to build it, and then > the executables will work when invoked from any directory. > > Some of the specific major changes and improvements occuring > with this release include: > > * Rakudo is now passing 12,369 spectests, an increase of 493 > passing tests since the July 2009 release. With this release > Rakudo is now passing 69.98% of the available spectest suite. > > * We now have a much cleaner traits implementation. Many of the > Perl 6 built-in traits are now implemented in Perl 6, and > user-defined traits can now be defined and applied to classes > and roles. > > * The 'hides' trait on classes can make one class hide another. > > * Many not-yet-implemented operators and features now provide > more helpful error messages instead of simply producing > parse errors. > > * The ROADMAP has been substantially updated and includes some > details regarding the "Rakudo Star" release [2]. > > * Embedded comments now require backticks (Perl 6 specification change). > > Since the Perl 6 specification is still in flux, some deprecated features > will be removed from Rakudo. Prominently among those are: > > * '=$handle' is deprecated in favor of '$handle.get' (one line) > and '$handle.lines' (all lines). > > * 'int $obj' is deprecated in favor of '$obj.Int'. > > The development team thanks all of our contributors and sponsors for > making Rakudo Perl possible. If you would like to contribute, > see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org > mailing list, or ask on IRC #perl6 on freenode. > > The next release of Rakudo (#21) is scheduled for September 17, 2009. > A list of the other planned release dates and codenames for 2009 is > available in the "docs/release_guide.pod" file. In general, Rakudo > development releases are scheduled to occur two days after each > Parrot monthly release. Parrot releases the third Tuesday of each month. > > Have fun! > > References: > [1] Parrot, http://parrot.org/ > [2] Rakudo Star, http://use.perl.org/~pmichaud/journal/39411 > >
Re: xml grammar
2009/8/3 Timothy S. Nelson : > On Fri, 31 Jul 2009, Raphael Descamps wrote: > >> Hi, >> >> I have seen that wayland76 was playing with an XML Grammar on #perl6, so >> I think that it was maybe the time to send what I already have done. > > Raphael: I don't say any of this to discourage you, but to present > alternatives to the list. > > Everyone: Just to note that, while I did essentially the same thing > (starting with moritz's work, and going from there), When Krunen's grammar > was pointed out to me, I used that instead: > > http://github.com/krunen/xml/tree/master > > However, Krunen's grammar has two bugs and no actions. One bug was > an extraneous colon, and the other was something to do with comments, and > was mentioned on #perl6, but I've forgotten it. > > However, my main reason for modifying it was that I needed actions > for what I'm doing. So I'll keep working on that. > > The stuff I've done is here: > > http://github.com/wayland/Tree/tree/master > > :) > Another version is at http://github.com/fperrad/xml/ It's a pure Parrot implementation. The XML grammar (close to W3C REC) is written with PCT, ie. with Perl6 syntax François > > - > | Name: Tim Nelson | Because the Creator is, | > | E-mail: wayl...@wayland.id.au | I am | > - > > BEGIN GEEK CODE BLOCK > Version 3.12 > GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ > R(+) !tv b++ DI D G+ e++> h! y- > -END GEEK CODE BLOCK- > > >
Re: Announce: Rakudo Perl 6 development release #19 ("Chicago")
2009/7/23 Moritz Lenz : > On behalf of the Rakudo development team, I'm pleased to announce > the July 2009 development release of Rakudo Perl #19 "Chicago". > Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. > The tarball for the July 2009 release is available from > http://github.com/rakudo/rakudo/downloads . > As usual, binaries for Windows are available on http://parrotwin32.sourceforge.net/ , including the latest Parrot release and many other languages. > Due to the continued rapid pace of Rakudo development and the > frequent addition of new Perl 6 features and bugfixes, we continue > to recommend that people wanting to use or work with Rakudo obtain > the latest source directly from the main repository at github. > More details are available at http://rakudo.org/how-to-get-rakudo . > > Rakudo Perl follows a monthly release cycle, with each release code named > after a Perl Mongers group. The July 2009 release is named "Chicago", > as chosen by Perl 6 contributor Kyle Hasselbacher. Kyle has been > doing a truly outstanding job of turning open tickets in the RT queues > into tests for the spectest suite. Chicago.pm has been the host for > the 2006 and 2008 YAPC::NA conferences and sponsored Perl 6 hackathons > at each conference. > > In this release of Rakudo Perl, we've focused our efforts on quality > improvements and bootstrapping. We now have operators and additional > builtin functions written in Perl 6. > > Some of the specific major changes and improvements in this release include: > > * Rakudo is now passing 11,876 spectests, an increase of 340 > passing tests since the June 2009 release. With this release > Rakudo is now passing 68% of the available spectest suite. > > * Operators can now be written in Perl 6, and this has been done for the > series operator '...', 'eqv' and the 'leg' operator. > > * The multi dispatcher has been refactored extensively, and now handles many > more edge cases correctly. > > * User defined traits now follow the specification much more closely; some > built-in traits are written in Perl 6. > > * Improved testing: Null PMC Access exceptions are never considered > "successful" by the test suite, even if the test was expecting a > (different) exception to be thrown. > > * Improved introspection: you can now get a list of roles composed into a > class, and a list of attributes. > > Since the Perl 6 specification is still in flux, some deprecated features > will be removed from Rakudo. Prominently among those are: > > * '=$handle' is deprecated in favor of '$handle.get' (one line) > and '$handle.lines' (all lines). > > * 'int $obj' is deprecated in favor of '$obj.Int'. > > The development team thanks all of our contributors and sponsors for > making Rakudo Perl possible. If you would like to contribute, > see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org > mailing list, or ask on IRC #perl6 on freenode. > > The next release of Rakudo (#20) is scheduled for August 20, 2009. > A list of the other planned release dates and codenames for 2009 is > available in the "docs/release_guide.pod" file. In general, Rakudo > development releases are scheduled to occur two days after each > Parrot monthly release. Parrot releases the third Tuesday of each month. > > Have fun! > > References: > [1] Parrot, http://parrot.org/ > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > >
Re: Rakudo Perl 6 development release #18 ("Pittsburgh")
2009/6/19 Patrick R. Michaud : > > On behalf of the Rakudo development team, I'm pleased to announce > the June 2009 development release of Rakudo Perl #18 "Pittsburgh". > Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. > The tarball for the June 2009 release is available from > http://github.com/rakudo/rakudo/downloads . > As usual, binaries for Windows are available on http://parrotwin32.sourceforge.net/ , including the latest Parrot release and many other languages. > Due to the continued rapid pace of Rakudo development and the > frequent addition of new Perl 6 features and bugfixes, we continue > to recommend that people wanting to use or work with Rakudo obtain > the latest source directly from the main repository at github. > More details are available at http://rakudo.org/how-to-get-rakudo . > > Rakudo Perl follows a monthly release cycle, with each release code named > after a Perl Mongers group. This release is named "Pittsburgh", which > is the host for YAPC|10 (YAPC::NA 2009) [2] and the Parrot Virtual Machine > Workshop [3]. Pittsburgh.pm has also sponsored hackathons for Rakudo > Perl as part of the 2008 Pittsburgh Perl Workshop [4]. > > In this release of Rakudo Perl, we've focused our efforts on refactoring > many of Rakudo's internals; these refactors improve performance, > bring us closer to the Perl 6 specification, operate more cleanly > with Parrot, and provide a stronger foundation for features to be > implemented in the near future. Some of the specific major changes > and improvements in this release include: > > * Rakudo is now passing 11,536 spectests, an increase of 194 > passing tests since the May 2009 release. With this release > Rakudo is now passing 68% of the available spectest suite. > > * Method dispatch has been substantially refactored; the new dispatcher > is significantly faster and follows the Perl 6 specification more > closely. > > * Object initialization via the BUILD and CREATE (sub)methods is > substantially improved. > > * All return values are now type checked (previously only explicit > 'return' statements would perform type checking). > > * String handling is significantly improved: fewer Unicode-related > bugs exist, and parsing speed is greatly improved for some programs > containing characters in the Latin-1 set. > > * The IO .lines and .get methods now follow the specification more closely. > > * User-defined operators now also receive some of their associated > meta variants. > > * The 'is export' trait has been improved; more builtin functions > and methods can be written in Perl 6 instead of PIR. > > * Many Parrot changes have improved performance and reduced overall > memory leaks (although there's still much more improvement needed). > > The development team thanks all of our contributors and sponsors for > making Rakudo Perl possible. If you would like to contribute, > see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org > mailing list, or ask on IRC #perl6 on freenode. > > The next release of Rakudo (#19) is scheduled for July 23, 2009. > A list of the other planned release dates and codenames for 2009 is > available in the "docs/release_guide.pod" file. In general, Rakudo > development releases are scheduled to occur two days after each > Parrot monthly release. Parrot releases the third Tuesday of each month. > > Have fun! > > References: > [1] Parrot, http://parrot.org/ > [2] YAPC|10 http://yapc10.org/yn2009/ > [3] Parrot Virtual Machine Workshop, http://yapc10.org/yn2009/talk/2045 > [4] Pittsburgh Perl Workshop, http://pghpw.org/ppw2008/ > >
Re: Rakudo Perl 6 development release #17 ("Stockholm")
2009/5/21 Patrick R. Michaud : > On behalf of the Rakudo development team, I'm pleased to announce > the May 2009 development release of Rakudo Perl #17 "Stockholm". > Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. > The tarball for the May 2009 release is available from > http://github.com/rakudo/rakudo/downloads . > A Windows setup is available at http://parrotwin32.sourceforge.net/ with many others languages. Parrot-1.2.0 : http://sourceforge.net/project/showfiles.php?group_id=211372&package_id=254691&release_id=684051 Parrot-1.2.0-Rakudo-17 (addon) : http://sourceforge.net/project/showfiles.php?group_id=211372&package_id=310553&release_id=684268 The Parrot documentation is also available as a CHM (Compiled HTML Help) http://sourceforge.net/project/showfiles.php?group_id=211372&package_id=312161&release_id=684050 > Due to the continued rapid pace of Rakudo development and the > frequent addition of new Perl 6 features and bugfixes, we continue > to recommend that people wanting to use or work with Rakudo obtain > the latest source directly from the main repository at github. > More details are available at http://rakudo.org/how-to-get-rakudo . > > Rakudo Perl follows a monthly release cycle, with each release code named > after a Perl Mongers group. This release is named "Stockholm"; > Stockholm Perl Mongers will be holding a Perl 6 hackathon on May 29 [3]. > Perl 6 developer Carl Mäsak is a member of Stockholm Perl Mongers and > a main author of November [4], Druid [5], proto [6], and other > Perl 6-based packages. Carl also contributes patches to Rakudo, > and has been stress-testing Rakudo over the past year, submitting > nearly 400 bug reports. > > In this release of Rakudo Perl, we've made the following major changes > and improvements: > > * Rakudo is now passing 11,342 spectests, an increase of 875 > passing tests since the April 2009 release. With this release > Rakudo is now passing 68% of the available spectest suite. > > * We now have an updated docs/ROADMAP . > > * Errors and stack traces now report the file name and line number > in the original source code. > > * Some custom operators can be defined, and it's possible to > refer to operators using &infix: syntax. > > * We can start to load libraries written in other Parrot languages. > > * Regexes now produce a Regex sub. > > * More builtin functions and methods have been rewritten in > Perl 6 and placed as part of the setting. > > * There are many additional improvements and features in this release, > see docs/ChangeLog for a more complete list. > > The development team thanks all of our contributors and sponsors for > making Rakudo Perl possible. If you would like to contribute, > see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org > mailing list, or ask on IRC #perl6 on freenode. > > The next release of Rakudo (#18) is scheduled for June 18, 2009. > A list of the other planned release dates and codenames for 2009 is > available in the "docs/release_guide.pod" file. In general, Rakudo > development releases are scheduled to occur two days after each > Parrot monthly release. Parrot releases the third Tuesday of each month. > > Have fun! > > References: > [1] Parrot, http://parrot.org/ > [2] Stockholm.pm, http://sthlm.pm.org/ > [3] Stockholm Perl 6 hackathon, > http://vic20.blipp.com/pipermail/kameler/2009-May/000318.html > [4] November wiki engine, http://github.com/viklund/november/ > [5] Druid, http://github.com/masak/druid/ > [6] Proto, http://github.com/masak/proto/ > >
Parrot 1.1.0 "Half-moon Conure" Released!
On behalf of the Parrot team, I'm proud to announce Parrot 1.1.0 "Half-moon Conure." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 1.1.0 is available on Parrot's FTP site, or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 1.1.0 News: - Core + Added op: load_language, find_caller_lex + socket IO are back as PMC + refactor some PMC: Hash, ManagedStruct - Compiler + PGE - Allow \x, \c, and \o in enumerated character classes (incl ranges) - Add initial greedy-only version of ** quantifier + PCT - Add HLL source line bytecode annotations - Add another dumper format to assist syntax highlighters - Revise mk_language_shell.pl to updated create_language.pl - Deprecations + Removed ops: gcd, exec, classname, need_finalize, runinterp, substr_r + Removed dynamic op: mul + Removed .HLL_map directive; use interp's .hll_map() instead + Removed PMCs: slice, bound_nci, ref + Removed Configure.pl option: --pmc + Removed PMC union struct - Documentation + Book - Reorganization and many improvements & additions - Tools + Add a parrot-fuzzer - Miscellaneous + Improve Debian/Ubuntu package + various bugfixes, code cleanups, and coding standard fixes Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 19 May 2009. Enjoy!
Re: Rakudo on Vista
2009/4/6 Bruce Gray : > > On Apr 5, 2009, at 6:48 PM, Lyle wrote: >> >> --snip-- >> There is a problem with the Rakudo Makefile? Help would be very much >> appreciated... >> >> http://perl.bristolbath.org/blog/lyle/2009/04/first-perl-6-experiences.html > > Yes, there is a problem. I have duplicated it under MinGW/Win2K, but have > not fully analyzed it yet. > > Workaround: > Line 330 of the Makefile reads something like: >CRITIC_FILES=Configure.pl t\harness build\ tools\ > Change all three of line 330's backslashes to forward-slashes, and then > `mingw32-make` will work. i.e.: >CRITIC_FILES=Configure.pl t/harness build/ tools/ > Makefile is generated, so this modification will be lost. in build/Makefile.in, just insert a empty line between : CRITIC_FILES=Configure.pl t/harness build/ tools/ perlcritic: François. > -- > Hope this helps, > Bruce Gray > (Util on PerlMonks) > > >
Re: [perl #43691] [TODO] lex_source_files() collects lisp files as well but shouldn't
2009/3/22 Will Coleda via RT :
> On Thu Jun 05 12:31:31 2008, coke wrote:
>> On Wed Jun 04 13:17:47 2008, bernhard wrote:
>> > On Mo. 09. Jul. 2007, 06:56:53, pcoch wrote:
>> > > In lib/Parrot/Distribution.pm there is the todo item:
>> > >
>> > > # XXX: lex_source_files() collects lisp files as well... how to
>> > fix ???
>> > >
>> > > We need to work out a nice way to stop the lisp files from being
>> > > collected and considered as lex files.
>> >
>> > The current workaround is to not use 'get_lex_files()'
>> > Instead:
>> >
>> > map( $_->files_of_type('Lex file'),
>> > $self->lex_source_file_directories ),
>> >
>> > is used. For self->lex_source_file_directories() there is a list of
>> > excemption dirs.
>> >
>> > I have no idea whether this workaround is good enough for closing this
>> > ticket.
>>
>> Given that lisp files aren't going to be in the parrot core, I think
>> handling this via exemption directory listings is fine. (we can just
>> exclude all of languages.)
>
> Not only are there no more lisp files, there's no more language directory. We
> should be able
> to remove any workarounds that were introduced for this issue.
>
Done in r37647.
François
> --
> Will "Coke" Coleda
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
Re: [perl #59968] [BUG] Calling Test::More sub after catching a div by zero exception segfaults
2009/3/22 Will Coleda via RT : > On Sat Jan 31 17:51:51 2009, jk...@verizon.net wrote: >> Thanks. Making that correction, I confirm that the OP's seg fault still >> occurs: >> >> $ cat seg.pir >> .sub main :main >> .include 'include/test_more.pir' >> >> new $P0, 'Integer' >> new $P2, 'Integer' >> new $P1, 'Integer' >> >> set $P0, 1 >> set $P2, 0 >> >> ok( 1, 'ready...' ) >> >> push_eh handler >> $P1 = $P0 / $P2 >> ok( 0, "not caught" ) >> end >> pop_eh >> handler: >> ok( 1, 'caught' ) # segfaults >> # say "ok" # no problem with this >> .end >> >> # Local Variables: >> # mode: pir >> # fill-column: 100 >> # End: >> # vim: expandtab shiftwidth=4 ft=pir: >> >> $ ./parrot seg.pir >> ok 1 - ready... >> Segmentation fault > > Still segfaulting in r37615. > > Here's the backtrace. > > #0 0x010925ef in clone_key_arg (interp=0x2300da0, st=0xbfffc618) at > src/call/pcc.c:1191 > #1 0x01092729 in Parrot_convert_arg (interp=0x2300da0, st=0xbfffc618) at > src/call/pcc.c:1817 > #2 0x01093792 in Parrot_process_args (interp=0x2300da0, st=0xbfffc618, > param_or_result=PARROT_PASS_PARAMS) at src/call/pcc.c:1694 > #3 0x01093cc2 in parrot_pass_args (interp=0x2300da0, src_ctx=0x2324a70, > dest_ctx=0x233bce0, src_indexes=0x2327488, dest_indexes=0x3591fc, > param_or_result=PARROT_PASS_PARAMS) at src/call/pcc.c:1884 > #4 0x0100fd10 in Parrot_get_params_pc (cur_opcode=0x3591fc, > interp=0x2300da0) at > src/ops/core.ops:615 > #5 0x010e68f3 in runops_slow_core (interp=0x2300da0, pc=0x3591fc) at > src/runops_cores.c:461 > #6 0x01099bc5 in runops_int (interp=0x2300da0, offset=66) at > src/interpreter.c:980 > #7 0x0109a651 in runops (interp=0x2300da0, offs=66) at src/call/ops.c:107 > #8 0x0109a917 in runops_args (interp=0x2300da0, sub=0x370750, obj=0x28354b0, > meth_unused=0x0, sig=0x12eddc8 "vP", ap=0xbfffc87c "x\0067") at > src/call/ops.c:254 > #9 0x0109b759 in Parrot_runops_fromc_args (interp=0x2300da0, sub=0x370750, > sig=0x12eddc8 "vP") at src/call/ops.c:321 > #10 0x0107b775 in Parrot_ex_throw_from_c (interp=0x2300da0, > exception=0x370678) at > src/exceptions.c:341 > #11 0x0107bd4f in Parrot_ex_throw_from_c_args (interp=0x2300da0, > ret_addr_unused=0x0, exitcode=30, format=0x131cddc "float division by zero") > at > src/exceptions.c:410 > #12 0x011beec5 in Parrot_Integer_multi_divide_DEFAULT_PMC (interp=0x2300da0, > pmc=0x32b8e8, value=0x32b858, dest=0x32b828) at ./src/pmc/integer.pmc:805 > #13 0x010a8bae in pcf_P_JPPP (interp=0x2300da0, self=0x283dc90) at > src/nci.c:609 > #14 0x011b18a9 in Parrot_NCI_invoke (interp=0x2300da0, pmc=0x283dc90, > next=0x0) at > ./src/pmc/nci.pmc:330 > #15 0x0109635f in Parrot_pcc_invoke_from_sig_object (interp=0x2300da0, > sub_obj=0x283dc90, sig_obj=0x370720) at src/call/pcc.c:2980 > #16 0x010a6dfc in Parrot_mmd_multi_dispatch_from_c_args (interp=0x2300da0, > name=0x12ec650 "divide", sig=0x1301048 "PPP->P") at src/multidispatch.c:340 > #17 0x0117d1f4 in Parrot_default_divide (interp=0x2300da0, pmc=0x32b8e8, > value=0x32b858, dest=0x32b828) at ./src/pmc/default.pmc:1473 > #18 0x01023aa0 in Parrot_div_p_p_p (cur_opcode=0x2327444, interp=0x2300da0) at > src/ops/math.ops:402 > #19 0x010e68f3 in runops_slow_core (interp=0x2300da0, pc=0x2327444) at > src/runops_cores.c:461 > #20 0x01099bc5 in runops_int (interp=0x2300da0, offset=0) at > src/interpreter.c:980 > #21 0x0109a651 in runops (interp=0x2300da0, offs=0) at src/call/ops.c:107 > #22 0x0109a917 in runops_args (interp=0x2300da0, sub=0x32ef78, obj=0x28354b0, > meth_unused=0x0, sig=0x12eddc8 "vP", ap=0xbfffed2c "`?2") at > src/call/ops.c:254 > #23 0x0109b759 in Parrot_runops_fromc_args (interp=0x2300da0, sub=0x32ef78, > sig=0x12eddc8 "vP") at src/call/ops.c:321 > #24 0x01077d8e in Parrot_runcode (interp=0x2300da0, argc=1, argv=0xbfffee80) > at > src/embed.c:1011 > #25 0x012d2caf in imcc_run_pbc (interp=0x2300da0, obj_file=0, > output_file=0x0, argc=1, > argv=0xbfffee80) at compilers/imcc/main.c:798 > #26 0x012d3936 in imcc_run (interp=0x2300da0, sourcefile=0xbfffef5f > "foo.pir", argc=1, > argv=0xbfffee80) at compilers/imcc/main.c:1085 > #27 0x29b8 in main (argc=1, argv=0xbfffee80) at src/main.c:61 > The program is running. Exit anyway? (y or n) > > Look like https://trac.parrot.org/parrot/ticket/472 François. > > -- > Will "Coke" Coleda > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > >
Re: [perl #42861] [BUG] config.pir broken in installed parrot
2009/3/22 Will Coleda via RT : > On Wed May 02 12:51:17 2007, yasa...@gmail.com wrote: >> This has a lot to do with tickets #42558 and #34994: >> (there's quite a bit to read in both) >> >> http://rt.perl.org/rt3/Public/Bug/Display.html?id=42558 >> http://rt.perl.org/rt3/Public/Bug/Display.html?id=34994 >> >> To get to config.fpmc (which is in runtime/parrot/include/), config.pir gets >> Parrot's runtime prefix via interpinfo .INTERPINFO_RUNTIME_PREFIX (this is >> part of patch #42558) and then adds "/runtime/parrot/include/config.fpmc" >> onto it. >> >> This works for an uninstalled Parrot, as the runtime prefix returned is the >> Parrot root directory, where runtime/ lives. >> >> On my machine, an installed Parrot returns "/usr/local" for the runtime >> prefix, while the installed config.fpmc lives in >> /usr/local/lib/parrot/include/ . So config.pir tries to look at >> /usr/local/runtime/parrot/include and fails. >> >> >> That was the bug report, my conclusions from here onwards :) >> >> If the "runtime" directory gets installed to "/usr/local/lib", (or whatever) >> then I think that for an installed Parrot that should be the runtime prefix. >> I'm guessing there's some reason that /usr/local is returned here instead. >> >> As far as I can tell, the only place that the runtime prefix is used in the >> Parrot code is Parrot_locate_runtime_file_str (in library.c) where it's used >> to prefix the library paths from parrot_init_library_paths (same file). That >> function returns both options - both runtime/ and lib/, so it works in both >> situations, but it seems to me it would be better to figure it out according >> to the real location of the runtime. >> >> Also, the runtime prefix is stored in the interpreter's IGLOBALS_CONFIG_HASH >> under the key "prefix". I think it would probably be better to rename that >> to "runtime_prefix". > > I'm hoping this issue was fixed before 1.0; Can someone verify? > Fixed by https://trac.parrot.org/parrot/changeset/37091 & https://trac.parrot.org/parrot/changeset/37094 François. > -- > Will "Coke" Coleda > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > >
Re: [perl #60986] Win32 package refuses to install if not run by an administrator
2009/2/1 James Keenan via RT : > My reading of the issues raised in this RT is that it's a > straightforward Win32 installation issue -- nothing specific to Parrot. > > Okay to close the ticket? +1 François > Thank you very much. > kid51 > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > >
Re: [perl #60654] [DEPRECATED] Closure PMC
2009/2/1 James Keenan via RT : > Have we come to any consensus re the issues raised in this RT? in r33344, I merge LuaFunction & LuaClosure PMC. So now, Lua doesn't need Closure PMC. François. > > Thank you very much. > kid51 > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > >
Re: [perl #61286] [PATCH][PROPOSAL] box complements
2008/12/11 Will Coleda via RT <[EMAIL PROTECTED]>: > On Thu Dec 11 01:51:23 2008, fperrad wrote: >> The new opcode 'box' is limited by its 3 signatures that target Float, >> Integer & String. >> I propose the 3 following new opcodes : > >> - true >> - false > > These can be approximated with: > > $P0 = box 1 > $P0 = box 0 No. On Lua, LuaNumber maps Float & Integer, LuaBoolean maps Boolean. So, with the current signature of box : $P0 = box 1 is equivalent to $P0 = new 'LuaNumber' set $P0, 1 but I want a LuaBoolean, because I want respect the precise rules of coercion for arithmetic operations. The expected behavior with a LuaNumber containing 1 and with a LuaBoolean containing 1 is not same. On WMLScript, WmlsInteger maps Integer, WmlsBoolean maps Boolean So, $P0 = box 1 is equivalent to $P0 = new 'WmlsInteger' set $P0, 1 but I want a WmlsBoolean. > > I know you'll end up with an Integer (or, perhaps, a LuaInt) instead of > a Boolean here. That doesn't work? > >> - undef or nil (less Perlish) > > undef and null are two different things in parrot, but we do have an > opcode for one of them, at least: > > $P0 = null > >> After some experiments with bytecode translation, >> in WMLScript (r33655) and in Lua (r33760), >> it seems obvious that we need them. > > Can you explain why? > With the opcode 'box', I could rewrite the generation of : - ConstantInteger - ConstantFloat - ConstantString but not : - ConstantBoolean - ConstantNil That's seems not homogene. >> François. > > > -- > Will "Coke" Coleda > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
Re: Parrot 0.8.1 "Tio Richie" Released!
chromatic a écrit : On behalf of the Parrot team, I'm proud to announce Parrot 0.8.1 "Tio Richie." [1] Parrot is a virtual machine aimed at running all dynamic languages. As usual, the Windows setup is available on http://parrotwin32.sourceforge.net/ François. Rat Creature #1: Comrade! We are about to feast! Quick, get your fat carcass behind this bush and get ready! Rat Creature #1: Hello, small mammal Could you step in here for a moment? I've got something to show you Fone Bone: Can't you show me out here, where I've got runnin' space? Rat Creature #1: No! No! Please! Step in here -- your friend the dragon isn't around, is he? Fone Bone: Hey, Ted! Where you goin'? Ted: You're on yer own, Bone! (exit stage left) Rat Creature #1: Quick, comrade! Start the cooking fire! Rat Creature #2: No. You called me fat. Fone Bone: Ted! Wait for me! Rat Creature #1: (pulls Bone into the bush) Well, well... Look who's joined us for supper... Go start the cooking fire!! Rat Creature #2: No. You called me fat. Rat Creature #1: No?!!! What do you mean, no?!!! Rat Creature #2: And it's not the first time you've done it either Rat Creature #1: Comrade... be reasonable! I wasn't thinking -- I was trying to catch our dinner -- this isn't the time -- I take it back you're not fat. Rat Creature #2: Too late! Rat Creature #1: Please, comrade! I just want to chop him up for the stew! Rat Creature #2: And that's another thing. I'm tired of stew! I want to put him in a crust and bake a light fluffy quiche! Rat Creature #1: Quiche?! What kind of food is that for a monster to eat?! Listen, do you think you could come back in half an hour? We'll have this straightened out by then! Bone: (runs away) Rat Creature #1: (beat) Why didn't you stop me? Rat Creature #2: Why should I? You're so smart! time passes Fone Bone: (hanging from a branch in a waterfall) Those rat creatures would have to be pretty stupid to follow me on to this frail, little branch! Rat Creatures: (follow Bone on to the frail, little branch) Fone Bone: Stupid, stupid rat creatures!! (branch breaks) -- "Bone", by Jeff Smith Parrot 0.8.1 is available via CPAN (soon [2]). You may also see the Parrot download instructions[3]. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion [4] on our source code repository [5] to get the latest and best Parrot code. Please note the updated Parrot Roadmap [6] and our goals leading to the 1.0 release. Parrot 0.8.1 News: - Implementation + added CPAN module Storable 2.12 as a configuration and build dependency + removed the pseudo PIR opcode 'addr' + added the 'box' opcode + fixed 'pop_eh' handling in PIR libraries and examples + removed usage of .return for tailcalls (use .tailcall instead) + removed 'get_hash' and 'get_array' from Capture PMC and Capture_PIR + improved debugger and HLL coordination + allowed MMD primitive autoboxing + fixed all known memory leaks in PIR "Hello, world!" + NCI signatures now JITted on x86-32 platforms (Windows and Linux) + made the .const directive take a quoted type name instead of a constant + made IMCC more re-entrant - Languages + Rakudo - refactored Junctions implementation - added "fire and forget" tool to rebase/rebuild/test Parrot and Rakudo - updated container/reference semantics - added more builtin methods and functions - improved support for multilevel namespaces - added support for .Str, .succ, .pred in user-defined classes - implemented pointy blocks on if/loops - increased STD.pm convergence - added %*VM hash - improved MMD candidate sorting - improved integration of Num and Int - implemented increment on protoobjects - added initial support for MAIN subs - added .PARROT method + Pipp - added some predefined constants. - added implemention of the function basename(). + Cardinal (Ruby) - Added initial support for the classes Proc, Continuation, Queue, Dir, File , and FileStat - fixed various minor bugs - fixed broken Regexes - Compilers + PCT - added '.isa' method to PCT::Node - cleaned up 'immediate block' handling - allowed arguments to immediate blocks in loops/conditionals - metaclass objects can now 'add_method' + PIRC - integrated macro processing in PIRC's lexer - integrated heredoc lexer in PIRC executable - added preprocess and heredoc-preprocess commandline options - integrated the PASM grammar into PIRC - added a register allocator to optimize the built-in vanilla allocator - code cleanups and documentation - added 'make test' target + TGE - updated to work with new namespace/classname s
[perl #60098] [BUG] "load_bytecode" couldn't find file 'P6object.pbc'
In fact, perl6.exe contains some dependencies on build tree. Just after a build, perl6.exe works : D:\parrot-0.8.0-devel>bin\perl6 -v This is Rakudo Perl 6, revision 32151 built on parrot 0.8.0-devel for MSWin32-x86-multi-thread. Copyright 2006-2008, The Perl Foundation. But, after a 'make realclean' in build tree, it fails : D:\parrot-0.8.0-devel>bin\perl6 -v "load_bytecode" couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6;Compiler;main' pc -1 ((unknown file):-1) François.
[perl #58852] [PATCH] enhance tools/install/smoke.pl
I am not really happy with this patch.
Perhaps my initial goal with the script tools/install/smoke.pl wasn't
well-known and/or understood.
Its main use case is :
- a Windows user (without parrot dev tree) downloads and installs the
setup of a monthly release.
- he runs this script in order to check the result of its installation.
- (or I ask him to run it when he tell me that he has a problem).
So this script must be *shipped* and it's the reason why I creat the
directory tools/install and put it in.
The second use case is when I prepare the Windows setup with
http://parrotwin32.wiki.sourceforge.net/LaRecetteDuChef
So, I agree to add some CLI options, but not to add dependence on
specific Parrot-dev Perl modules.
The following patch restores the initial behavior and preserves some CLI
options.
François.
Index: tools/install/smoke.pl
===
--- tools/install/smoke.pl (revision 32008)
+++ tools/install/smoke.pl (working copy)
@@ -5,9 +5,9 @@
use strict;
use warnings;
use 5.008;
+
use Getopt::Long;
-use lib qw( lib );
-use vars qw( %PConfig );
+use File::Spec::Functions;
use Test::More tests => 28;
@@ -17,23 +17,22 @@
=head1 SYNOPSIS
- parrot in bin
+parrot in bin
% cd /usr/local/parrot-$version
-% perl tools/install/smoke.pl -Ilib
+% perl tools/install/smoke.pl
- parrot in .
+parrot in .
% perl tools/install/smoke.pl --bindir=.
- test installation in DESTDIR:
+test installation in DESTDIR:
% cd /usr/src/parrot
% mkdir .inst
% make install DESTDIR=.inst
% perl tools/install/smoke.pl DESTDIR=.inst
-
=head1 DESCRIPTION
Checks that most of things run (or just start) into the install directory,
@@ -43,68 +42,29 @@
=over
-=item -I libdir
-
-Add libdir to the libpath to find Parrot::Config
-
=item --bindir=/usr/bin
-Override Parrot::Config bindir
+Override default value : 'bin'
=item --libdir=/usr/lib
-Override Parrot::Config libdir
+Override default value : 'lib'
-=item --prefix=/usr
-
-Override Parrot::Config prefix and adjust
-libdir and bindir accordingly.
-
-=item DESTDIR=instpath
-
-Use the temp. installation in instpath.
-
=back
=cut
-my (@libdirs, $prefix, $bindir, $libdir, $DESTDIR);
-my $opts = GetOptions( 'I=s' => [EMAIL PROTECTED],
- 'prefix=s' => \$prefix,
- 'bindir=s' => \$bindir,
- 'libdir=s' => \$libdir,
- 'DESTDIR=s' => \$DESTDIR,
- );
-if (@libdirs) {
-push @INC, @libdirs;
-}
-require Parrot::Config;
-Parrot::Config->import;
-require Parrot::Test;
+my ($bindir, $libdir, $DESTDIR);
+my $opts = GetOptions(
+'bindir=s' => \$bindir,
+'libdir=s' => \$libdir,
+'DESTDIR=s' => \$DESTDIR,
+);
-$bindir = $PConfig{bindir} unless $bindir;
-$libdir = $PConfig{libdir} unless $libdir;
-if ($prefix) {
-$bindir = $prefix . "/bin";
-$libdir = $prefix . "/lib";
-}
-# Check for DESTDIR arg and adjust the path
-if (@ARGV and $ARGV[0] =~ /^DESTDIR/) {
-if ($ARGV[0] =~ /^DESTDIR=(\S+)/) {
-$DESTDIR = $1;
-}
-else {
-$DESTDIR = $ARGV[1];
-}
-}
-if ($DESTDIR) {
-my $envsep = $^O eq 'MSWin32' ? ';' : ':';
-$ENV{PATH} = $DESTDIR.$bindir.$envsep.$ENV{PATH};
-$bindir = $DESTDIR . $bindir;
-$libdir = $DESTDIR . $libdir;
-}
+$bindir = 'bin' unless $bindir;
+$libdir = 'lib' unless $libdir;
-use File::Spec::Functions;
+chdir $DESTDIR if ($DESTDIR);
my $filename;
my $exe;
@@ -115,7 +75,6 @@
#
# parrot executable
#
--x $parrot or die "$parrot does not exist\n";
$exe = catfile($bindir, 'pbc_merge');
$out = `$exe`;
Re: Revisiting lexicals, part 1
2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>:
> On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
>> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
>> Lua jargon (the reason for Lua on Parrot is not really Lua).
>> The following Lua code doesn't give the expected result (from
>> languages/lua/t/closure.t) :
>> a = {}
>> local x = 20
>> for i=1,10 do
>> local y = 0
>> a[i] = function () y=y+1; return x+y end
>> end
>>
>> print(a[1]())
>> print(a[1]())
>> print(a[2]())
>>
>> --[[
>> The loop creates ten closures (that is, ten instances of
>> the anonymous function). Each of these closures uses
>> a different y variable, while all of them share the same x.
>> ]]
>>
>>
>> With the current Parrot, I never found a way to do it.
>>
>> So, I'll be happy if this revisiting handles this issue.
>
>
> Here's how I would expect this to look in PIR under the
> new scheme (I'm not familiar with Lua, but I'm assuming 'local'
> in Lua means 'lexical', and that the loop variable is lexical):
>
Details are here http://www.lua.org/manual/5.1/manual.html#2.6
"Visibility Rules",
where comes from the code sample.
> .sub 'main'
>## set outer context of forbody_block
>.const .Sub forbody = 'forbody_block'
>capture_lex forbody
>
>## a = {}
>.local pmc a
>a = new 'ResizablePMCArray'
>store_global 'a', a
>
>## local x = 20
>.local pmc x
>x = new 'Integer'
>x = 20
>.lex 'x', x
>
>## for i = 1,10 do
>.local pmc i
>i = new 'Integer'
>.lex 'i', i
> for_loop:
>if i > 10 goto for_done
>forbody()
>inc i
>goto for_loop
> for_done:
>
>## print(a[1]())
>$P0 = a[1]
>$P1 = $P0()
>say $P1
>
>## ...
> .end
>
>
> .sub 'forbody_block' :outer('main')
>## set outer context of lambda_block
>.const .Sub lambda = 'lambda_block'
>capture_lex lambda
>
>## local y = 0
>.local pmc y
>y = new 'Integer'
>y = 0
>.lex 'y', y
>
>## a[i] = function () y = y+1; return x+y; end
>.local pmc a,i
>a = get_global 'a'
>i = find_lex 'i'
>$P0 = clone lambda ## this creates the closure
>a[i] = $P0
> .end
>
>
> .sub 'lambda_block' :outer('forbody_block')
>## y = y + 1;
>.local pmc y
>y = find_lex 'y'
>n_add $P0, y, 1
>copy y, $P0
>
>## return x+y;
>.local pmc x
>x = find_lex 'x'
>n_add $P1, x,y
>.return ($P1)
> .end
>
Looks fine.
Thanks.
François.
>
>
> Pm
>
>
Re: Revisiting lexicals, part 1
Patrick R. Michaud a écrit :
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far cleaner design than the
current implementation but also handles the vast bulk of
what we need (or can be made to do so easily).
Anyway, comments greatly appreciated.
Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
Lua jargon (the reason for Lua on Parrot is not really Lua).
The following Lua code doesn't give the expected result (from
languages/lua/t/closure.t) :
a = {}
local x = 20
for i=1,10 do
local y = 0
a[i] = function () y=y+1; return x+y end
end
print(a[1]())
print(a[1]())
print(a[2]())
--[[
The loop creates ten closures (that is, ten instances of
the anonymous function). Each of these closures uses
a different y variable, while all of them share the same x.
]]
With the current Parrot, I never found a way to do it.
So, I'll be happy if this revisiting handles this issue.
François.
Pm
[perl #58812] Tcl Segfaults parrot
On Sat Sep 13 06:01:58 2008, coke wrote: > On Fri, Sep 12, 2008 at 10:54 PM, chromatic <[EMAIL PROTECTED]> wrote: > > On Friday 12 September 2008 19:48:30 Will Coleda wrote: > > > > > > Rough guess: you have a HLL type map before you load Tcl's dynpmcs. > If so, > > change the order of operations as a workaround. > > > > I think that might "fix" Lua too. > > > > -- c > > > > I never call .hll_map; all the mappings are done via the dynpmcs > themselves. (I do have liberal uses of .hll spread about, though.) > The problem comes with src/hll.c r30847. See http://rt.perl.org/rt3/Ticket/Display.html?id=58636 François.
[perl #58636] Must Instantiate Class PMCs Before Using Them in HLL Mappings
With this commit r30847, partcl & lua are broken. $ ./parrot languages/lua/lua.pbc Segmentation fault #0 0xb7c93a03 in pmc_new_noinit (interp=0x804f040, base_type=86) at src/pmc.c:300 #1 0xb7c4dd5b in Parrot_register_HLL_type (interp=0x804f040, hll_id=1, core_type=17, hll_type=86) at src/hll.c:362 #2 0xb7dc59ce in Parrot_ParrotInterpreter_thawfinish (interp=0x804f040, pmc=0x8214800, info=0xbfd136b8) at ./src/pmc/parrotinterpreter.pmc:670 #3 0xb7c930bc in visit_loop_todo_list (interp=0x804f040, current=0x8214800, info=0xbfd136b8) at src/pmc_freeze.c:1609 #4 0xb7c93276 in run_thaw (interp=0x804f040, image=0x82218e4, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1700 #5 0xb7c934f0 in Parrot_thaw (interp=0x804f040, image=0x82218e4) at src/pmc_freeze.c:1820 #6 0xb7c8e030 in PackFile_Constant_unpack_pmc (interp=0x804f040, constt=0x822e4e0, self=0x8237c00, cursor=0xb6748fe8) at src/packfile.c:3588 #7 0xb7c8df88 in PackFile_Constant_unpack (interp=0x804f040, constt=0x822e4e0, self=0x8237c00, cursor=0xb6748e78) at src/packfile.c:3542 #8 0xb7c8dc8c in PackFile_ConstTable_unpack (interp=0x804f040, seg=0x822e4e0, cursor=0xb6748e74) at src/packfile.c:3338 #9 0xb7c8b3aa in PackFile_Segment_unpack (interp=0x804f040, self=0x822e4e0, cursor=0xb6748e70) at src/packfile.c:1614 #10 0xb7c8b8ce in directory_unpack (interp=0x804f040, segp=0x822e388, cursor=0xb6748e60) at src/packfile.c:1808 #11 0xb7c8b3aa in PackFile_Segment_unpack (interp=0x804f040, self=0x822e388, cursor=0xb6701040) at src/packfile.c:1614 #12 0xb7c8a303 in PackFile_unpack (interp=0x804f040, self=0x822e388, packed=0xb6701000, packed_size=747344) at src/packfile.c:877 #13 0xb7c3d7d5 in Parrot_readbc (interp=0x804f040, fullname=0xbfd146fb "languages/lua/lua.pbc") at src/embed.c:506 #14 0xb7ea49db in imcc_run (interp=0x804f040, sourcefile=0xbfd146fb "languages/lua/lua.pbc", argc=1, argv=0xbfd13a98) at compilers/imcc/main.c:1039 #15 0x08048998 in main (argc=1, argv=0xbfd13a98) at src/main.c:61 François.
Name spaces of PIR identifiers
It seems that PIR uses only one name space of identifiers.
$ cat const.pir
.const int cst = 42
.sub 'cst'
print cst
.end
$ parrot const.pir
error:imcc:undefined identifier 'cst'
in file 'const.pir' line 5
$ cat label.pir
.const int L1 = 42
.sub 'main'
print L1
goto L1
L1:
.end
$ parrot label.pir
error:imcc:syntax error, unexpected VAR, expecting IDENTIFIER or
PARROT_OP ('L1')
in file 'label.pir' line 5
The expected behavior is not defined in ppd19.
François.
Re: [perl #47503] [RFC] Remove config::init::defaults From configure tests
2008/8/29 James Keenan via RT <[EMAIL PROTECTED]>:
> This dependence has been eliminated from 20 of the 76 current
> configuration step tests. More to come.
>
On MinGW32 (ie gcc on Win32), there are new failure since r30361
D:\fperrad\Parrot\trunk>perl t\steps\auto_msvc-01.t
1..39
ok 1 - use config::auto::msvc;
ok 2 - auto::msvc constructor returned defined value
ok 3 - The object isa auto::msvc
ok 4 - auto::msvc has description
C compiler failed (see test_1508.cco) at
lib/Parrot/Configure/Compiler.pm line 101
Parrot::Configure::Compiler::cc_build('Parrot::Configure=HASH(0x1e18ffc)')
called at config/auto/msvc.pm line 45
auto::msvc::_probe_for_msvc('Parrot::Configure=HASH(0x1e18ffc)')
called at config/auto/msvc.pm line 35
auto::msvc::runstep('auto::msvc=HASH(0x15d629c)',
'Parrot::Configure=HASH(0x1e18ffc)') called at t\steps\auto_msvc-01.t
line 39
# Looks like you planned 39 tests but only ran 4.
# Looks like your test died just after 4.
previously, all was fine :
D:\fperrad\Parrot\trunk>perl t\steps\auto_msvc-01.t
1..44
ok 1 - use config::init::defaults;
ok 2 - use config::auto::msvc;
ok 3 - init::defaults constructor returned defined value
ok 4 - The object isa init::defaults
ok 5 - init::defaults has description
Set up gcc environment - 3.4.5 (mingw special)
ok 6 - init::defaults runstep() returned defined value
ok 7 - auto::msvc constructor returned defined value
ok 8 - The object isa auto::msvc
ok 9 - auto::msvc has description
ok 10 - runstep() returned true value
ok 11 - auto::msvc constructor returned defined value
ok 12 - The object isa auto::msvc
ok 13 - auto::msvc has description
ok 14 - _evaluate_msvc returned true value
ok 15 - Got expected result
ok 16 - Got expected msvc version string
ok 17 - auto::msvc constructor returned defined value
ok 18 - The object isa auto::msvc
ok 19 - auto::msvc has description
ok 20 - _evaluate_msvc returned true value
ok 21 - Got expected result
ok 22 - Got expected msvc version string
ok 23 - ccflags appropriately adjusted given MSVC version
ok 24 - auto::msvc constructor returned defined value
ok 25 - The object isa auto::msvc
ok 26 - auto::msvc has description
ok 27 - sub return value, as expected, not yet set
ok 28 - result, as expected, not yet set
ok 29 - sub return value, as expected, set to true value
ok 30 - Got expected result
ok 31 - msvcversion is undef, as expected
ok 32 - sub return value, as expected, set to true value
ok 33 - Got expected result
ok 34 - msvcversion is undef, as expected
ok 35 - sub return value, as expected, set to true value
ok 36 - Got expected result
ok 37 - msvcversion is undef, as expected
ok 38 - Got expected verbose output
ok 39 - Got expected MSVC version
ok 40 - Got expected result
ok 41 - Got expected MSVC version
ok 42 - Got expected result
ok 43 - Got expected verbose output
ok 44 - Completed all tests in t\steps\auto_msvc-01.t
> kid51
>
>
Re: gsoc_nci merge
Kevin Tew a écrit :
The merge has happened.
The following patch adds NCIGEN in the documentation (HTML generated).
Note : needs a better title than 'Native Call Interface Generator'.
François.
Developers/Users should see no visible changes.
Please build and test, should you have any problems, just yell at me on
#irc or parrot-porters.
Regression test cases will be appreciated. :)
I'll try to be available until 3:00pm MDT and later this evening
9:00pmMDT -> until my eyelids close.
NOTE:
Jitted nci stubs are supported now on i386 linux and win32.
However jitted nci stubs are DISABLED by default.
Once we have this initial merge completed and everyone happy, I will
enable jitted nci stubs as the default, accompanied by another message
to parrot-porters
If you want to test jitted nci stubs uncomment tools/build
cs/nativecall.pl:308, make realclean, rinse, etc
Jitted nci stubs for x86_64 and i386 OSX are in the works but not
present in this current merge.
i386 OSX doesn't work with the current patch because it requires a 16
byte aligned stack.
Don't worry, by default configure disables jit on OSX.
Things that have changed under the covers:
1) a new makefile is being generated
+++ config/gen/makefiles.pm (working copy)
@@ -41,6 +41,8 @@
conditioned_lines => 1,
},
+'compilers/ncigen/Makefile' =>
+{ SOURCE => 'compilers/ncigen/config/makefiles/ncigen.in' },
2) nci c function stub generation has changed slightly
Kevin
Index: lib/Parrot/Docs/Section/Compilers.pm
===
--- lib/Parrot/Docs/Section/Compilers.pm(revision 30562)
+++ lib/Parrot/Docs/Section/Compilers.pm(working copy)
@@ -48,6 +48,7 @@
$self->new_group( 'BCG', 'Byte Code Generation',
'compilers/bcg' ),
$self->new_group( 'JSON', 'JavaScript Object Notation',
'compilers/json' ),
$self->new_group( 'PIRC', 'a PIR Compiler',
'compilers/pirc' ),
+$self->new_group( 'NCIGEN', 'Native Call Interface Generator',
'compilers/ncigen' ),
);
}
Re: Windows visibility (was: Re: Parrot 0.7.0 "Severe Macaw")
2008/8/23 Allison Randal <[EMAIL PROTECTED]>: > Moritz Lenz wrote: >> >> On #perl6 somebody just asked if there were up-to-date windows builds of >> parrot somewhere, he had googled for 'parrot windows'. The parrotwin32 >> project didn't show up in his search (but it's first for 'parrot win32'). >> >> I think we should improve that situation. Suggestions: >> >> 1) A link on http://www.parrotcode.org/source.html > > Sure. Already done since 2-3 months, see http://www.parrotcode.org/source.html#Packages, but with the word Win32, not Windows. François. > >> 2) A page in the parrot wiki > > Even better, on the new site give it a page like > http://www.parrot.org/windows. > >> 3) maybe even a separate site (parrot-on-windows.org perhaps?) > > It already has a separate site on SourceForge. Adding yet another site would > be more confusing than helpful. > > Allison > >
Re: gsoc_nci merge
2008/8/22 Kevin Tew <[EMAIL PROTECTED]>:
> The merge has happened.
>
The target 'hello' seems broken :
src/exec_start.o: In function `set_nci_I':
/home/fperrad/checkout/parrot/src/jit_emit.h:96: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_N':
/home/fperrad/checkout/parrot/src/jit_emit.h:107: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_S':
/home/fperrad/checkout/parrot/src/jit_emit.h:118: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_P':
/home/fperrad/checkout/parrot/src/jit_emit.h:129: undefined reference
to `Parrot_store_arg'
collect2: ld returned 1 exit status
Francois.
> Developers/Users should see no visible changes.
> Please build and test, should you have any problems, just yell at me on #irc
> or parrot-porters.
> Regression test cases will be appreciated. :)
> I'll try to be available until 3:00pm MDT and later this evening 9:00pmMDT
> -> until my eyelids close.
>
> NOTE:
> Jitted nci stubs are supported now on i386 linux and win32.
> However jitted nci stubs are DISABLED by default.
> Once we have this initial merge completed and everyone happy, I will enable
> jitted nci stubs as the default, accompanied by another message to
> parrot-porters
> If you want to test jitted nci stubs uncomment tools/build
> cs/nativecall.pl:308, make realclean, rinse, etc
> Jitted nci stubs for x86_64 and i386 OSX are in the works but not present in
> this current merge.
> i386 OSX doesn't work with the current patch because it requires a 16 byte
> aligned stack.
> Don't worry, by default configure disables jit on OSX.
>
> Things that have changed under the covers:
> 1) a new makefile is being generated
> +++ config/gen/makefiles.pm (working copy)
> @@ -41,6 +41,8 @@
>conditioned_lines => 1,
>},
>
> +'compilers/ncigen/Makefile' =>
> +{ SOURCE => 'compilers/ncigen/config/makefiles/ncigen.in' },
>
> 2) nci c function stub generation has changed slightly
>
>
> Kevin
>
>
[perl #57668] [BUG][PATCH] Iterate through the current namespace causes a segfault
On Wed Aug 06 12:51:02 2008, fperrad wrote: > The patch contains a test case that exhibits the problem. > > François. Applied in r30181, as a TODO test. François.
[perl #57568] [PATCH][Lua] 4 bugfixes for the Lua language and test cases.
On Sun Aug 03 16:11:56 2008, Neopallium wrote: > > I have separated the bugfixes into different patch files and included > one > large patch file (all_changes.patch) that includes all the other > patches. > > fix_assignlist.patch: > In Lua you can swap variables using an assignlist like this: > v1,v2 = v2,v1 > The problem is that both v1 & v2 would equal the value in v2. The > value in v1 > was lost. To fix this I added the use of temp registers to store the > values > before the final assignments. The life.lua script was effected by > this bug. > > test_swap_assignlist.patch: > Adds test case for bug fixed in 'fix_assignlist.patch' > both applied in r29995. > fix_environ_reg_cache.patch: > Accessing a global in Lua after using a logical "and" operation would > cause a > crash if the second operand was a global variable and the first > operand was > false. The POST pass was caching the register name used to access > global > variable to speed up global access. That cached register needs to be > cleared > after method calls and branches. It wasn't being cleared after the > logical "and" operation so the next global access try using a register > that > will not be set if the branch wasn't taken. This bug is why the > life.lua > script was crashing. > > test_global_access.patch: > Adds test case for bug fixed in 'fix_environ_reg_cache.patch' both applied in r29997. > > fix_fornum.patch: > The loop count variable in "for" loops was being passed by reference > instead > of by value as is required for numbers in Lua. To fix this I added a > temp > register for the real loop counter and cloned that value into the > count > variable that is visible to the loop code. This bug effected the > sieve.lua > script making it return only 1 prime. applied in r30005. > > fix_lua_bytecode_loader.patch: > This patch fixes the loading of Lua bytecode files. applied in r29998. > > test_fix_bisect_output.patch: > The expected output for the bisect.lua script seems to be wrong. I > have > tested that script with Lua 5.1.3 on three different computers and the > output > doesn't match the expected output for this test case. Even the "Live > demo" > on lua.org: http://www.lua.org/cgi-bin/demo matches the output from my > three > computers. This patch updates the expected output file so it matches > the > output from the official Lua output. Applied with modification in r30009. The current output reference was created with Lua 5.1.3 on Windows (from LuaBinaries). The code of the Lua interpreter is extremely portable, but not the output. So, now there are 2 reference outputs. Thanks again for these real improvements. François. Note: the ticket #57504 (mktime vs 64bits) was prematurely closed. See http://rt.perl.org/rt3/Ticket/Update.html?id=57504 > > test_from_lua.patch: > Removes TODO on bisect & sieve tests. Changes skip message for life > test > from "crash" to "uses to much memory with default runcore" > > The life.lua script uses too much memory (>1 Gbyte) when using the > slow/fast/computed-goto cores and even when the JIT is turned on. > Using > the "--leak-test" option doesn't show any leaks and the "--gc-debug" > option > doesn't improve memory usage. The CGP & switched cores don't have > this > problem they use less then 60 Mbytes. > > diffstats for all_changes.patch: > src/POSTGrammar.tg | 14 ++ > src/lib/luaaux.pir |2 +- > t/assign.t | 30 +- > t/expr.t | 18 +- > t/test-from-lua.t| 12 +--- > t/test/bisect-output.txt |6 +++--- > 6 files changed, 61 insertions(+), 21 deletions(-) >
Re: Merged pdd25cx branch
2008/8/3 Allison Randal <[EMAIL PROTECTED]> > I just merged in the pdd25cx branch. Resolving all the conflicts took > several hours (124 files, 1 minute or more per file...), but otherwise it > went smoothly. > > The biggest changes you'll notice are the new exception system, a vastly > reduced usage of the remaining stack (though it's not completely removed > yet), and the fact that pushaction subs no longer fire on scope exit > (pushaction will likely be deprecated). > > Keep an eye out for exception-related problems in the next couple of weeks > before the release. > Ok, Lua tests pass, but the behavior has changed. (The tests were written to check the exception message, not the full back trace) The pushaction allowed to retrieve the backtrace where the exception occurred. The backtrace from the exception handler is alway the same (docall -> main), so it has no interest in an user point of view. Previously : $ ./parrot languages/lua/lua.pbc -e "error 'user_exception'" lua.pbc: EVAL_1:34: user_exception stack traceback: languages/lua/src/lib/luaaux.pir:205 in function 'lua_error' languages/lua/src/lib/luabasic.pir:336 in function 'error' EVAL_1:34 in function '&main_10' languages/lua/src/lib/luaaux.pir:916 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' Now: $ ./parrot languages/lua/lua.pbc -e "error 'user_exception'" lua.pbc: _._:0: user_exception stack traceback: languages/lua/src/lib/luaaux.pir:920 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' François. > > Allison > >
Re: [perl #57504] [PATCH][Lua] Fixed 64bit bug in Lua bytecode decoder/translator.
Thanks. Applied in r29937. Francois. 2008/8/1 Robert G. Jakabosky (via RT) <[EMAIL PROTECTED]>: > # New Ticket Created by Robert G. Jakabosky > # Please include the string: [perl #57504] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=57504 > > > > Hello everyone, >This is my first patch to the parrot project. > > This patch fixes 19 failed tests for the Lua language. > > Changes to 'languages/lua/src/build/translator.pl': > When the 32bit Lua instruction codes are being decoded they are stored in a > 64bit signed integer. The top 32bits where not always masked off. This > caused a problem for instructions that had the 31st bit sit, since the top > 32bits would have been sign-extended (filled with 1s). > > Changes to 'languages/lua/t/os.t': > 1 test from 'os.t' fails on 64bit systems because 'os.time()' does not return > a 'nil' for dates with year < 1970. 'os.time()' only returns 'nil' when > mktime returns ((time_t)-1). On 32bit systems mktime uses -1 for dates > outside year range 1970-2038. On 64bit systems mktime returns negative > values for dates before year 1970, so there is only one date that will cause > mktime to return -1 and make 'os.time()' in lua return 'nil'. I have updated > the test to use that one date that returns 'nil' on both 32bit & 64bit > systems. > > > CREDITS |4 > languages/lua/src/build/translator.pl |4 > languages/lua/t/os.t | 16 +--- > 3 files changed, 17 insertions(+), 7 deletions(-) > > -- > Robert G. Jakabosky >
Re: [perl #56800] [META] merge pdd25cx branch back into trunk
2008/8/2 Allison Randal via RT <[EMAIL PROTECTED]> > On Tue Jul 22 06:10:41 2008, fperrad wrote: > > > > In fact 'docall' uses a pushaction. > > I modified 'docall' so it no longer uses pushaction, and all Lua tests > are now passing. > > Ok, tests pass, but the behavior has changed. (The tests were written to check the exception message, not the full back trace) The pushaction allowed to retrieve the backtrace where the exception occurred. The backtrace from the exception handler is alway the same (docall -> main), so it has no interest in an user point of view. Previously : $ ./parrot languages/lua/lua.pbc -e "error 'user_exception'" lua.pbc: EVAL_1:34: user_exception stack traceback: languages/lua/src/lib/luaaux.pir:205 in function 'lua_error' languages/lua/src/lib/luabasic.pir:336 in function 'error' EVAL_1:34 in function '&main_10' languages/lua/src/lib/luaaux.pir:916 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' Now: $ ./parrot languages/lua/lua.pbc -e "error 'user_exception'" lua.pbc: _._:0: user_exception stack traceback: languages/lua/src/lib/luaaux.pir:920 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' François.
OpenGL & Lua
I wrote languages/lua/src/lib/gl.pir & glut.pir over runtime/parrot/library/OpenGL.pir. I obtain some success : $ ./parrot languages/lua/lua.pbc languages/lua/demo/triangles.lua run properly. But the wrapper for Lua is currently incomplete. And I am not happy with this way of doing, too many PIR hand written. So I'll experiment another way in a branch opengl4lua. I want write a part (arguments checking & conversion) of the wrapper in Lua. François.
Re: HLLs needing OpenGL support
Geoffrey Broadwell a écrit : On Tue, 2008-07-22 at 09:03 +0200, François Perrad wrote: Ok, talking about libraries : Lua compiler & Lua Standard Libraries are complete (as far as the current Parrot supports it). So, since April 2008, I wrote some extension libraries for Lua Since mid-June 2008, I tried to write extension libraries for Pipp (PHP supplies more than 2500 functions !!!, huge work) >From a couple comments you make later, it sounds like you're aiming to be perfectly API compatible with the original library implementations for Lua and PHP, so that moving to Parrot is a "drop-in" replacement as far as the user's source code is concerned; am I correct in this assumption? Yes, fully compatible. For me, a Lua-like or PHP-like is just a toy. I believe that PHP could be the killer application for Parrot Why PHP in particular? Is it because of what Parrot can do for PHP (performance, stability (we hope), interop, ...), or because of what PHP can do for Parrot (bring lots of eyeballs to Parrot, as Tim Bunce mentioned for embedding Parrot in Java)? - lua/src/lib/md5.pir & sha1.pir : wrapper over PMC MD5 & SHA1 (I wrote them on the outside of Lua) - lua/src/lib/random.pir : wrapper over library/Math/Random/mt19937ar.pir (I wrote it on the outside of Lua) - lua/src/lib/uuid.pir : wrapper over library/uuid.pir (I wrote it on the outside of Lua) Meaning, you wrote the PMCs / Parrot library PIR before working on Lua, without any Lua dependencies? Yes, they depend only on Parrot. - lua/src/lib/lfs.pir : Lua File System library, over the PMC OS (still incomplete) - pipp/src/common/php_base64.pir : wrapper over library/MIME/Base64.pir (but incomplete because PHP API has more options than MIME/Base64 Perl API) - pipp/src/common/php_pcre.pir : wrapper over library/pcre.pir (incomplete because no PhpArray support, and the NCI PCRE is incomplete and seems very old) Can you please create tickets for the stuff that's missing that you need? Maybe we can get someone to take on improvements of these, so you don't have to As I need to write a NCI wrapper over gmp, I begin my study of NCI by using the OpenGL one (with Lua). Makes sense. If I try to summarize my experiment with libraries : Parrot will supply 3 kinds of common libraries for HLL - written in Perl6, but currently not available (I don't know if NQP is suitable for writing library) In theory perhaps, but NQP has a lot of limitations (intentionally). - written in PIR, but only for bootstrap, because as Bernhard Schmalhofer tell "PIR is not a decent language" + good for libraries not common (in fact equivalent to builtins) - lua/src/lib/bitlib.pir - lua/src/lib/lfs.pir - pipp/src/common/php_ctype.pir - pipp/src/common/php_math.pir - pipp/src/common/php_type.pir + good when no native library available (but a full test suite is needed) - library/Math/Random/mt19937ar.pir (Mersenne Twisted) I'm not sure what you mean by "only for bootstrap" here. Do you mean because of potential performance problems implementing heavy math code in PIR as opposed to C? Currently, the whole parrot/perl6 project is in bootstrap stage, ie. Perl6 is not available. So, the choice is : - waiting for Perl6 or other magic tools - writing PIR today, and doing the job - binding over native (C/C++) shared libraries + with native PMC (C compile/link) - sometime, for security reason, a static linkage is mandatory (libssl is shared lib, but its subset libcrypto is static lib) - other advantage, PMC allows direct OO interface And for security libraries, being able to precisely control buffer copies is important + with NCI : the best way (no C compile/link) - but only procedural interface (no direct OO) How many system libraries provide a true OO interface only, with no procedural or procedural-pretending-to-be-OO interface (like GNOME, for instance)? What functionality do we actually *need* to support those stragglers? 2 designs choices : - For long term maintenance, I write PIR close to original C. For example, I start Lua on Parrot aligned with version 5.0.2 and now it's 5.1.3. And in most of case, the original C is the only valid (updated) user & requirements documentation. Like the old "Perl 5 (the language) *is* what perl5 (the VM) *does*" problem - I try to emit the same (as possible) error or warning messages than the original implementation and to have the same interface. Rule of Least Surprise for the end user. And I could run the test suite against the original implementation. Makes sense. So, in the init function of a library, I wrote (or generate) some boring code like : .const .Sub _mod_funct = 'func
Re: [perl #56800] [META] merge pdd25cx branch back into trunk
François Perrad a écrit :
Bernhard Schmalhofer via RT a écrit :
In r29552 of https://svn.perl.org/parrot/branches/pdd25cx I ran make test
for: pipp, eclectus, hq9plus, lazy-k, m4, unlambda.
All tests were passing.
in branch_pdd25cx, 221/1109 Lua subtests failed.
Mostly for same reason : exception handling.
$ cat nil.lua
print(- nil)
[trunk] $ parrot luc.pbc nil.lua
lua.pbc: EVAL_1:33: attempt to perform arithmetic on a nil value
stack traceback:
EVAL_1:33 in function '&main_10'
languages/lua/src/lib/luaaux.pir:788 in function 'docall'
lua.pir:303 in function 'handle_script'
lua.pir:123 in function 'main'
[branch_pdd25cx] $ parrot lua.pbc nil.lua
lua.pbc: attempt to perform arithmetic on a nil value
in this example, the exception is raised by the following code in
languages/lua/src/pmc/luaany.pmc (line #216)
PMC* neg(PMC *dest) {
PMC *meth = find_meth(INTERP, SELF, "__unm");
if (!meth)
Parrot_ex_throw_from_c_args(INTERP, NULL,
EXCEPTION_ILL_INHERIT,
"attempt to perform arithmetic on a %Ss value",
SELF.name());
...
The global exception handler for Lua is in
languages/lua/src/lib/luaaux.pir (lines 775-823),
with the function 'docall' and the closure 'traceback'.
Missing data are retrieved with the methods 'where' & 'traceback'
implemented in languages/lua/src/pmc/lua.pmc.
In fact 'docall' uses a pushaction.
François.
How rewrites it in branch_pdd25cx ?
François.
Re: HLLs needing OpenGL support
Geoffrey Broadwell a écrit : On Mon, 2008-07-21 at 09:34 +0200, François Perrad wrote: Geoffrey Broadwell a écrit : fperrad: How do these bindings actually work? There'll work with runtime/parrot/library/OpenGL.pir. OK ... so what could be improved about runtime/parrot/library/OpenGL.pir so that you didn't have to write any bindings at all, or so that your bindings could be greatly simplified? So far, I'm seeing the following: Ok, talking about libraries : Lua compiler & Lua Standard Libraries are complete (as far as the current Parrot supports it). So, since April 2008, I wrote some extension libraries for Lua : - lua/src/lib/base64.pir : wrapper over library/MIME/Base64.pir - lua/src/lib/bc.pir : big number library, currently over the PMC BigInt (waiting for BigFloat) - lua/src/lib/bitlib.pir : bitwise operation library, pure PIR - lua/src/lib/lfs.pir : Lua File System library, over the PMC OS (still incomplete) - lua/src/lib/md5.pir & sha1.pir : wrapper over PMC MD5 & SHA1 (I wrote them on the outside of Lua) - lua/src/lib/random.pir : wrapper over library/Math/Random/mt19937ar.pir (I wrote it on the outside of Lua) - lua/src/lib/uuid.pir : wrapper over library/uuid.pir (I wrote it on the outside of Lua) Since mid-June 2008, I tried to write extension libraries for Pipp (PHP supplies more than 2500 functions !!!, huge work, but I believe that PHP could be the killer application for Parrot) : - pipp/src/common/php_API.pir & php_MACRO.pir : some helpers (argument checking) - pipp/src/common/php_base64.pir : wrapper over library/MIME/Base64.pir (but incomplete because PHP API has more options than MIME/Base64 Perl API) - pipp/src/common/php_ctype.pir : pure PIR - pipp/src/common/php_gmp.pir : started over PMC BigInt, but needs a full NCI binding over gmp - pipp/src/common/php_math.pir : pure PIR - pipp/src/common/php_md5.pir & sha1.pir : wrapper over PMC MD5 & SHA1 - pipp/src/common/php_pcre.pir : wrapper over library/pcre.pir (incomplete because no PhpArray support, and the NCI PCRE is incomplete and seems very old) - pipp/src/common/php_rand.pir : wrapper over PMC Random & library/Math/Random/mt19937ar.pir - pipp/src/common/php_type.pir : pure PIR As I need to write a NCI wrapper over gmp, I begin my study of NCI by using the OpenGL one (with Lua). If I try to summarize my experiment with libraries : Parrot will supply 3 kinds of common libraries for HLL - written in Perl6, but currently not available (I don't know if NQP is suitable for writing library) - written in PIR, but only for bootstrap, because as Bernhard Schmalhofer tell "PIR is not a decent language" + good for libraries not common (in fact equivalent to builtins) - lua/src/lib/bitlib.pir - lua/src/lib/lfs.pir - pipp/src/common/php_ctype.pir - pipp/src/common/php_math.pir - pipp/src/common/php_type.pir + good when no native library available (but a full test suite is needed) - library/Math/Random/mt19937ar.pir (Mersenne Twisted) - binding over native (C/C++) shared libraries + with native PMC (C compile/link) - sometime, for security reason, a static linkage is mandatory (libssl is shared lib, but its subset libcrypto is static lib) - other advantage, PMC allows direct OO interface + with NCI : the best way (no C compile/link) - but only procedural interface (no direct OO) 2 designs choices : - For long term maintenance, I write PIR close to original C. For example, I start Lua on Parrot aligned with version 5.0.2 and now it's 5.1.3. And in most of case, the original C is the only valid (updated) user & requirements documentation. - I try to emit the same (as possible) error or warning messages than the original implementation and to have the same interface. Rule of Least Surprise for the end user. And I could run the test suite against the original implementation. Now, talking about Lua specifics : - Lua Tables are the main (and the only) structured type in Lua, they supply array & hash (like PHP array). They are used to supply the namespace support and the OO mecanism. There are no keyword for namespace. Standard Libraries & others live in their table (ie namespace). So, in the init function of a library, I wrote (or generate) some boring code like : .const .Sub _mod_funct = 'func' _mod_func.'setfenv'(_lua__GLOBAL) set $P1, 'func' _mod[$P1] = _mod_func I wait for a IMCC improvement (hi kjs) in order to support : .macro register(tname, fname) .const .Sub $fname = .fname $fname.'setfenv'(_lua__GLOBAL) set $P1, .fname .tname[$P1] = $fname .endm - Currently, the LuaTable implementation don't support the Parrot namespaces API. But I think it's doable. - Since my first implementation, libraries &
Re: HLLs needing OpenGL support
Geoffrey Broadwell a écrit :
I noticed a couple commits overnight for Lua to support OpenGL. I'm a
bit confused by them, since they don't seem to actually *do* anything,
just lots of (hopefully automatically generated!) scaffolding.
fperrad: How do these bindings actually work?
There'll work with runtime/parrot/library/OpenGL.pir.
François.
Everyone:
We're getting to the stage that HLLs are starting to want common library
access. Some of these already exist as more or less decent PIR bindings
in /runtime/parrot/library/ ; others are either very incomplete or
non-existant. Still, the time has come to be working on making it
easier for HLL authors to get a fully colloquial binding using the
common libraries, rather than having to roll their own from scratch.
pmichaud, jonathan, and I discussed a basic design a few weeks ago in
#parrot for PCT languages to use cross-language modules; the basic
protocol we sketched out should be workable for non-PCT languages as
well. That protocol needs to be fleshed out and implemented.
Also, I would love to know what I can do for the OpenGL binding to make
it more amenable to use by the HLLs. I notice that the Lua bindings
want to unflatten the namespace ('gl.Foo' rather than 'glFoo'). What
other changes do various HLLs typically make to C library bindings?
-'f
Re: [perl #56800] [META] merge pdd25cx branch back into trunk
Bernhard Schmalhofer via RT a écrit :
In r29552 of https://svn.perl.org/parrot/branches/pdd25cx I ran make test
for: pipp, eclectus, hq9plus, lazy-k, m4, unlambda.
All tests were passing.
in branch_pdd25cx, 221/1109 Lua subtests failed.
Mostly for same reason : exception handling.
$ cat nil.lua
print(- nil)
[trunk] $ parrot luc.pbc nil.lua
lua.pbc: EVAL_1:33: attempt to perform arithmetic on a nil value
stack traceback:
EVAL_1:33 in function '&main_10'
languages/lua/src/lib/luaaux.pir:788 in function 'docall'
lua.pir:303 in function 'handle_script'
lua.pir:123 in function 'main'
[branch_pdd25cx] $ parrot lua.pbc nil.lua
lua.pbc: attempt to perform arithmetic on a nil value
in this example, the exception is raised by the following code in
languages/lua/src/pmc/luaany.pmc (line #216)
PMC* neg(PMC *dest) {
PMC *meth = find_meth(INTERP, SELF, "__unm");
if (!meth)
Parrot_ex_throw_from_c_args(INTERP, NULL,
EXCEPTION_ILL_INHERIT,
"attempt to perform arithmetic on a %Ss value",
SELF.name());
...
The global exception handler for Lua is in
languages/lua/src/lib/luaaux.pir (lines 775-823),
with the function 'docall' and the closure 'traceback'.
Missing data are retrieved with the methods 'where' & 'traceback'
implemented in languages/lua/src/pmc/lua.pmc.
How rewrites it in branch_pdd25cx ?
François.
Re: [perl #56558] [PATCH] pdb rename to parrot_pdb
NotFound a écrit : After some discussion in #parrotsketch, the name parrot_debugger wins. Done in r29496, waiting for comments and fixes before closing the ticket. pdb was renamed parrot_debugger, but not installable_pdb. François.
Re: Parrot 0.6.4
Bernhard Schmalhofer a écrit : Hi, on behalf of the Parrot team, I'm proud to announce the release of Parrot 0.6.4 "St. Vincent Amazon." As usual, the Windows setup is available on http://parrotwin32.sourceforge.net/ François. Parrot 0.6.4 is available via CPAN, or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.6.4 News: - Documentation + removed a lot of old information from the FAQ + improved function level documentation - Configuration + removed the configuration item 'has_gnu_m4' + refactored ICU-detection - Languages + ChitChat - improved the Smalltalk implementation + Pipp - renamed Plumhead to Pipp - support for a lot of builtin functions. - Pipp now uses PHP specific data types. - converted from PCT with TGE to PCT with NQP actions - improvements in the PCT variant by using optok parsing - start of object support + pir - simple assignments work + json - added a PCT-based implementation of JSON parsing + lolcode - improved handling of symbols - added support for block handling - added support for globals + Lua - more tests + Rakudo - updated Range implementation - added enums - added generic type declarations (::T) - added runtime mixing of roles with 'does' and 'but' - added generic type declarations - fixed handling of implicit lexicals ($_, $!, and $/) - fixed implicit method calls on $_ - improved complex math builtins, added Complex - moved many builtins to class Any - declaration of lists of variables now work - improved test infrastructure - 910 additional passing spec tests since last release - more convergence with STD.pm grammar - added named 0-ary parsing and ops - Compilers + PCT: - allowed subroutine and method names to be a PAST tree that produces the name - Improved lexical handling - Tools + pbc_disassemble renamed from disassemble - Implementation + allowed .macro_const in PIR + added the flag :lexid(...) for subroutines + made multiple dispatch work for sub types + fixed garbage collection bug related to the metadata attached to a PMC_EXT structure + added a warning when using deprecated opcodes + simplified the stacks implementation + fixed C++ build + improved closure and lexical support + improved IMCC register allocator + added cache for all runtime-constant strings, reducing memory usage - Miscellaneous + improved OpenGL/GLU/GLUT bindings + added a standard profile for Perl::Critic coding standard testing + added support for smoke testing with Smolder + enabled use of Test::Harness 3.0 if available, but don't require it for 'make test' + added the executable 'parrot_config' to query Parrot configuration Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is August 19th 2008. Enjoy!
Re: [perl #37664] [TODO] create autogenerated files read-only
2008/7/12 Bob Rogers <[EMAIL PROTECTED]>: > 9 days and no complaints; done. > When the coda is added by the generator, that's fine. But MANIFEST is generated (with MANIFEST.SKIP) and MANIFEST.generated is not a generated file (but the file that contains all the generated/built files that could be installed). François. > >-- Bob > > > 2008-07-12 17:28:24: > revision: 29361; author: rgrjr > [CORE] Make Emacs coda read-only in generated files (part of #37664). > => /trunk/MANIFEST: action: M > => /trunk/MANIFEST.generated: action: M > => /trunk/config/gen/call_list.pm: action: M > => /trunk/config/gen/platform.pm: action: M > => /trunk/lib/Parrot/Manifest.pm: action: M > => /trunk/lib/Parrot/Ops2c/Utils.pm: action: M > => /trunk/lib/Parrot/Ops2pm/Utils.pm: action: M > => /trunk/tools/build/c2str.pl: action: M > => /trunk/tools/build/jit2c.pl: action: M > => /trunk/tools/build/parrot_config_c.pl: action: M > => /trunk/tools/build/pbcversion_h.pl: action: M > => /trunk/tools/build/vtable_extend.pl: action: M > => /trunk/tools/build/vtable_h.pl: action: M > >
[perl #56694] [PATCH] nullptr segfault in closure.pmc
Since the introduction of :lexid in PCT, the code generation in Lua is
wrong (empty outer). For example :
$ parrot luap.pir --target=pir
Compiler Lua 5.1 on Parrot Copyright (C) 2005-2008, The Perl Foundation.
> print "hello"
.include "interpinfo.pasm"
.HLL "Lua", "lua_group"
.namespace
.sub "&start" :anon :main :lexid("11")
.param pmc args :optional
#print "start\n"
load_bytecode "languages/lua/lua.pbc"
lua_openlibs()
.local pmc env
env = get_hll_global "_G"
.local pmc vararg
vararg = argstolua(env, args)
.const .Sub main = "&main_10"
main."setfenv"(env)
($I0, $P0) = docall(main, vararg :flat)
unless $I0 goto L1
printerr "luap: "
printerr $P0
L1:
.end
.namespace
.sub "&main_10" :anon :lex :lexid("10") :outer("")
.param pmc vararg :slurpy
.const .LuaString k_print = "print"
.local pmc subr
subr = interpinfo .INTERPINFO_CURRENT_SUB
$P11 = subr.getfenv()
set $P12, $P11[k_print]
new $P13, "LuaString"
set $P13, "hello"
$P12($P13)
.end
Instead of :
...
.sub "&start" :anon :main :lexid("11")
...
.sub "&main_10" :anon :lex :lexid("10") :outer("11")
...
Fixed in r29184.
François.
Re: [perl #55842] [BUG] empty .const .String broken
chromatic a écrit :
On Tuesday 08 July 2008 02:36:37 François PERRAD via RT wrote:
This bug starts with r28354 (cache string).
The cache don't handle empty string.
Now, in Pipp (PHP), an empty string is used to stringify boolean False.
// languages/pipp/src/pmc/phpboolean.pmc
STRING* get_string() {
if (PMC_int_val(SELF))
return const_string(INTERP, "1");
else
return const_string(INTERP, "");
}
Instead of an empty string, I obtain another cached string like "MD2",
"PhpUndef", ...
I can't reproduce that with this test case:
.loadlib 'php_group'
.sub 'main' :main
.local pmc true, false
true = new 'PhpBoolean'
false = new 'PhpBoolean'
true = 1
false = 0
$S0 = true
say $S0
$S0 = false
say $S0
.end
On windows, r29191, with this test, I obtain :
D:\fperrad\Parrot\trunk\languages\pipp>parrot bool.pir
1
Php
D:\fperrad\Parrot\trunk\languages\pipp>
and with a Lua PMC test
D:\fperrad\Parrot\trunk\languages\lua>perl -I../../lib t/pmc/string.t
1..13
ok 1 - check inheritance
ok 2 - check interface
ok 3 - check name
ok 4 - check get_bool
ok 5 - check logical_not
ok 6 - check embedded zero
ok 7 - check HLL
ok 8 - check HLL (autoboxing)
ok 9 - check HLL & .const
not ok 10 - .const & empty string
# Failed test '.const & empty string'
# at t/pmc/string.t line 196.
# got: '¤
# 1
# '
# expected: '
# 1
# '
ok 11 - check tostring
ok 12 - check tonumber
ok 13 - check tobase
# Looks like you failed 1 test of 13.
I shaw the same behavior on Xubuntu 8.04 (r29194).
But I notice that this issue is random (disappear or re-appear after an
update & re-compilation).
And when I revert all modifications in src/string.c since r28354, all is
OK.
François.
Do you have PIR which demonstrates it?
-- c
[perl #55842] [BUG] empty .const .String broken
This bug starts with r28354 (cache string).
The cache don't handle empty string.
Now, in Pipp (PHP), an empty string is used to stringify boolean False.
// languages/pipp/src/pmc/phpboolean.pmc
STRING* get_string() {
if (PMC_int_val(SELF))
return const_string(INTERP, "1");
else
return const_string(INTERP, "");
}
Instead of an empty string, I obtain another cached string like "MD2",
"PhpUndef", ...
Re: [perl #43334] [TODO] config/auto/icu.pm: Write unit tests
James Keenan via RT a écrit : On Mon Jul 07 04:46:52 2008, [EMAIL PROTECTED] wrote: Do you think you could 'svn up', reconfigure, and then let me know if your patch is still needed? Also send output of 'prove -v t/steps/auto_icu*.t' and 'perl Configure.pl --verbose-step=auto::icu'. Thanks. output with & without my patch. François. D:\fperrad\Parrot\trunk>prove -v t/steps/auto_icu*.t t/steps/auto_icu-011..81 ok 1 - use config::init::defaults; ok 2 - use config::auto::icu; ok 3 - init::defaults constructor returned defined value ok 4 - The object isa init::defaults ok 5 - init::defaults has description Set up gcc environment - 3.4.5 (mingw special) ok 6 - init::defaults runstep() returned defined value ok 7 - auto::icu constructor returned defined value ok 8 - The object isa auto::icu ok 9 - auto::icu has description ok 10 - auto::icu runstep() returned true value ok 11 - Got expected value for 'has_icu' ok 12 - Got expected value for 'icu_shared' ok 13 - Got expected value for 'icu_dir' ok 14 - Got expected result ok 15 - Got expected value for icu-config ok 16 - Got expected value for icu-config ok 17 - Got expected value for icu-config ok 18 - icu-config not found, as expected ok 19 - Autodetection cancelled, as expected ok 20 - Continuing to configure without ICU ok 21 - icu-config not found, as expected ok 22 - Autodetection cancelled, as expected ok 23 - Continuing to configure without ICU ok 24 - icu-config found, as expected ok 25 - Autodetection continues, as expected ok 26 - Continuing to try to configure with ICU ok 27 - icu-config found, as expected ok 28 - Autodetection continues, as expected ok 29 - Continuing to try to configure with ICU ok 30 - Got expected verbose output ok 31 - icu-config unchanged, as expected ok 32 - Autodetection still active, as expected ok 33 - Continuing to try to configure with ICU ok 34 - icu-config unchanged, as expected ok 35 - Autodetection still inactive, as expected ok 36 - Continuing to try to configure with ICU ok 37 - Got expected verbose output ok 38 - Got expected ld flags ok 39 - Continuing to try to configure with ICU ok 40 - No icushared, as expected ok 41 - No longer trying to configure with ICU ok 42 - icushared remains undefined, as expected ok 43 - Continuing to try to configure with ICU ok 44 - icuheaders path undefined, as expected ok 45 - Continuing to try to configure with ICU ok 46 - Got expected icuheaders path value ok 47 - No longer trying to configure with ICU ok 48 - Got expected icuheaders path value ok 49 - No longer trying to configure with ICU ok 50 - Got expected icuheaders path value ok 51 - Continuing to try to configure with ICU ok 52 - Not trying to configure with ICU ok 53 - icushared undefined, as expected ok 54 - icuheaders undefined, as expected ok 55 - result is still empty string, as expected ok 56 - Still trying to configure with ICU ok 57 - icushared undefined, as expected ok 58 - icuheaders undefined, as expected ok 59 - result is still empty string, as expected ok 60 - Still trying to configure with ICU ok 61 - icushared undefined, as expected ok 62 - icuheaders undefined, as expected ok 63 - result is still empty string, as expected ok 64 - Got expected die message ok 65 - Got expected verbose output ok 66 - Got expected verbose output ok 67 - Got expected verbose output ok 68 - No verbose output, as expected ok 69 - Got expected warnings ok 70 - Got expected warnings ok 71 - Got expected warnings ok 72 - Got expected verbose output ok 73 - Got expected verbose output ok 74 - ccflags augmented as expected ok 75 - No verbose output, as expected ok 76 - ccflags augmented as expected ok 77 - Got expected value for 'has_icu' ok 78 - Got expected value for 'icu_shared' ok 79 - Got expected value for 'icu_dir' ok 80 - Got expected result ok 81 - Completed all tests in t/steps/auto_icu-01.t ok t/steps/auto_icu-021..15 ok 1 - use config::init::defaults; ok 2 - use config::auto::icu; ok 3 - init::defaults constructor returned defined value ok 4 - The object isa init::defaults ok 5 - init::defaults has description Set up gcc environment - 3.4.5 (mingw special) ok 6 - init::defaults runstep() returned defined value ok 7 - auto::icu constructor returned defined value ok 8 - The object isa auto::icu ok 9 - auto::icu has description ok 10 - auto::icu runstep() returned true value ok 11 - Got expected value for 'has_icu' ok 12 - Got expected value for 'icu_shared' ok 13 - Got expected value for 'icu_dir' ok 14 - Got expected result ok 15 - Completed all tests in t/steps/auto_icu-02.t ok t/steps/auto_icu-031..0 # Skip icu-config not available skipped all skipped: icu-config not available t/steps/auto_icu-041..17 ok 1 - use config::init::defaults; ok 2 - use config::auto::icu; ok 3 - init::defaults constructor returned defined value ok 4 - The object isa init::defaults ok 5 - init::defaults has description Set up gcc environment - 3.4.5 (mingw special) ok 6 - init::defaults runstep() returned
Re: [perl #43334] [TODO] config/auto/icu.pm: Write unit tests
James Keenan via RT a écrit :
Please review the patch attached. Note the following:
1. As mentioned in my last post in this RT, the flow in this step
class's runstep() method is quite convoluted. I tried to improve it,
but this step still has five different points at which it can return. I
have, however, created a distinction between those variables which hold
the user's command-line options and those which hold the current state
of the user's attempt to configure with those options.
2. I suspect that some of the command-line options haven't been used in
years. Evidence? The fact that one command-line, --icudatadir, is
mentioned in the Configure.pl --help message (held in
lib/Parrot/Configure/Options/Conf.pm) and in README_win32.pod -- but is
not mentioned anywhere in config/auto/icu.pm, or anyplace else for that
matter! The fact that we have lived happily without this option since
r14398 provides the rationale to remove it from the files where it is
mentioned.
Moreover, I have heard no response to the request in my earlier post for
feedback from people who regularly use the --icushared and --icuheaders
options. I suspect that in practice we could do without those options,
but have taken no action to remove them.
So, if you have any strong feelings about this patch, please speak up.
Otherwise I will apply it to trunk in 3 days (or 2, if I get impatient).
On Windows, no icu-config comes with ICU binaries.
README_win32.pod gives 2 ways :
--without-icu
works fine.
--icushared="C:\usr\lib\icu\lib\icudt.lib
C:\usr\lib\icu\lib\icuuc.lib"
--icuheaders="C:\usr\lib\icu\include"
now fails.
because _try_icuconfig overwrites the values (supplied by command line)
of icushared & icuheader with undef.
The attached patch solves the issue.
François.
Thank you very much.
kid51
Index: config/auto/icu.pm
===
--- config/auto/icu.pm (revision 29107)
+++ config/auto/icu.pm (working copy)
@@ -127,7 +127,9 @@
autodetect => $autodetect,
icuconfig => $icuconfig,
verbose => $verbose,
-}
+},
+$icushared,
+$icuheaders
);
# 3rd possible return point
@@ -272,7 +274,8 @@
my $self = shift;
my $conf = shift;
my $arg = shift;
-my ($icushared, $icuheaders);
+my $icushared = shift;
+my $icuheaders = shift;
if (
( ! $arg->{without} ) &&
$arg->{autodetect}&&
Re: Keep the 'keet Re: Renaming Plumhead
2008/6/15 Bernhard Schmalhofer <[EMAIL PROTECTED]>: > Bill Ricker schrieb: > >> >> Plumhead may sound stupid but there's nothing wrong with Plum-Headed >> Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's >> a real bird whose initials spell PHP, what more could you want in a >> name?. O'Reilly's cover editor will be happy, although they may have >> to hand-tint the old block to get the evocative colo[u]?ring - they're >> quite colo[u]?rful, almost pretty in a garish sort of way, which >> somehow seems appropriate for PHP. >> >> http://en.wikipedia.org/wiki/Plum-headed_Parakeet. >> >> (One /could/ be obscure and use the latin name >> http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) >> >> > On the Wikipedia page I liked the sentence: > > "Plum-headed Parakeet is a gregarious and noisy species with range of > raucous calls." > > This is definitly a good description of PHP. > +1 but currently no opinion for the best short-form. François. > > If what one wants is a short-form of the name that sounds less goofy >> than "Plumhead" but still much fewer keystrokes than Plum-Headed >> Parakeet , perhaps PHPkeet would serve as a logotype for the longer >> formal name with good pun and allusions, and simultaneously serve as a >> Google(tm)-able keyword distinct from the aviary variety? >> >> >> > My favourite short form would be "PHParakeet", pronounced as "P - H - > Parakeet". > This still has the PHP in it, but only as a sensible abbreviation of > "Plum-Headed Parakeet". > > Regards, > Bernhard > >
Re: [perl #52894] [CAGE] use more File::Temp to avoid permission issues
2008/6/9 James Keenan via RT <[EMAIL PROTECTED]>: > Based on our experience with File::Temp in the test suite, I think we > can avoid calling 'chmod' entirely (regardless of OS) and can simply use > File::Temp's functional interface (which avoids that warning I mentioned > in an earlier post). > > François: If the patch attached works for you on Windows, you can apply > it to trunk. It works for me on Linux. > Ok, applied on r28206. François. > > kid51 >
Re: [perl #52894] [CAGE] use more File::Temp to avoid permission issues
James Keenan via RT a écrit : On Sun Jun 08 17:57:56 2008, [EMAIL PROTECTED] wrote: Patch applied in r28188. Will resolve ticket if no one complains within 1-2 days. Thanks, Andy. I had no problems running the two existing step tests for this step via 'prove -v t/steps/auto_perldoc*.t. But I got this warning when running them via 'perl Configure.pl --test', which is tantamount to running them via 'perl t/harness t/steps/auto_perldoc.t': $ perl t/harness t/steps/auto_perldoc*.t t/steps/auto_perldoc-01..10/14 unlink0: /tmp/bYZRgOpN3V.tmp is gone already at t/steps/auto_perldoc-01.t line 41 Nothing fails here; it's only a warning. But if anyone can clarify, that would be helpful to me. Thank you very much. kid51 since r28188, on Windows with ActiveState Perl 5.8.8 (build 822) , I've the following error : Determining whether perldoc is installed... step auto::perldoc died during execution: The fchmod function is unimplemented at config/auto/perldoc.pm line 42. On Windows, the Perl function 'chmod' works with filename (use POSIX chmod) but not the file handle (use POSIX fchmod). François.
Re: [perl #55332] [BUG] can't build parrot on win32 + strawberry perl
2008/6/5 chromatic <[EMAIL PROTECTED]>: > > Look at get_length() in tools/build/c2str.pl. If that's the problem (and > it > looks like it is), that's the place to fix it. > The length computation (in c2str.pl) is correct. There are no missing make dependence. But looks like a missing make dependence (keep old & bad values in all_cstring.str), because on Windows, unlink is not POSIX compliant : unlink on an opened file does nothing (now & after closing). Fix in r28165. François. > -- c > >
Re: [perl #55332] [BUG] can't build parrot on win32 + strawberry perl
Klaas-Jan Stol a écrit :
somehow a fresh checkout has resolved the problem
(but my other sandbox was still up to date according to svn status...)
anyhow, this ticket can be rejected.
I'm not sure.
Since r26988, I've same failure on Windows, with mingw gcc-3.4.2, and
perl 5.8.8 (build 822 from ActiveState).
The following patch solves (or hides) the problem
Index: src/string.c
===
--- src/string.c(revision 28084)
+++ src/string.c(working copy)
@@ -284,7 +284,7 @@
for (i = 0; i < n_parrot_cstrings; ++i) {
interp->const_cstring_table[i] = string_make_direct(interp,
parrot_cstrings[i].string,
-parrot_cstrings[i].len,
+strlen(parrot_cstrings[i].string),
PARROT_DEFAULT_ENCODING, PARROT_DEFAULT_CHARSET,
PObj_external_FLAG|PObj_constant_FLAG);
}
Now, I start to investigate where are the difference with the following
code :
for (i = 0; i < n_parrot_cstrings; ++i) {
if (strlen(parrot_cstrings[i].string) != parrot_cstrings[i].len) {
printf("string_init %d %d 0x%08x %s\n",
strlen(parrot_cstrings[i].string),
parrot_cstrings[i].len,
parrot_cstrings[i].hash_val,
parrot_cstrings[i].string);
}
interp->const_cstring_table[i] = string_make_direct(interp,
parrot_cstrings[i].string,
strlen(parrot_cstrings[i].string),
PARROT_DEFAULT_ENCODING, PARROT_DEFAULT_CHARSET,
PObj_external_FLAG|PObj_constant_FLAG);
}
I obtain the following ouput (note the newline):
string_init 1 2 0x0c38 \
string_init 3 4 0x00334876 ?%d
string_init 1 2 0x0c4a
string_init 1 4 0x003477f8 "
string_init 2 3 0x000193b0 \x
string_init 2 3 0x000193ad \u
string_init 0 2 0x0c0c
I suspect a problem in c2str.pl string only on Windows, something like a
missing or bad binmode.
François.
kjs
On Thu, Jun 5, 2008 at 10:38 AM, via RT Klaas-Jan Stol
<[EMAIL PROTECTED]> wrote:
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #55332]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55332 >
Parrot is built fine, but there seems to be something wrong in PGE.
I'm using visual studio express edition and strawberry perl.
this is the output:
[...]
mingw32-make: Leaving directory `C:/Documents and
Settings/klaas-jan.stol/My Documents/parrot3/src/dynoplibs'
mingw32-make -C compilers\pct
mingw32-make: Entering directory `C:/Documents and
Settings/klaas-jan.stol/My Documents/parrot3/compilers/pct'
..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT.pbc --output-pbc PCT.pir
..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\PAST.pbc
--output-pbc src\PAST.pir
..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\Grammar.pbc
--output-pbc src\PCT\Grammar.pir
..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\HLLCompiler.pbc
--output-pbc src\PCT\HLLCompiler.pir
mingw32-make: Leaving directory `C:/Documents and
Settings/klaas-jan.stol/My Documents/parrot3/compilers/pct'
mingw32-make -C compilers\pge
mingw32-make: Entering directory `C:/Documents and
Settings/klaas-jan.stol/My Documents/parrot3/compilers/pge'
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e rm_f PGE.pbc
..\..\runtime\parrot\library\PGE.pbc
C:\strawberry\perl\bin\perl.exe -e "" >PGE\builtins_gen.pir
..\..\parrot.exe -o PGE.pbc --output-pbc PGE.pir
..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir
--output=PGE\builtins_gen.pir PGE\builtins.pg
Null PMC access in invoke()
current instr.: 'parrot;PGE::Perl6Grammar::Compiler;compile' pc 200
(..\..\runtime\parrot\library\PGE\Perl6Grammar.pir:157)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 753
(src\PCT\HLLCompiler.pir:450)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1065
(src\PCT\HLLCompiler.pir:587)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1257
(src\PCT\HLLCompiler.pir:679)
called from Sub 'parrot;PGE::Perl6Grammar::Compiler;main' pc 16
(..\..\runtime\parrot\library\PGE\Perl6Grammar.pir:66)
mingw32-make: *** [PGE.pbc] Error 1
mingw32-make: Leaving directory `C:/Documents and
Settings/klaas-jan.stol/My Documents/parrot3/compilers/pge'
NMAKE : fatal error U1077: 'mingw32-make' : return code '0x2'
Stop.
=== myconfig ===
Summary of my parrot 0.6.2 (r28084) configuration:
configdate='Thu Jun 5 09:24:55 2008 GMT'
Platform:
osname=MSWin32, archname=MSWin32-x86-multi-thread
jitcapable=1, jitarchname=i386-MSWin32,
jitosname=MSWIN32, jitcpuarch=i386
execcapable=1
perl=C:\strawberry\perl\bin\perl.exe
Compiler:
cc='gcc', ccflags='-DWIN32 -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC
-DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
-DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_
Parsing Machine
The Roberto Ierusalimschy's paper "A Text Pattern-Matching Tool based on Parsing Expression Grammars" http://www.inf.puc-rio.br/~roberto/docs/peg.pdf describes a Parsing Machine that allows a small and efficient implementation of Bryan Ford's PEG (see http://pdos.csail.mit.edu/~baford/packrat/popl04/peg-popl04.pdf). Since 2007, an implementation named 'lpeg' is available as native extension of Lua (the language created by R. Ierusalimschy) with 2 interfaces : - one in regular expression syntax style : http://www.inf.puc-rio.br/~roberto/lpeg/re.html - another following the SNOBOL tradition : http://www.inf.puc-rio.br/~roberto/lpeg.html For example, SciTE-tools, a variant of the SciTE text editor, uses LPEG for syntax highlighting. See a collection of grammar : http://scite-tools.googlecode.com/svn/branches/scite-st/lexers/ Another example : http://luaforge.net/projects/luapod/ François.
Re: [perl #54602] [PATCH] Several changes to allow C++ compiling
NotFound a écrit : Looking more carefully at this issue, it seems that those variables and the code that uses them has no real effect. Without it, make test pass, make testj pass, make hello and make perl6 builds and runs. This patch cleans all. It needs to be tested with make testj in win 32, and for completeness in other jitable platforms, but the variables are only used in the i386 jit files. I already tested in linux i386. with MinGW32, r28058 + no_exec_rel.patch : make hello : build & run make perl6 : build & run make smoke : 10 failed as usual make smokej : 9 failed as usual François.
Re: [perl #54602] [PATCH] Several changes to allow C++ compiling
2008/5/26 NotFound <[EMAIL PROTECTED]>: > Looks like exec_start.c include jit.h and jit_emit.h but doen't use > it. This patch drops those includes and solve the problem, at least in > i386. > I experiment this patch (on src/exec_start.c). On Windows, with MinGW, r28042 : - linking : OK - but execution crash : The procedure entry point Parrot_exec_rel_addr could not be located in the dynamic link library libparrot.dll On Ubuntu 8.04 (x86), r28047 : - linking : OK - but execution crash : symbol lookup error: ./examples/pasm/hello: undefined symbol: Parrot_exec_rel_count François. > -- > Salu2 >
Re: [perl #54602] [PATCH] Several changes to allow C++ compiling
2008/5/24 chromatic <[EMAIL PROTECTED]>: > On Friday 23 May 2008 04:06:45 NotFound wrote: > > > Looking better at the Parrot_exec_rel_... vars, they are not intended > > to be exported at all, they are globals for private usage between exec > > and jit, so they don't need the API or DATA things. This patch cleans > > it, make sure they are defined only in jit.c and declared as extern in > > the others, and also moves his declaration in 386 jit_emit.h before > > his first usage. > > > > I hope that this changes will solve the issue in all platforms. > > > > Next step will be to try to get rid of these globals. > > As this builds in PPC and 64-bit x86 and 32-bit x86, I applied it as > r27785. > Thanks! > on Windows, since r27785, the command 'make hello' can't link. Info: resolving _op_jit by linking to __imp__op_jit (auto-import) src\exec_start.o: In function `emit_disp8_32': D:/fperrad/Parrot/trunk/src/jit_emit.h:171: undefined reference to `Parrot_exec_rel_addr' D:/fperrad/Parrot/trunk/src/jit_emit.h:171: undefined reference to `Parrot_exec_rel_count' D:/fperrad/Parrot/trunk/src/jit_emit.h:171: undefined reference to `Parrot_exec_rel_addr' D:/fperrad/Parrot/trunk/src/jit_emit.h:171: undefined reference to `Parrot_exec_rel_count' src\exec_start.o: In function `emit_r_X': ... the attached patch fixes it. François. > > -- c > > hello.patch Description: Binary data
Re: Parrot 0.6.2 "Reverse Sublimation" Released!
chromatic a écrit : They were walking to the Hemlock, the Rooster and the Mice, and the Mice kept looking at one another, questioning. "We don't know what the future holds, do we?" said Chauntecleer. The Mice all shook their heads. They knew very little of anything. "If," said Chauntecleer, "I say, if I don't come back again, then you must make this food to last a long, long time. I trust your prudence, don't I?" he asked, and they nodded automatically, but their eyes were very big. "And I trust your integrity, right?" They nodded. "And you are mature, now, and I respect your maturity, isn't that so?" Poor Mice, they nodded and nodded, and they blinked, and they nodded. They looked afraid. "Good," said Chauntecleer. "I know I won't be disappointed. In this way he gave each Mouse a manhood. They couldn't talk to him just now, having so much to turn over in their minds. But neither did they cry. -- The Book of Sorrows, by Walter Wangerin Jr. On behalf of the Parrot team, I'm proud to announce Parrot 0.6.2 "Reverse Sublimation." [1]Parrot is a virtual machine aimed at running all dynamic languages. The Windows setup is available on http://parrotwin32.sourceforge.net/ François. Parrot 0.6.2 is available via [2]CPAN (soon), or [3]follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using [4]Subversion or [5]SVK on [6]our source code repository to get the latest and best Parrot code. Parrot 0.6.2 News: * Specification + updated and launched pdd28_strings.pod + updated pdd19_pir.pod * Implementation + added implementation of Rational PMC + simplified ops control flow syntax + enabled backtrace on non-glibc platforms too + improved some PIR error reporting + removed user stack opcodes (save, restore, lookback, entrytype, depth, rotate_up) (NOTE: This was scheduled to occur after 0.7.0, moved up to this release) + removed register stack, saveall, and restoreall opcodes + removed various deprecated features and unused code * Languages + Amber: retired + C99: grammar updated + Cardinal: resurrected, method calls and do blocks work now + Eclectus: use NQP as PAST generating code + Lua: o added big number library o updated to match PGE changes o added a bytecode disassembler & a Lua 5.1 VM bytecode translator + Pheme: updated to match PGE/PCT changes + Plumhead: o use NQP as PAST generating code o use riaxpander for macro expansion + Rakudo: o updated ROADMAP o conditional and loop statement modifiers o lots of class, object, role, and method improvements o Str increment and decrement o improved spectest reporting o type checking on assignment o regexes and grammars o undef and self o placeholder vars + Squaak: added to repository + TAP: retired * Compilers + PGE: updated to match Synopsis 5, deprecated features removed + PCT: o improve handling of register types, conversion between registers o improved error diagnostics o add 'arity' to for loops * Configuration + added step auto::opengl + added step gen::opengl + added step gen::call_list * Miscellaneous + still more optimizations and performance improvements, especially in GC + new libraries: OpenGL/GLU/GLUT bindings (small subset working) + new dump_pbc.pl utility: PBC disassembly/source code weaver + improved C++ compiler support + optimized builds work again Gracias to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! References 1. http://parrotcode.org/ 2. http://search.cpan.org/dist/parrot 3. http://parrotcode.org/source.html 4. http://subversion.tigris.org/ 5. http://svk.bestpractical.com/ 6. https://svn.perl.org/parrot/trunk/
Re: I need Windows OpenGL headers for study/testing
Geoffrey Broadwell a écrit : Thanks to tetragon++, I've now got OpenGL header parsing (mostly) working on both Debian Linux/i386 and Mac OS X 10.5. Now I need headers for Windows to continue the porting work. For each of MSVC, MinGW, and cygwin, I need: 1. Path globs [1] for all OpenGL headers, in the form '/path/to/dir1/*.h', '/path/to/dir2/*.h' 2. A tarball or zip archive of all of these headers Any volunteers who can send me the above for one or more of the Windows compiler environments? Thanks in advance! when I tried OpenGL on MinGW, I found some information on : http://www.transmissionzero.co.uk/computing/using-glut-with-mingw/ http://www.xmission.com/~nate/glut.html I compiled with success the configure step, but not the full wrapper. François. -'f [1] No really, I need the full path globs. I'm actually parsing the headers myself, not just trying to get C code to compile. :-)
Re: [perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
James Keenan via RT a écrit : On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote: I prefer the die behavior, because with it, I don't forget to add tests with auto::crypto. So I'm not alone, after all ;-) Now, I think the name gen::digest is not good. I prefer gen::crypto because : 1) same as auto::crypto 2) libcrypto contains cypher algo (not only digest), so we could add some PMC wrapper (for example : DES, ...) The patch attached renames gen::digest to gen::crypto and makes associated changes. I had one problem pulling the patch. For some reason, config/gen/digest.pm was showing up in Subversion as a "binary" type. I couldn't figure out how to fix that, so if we decide to change the file's name and apply this patch, we may have to do a separate 'svn rm config/gen/digest.pm' to get everything in place. But that should be no impediment to reviewing the patch. Applied in r27116. François Thank you very much. kid51
Re: [perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
James Keenan (via RT) a écrit : # New Ticket Created by James Keenan # Please include the string: [perl #53126] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53126 > I noticed that a new step, auto::digest, has been added to the list of Parrot configuration steps. Two issues: 1. The commit message suggests that this is a refactoring of code previously found elsewhere in the configuration system: r27060 | fperrad | 2008-04-20 15:26:38 -0400 (Sun, 20 Apr 2008) | 2 lines [digest]- refactor digest PMC generation (now a config/gen step) However, when I grep config/*/*.pm for 'digest', the only mention I get (other than in config/gen/digest.pm itself) is here: config/auto/crypto.pm:68:$conf->data->set( has_crypto => $has_crypto );# for dynpmc.in & digest.t So I don't see where the code was refactored from, and I don't understand the rationale for the addition of this step. Previously, the generation was done by src/dynpmc/Makefile (generated from config/gen/makefiles/dynpmc.in) and use some perl -pe "s///" from a template src/dynpmc/mdx.pmc. So it was not the standard way, and it was not enought smart : two files SHA256 & SHA512 need different behaviors for OpenSSL 0.9.7 and 0.9.8. 2. When I now configure with 'perl Configure.pl --test', I get this warning, both at the start of configuration and in t/configure/025- options_test.t andn t/configure/049-options_test.t: No tests exist for configure step gen::digest at Configure.pl line 14 ... which means we've added a configuration step class with no corresponding tests. (Until yesterday, configuration would have simply died at this point, but I acknowledged a request to have it just generate a warning instead.) The test file could be as simple as a two-test file, with one test saying use_ok the new step and another saying 'pass'. I prefer the die behavior, because with it, I don't forget to add tests with auto::crypto. Now, I think the name gen::digest is not good. I prefer gen::crypto because : 1) same as auto::crypto 2) libcrypto contains cypher algo (not only digest), so we could add some PMC wrapper (for example : DES, ...) François. Thank you very much. kid51
Re: Parrot 0.6.1 "Bird of Paradise" Released
2008/4/15 jerry gay <[EMAIL PROTECTED]>: > Aloha! > > On behalf of the Parrot team, I'm proud to announce Parrot 0.6.1 > "Bird of Paradise." Parrot (http://parrotcode.org/) is a virtual machine > aimed > at running all dynamic languages. > The Windows setup is available on http://parrotwin32.sourceforge.net/ François. > > Parrot 0.6.1 can be obtained via CPAN (soon), or follow the > download instructions at http://parrotcode.org/source.html. > For those who would like to develop on Parrot, or help develop > Parrot itself, we recommend using Subversion or SVK on the > source code repository to get the latest and best Parrot code. > > Parrot 0.6.1 News: > - Specification > + drafted pdd29_compiler_tools.pod > + updated pdd28_character_sets.pod draft > + updated pdd19_pir.pod draft > - Languages > + c99: added independent C pre-processor > + HQ9+: reimplemented with PCT > + Lua: >. reimplementation with PCT, using PAST and POST >. behavior aligned wih 5.1.3 > + Rakudo: >. implemented basic I/O, including '$*IN', '$*OUT', '$*ERR', 'prefix:=' >. implemented simple typing and runtime type checking >. added basic multi-method dispatch >. expanded named argument handling, including Pair and colonpairs >. added 'Whatever' and 'Capture' classes >. implemented 'handles' trait verb >. added 'loop' statement >. implemented 'given', 'when', 'for', 'while', 'until' statement > modifiers >. implemented Hash methods '.keys' and '.values' >. fixed bug to get '.WHAT' working correctly >. initial implementation of 'eval' > - Compilers > + NQP: >. created a bootstrapped build, see 'make boot' >. added 'infix:<', 'infix:<=', 'infix:>', 'infix:>=' relational > operators >. added 'postfix:++', 'postfix:--' operators > + PCT: >. added methods specifying default behaviors in PAST, reducing repeated > code >. improved symbol table lookup > + PGE: >. removed deprecated code including: P6Regex, P6Grammar, PAST-pm > - Miscellaneous > + notable speedups during compilation and execution of parrot and HLLs > + pdb (the parrot debugger) can now catch parrot exceptions > + better detection of glibc and gettext during configuration > + various bugfixes, code cleanups, deprecations, and coding standard > fixes > > > Mahalo to all our contributors for making this possible, and our > sponsors for supporting this project. > > Enjoy! > ~jerry > >
The evolution of TGE
In my opinion, TGE is a very good tool, especially for new languages
when the grammar (and its tree structure) is not well established.
The need for language experimentation is not execution performance,
but rapid development and clean design.
The functional paradigm of TGE (like XSLT, transforming tree) allows to
create clean design.
TGE could be used in 2 different stages : parse -> PAST, and PAST -> POST.
The current syntax allows to specified a target language :
transform name (pattern) :language('PIR') {
# action
}
Currently, only PIR is supported.
I think that the support of NQP (action written in NQP, and NQP
generation) will be a great improvement.
By this way, TGE becomes a NQP preprocessor.
Comments most welcome.
François Perrad
Re: macro PIR needs
Original Message Subject: Re: macro PIR needs Date: Mon, 14 Apr 2008 18:03:44 +0200 From: François Perrad <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: jerry gay <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> jerry gay wrote: On Mon, Apr 14, 2008 at 5:03 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote: IMCC's macro processor doesn't currently allow for uniquely generated variable names. It's in the pdd (19), but not yet implemented. You're right in that it only works for labels. kjs On Mon, Apr 14, 2008 at 1:32 PM, François Perrad <[EMAIL PROTECTED]> wrote: > > In Lua libraries, I wrote many time the same piece of code. > The purpose of this code is to register each function. > So, I try to write the following PIR macro : > > .macro register(tname, fname) > .const .Sub $fname = .fname > $fname.'setfenv'(_lua__GLOBAL) > set $P1, .fname > .tname[$P1] = $fname > .endm > also note that .Sub is deprecated, and should be replaced by 'Sub' ~jerry Perhaps in the future, but currently, NO. The syntax new $P0, 'Sub' is OK. But with .const, the only is way .const .Sub funct = 'funct' François.
macro PIR needs
In Lua libraries, I wrote many time the same piece of code. The purpose of this code is to register each function. So, I try to write the following PIR macro : .macro register(tname, fname) .const .Sub $fname = .fname $fname.'setfenv'(_lua__GLOBAL) set $P1, .fname .tname[$P1] = $fname .endm Currently, I obtain the following error : error:imcc:'$fname' is not a valid register name in macro '.register' line 30 included from 'src\lib\base64.pir' line 1 make: *** [src\lib\base64.pbc] Error 2 The notation $fname seems limited to local label (.label) and local variable (.macro_label). Are there any other notation? Or is this a new requirement? The attached patch is a full example for languages/lua/lib/base64.pir François Perrad. Index: base64.pir === --- base64.pir (revision 26867) +++ base64.pir (working copy) @@ -26,6 +26,13 @@ set_hll_global 'luaopen_base64', entry .end +.macro register(tname, fname) +.const .Sub $fname = .fname +$fname.'setfenv'(_lua__GLOBAL) +set $P1, .fname +.tname[$P1] = $fname +.endm + .sub 'luaopen_base64' #print "luaopen_base64\n" @@ -43,16 +50,9 @@ lua_register($P1, _base64) -.const .Sub _base64_decode = 'decode' -_base64_decode.'setfenv'(_lua__GLOBAL) -set $P1, 'decode' -_base64[$P1] = _base64_decode +.register(_base64, 'decode') +.register(_base64, 'encode') -.const .Sub _base64_encode = 'encode' -_base64_encode.'setfenv'(_lua__GLOBAL) -set $P1, 'encode' -_base64[$P1] = _base64_encode - new $P2, 'LuaString' #set $P2, "Copyright (C) 2008, The Perl Foundation"
Re: [ANN] Lua on Parrot 0.6.0
Klaas-Jan Stol wrote: Hi François, lua on parrot seems to have improved a lot, indeed. It's looking really good. Some remarks: * is it possible to show the generated PIR? I can't get life.lua (included with lua distr.), and I'd like to see what's going on under the hood. lua.pbc acts as the original lua interpreter, but luap.pir has an HLLCompiler interface, so try the following command : $ parrot luap.pir --target=pir life.lua François. * running (n)make fails for me on windows,as I don't have yapp installed. Running (n)make test won't work either (because of that) * if you need help with converting to PCT, let me know. kjs On Wed, Mar 19, 2008 at 4:44 PM, François Perrad <[EMAIL PROTECTED]> wrote: Parrot is a VM (virtual machine) designed specifically for running dynamic languages in general, and Perl 6 in particular (see http://www.parrotcode.org/). Parrot is still in development, the latest monthly version is 0.6.0. A complete prototype of Lua 5.1 (aligned on 5.1.3) is available : - an Lua interpreter written in PIR (Parrot Intermediate Representation) that generates PIR - a large subset of the Lua Standard Librairies (written in PIR) - a test suite (more than 980 tests) For the first time, with Parrot 0.6.0, all garbage collection problems seem to be fixed. Documentation starts in http://svn.perl.org/viewcvs/parrot/trunk/languages/lua/doc/running.pod?view=markup and http://svn.perl.org/viewcvs/parrot/trunk/languages/lua/doc/status.pod?view=markup. Any comments, suggestions, bug report, test, improvement are welcome on Parrot mailing list ([EMAIL PROTECTED]). François Perrad.
[ANN] Lua on Parrot 0.6.0
Parrot is a VM (virtual machine) designed specifically for running dynamic languages in general, and Perl 6 in particular (see http://www.parrotcode.org/). Parrot is still in development, the latest monthly version is 0.6.0. A complete prototype of Lua 5.1 (aligned on 5.1.3) is available : - an Lua interpreter written in PIR (Parrot Intermediate Representation) that generates PIR - a large subset of the Lua Standard Librairies (written in PIR) - a test suite (more than 980 tests) For the first time, with Parrot 0.6.0, all garbage collection problems seem to be fixed. Documentation starts in http://svn.perl.org/viewcvs/parrot/trunk/languages/lua/doc/running.pod?view=markup and http://svn.perl.org/viewcvs/parrot/trunk/languages/lua/doc/status.pod?view=markup. Any comments, suggestions, bug report, test, improvement are welcome on Parrot mailing list ([EMAIL PROTECTED]). François Perrad.
Re: Parrot 0.6.0 "P&P" is released.
Bernhard Schmalhofer wrote:
On behalf of the Parrot team, I'm proud to announce Parrot 0.6.0
"P&P."
Parrot (http://parrotcode.org/) is a virtual machine aimed
at running dynamic languages.
This release is a milestone release featuring the
revamping of Parrot Magic Cookies.
The Windows setup is available on http://parrotwin32.sourceforge.net/
François.
Parrot 0.6.0 can be obtained via CPAN (soon), or follow the
download instructions at http://parrotcode.org/source.html.
For those who would like to develop on Parrot, or help develop
Parrot itself, we recommend using Subversion or SVK on the
source code repository to get the latest and best Parrot code.
Parrot 0.6.0 News:
- Specification
+ launched pdd18_security.pod
+ updated pdd17_pmc.pod
+ launching draft of pdd28_character_sets.pod
- Documentation
+ cleanup of IMCC documentation
- Configuration
+ add step auto::gettext
+ add step auto::crypto
- Compilers
+ PCT:
. Fix '-e' option
. Phase out P6Regex in favor of Perl6Regex
+ IMCC:
'.local Array my_arr' is illegal now
- Languages
+ C99: reimplementation with PCT
+ lolcode:
. various updates
. add support for functions with params
. add math functions
+ Rakudo:
. support for 'say'
. first cut at smart matching
. indirect method calls
. support for Pairs
. added methods 'grep' and 'first'
. implement auto{increment,decrement}
. initial implementation of 'perl6doc'
+ Lua:
. various updates
. add base64 library
+ Cardinal: basic support for functions with parameters
+ Pheme: various updates
+ Ecmascript: various updates
+ Tcl: now targeting tcl 8.5.1, no more expected failures in test suite.
(No, this doesn't mean everything's implemented. =-)
+ Eclectus: various updates
+ WMLScript: various updates
- Implementation
+ PDD17 (PMCs)
+ Add library YAML::Dumper
+ Add the MD2, MD4, MD5, RIPEMD160, SHA & SHA1 PMC, as a wrapper
around libcrypto
- Miscellaneous
+ various bugfixes, code cleanups and coding standard fixes
+ consting
+ remove external Perl 5 modules from the Parrot distribution
Thanks to all our contributors for making this possible, and our
sponsors for supporting this project.
Enjoy!
Bernhard Schmalhofer
Re: [perl #51838] [BUG] cygwin build fails
Jonathan Scott Duff (via RT) wrote: # New Ticket Created by "Jonathan Scott Duff" # Please include the string: [perl #51838] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51838 > It's time to use Configure.pl with the option --without-crypto François. --- osname= cygwin osvers= 1.5.24(0.15642) arch= cygwin-thread-multi-64int cc= gcc --- Flags: category=core severity=critical ack=no --- It looks like the latest [digest] changes have somehow broken builds on cygwin. Here's the tail end of the output from make: gcc -o digest_group.dll lib-digest_group.o md2.o md4.o md5.o ripemd160.o sha.o sha1.o -s -L/usr/local/lib -shared -L/home/Compaq_Administrator/parrot/blib/lib -lparrot md2.o: In function `Parrot_MD2_nci_MD2_Init': /home/Compaq_Administrator/parrot/src/dynpmc/./md2.pmc:101: undefined reference to `_MD2_Init' md2.o: In function `Parrot_MD2_nci_MD2_Update': /home/Compaq_Administrator/parrot/src/dynpmc/./md2.pmc:115: undefined reference to `_MD2_Update' md2.o: In function `Parrot_MD2_nci_MD2_Final': /home/Compaq_Administrator/parrot/src/dynpmc/./md2.pmc:132: undefined reference to `_MD2_Final' md4.o: In function `Parrot_MD4_nci_MD4_Init': /home/Compaq_Administrator/parrot/src/dynpmc/./md4.pmc:101: undefined reference to `_MD4_Init' md4.o: In function `Parrot_MD4_nci_MD4_Update': /home/Compaq_Administrator/parrot/src/dynpmc/./md4.pmc:115: undefined reference to `_MD4_Update' md4.o: In function `Parrot_MD4_nci_MD4_Final': /home/Compaq_Administrator/parrot/src/dynpmc/./md4.pmc:132: undefined reference to `_MD4_Final' md5.o: In function `Parrot_MD5_nci_MD5_Init': /home/Compaq_Administrator/parrot/src/dynpmc/./md5.pmc:101: undefined reference to `_MD5_Init' md5.o: In function `Parrot_MD5_nci_MD5_Update': /home/Compaq_Administrator/parrot/src/dynpmc/./md5.pmc:115: undefined reference to `_MD5_Update' md5.o: In function `Parrot_MD5_nci_MD5_Final': /home/Compaq_Administrator/parrot/src/dynpmc/./md5.pmc:132: undefined reference to `_MD5_Final' ripemd160.o: In function `Parrot_RIPEMD160_nci_RIPEMD160_Init': /home/Compaq_Administrator/parrot/src/dynpmc/./ripemd160.pmc:101: undefined reference to `_RIPEMD160_Init' ripemd160.o: In function `Parrot_RIPEMD160_nci_RIPEMD160_Update': /home/Compaq_Administrator/parrot/src/dynpmc/./ripemd160.pmc:115: undefined reference to `_RIPEMD160_Update' ripemd160.o: In function `Parrot_RIPEMD160_nci_RIPEMD160_Final': /home/Compaq_Administrator/parrot/src/dynpmc/./ripemd160.pmc:132: undefined reference to `_RIPEMD160_Final' sha.o: In function `Parrot_SHA_nci_SHA_Init': /home/Compaq_Administrator/parrot/src/dynpmc/./sha.pmc:101: undefined reference to `_SHA_Init' sha.o: In function `Parrot_SHA_nci_SHA_Update': /home/Compaq_Administrator/parrot/src/dynpmc/./sha.pmc:115: undefined reference to `_SHA_Update' sha.o: In function `Parrot_SHA_nci_SHA_Final': /home/Compaq_Administrator/parrot/src/dynpmc/./sha.pmc:132: undefined reference to `_SHA_Final' sha1.o: In function `Parrot_SHA1_nci_SHA1_Init': /home/Compaq_Administrator/parrot/src/dynpmc/./sha1.pmc:101: undefined reference to `_SHA1_Init' sha1.o: In function `Parrot_SHA1_nci_SHA1_Update': /home/Compaq_Administrator/parrot/src/dynpmc/./sha1.pmc:115: undefined reference to `_SHA1_Update' sha1.o: In function `Parrot_SHA1_nci_SHA1_Final': /home/Compaq_Administrator/parrot/src/dynpmc/./sha1.pmc:132: undefined reference to `_SHA1_Final' collect2: ld returned 1 exit status partial link of digest_group failed (256) make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/Compaq_Administrator/parrot/src/dynpmc' make: *** [dynpmc.dummy] Error 2 --- Summary of my parrot 0.5.3 (r26460) configuration: configdate='Tue Mar 18 06:40:02 2008 GMT' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl.exe Compiler: cc='gcc', ccflags=' -pipe -Wdeclaration-after-statement -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations -Wno-missing-format-attribute -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -
Re: One Remaining WMLScript Test Failure
chromatic wrote: We've cleared up almost everything (nice work). Here's the last one: WMLScript/t/string...7/48 # Failed test '- " 3.14 "' # at WMLScript/t/string.t line 93. # got: '4 # ' # expected: '-3.14 # 1 # ' I dug into the code a bit, but nothing in the PMCs jumped out at me. Does this look at all familiar? Fix in r26471. François. -- c
Re: pdd17pmc branch review
chromatic wrote: On Monday 10 March 2008 07:24:44 François Perrad wrote: chromatic wrote: I fixed all of the compilation errors I could find as of r26285. 280 tests fail on the trunk for me and 308 fail on the branch, but they don't look like compilation errors or PDD 17 porting errors. I think the problem is in the wmlsbytecode.pmc (a singleton PMC with only one method 'load'), because the following command has no output : parrot wmlsd.pir t/examples_1.wmlsc The script wmlsd.pir is a disassembler that loads a WMLScript bytecode and dumps it. Other scripts make more complicated thinks after loading the WMLScript bytecode, but all scripts start with this loading step. Could you send me an output of the failure on the trunk on your platform ? Here you are! Thank you. After some ppd17pmc fix (-> r26440), I've only 9 -- c
Re: pdd17pmc branch review
Will Coleda wrote:
I wanted to call attention to part of today's Parrot Sketch:
- Otherwise, the PMC branch is ready for language testing,
will plan to merge it back into trunk next weekend.
So, language developers (and others); please grab a copy of
https://svn.perl.org/parrot/branches/pdd17pmc and check out the
languages to see how they fare compared to their counterparts in
trunk.
With the attached patch, I try to fix build of dotnet.
Now, all tests fail.
François.
Thanks!
Index: languages/dotnet/pmc/managedpointer.pmc
===
--- languages/dotnet/pmc/managedpointer.pmc (revision 26295)
+++ languages/dotnet/pmc/managedpointer.pmc (working copy)
@@ -540,7 +540,9 @@
PMC* get_attr(INTVAL idx)
{
-PMC *ref = SELF.load_pmc();
+PMC *ref;
+Parrot_PCCINVOKE(interp, SELF, const_string(interp, "load_pmc"),
+"->P", &ref);
if (ref)
return VTABLE_get_attr(INTERP, ref, idx);
else
@@ -549,7 +551,9 @@
PMC* get_attr_str(STRING* idx)
{
-PMC *ref = SELF.load_pmc();
+PMC *ref;
+Parrot_PCCINVOKE(interp, SELF, const_string(interp, "load_pmc"),
+"->P", &ref);
if (ref)
return VTABLE_get_attr_str(INTERP, ref, idx);
else
@@ -558,14 +562,18 @@
void set_attr(INTVAL idx, PMC* value)
{
-PMC *ref = SELF.load_pmc();
+PMC *ref;
+Parrot_PCCINVOKE(interp, SELF, const_string(interp, "load_pmc"),
+"->P", &ref);
if (ref)
VTABLE_set_attr(INTERP, ref, idx, value);
}
void set_attr_str(STRING* idx, PMC* value)
{
-PMC *ref = SELF.load_pmc();
+PMC *ref;
+Parrot_PCCINVOKE(interp, SELF, const_string(interp, "load_pmc"),
+"->P", &ref);
if (ref)
VTABLE_set_attr_str(INTERP, ref, idx, value);
}
Re: pdd17pmc branch review
chromatic wrote: On Friday 07 March 2008 02:22:58 François Perrad wrote: in r26261 with MinGW32, Lua PMCs seem OK (thank to chromatic). Several tests fail for me, but it looks like a problem with caller() in Lua, so it's probably beyond my expertise. It looks simpler to fix (if you know how the Lua compiler works, hint hint.) After reverting commit 26097 ([core] Implement does_pmc and ...), I see a different behavior between trunk and ppd17pmc : on trunk : parrot --no-gc lua.pbc -e "print(-nil)" lua.pbc: EVAL_1:30: attempt to perform arithmetic on a nil value stack traceback: EVAL_1:30 in function '&main_10' languages/lua/lib/luaaux.pir:599 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' parrot --no-gc lua.pbc -e "print(#nil)" lua.pbc: EVAL_1:30: attempt to get length of a nil value stack traceback: EVAL_1:30 in function '&main_10' languages/lua/lib/luaaux.pir:599 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' on ppd17pmc : parrot --no-gc lua.pbc -e "print(-nil)" lua.pbc: EVAL_1:30: attempt to perform arithmetic on a nil value stack traceback: EVAL_1:30 in function '&main_10' languages/lua/lib/luaaux.pir:597 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' parrot --no-gc lua.pbc -e "print(#nil)" lua.pbc: (unknown file):-1: attempt to get length of a nil value stack traceback: (unknown file):-1 in function '&main_10' EVAL_1:30 in function '&main_10' languages/lua/lib/luaaux.pir:597 in function 'docall' lua.pir:353 in function 'dostring' lua.pir:247 in function 'runargs' lua.pir:120 in function 'main' The compiler generates : - a call to VTABLE_neg (in luaany.pmc) when "print(-nil)" - a call to METHOD len (in luaany.pmc) when "print(#nil)", # is the Lua length operator After that, in ppd17pmc, the method caller (in lua.pmc) find a new level in the call stack when METHOD len is called. I don't know if it's a expected behavior in ppd17pmc. I'll update the test files to accept the output "(unknown file):-1". François. -- c
Re: pdd17pmc branch review
chromatic wrote: On Friday 07 March 2008 02:22:58 François Perrad wrote: but WMLScript PMCs don't compile : many error like .\wmlsinteger.pmc: In function `Parrot_WmlsInteger_subtract_WmlsString': .\wmlsinteger.pmc:251: error: void value not ignored as it ought to be I fixed all of the compilation errors I could find as of r26285. 280 tests fail on the trunk for me and 308 fail on the branch, but they don't look like compilation errors or PDD 17 porting errors. I think the problem is in the wmlsbytecode.pmc (a singleton PMC with only one method 'load'), because the following command has no output : parrot wmlsd.pir t/examples_1.wmlsc The script wmlsd.pir is a disassembler that loads a WMLScript bytecode and dumps it. Other scripts make more complicated thinks after loading the WMLScript bytecode, but all scripts start with this loading step. Could you send me an output of the failure on the trunk on your platform ? François -- c
Re: pdd17pmc branch review
chromatic wrote: On Friday 07 March 2008 02:22:58 François Perrad wrote: in r26261 with MinGW32, Lua PMCs seem OK (thank to chromatic). Several tests fail for me, but it looks like a problem with caller() in Lua, so it's probably beyond my expertise. It looks simpler to fix (if you know how the Lua compiler works, hint hint.) Currently, some Lua tests are broken in the trunk, this regression comes from commit 26097 ([core] Implement does_pmc and ...). François.
Re: pdd17pmc branch review
Will Coleda wrote:
I wanted to call attention to part of today's Parrot Sketch:
- Otherwise, the PMC branch is ready for language testing,
will plan to merge it back into trunk next weekend.
So, language developers (and others); please grab a copy of
https://svn.perl.org/parrot/branches/pdd17pmc and check out the
languages to see how they fare compared to their counterparts in
trunk.
in r26261 with MinGW32, Lua PMCs seem OK (thank to chromatic).
but WMLScript PMCs don't compile :
many error like
.\wmlsinteger.pmc: In function `Parrot_WmlsInteger_subtract_WmlsString':
.\wmlsinteger.pmc:251: error: void value not ignored as it ought to be
Here, a fragment of wmlsinteger.c :
PMC*
Parrot_WmlsInteger_subtract_WmlsString(PARROT_INTERP, PMC *pmc, PMC
*value, PMC *dest)
{
#line 250 ".\\wmlsinteger.pmc"
PMC * trans = Parrot_WmlsString_nci_parseInt(interp, value);
if (trans->vtable->base_type == dynpmc_WmlsInteger) {
INTVAL result = VTABLE_get_integer(interp, pmc)
- VTABLE_get_integer(interp, trans);
dest = pmc_new(interp, dynpmc_WmlsInteger);
VTABLE_set_integer_native(interp, dest, result);
return dest;
}
return pmc_new(interp, dynpmc_WmlsInvalid);
#line 245 ".\\wmlsinteger.c"
}
Now, back to wmlsinteger.pmc :
PMC* subtract(PMC* value, PMC* dest) {
...
MMD_WmlsString: {
PMC * trans = WmlsString.value.parseInt();
...
So, WmlsString.value.parseInt() seems not correctly managed.
Francois.
Nota: WMLScript is a bytecode translator, so the test suite needs a
WMLScript compiler, you could install it with the command :
cpan WAP::wmls
Thanks!
Re: Parrot 0.5.2 Released
Bob Rogers wrote: On behalf of the Parrot team, I'm proud to announce Parrot 0.5.2 "P.e. nipalensis." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. The Windows setup is available on http://parrotwin32.sourceforge.net/ with a perl6.exe for the first time. François. Parrot 0.5.2 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.2 Highlights: * "make perl6" uses the new pbc_to_exe tool to build a Perl 6 executable. It's still a ways from being a finished implementation of Perl 6, but we're working on that. Come join us! * Parrot now has a LOLCODE implementation! Not an "enterprise-class" computing language, you say? We don't expect anyone to use it for their next app, but at less than 500 lines of source code (and most of that in a subset of Perl 6), it demonstrates the power of the Parrot Compiler Toolkit. See http://lolcode.com/news/i-haz-a-parrot for more. Parrot 0.5.2 News: - Documentation + PDD27 (multiple dispatch) - debut of new design + Numerous small updates to glossary.pod, etc - Compiler Toolkit + NQP: optional, named, and named/required parameters + PIRC: cleanups + PAST: "defined-or" - Languages + New mk_language_shell.pl script creates language stubs + LOLCODE: new + Lua: various + Eclectus: start with support for local variables and procedures, use SXML as intermediate representation + Perl 6: list builtins, compiler directives, command-line options, etc. + "make perl6" now builds a Perl 6 executable + punie: more builtins, control structures, code refactoring + pynie: builtin stubs, more tests - Implementation + New "pbc_to_exe" utility turns bytecode to executables + New set_outer method for subs + Further configuration refactoring for testability + All functions now completely headerized + Concurrency: interpreter schedulers - Deprecations + DYNSELF (changes to SELF; SELF to STATICSELF) + METHOD (replaced by renaming PCCMETHOD) + pmcinfo op (superseded by 'inspect') + get_attr, set_attr, and 8 other vtable methods + See DEPRECATED.pod for details - Miscellaneous + Many bug fixes + Minor speed enhancements with UTF-8 string handling + Debian packaging + consting, attribute marking, warnings cleanup, memory leaks plugged ... The next scheduled Parrot release will be five weeks from today, on 19 February 2008. Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
Re: headerizer and src/atomic/gcc_x86.c
Allison Randal wrote: François and I have been writing over each other's commits on src/atomic/gcc_x86.c, so before I edit again, let's figure out the right way to edit. Andy, the headerizer dies with an error when src/atomic/gcc_x86.c has two functions that are marked with both PARROT_API and PARROT_INLINE. Am I correct in understanding that these two markings should never occur on the same function at the same time? And François, from your commits it looks like parrot_i386_cmpxchg and parrot_i386_xadd need PARROT_API for linking on MinGW32. Can you delete PARROT_INLINE and have it still work? Done, r24639. François. Thanks, Allison
Re: [perl #48735] [DEPRECATED] :: in PIR identifiers
Klaas-Jan Stol via RT wrote: On Sun Dec 16 21:11:34 2007, coke wrote: From PDD 19: NOTE: The use of C<::> in identifiers is deprecated. what exactly does this mean? In Lua, I started to replace (see r23367) : [ 'Lua::io' ] by [ 'Lua'; 'io' ] François I take it that "::" can still appear in typenames, as in "PAST::Op", but not, for instance like so: .local int some::var Is that it?
Re: Parrot 0.5.1 "Hatachi" Released!
Jonathan Worthington wrote: -- Lebennin Silver flow the streams from Colos to Erui In the green fields of Lebennin! Tall grows the grass there. In the wind from the Sea The white lilies sway, And the golden bells are shaken of mallos and alfirin In the green fields of Lebennin, In the wind from the Sea! -- On behalf of the Parrot team, I'm proud to announce Parrot 0.5.1 "Hatachi." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. The Windows setup is available on http://parrotwin32.sourceforge.net/ with following smoke (installed) result : C:\parrot-0.5.1>perl tools\install\smoke.pl 1..22 ok 1 - check pbc_merge ok 2 - check pdump This is parrot version 0.5.1 built for i386-MSWin32. Copyright (C) 2001-2007, The Perl Foundation. This code is distributed under the terms of the Artistic License 2.0. For more details, see the full text of the license in the LICENSE file included in the Parrot source tree. ok 3 - display parrot version ok 4 - check PGE ok 5 - check TGE ok 6 - check nqp ok 7 - check abc ok 8 - check APL ok 9 - check bf ok 10 - check bfc ok 11 - check bfco ok 12 - check dotnet ok 13 - check ecmascript ok 14 - check HQ9Plus Class 'Rational' doesn't exist current instr.: '_init_types' pc 201 (types.pir:45) called from Sub '_common_lisp' pc -1 ((unknown file):-1) not ok 15 - check lisp # TODO Class 'Rational' doesn't exist # Failed (TODO) test 'check lisp' # at tools\install\smoke.pl line 132. ok 16 - check lua ok 17 - check m4 ok 18 - check ook ok 19 - check perl6 "load_bytecode" couldn't find file 'lib/PhemeObjects.pir' current instr.: 'parrot;Pheme::Compiler;main' pc 89 (pheme.pir:73) not ok 20 - check pheme # TODO couldn't find file 'lib/PhemeObjects.pir' # Failed (TODO) test 'check pheme' # at tools\install\smoke.pl line 163. ok 21 - check plumhead No such file or directory current instr.: '__load_macros' pc 29634 (src\grammar\expr\pge2past.tg:292) called from Sub '_main' pc 3 (src\tclsh.pir:36) not ok 22 - check tcl # TODO missing file ? # Failed (TODO) test 'check tcl' # at tools\install\smoke.pl line 179. C:\parrot-0.5.1> François. Parrot 0.5.1 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.1 News: - Documentation + PDD19 (PIR) - reflect state on the ground; incorporate old IMCC docs + PDD25 (Concurrency) - launch out of draft + Improve documentation of deprecated parrot features. - Compilers + PCT: Parrot Compiler Toolkit redesigned and updated + NQP: major updates, including support for namespaces, module/class declarations, methods + IMCC: remove .sym as alias for .local. Remove .pcc_ prefix for calling directives (.pcc_begin became .begin_call). + PIRC: creates an AST during the parse. + PGE: more updates to match S05 syntax. - Languages + perl6: re-implemented using PCT and NQP, new object subsystem + abc: re-implemented using PCT and NQP + eclectus: initial implementation + plumhead: add PCT variant + punie: re-implemented using PCT and NQP, extended to handle subroutines Happy 20th Birthday, Perl! + pynie: re-implemented using PCT and NQP + PIR: start conversion to NQP (under construction) - Implementation + new opcodes: 'die', 'addhandler', 'copy' + Initial implementation of Concurrency PDD + Add 'arity' method to Sub and NCI PMCs - Miscellaneous + Bug cleanup + consting, attribute marking, warnings cleanup, memory leaks, GC... + dead code removal (includes some defunct languages) Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! Jonathan
Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua
Patrick R. Michaud wrote:
On Sat, Dec 15, 2007 at 05:45:56PM +0200, Allison Randal wrote:
Patrick R. Michaud via RT wrote:
Yes, I didn't quite expect anyone to be using PCT::HLLCompiler with
PAST-pm, or supplying their own PAST->POST transformation.
If we need to put the ostgrammar back into the HLLCompiler, we can do
that.
Supplying your own PAST->POST transformation should at least be an
option. HLLCompiler is useful for all HLLs, even ones that don't use
PGE, NQP, PAST, or POST at all in their implementation.
It is possible now. I've been thinking that the way for someone to
supply a custom PAST->POST transformation would be any or all of:
1. Use the addstage(), removestage(), or stages() methods to
change the compiler stage sequence and/or introduce new
or replacement stages for the PAST->POST step.
2. Subclass the PCT::HLLCompiler class to provide a custom
'post' method that calls whatever is desired.
3. Subclass the PAST::Compiler class to provide custom PAST->POST
transformations that might not exist in standard PCT.
Given that this gives us at least three "good" ways to supply
a custom PAST->POST transformation into PCT::HLLCompiler, I didn't
think we really needed a fourth one that is specific to ostgrammars
and TGE.
I'm also thinking that HLLGrammar may evolve slightly so that
each translator can globally register itself with HLLCompilers as
"I know how to transform something of type Foo into another thing
of type Bar". Then an ostgrammar would simply register itself
as another PAST->POST converter, and a HLLCompiler would have some way of
saying "use the ostgrammar instead of POST::Compiler".
The monthly release is today.
So in Lua, I reverted the revision 23368 (HLLCompiler ->
PCT::HLLCompiler). And Lua works with the old HLLCompiler library.
And I'll try to overload PCT::HLLCompiler for the next release 0.5.2.
But, I've another problem : some failure with languages/lua/t/test_lex.t
The following patch fixes it.
But I don't understand why now I must duplicate the declaration of the
token 'ws' in lua51_testlex.pg grammar ; previously this token was
imported for lua51.pg (the full Lua Grammar).
François.
Pm
Index: languages/lua/src/lua51_testlex.pg
===
--- languages/lua/src/lua51_testlex.pg (revision 24033)
+++ languages/lua/src/lua51_testlex.pg (working copy)
@@ -92,6 +92,13 @@
| \]
}
+token ws {
+[ \s+
+| '--'
+| '--' \N*
+]*
+}
+
=head1 AUTHOR
Francois Perrad
Index: languages/lua/test_lex.pir
===
--- languages/lua/test_lex.pir (revision 24033)
+++ languages/lua/test_lex.pir (working copy)
@@ -48,8 +48,6 @@
# import Lua::Grammar::* into Lua::TestLex
$P0 = get_hll_global ['Lua::Grammar'], 'string'
set_hll_global ['Lua::TestLex'], 'String', $P0
-$P0 = get_hll_global ['Lua::Grammar'], 'ws'
-set_hll_global ['Lua::TestLex'], 'ws', $P0
$P0 = get_hll_global ['Lua::Grammar'], 'syntaxerror'
set_hll_global ['Lua::TestLex'], 'die', $P0
Re: [ANN] SF parrot win32
Xiao Yafeng wrote:
Cool!
But if it could include doc would be better.
Many doc are available in share/doc/parrot/docs (POD format).
François.
On Dec 5, 2007 11:38 PM, François Perrad <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I have no personal web site, so I create the project parrotwin32 on
sourceforge : http://parrotwin32.sourceforge.net/
This project supplies only binaries for Windows ( setup.exe form) of the
monthly releases.
I hope that help Parrot end-users (on Windows) and promote the use of
Parrot.
François Perrad.
Re: [ANN] SF parrot win32
Andrew Shitov wrote: I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ Cool, and I also promoted it at http://perl6.ru/parrotwin32/. But an attempt to run perl6.pbc faied: C:\Program Files\parrot-0.5.0-devel>"bin/parrot.exe" languages/perl6/perl6.pbc "load_bytecode" couldn't find file 'PGE.pbc' current instr.: 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Probably setup.exe have to update an environment also? I've found the problem. Don't install Parrot in C:\Program Files\parrot-0.5.0-devel (the proposed path). You must install Parrot in C:\usr\local\parrot-0.5.0 (the letter drive could be change). I've generated Parrot with prefix=/usr/local/parrot-0.5.0. François. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Re: [ANN] SF parrot win32
Andrew Shitov wrote: I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ Cool, and I also promoted it at http://perl6.ru/parrotwin32/. But an attempt to run perl6.pbc faied: C:\Program Files\parrot-0.5.0-devel>"bin/parrot.exe" languages/perl6/perl6.pbc "load_bytecode" couldn't find file 'PGE.pbc' current instr.: 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Probably setup.exe have to update an environment also? We have thousand tests in build tree, but nothing for testing install tree. So, there are missing part. Now, I append a new tools/install/smoke.pl. setup-parrot-0.5.0 is good for only running PIR file, I hope 0.5.1 allow to run others languages. François. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
[ANN] SF parrot win32
I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ This project supplies only binaries for Windows (setup.exe form) of the monthly releases. I hope that help Parrot end-users (on Windows) and promote the use of Parrot. François Perrad.
Lua on Parrot @ FPW'07
I gave a talk at the French Perl Workshop last week. The subject was : Languages Implementation with Parrot - A study case: Lua on Parrot. Now, it's available on http://www.parrotcode.org/talks/LuaOnParrot.pdf François.
Re: pdd19 comments
At 17:18 02/11/2007 -0400, you wrote: François PERRAD wrote: just few comments about pdd19 : 1) Directive .namespace .namespace is currently valid, and I understand its behavior as : back to the default It's in the docs for IMCC (docs/imcc/calling_conventions.pod), but not in the calling conventions or namespaces PDDs. It currently does nothing. And, something more blatantly obvious like: .namespace [ "" ] seems preferable. 2) Directive .const with PMC .const .String str = "text" the form .type is currently required. Have you plan to deprecated it in favour of 'type' ? Ideally, yes. 3) Identifiers What is the meaning of 'letter' in the identifier definition ? - only ASCII 7bit letter, ie [A-Za-z] Yes. - or other unicode letter like ç No. For those you need a string quoted name (which subroutines, globals, lexicals, etc. allow). What is the incidence of the following note ? The use of :: in identifiers is deprecated That's in bareword identifiers. In docs/imcc/syntax.pod (which was a significant source for the first draft of the PIR PDD), identifiers allowed '::' but not any other separators common to other HLLs. Since bareword identifiers are only used internally, it's not really useful to support various HLL separators. Now, some behaviors not correct against pdd19 : 1) Comments between 2 .param I think it's a bug. sub 'main' .param pmc arg1 :optional # this comment is not ignored and causes some troubles .param pmc arg2 :optional print "ok\n" end 2) Directive .const with empty string I think it's bug too, I don't understand the limitation : everything except empty string Francois sub 'main' .const .String empty = '' print empty print "ok\n" end Do you mean "PDD 19 doesn't allow this but should"? Or "PDD 19 allows this but it's not currently implemented"? Allison
pdd19 comments
just few comments about pdd19 : 1) Directive .namespace .namespace is currently valid, and I understand its behavior as : back to the default 2) Directive .const with PMC .const .String str = "text" the form .type is currently required. Have you plan to deprecated it in favour of 'type' ? 3) Identifiers What is the meaning of 'letter' in the identifier definition ? - only ASCII 7bit letter, ie [A-Za-z] - or other unicode letter like ç What is the incidence of the following note ? The use of :: in identifiers is deprecated Now, some behaviors not correct against pdd19 : 1) Comments between 2 .param .sub 'main' .param pmc arg1 :optional # this comment is not ignored and causes some troubles .param pmc arg2 :optional print "ok\n" .end 2) Directive .const with empty string .sub 'main' .const .String empty = '' print empty print "ok\n" .end François.
Re: [perl #46007] [CAGE] licensing cleanup
At 08:25 27/10/2007 -0700, you wrote: On Tue Oct 02 13:39:30 2007, [EMAIL PROTECTED] wrote: > Parrot is no longer licensed under the GPL directly (though it is > available under the GPL through the Artistic 2.0). Update or remove > references to the GPL license in these files: > > debian/copyright:45 Removed mention of some no-longer-existing files in r22523. The other copyrights mentioned are: lib/Digest/Perl/MD5.pm: Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. lib/Pod/: Copyright (c) 2001-2002 Sean M. Burke. All rights reserved. These two will no longer be a problem when we get the external Perl modules removed from the repository and the bundling working correctly. languages/regex/lib/Regex/Grammar.pm: (c) Copyright 1998-2001 Francois Desarmenien, all rights reserved. This file is automatically generated. So what do we do with files in such cases? It is generated from Parse::Yapp, so can we just generate this file on demand rather than have it committed to the repository? This copyright could be easily removed. Currently, Grammar.pm is generated by yapp with the -s option (standalone). So, the package Parse::Yapp::Driver is included (with its copyright) in Grammar.pm. Without this option, only a line "use Parse::Yapp::Driver;" is inserted in Grammar.pm. The constraint is now you need to install Parse::Yapp when you want use the generated file. François. compilers/imcc/imcc.y, compilers/imcc/main.c, compilers/imcc/ parser_util.c, languages/cola/: Copyright (C) 2002 Melvin Smith <[EMAIL PROTECTED]> Much of Melvin's stuff is co-licensed with The Perl Foundation, so can we safely assume that the copyright here can just be updated to Artistic 2.0? > docs/faq.pod:159 There is only one mention of GPL here, and that is to tell people that we use the Artistic 2.0 license and that it's compatible with the GPL, so we don't need to worry about this file anymore. > include/parrot/datatypes.h:4 Removed mention of the GPL in r22524. > include/parrot/list.h:4 Removed mention of the GPL in r22525 > src/datatypes.c:3 > src/list.c:3 Removed mention of the GPL in r22526. > Review these languages and decide whether to update the license or move > them to the google-code repository for Parrot languages: > > languages/lazy-k/calc.lazy:2 > languages/lazy-k/README:21 I don't know what to do with this language. It's not been updated in a while. Should we move it to google-code or should it be deleted? > languages/urm/examples/biggerzero.urm:3 > languages/urm/examples/distance.urm:3 > languages/urm/examples/div.urm:3 > languages/urm/examples/mult.urm:3 > languages/urm/examples/sim.urm:3 > languages/urm/examples/sub.urm:3 > languages/urm/README:137 > languages/urm/t/syn.t:13 > languages/urm/urmc:11 This language is all GPLd, so maybe a good canditate for being moved to google-code. Or perhaps we could ask the author if we can license it under Artistic 2.0? Opinions? If you got this far through this message, thanks! :-) Paul
pdd15 conversion of Lua
The conversion of Lua is ended. The main issue was with the grammar parser : Lua keywords were recognized as identifier. I solve it by renaming the rule 'name' to 'Name' (r22499). This rule is defined in lua/src/lua51.pir and used by lua/src/lua51.pg So, that sounds strange. François.
pdd15 conversion problem in PMC
I've the following problem in languages/lua/pmc/luathread.pmc :
when the creation of Parrot::Coroutine
(runtime/parrot/library/Parrot/Coroutine.pir) was :
.local pmc coro
.const .Sub coro_sub = "enumerate_tree"
coro = new 'Parrot::Coroutine', coro_sub
in luathread.pmc, I wrote (translation PIR to C):
void init_pmc(PMC* sub) {
INTVAL type = pmc_type(INTERP,
const_string(INTERP, "Parrot::Coroutine"));
if (type)
PMC_pmc_val(SELF) = pmc_new_init(INTERP, type, sub);
else
real_exception(INTERP, NULL, E_Exception,
"Parrot::Coroutine not found");
}
now, the creation of Parrot::Coroutine becomes (r21929) :
.local pmc coro
.const .Sub coro_sub = "enumerate_tree"
coro_class = get_class 'Parrot::Coroutine'
coro = coro_class.'new'('initial_sub' => coro_sub)
So, how translate it in PMC ?
Thank for help.
François.
Some feedbacks from Lua experience
I try to summarize all my feedback after this work.
I hope give you some subjects for next parrot sketches.
I) ISSUES
1) Closure & lexical scoping rules
This is the biggest issue versus Lua specifications.
The TODO test in languages/lua/t/closure.t (line 73) shows it
(see also http://www.lua.org/manual/5.1/manual.html#2.6).
I think that Lua needs some think like a specific DynLexPad,
but I can't do this task (too complex for me).
2) Metamethod __call
2 TODO tests in languages/lua/t/metatable.t (line 506 & 539) show this issue.
In languages/lua/pmc/luaany.pmc (line 250), the invoke method must manipulate
arguments because with the following PIR example :
result = obj(arg1, arg2)
the metamethod __call retrieved in the metatable of obj, must be call with
3 parameters (obj, arg1, arg2).
3) garbage collection
How write code without GC problems ?
How track down and fix GC problems ?
4) library debug
This library deals with some low level of the Lua VM (see
http://www.lua.org/manual/5.1/manual.html#5.9).
What's possible with Parrot VM ?
5) back trace & friends
Currently, back trace speaks PIR, and it's fine for debugging.
But in future, it must speak Lua (source name & line number).
II) SUGGESTIONS & QUESTIONS
Concerns the scope of Parrot core, platform assumption (POSIX ?)
1) os.time needs mktime
My current implementation uses a NCI method in lua.pmc (line 206).
Another implementation could be an opcode mktime (the reverse of
decodelocaltime, with the same array definition)
There are the following opcodes : time, gmtime, localtime, decodetime
& decodelocaltime.
It seems that Parrot follows Perl5 where gmtime, localtime, time, times are
builtins functions and mktime is supplied by POSIX::mktime.
If someone has a better explanation or the real reason, I'm interested.
2) os.tmpname
My current implementation uses a NCI method in lua.pmc (line 312)
that calls a C POSIX function (platform dependant: tmpnam or mkstemp).
Another implementation could be a method in the PMC random or ParrotIO.
3) os.tmpfile
My current implementation uses a ParrotIO (so, a standard file) and
the POSIX behavior of unlink for the final destroy.
So, this implementation depends of the platform (really POSIX or not).
Another implementation could be ParrotIO-tmp : a subclass of ParrotIO
with a constructor without filename and a finalizer responsible of the
destroy of the file.
Another implementation could be ParrotIO-String (like the Perl module
IO::String) where temporary files live only in memory.
4) io.popen
pipe in ParrotIO not fully implemented.
5) file:setvbuf
My implementation depends on the methods buffer_type & buffer_size of
ParrotIO PMC.
Currently, these 2 methods are only specified, but not implemented.
6) lfs.touch (utime)
Not yet implemented.
utime could be a method of OS PMC (not found in any documentation).
7) lfs.lock & lfs.unlock
Same as lfs.touch.
III) CRAZY BUGS
1) command line arguments lost in the call tree
$ cat arg.lua
print(...)
print(debug.traceback())
$ parrot luap.pir --target=pir arg.lua > arg.pir
$ parrot --no-gc arg.pir arg1 arg2
# correct
arg1arg2
stack traceback:
arg.pir:41 in function '&main_10'
languages/lua/lib/luaaux.pir:601 in function 'docall'
arg.pir:17 in function '&start'
$ parrot --no-gc lua.pbc arg.lua arg1 arg2
# BAD: all arguments are lost
stack traceback:
EVAL_1:41 in function '&main_10'
languages/lua/lib/luaaux.pir:601 in function 'docall'
lua.pir:302 in function 'handle_script'
lua.pir:122 in function 'main'
When I add some trace code, I see the correct value in 'docall' just before
line 601and after it's the same generated code.
2) other argument lost
On Lua, the mecanism of package uses 2 functions : require & module.
$ cat mod.lua
print("modname:", ...) -- must print "mod" when called by require
print(debug.traceback())
$ parrot --no-gc lua.pbc -e "require 'mod'"
modname:
stack traceback:
EVAL_2:43 in function '&main_34'
languages/lua/lib/luapackage.pir:463 in function 'require'
EVAL_1:33 in function '&main_10'
languages/lua/lib/luaaux.pir:601 in function 'docall'
lua.pir:352 in function 'dostring'
lua.pir:246 in function 'runargs'
lua.pir:119 in function 'main'
now, if you duplicate the line 463 in luapackage.pir [ $P0 = $P1(modname) ],
the second call is correct.
$ parrot --no-gc lua.pbc -e "require 'mod'"
modname:
stack traceback:
EVAL_2:43 in function '&main_34'
languages/lua/lib/luapackage.pir:463 in function 'require'
EVAL_1:33 in function '&main_10'
languages/lua/lib/luaaux.pir:601 in function 'docall'
Re: [ANN] Lua on Parrot 0.4.16
At 11:40 19/09/2007 -0700, chromatic wrote: On Wednesday 19 September 2007 09:58:56 François PERRAD wrote: > Any comments, suggestions, bug report, test, improvement are welcome on > Parrot mailing list ([EMAIL PROTECTED]). Two tests fail reliably for me on x86 GNU/Linux, and one fails now and then: Failed Test Stat Wstat Total Fail List of Failed --- lua/t/alarm.t1 256 61 2 I've some troubles with GC (in Lua PMC, I think). I don't known how track them. lua/t/io.t 1 256411 15 on win32 popen is not implemented, on linux it seems to be, but there are no specific test like this : .sub 'main' :main .local pmc f f = open 'perl -v', '-|' $S0 = read f, 1000 print $S0 print "\n" .end so I'll skip this test in all platforms. lua/t/os.t 1 256251 23 looks like a time zone problem, so I'll modify the test with a less strict condition. François.
Re: [ANN] Lua on Parrot 0.4.16
At 12:00 20/09/2007 -0300, you wrote: Date: Wed, 19 Sep 2007 20:26:52 +0200 From: Mike Pall <[EMAIL PROTECTED]> Subject: Re: [ANN] Lua on Parrot 0.4.16 To: Lua list <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=iso-8859-1 Hi, Fran?ois PERRAD wrote: > Any comments, suggestions, bug report, test, improvement are welcome on > Parrot mailing list ([EMAIL PROTECTED]). Mike, I can't give you an answer, because in a Parrot point of view, I'm only a Parrot user, in fact a language implementor (Lua in this case) in the Parrot terminology. So I am not the guru of internals, JIT or others optimisation issues. But someone on [EMAIL PROTECTED] have responses for you. Thank you for interest, and I am happy to see that the current implementation allows this kind of test. I'm interested by the source of yours benchmarks, for me, it's more test case. Regards. François. Umm, before I make a fool of myself over there ... I've tested this with a few benchmarks. So, maybe I'm missing something essential, but why does --jit-core *slow down* things (5%-10% slower than --computed-goto-core)? And even if it's only interpreted, 20x-33x *slower* than the Lua interpreter seems a bit hefty. And comparing (supposedly) JIT compilers, it's 50x-200x slower than LuaJIT 1.1. Do I need to disable some debug stuff? I just followed the standard build instructions ... Bye, Mike
