xml and perl 6
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? cheers, Jim Fuller
Re: xml and perl 6
all makes good sense, to make a poor analogy (and to make my point); the java build tool, Apache Ant went through the same sort of cycle (at a much smaller scale) whereby initial architecture forced a lot of extraneous functionality into the core hard to maintain and limited deployment profile capability was the result. With Ant's latest incarnation, they finally have a good model for extensibility and have been successful at segregating axiomatic functionality to the core and relegating extensions to external libraries. I completely agree that this is also good approach for Perl 6 but I would weakly argue that XML ubiquity is fast making it the 'text' format of the day and perl having many text processing facilities built into its core might want to reconsider some basic premises about how it perceives XML. A few things I could imagine; native XML data type (and whatever that means at this late stage) xml parser, xpath processor built into Perl6 core making it very quick, since we are late stage I would call this an optimization ;), I can even see in a moment of madness a nod to 'whatever' programming and embed some triple inference processing deep into perl6. making perl 6 XML-neutral is a mistake. imho. cheers, Jim Fuller On Nov 28, 2007 7:12 PM, Nicholas Clark <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: > > there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps > > before Perl 6 is fully its time to review what could live in the > > core versus an external module. > > > > thoughts? > > If I remember the plan correctly, it's roughly that the core consists only of > the mechanisms for getting and installing other extension modules - anything > that doesn't need to be in the core, isn't. > > This slim core intentionally won't be useful for that much, other than the > basis for building larger Perl 6 distributions aimed at broad types of tasks. > The idea being that an ISP would install the "web serving" distribution, > which would be bundled with the sorts of modules appropriate for that task, > but not burned with the sorts of modules useful for bioinformatics. > > The aim is to avoid the problem that Perl 5 finds itself in, where things > once added to the core can never be removed, and 15 years later you find > that there are several generations of "this is current" modules in the > distribution that are a maintenance burden. Usually a burden that falls on > volunteers. > > Nicholas Clark >
Re: xml and perl 6
On Nov 28, 2007 7:31 PM, C.J. Adams-Collier <[EMAIL PROTECTED]> wrote: > On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote: > > On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: > > > there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps > > > before Perl 6 is fully baked its time to review what could live in the > > > core versus an external module. > > > > > > thoughts? > > > > If I remember the plan correctly, it's roughly that the core consists only > > of > > the mechanisms for getting and installing other extension modules - anything > > that doesn't need to be in the core, isn't. > > > > This slim core intentionally won't be useful for that much, other than the > > basis for building larger Perl 6 distributions aimed at broad types of > > tasks. > > James, > > Perhaps you should create a "distribution" for xml processing? If there > is not yet a Standard Operating Procedure for creating a perl 6 > distribution, I think the community would benefit from the creation of > such. Start small, with only enough to do a simple XML processing task. > Allow for inheritence/extension of the distribution. I see these 'distributions' as deployment profiles. It would be very easy to package up (more akin to customizing a linux distro) perl6 with all those lovely XML pm tweaking here and there, etc. in the meantime, I have yet to get latest trunk perl6 running properly, on parrot, or freebsd then I will start thinking of such a task (everything compiles fine). as an aside I am getting an; "load_bytecode" couldn't find file 'Protoobject.pbc' current instr.: 'parrot;PGE::Match;__onload' pc 0 (compilers/pge/PGE/Match.pir:14) called from Sub 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) also I do not want to emulate perl6 in perl5; will try on the OSX box now. cheers, Jim Fuller
Re: xml and perl 6
On Nov 28, 2007 7:39 PM, Andy Armstrong <[EMAIL PROTECTED]> wrote: > On 28 Nov 2007, at 18:28, James Fuller wrote: > > > A few things I could imagine; native XML data type (and whatever that > > means at this late stage) > > What might that mean at any stage? from a syntactic point of view, here are 2 interesting examples of representing XML in a programming context http://en.wikipedia.org/wiki/E4X and http://en.wikipedia.org/wiki/XQuery there is lots to learn here. J
Re: xml and perl 6
On Nov 28, 2007 7:50 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote: > 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. XML Parser is what I am talking about and I would argue that XPATH is simple and standard enough to be included as well. > 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. 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. 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. 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? I am going on now but you get the point. cheers, Jim Fuller
Re: xml and perl 6
On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 28 November 2007 10:59:30 James Fuller wrote: > > > 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? > > Because it's not necessary for getting and installing other extension modules. > > 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?" I read this statement as saying that perl's core main purpose is to enable extension versus be a useful programing language ? feels like we are externalizing what I would call build artifacts of a language e.g. a distro of Perl 6 should be easy to adopt and easy to use immediately . I would like to see some basic level of XML support in this distro. I understand that there can be different distros customized to certain problem domains, but as explained I see XML as common to all those problem domains. I like the approach from a 'build language' point of view, but I am wondering what sort of dependency management one must get involved with if using distro X versus distro Y. cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 7:45 AM, Alex Kapranoff <[EMAIL PROTECTED]> wrote: > В Чтв, 29/11/2007 в 07:18 +0100, James Fuller пишет: > > On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote: > > > On Wednesday 28 November 2007 10:59:30 James Fuller wrote: > > > > 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? > > > > > > Because it's not necessary for getting and installing other extension > > > modules. > > > > > > 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?" > > > > I read this statement as saying that perl's core main purpose is to > > enable extension versus be a useful programing language ? > > > > feels like we are externalizing what I would call build artifacts of a > > language e.g. a distro of Perl 6 should be easy to adopt and easy > > to use immediately . I would like to see some basic level of XML > > support in this distro. > > > > I understand that there can be different distros customized to certain > > problem domains, but as explained I see XML as common to all those > > problem domains. > > But is it? I'm sure you can easily find lots of people using Perl > professionally without any need of an XML parser/processor. Just like > database or web libraries. Why do you consider XML something essential > without also insisting on all the other technologies people use in Perl? I know that perl 6 will have XML processing libraries to get my XML processing jobs done ... not concerned about this and there is no need to argue this point with me... as that is not my point. Though isn't perl 6 missing an opportunity with perl module development, e.g. every time someone does something with a perl module they could benefit from a core of XML processing functions, from which to interact in XML? So what is proposed is a dependency with another module. From another point of view, there must be a reason why most languages have not decided as treating XML as a first class citizen. I do know that instead of using XSLT or XQuery or whatever ... that I can see such a thing as 'useful' for me and my world. I am not trolling here, I did want to sample the opinion, which seems to be a majority who disagree with me. cheers, Jim Fuller
Re: xml and perl 6
On Nov 28, 2007 8:48 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote: > 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? a basic XML parser, from which one can build anything else (like a DOM or SAX parser). when building a parser, I would care about memory limitations and all the questions you ask, this would be asked irregardless of embedding into perl or writing something standalone ... feels like you are just asking questions to enhance perception of complexity. > 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. I would argue that XML is slightly evolved 'text' and I would like to see my fav programming language treat it as a first class citizen internally. Put this in perspective, XML is 10 years old and it is widely adopted. Just doing an informal survey across a lot of common programming languages/frameworks shows it is common and widely supported; having some tooling embedded in the language, though admittedly most of these approaches still 'bolt on' XML. I will first have to get perl6 (on parrot) running to understand a bit more of what is in core before I continue asking any more questions. cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 12:01 PM, Smylers <[EMAIL PROTECTED]> wrote: > So, to make a claim for any 'domain-specific' functionality to be added there are plenty of core perl functions that you or I will use rarely (both in perl 5 and perl 6). my claim is that XML is significantly common place, that any new language that descends from the gods, could have some basic XML processing support in place. It's an opportunity to formalize xml processing idioms in all those external modules, as well as ensuring high performance. > to the core, you would have to be better at making predictions than > those who added modules to Perl 5. _Are_ you better at such > predictions? What evidence have you got for that? the only evidence I have is anecdotal. > When XHTML1 launched did you correctly predict that XHTML2 would turn > into an ignored project that no web-browser vendors are interested in > implementing, and that instead they would be implementing HTML5, a > language based on HTML4 that encourages authors not to bother with XML? no, I didn't predict this ... but this is not really a valid analogy,I am not predicting XML usage I am using it all the time, as is most of the folks I know are . I am sure there is a silent majority of perl users who interact with XML on a regular basis but yes I agree it is impossible for me to prove ;) as already mentioned, I am sure that perl 6 will have XML processing my point is if we should have some bits in the core which I see as being an advantage over other languages; also will , the vocal majority here is saying 'no' . but doesn't every good idea meet resistance. It would be interesting to hear from someone who does use perl and XML if this is not the case on the perl 6 language list, then perhaps perl 6 is not the language for me ;) cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 1:15 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
> This has become quite the flame war. There seem to be two sides of
> the argument, you arguing one, everybody else arguing the other.
good to see there is passion underlying perl 6 development ;)
> So to bring some perspective back into this discussion, I'd like to
> ask you, what would it mean to you for there to be an XML type in
> core? That is,
> from a user's perspective, disregarding implementation of the
> language? What would you be able to do with it that you couldn't do
> if it were a module
> (arguments such as "use it without putting 'use XML::Foo' at the top"
> considered valid)?
well, if my previous posts didn't attract flames this post certainly will ;)
but you did say 'from a users perspective' ... so I will play 'make
believe' with some syntax
first a few assumptions;
we will probably never want to 'address' xml in perl ... e.g. perl
format will never become declarative markup and there is no reason to
start wanting to somehow mix code/data lisp style in perl
another thing to admit is that an XML type would probably just be an
XML document well formed and adhering to the rules of XML v1.0
going beyond that and stating it must be an XML Infoset is going
too far.
---
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
-
declaring some xml in one's perl program;
-
my $sales =
;
no surrounding quotes seems about right.
however this leads to some 'other thoughts, like how does perl and xml
play nice together
what about;
my $html =
{ $sometitlevar }
{
loop ($counter = 1; $counter < 20; $counter++) {
Try to count electric sheep . . . ;
}
}
I have eschewed with explicitly having a print statement, as a
syntactic shortcut.
when it comes to manipulating XML, there are a few axioms...
-
How to Address parts of an XML document variable ?
-
It is common to want to address a portion of an XML document
my $select_li_elements = $html.html.body.span.ul ;
this syntax is ok (actually I do not like this approach), but I like
my 'scanability' to be in xpath form ala:
my $select_li_elements = $html[/html/body/span/ul/li];
and then u have the expressive power of xpath inside of these brackets.
so when declaring a var as xml, it would be this
my $data is XML;
( as an aside, is there any concept of the native types, Scalar,
Array, Hash being in a different namespace then all the other symbols
e.g. could I override Scalar type ?)
next,
-
How do I update an XML document variable ?
-
Here are a few edit type examples reusing the XPATH syntax introduced earlier;
This would replace text context node of
$html[/html/body/[EMAIL PROTECTED]'mydivid'] ] = "new text value";
This would replace text context node of a div with an id of the value
of $myperlvar
$html[/html/body/[EMAIL PROTECTED] ] = "new text value";
This would replace XML children of ul element
$html[/html/body/span/ul] .= some new bullet point;
This would remove XML children of ul element
$html[/html/body/span/ul] .= null;
I am unsure of what an append scenario would look like.
-
And what about validation?
-
Perhaps one would like to be able to decide if this xml must be
checked for validaty against some schema technology (DTD and relaxNG
as basic) are there any 'adjectives when declaring a type ... I
guess I am suggesting a new sigil enforcing an XML context ;0
then there is the 'processing' XML bit .
-
Iterating through XML
-
should print out the value of each div contained in html
for $myxmlvar[/html/body/div]]{
print; # prints $_, the current loop variable
}
I will stop here ... so I can put on my flame proof suit.
cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 1:15 PM, Luke Palmer <[EMAIL PROTECTED]> wrote: > language? What would you be able to do with it that you couldn't do > if it were a module > (arguments such as "use it without putting 'use XML::Foo' at the top" > considered valid)? and to answer specifically the question; 'What would you be able to do with it that you couldn't do if it were a module ?' there is no difference in usage. but by making some fundamental xml processing available by the core (like file access, regex, and a host of other fundamental bits n bobs), u do promote a common and systematic approach to working with XML in all perl modules. I see some real benefits to this (more associated to lingua franca type design patterns). cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 3:44 PM, Smylers <[EMAIL PROTECTED]> wrote: > What makes you so sure that nobody will come up with a better way of > working with XML there is power in everyone doing the same thing ... this is a variation of lingua franca design pattern. For example, would we say that the reason why HTML is powerful today based upon the right mix of angle brackets and hyperlinks, etc... I would argue no; its simply because everyone is using it. HTML 'could' just as easily been pure SGML or s-expressions for all I care. Back to the arguement; By placing some basic xml handling in core, then you are enforcing a single authoritative approach to using XML inside of perl ... you are not restricting it ... yes someone can come up with a 'better' way as well. I have been arguing that having some simple functionality, provided by the core, would potentially harmonize usage across modules and promote better understanding of code, in general, through consistent usage. There is a recent analogs in perl, of what happens, for example; the lack of a case statement in perl (which I am personally fine with) meant a multiplication of the ways one implements such a logic structure, in turn reducing understandability in the end we now have 'given'. I would not include XML::Parser though I would expect an XML parser (like expat) to have to 'live' somewhere in perl or be dynamically linked is there one in parrot I wonder . to underpin the structures I have shown in my previous email with faux perl syntax. Once again, the point is that I would like to manage and process XML using native types, structures and xml aware operators, from within perl. If I inherit XPATH, then I get 90% of everything I need. cheers, Jim Fuller
Re: xml and perl 6
Thanks to all for taking the time to respond at a minimum the discussion has taught me where perl 6 is headed and where the major architectural brake points currently are. gl, Jim Fuller
Re: Perl 6 fundraising and related topics.
can I add a few unsolicited ruminations from a lurker; * just release perl 6 now and move on * do not hire 40 year olds with responsibilities, convince the young to spend their time for free ... isn't that what one is supposed to do after the age of 40 ? * use all funds to promote its usage, not fund its development * promote its usage past perl's borders, e.g. perl should be an ingredient not a closed garden at some Perl conference ... * look at successful OS orgs like mozilla and apache (different to each other yes) and copy their techniques a systematic plan past these points will then be possible. cheers, Jim Fuller
Re: Perl 6 fundraising and related topics.
On Wed, Mar 26, 2008 at 7:44 PM, Richard Dice <[EMAIL PROTECTED]> wrote: > What all of myself, chromatic and Richard Hainsworth seem to appreciate is > that a plan without resources to back it up is almost guaranteed to be > ineffective. Even more than that, we have an appreciation that planning I always relate OS development to how the genetic algorithm works; e.g. a successful OS development typically works quite happily even without a lot of upfrontplanning (though major 'weeding' can be required) or a major spot on the horizon to navigate towards. its ruthless in what dies (projects failing) and what succeeds however it does need a few self organizing principles; a large gene pool, heterogeneity and the ability to mutate to respond to short duration events, oh ya and the ability to mate right we can leave the last one off ;) I do not pretend to know how this specifically relates to getting 'critical mass' of development on perl6 to be feature complete ... my comments were a bit casual; I do not think that its right to release perl6 for the language, but it might be 'right' to do for language adoption no doubt cathedral / bazaar forces are in effect. cheers ,Jim Fuller
Re: New specdoc available
nice work, I think this kind of redrafting can be a good foundation for refactoring ... though I would go further and suggest an xml based format ... if u have a .odt you can convert this to docbook ;) one nit pick; drop 'rigorous' in title Jim Fuller
Re: treatment of "isa" and inheritance
On Wed, Apr 30, 2008 at 9:14 PM, Jon Lang <[EMAIL PROTECTED]> wrote: > Brandon S. Allbery KF8NH wrote: > > > TSa wrote: > > > I totally agree! Using 'isa' pulls in the type checker. Do we have the > > > same option for 'does' e.g. 'doesa'? Or is type checking always implied > > > in role composition? Note that the class can override a role's methods > > > at will. > > > > It occurs to me that this shouldn't be new keywords, but adverbs, i.e. > ``is > > :strict Dog''. > > Agreed. I'm definitely in the category of people who find the > difference between "is" and "isa" to be, as Larry put it, eye-glazing. > I can follow it, but that's only because I've been getting a crash > course in type theory. +1 > Brandon's alternative has the potential to be less confusing given the > right choice of adverb, and has the added bonus that the same adverb > could apply equally well to both 'is' and 'does'. > > On a side note, I'd like to make a request of the Perl 6 community > with regard to coding style: could we please have adverbal names that > are, well, adverbs? "is :strict Dog" brings to my mind the English > "Fido is a strict dog", rather than "Fido is strictly a dog". Not > only is "is :strictly Dog" more legible, but it leaves room for the +1 > possible future inclusion of adjective-based syntax such as "big Dog" > (which might mean the same thing as "Dog but is big" or "Dog where > .size > Average"). To misquote Einstein, things should be as simple > as is reasonable, but not simpler. and can I add another quote, from someone who's last name is appropriate ;) 'Simplicity does not precede complexity, but follows it.' (Alan Perlis) cheers, Jim Fuller
Re: Logo considerations
I think if the logo alluded to something revolving around a xmas present would be appropriate. -Jim Fuller
Re: Logo considerations
creating a logo by committee is probably the worst way to design such things ... perl6 logo will be seen in the context of other more professionally designed logos and like it or not using the basics of modern branding and marketing will result in something that is more recognizable no matter how much we may despise these kind of techniques realize that commercial entities (which compete in some way directly with perl6) will spendmillions on such activities and perl6 should consider at a minimum professional execution of a design. Is there any sponsorship money to spend on a very good graphic designer to create something based on a small list of requirements as to what meaning it should convey ? Of course the logo should represent the community fundamentally, but I find all of the suggestions little to do with addressing needs of a logo versus needs of what I would call more of a 'club' badge. I mention these concerns because I would like perl6 to be adopted to as wide a developer audience as possible. my 2p, Jim Fuller On Tue, Mar 24, 2009 at 8:51 PM, Conrad Schneiker wrote: >> From: Guy Hulbert [mailto:gwhulb...@eol.ca] >> On Tue, 2009-24-03 at 11:38 -0700, Conrad Schneiker wrote: >> > Here's my latest suggestion: >> > >> > http://www.athenalab.com/Rakudo_logo_2.htm >> > >> > It combines Damian Conway's suggestions (please see below) >> > and Ross Kendall's suggestions at >> > (http://www.rakudo.org/some-rakudo-logo-ideas). >> > >> > For a smaller sized Rakudo logo, >> > just remove the text between the proposed Perl 6 logo >> > and the Parrot logo. >> >> For the small logo, you could super-impose the Parrot on top of the >> molecule ... and for pugs: >> http://www.bnpositive.com/blog/wp-content/uploads/2006/10/starwars-pugs.jpg > > That's awful! > > And outrageously hilarious. > > The Yoda image + molecule (aka "hexa-flower") gets my vote for Pugs > (although it's not my decision to make). > > Best regards, > Conrad > > Conrad Schneiker > www.AthenaLab.com > > > >
Re: Logo considerations
to further comment, I would never believe a logo actually influences which programming languages one chooses to develop in ... but I would argue that a logo needs to convey the right 'messages' to those who pay for software projects ... as with any logo; my point is to identify these messages prior to instantiation e.g. graphic design ... though doing both ain't bad either. here is a stab at some simple messages. for developers: inclusive, easy to use, fast, powerful, linguistic based, DIY, all computing paradigms allowed (func, proc, oo, etc), fun, subversive for wider audience: robust, trusted, straightforward, safe, supported colors evoke meaning, shapes/animals, etc do as well ... thats enough from the 'marketing corner' ... back to programming. cheers, Jim Fuller On Tue, Mar 24, 2009 at 10:34 PM, Guy Hulbert wrote: > On Tue, 2009-24-03 at 21:10 +0100, James Fuller wrote: >> creating a logo by committee is probably the worst way to design such >> things ... perl6 logo will be seen in the context of other more >> professionally designed logos and like it or not using the basics of > > I hate the java stuff (professional). I don't think much of the debian > stuff either (amateur). Some of the things suggested here have been > pretty good. > > [snip] >> Is there any sponsorship money to spend on a very good graphic >> designer to create something based on a small list of requirements as >> to what meaning it should convey ? > > How was the parrot logo created ?? I saw a suggestion here that it is > professionally designed but that wasn't confirmed. It looks good enough > to me regardless. > > I don't see a problem with a long list ... > >> >> Of course the logo should represent the community fundamentally, but I >> find all of the suggestions little to do with addressing needs of a >> logo versus needs of what I would call more of a 'club' badge. > > ... I see the suggestions here as necessary input. > >> >> I mention these concerns because I would like perl6 to be adopted to >> as wide a developer audience as possible. > > I don't think the logo will make much difference. > > I don't particularly care much about *what* the logo is or *how* it is > created. I've only been offering comments as feedback to the people who > are actually working on it. Beauty is better than not. > >> >> my 2p, Jim Fuller >> > [snip] > > -- > --gh > > >
Re: Rukudo-Star => Rakudo-lite?
how about 'raku' then the final version could be called 'rakudone' Jim Fuller
