Re: r31789 -[S32] DateTime immutable, leap seconds validation
On Fri, 2010-07-23 at 15:26 +0200, Raphael Descamps wrote: Have a look at nqp-rx + kakapo + plumage + proto/PLS for some examples where you can help without any C or Perl 5 knowledge: http://gitorious.org/parrot-plumage Best. Suggestion. Ever. :-) -'f
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, 2010-04-12 at 11:23 -0700, Larry Wall wrote: The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no worse than the difference between Damian and Damien, at least in Levenshtein distance. Ah yes, I forgot about this feature. Consider my argument for choosing only one separator throughout the standard setting Way Less Adamant -- though I still think it's a good idea. -'f
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, 2010-04-10 at 17:20 -0700, yary wrote: Adjectives and nouns aren't English-only. So Damian's proposal is multi-culti. One could argue that Perl's identifiers, keywords, etc are based on English so that it is more difficult for a non-English speaker to discern why underscore is used in some places and hyphens in other. The solution to that would be rote memorization of method names, including _ and - in the spelling. Not ideal, but most likely what many English speaking programmers would do too. And would cuss over. And there's the rub for me. One of the goals of Perl 6 is to reduce the amount of rote memorization of special cases that Perl 5 required. Any mixed use of _ and - in the standard setting defies that goal. (FWIW, I don't really care which is used -- I see arguments for both -- but I do firmly believe the standard setting should only use one or the other. Damian's Temporal example in which only one method used a different separator made the rules-versus-exceptions part of my brain scream for mercy.) -'f
Re: A common and useful thing that doesn't appear to be easy in Perl 6
First: what Damian said. Second: Whatever syntax people come up with has to make it easy and type-safe to name particular combinations of those bits. In other words, you should be able to make a bitset with Unix-style permissions: OTHER_EXECUTE OTHER_WRITE OTHER_READ GROUP_EXECUTE GROUP_WRITE GROUP_READ ... But still be able to make bitmasks (ignore the syntax here): OTHER_MASK = OTHER_READ +| OTHER_WRITE +| OTHER_EXECUTE; GROUP_MASK = GROUP_READ +| GROUP_WRITE +| GROUP_EXECUTE; ... These bitmasks should be properly typed with respect to the original bitset; which is to say, this should work: my Permissions $other_perms = $file_perms + OTHER_MASK; -'f
Re: r30205 - docs/Perl6/Spec
On Fri, 2010-03-26 at 08:38 +0100, pugs-comm...@feather.perl6.nl wrote:
.doit: { $^a = $^b } # okay
.doit(): { $^a = $^b }# okay
.doit(1,2,3): { $^a = $^b } # okay
+.doit(1,2,3): { $^a = $^b } # okay
+.doit:{ $^a = $^b } # okay
+.doit():{ $^a = $^b }# okay
+.doit(1,2,3):{ $^a = $^b } # okay
+.doit(1,2,3):{ $^a = $^b } # okay
My eyes must be playing tricks on me -- I can't see the difference
between the last two lines in each of the above blocks. What am I
missing?
-'f
Re: p6 Q: How do I metaprogram this?
On Tue, 2009-12-08 at 18:58 -0500, Austin Hastings wrote: I know that I could 'metaprogram' this stuff by using string manipulation on the various method names, and then calling a (self-built) call_method($obj, $method_name, ...args...) function. You don't need to write this by hand. NQP-rx supports the method call by name Perl 6 syntax: $obj.$method_name(...args...); which makes this kind of thing much easier. I use it in Plumage in a number of places. But I'm curious if there's some P6 feature I've forgotten about (which I've forgotten most of them, excepting the rev number) that would let me do this without having to go too far away from the metal. The above syntax is actually pretty close to the metal because it translates directly to standard PIR ops. -'f
Re: p6 Q: How do I metaprogram this?
On Wed, 2009-12-09 at 00:16 -0500, Austin Hastings wrote:
Geoffrey Broadwell wrote:
On Tue, 2009-12-08 at 18:58 -0500, Austin Hastings wrote:
I know that I could 'metaprogram' this stuff by using string
manipulation on the various method names, and then calling a
(self-built) call_method($obj, $method_name, ...args...) function.
You don't need to write this by hand. NQP-rx supports the method call
by name Perl 6 syntax:
$obj.$method_name(...args...);
The problem I have with the above is that it seems to require a second
layer of call. Something like:
sub beforeall_methods() { return
fetch_methods_by_category('beforeall'); }
sub fetch_methods_by_category($cat) {...}
Essentially, it's one level of function call to translate code into data
(method name into string) and then the template function is the second
layer of call.
I'm not entirely sure what you mean here by translate code into data
(method name into string). The method name is already a string, which
is why I offered the call by name syntax above. But of course if you
have a code object for the method itself, you could do this in Perl 6:
$obj.$method(...args...);
Sadly this does not currently work in NQP-rx, though IIUC there's no
reason it couldn't (and in fact I've already requested this feature
because it would be useful for some function table stuff I do).
Full Perl 6 offers a number of features that would be useful for calling
a whole pile of dynamically-chosen methods on an object, but few have
been implemented in NQP-rx. (I would assume because there hasn't been a
lot of demand for it yet.)
I'll let the Perl 6 gurus follow up with actual syntax examples for some
of these nifty features. ;-)
-'f
Re: Parrot and Perl 6 Summary
On Mon, 2009-11-23 at 01:15 +0100, Lithos wrote: Today I posted my first attempt at summarizing Perl 6 and Parrot things at http://lith-ology.blogspot.com/ Any comments and corrections welcome! This is *very* valuable to us. Please keep it up! -'f
Re: r29129 - docs/Perl6/Spec
I kinda like 'blorst'. The word makes me think of a warm stew on a cold winter night. And I agree with the searchability advantage of 'blorst' as well. /bikeshed -'f
Re: S26 - The Next Generation
On Thu, 2009-09-17 at 11:12 -0700, yary wrote: On Thu, Sep 17, 2009 at 1:05 AM, Damian Conway dam...@conway.org wrote: Aaron Sherman asked: ... I'd very much like to establish that at default optimization levels for execution, this information is not guaranteed to be maintained past the creation of the AST. Unfortunately, it is. Perl 6 defines that Perl 6 programs can always access their own Pod at runtime (via $=POD). You probably can't even optimize the information away in the absence of any compile-time reference to $=POD, since there are plenty of symbolic ways to refer to $=POD at run-time. Can some concept/implementation of $=POD lazyness only incur the memory and performance hit on access? Alternately it should be possible to declare that the Pod data be dropped before mainline runtime begins. For example, it ought to be possible for a compiling implementation such as Rakudo to declare that the Pod data not be frozen into the PBC file. (If this is already specced, I apologize -- I haven't searched for it.) -'f
Re: How can i contribute for perl 6 ?
On Wed, 2009-09-16 at 19:49 +1000, Timothy S. Nelson wrote: +1. I have a set of 7 bookmarks that load in tabs that I call my Perl 6 bookmarks. I load this group of tabs into a separate web browser window when I'm doing Perl 6 stuff. That link is one of the 7 links. Perhaps your other Perl 6 bookmarks ought to appear on rakudo.org or perl6.org as well. :-) -'f
Re: patch for t/spec/s06-multi/type-based.t
On Fri, 2009-08-21 at 14:24 +1100, Илья wrote:
-multi foo (@bar) { Array ~ join(', ', @bar) }
-multi foo (%bar) { Hash ~ join(', ', %bar.keys.sort) }
+multi foo (@bar) { Positioanl ~ join(', ', @bar) }
+multi foo (%bar) { Associative ~ join(', ', %bar.keys.sort) }
Typo in third line there (Positioanl ).
-'f
Re: r27605 - docs/Perl6/Spec/S32-setting-library
On Sat, 2009-07-18 at 21:22 -0400, James Cloos wrote: lwall + enum TrigBase is export Radians Degrees Gradians Circles; Is Circles of much value? I can see Semicircles, since that would make the range (-1,1] or [-1,1). But a range of [0,1) or (0,1] seems *much* less useful. Or am I missing an obvious use case? With Circles, simple int/frac always gets you a count of full rotations and an angle always between 0 and one full rotation. Seems useful to me. Semicircles sounds useful as well, for the reason you state above. -'f
Re: Amazing Perl 6
Tim Nelson: There's some standard that says this is how to generate unicode: 1.Hold down Ctrl+Shift 2.Press U 3.Type the hexadecimal for the unicode character 4.Release Ctrl+Shift This works under GNOME, which also has a variant that is a little friendlier to the fingers (and probably also works better with various accessibility changes to the shift keys): 1. Press Ctrl+Shift+U 2. Release; see 'underlined u' feedback 3. Type the hex for the Unicode character (leading 0's optional); hex digits continue showing underline feedback 4. Press Enter; underlined u and digits are replaced with final glyph -'f
Re: Comparing inexact values (was Re: Temporal changes)
On Tue, 2009-02-24 at 12:31 -0800, Jon Lang wrote: $y ± 5 # same as ($y - 5) | ($y + 5) $y within 5 # same as ($y - 5) .. ($y + 5) Oh, that's just beautiful. -'f
Re: Temporal revisited
On Fri, 2009-02-20 at 15:33 -0600, Dave Rolsky wrote: Of course, if you're dealing with TAI only, you're safe for constants up to ONE_WEEK. So we just define ONE_MONTH as 4 * ONE_WEEK, right? *duck* -'f
Re: Spec reorganisation
On Thu, 2009-02-19 at 22:57 +1100, Timothy S. Nelson wrote: On Thu, 19 Feb 2009, Carl Mäsak wrote: A tree is a graph without cycles. That's insufficient. In fact, there are a number of ways that the general concept of an acyclic graph must be constrained before you get something you can call a 'tree'. The concept of a root is very common in computer representations, but in no way necessary for a general tree. In fact, in phylogenetics, it's business as usual to handle unrooted trees. This makes the $root attribute meaningless in at least some cases. Interesting. I'm happy to assume that $root is allowed to be Undefined, I think. But let me ask a question; were you to represent an unrooted tree in a computer, how would you do it so that, if you had to look around the tree, you could do it? You'd need some node that was an entry-point into the tree. That's the purpose I'm trying to get at here. A tree with nodes but without a root is not a tree -- it's a collection of trees, more commonly called a grove or forest. -'f
Re: IO, Trees, and Time/Date
On Tue, 2009-02-17 at 22:38 +1100, Timothy S. Nelson wrote: My third thought is that it would be very useful also to have date/time objects that integrate well with eg. ctime, mtime, and the like; I'd start with Time::Piece as a model. http://search.cpan.org/dist/Time-Piece/Piece.pm Conceptually, I agree. But there are places that Time::Piece assumes time is a sane thing, and it just isn't. Date::Time has a less DWIM interface, but is much more correct in the face of general human nuttiness on this topic (especially with regard to durations and timezones). I'd prefer to generally follow Date::Time, with DWIM features cherry picked from Time::Piece as long as they don't result in wrong behavior. (As an aside: It's the 21st century -- the default stringification of time objects should be easily parseable and sortable, not the insanity produced by Perl 5's 'scalar localtime'. ISO or SQL timestamp format please.) -'f
Re: r25122 - docs/Perl6/Spec
On Fri, 2009-01-30 at 08:12 +0100, pugs-comm...@feather.perl6.nl wrote: @@ -103,7 +106,7 @@ =item * POD sections may be used reliably as multiline comments in Perl 6. -Unlike in Perl 5, POD syntax now requires that C=begin comment +Unlike in Perl 5, POD syntax now lets you use C=begin comment and C=end comment delimit a POD block correctly without the need for C=cut. (In fact, C=cut is now gone.) The format name does not have to be Ccomment -- any unrecognized format name will do I believe that with this change in wording the next line needs to use 'to delimit' rather than just 'delimit'. -'f
Re: RFD: Built-in testing
On Wed, 2009-01-21 at 14:23 +, Peter Scott wrote:
On Wed, 21 Jan 2009 13:35:50 +0100, Carl Mäsak wrote:
I'm trying to explain to myself why I don't like this idea at all. I'm
only partially successful. Other people seem to have no problem with it,
so I might just be wrong, or part of a very small, ignorable minority.
:)
I find myself echoing you. I don't have the language design skills others
are displaying here. I can only evaluate this from an educator's point of
view and say that the P5 syntax of
is $x, 42, 'Got The Answer';
is just about the conceivable pinnacle of elegance for at least that form
of question. (Compare, e.g., the logorrhoea of Java tests.) I do not see
how I could tell a student with a straight face that the P6 proposal is an
improvement, at which point the conversation would devolve into a
defensive argument I do not want to have.
I get that 'is' is already taken and we do not want the grammar to engage
in Clintonesque parsing when it encounters the token. Okay. But how do I
justify the new syntax to a student? What are they getting that makes up
for what looks like a fall in readability?
I don't quite understand the problem with using the same syntax as in
Perl 5, just uppercasing the verbs so they won't conflict with everyday
syntactic features:
OK($bool, 'Widget claimed success');
IS($x, 42, 'Widget produced the right answer');
(This is ignoring issues of placement of parens or curlies to make the
Perl 6 syntax attractive and consistent with other constructs -- I'm
just talking about using verb rather than adverb syntax, with our
already properly Huffmanized verb names intact.)
I do like the idea of having TEST {} blocks that go inactive when not in
testing mode (however that is defined). But other than that, I don't
understand the value of the other syntactic changes suggested, the
adverb syntax in particular. Maybe I'm missing something obvious
-'f
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
On Thu, 2009-01-15 at 16:03 -0800, Darren Duncan wrote: Patrick R. Michaud wrote (on p6c): On Thu, Jan 15, 2009 at 08:53:33AM +0100, Moritz Lenz wrote: Another thing to keep in mind is that once we start to have a Perl 6 prelude, we might decide to be nice neighbors and share it with other implementations, as far as that's practical. My guess is that there will be a shared prelude that is maintained in a central repository like the spectests, but that individual implementations are likely to want or need customized versions of the prelude for performance or implementation reasons. In this sense the shared prelude acts as a reference standard that implementations can use directly or optimize as appropriate. What I recommend, and forgive me if things already work this way, is to expand the Prelude so that it defines every Perl 6 core type and operator using pure Perl 6, complete enough such that there are as few as possible actual primitives not defined in terms of other things. This Prelude would then be shared unchanged between all the Perl 6 implementations. Then, each implementation would also define its own PreludeOverride file (name can be different) in which it lists a subset of the type and operator definitions in the Prelude that the particular implementation has its own implementation-specific version of, and the latter then takes precedence over the former in terms of being compiled and executed by the implementation. The problem with this method is that there are usually *several* ways to implement each feature in terms of some number of other features. The creators of the shared prelude are then stuck with the problem of deciding which of these to use. If their choices do not match the way a particular implementation is designed, it will then be necessary for the implementation to replace large swaths of the Prelude to get decent performance. For example, implementations in pure C, Common Lisp, and PIR will probably have VASTLY different concepts of available and optimized primitive operations. A prelude written with any one of them in mind may well be pessimal for one of the others. That's not to say it's not a useful idea for helping to jumpstart new implementations -- I just somewhat doubt that a mature implementation will be able to use more than a fraction of a common prelude. -'f P.S. I did this sort of thing once -- a Forth prelude that attempted to minimize the primitive set, and it *was* very nice from an abstract perspective. Unfortunately, it also made some operations take millions of cycles that would take no more than one assembly instruction on just about every CPU known to man. It's a REALLY easy trap to fall into.
Re: [PATCH] Add .trim method
On Mon, 2009-01-12 at 07:01 -0800, Ovid wrote: - Original Message I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. When I saw your proposed syntax above, instead of reading don't trim leading/trailing whitespace, I read change the definition of 'whitespace' to 'codepoint 0' for leading/trailing. That of course raises the question of how one *would* properly override trim's concept of whitespace -'f
Re: r24809 - docs/Perl6/Spec
On Thu, 2009-01-08 at 23:06 +0100, pugs-comm...@feather.perl6.nl wrote:
+=item -0 *octal/hex*
+
+Sets input record separator. Missing due to lack of specification in
+LSynopsis 16|S16-io. There is a comment about this in the L/Notes
+section at the end of this document.
I use this option quite a bit -- but only in the bare '-0' syntax,
meaning null-terminated lines, necessary for robust command line pipes.
I only rarely use the full form. In fact, really rarely.
+=item -i *extension*
+
+Modify files in-place. Haven't thought about it enough to add yet, but
+I'm certain it has a strong following. {{TODO review decision here}}
Oh yeah. I use this a LOT.
+=item -l
+
+Enable automatic line-ending processing. This is the default behavior.
And there was much rejoicing
-'f
Re: Converting a Perl 5 pseudo-continuation to Perl 6
On Fri, 2009-01-02 at 14:19 +0200, Leon Timmermans wrote:
When going OO, I'd say an augment()/inner() approach would be
cleanest. See
http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook/Basics/Recipe6.pod
for an example. I don't know how to express that in Perl 6 though.
There's no description on that page, just sample code, but it looks like
augment performs a similar function to the .wrap method on Routines in
Perl 6. That's an interesting variation of my approach #4, I think:
4. In order to keep the sub separate, but still not split the
pid_file_handler call, I came up with a variation of #3 in which
pid_file_handler takes a callback parameter:
sub init_server {
# ...
pid_file_handler($options{pid_file}, become_daemon);
# ...
}
sub pid_file_handler($pid_file, callback) {
# ... top half ...
callback();
# ... bottom half ...
}
I like your idea a little better than the callback method, because I can
see the logic behind saying I want to make an enhanced version of
become_daemon that is *also* able to handle PID files. However, it ties
the two together -- the PID file handling cannot be used in any context
other than becoming a daemon, and in particular it's not obvious how you
would unit test it.
-'f
Re: r24737 - docs/Perl6/Spec
Thank you for the quick turnaround! On Fri, 2009-01-02 at 10:55 -0800, jerry gay wrote: On Fri, Jan 2, 2009 at 09:27, Geoffrey Broadwell ge...@broadwell.org wrote: It's also not obvious what a boolean named $doc does -- which probably means either that it's not supposed to be a boolean, or it needs a somewhat more descriptive long name (or both). I think this is the only remaining item you had not yet responded to -- er, unless I missed it. -'f
Re: Converting a Perl 5 pseudo-continuation to Perl 6
On Fri, 2009-01-02 at 22:56 +0100, Aristotle Pagaltzis wrote:
When I asked this question on #perl6, pmurias suggested using
gather/take syntax, but that didn't feel right to me either --
it's contrived in a similar way to using a one-off closure.
Contrived how?
Meaning, the gather/take syntax doesn't make much sense, because we're
not gathering anything; the PID file handler has nothing to return.
We'd only be using it for the side effect of being able to pause the
callee's execution and resume it later.
When you have an explicit entity representing the continuation,
all of these questions resolve themselves in at once: all calls
to the original routine create a new continuation, and all calls
via the state object are resumptions. There is no ambiguity or
subtlety to think about.
I like this argument. I'm not sure it's applicable in every case, but
it certainly applies to the class of situations containing my problem.
So from the perspective of the caller, I consider the “one-off”
closure ideal: the first call yields an object that can be used
to resume the call.
However, I agree that having to use an extra block inside the
routine and return it explicity is suboptimal. It would be nice
if there was a `yield` keyword that not only threw a resumable
exception, but also closed over the exception object in a
function that, when called, resumes the original function.
That way, you get this combination:
sub pid_file_handler ( $filename ) {
# ... top half ...
yield;
# ... bottom half ...
}
sub init_server {
# ...
my $write_pid = pid_file_handler( $optionspid_file );
become_daemon();
$write_pid();
# ...
}
That's pretty nice. Perhaps we can make it even cleaner with a few
small tweaks to init_server():
sub init_server(:$pid_file, ...) {
# ...
my write_pid := pid_file_handler($pid_file);
become_daemon();
write_pid();
# ...
}
So far, this variant is winning for me, I think. It's slightly more
verbose on the caller's side than the yield variant I had proposed, but
it's also more explicit, and allows (as you said) a clean syntactic
separation between starting the PID file handler and continuing it.
It does bring up a question, though. What if pid_file_handler() needed
to be broken into three or more pieces, thus containing multiple yield
statements? Does only the first one return a continuation object, which
can be called repeatedly to continue after each yield like this?
sub init_server(:$pid_file, ...) {
# ...
my more_pid_stuff := pid_file_handler($pid_file);
become_daemon();
more_pid_stuff();
do_something();
more_pid_stuff();
do_something_else();
more_pid_stuff();
# ...
}
Or does each yield produce a fresh new continuation object like this?
sub init_server(:$pid_file, ...) {
# ...
my write_pid := pid_file_handler($pid_file);
become_daemon();
my fold_pid:= write_pid();
do_something();
my spindle_pid := fold_pid();
do_something_else();
spindle_pid();
# ...
}
(Note that I assume you can simply ignore the returned object if you
don't plan to continue the operation any more, without raising a
warning.)
Certainly the first version has less visual clutter, so I tend to lean
that way by default. But the second design would allow one to create a
tree of partial executions, by calling any earlier continuation object
again. That's a very powerful concept that I don't want to give up on.
Supporting both feels like it might be an adverb on the invocation
(possibly with a frosty sugar coating available). It would be nice to
support invoking a continuation in ratcheting and forgetful modes.
Thoughts?
-'f
Re: r24737 - docs/Perl6/Spec
On Fri, 2009-01-02 at 12:27 -0800, jerry gay wrote: oh, yes, whoops! i responded to someone else in #pugs earlier, and forgot to address the item here. Cperl6 --doc replaces p5's Cperldoc (that's the latest idea from damian, although it seems not to be published yet). Ah, I get it! What about perldoc's special modes? Will these go in ++DOC ... ++/DOC sections? the most likely short names, C -d -o -c are all taken by either p5 or p6 command-line. i don't want to use C-d, because that has to do with the debugger in p5, so makes it harder for p6 to catch accidental usage. C--doc probably warrants a short name, since it will be called frequently--i hope, reducing irc traffic :) but i haven't decided on a good name yet. i'm open to suggestions. Don't have any yet. Will let my subconcious ruminate on it. -'f
Converting a Perl 5 pseudo-continuation to Perl 6
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a continuation. The syntax is a
bit ugly, though. Is there a cleaner way to this in Perl 6?
##
sub init_server {
my %options = @_;
# ...
# Do top (pre-daemonize) portion of PID file handling.
my $handler = pid_file_handler($options{pid_file});
# Detach from parent session and get to clean state.
become_daemon();
# Do bottom (post-daemonize) portion of PID file handling.
$handler-();
# ...
}
sub pid_file_handler {
# Do top half (pre-daemonize) PID file handling ...
my $filename = shift;
my $basename = lc $BRAND;
my $PID_FILE = $filename || $PID_FILE_DIR/$basename.pid;
my $pid_file = open_pid_file($PID_FILE);
# ... and return a continuation on the bottom half (post-daemonize).
return sub {
$MASTER_PID = $$;
print $pid_file $$;
close $pid_file;
};
}
##
When I asked this question on #perl6, pmurias suggested using
gather/take syntax, but that didn't feel right to me either -- it's
contrived in a similar way to using a one-off closure.
pmichaud offered several possibilities (I've converted some of his
suggestions expressed as prose into code, so the errors there are mine):
1. Take advantage of Perl 6 syntax reduction to turn 'return sub {...}'
into 'return {...}' (or even just fall of the end with '{...}', I
suppose). This is visually slightly better, but still leaves the
bottom half inside a block that merely exists to satisfy Perl, not
actually representing anything intrinsic about the problem.
2. Throw a resumable exception in the middle:
sub init_server {
# ...
pid_file_handler($options{pid_file});
become_daemon();
pid_file_handler();
# ...
}
sub pid_file_handler {
# ... top half ...
throw ResumableException;
# ... bottom half ...
}
He also suggested a variant syntax with an adverb on return:
sub pid_file_handler {
# ... top half ...
return :resumable;
# ... bottom half ...
}
I suggested a naked yield syntax:
sub pid_file_handler {
# ... top half ...
yield;
# ... bottom half ...
}
These all desugar to the same thing, of course.
3. Make become_daemon a part of pid_file_handler, or vice-versa.
I rejected both of these on the basis of separating different
things into different subs. The two tasks are only tangentially
related, and neither really seems like a subordinate op of the
other.
4. In order to keep the sub separate, but still not split the
pid_file_handler call, I came up with a variation of #3 in which
pid_file_handler takes a callback parameter:
sub init_server {
# ...
pid_file_handler($options{pid_file}, become_daemon);
# ...
}
sub pid_file_handler($pid_file, callback) {
# ... top half ...
callback();
# ... bottom half ...
}
That seems like a silly contortion to hide the problem, and
doesn't represent my intent well -- the pid file handler doesn't
need to send a message, it needs to yield control while waiting
for something else to happen.
5. Make a new PidHandler class and address the problem in OO fashion:
sub init_server {
# ...
my $pid_handler = PidHandler.new(file = $options{pid_file});
$pid_handler.top();
become_daemon();
$pid_handler.bottom();
#...
}
This is certainly workable, but again feels like a contrived
workaround in the same way that gather/take and return {...} do.
Plus, writing a new class and using OO/method call syntax just to
allow a sub to be split seems like pointless busy work. Not
as bad in Perl 6 as in Perl 5, but still.
In the end, I think I like the 'naked yield' idea best of the ones we
have so far. Any comments or other ideas? [1]
-'f
[1] Other than that I've used the word 'contrived' too many times. :-)
Re: Converting a Perl 5 pseudo-continuation to Perl 6
On Fri, 2009-01-02 at 00:30 +0200, Leon Timmermans wrote: I can't help wondering why does pid_file_handler need to be split up in the first place? Why wouldn't it be possible to simply call pid_file_handler after become_daemon? Two answers: 1. If an error occurs that will not allow the PID file to be created (another copy of the daemon is already running, the user doesn't have required root permissions, or what have you), the program should die visibly at the command line, rather than *appearing* to launch but actually just spitting an error into the syslog and disappearing silently. Checking for another running daemon and taking ownership of the pid file should be an atomic operation (or at the very least err on the side of failing noisily if something fishy happens), so I can't just check for an existing pid file before daemonizing, and then create the new pid file after. It's not visible in the code I posted, but the program should also do a number of other sanity checks before it daemonizes, for the very same reasons. For example, it should load all modules it expects to use before becoming a daemon, and complain loudly if it can't. 2. The particular code I used is just a decent example to ask about the general question of a better syntax for interrupting and continuing a sub. So even if I could do what you say, I'd still have the question. :-) -'f
Re: how to write literals of some Perl 6 types?
On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote: Darren (): Bit Blob Set Bag Mapping How does one write anonymous value literals of those types? And I mean directly, not by writing a literal of some other type and using a conversion function to derive the above? Why is the latter method insufficient for your needs? Efficiency reasons, among others. We can quibble over the syntax, but it would be awfully nice if implementations were able to generate the data structure as early as possible -- at compile time (for literals containing only constants) or during runtime as a single build pass rather than build-other-type-then-convert (for literals containing runtime-evaluated expressions). If there isn't an easy way for the implementation to make this optimization, then we're stuck with some of the basic types taking twice the time and space to create that other similar types do, for no good reason. Mind you, some implementations may get lucky by using a common all-powerful collection implementation underneath, and turning the conversion into a simple type relabel (constant cost in time and space), but that doesn't generalize to highly-tuned implementations that optimize each collection type's data structures individually. -'f
Re: how to write literals of some Perl 6 types?
On Tue, 2008-12-02 at 13:07 -0700, David Green wrote: On 2008-Dec-2, at 12:33 pm, Geoffrey Broadwell wrote: On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote: Darren (): How does one write anonymous value literals of those types? Why is the latter method [conversion] insufficient for your needs? Efficiency reasons, among others. Surely the optimizer will perform conversions of constants at compile time. It would be nice to expect that (though I don't, actually) ... but the second half of my statement was at least as important. It also matters how this is handled for runtime expressions (literals that aren't constants). I was merely saying that we must avoid deciding the semantics in a way that prevents a runtime-varying literal from being constructed efficiently. -'f
Re: how to write literals of some Perl 6 types?
On Tue, 2008-12-02 at 21:21 +0100, Leon Timmermans wrote: If you really want it, a macro can fix all of this for you. That's the beauty of macros: these kinds of things are possible if you need them. Sure, but user-written macros are also an easy out that allows one to avoid making hard decisions about syntax and semantics. Where the base language is concerned, we should avoid waving our hands and telling the user to paper over our indecisiveness. Though perhaps you meant that the base language should implement a few standard macros that convert sugary syntax into something efficient, in which case I'm fine with that answer. -'f
Re: Files, Directories, Resources, Operating Systems
On Wed, 2008-11-26 at 11:34 -0800, Darren Duncan wrote: I agree with the idea of making Perl 6's filesystem/etc interface more abstract, as previously discussed, and also that users should be able to choose between different levels of abstraction where that makes sense, either picking a more portable interface versus a more platform-specific one. Agreed on both counts. Following up on Tim Bunce's comment about looking at prior art, I also recommend looking at the SQLite DBMS, specifically its virtual file system layer; this one is designed to give you deterministic behaviour and introspection over a wide range of storage systems and attributes, both on PCs and on embedded devices, or hard disks versus flash or write once vs write many etc, where a lot of otherwise-assumptions are spelled out. One relevant url is http://sqlite.org/c3ref/vfs.html and for the moment I forget where other good urls are. There are also higher-level VFS systems, such as Icculus.org PhysicsFS, which goes farther than just abstracting the OS operations. It also abstracts away the differences between archives and real directories, unions multiple directory trees on top of each other, and transparently redirects writes to a different trunk than reads: http://icculus.org/physfs/ I want to be able to support that functionality in a way that still allows me to open and close PhysicsFS files and directories the way I would normally. I want to be able to layer it *under* the standard Perl IO ops, rather than above them. The following is all obvious, but just to keep it in people's minds and frame the discussion: Being able to layer IO abstractions is at least as important as the basic OS abstraction itself -- as well as the ability to use the high level abstraction most of the time, but reach down the stack when needed. This implies making best effort to minimize the ways in which upper layers will be hopelessly confused by low-level operations, and documenting the heck out of the problem areas. These layers should be mix-and-match as much as possible, with abstractions designed with common interfaces. Certainly Perl 5's IO layers, as well as any networking or library stack, are prior art here. To summarize, what we really want is something more generic than case-sensitivity, which is text normalization and text folding in general, as well as distinctly dealing with distinctness for representation versus distinctness for mutual exclusivity. Yes, definitely. [This] implies that sensitivity is special whereas sensitivity should be considered normal, and rather insensitivity should be considered special. If only that were true in other areas of life. :-) -'f
Re: [svn:perl6-synopsis] r14586 - doc/trunk/design/syn
On Sun, 2008-10-05 at 17:05 -0700, [EMAIL PROTECTED] wrote: +C infix:... , the series operator. Lovely, just lovely. +1, 3, 5 ... *# odd numbers +1. 2. 4 ... *# powers of 2 Did you mean to use commas on that second line? -'f
Re: Speccing Test.pm?
On Tue, 2008-09-02 at 12:32 -0700, Darren Duncan wrote: Now a common factor to both of my proposals is that this Test.pm is intentionally kept as simple as possible and contains just the functionality needed to bootstrap the official Perl 6 test suite; if the official test suite doesn't use certain features, then they don't exist in this Test.pm, in general. This doesn't quite address one assumed detail -- should the official test suite be modified to use as few (and as simple) Test.pm features as possible, so that Test.pm can then be made even simpler? This would likely make the test suite slightly clumsier in places, while making it easier for a new implementation to get enough functionality in place so that Test.pm is fully supported. There would still be room for third party Test modules, as those would be richer and provide functionality that would be useful for testing language extensions / CPAN modules but that aren't needed by the tests for Perl 6 itself. If the test suite is modified as above, then there pretty much HAVE to be additional Test modules -- people programming third-party code would go insane using only the anemic Test.pm that would be sufficient for a simplified test suite. Of course, that doesn't mean that a more extensive Test module can't be standardized, or even an official version written that all perl6's can ship with. It doesn't have to be all-encompassing, but a core set of best practices test tools, perhaps just taken from Perl 5 experience of the TDD folks and modified for Perl 6 differences, would be nice to rely on everywhere. -'f
Re: [svn:perl6-synopsis] r14516 - doc/trunk/design/syn
Typo nit: On Tue, 2008-02-26 at 09:42 -0800, [EMAIL PROTECTED] wrote: +file in the Standard Dialect (which itself has versions that correspond +to the same version of the official Perl test suite. Eval strings, Appears to be missing a ')' before the '.' -'f
Re: Perl 6 fundraising and related topics.
On Thu, 2008-02-21 at 18:45 -0500, Joshua Gatcomb wrote: On Thu, Feb 21, 2008 at 4:23 PM, chromatic [EMAIL PROTECTED] wrote: 2. Allow people to choose where their money will go (if that's what they want to do) Someone earlier in this thread mentioned that this can't be done directly because of rules surrounding TPF's non-profit status. Someone else pointed out the problems with TPF officers benefitting directly from the donations, even though some of the current and former TPF officers would be great candidates for support. Which made me think ... wasn't this why Mozilla created a corporation? Personally, I think it's ridiculous that a non-profit can't be an umbrella facilitator for directed donations (if that is in fact the case). But if that is really the way of things, can TPF go the Mozilla route to break the logjam? Tax incentives are great, but having piles of money sitting around not getting to hackers is clearly not working for us. -'f
Re: xml and perl 6
Not too put too strong a bias on it, but: XML processors are a dime a dozen. There is no way for us to know *now* what the best XML processor(s) will be a decade from now, and Perl 6 is intended to be a very long term language. And frankly there are enough different use cases to ensure that no single XML processor could possibly be best in all circumstances anyway. We should not canonize a single XML processor (now especially) by putting it in the core. As Nicholas pointed out, it's unlikely that vanilla will be the Perl 6 flavor that any vendor actually ships. But I definitely want to be able to choose between strawberry and chocolate, and perhaps a new flavor of my own (or my company's) design. I really do not want to always get Baskin-Robbins in a blender because everything's in core. The grammar engine is core. A *particular* grammar is not. -'f
Re: xml and perl 6
On Wed, 2007-11-28 at 19:59 +0100, James Fuller wrote: XML Parser is what I am talking about OK -- do you want an event-based parser? Do you want a DOM parser? Do you want a simplified tree generator parser? Do you care about memory limitations? Run time? Does the parser need to be robust against non-compliant XML documents, or is all the data you will be parsing known to be perfectly conformant with specs? Can you take advantage of the fact that all the XML you need to parse was previously written by your own code in the first place? Conversely, are you willing to *always* pay the performance cost associated with security against complete garbage or carefully crafted evil in the input stream? What about parsers that are optimized for particular schema? (For example, that parse an XML dump of a relational database back into a stream of rows to be pushed efficiently into actual RDBMS tables without having to fit the entire database in memory?) Most importantly -- are you sure that *any* of us can make all those decisions for everyone? Are you sure it's even possible to balance all these requirements? Even if we try to handle the common cases, who decides what those are? I guarantee that HugeBank.com and MyFamilyWebsite.net have different views of what the common cases are. and I would argue that XPATH is simple and standard enough to be included as well. I have used XPath exactly once, ever, and it wasn't really necessary even then. For some tasks, yes, it's a standard tool. But the world is much, MUCH bigger than that. putting it more harshly ... I expect my basic programming language to solve my basic problems without having to resort to some layer of abstraction in the form of a framework or external module for the simplest scenarios. This view frustrates me. I want my programming language to provide me expressive power. And I certainly do want modules available should I choose to be Lazy. But I don't expect that someone in a totally different business (or hobby) should want the same modules I do. That's what CPAN6 is for. Or task-related bundles, for that matter. We should not ship CGI *as core*. We should not ship XML tools *as core*. Frankly, I don't think we should ship DBI *as core*, even though I use databases ever day. But these APIs should be available easily. In fact, I expect to be able to intall Bundle::IntarWeb and get them all, plus all sorts of other useful goodies. But what if I am (say) wanting to ship a video game written in Perl. Why should I have to ship all that web-related crap? But I *will* need to ship an OpenGL binding. Which I would guess is totally unimportant to you, while being vitally important, completely basic, and utterly standard (XML is for youngin's, dagnabbit) to me. The Python folks want to ship batteries included. I want Perl 6 to ship a Mr. Fusion Home Energy Reactor and an easy way to download power adapters. I have a lot of XML in front of me in all projects that I work on in every programming context and have had so for the past 3-4 years. I am a bit biased, but I can only see more XML for all of us. Sure. But the world of XML is not the whole world, just as the world of English is not the whole world -- despite the great difficulty many of us have in recognizing that and writing our software accordingly. I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? But that's just it -- it's not common to every problem, only to the problems *YOU* face. I don't by any stretch of the imagination intend this to be a personal attack, by the way. I'm merely saying that numerous people have made similar claims about the feature they need every day being rightfully core. But in nearly every case, that feature was important to *them*, and perhaps even a large class of people, but not to *everyone*. And on occasion, some feature has gotten added to core because it can be used in many different circumstances, or because it's simply not possible to efficiently or easily handle the problem without additions to core. Hence the reason for the amazingly powerful grammars -- you can write parsers in Perl 5 regex (and most of us have), but it's painful, and no amount of tweaking and extending them can make the massive leap in usability and expressive power that Perl 6 grammars bring. With the grammar core in place, XML can be efficiently and easily handled by modules. So it should be. -'f
Re: xml and perl 6
On Wed, 2007-11-28 at 11:46 -0800, chromatic wrote: The criterion for including a module in the core is Is this necessary to get and install other modules? not Why not include this module? WELL SAID. -'f
Re: , , and backtracking.
On Thu, 2007-09-06 at 12:37 -0700, Larry Wall wrote: Yow. ICATBW. The what now? -'f
Re: Should a dirhandle be a filehandle-like iterator?
On Fri, 2007-04-13 at 19:00 -0700, Jonathan Lang wrote: Please. I've always found the opendir ... readdir ... closedir set to be clunky. Also: why distinguish between open and opendir? If the string is the name of a file, 'open' means open the file; if it is the name of a directory, 'open' means open the directory. If it's the name of a pipe, it opens the pipe. And so on. As long as you still have some way to reach the low-level opens -- though it's an odd thing to do (except perhaps in a disk integrity checker), there's no fundamental reason why you shouldn't be able to actually look at the bytes that happen to represent a directory structure on disk. Also, for security or correctness reasons you may want to make sure that you don't clobber things you don't mean to -- so non-dwimmy open variants are a good idea to keep around. This could be as simple as 'open(:!dwim)' I guess, or whatever the negated boolean adverb syntax is these days -'f
Re: [svn:perl6-synopsis] r14319 - doc/trunk/design/syn
On Wed, 2007-03-07 at 21:35 -0800, [EMAIL PROTECTED] wrote: +So these are in sorted version order: + +1.2.0.999 +1.2.1_01 +1.2.1_2 +1.2.1_003 +1.2.1a1 +1.2.1.alpha1 +1.2.1b1 +1.2.1.beta1 +1.2.1.gamma +1.2.1α1 +1.2.1β1 +1.2.1γ +1.2.1 The paragraph above this should explain why the last line (missing a last part) sorts to the end. I'm assuming the intent is so that pre-releases sort before final releases, we just need to specify that intent as part of the sort definition. Debian has crazy version numbers that we can use to test the completeness of our sorting definition. For example, here's one I noticed in this morning's Etch updates: 1.39+1.40-WIP-2006.11.14+dfsg-2 How do symbols (especially + and -, but don't forget others) sort? UTF8 sorting? And do they introduce new fields? And of course, there's epoch notation: 2:20060501cvs-10 Will we handle version epochs, and if so, how? At first I thought Just push this into the auth field and then I wondered What if cpan:DCONWAY decides to change numbering plan on one of his own modules? -'f
request: num16
I'd like to request that num16 and therefore complex16 be added to S09, and made optional just as num128 and complex128 are. The half-sized floating point type is commonly used in computer graphics and widely supported by GPUs and High Dynamic Range image formats such as OpenEXR. -'f
Bit shifts on low-level types
How are the bitwise shifts defined on low level types? In particular, for right shift, does high bit extension or zero fill occur? Does the answer depend on whether the low level type is signed or not? On the flip side, it seems more useful if we have both operators available for either signed or unsigned types, to avoid having to do pointless casting just to change the meaning of +. Perhaps having both + and ? operators? Since coerce to boolean and then right shift is meaningless, this seems ripe to DWIM. (For me, DWIM here means + does high bit extension, ? does zero fill.) -'f
Rotation ops?
Does Perl 6 have (bit/string) rotation ops? Especially bit rotation on low-level integer types would be Nifty for making some numeric algorithms cleaner, more self documenting, and potentially faster than forcing the use of a combination of other bitwise ops to do the same thing. -'f
Low-level types and over/underflow
What happens when a low-level type overflows or underflows? For example, if you decrement an int1 twice, what happens? If you increment a uint8 past 255, do you get: 1. A uint8 with value 0? 2. A uint16 with value 256? 3. A failure? What about incrementing an int8 past 127? Do you get: 1. An int8 with value -128? 2. A uint8 with value 128? 3. An int16 with value 128? 4. A failure? In both cases, I think option 1 is best, but I can see that option 2 in the signed case might make sense in certain circumstances. Personally, I'd prefer to keep option 1 always, because if I want option 2 I should cast to uint or a larger int first. -'f
Casting and low-level types
What happens when you cast between low-level types? If the source value is out of range of the destination type, do you get: 1. An exception? 2. Clip to finite range always? 3. Clip to finite range for ints, clip to infinities for nums? 4. Exception when dest is int, clip to infinities when dest is num? 5. Copy bits that fit from source to dest and reinterpret? Personally, I think option 1 or option 4 make the most sense for conversion between int, uint, num, and complex types, while either option 1 or option 5 make sense for conversion to/from buf types. Also, when casting from a num type to an int type, is there a way to specify desired rounding/truncation behavior in a way that allows the most efficient code under the covers, rather than making a side trip through Num and Int? -'f
Compact structs and byte-stringification
How do you specify that you want to byte-stringify a compact struct, rather than normal stringify it? Does the byte-stringified version include internal and/or trailing alignment padding? How do you specify the other choices? Whether or not trailing padding is included when byte-stringifying a single compact struct, is the choice the same when byte-stringifying an array of same? In other words, are you guaranteed that the byte-stringify of an array of compact structs is merely the concatenation of the byte-stringification of each struct? -'f
Expressions with mixed types including low-level types
How is casting and coersion handled with expressions involving mixed low and high level types? For example, what is the output of this? my Int $ten = 10; my int4 $a = 0; my int4 $b; $b = ($a + 2.4 * $ten) / 4; say $b; The answers to the above questions may alter my view on the proper handling of overflow during casting/coersion. -'f
Re: Expressions with mixed types including low-level types
On Tue, 2007-02-27 at 09:20 -0800, Geoffrey Broadwell wrote: How is casting and coersion handled with expressions involving mixed low and high level types? For example, what is the output of this? my Int $ten = 10; my int4 $a = 0; my int4 $b; $b = ($a + 2.4 * $ten) / 4; say $b; The answers to the above questions may alter my view on the proper handling of overflow during casting/coersion. And for those who think the above code is too easy -- and I can see at least 1, 2, 5, and 6 as defensible answers -- try 2.8 instead of 2.4. -'f
Re: Packed array status?
On Mon, 2007-02-26 at 08:25 -0600, Patrick R. Michaud wrote: On Sun, Feb 25, 2007 at 03:48:47PM -0800, chromatic wrote: On Sunday 25 February 2007 12:40, Geoffrey Broadwell wrote: What backends support packed native arrays at this point? And what's the performance like? I don't know if Patrick has using PIR libraries working in Perl 6 yet, but the last time we talked about it, he said it would take just a bit of work. No, I don't have them working yet, but implementing them shouldn't be too difficult. I just need to have perl6 recognize imported classnames. (The syntax for making method calls is already in place and working.) Is there a page where you keep your working / in progress / not working status information? If so, I can look there to see how close Perl 6 on Parrot is to what I'll need for the port. As a simpler case than a full 3D engine port, I have some OpenGL benchmarks in Perl 5 that I can port -- these have much reduced requirements. Principly, they need: 1. Basic math and string operators (not grammars) 2. Basic looping and simple control structures 3. Basic subroutine handling 4. Basic I/O: read file, print to STDOUT (printf is a bonus) 5. Read access to command line args 6. Perl scalars, hashes, and arrays, with one level nesting 7. Packed arrays with access to raw data pointer to give to API 8. eval (tight inner loops are generated) 9. High-resolution time 10. Access to SDL OpenGL constants 11. Procedural calls to OpenGL, with scalar return values 12. Procedural or OO calls to SDL, with scalar (and object, if OO) return values (no callbacks) Requirements 3, 4, 5, 8, 9, 10 can all be worked around with some effort, but the rest would be quite painful to work around. It is possible to do part of the benchmark without requirement 7 (the one that started all this) just to make sure the other stuff is functional, but it's a pretty limited benchmark without the packed arrays. How is Perl 6 on Parrot doing with regard to the above list? -'f
Re: Packed array status?
Pugs at the moment support all of the above, using the Perl 5 bridge for use perl5:SDL and use perl5:OpenGL. So the sole requirement seems to be: Cool beans. I'd had some simple OpenGL code working-with-hacks on Pugs many months ago, but I did not know the current status after all the internals churn. 7. Packed arrays with access to raw data pointer to give to API Is it possible to point us to some use cases of such packed arrays, especially the raw data pointer API part? Are you looking for Perl code that creates such packed arrays and passes them to OpenGL? Or are you looking for links to manpages for the OpenGL calls themselves? Or both? Also, if you would translate a few such use cases to the syntax in S09 (http://perlcabal.org/syn/S09.html) and committing them under t/data_types/, then it'd be much easier to measure which parts of packed arrays needs to be specced/implemented first. I can write some tests that build packed arrays of some of the types I need and then go snooping around it checking the contents ... would that help? Somehow I'm thinking it's a bad thing if data types tests require OpenGL ... but it seems hard to tell whether the implementation is actually creating a packed array, or just faking the Perl-side behavior using an unpacked array, unless we make a call to some C API that can confirm the results. H ... a quick scan of S09 indicates a packed array of any low-level type can be treated as a buf, so I might be able to get sneaky with that equivalence in order to reach a high probability that either the packing is real or the implementor is insane. -'f
Re: Packed array status?
On Tue, 2007-02-27 at 03:02 +0800, Audrey Tang wrote: 2007/2/27, Geoffrey Broadwell [EMAIL PROTECTED]: Are you looking for Perl code that creates such packed arrays and passes them to OpenGL? Or are you looking for links to manpages for the OpenGL calls themselves? Or both? The former. OK, I'll pull some of the interesting routines out of my code and post them. I can write some tests that build packed arrays of some of the types I need and then go snooping around it checking the contents ... would that help? Somehow I'm thinking it's a bad thing if data types tests require OpenGL ... but it seems hard to tell whether the implementation is actually creating a packed array, or just faking the Perl-side behavior using an unpacked array, unless we make a call to some C API that can confirm the results. That is correct. However as you noted, our buf should be as good as a C-level packed buffer, so you can assume that when writing the tests. Alternately, we can assume some fairly simple C FFI calls such as strlen() (or some such) that manages the structs we'd like it to manage. I'm being an idiot -- if we can assume Perl 5 connectivity, I can just pass the buf as a string over to Perl 5, unpack there, return the unpacked values to Perl 6, and compare. Does Perl 6 on Parrot have Perl 5 connectivity? -'f
Re: Packed array status?
On Mon, 2007-02-26 at 16:29 -0800, chromatic wrote: On Monday 26 February 2007 11:29, Geoffrey Broadwell wrote: Does Perl 6 on Parrot have Perl 5 connectivity? Not until Perl 6 can use PIR code. After that, it depends on what you want to do with the two. If you can get Parrot::Embed compiled and running on your machine, Perl 5 can have Parrot connectivity. (As far as I know, Windows is the only broken platform now, but I already knew that.) OK, between chromatic and Audrey, it sounds like the paths forward are: 1. Add tests to Pugs for packed data handling. 2. Pugs implements functionality for said tests. 3. Port of OpenGL code proceeds assuming use of SDL/OpenGL via Perl 5. 4. Perl 6 on Parrot implements PIR calls. 5. Perl 6 on Parrot gets native packed arrays. Then either: 6. Perl 6 on Parrot gets Perl 5 connectivity. 7. Perl 6 on Parrot uses #3 as written. or: 6. SDL/OpenGL are wrapped directly in PIR. 7. #3 is rewritten to use native Parrot modules. Of course, *both* paths will probably eventually be followed, it's just a question of which one works first. :-) In the mean time, I need to try to find my commit details for the Pugs repo so that I can check out a copy and start on step 1. -'f
Packed array status?
What backends support packed native arrays at this point? And what's the performance like? Native access to packed arrays is the big thing I'm looking for before I port a pile of source filtered Perl 5 code to Perl 6. It's a simple 3D engine, so all of the libraries I need to work with want to work with pointers to huge arrays of simple and structured C data types -- and I need the Perl code to be able to directly manipulate those arrays. In Perl 5 I'm using PDL for this, and for certain operations it's not too bad, but it's REALLY slow to cross any of the Perl - PDL - C borders (even give me a pointer to the raw data inside a PDL object is a slow operation). Apropos of the recent thread about specification lockdown: To those wondering why I haven't started the Perl 6 port already, in anticipation of this feature working: I'm still adding features (and even some major rewrites) in the Perl 5 version. When I do the port, I want to be able to cut over from one working code base to another. I don't want a period of bitrot in which the Perl 6 port is done but not working, and continuously at risk of being out of sync with changes to the working Perl 5 codebase. I also want to be able to quickly graduate from a pure port design to a colloquial Perl 6 design, which I can't safely do and still keep syncing updates reasonable. If I could expect packed arrays to be working at some *known* point in the future, I could probably aim for that. However, my recollection of the Perl 6 history so far is that itch-scratching and bootstrapping are the two forces driving the implementations, so I've no idea when I could expect the feature to appear if it hasn't already -- and hence no desire to start now and risk the aforementioned bitrot for an unknown and possibly long period. (I'm *NOT* complaining about the state of implementation -- the spec lockdown thread just reminded me that the core team might want to know why someone who is very excited about Perl 6 isn't jumping in with both feet. My gut feeling is that the details may change, but my hesitation is probably not unusual.) -'f
Re: What criteria mark the closure of perl6 specification
On Sun, 2007-02-25 at 12:15 -0800, Jonathan Lang wrote: I submit that you'll have even more luck discouraging such things if you can give a reasonable and believable timeline as to when the 6.0 spec will be ready and perl 6.1 features can start being considered. As I mentioned in another thread, but didn't make clear in that email: I don't need a finished spec. I need the *current* version of spec to actually be mostly implemented. I'm completely willing to surf a moving spec, as long as I can have working or near-working[1] code the whole time. Some people are happy writing great gobs of code completely separate from a working compiler purely for the mental exercise, but that doesn't -Ofun for me. My programming style is extremely iterative, and I need to be able to get something working right off the bat, or it's just not fun for me. And if it's not fun, I won't end up putting any of my very limited free time into it. -'f [1] Near-working in this case meaning some feature's syntax just changed slightly, and it will only take 5-10 minutes to get everything going again.
Re: What criteria mark the closure of perl6 specification
On Sun, 2007-02-25 at 13:26 -0800, chromatic wrote: On Sunday 25 February 2007 12:56, Geoffrey Broadwell wrote: As I mentioned in another thread, but didn't make clear in that email: I don't need a finished spec. I need the *current* version of spec to actually be mostly implemented. The implementors want the same thing. And if it's not fun, I won't end up putting any of my very limited free time into it. Neither will the implementors. My apologies if what I said came across as critical; it wasn't intended that way. I was merely trying to point out that there is at least one user here that does not believe lack of a finished spec is the biggest blocker for people wanting to switch to Perl 6. I don't believe that the core team should be rushing the spec at all. That's just pushing any possible issues from before first release to after first release, and any team manager can tell you that's a recipe for making broken things considerably more difficult/expensive to fix. In the early days, the extreme flux of the spec was a bit of an issue, because being away for a couple weeks meant that things had changed A LOT in the intervening time. That doesn't seem true any more. Even for a user with limited time, the current pace of changes don't seem daunting to keep up with. Rather, the problem is that many things have yet to work at all. I'm not trying to say that the implementors should rush either, nor am I complaining about current status; I grok the dynamics of volunteer code. I merely disagree with the spec is all-important crowd. I personally have a preference for rough consensus and working code, and I wanted to make sure that viewpoint wasn't lost. -'f
Re: What criteria mark the closure of perl6 specification
On Sun, 2007-02-25 at 14:16 -0800, chromatic wrote: On Sunday 25 February 2007 13:57, Geoffrey Broadwell wrote: I'm not trying to say that the implementors should rush either, nor am I complaining about current status; I grok the dynamics of volunteer code. I merely disagree with the spec is all-important crowd. I personally have a preference for rough consensus and working code, and I wanted to make sure that viewpoint wasn't lost. Me too. I also want to point out that we're not nearly at the point where adding more developers--for as much or as little as they want to contribute--will slow things down. Hmmm. Let's see if there is a way I can help to get what I want Assuming that the answer to my question in the other thread is packed arrays aren't implemented anywhere yet, are any implementations close enough that I can trade tests for implementation? Given my programming style, creating a big pile of tests all at once won't really work (I'll just end up creating a bunch of bad tests). But I could probably loop over add a couple tests, implement piece of feature, add a couple more tests, implement another piece, ... with someone. It wouldn't be a particularly *fast* iteration, but at least there would be some movement -'f
Re: [svn:perl6-synopsis] r8902 - doc/trunk/design/syn
On Fri, 2006-04-21 at 13:27 -0700, [EMAIL PROTECTED] wrote: Bitwise operations on a CStr generally fail unless the +CStr in question can provide an abstract CBtr interface somehow. +Coercion to CBtr should generally invalidate the CStr interface. +As a generic type CBtr may be instantiated as (or bound to) any +of Cbuf8, Cbuf16, or Cbuf32 (or to any type that provide the +appropriate CBuf interface), but when used to create a buffer CBuf +defaults to Cbuf8. What's a Btr? A Bit sTRing? -'f
Mismatching text and example in S06
From S06:
*
As we saw earlier, zip produces little arrays by taking one element
from each list in turn, so
(0..2; 'a'..'c') == my @;tmp;
for @;tmp.zip { say }
produces [0,'a'],[1,'b'],[2,'c']. If you don't want the subarrays, then
use Ceach() instead:
(0..2; 'a'..'c') == my @;tmp;
for @;tmp.map { say }
and then you just get 0,'a',1,'b',2,'c'. This is good for
for @;tmp.map - $i, $a { say $i: $a }
*
The reference to Ceach() and the use of .map don't match.
-'f
Perl6 Polyglot
The first entry in my new weekly Perl etc. O'Reilly blog is up: http://www.oreillynet.com/pub/wlg/7928 When I mentioned it on #perl6, nothingmuch suggested I post to p6l as well. So here you go. :-) -'f
