[perl #41099] [PATCH] root.in Makefile and CREDITS
Thanks! Applied in r16183.
Re: [perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003
chromatic via RT wrote: With ICU optional these days, is this still necessary? Since Windows doesn't ship with a C compiler and this toolkit is one of the easiest ways to get hold of one for free, then yes, it's good to have it documented. (It may be *called* the C++ toolkit, but it's also what you need to compile C code. Go figure. :-)) Jonathan
Re: [perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003
Jonathan Worthington wrote: > chromatic via RT wrote: >> With ICU optional these days, is this still necessary? >> > Since Windows doesn't ship with a C compiler and this toolkit is one of > the easiest ways to get hold of one for free, then yes, it's good to > have it documented. (It may be *called* the C++ toolkit, but it's also > what you need to compile C code. Go figure. :-)) I didn't use the Visual C++ Toolkit 2003 but the full Visual Studio .NET 2003, so couldn't help there. But I'm using the new Visual C++ 2005 Express edition to build Parrot. Seems like the old Visual C++ Toolkit 2003 is discontinued. http://msdn2.microsoft.com/en-us/visualc/aa336490.aspx -snip- The Visual C++ Toolkit 2003 has been replaced by Visual C++ 2005 Express Edition. Visual C++ 2005 Express Edition [1] provides a complete integrated development and debugging environment making it the easiest way to create powerful applications using the C/C++ language. Visual C++ 2005 Express Edition also contains an enhanced version of the C/C++ optimizing compiler for the fastest executables. Best of all, the Visual C++ 2005 Express Edition is completely free! [1] http://msdn.microsoft.com/vstudio/express/visualc/default.aspx -snip-
Parrot Bug Summary
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.
RAII in Perl6/Parrot
Dear all I hope I am sending this to the correct place. I regularly use the RAII idiom in Perl 5 and C++ to automatically clean up resources during object destruction. I recently read a mail thread "Is RAII possible in Python?" at http://www.thescripts.com/forum/thread25072.html and "Perl vs Python - GC and Reference Counting" at http://discuss.joelonsoftware.com/default.asp?joel.3.323675.32. The above threads suggests that Python cannot do RAII since its garbage collection does not offer deterministic finalization. I understand that Parrot will not use reference counting for garbage collection and so may suffer from the same problem. Are my fears warranted? Kind regards Blair
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
On Dec 18, 2006, at 1:57 AM, Paul Cochrane wrote: Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: So this means we need to put the emacs and vim settings at the end of the file. No, it means that if you want to use the verbose form of Emacs file variables, then it has to be at the end of the file. Vim sets a similar restriction in that its settings should be in the first or last 5 lines. The problem that I'm trying to solve here is: how do we add the settings information to perl language files such that it doesn't cause problems with __END__ and __DATA__ blocks, is testable by perlcritic, emacs *and* vim pick up their settings values, and it doesn't interfere with the visual structure of the file. I've hit a bit of a brick wall in trying to satisfy all these conditions; any ideas as to how we can achieve this? Not really... The only elegany approach is: # -*- parrot -*- and insist that parrot-mode.el be installed. That may annoy some people, but I don't see another way without crufting up the top of the file or requiring that you de-cruft everywhere. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
[perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003
On Sun Dec 17 19:29:46 2006, [EMAIL PROTECTED] wrote: > With ICU optional these days, is this still necessary? I have a Visual C++ Toolkit 2003 lying around (I think), so, if I do, I'll give this a try along with my Borland work.
[perl #40950] [PATCH] Compiling Parrot with the new Borland C++
> On Mon Nov 20 06:24:00 2006, stmpeters wrote: > > It took some tweaking to get some of the warnings shut off, but the > > attached patch actually gets the files to compile, although it doesn't > > actually build a parrot to test with. Expect a few more patches over > the > > next week to finish this off. > > > > Steve Peters > > [EMAIL PROTECTED] > > This patch still needs to be applied to continue work on compiling parrot with Borland C++.
Re: [perl #40816] open opcode creates file if it doesn't exist
On 12/16/06, [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]> wrote: On Sat Nov 11 11:53:27 2006, [EMAIL PROTECTED] wrote: > Not sure if this is a bug or not, but I noticed that the open opcode > creates its argument if the desired file doesn't exist. > There are two variants of the open opcode: this one, and one where you can specify a mode. The default open mode at the moment is "+<" - that is, open for read and create it if it doesn't exist. You can specify another operand to open specifying the open mode "<" instead, which will just open the file and not create it. So, I think this is not a bug - yes, we could argue all day about what the default open mode should be, but there's a perfectly good way to be explicit about you want that's only a few characters to type. :-) pardon my ignorance, because i haven't checked the documentation, but is the behavior in the last paragraph documented? arguably, it is a bug in the C documentation unless that opcode it is described as defaulting to '+<'. ~jerry
Re: RAII in Perl6/Parrot
On Mon, Dec 18, 2006 at 12:02:35PM +, Blair Sutton wrote: : Dear all : I hope I am sending this to the correct place. : I regularly use the RAII idiom in Perl 5 and C++ to automatically clean : up resources during object destruction. : I recently read a mail thread "Is RAII possible in Python?" at : http://www.thescripts.com/forum/thread25072.html and "Perl vs Python - : GC and Reference Counting" at : http://discuss.joelonsoftware.com/default.asp?joel.3.323675.32. : The above threads suggests that Python cannot do RAII since its garbage : collection does not offer deterministic finalization. I understand that : Parrot will not use reference counting for garbage collection and so may : suffer from the same problem. Are my fears warranted? Short answer: absolutely. Long answer: emphatically not. I believe you have a bit of an XY problem here. You're wanting transactional security and timely destruction but have predisposed yourself not to accept them unless they happen to look like deterministic reference counting. Perl 6 offers the former without offering you the latter, because Perl 6 must run on a variety of platforms that may or may not support deterministic reference counting semantics easily. Perl 6 is a language, not an implementation. As such, it officially Doesn't Care what Parrot does about GC under the hood. But the problem goes much deeper than that, and has to do with the necessary virtualization of time as we scale things up and distribute responsibility for them. In this day of multiple, distributed processing units of uncertain proximity, it's going to get harder and harder to say what a deterministic reference is. What if a bit your program is running on a different processor and it goes down? You can't know that till the next GC run at the appropriate granularity fails to sync with the down processor. A GC solution can finesse around such problems, up to a point, whereas a deterministic solution really has only one approach. In the larger and wider scale of things, you can't know whether a reference is valid till you try it--see the Web for an example. The web would never have take off with perfect accountability. (That's why Xanadu didn't work, basically.) All of computing is getting more like that. For instance, people are now finding that deterministic locking solutions don't scale up either. STM (software transactional memory) seems to be a way to get around that, and that's partly because a transactional memory manager can virtualize time much like a garbage collector can defer decisions it isn't sure of. Two transactions can be in conflict in real time, which would prevent at least one of them from happening under deterministic locking. But an STM manager can decide the fate of the transactions based *only* on the data dependencies, ignoring the bogus realtime dependency, and maybe decide to allow both transactions if a consistent state is maintained. In short, programs written in languages that require unnecessary determinism will not escape the von Neumann bottleneck as easily as programs written in languages that do not. Determinism is fine when you need it, and a good language will provide adequate ways to express that when you do need it. (Perl 6 provides several ways that are much handier than try/finally, and just about as handy as RAII.) But baking such handicaps into every object merely guarantees it will not scale well in the real world. The real world itself avoids computing deterministically most of the time! And if anything could manage determinism, it'd probably be the real world! Languages that require determinism will scale only up only when the entire world is running one huge completely entangled quantum computer. Determinism is not interoperable. Anyway, that's the trend I see. And that's why Perl 6 has lots of ways to promise you Don't Care about various dependencies, but Do Care about others. That's why Perl 6 has pipes and lazy lists, junctions and hyperoperators, contend and defer. These are for building scalable solutions to run on cell processors and GPUs and clusters of servers and corporate intranets. And maybe even trigger a Singularity or two. :-) Larry
Re: RAII in Perl6/Parrot
Larry Wall wrote: ... (Perl 6 provides several ways that are much handier than try/finally, and just about as handy as RAII.) But baking such handicaps into every object merely guarantees it will not scale well in the real world. Thanks for the information. I must admit I rely heavily on the deterministic nature of C++ for writing "real-time" feed collectors into stock exchanges. RAII plays a big part in managing locks between threads and tearing down sockets cleanly (as well as many other things). I agree entirely that not all objects need this capability but some certainly do. That is, the capability to execute code once every reference of an object has been removed. Could you point to, or give an example of the Perl 6 way for doing something similar? Best regards, Blair
Re: RAII in Perl6/Parrot
On 12/18/06, Blair Sutton <[EMAIL PROTECTED]> wrote:
I agree entirely that not all objects need this capability but some
certainly do. That is, the capability to execute code once every
reference of an object has been removed. Could you point to, or give an
example of the Perl 6 way for doing something similar?
Well, there is one general method I can think of. You need to know
more about your program in order to implement it; i.e. if an object
which contains an array of objects, one element of which has a socket
that needs closing, it's going to be tough to get it right. That's
one of the negative sides of the trade-off Larry mentioned (but he
made an excellent case for the positive sides, and the reason why
we're leaning the nondeterministic way).
The main tool at your disposal is the LEAVE closure trait. i.e.:
sub foo {
do_stuff();
do_more_stuff();
LEAVE { say "leaving foo" }
}
This code will say "leaving foo" whenever its dynamic scope ends,
whether that time is the successful completion of do_more_stuff or
whether do_stuff threw an exception. If I understand the idiom
correctly, this exceptional case was the main reason behind RAII. Do
your cleanup in the LEAVE block.
If you have a specific scenario that comes up a lot, other than "the
exact semantics of RAII", do describe it and that will give us
something to think about. Either there's already some clever trick
you can do to handle it, there's a little extra language feature we'll
have to add, or you'll have to put up with doing a little more manual
bookkeeping.
Luke
take: bug or feature?
A few days ago, Larry posted this on Perlmonks
(http://perlmonks.org/?node_id=590147):
sub group ([EMAIL PROTECTED] is copy) {
gather {
while @array {
take [ # line 112
gather {
my $h = shift @array;
take $h;
while @array and $h eq @array[0] {
take shift @array;
}
}
];
}
}
}
I added that to my "99 Problems" code because it worked just fine (I
would swear it did. I'd be embarrassed if I am misremembering). Now
I've upgraded Pugs and it fails with:
Unexpected "["
expecting bare or pointy block construct, ":", identifier, operator
or "}"
at 99.pugs line 112, column 18
Line 112 is the first take. Did something break? If so, I'll add a
test. Otherwise, what's wrong with this code? Also, I've been
searching the docs for the exact syntax of 'gather/take' and I can't
find it. Pointers would be great.
Pugs Version: 6.2.13 (r14911)
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: [perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003
Ron Blaschke wrote: Seems like the old Visual C++ Toolkit 2003 is discontinued. http://msdn2.microsoft.com/en-us/visualc/aa336490.aspx Aha. If you would have a moment to write these latest changes into readme.win32.pod and send in a patch, that'd be awesome; otherwise I'll get to it when I can. Thanks, Jonathan
take: bug or feature?
A few days ago, Larry posted this on Perlmonks
(http://perlmonks.org/?node_id=590147):
sub group ([EMAIL PROTECTED] is copy) {
gather {
while @array {
take [ # line 112
gather {
my $h = shift @array;
take $h;
while @array and $h eq @array[0] {
take shift @array;
}
}
];
}
}
}
I added that to my "99 Problems" code because it worked just fine (I
would swear it did. I'd be embarrassed if I am misremembering). Now
I've upgraded Pugs and it fails with:
Unexpected "["
expecting bare or pointy block construct, ":", identifier, operator
or "}"
at 99.pugs line 112, column 18
Line 112 is the first take. Did something break? If so, I'll add a
test. Otherwise, what's wrong with this code? Also, I've been
searching the docs for the exact syntax of 'gather/take' and I can't
find it. Pointers would be great.
Pugs Version: 6.2.13 (r14911)
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: take: bug or feature?
Ovid <[EMAIL PROTECTED]> writes: > Did something break? If so, I'll add a test. Otherwise, what's > wrong with this code? I noticed this as well, and believe it's a bug -- pugs accepts the code if you remove all the newlines. Then again, I'm not sure this is the desired behavior: pugs> group(1..10) ((1,), (2,), (3,), (4,), (5,), (6,), (7,), (8,), (9,), (10,)) /s
Re: take: bug or feature?
--- Sean O'Rourke <[EMAIL PROTECTED]> wrote: > I noticed this as well, and believe it's a bug -- pugs accepts > the code if you remove all the newlines. Then again, I'm not > sure this is the desired behavior: > > pugs> group(1..10) > ((1,), (2,), (3,), (4,), (5,), (6,), (7,), (8,), (9,), (10,)) > > /s It looks like there's a bug in gather/take and luqui is working on it now (from #perl6). Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
[svn:perl6-synopsis] r13493 - doc/trunk/design/syn
Author: larry
Date: Mon Dec 18 17:50:54 2006
New Revision: 13493
Modified:
doc/trunk/design/syn/S06.pod
Log:
Nitty infrastructural routines probably shouldn't rely on multiple dispatch or
optional args, so we now have .call, .callc and .callv forms.
Also added .goto variants for tail call enforcement. This provides "goto &foo"
as well to make P5 programmers feel like they not everything has changed.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podMon Dec 18 17:50:54 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 5 Dec 2006
+ Last Modified: 18 Dec 2006
Number: 6
- Version: 63
+ Version: 64
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -703,17 +703,23 @@
parameter marked with a C<|>.
sub bar ($a,$b,$c,:$mice) { say $mice }
-sub foo (|$args) { say |$args.perl; &bar.callargs(|$args); }
+sub foo (|$args) { say |$args.perl; &bar.callc($args); }
-The C<.callargs> method of C objects accepts an argument list,
-(which can be specified as a Capture object as above), and calls it
-without introducing an official C frame.
+The C<.callc> method of C objects takes a C argument.
+The C<.callv> method accepts an ordinary variadic argument list, so the
+following is equivalent:
+
+sub foo (|$args) { say |$args.perl; &bar.callv(|$args); }
+
+In either case, the wrapped routine is called
+without introducing an official C frame, and produces:
foo 1,2,3,:mice; # says "\(1,2,3,:mice)" then "blind"
-It is allowed to specify additional parameters. The Capture binding merely
-takes a snapshot of what's left of the Capture at that point and then
-continues binding as if the Capture parameter weren't there:
+It is allowed to specify additional parameters within the signature.
+The C binding merely takes a snapshot of what's left of
+the C at that point and then continues binding as if the
+C parameter weren't there:
sub compare (|$args, Num $x, Num $y --> Bool) { ... }
@@ -2025,7 +2031,7 @@
smart-matched against the dynamic scope objects from inner to outer.
The first that matches is the scope that is left.
-The remainder of the arguments are taken to be a Capture holding the
+The remainder of the arguments are taken to be a C holding the
return values.
leave; # return from innermost block of any kind
@@ -2113,27 +2119,28 @@
=head2 Wrapping
Every C object has a C<.wrap> method. This method expects a single
-C argument. Within the code, the special C and C
functions will invoke
+C argument. Within the code, the special C and C functions
will invoke
the original routine, but do not introduce an official C frame:
sub thermo ($t) {...} # set temperature in Celsius, returns old value
# Add a wrapper to convert from Fahrenheit...
-$handle = &thermo.wrap( { callargs( ($^t-32)/1.8 ) } );
+$handle = &thermo.wrap( { callv( ($^t-32)/1.8 ) } );
-The C function lets you pass your own arguments to the wrapped
-function. The C function takes no arguments and implicitly passes
-the original argument list through unchanged.
+The C function lets you pass your own arguments to the wrapped
+function. The C function takes an optional C argument,
+with no arguments it implicitly passes the original argument list
+through unchanged.
The call to C<.wrap> replaces the original C with the C
-argument, and arranges that the call to C or C invokes the
previous
+argument, and arranges that the call to C or C invokes the
previous
version of the routine. In other words, the call to C<.wrap> has more
or less the same effect as:
&old_thermo := &thermo;
&thermo := sub ($t) { old_thermo( ($t-32)/1.8 ) }
-Except that C<&thermo> is mutated in-place, so C<&thermo.WHICH> stays the same
+except that C<&thermo> is mutated in-place, so C<&thermo.WHICH> stays the same
after the C<.wrap>.
The call to C<.wrap> returns a unique handle that can later be passed to
@@ -2148,36 +2155,53 @@
# Add a wrapper to convert from Kelvin
# wrapper self-unwraps at end of current scope
-temp &thermo.wrap( { callargs($^t + 273.16) } );
+temp &thermo.wrap( { callv($^t + 273.16) } );
-The entire argument list may be captured by binding to a Capture parameter.
-It can then be passed to C using that name:
+The entire argument list may be captured by binding to a C parameter.
+It can then be passed to C using that name:
# Double the return value for &thermo
-&thermo.wrap( -> |$args { callargs(|$args) * 2 } );
+&thermo.wrap( -> |$args { call($args) * 2 } );
In this case only the return value is changed.
The wrapper is not required to call the original routine; it can call another
-C object by passing the C to its C method:
+C object by passing the C to one
[perl #41104] [PATCH] Building on MinGW is disrupted by the presense of /bin/sh.exe on the PATH, docs explain required environment change
On Sat Dec 16 14:35:24 2006, [EMAIL PROTECTED] wrote: > Affected files: > > /README.win32.pod > > ... > Applied in r16187, thanks! Jonathan
