Re: Parrot 0.7.0 Severe Macaw
Bob Rogers a écrit :
On behalf of the Parrot team, I'm proud to announce Parrot 0.7.0 Severe
Macaw. Parrot (http://parrotcode.org/) is a virtual machine aimed at
running all dynamic languages.
As usual, the Windows setup is available on
http://parrotwin32.sourceforge.net/
François.
Parrot 0.7.0 is available 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 on the source code repository to get the latest and
best Parrot code.
Parrot 0.7.0 Highlights:
* The new concurrency implementation makes its debut in 0.7.0. See
http://www.parrotcode.org/docs/pdd/pdd25_concurrency.html for more.
* Rakudo (Perl 6) now supports class attributes and multiple dispatch,
plus some metaclass support, among others.
Parrot 0.7.0 News:
- Specification
+ PDD27: add multisub lookup
- Implementation
+ new concurrency implementation (see PDD25)
+ Exception PMC now captures a return continuation
+ improved PMC encapsulation (Iterator, Key, Pair)
- Languages
+ Cardinal (Ruby):
- class variables
- parsing improvements
- minor additions to class builtins
- add support for block parameters to functions
+ Lua:
- various language fixes
- refactor all libraries (namespace, method registration)
- add a OpenGL binding (still incomplete)
- lost user back trace (see ppd25 pushaction)
+ Pipp (PHP):
- add support for while- and for-loops
- add support for increment and decrement
- designate PHP 5.3 as the reference implementation
- improve support for string literals
+ Pugs (Perl 6):
- removed due to bit rot
+ Rakudo (Perl 6):
- now over 2200 passing spectests
- updated the Rakudo roadmap
- Perl 6 multi dispatch
- dispatch with slurpies
- class attributes (my $.x)
- anonymous classes
- OO and metaclass improvements (.WHAT, .WHICH, .WHENCE)
- additional builtin methods and subs
- improved make test targets and harness
+ Tcl:
- implement [lreverse], [lsort -command]
- allow [incr] to autovivify
- update tclsh spec target to 8.5.3
- fix bug in TclDict PMC, allowing ~200 more [dict] spec tests to pass
- update 'make spectest' fudging, using TODO instead of SKIP if possible
- Compilers
+ PCT:
- :scope('register') for PAST::Var nodes
- allow invocant specification in attribute scope PAST::Var nodes
- correct ordering of sub generation from POST
- add 'loadinit' attribute to PAST::Block for block initialization
+ PIRC:
- PIR registers now use the vanilla register allocator
- all PASM output now uses PASM registers
- all .locals and $registers are mapped
- clean-up of grammar, back-end and documentation
- implemented constant folding
- implemented instruction selection
- Configuration
+ tests now clean up after themselves
+ improved parallel test support
+ ports/cygwin added
+ Darwin problems fixed
- Tools
+ parrot_debugger renamed from pdb, numerous tweaks
- Miscellaneous
+ IMCC cleanups
+ :vtable implies self in PIR
+ modest core speed improvements
+ Cygwin support improved
+ say now an opcode (was dispatched to a method; see Deprecations)
- Deprecations
+ .pragma n_operators is deprecated
+ old PASM register syntax (without $) is deprecated
+ bare (unquoted) method names are deprecated
+ #line will be replaced with .line
+ .HLL_map syntax will change
+ .loadlib is now separate from .HLL
+ mmdvtregister and mmdvtablefind opcodes are deprecated
+ removed getfd, getclass opcodes
+ removed IMCC syntax that treated some methods as builtins
+ removed numeric get_attr and set_attr vtable entries
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 16 Sep 2008.
Enjoy!
-- Bob Rogers
http://rgrjr.dyndns.org/
[perl #58088] [PATCH] [pdd27mmd] Rename Parrot_mmd_sort_candidate_list
Thanks, applied in r30349.
Questions about GSOC
Hey guys, Today I saw Andrew's last post in his blog about the end of gsoc. Since I could not find much information about the NCI and GC projects I'm asking here: What's the status of these projects? Andrew's last post seems discouraging. How much of the new GC is completed? Are we going to have a new GC this year? What are the main problems that remain and have to be solved? And about the NCI project... I couldn't find any information about it. What's going on there?
Re: arrayref/hashref in spectest suite
On Monday, 18. August 2008 20:38:05 Patrick R. Michaud wrote: I would somewhat expect a reference to be instead handled using a statement like $foo[1] := $bar; Comments and clarifications appreciated. I would also opt for copy semantics whenever = is used for assignment. But it seems to be the case that this is not deep, just like captures are only one level deep readonly. So, I would also expect $foo[1] = \$bar to result in 24. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[perl #58138] Methods outside class declarations
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #58138]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58138
masak rakudo: method x { say self }; x(1)
polyglotbot OUTPUT[1]
masak question: should methods be allowed outside class declarations? :)
moritz don't think so ;-)
* masak files rakudobug
Re: Questions about GSOC
gsoc_nci code is available in branches/gsoc_nci_001 jitted nci stubs works on i386 WIN32 and i386 LINUX Its probably going to be merged this week. Kevin Nikolay Ananiev wrote: Hey guys, Today I saw Andrew's last post in his blog about the end of gsoc. Since I could not find much information about the NCI and GC projects I'm asking here: What's the status of these projects? Andrew's last post seems discouraging. How much of the new GC is completed? Are we going to have a new GC this year? What are the main problems that remain and have to be solved? And about the NCI project... I couldn't find any information about it. What's going on there?
Re: Parrot 0.7.0 publicity
Bob Rogers wrote: 2. I've managed to log in at Perl Monks, but can't even figure out how to post. (I managed it last time, so I must be getting stupider.) Click on the Perl News link, and scroll down to the bottom of the page where it says Add a piece of Perl News. Fill in the title, fill in the text (note that perlmonks uses HTML. So paragraphs go into p.../p, the list of news should go into code.../code tags). Then click Preview, and if everything looks like you want it, to clik Submit. No rocket science ;-) Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Resumable exceptions
Here's a simple test for resumable exceptions that I'm trying to get to work. I'm probably coding/understanding something wrong, so any suggestions or pointers would be greatly appreciated. .sub main :main push_eh catcher 'foo'() pop_eh say 'ok 4' .return () catcher: .get_results ($P0, $S0) $P1 = $P0['retcont'] $P1() .end .sub 'foo' say 'ok 1' $P0 = new 'Exception' throw $P0 say 'ok 2' $P0 = new 'Exception' throw $P0 say 'ok 3' .end What I'm trying to do is to test the ability to resume after exceptions thrown by Cfoo. The Cmain sub above sets up a handler to catch exceptions, then calls Cfoo. The handler simply resumes any exception that is caught. The Cfoo sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. Pm
[svn:parrot-pdd] r30378 - trunk/docs/pdds
Author: kjs Date: Wed Aug 20 07:13:25 2008 New Revision: 30378 Modified: trunk/docs/pdds/pdd19_pir.pod Log: [pdd19] document :instanceof pragma. pmichaud++ for writing it Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Wed Aug 20 07:13:25 2008 @@ -510,6 +510,13 @@ subroutines in the file may have the same name (because they are multi, or in different namespaces). +=item :instanceof( string_constant ) + +The C:instanceof pragma is an experimental pragma that creates a sub as a +PMC type other than 'Sub'. However, as currently implemented it doesn't +work well with C:outer or existing PMC types such as CClosure, +CCoroutine, etc. + =back
Re: [PATCH] Help catching gc errors in HLL
On Mon, Jun 2, 2008 at 7:18 PM, chromatic [EMAIL PROTECTED] wrote: I like the general idea, but I wonder if there's something cleaner than an environment variable. Nothing really comes to mind at the moment besides making argument processing even uglier in IMCC's main.c. Let's think about it for a little bit, but I really like the idea. I've included a 'gcdebug' command in parrot_debugger that toggles a garbage collection cycle before each opcode in the debugger runloop, allowing the functionality proposed in this patch (when parrot_debugger reaches a more stable state). -- Salu2
[svn:parrot-pdd] r30384 - trunk/docs/pdds
Author: kjs Date: Wed Aug 20 09:51:31 2008 New Revision: 30384 Modified: trunk/docs/pdds/pdd26_ast.pod Log: [pdd26] add description for register scope + add missing ')' + mention :vtable subs have 'self' too (in attribute scope description). Modified: trunk/docs/pdds/pdd26_ast.pod == --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_ast.pod Wed Aug 20 09:51:31 2008 @@ -203,7 +203,21 @@ the attribute belongs. If this child is not present, the attribute is assumed to belong to the current invocant, indicated by the special variable Cself (which is implicitly passed to all subs -that are flagged as a C:method. +that are flagged as a C:method or C:vtable). + +=item register + +Register variables are limited in scope to the CPAST::Block node +in which they are declared. This is different from the Clexical +scope, which Iincludes any nested CPAST::Block nodes. If the +node's Cisdecl attribute is true, then this node defines a new +register variable within the current block. Register variables +are mapped to Parrot registers, and are useful for handling the +PIR pseudo-variable Cself and storing intermediate results. +Names given to the Cname attribute must conform to rules for +PIR identifiers. If no Cname atribute is set, Parrot registers +are used. In this case, setting the Cisdecl does not have any +effect. =back
Re: Questions about GSOC
On Wed, Aug 20, 2008 at 01:00:24PM +0300, Nikolay Ananiev wrote: Today I saw Andrew's last post in his blog about the end of gsoc. Since I could not find much information about the NCI and GC projects I'm asking here: What's the status of these projects? Andrew's last post seems discouraging. How much of the new GC is completed? It's just about functionally complete, but there are a couple of difficult-to-debug bugs remaining. I figured out one of them the other day, but as with most new GC problems, it'll take a while to find and fix. Are we going to have a new GC this year? Yes. What are the main problems that remain and have to be solved? The overall concepts of the incremental GC are solid, but a couple of details of the implementation need polishing. It's difficult to debug these types of problems, and even more difficult to estimate them. (In particular, interleaving GC headers and GC'd elements leads to some troublesome offset manipulation.) It's not clear what the best approach to merging is; I should have encouraged Andrew to work in smaller steps, such that he could run all of the tests after each change and expect that they'd all pass. -- c
Re: Questions about GSOC
On Wed, Aug 20, 2008 at 1:15 PM, chromatic [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 01:00:24PM +0300, Nikolay Ananiev wrote: Today I saw Andrew's last post in his blog about the end of gsoc. Since I could not find much information about the NCI and GC projects I'm asking here: What's the status of these projects? Andrew's last post seems discouraging. How much of the new GC is completed? It's just about functionally complete, but there are a couple of difficult-to-debug bugs remaining. I figured out one of them the other day, but as with most new GC problems, it'll take a while to find and fix. Are we going to have a new GC this year? Yes. What are the main problems that remain and have to be solved? The overall concepts of the incremental GC are solid, but a couple of details of the implementation need polishing. It's difficult to debug these types of problems, and even more difficult to estimate them. (In particular, interleaving GC headers and GC'd elements leads to some troublesome offset manipulation.) It's not clear what the best approach to merging is; I should have encouraged Andrew to work in smaller steps, such that he could run all of the tests after each change and expect that they'd all pass. -- c You can always try to identify the chunks ex post facto and start the merge back a chunk at a time; not as easy as identifying the bits ahead of time, but doable. If it's *close* (and mostly passing tests) we can always throw it back into trunk immediately after a monthly release and give ourselves 4 weeks to clean it up. -- Will Coke Coleda
Re: Questions about GSOC
On Wed, Aug 20, 2008 at 01:22:33PM -0400, Will Coleda wrote: On Wed, Aug 20, 2008 at 1:15 PM, chromatic [EMAIL PROTECTED] wrote: The overall concepts of the incremental GC are solid, but a couple of details of the implementation need polishing. It's difficult to debug these types of problems, and even more difficult to estimate them. (In particular, interleaving GC headers and GC'd elements leads to some troublesome offset manipulation.) You can always try to identify the chunks ex post facto and start the merge back a chunk at a time; not as easy as identifying the bits ahead of time, but doable. If it's *close* (and mostly passing tests) we can always throw it back into trunk immediately after a monthly release and give ourselves 4 weeks to clean it up. Right now TGE fails to build, because the Integer PMCs stored in the interpreter class type registry get collected inappropriately. That's on GNU/Linux on x86, which is as forgiving as a platform gets. There are likely platform-specific bugs on PPC and Sparc and 64-bit platforms, not to mention with compilers other than GCC. Tracking down bugs and crashes to a specific checkin will be difficult. If we can figure out the class registry bug and get tests to pass reliably, we might be able to get more platform testing and consider a merge back. As it is now, it's riskier than I like. I don't want to block Rakudo, at least for more than overnight. -- c
Re: arrayref/hashref in spectest suite
On Mon, Aug 18, 2008 at 01:38:05PM -0500, Patrick R. Michaud wrote:
: There are quite a few tests in the spectest suite that
: make mention of arrayref and hashref, and that expect
: things to work like references do in Perl 5. I'd like to
: get some confirmation/clarification on them.
:
: Here's one example:
:
: my $foo = [ 42 ];
: my $bar = { a = 23 };
: $foo[1] = $bar;
: $barb = 24;
:
: say $foo[1]b; # 24 or undef ???
:
: The test suite expects 24 to be output here, treating
: treating C $foo[1] as a reference to the hash in
: C$bar, such that any changes to C$bar are also reflected
: in C$foo[1]. Is this correct Perl 6? I would somewhat expect
: a reference to be instead handled using a statement like
:
: $foo[1] := $bar;
:
: Comments and clarifications appreciated.
Well, sure, you can use := for clarity, but we left = in the language
to provide (to the extent possible) the same semantics that it
does in Perl 5. And when it comes to non-value types, there really
are still references, even if we try not to talk about them much.
So I think assignment is basically about copying around identities,
where value types treat identity differently than object types (or
at least, objects types that aren't pretending to be value types).
In any case, an array or a hash is not pretending to be a value type,
so it just clones its identity (a reference, if you will) by default.
It's quite possible this is insane, but I can't tell in my current
state of jet lag.
Larry
Re: Allowing '-' in identifiers: what's the motivation?
On Tue, Aug 19, 2008 at 11:59:50PM +0200, Aristotle Pagaltzis wrote:
: * Peter Scott [EMAIL PROTECTED] [2008-08-13 19:20]:
: If we allow operator symbols in identifiers then the world
: will divide into those people who look at Perl 6 programs
: only through syntax-highlighting editors and don't know what
: all the fuss is about naming a variable $e*trade since it is
: all purple, and those people who give up on reading the other
: people's programs.
:
: False dilemma. See Bob Rogers’ mail in this thread; some
: languages already allow all these symbols and the net effect
: is zero, because they take more work to type and people are
: lazy.
:
: That said, I really *really* like the idea of embedded dashes
: in identifiers (not least because underscores offend my amateur
: typophile self), but the idea of being able to embed other
: operator-ish symbols in identifiers leaves me utterly cold. I
: strongly doubt that if they are put in, it’ll cause the end of
: Perl 6, as you argue, but I also don’t care at all about whether
: they are allowed. I’m not going to use them anyway.
If one wants them, all you need to do is override the apostrophe rule
in the standard grammar, so I'm not going to go out of my way to add
maximum flexibility to the base grammar. Currently the apostrophe
rule reads:
token apostrophe {
[ ' \- ]
}
Larry
[perl #58176] [PATCH] dotnet exceptions
# New Ticket Created by Reini Urban
# Please include the string: [perl #58176]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58176
---
osname= cygwin
osvers= 1.5.25(0.15642)
arch= cygwin-thread-multi-64int
cc= gcc
---
Flags:
category=languages
severity=high
ack=no
---
make dotnet work with the new exceptions.
I'm not sure how to return the jump_point correctly, but it looks fine.
---
Summary of my parrot 0.7.0 (r0) configuration:
configdate='Wed Aug 20 18:34:46 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='-U__STRICT_ANSI__ -pipe -I/usr/local/include
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC
-DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
-DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT
-falign-functions=16 -maccumulate-outgoing-args -W -Wall
-Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment
-Wdisabled-optimization -Wendif-labels -Wextra -Wformat
-Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
-Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces
-Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare
-Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default
-Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings
-Wbad-function-cast -Wdeclaration-after-statement
-Wimplicit-function-declaration -Wimplicit-int -Wmain
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull
-DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT',
Linker and Libraries:
ld='gcc', ldflags=' -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base ',
cc_ldflags='',
libs='-L/usr/local/lib -lcrypt -lgmp -lreadline -lpcre -lglut32
-lglu32 -lopengl32 -lcrypto -lintl'
Dynamic Linking:
share_ext='.dll', ld_share_flags='-shared',
load_ext='.dll', ld_load_flags='-shared'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
Locally applied patches:
[perl #39742] [BUG] installed conflict
[perl #51944] [DOCS] Cygwin Readme
[perl #56544] [PATCH] install_files.pl
[perl #56998] [PATCH] rename cygwin dll to cygparrot$MAJ_$MIN_$P.dll
[perl #57006] [PATCH] add cygwin opengl config quirks
[perl #56554] [TODO] make install -C languages
[perl #58034] [TODO] config_args
[perl #56996] [TODO] FHS runtime paths
---
Environment:
CYGWIN =server
HOME =/home/rurban
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH
=~/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/usr/bin:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Programme/ATI
Technologies/ATI.ACE/Core-Static:/usr/local/bin:/usr/lib/gstreamer-0.8:/usr/lib/lapack
SHELL (unset)
Index: parrot-svn/languages/dotnet/ops/dotnet.ops
===
--- parrot-svn.orig/languages/dotnet/ops/dotnet.ops
+++ parrot-svn/languages/dotnet/ops/dotnet.ops
@@ -88,7 +88,10 @@ static opcode_t* dotnet_OverflowExceptio
PMC *ex_pmc = pmc_new(interp, enum_class_Exception);
VTABLE_set_string_native(interp, ex_pmc,
string_from_literal(interp, System.OverflowException));
-return (opcode_t *)throw_exception(interp, ex_pmc, ret);
+VTABLE_set_integer_keyed_str(interp, ex_pmc,
+severity, EXCEPT_error);
+Parrot_ex_throw_from_c(interp, ex_pmc);
+return ret;
}
Index: parrot-svn/languages/dotnet/pmc/dotnetassembly.pmc
===
--- parrot-svn.orig/languages/dotnet/pmc/dotnetassembly.pmc
+++ parrot-svn/languages/dotnet/pmc/dotnetassembly.pmc
@@ -1848,7 +1848,7 @@ pmclass DotNetAssembly dynpmc group dotn
free(filename);
if (!in)
-Parrot_ex_throw_from_c_args(INTERP, NULL, E_IOError,
+Parrot_ex_throw_from_c_args(INTERP, NULL, EXCEPTION_PIO_ERROR,
Unable to open file %s, filename);
/* Attempt to load the PE parts of the file; this locates the CLI
@@ -2184,12 +2184,9 @@ pmclass DotNetAssembly dynpmc group dotn
/* If we don't have an assembly or nothing is loaded, throw an
exception and leave. */
-if (ass == NULL || ass-loaded == 0)
-{
-EXCEPTION_INVALID_OPERATION(INTERP, NULL,
NCI and Calling Conventions (esp. on Windows)
AFAICT, Parrot uses function pointers for NCI. This means NCI uses whatever calling convention the compiler uses by default. Unfortunately, there's More Than One Way To Do It. On Windows, there's the C calling convention (__cdecl), which is usually used by default by the Visual C++ compiler. There's also the standard (__stdcall) and fast (__fastcall) calling convention. I haven't seen any use of fastcall, but stdcall is used by the Win32 API. Using the wrong calling convention most certainly blows the stack. I think we need a way to select the calling convention for a function, similar to, or maybe even part of, the signature. Also, it would be good to have a way to select a calling convention when loading a library, as a calling convention is usually used consistently, and providing defaults for well known libraries. Ron
[Link] Deep Dynamic Language Runtime
A quick overview of Microsoft's Dynamic Language Runtime (DLR). http://channel9.msdn.com/shows/Going+Deep/John-Lam-and-Martin-Maly-Deep-DLR/ Ron
Re: NCI and Calling Conventions (esp. on Windows)
On Wed, 2008-08-20 at 22:20 +0200, Ron Blaschke wrote: I think we need a way to select the calling convention for a function, similar to, or maybe even part of, the signature. Also, it would be good to have a way to select a calling convention when loading a library, as a calling convention is usually used consistently, and providing defaults for well known libraries. tewk's C99 parser / NCI JIT code should handle part of this (and could be expanded to do more). We may want to just settle on extending that work as needed, rather than trying to shoehorn it into old-style NCI. -'f
Re: Moving GC MS
Andrew Whitworth wrote: I created a new branch tonight, /branches/pdd09gc to try to continue some of my GC work from the summer with a blank slate. I have a few cleanup jobs I want to do first, so that it should be easier to add in a new GC without having so many problems as I had. One thing I've wanted to do is to separate out all the MS collector from src/gc/dod.c and src/gc/smallobject.c into a new src/gc/gc_ms.c. I've made this change already in my branch, and if there are no objections I would like to merge this change over into trunk. I think it gives us better consistency with the other GC cores we're making (src/gc/gc_gms.c, src/gc/gc_ims.c, src/gc/gc_it.c), and keeps GC hackers from having to jump back and forth between files to see functions that are part of the same essential subsystem. Any disagreements? chromatic or I will code review it. The general principle sounds sane. Allison
Re: Questions about GSOC
chromatic wrote: If it's *close* (and mostly passing tests) we can always throw it back into trunk immediately after a monthly release and give ourselves 4 weeks to clean it up. The important thing to remember is that the GSOC project wasn't revamp the GC system to meet the new spec it was implement a tri-color, incremental GC module for Parrot. Andrew did that, quite well. There's a separate milestone (funded by NLNet) for the full implementation, which includes integrating Andrew's work. Under the revised timeline, that milestone is due October 15th. We shouldn't rush to merge in code that isn't ready to merge. It will be merged, though, after some additional work. Andrew might be disappointed that he didn't reach the top of Mt. Everest, but he far exceeded our expectations, and congratulations are in order. Allison
Re: Parrot 0.7.0 Severe Macaw - permissions
Will Coleda wrote: Please open a ticket tracking this if we're not going to apply it right now so we don't miss it for next release. CPAN is great for distributing Perl modules, but simply can't handle Parrot. As soon as we have the alternate FTP site up, we're done with CPAN. Allison
[CAGE] clean up stray test files
Running 'make test' now fills the main directory of the repository with junk files like: test_98093.out test_37653.c test_98093.ldo test_97159.c The offending tests need to be modified to clean up after themselves. Allison
Re: [CAGE] clean up stray test files
On Wed, Aug 20, 2008 at 2:32 PM, Allison Randal [EMAIL PROTECTED] wrote: Running 'make test' now fills the main directory of the repository with junk files like: test_98093.out test_37653.c test_98093.ldo test_97159.c The offending tests need to be modified to clean up after themselves. make sure to use File::Temp for any files created via Perl 5. these files should be written to an appropriate temp directory for the platform, not to the root of the parrot source directory. ~jerry
The False Cognate problem and what Roles are still missing
Hi $Larry et al, I brought this up as a question at YAPC::EU and found to my surprise that no one seems to have thought of it yet. This is the mail I said I’d write. (And apologies, Larry. :-) ) Consider the classic example of roles named Dog and Tree which both have a `bark` method. Then there is a class that for some inexplicable reason, assumes both roles. Maybe it is called Mutant. This is standard fare so far: the class resolves the conflict by renaming Dog’s `bark` to `yap` and all is well. But now consider that Dog has a method `on_sound_heard` that calls `bark`. You clearly don’t want that to suddenly call Tree’s `bark`. Unless, of course, you actually do. It therefore seems necessary to me to specify dispatch such that method calls in the Dog role invoke the original Dog role methods where such methods exist. There also needs to be a way for a class that assumes a role to explicitly declare that it wants to override that decision. Thus, by default, when you say that Mutant does both Dog and Tree, Dog’s methods do not silently mutate their semantics. You can cause them to do so, but you should have to ask for that. I am, as I mentioned initially, surprised that no one seems to have considered this issue, because I always thought this is what avoiding the False Cognate problem of mixins, as chromatic likes to call it, ultimately implies at the deepest level: that roles provide scope for their innards that preserves their identity and integrity (unless, of course, you explicitly stick your hands in), kind of like the safety that hygienic macros provide. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Resumable exceptions
Patrick R. Michaud wrote: What I'm trying to do is to test the ability to resume after exceptions thrown by Cfoo. The Cmain sub above sets up a handler to catch exceptions, then calls Cfoo. The handler simply resumes any exception that is caught. The Cfoo sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. The old exception system deleted a handler as soon as it was retrieved for an exception. For backward-compatibility, the new exception system replicates that mis-feature. The problem is, if you end up throwing an exception in the middle of handling another one, and didn't mark the handler somehow, you can easily get an infinite loop of thrown exceptions (when the handler gets some data it didn't expect from the second exception, and so throws another exception). In an ideal world: a) every exception handler would first check the type of the exception it was passed, and rethrow any exceptions it can't handle. b) exception handlers would only be deleted by 'pop_eh', and otherwise would simply pass out of scope after leaving the context where they were defined. Since (a) has to be in place before (b) can work, it was delayed. (And I just changed the name of the 'retcont' attribute to 'resume', to make it a little clearer.) Allison
Re: Fwd: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else)
Klaas-Jan Stol wrote:
I'm sorry, but this is not the case. It is in fact valid:
running:
==
.sub main
newclass $P0, foo
$P1 = new foo
$P1 .hi() # note the space before the dot
$P1. hi() # note the space after the dot
.end
.namespace [foo]
.sub hi :method
print hi\n
.end
==
prints hi\n twice on my system and always has since I've worked on pir..
Ah, my code example had some other syntax error, which it was reporting as:
error:imcc:syntax error, unexpected DOT, expecting '(' ('.')
in file 'method_call_whitespace.pir' line 5
Yes, those spaces do work.
And they shouldn't work.
(this is because, in imcc's lexer a '.' is always returned as DOT (for
object/method separation) and a '.' is only returned as a concatenation
operator iff it is surrounded by whitespace on both sides; the actual
reg.expr for this in imcc.l is {WS}'.'{WS} )
Which explains why it was interpreting 'foo . bar()' as CONCAT, even
though a concatenation operation makes absolutely no sense in that context.
In all, I don't want to make too big an issue out of this, just trying
to clean up the peculiarities and have them documented :-)
Agreed, I've spent about all the time on it I'm willing to spend.
The valid syntaxes containing '.' are:
var.method(args)# method call
var = var/val . var/val # concatenation
var .= var/val# concatenation
Anything we can do to tighten the implementation and allow *only* those
three is progress. But, it may just wait until the next PIR implementation.
Allison
Re: [CAGE] clean up stray test files
Allison Randal wrote: Running 'make test' now fills the main directory of the repository with junk files like: test_98093.out test_37653.c test_98093.ldo test_97159.c The offending tests need to be modified to clean up after themselves. Are these happening notwithstanding the patches I applied for RTs 57956, 57958 and 58036? If so, could you please post the content of the straggler files? That way, I can identify whether they're a byproduct of configuration tests or not. Along the same lines, after deleting existing straggler files, could you run perl Configure.pl, with and without --test=configure, so that we can see whether they're coming from configuration itself or from the pre-configuration tests. Thank you very much. kid51
Re: Parrot 0.7.0 publicity
From: Moritz Lenz [EMAIL PROTECTED] Date: Wed, 20 Aug 2008 14:14:46 +0200 Bob Rogers wrote: 2. I've managed to log in at Perl Monks, but can't even figure out how to post. (I managed it last time, so I must be getting stupider.) Click on the Perl News link, and scroll down to the bottom of the page where it says Add a piece of Perl News . . . Ah, the *bottom* of the page! It could be that I'm stupider than last time, or just more impatient. No rocket science ;-) Cheers, Moritz No, of course not. But even rocket scientists have to be able to find the launch button. ;-} Thanks, -- Bob
Re: The False Cognate problem and what Roles are still missing
On Wed, Aug 20, 2008 at 3:16 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
Hi $Larry et al,
I brought this up as a question at YAPC::EU and found to my
surprise that no one seems to have thought of it yet. This is
the mail I said I'd write. (And apologies, Larry. :-) )
Consider the classic example of roles named Dog and Tree which
both have a `bark` method. Then there is a class that for some
inexplicable reason, assumes both roles. Maybe it is called
Mutant. This is standard fare so far: the class resolves the
conflict by renaming Dog's `bark` to `yap` and all is well.
But now consider that Dog has a method `on_sound_heard` that
calls `bark`.
You clearly don't want that to suddenly call Tree's `bark`.
Unless, of course, you actually do.
It therefore seems necessary to me to specify dispatch such that
method calls in the Dog role invoke the original Dog role methods
where such methods exist. There also needs to be a way for a
class that assumes a role to explicitly declare that it wants
to override that decision. Thus, by default, when you say that
Mutant does both Dog and Tree, Dog's methods do not silently
mutate their semantics. You can cause them to do so, but you
should have to ask for that.
I am, as I mentioned initially, surprised that no one seems to
have considered this issue, because I always thought this is what
avoiding the False Cognate problem of mixins, as chromatic likes
to call it, ultimately implies at the deepest level: that roles
provide scope for their innards that preserves their identity and
integrity (unless, of course, you explicitly stick your hands in),
kind of like the safety that hygienic macros provide.
My thoughts:
Much of the difficulty comes from the fact that Mutant [i]doesn't[/i]
rename Dog::bark; it overrides it. That is, a conflict exists between
Dog::bark and Tree::bark, so a class or role that composes both
effectively gets one that automatically fails. You then create an
explicit Mutant::bark method that overrides the conflicted one; in its
body, you call the Tree::bark method (or the Dog::bark method, or both
in sequence, or neither, or...) As such, there's no obvious link
between Mutant::bark and Tree::bark. Likewise, you don't rename
Dog::bark; you create a new Mutant::yap that calls Dog::bark.
One thing that might help would be a trait for methods that tells us
where it came from - that is, which - if any - of the composed methods
it calls. For instance:
role Mutant does Dog does Tree {
method bark() was Tree::bark;
method yap() was Dog::bark;
}
As I envision it, was sets things up so that you can query, e.g.,
Mutant::yap and find out that it's intended as a replacement for
Dog::bark. Or you could ask the Mutant role for the method that
replaces Dog::bark, and it would return Mutant::yap.
It also provides a default code block that does nothing more than to
call Dog::bark; unless you override this with your own code block, the
result is that Mutant::yap behaves exactly like Dog::bark.
By default, this is what other methods composed in from Dog do: they
ask Mutant what Dog::bark is called these days, and then call that
method. All that's left is to decide how to tell them to ask about
Tree::bark instead, if that's what you want them to do.
--
Jonathan Dataweaver Lang
