This fortnight's summary
The Perl 6 Summarizer
Good evening. You find me typing away in a motel room on the edge of the
Lake District on the shortest night of the year. I suppose, by rites, I
should be spending the night by some stone circle drinking, dancing and
generally making merry, but as I'm a teetotal, unfit, atheistical nerd
with a mission to summarize I'll skip that and plough straight into the
activities of another arcane sect. Yes, it's perl6-internals again...
Towards an accurate README
Andy Dougherty sent in a patch adjusting the Parrot README so that it
accurately reflected the toolset needed to build parrot. For some
reason, as well as the requirement for a C++ compiler if you want to
build the ICU library, we've moved to needing Perl 5.6.0 rather than
5.005. Nicholas Clark suggested that, rather than bumping the Perl
version requirement, we bundle appropriate versions of modules Parrot
required, but chromatic thought it better to check the for the correct
versions of said modules at Configure time and bail out if they weren't
there.
There was further discussion about whether going to Perl 5.6.0 as a
requirement was the right thing to do -- the issue is that some OSes
(FreeBSD and Solaris 8 were cited) still only ship with 5.005 family
Perls. My feeling (which I didn't mention in the thread, more fool me)
is that, as eventually the goal is to eliminate the need for Perl at all
in the build process, then require 5.6.0 rather than 5.005 isn't exactly
the end of the world.
http://groups.google.com/groups?selm=rt-3.0.9-30095-89...@perl.org
http://groups.google.com/groups?selm=Pine.SOL.4.58.04...@maxwell.phys.lafayette.edu
OS X Builds again
Someone finally summoned up the tuits to fix the OS X build. Step
forward Nicholas Clark and accept your plaudits.
http://groups.google.com/groups?selm=a06110404bcee2724f70a@[10.0.1.3]
Basics of the PMC class set
Dan announced that he was about to make some changes to the repository,
including establishing a basic set of PMC classes. Matt Fowles wondered
about Array PMCs, which seemed to be missing from Dan's list. Dan agreed
that they should be rationalized as well.
Bernhard Schmalhofer suggested adding a complex number class to Dan's
basic menagerie, but Dan was unconvinced.
http://groups.google.com/groups?selm=a06110402bcee766bc83c@[172.24.18.98]
Correct use of #define
Nicholas Clark was moved to growl by a section of
include/parrot/string.h that used a #define to define a type. Actually,
he was moved to 'swearing and cursing and time wasted grepping to find
out what a STRING is'. Dan agreed that this was bad and decreed:
'Typedefs for types, #defines for constants and bizarre (*temporary!*)
debugging things.'
http://groups.google.com/groups?selm=20040611095...@plum.flirble.org
The next release
During a lull while Leo Tötsch was away at a conference, Dan mused on
the next release of parrot. His goal for that is a rejig of classes/,
aiming to make sure that all the PMCs we want are in and working, and
that the ones we don't care about are neatly deprecated.
Warnock applies.
http://groups.google.com/groups?selm=a06110409bcefa5f8c6ff@[10.0.1.3]
A small task for the interested
Stretching the definition of 'small' somewhat, Dan asked for volunteers
to implement the missing PMCs detailed in PDD 17. He reckoned it should
be 'fairly straightforward'. A new entrant in these summaries, Ion
Alexandru Morega took a crack at the String PMC and posted a patch to
the list which was promptly ignored. Which seems a little unfair really.
http://groups.google.com/groups?selm=a0611040abcefb912413e@[10.0.1.3]
Bignums!
Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up
to the plate. Leo suggested that, rather than starting from
types/bignum.c, it might be better to use an existing, maintained, maths
(Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will
be a cold, cold day in hell when I start abbreviating 'mathematics' as
'math'. Ahem.) package. Dan worried about license compatibility; the
proposed GMP package is licensed under the LGPL which may (or may not)
be compatible with Parrots Artistic/GPL dual licence. After a closer
reading he reckoned that GMP's license is definitely incompatible with
Parrot.
http://groups.google.com/groups?selm=a0611040bbcefb9fb77e6@[10.0.1.3]
Adding Fixed*Array classes
Matt Fowles posted a patch implementing Fixed Array classes. Dan applied
it. Leo wondered about the patch's use of malloc(3) instead of Parrot's
memory management. Dan wasn't worried in the case of fixed size arrays.
http://groups.google.com/groups?selm=rt-3.0.9-30230-903...@perl.org
Resizeable*Array classes
Fresh from his Fixed Array triumph, Matt Fowles posted a patch
implementing naïve Resizeable Arrays. Leo thought it a little too naïve,
and worried about duplication of existing functionality. Dan wasn't
worried about the naïveté, or the duplication of functionality. He
pointed out that it was more important to get *something* which could be
improved and that the duplication was okay given that the idea was to
get a standard framework in place and then eliminate the duplication. (I
admit that I'm a little surprised to hear Dan, who's normally a strong
advocate of up front design, preaching the refactorers creed...)
http://groups.google.com/groups?selm=rt-3.0.9-30245-904...@perl.org
Making PMCs
Nicholas Clark wondered how to go about making a PMC, pointing out that
the documentation is rather sparse. He had a bunch of questions for the
Men Who Know. Matt Fowles and Dan Sugalski came up with answers. Leo
wrote a document and checked it in as docs/pmc.pod. If you're interested
in implementing a PMC, you'd do well to read it.
http://groups.google.com/groups?selm=20040613100...@plum.flirble.org
Slices and iterators
Continuing his campaign to spec out more and more of Parrot, Dan set to
work on defining and documenting Parrot's handling of slices and
iterators. It appears that array slicing syntax is one of those topics
where you can't please everyone; Dan's post generated a good deal of
discussion.
Dan added more in a later post and, in later post still, threw up his
hands and asked for a volunteer to define the iterator protocol.
http://groups.google.com/groups?selm=a06110409bcf382d914cc@[10.0.1.3]
http://groups.google.com/groups?selm=a06110409bcf4cf7b179c@[172.24.18.98]
http://groups.google.com/groups?selm=a0611040bbcf4ecb9f27f@[172.24.18.98]
Iterator semantics
Having a syntax is all very well, but you need to define what it *means*
too. So Dan did.
http://groups.google.com/groups?selm=a0611040abcf38b01fe20@[10.0.1.3]
Some rationale for Parrot's mixed encoding scheme
Argh! Unicode! Run away!
Dan posted the rationale for his design for Parrot's strings, in
particular the decision to defer conversion of strings to Unicode.
Amazingly, there was no argument.
http://groups.google.com/groups?selm=a0611041bbcf3f6bd3ee8@[10.0.1.3]
Strings. Finally.
Dan posted "the official, 1.0, final version" of the Parrot Strings
document. Modulo a caveat about the use of 'grapheme' it looks like this
one might stick.
http://groups.google.com/groups?selm=a06110418bcf3bff76821@[10.0.1.3]
Strings internals
Having got a Strings spec that people seemed to agree on, Dan went on to
discuss how parrot's strings should work internally. He and Mark A
Biggar ironed out a few wrinkles.
http://groups.google.com/groups?selm=a06110403bcf61a2185f0@[10.0.1.3]
Fixing pbc2c.pl
Dan asked for volunteers to get build_tools/pbc2c.pl working and/or
write a test suite for it.
http://groups.google.com/groups?selm=a06110402bcf79fccdc91@[10.0.1.3]
PIO_unix_pipe
Leo's extended Parrot's "open" opcode to allow for opening a unix pipe
rather than simply a file. There were issues with passing arguments to
the the program being piped to/from, but Dan came up with a suggested
"backtick" opcode whose semantics were liked, but whose necessity and
name were called into question. Leo pointed out that the major credit
for the functionality belongs to Melvin Smith; Leo merely implemented a
means to get at the functionality from parrot code.
http://groups.google.com/groups?selm=200406071207...@thu8.leo.home
Teapots!
Nick Glencross wants us all to look at his shiny SDL teapots; the poor
man's wife is apparently underwhelmed, so let's all make with the "Wooo!
Well done that man!".
Simple trinary ops
Dan toyed with adding a couple of non-flowcontrol min/max ops along the
lines of
min $P1, $P2, $P2 # Sets $P1 to the lesser of $P2 and $P3
he noted that such ops would make some of the code he was generating
much simpler, but wasn't sure if that particular itch needed to be
scratched with a new op. He was rapidly convinced that it wasn't a good
idea (I wouldn't be surprised to discover that he was convinced of this
about 10 seconds after he hit the 'send' button for the thread's root
message).
Steve Fink attempted to resurrect the idea by proposing a single
"choose" operator, which looks rather neat, but is probably still
unnecessary.
http://groups.google.com/groups?selm=a06110404bcf6254d244e@[10.0.1.3]
Meanwhile, in perl6-language
Cawley's Corollary to Godwin's Law
Given enough time, any thread on perl6-language will end up arguing the
toss about Unicode operators.
Perl 6 will have Unicode operators. It will also have ASCII equivalents.
You're highly unlikely to convince Larry to change his mind on this.
IDs of subroutine wrappers should be objects
Ingo Blechschmidt made a convincing argument for making the subroutine
wrappers discussed in Apocalypse 6 into first class objects. (Well, I
was convinced.)
Later in the thread, Dan invoked "our Quantum Ninjas".
http://groups.google.com/groups?selm=2004060813081...@onion.perl.org
Simple grammar example
Aldo Calpini asked for assistance in coming up with a simple, yet
impressive, example of Perl 6 grammars. I'm not sure anyone's come up
with a suitably satisfactory example yet, but Garrett Goebel pointed out
that Damian has released Perl6::Rules. And there was much rejoicing
(well, in this summarizer's head there was).
http://groups.google.com/groups?selm=40C71BFD...@perl.it
http://search.cpan.org/~dconway/Perl6-Rules-0.03/Rules.pm
Messages are not guaranteed to arrive in the order sent
In a message dated 28th of January 2004, Damian Conway addressed the
issue of junctive lvalues.
http://groups.google.com/groups?selm=40171197...@conway.org
Apologies, Acknowledgements, Announcements
This summary would have been a great deal trickier to write it if
weren't for the efforts of Jeffrey Dik, Sebastian Riedel, Brent
Royal-Gorden and Robert Spier, all of whom helped me fill in my message
archive while my main server is away being fettled.
Apologies for the long URLs to those of you reading this in email; my
link shortening script is on the hard disk that's at the menders...
Computer menders and British Telecom willing, next week's summary will
actually happen. If it doesn't, I'll be along in a fortnight.
If you find these summaries useful or enjoyable, you can show your
appreciation by contributing to the Perl Foundataion to help support the
ongoing development of Perl. Money and time are both appreciated. Or you
could drop me a line at mailto:p6summ...@bofh.org.uk; I'm always
happy to get feedback.
http://donate.perlfoundation.org/ -- The Perl Foundation
Dan Sugalski
> Bignums!
> Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up
> to the plate. Leo suggested that, rather than starting from
> types/bignum.c, it might be better to use an existing, maintained, maths
> (Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will
> be a cold, cold day in hell when I start abbreviating 'mathematics' as
> 'math'. Ahem.) package. Dan worried about license compatibility; the
> proposed GMP package is licensed under the LGPL which may (or may not)
> be compatible with Parrots Artistic/GPL dual licence. After a closer
> reading he reckoned that GMP's license is definitely incompatible with
> Parrot.
>
> http://groups.google.com/groups?selm=a0611040bbcefb9fb77e6@[10.0.1.3]
The license issues there require that the full source of GMP ship with any
binary copy. (the license has no "provide a place to fetch it"
provision--the source is required) Which would make the Gameboy version
of Parrot somewhat cumbersome. :)
> Resizeable*Array classes
> Fresh from his Fixed Array triumph, Matt Fowles posted a patch
> implementing naïve Resizeable Arrays. Leo thought it a little too naïve,
> and worried about duplication of existing functionality. Dan wasn't
> worried about the naïveté, or the duplication of functionality. He
> pointed out that it was more important to get *something* which could be
> improved and that the duplication was okay given that the idea was to
> get a standard framework in place and then eliminate the duplication. (I
> admit that I'm a little surprised to hear Dan, who's normally a strong
> advocate of up front design, preaching the refactorers creed...)
Ah, but the design is already fixed. And I'm a big advocate of "I don't
care if it's implemented by the appropriate application of garden gnomes
so long as it works" school of thought. The code is close to irrelevant,
it's the architecture and API of a black box and the system that
box exists in that's important.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Scott Bronson
> The license issues there require that the full source of GMP ship with any
> binary copy. (the license has no "provide a place to fetch it"
> provision--the source is required) Which would make the Gameboy version
> of Parrot somewhat cumbersome. :)
Has anybody inquired to the GMP project as to the possibility of
relaxing that restriction? If GMP truly is the best bignum
implementation, I definitely think it's worth asking.
If nobody else is pursuing this then sure, I volunteer to subscribe to
some lists and try to find the people to ask. I'll wait for a "Yes"
from Dan or Leo before I run off trying to represent the Parrot project,
of course. :)
- Scott
Uri Guttman
SB> On Wed, 2004-06-23 at 08:12, Dan Sugalski wrote:
>> The license issues there require that the full source of GMP ship with any
>> binary copy. (the license has no "provide a place to fetch it"
>> provision--the source is required) Which would make the Gameboy version
>> of Parrot somewhat cumbersome. :)
SB> Has anybody inquired to the GMP project as to the possibility of
SB> relaxing that restriction? If GMP truly is the best bignum
SB> implementation, I definitely think it's worth asking.
SB> If nobody else is pursuing this then sure, I volunteer to subscribe to
SB> some lists and try to find the people to ask. I'll wait for a "Yes"
SB> from Dan or Leo before I run off trying to represent the Parrot project,
SB> of course. :)
i still have my stillborn bignum (using bcd registers and efficient
algorithms) implementation if anyone wants to pick it up. i have some
working base code and the overall design. it has features and stuff that
i don't see in the other packages. the main thing is that it uses bcd
all the way and numbers can be any scale and precision (effectively
including floating point since that is just a scaled number). numbers
can grow infinitely long if desired as well.
initialization (constructor) for ints and floats and add/subtract
work. more alignment support of registers is needed for that as well as
multiply/divide. i have all the rest of the design in my feverish brane
including various optimization tricks.
it currently uses c's malloc so that needs to be changed to use parrot's
malloc.
the reason for bcd is that it makes conversions to/from ascii (or
unicode, gack!) very easy and you get exact representations at any
precision and scale (including fractions). the algorithms are decent and
add/subtract work on binary words at a time and not individual bcd
digits.
i am willing to help out anyone who wants to take this on but i can't
lead it now. it would be a great way to learn some neat bcd math
tricks! :) these are classic ideas from the heyday of bcd math from the
60's.
the code is in pure c and of course since i wrote it i won't charge
parrot too much to licence it :)
this is about 700 lines of code including test code.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Leopold Toetsch
>>>>>>"SB" == Scott Bronson <bro...@rinspin.com> writes:
>
> SB> Has anybody inquired to the GMP project as to the possibility of
> SB> relaxing that restriction? If GMP truly is the best bignum
> SB> implementation, I definitely think it's worth asking.
Not AFAIK. Please try.
> i still have my stillborn bignum (using bcd registers and efficient
> algorithms) implementation if anyone wants to pick it up. i have some
> working base code and the overall design.
The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon
benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK.
We can always switch the internals, as long as we keep it consistent at
the surface.
> uri
leo
Uri Guttman
LT> Uri Guttman wrote:
>>>>>>> "SB" == Scott Bronson <bro...@rinspin.com> writes:
SB> Has anybody inquired to the GMP project as to the possibility
>> of
SB> relaxing that restriction? If GMP truly is the best bignum
SB> implementation, I definitely think it's worth asking.
LT> Not AFAIK. Please try.
>> i still have my stillborn bignum (using bcd registers and efficient
>> algorithms) implementation if anyone wants to pick it up. i have some
>> working base code and the overall design.
LT> The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon
LT> benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK.
LT> We can always switch the internals, as long as we keep it consistent
LT> at the surface.
sorry about the timing. and dan and i discussed the ability to swap the
lib later so that is how we should go with my lib. but it still needs
work so if anyone wants to get into parrot this way, let me know.
André pang
>> i still have my stillborn bignum (using bcd registers and efficient
>> algorithms) implementation if anyone wants to pick it up. i have some
>> working base code and the overall design.
>
> The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon
> benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK.
Is there a big problem with using GMP for the purposes of the demo?
And, what does Python use for arbitrary-precision integers? It only
seems fair to be using the same library as Python, if you want a decent
bignum speed comparison.
--
% Andre Pang : trust.in.love.to.save
Leopold Toetsch
> On 24/06/2004, at 6:31 PM, Leopold Toetsch wrote:
>> The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon
>> benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK.
> Is there a big problem with using GMP for the purposes of the demo?
I don't think that this should be a problem.
> And, what does Python use for arbitrary-precision integers?
They have their own lib (base 2^15 binary digits).
> ... It only
> seems fair to be using the same library as Python, if you want a decent
> bignum speed comparison.
Python::F<longobject.c> is not pluggable, it's full of Python internals.
leo
Jerome Quelin
> It only seems fair to be using the same library as Python, if you want
> a decent bignum speed comparison.
We don't mind being unfair, as long as parrot's winning :-)
Jerome
--
jqu...@mongueurs.net
Dan Sugalski
> On 24/06/2004, at 6:31 PM, Leopold Toetsch wrote:
>
> >> i still have my stillborn bignum (using bcd registers and efficient
> >> algorithms) implementation if anyone wants to pick it up. i have some
> >> working base code and the overall design.
> >
> > The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon
> > benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK.
>
> Is there a big problem with using GMP for the purposes of the demo?
Nope. Nor, if the freeze/thaw system is representation-neutral, as a
plugin option for parrot itself. There are just some license issues (or
I'm reading it wrong, which is an issue itself :) that make shipping GMP
with parrot problematic.
Leopold Toetsch
> Nope. Nor, if the freeze/thaw system is representation-neutral, as a
> plugin option for parrot itself. There are just some license issues (or
> I'm reading it wrong, which is an issue itself :) that make shipping GMP
> with parrot problematic.
Isn't it enough, whem we provide a link, where people can download GMP?
And, what about making GMP a prerequisit (in the case that GMP is
selected at configure time)?
> Dan
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>
>> Nope. Nor, if the freeze/thaw system is representation-neutral, as a
>> plugin option for parrot itself. There are just some license issues (or
>> I'm reading it wrong, which is an issue itself :) that make shipping GMP
>> with parrot problematic.
>
>Isn't it enough, whem we provide a link, where people can download GMP?
Not by my reading of the license, no.
>And, what about making GMP a prerequisit (in the case that GMP is
>selected at configure time)?
If they choose to use GMP at configure time, that's fine.
I think what's in our best interests is to ship as part of parrot a
basic bignum library that does what we need (which is nicely limited)
with the option to replace it with GMP if the person building parrot
wants to do so. Then it's just a matter of making sure we keep frozen
bignums cross-compatible and having a simple thunking layer to
translate our API to GMP's so parrot's source doesn't need to care
which is chosen.
--
Dan
--------------------------------------it's like this-------------------