Re: Preening the parrot for show
On Feb 19, 2007, at 5:57 PM, Nicholas Clark wrote: There's a benchmark of Ruby implementations at http://www.antoniocangiano.com/articles/2007/02/19/ruby- implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby- net-vs-rubinius-vs-cardinal (or http://xrl.us/uy5m ) There's a comment from Matt Diephouse Did you build an optimized version of Parrot to use with Cardinal? By default, Parrot builds with all optimizations off and with all debug flags on. This makes it slower but makes development a lot easier. The answer was "no" I was wondering - are people doing benchmarks more likely to be using release versions of parrot rather than svn head? If so, would it be a good idea for positive publicity's sake to have the release versions default to optimise? And at the same time, why have the default runcore be the slow core. It's probably better for testing, but for the vast majority of cases, -Cj is faster(although in some instance -j's faster, or -C is faster, or even -S, just depends on the specific benchmark). If we have release versions default to optimize, shouldn't we also try and default to a faster runcore? An optimized parrot with a faster runcore greatly increases speed. Alternatively, given that gcc is capable of building with both debugging and optimising, and a good number of people benchmarking will be on Linux, would it be viable to make the default with gcc to be "-g -O2"? Also, looking through the gcc manpage, one thing caught my eye about optimizing, with regards to CG and CGP. "Note: When compiling a program using computed gotos, a GCC extension, you may get better runtime performance if you disable the global common subexpression elimination pass by adding -fno-gcse to the command line." It would be interesting to benchmark this with parrot, as the cg and cgp runcores work by computed gotos. But, gcse fails on the cgp core because it's too complicated anyway so it may not matter. Anything for that hundredth of a second, right? Either way could try to skew third party benchmarks (and the unpublished private benchmarks we don't even know about) in Parrot's favour. Nicholas Clark
Re: Preening the parrot for show
On Tue, Feb 20, 2007 at 03:05:30AM -0600, Joshua Isom wrote: > Also, looking through the gcc manpage, one thing caught my eye about > optimizing, with regards to CG and CGP. "Note: When compiling a > program using computed gotos, a GCC extension, you may get better > runtime performance if you disable the global common subexpression > elimination pass by adding -fno-gcse to the command line." It would be > interesting to benchmark this with parrot, as the cg and cgp runcores > work by computed gotos. But, gcse fails on the cgp core because it's > too complicated anyway so it may not matter. Anything for that > hundredth of a second, right? The counter to that is that if one can arrange for the compiler to do as many (legitimate) yak shaving optimisations as possible, it frees the programmer's time up to increase functionality (or find better algorithms). Nicholas Clark
Deprecated ops: emit warning?
hi, currently there are some deprecated ops, as listed in: http://www.parrotcode.org/docs/ops/var.html they are not listed in DEPRECATED.pod This is not the first time some ops are deprecated, and will probably not be the last time before the 1.0 release. Is it a good idea to add a check to the parser that checks whether a certain op is deprecated, so it can emit a warning? As Parrot will be more stable from a 1.0 release, this code can be removed, so the overhead of checking is gone. Doing this check, tests using those ops will fail (because there is more output), and there is more "pressure" to start using the new ops. Then, after a deprecation cycle, they can be removed completely. If this is desirable, I'd be happy to provide a patch. Regards, klaas-jan
[PATCH] languages/lua lua.pg Grammar fixes
hi,
attached a patch for the Lua grammar file for PGE (lua.pg).
fixing:
* reorganized some rules w.r.t. "do end"
* rule instead of "..."
* fixed table constructor rules (they now work correctly) -- stolen from
lua51.pg
regards,
kjs
Index: languages/lua/src/lua.pg
===
--- languages/lua/src/lua.pg (revision 17078)
+++ languages/lua/src/lua.pg (working copy)
@@ -22,7 +22,7 @@
rule statement {
|
- |
+ |
|
|
|
@@ -35,11 +35,11 @@
}
rule laststat {
- <'return'> ?
+<'return'> ?
| <'break'>
}
-rule doblock {
+rule dostat {
<'do'>
}
@@ -57,14 +57,14 @@
}
rule whilestat {
- <'while'>
+ <'while'>
}
rule repeatstat {
<'repeat'>
}
-rule forbody {
+rule doblock {
}
@@ -77,7 +77,7 @@
}
rule forstat {
- <'for'> [ | ]
+ <'for'> [ | ]
}
rule ifstat {
@@ -93,7 +93,7 @@
}
rule localdecl {
- <'local'> [ <','> ]* [ <'='> ]?
+ <'local'> [ <'='> ]?
}
rule localfunc {
@@ -101,17 +101,18 @@
}
rule funcname {
- [ <'.'> ]* [ <':'> ]?
+ [ <'.'> ]* ?
}
+rule method {
+ <':'>
+}
+
+
rule index {
<'['>
}
-rule recfield {
- [ | ]
-}
-
rule constructor {
<'{'> ?
}
@@ -125,14 +126,20 @@
}
rule tablefield {
- [ | ]*
+ <'='>
+ | <'='>
+ |
}
rule parlist {
- [ <','> <'...'> ]?
- | <'...'>
+ [ <','> ]?
+ |
}
+token varargs {
+ <'...'>
+}
+
rule body {
<'('> ?
}
@@ -146,14 +153,14 @@
}
rule funcargs {
-<'('> ?
+<'('> ?
|
|
}
rule prefixexp {
- | <'('>
+ | <'('>
}
rule primaryexp {
@@ -163,16 +170,16 @@
| <':'>
|
]*
-
}
+
rule simpleexpr {
|
| <'nil'>
| <'true'>
| <'false'>
- | <'...'>
+ |
|
| <'function'>
|
@@ -281,7 +288,7 @@
=cut
token name {
- \b
+ \b
}
@@ -331,5 +338,5 @@
| <'function'> | <'if'> | <'in'>| <'local'>
| <'nil'> | <'not'>| <'or'>| <'repeat'>
| <'return'> | <'then'> | <'true'> | <'until'>
- | <'while'> ] \b
+ | <'while'>] \b
}
Cross-compiling Parrot
back in 2004, Dan Sugalski wrote: http://www.nntp.perl.org/group/perl.perl6.internals/2004/09/msg25521.html nowadays my effort of porting Parrot to the PocketPC platform, as you may have suspected, force me to reopen the question. there is, I know, a lot of work to be done. and this will surely require a lot of time. and, very probably, much more knowledge than I currently have. but I'm willing to learn, and to live long enough to complete the task. I intend to start submitting patches that do not break things that already work. for example, everything that is pulled out from Perl's %Config will need to be pulled out from somewhere else if, and _only if_, we are currently cross-compiling. (well, this is the plan. I can't exclude that something somewhere may break for some obscure reason, so please bear with me in advance :-). before I start dirting my hands with code, I'm here to ask you: 1) does anybody have objections to patching the current build system for cross-compilation (even "yes, but not now because..." objections)? 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? should I be warnocked, I will silently assume "no" and "no" as answers to the preceeding points :-) cheers, Aldo
Re: Cross-compiling Parrot
On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote: back in 2004, Dan Sugalski wrote: http://www.nntp.perl.org/group/perl.perl6.internals/2004/09/msg25521.html nowadays my effort of porting Parrot to the PocketPC platform, as you may have suspected, force me to reopen the question. there is, I know, a lot of work to be done. and this will surely require a lot of time. and, very probably, much more knowledge than I currently have. but I'm willing to learn, and to live long enough to complete the task. I intend to start submitting patches that do not break things that already work. for example, everything that is pulled out from Perl's %Config will need to be pulled out from somewhere else if, and _only if_, we are currently cross-compiling. (well, this is the plan. I can't exclude that something somewhere may break for some obscure reason, so please bear with me in advance :-). before I start dirting my hands with code, I'm here to ask you: 1) does anybody have objections to patching the current build system for cross-compilation (even "yes, but not now because..." objections)? no objection here! this is a long-desired feature, and is currently unavailable. although i don't have a pocketpc to test on, i'll do my best to help. for years, the dependence on perl 5's configure probes has bothered me--just not enough to fix it. i'm glad to see this porting effort will renew that effort. 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? parrot's configure system is *large*. and it's *working* (at least, for the core platforms, most of the time.) that said, it's still buggy, and we get reports of configure failures here and there. so, changes to configure will affect everybody, and must be well tested. therefore, i suggest a test-driven development style for configure changes. first, we need higher test coverage on configure system. i'm willing to organize a day or two to direct our efforts at testing the configure system in order to get the work done quickly so your efforts are not held up too long. once we have high-enough coverage, we can begin refactoring with considerably more peace of mind than in the current situation. also, we need to smoke configure tests on multiple platforms. i suggest initially you make your changes in a 'porting' branch, and we merge the branch to trunk and smoke it in planned intervals. that way, you get to make small, frequent commits to your branch, and rolling back trunk changes is a simple command as well. also, we won't have to modify our smokers to sometimes build a branch, they can keep running against trunk. since this style hasn't been practiced as a rule in the past, it'll take some time to get used to--for all of us. but i believe it's the safest way to proceed to modify the critical-yet-undertested subsystem that is configure. are you willing to work in the way i described? how does the project team feel about this approach? speaking briefly about a technical plan--there have been discussions of a way forward in the past. the general consensus is that miniparrot be designed to be ANSI C-only, with as few platform-specific extensions as possible, and zero dependence on perl's configure. after miniparrot is built, it can be used to perform the remainder of the build tasks in a portable manner. this gives us a lot of code reuse, and should make future porting efforts easier. however, there's a lot of this design left to flesh out, and none of it is implemented. i think this is the right design, but we need to find one or more ways to get there, and work towards that. however that discussion merits one or more separate message threads. ~jerry
[perl #37542] [TODO] core - document behavior of multiple :load subpragmas in same compilation unit
This behavior *is* defined, according to: http://www.parrotcode.org/docs/imcc/calling_conventions.html And Patrick R. Michaud wrote: First, PGE no longer uses the workaround, and relies on the fact that :load works as documented in calling_conventions.html . But I also think that with things like this we want to make sure that not only is the documentation updated (as given by the TODO), but also that there is test coverage for the behavior described by the new documentation. Fortunately, in this case it looks to me as though t/pmc/sub.t does have tests that check for proper execution of multiple :load subs. So I think this ticket can be safely closed. Thanks, Pm
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
On 20/02/07, Paul Cochrane <[EMAIL PROTECTED]> wrote: On 20/02/07, Will Coleda via RT <[EMAIL PROTECTED]> wrote: > After the application of this test, we have 1265 files that don't pass muster as of 19FEB2007. This is related to the new test in t/distro/file_metadata.t right[1]? In which case this is related to RT#41485. I've set the property appropriately in my working copy, and the test is now passing. Is it ok to do a single commit back to the repository, or is doing a single commit ok? After a discussion on #parrot, it was decided to do a small number of commits (it'll be about 16) updating the svn:eol-style property (changing metadata only). This will affect a *large* number of files, so I'm trying to prepare people before I actually do it. I will begin the update in about 3-4 hours (by approx 19:00-20:00 GMT) and it won't take that long to do (I hope!). Regards, Paul
[svn:perl6-synopsis] r13592 - doc/trunk/design/syn
Author: larry Date: Tue Feb 20 09:35:53 2007 New Revision: 13592 Modified: doc/trunk/design/syn/S12.pod Log: Conjecturalized the delegation-via-hash syntax for now. Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podTue Feb 20 09:35:53 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 27 Oct 2004 - Last Modified: 15 Feb 2007 + Last Modified: 20 Feb 2007 Number: 12 - Version: 41 + Version: 42 =head1 Overview @@ -1325,7 +1325,7 @@ not the declared type. Any other kind of argument to C is considered to be a -smartmatch selector for methods. So you can say: +smartmatch selector for method names. So you can say: has $.fur is rw handles /^get_/; @@ -1334,7 +1334,9 @@ has $.fur is rw handles Groomable; then you get only those methods available via the C role -or class. +or class. To delegate everything, use the C matcher: + +has $the_real_me handles *; Wildcard matches are evaluated only after it has been determined that there's no exact match to the method name anywhere. When you have @@ -1369,22 +1371,26 @@ This is not considered a wildcard match unless the "handles" argument forces it to be. -If your delegation object happens to be a hash: +[Conjectural: the hash syntax is reserved until we figure out the +semantics we really want, and whether this actually buys us anything +over normal polymorphism.] If your delegation object happens to be +a hash: has %objects handles 'foo'; -then the hash provides a mapping from the string value of "self" -to the object that should be delegated to: +then the hash provides a mapping from a set of Selectors specified as Pair +keys to the object specified as the Pair value that should be delegated to: has %barkers handles "bark" = (Chihauhau => $yip, Beagle => $yap, Terrier => $arf, StBernard => $woof, + * => $ruff, ); method prefix:<~>( return "$.breed" ) -If the string is not found in the hash, a "C" is +If the current object matches no Selector, a "C" is automatically performed. =head1 Types and Subtypes
Re: Cross-compiling Parrot
On Feb 20, 2007, at 8:44 AM, jerry gay wrote: On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote: no objection here! this is a long-desired feature, and is currently unavailable. although i don't have a pocketpc to test on, i'll do my best to help. for years, the dependence on perl 5's configure probes has bothered me--just not enough to fix it. i'm glad to see this porting effort will renew that effort. Using perl 5's configure probes also somewhat limits us to how the vendor distributed perl. It should also be considered that we can't rely on perl5 being available, especially since we intend to replace it eventually, so rewriting all the perl to support cross compiling would likely not be the best thing. 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? parrot's configure system is *large*. and it's *working* (at least, for the core platforms, most of the time.) that said, it's still buggy, and we get reports of configure failures here and there. so, changes to configure will affect everybody, and must be well tested. therefore, i suggest a test-driven development style for configure changes. first, we need higher test coverage on configure system. i'm willing to organize a day or two to direct our efforts at testing the configure system in order to get the work done quickly so your efforts are not held up too long. once we have high-enough coverage, we can begin refactoring with considerably more peace of mind than in the current situation. If we create a new configure system, we can essentially have two configuration methods in the trunk, and have tests for the new one to be sure it's working and portable before trying to get everyone to start using it. also, we need to smoke configure tests on multiple platforms. i suggest initially you make your changes in a 'porting' branch, and we merge the branch to trunk and smoke it in planned intervals. that way, you get to make small, frequent commits to your branch, and rolling back trunk changes is a simple command as well. also, we won't have to modify our smokers to sometimes build a branch, they can keep running against trunk. since this style hasn't been practiced as a rule in the past, it'll take some time to get used to--for all of us. but i believe it's the safest way to proceed to modify the critical-yet-undertested subsystem that is configure. are you willing to work in the way i described? how does the project team feel about this approach? speaking briefly about a technical plan--there have been discussions of a way forward in the past. the general consensus is that miniparrot be designed to be ANSI C-only, with as few platform-specific extensions as possible, and zero dependence on perl's configure. after miniparrot is built, it can be used to perform the remainder of the build tasks in a portable manner. this gives us a lot of code reuse, and should make future porting efforts easier. however, there's a lot of this design left to flesh out, and none of it is implemented. i think this is the right design, but we need to find one or more ways to get there, and work towards that. however that discussion merits one or more separate message threads. ~jerry I've noticed a lot that mentions miniparrot being used for building parrot, but at the same time, we don't have anything to work with to know just how limited miniparrot should be. Perhaps a step to work for before rebuilding the configure subsystem(which theoretically should be in pir to get rid of perl5 dependence), is to get an actual miniparrot working? Currently miniparrot just seems to be a macroparrot with a miniconfig. If we can't realistically get a miniparrot, maybe it should be considered if building a miniparrot for configuration is a good idea. Instead of rewriting everything now in perl5 to support cross compiling, maybe we should dive in and try to see if we can get it rewritten in pir. After all, we're getting more pir programmers than perl5 programmers it seems.
Re: Cross-compiling Parrot
On Tuesday 20 February 2007 03:55, Aldo Calpini wrote: > 2) does anybody already have a .plan or something in mind about it (so > that I may either learn from what others have thought, or avoiding > reinventing some wheel)? It would be nice, though I don't know how feasable it is, to be able to plop one or more data files where Configure can read them instead of running the probes on the compiling system. That may make it much easier to generate that data on the target. -- c
Re: [perl #41538] readline kills parrot on files missing a final newline
On Monday 19 February 2007 01:49, Joshua Isom wrote: > The problem lies in io_buf.c, at line 562. My best guess is that it > doesn't check that it hasn't gone past the end of the buffer. In some > instances, parrot segfaults at this location, but it may take a while. Tested in 17079, fixed in r17103. -- c
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
On 20/02/07, Paul Cochrane <[EMAIL PROTECTED]> wrote: On 20/02/07, Paul Cochrane <[EMAIL PROTECTED]> wrote: > On 20/02/07, Will Coleda via RT <[EMAIL PROTECTED]> wrote: > > After the application of this test, we have 1265 files that don't pass muster as of 19FEB2007. > > This is related to the new test in t/distro/file_metadata.t right[1]? > In which case this is related to RT#41485. I've set the property > appropriately in my working copy, and the test is now passing. Is it > ok to do a single commit back to the repository, or is doing a single > commit ok? After a discussion on #parrot, it was decided to do a small number of commits (it'll be about 16) updating the svn:eol-style property (changing metadata only). This will affect a *large* number of files, so I'm trying to prepare people before I actually do it. I will begin the update in about 3-4 hours (by approx 19:00-20:00 GMT) and it won't take that long to do (I hope!). The tests in t/distro/file_metadata.t should now pass as of r17102 Paul
Y not
I think the ¥ and Y operators are going to have to change to something else.
The current Y has at least four strikes against it:
* It's an ASCII version of a cute Unicode picture, but other than that,
the picture it doesn't remind you of "zip" at all, especially in
the Y form.
* Functional programmers are likely to continually confuse it with the
Y combinator, and they'll be confused enough as it is.
* It violates the item-vs-list meme that we acquired with x vs xx and
X vs XX.
* Huffmanly speaking, it's rather short for its weight.
Those last reasons suggest that we want something spelled with a double
letter like XX. I thought about replacing it with YY (and letting Y
be the string form of zip), but that looks even less like a zipper.
But I do like the double letter idea for infix listops. It helps them
stand out more. I suspect we'll have a lot of
for @foo XX @bar XX @baz -> $x, $y, $z {...}
as list comprehensions of cross operators, so you'd like to have something
similar for "zip" semantics, and I think the obvious thing is:
for @foo ZZ @bar ZZ @baz -> $x, $y, $z {...}
You'll note that this has association of using the same letter, but
for those who mourn the loss of the word picture, note that the two
Z's form a pair of parallel lines in the middle, indicating that zip
treats the arrays in parallel. Plus the Z itself can be taken to be
a picture of "row major" visitation order: "first you go across, then
go to the beginning of the next row, then go across again."
The Z operator would presumably be the equivalent of >>~<< except that,
as a list infix, it would take a list on either side rather than two
scalar objects as hyperops do.
One could go as far as to say that Z*Z is the list infix form of >>*<<.
Anyway, I think we're close to establishing a convention that a list
infix should generally be formed from two capital letters, with the
additional proviso that if the list infix promotes to a meta operator,
the base operator goes in the middle. And if there's a stringwise or
scalar form, it's the single letter.
'Course, if someone goes ahead and adds the Y combinator, one must
naturally begin to wonder what the YY combinator would be... :-)
Larry
Re: Y not
On Tuesday 20 February 2007 12:42, Larry Wall wrote: > 'Course, if someone goes ahead and adds the Y combinator, one must > naturally begin to wonder what the YY combinator would be... :-) Obviously it generates a function so anonymous that it can't even refer to itself. I call it the depressed existentialist solipsist operator. -- c
Re: [perl #41529] [BUG]: t/perl/Parrot_Distribution.t test failure
On Saturday 17 February 2007 08:27, jerry gay wrote: > as noted in my svn log at time of checkin, this is a failing test > which exposes a bug in Parrot::Distribution. '*.t' files are only perl > files if the shebang says they are, but Parrot::Distribution is > classifying all '*.t' files as perl files, which is incorrect. the fix > belongs in lib/Parrot/Distribution.pm. Fixed in r17069. -- c
Re: Y not
Larry Wall schrieb: > I think the ¥ and Y operators are going to have to change to something else. Very probably I missed something as I'm only a distant observer of the Perl6 development: Why not just call it "zip"?! There is a function called zip, wouldn't it be possible to create an operator with the same name? zip(@a; @b) -> function @a zip @b -> operator Or would that lead to grammar ambiguities, that are impossible to resolve? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Y not
Thomas Wittek wrote:
Larry Wall schrieb:
> I think the ¥ and Y operators are going to have to change to something else.
Very probably I missed something as I'm only a distant observer of the
Perl6 development: Why not just call it "zip"?!
There is a function called zip, wouldn't it be possible to create an
operator with the same name?
zip(@a; @b) -> function
@a zip @b -> operator
Or would that lead to grammar ambiguities, that are impossible to resolve?
more generally, could we say that any function that has no parameters
other than a list - i.e., :(*@) - automatically gets a list-infix
operator form as well? e.g.:
my sub zip([EMAIL PROTECTED]) { ... }
could be called with
zip (@a; @b; @c)
or
@a zip @b zip @c
--
Jonathan "Dataweaver" Lang
Re: Y not
On Wed, Feb 21, 2007 at 12:49:20AM +0100, Thomas Wittek wrote: : Larry Wall schrieb: : > I think the ¥ and Y operators are going to have to change to something else. : : Very probably I missed something as I'm only a distant observer of the : Perl6 development: Why not just call it "zip"?! : There is a function called zip, wouldn't it be possible to create an : operator with the same name? : : zip(@a; @b) -> function : @a zip @b -> operator : : Or would that lead to grammar ambiguities, that are impossible to resolve? Hmm, but then what corresponds to XX? I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c -> zip operator ZZ(@a; @b; @c) -> zip function @a XX @b XX @c -> cross operator XX(@a; @b; @c) -> cross function @a X*X @b X*X @c -> cross product operator X*X(@a; @b; @c) -> cross product function @a MM @b MM @c -> minmax operator MM(@a; @b; @c) -> minmax function Larry
Re: Y not
Larry Wall wrote: Hmm, but then what corresponds to XX? I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c -> zip operator ZZ(@a; @b; @c) -> zip function @a XX @b XX @c -> cross operator XX(@a; @b; @c) -> cross function @a X*X @b X*X @c -> cross product operator X*X(@a; @b; @c) -> cross product function @a MM @b MM @c -> minmax operator MM(@a; @b; @c) -> minmax function But the X*X already has a meaning: * under the cross metaoperator. Maybe you could use DD instead (for dot product). Joe Gottman
Re: Y not
[Off-list] I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c -> zip operator ZZ(@a; @b; @c) -> zip function @a XX @b XX @c -> cross operator XX(@a; @b; @c) -> cross function @a X*X @b X*X @c -> cross product operator X*X(@a; @b; @c) -> cross product function @a MM @b MM @c -> minmax operator MM(@a; @b; @c) -> minmax function I'm not strongly opposed to this, unless they're the *only* forms of the functions. If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Damian
Re: Y not
On 21/02/07, Damian Conway <[EMAIL PROTECTED]> wrote: [Off-list] Apparently not. Just pretend I'm not here. ;-) Damian
Re: Y not
On Tue, Feb 20, 2007 at 08:50:07PM -0500, Joe Gottman wrote: : Larry Wall wrote: : >Hmm, but then what corresponds to XX? I'd be more inclined to go : >the other way and say that you can transform any list infix form to : >the corresponding function form: : > : >@a ZZ @b ZZ @c -> zip operator : >ZZ(@a; @b; @c) -> zip function : > : >@a XX @b XX @c -> cross operator : >XX(@a; @b; @c) -> cross function : > : >@a X*X @b X*X @c -> cross product operator : >X*X(@a; @b; @c) -> cross product function : > : >@a MM @b MM @c -> minmax operator : >MM(@a; @b; @c) -> minmax function : > : > : > : > : But the X*X already has a meaning: * under the cross metaoperator. : Maybe you could use DD instead (for dot product). Oh, sorry, I mean "cross product" in the literal cross-multiply sense, not in the mathematical sense of dot product. But yeah, this would also a way for mathematicians to add similar vector operators in a somewhat consistent naming style. 'Course, if they're going to go to that extreme they'll probably just use ⋅ or some such. Larry
Re: [svn:parrot] r17107 - trunk/src/stm
On Tuesday 20 February 2007 19:01, [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/stm/backend.c
>
> Log:
> [stm]: don't access a null pointer
>
> Modified: trunk/src/stm/backend.c
> ===
>=== --- trunk/src/stm/backend.c(original)
> +++ trunk/src/stm/backend.c Tue Feb 20 19:01:12 2007
> @@ -1338,6 +1338,9 @@
> void Parrot_STM_destroy_extracted(Interp *interp, void *saved_log_data) {
> STM_saved_tx_log *saved;
>
> +if (saved_log_data == NULL)
> +return;
> +
> saved = saved_log_data;
> mem_sys_free(saved->reads);
> mem_sys_free(saved->writes);
I'm not sure this is the right fix; there's little reason to use an STMLog PMC
if it doesn't get a valid transaction log. My vote is for the PMC's init()
to throw an exception.
If that's not the case, then at least both of Parrot_STM_mark_extracted() and
Parrot_STM_replay_extracted() need similar null guards.
-- c
Re: Y not
Damian Conway wrote: > I'd be more inclined to go > the other way and say that you can transform any list infix form to > the corresponding function form: > > @a ZZ @b ZZ @c -> zip operator > ZZ(@a; @b; @c) -> zip function > > @a XX @b XX @c -> cross operator > XX(@a; @b; @c) -> cross function > > @a X*X @b X*X @c -> cross product operator > X*X(@a; @b; @c) -> cross product function > > @a MM @b MM @c -> minmax operator > MM(@a; @b; @c) -> minmax function Can't you already do this, with square braces? @a XX @b XX @c [XX] (@a; @b; @c) etc? Or am I missing something about the reduction metaoperator? I'm not strongly opposed to this, unless they're the *only* forms of the functions. If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Hear, hear. I very much prefer 'zip' and 'minmax' to 'ZZ' and 'MM'. -- Jonathan "Dataweaver" Lang
