Namespaces, again

[Tim]

Seems like the last major thread on namespace issues, especially
inter-language issues, was around October last year and didn't reach
any firm conclusions.

What's the current status?

Tim.

Test failures on OSX

[Tim]

Fresh (and first) checkout and build of parrot (#8075)
on a Mac running OSX 10.3 using the default perl v5.8.1-RC3 built for
darwin-thread-multi-2level.

Failed two tests. Are these known problems or should I dig deeper?

Tim.

t/pmc/config...NOK 2# Failed test (t/pmc/config.t at line 
37)
#  got: 'None'
# expected: '/Users/timbo/perl/parrot'
t/pmc/config...ok 3/3# Looks like you failed 1 tests of 3.   

t/dynclass/foo.ok
1/3 skipped: No BigInt Lib configured
t/dynclass/gdbmhashskipped
all skipped: No gdbm library available
t/dynclass/pybuiltin...ok
1/6 skipped: No BigInt Lib configured
t/dynclass/pyclass.ok
t/dynclass/pycomplex...ok
t/dynclass/pyfunc..ok
t/dynclass/pyint...ok 25/26# Failed test (t/dynclass/pyint.t at 
line 620)
#   '2147483647
# no bigint lib loaded
# '
# doesn't match '/^\d+
# -\d+
# PyLong/
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/dynclass/pyint_26.pir"' 
failed with exit code 1
# Looks like you failed 1 tests of 26.
t/dynclass/pyint...dubious   
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 26
Failed 1/26 tests, 96.15% okay
 ...
Failed TestStat Wstat Total Fail  Failed  List of Failed
---
t/dynclass/pyint.t1   256261   3.85%  26
t/pmc/config.t1   256 31  33.33%  2
3 tests and 74 subtests skipped.
Failed 2/151 test scripts, 98.68% okay. 2/2443 subtests failed, 99.92% okay.

Re: RFC 343 (v1) New Perl Mascot

[Tim Conrow]

Perl6 RFC Librarian wrote:
> =head1 TITLE
> 
> New Perl Mascot
> 
> =head1 ABSTRACT
> 
> Perl has no common symbol usable by the public at large to state to
> the world "I am a Perl Programmer, and D**n Proud Of It!"
> 
> =head1 DESCRIPTION
> 
> The symbol that would be commonly used for this is the Camel, of course,
> but that symbol has strict trademark restrictions, and is unsuitable for
> the purpose of identification. O'Reilly allows only its commercial
> friends and allies to use it, and any other use is strictly prohibited.
> This presumes in a way to commercialize the public face of the Perl
> language as an O'Reilly-owned commodity. No other symbol is currently
> recognized to symbolize Perl and its community.

I don't know trademark law, but it seems unlikely that O'Reilly can trademark
the concept of the camel, or all representations of the camel. Since the new
symbol would be used to promote [pP]erl, which is good for O'Reilly, perhaps
they would not object to the use of a sufficiently distinct rendering. (Has
anyone trademarked the Alpaca yet? :-)

Since perl developers don't conflict but in fact enhance O'Reilly's buisness,
I'm not sure I see why they'd object.

OT: What's the history of the camel? Does it predate O'Reilly's involvement?

--

-- Tim Conrow [EMAIL PROTECTED]   |

Re: A tentative list of vtable functions

[Tim Jenness]

On Mon, 2 Oct 2000, Jarkko Hietaniemi wrote:

> > Assuming that the perl parser generated IV SVs rather than NVs for
> > the 2 constants 2,3, then my scheme would handle this fine; the IV
> 
> It currently does so.
> 
> > version of add() would be called, and an IV SB would result.
> 
> "The IV version of add()"?  Beware of combinatorial explosion:
> addII, addIU, addUI, addUU, addIN, addNI, addNN, addblahbah
> 

PDL overcomes this by using PDL::PP to automatically generate all the
required function code from a simple signature. PDL has to automatically
deal with type conversions all the time.


-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC 125 (v2) Components in the Perl Core Should Have Well-Defined APIs and Behavior

[Tim Bunce]

On Tue, Oct 10, 2000 at 12:34:04PM +0200, Bart Schuller wrote:
> On Sun, Oct 01, 2000 at 03:01:18PM -0400, 'John Porter' wrote:
> > Thanks for the link, Peter.  I have now checked out Dia, and I'm not
> > enthusiastic about it.  It seems to be a good start, but maturity is
> > a long way off.  Not only that, but it is cumbersome (imho) to set up.
> > I still think I'd rather see a java or web-based solution.  
> 
> A very complete UML tool in Java is ArgoUML:
> 
> http://argouml.tigris.org/

Umm, it might be interesting for someone to add a Perl code generator
for it...

Tim.

Re: The external interface for the parser piece

[Tim Jenness]

On Mon, 27 Nov 2000, Dan Sugalski wrote:

> ---
> 
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
> 

> The third parameter is the flags parameter, and it's optional. If omitted 
> or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard 
> null-terminated string. If set to PERL_COUNTED_SOURCE, the second parameter 
> is treated as if it points to a stream of bytes, where the first four are 
> the length of the source to be read followed by the source. If set to 

Since you have a fourth argument couldn't that be used for the length
of the byte stream rather than embedding that length into the byte stream
itself? Makes more sense to me to separate the bytes from the length.


-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: The external interface for the parser piece

[Tim Bunce]

On Thu, Nov 30, 2000 at 04:15:24PM +, Nick Ing-Simmons wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> >
> >We're trying to make this an easy embedding API.
> 
> Yes, and we are in danger of "premature optimization" of the _interface_.  

Amen.

Tim.

Re: Proposal for groups

[Tim Bunce]

On Tue, Dec 05, 2000 at 09:20:29AM +, Simon Cozens wrote:
> On Tue, Dec 05, 2000 at 09:16:23AM +, Alan Burlison wrote:
> > I still think that with the correct
> > DTD writing the specs in XML would be doable.
>  
> DocBook strikes me as being made for this sort of thing.

As someone who had the option of writing a book in DocBook or POD
I can tell you that it simply would not have happened in DocBook.
My co-author had used DocBook for a previous book and would rather
have his hands cut off than use it again. Having looked at it myself
I had to agree with him. Nice in theory. Good for an internal format
perhaps. But to author docs in it? No way.

I'd like to see pod improved in some small but significant ways.

I also remember saying a couple of years ago that I thought all the
pod-to-foo translators should be built on top of a small fast
pod-to-xml translator implemented in C/XS. XML would then be
doing what it's good at and very appropriate for.

But this isn't what we're here to design...

Tim.

Re: standard representations

[Tim Jenness]

On Tue, 2 Jan 2001, Dan Sugalski wrote:

> At 12:34 PM 1/2/01 -0500, Andy Dougherty wrote:
> >If you want to experiment with modifying perl5's bigints and bigfloats
> >with a tuned library to get an idea of how much speed we're talking about,
> >gmp is probably the best bet to get a good estimate with the least amount
> >of effort (though it doesn't look as if it's been ported to VMS, and it
> >didn't build for me under Solaris 8 when I just tested it ...). If you
> >want to redistribute the code, of course, then you need to think about
> >licensing issues.
>
> I think gmp/fgmp is probably the best place to start, if I can get the fgmp
> code building with enough abuse. It ought to be simple enough, and we'll
> need to smack it around some for perl's memory management anyway.

Math::GMP is on CPAN already. It does operator overloading.


-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: Support for interactive interpreters...

[Tim Jenness]

On Wed, 17 Jan 2001, Branden wrote:

> I'm actually not following this list from close and I searching the archives
> isn't that easy yet, so pardon me if this was already brought up.
>
> I work with Perl and I also work with Tcl, and one thing I actually like
> about Tcl is that it's interactive like a shell, i.e. it gives you a prompt,
> where you type commands in and, if you type a whole command by the end of
> the line, it executes it, otherwise, it gives you another prompt and keeps
> reading more lines until the whole command is typed, when it's executed. I
> think this is particularly useful for:
> a) testing features (what the value of ... would be if I ...?)

This may not sound obvious but I use the Perl Data Language (PDL) for
interactive testing since it provides a shell interface. It's not perfect
(needs to be extended to handle multi-line input) but it's a start.

Both Python and Tcl support features like this and I agree that a perl
shell would be useful.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: Thought for the day

[Tim Bunce]

On Wed, Jan 31, 2001 at 05:55:13PM +, Simon Cozens wrote:
>Never over-design. Never think "Hmm, maybe somebody would find this
>useful". Start from what you know people _have_ to have, and try to
>make that set smaller. When you can make it no smaller, you've reached
>one point. That's a good point to start from - use that for some real
>implementation.
> 
> - Linus Torvalds

Since this thread is in the mood for quotes, here's one I'm fond of...
It goes something along the lines of:

Any fool can create a complicated system.
The real skill is in making a simple one.

I honestly don't know where that came from. (I might even have
originated it myself, but I'm sure someone will come up with the real
source. If not maybe I'll claim it for my own :-)

Tim.

Re: Really auto autoloaded modules

[Tim Bunce]

On Thu, Feb 01, 2001 at 04:02:31PM +, Tim Bunce wrote:
> of the Foo interface (one SX and one pure-perl, for example).

s/SX/XS/ of course.

Tim.

Re: Really auto autoloaded modules

[Tim Bunce]

On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> Since everyone's spinning aimlessly around, I'll throw out something for 
> everyone to think about, and perhaps we can get a PDD out of it.
> 
> One of the features of perl 6 is going to be the ability to automatically 
> use a module if one or more preregistered functions are used in your 
> source. So, for example, if we pull out the socket routines into a separate 
> module but your code uses one of the socket routines, we automagically use 
> the socket module. The fact that it's separate is completely invisible to 
> your program. The module loaded can define the routines as either regular 
> perl subs or opcode functions (the difference is in calling convention 
> mainly) and could be the standard mix of perl or compiled code.
> 
> Would someone care to take a shot at formalizing the system? We need a way 
> to register these functions, track the module version (if any) they're in, 
> and stuff like that. (Including, I'm sure, things I've forgotten)

Don't forget that it should tie in with the concept of defining
'interfaces' so

use Foo qw(bar);

may actually just load an interface definition and that definition
can be (lazily) bound to one of several alternative implementations
of the Foo interface (one SX and one pure-perl, for example).

Basically I'm saying that transparent autoloading should be an
attribute of the interface definition.

Tim.

Re: Really auto autoloaded modules

[Tim Bunce]

On Fri, Feb 02, 2001 at 11:47:43AM -0500, John Porter wrote:
> And isn't this rather off-topic for this list?
> Sounds more like an internals thing...

No. I think this is an area where the language should lead.

I also think we need to define what an 'interface definition' should
look like and/or define before we go much further.

Tim.

Re: Really auto autoloaded modules

[Tim Bunce]

On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote:
> At 02:17 PM 2/5/2001 -0200, Branden wrote:
> > > I think that, if you want this behavior, a module that implements it
> > > would be just fine.  (Why muck with "use"?)  To use a module name
> > > that seems like it could fit this purpose:
> > >
> > > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
> > >  { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
> >2 };
> >
> >Very good idea indeed!!! Append the wishlist to add this module to perl6's
> >standard library!!!
> 
> Very *bad* idea. It sounds nice, but using a remote module without any sort 
> of control is just begging for trouble.

True. But perl6 shouldn't stand in the way of making silly things possible.

Tim.

Re: PDD 2, vtables

[Tim Bunce]

[First off: I've not really been paying attention so forgive me if I'm
being dumb here.  And many thanks for helping to drive this forwards.]

On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> 
> =head2 Core datatypes
> 
> For ease of use, we define the following semi-abstract data types

Probably worth stating upfront that it'll be easy to add new types
to avoid people argusing for their favorite type to be added here.

> =item INT
> =item NUM
> =item STR
> =item BOOL

What about references?

Arrays and hashes should probably be at least mentioned here.

> =head3 String data types
> 
> =item binary buffer

'Binary string'

> =item UTF-32 string
> =item Native string
> =item Foreign string

I'm a little surprised not to see UTF-8 there, but since I'm also
confused about what Native string and Foreign string are I'll skip it.
Except to say that some clarification here may help, and explicitly
mentioning UTF-8 (even to say it won't be a core type and provide a
reference to why) would be good.


> The functions are divided into two broad categories, those that perl
> will use the value of internally (for example the type functions) and
> those that produce or modify a PMC, such as the add function.

So possibly a good idea to explicitly group them that way.

> =head2 Functions in detail
> 
> =item type
> 
> =item name
> 
>STRname(PMC[, key]);
> 
> Returns the name of the class the PMC belongs to.

So I'd call it type_name (or maybe class_name as you seem to be useing
the words interchangably. If type != class then clarify somewhere.).

> =item move_to
> 
>BOOL   move_to(void *, PMC);
> 
> Tells the PMC to move its contents to a block of memory starting at
> the passed address. Used by the garbage collector to compact memory,
> this call can return a false value if the move can't be done for some
> reason. The pointer is guaranteed to point to a chunk of memory at
> least as large as that returned by the C vtable function.

Shouldn't the PMC be the first arg for consistency?

> =item real_size
> 
>IV real_size(PMC[, key]);
> 
> Returns an integer value that represents the real size of the data
> portion, excluding the vtable, of the PMC.

Contiguous? Sum of parts (allowing for allignment) if it contains
multiple chunks of data?

> =item destroy
> 
>void   destroy(PMC[, key]);
> 
> Destroys the variable the PMC represents, leaving it undef.

Using the word 'variable' here probably isn't a good idea.
Maybe "Destroys the contents of the PMC leaving it undef."

> =item is_same
> 
>BOOL   is_same(PMC1, PMC2[, key]);
> 
> Returns TRUE if C and C refer to the same value, and FALSE
> otherwise.

I think that needs more clarification, especially where they are of
different types. Contrast with is_equal() below.

> =item concatenate
> 
>void   concatenate(PMC1, PMC2, PMC3[, key]); ##
> 
> Concatenates the strings in C and C, storing the result in
> C.

and insert (ala sv_insert)  etc?

> =item is_equal

Contrast with is_same() above.

> =item logical_or
> =item logical_and
> =item logical_not

Er, why not just use get_bool? The only reason I can think of is to
support three-value-logic but that would probably be better handled
via a higher-level overloading kind of mechanism. Either way, clarify.

> =item match
> 
>void   match(PMC1, PMC2, REGEX[, key]);
> 
> Performs a regular expression match on C against the expression
> C, placing the results in C.

Results, plural => container => array or hash. Needs clarifying.

> =item repeat (x)
> 
>void   repeat(PMC1, PMC2, PMC3[, key]); ##
> 
> Performs the following sequence of operations: finds the string value
> from C; finds an integer value I from C; replicates the
> string I times; stores the resulting string in C.

So call it replicate? Could also work for arrays.

> =item nextkey (x)
> 
>void   nextkey(PMC1, PMC2, start_key[, key]);
> 
> Looks up the key C in C and then stores the key after
> it in C. If start_key is C, the first key is returned,
> and C is set to undef if there is no next key.

Containers again.  And I'd call it key_next()

> =item exists (x)

Likewise, key_exists()

> =head1 TODO
> 
> The effects of each function on scalar, array, hash, list, and IO
> PMCs needs to be hashed out.

Before that I think a section on containers need to be added.

> =head1 REFERENCES
> 
> PDD 3: Perl's Internal Data Types.

Some references to any other vtable based languages would be good.
(I presume people have looked at some and learnt lessons.)

Tim.

Re: PDD 2, vtables

[Tim Bunce]

On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> At 11:26 AM 2/6/2001 +0000, Tim Bunce wrote:
> >[First off: I've not really been paying attention so forgive me if I'm
> >being dumb here.  And many thanks for helping to drive this forwards.]
> >
> >On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> > >
> > > =head2 Core datatypes
> > >
> > > For ease of use, we define the following semi-abstract data types
> >
> >Probably worth stating upfront that it'll be easy to add new types
> >to avoid people argusing for their favorite type to be added here.
> 
> I'm not sure it should be--that'd mean extending the vtables in ways they 
> have little room to grow. Adding new perl datatypes is easy, adding new 
> low-level types is harder.

That's pretty much what I meant. I think it's worth saying.

> > > =item INT
> > > =item NUM
> > > =item STR
> > > =item BOOL
> >
> >What about references?
> 
> Special type of scalar, not dealt with here.

But should be at least mentioned.

> > > =item UTF-32 string
> > > =item Native string
> > > =item Foreign string
> >
> >I'm a little surprised not to see UTF-8 there, but since I'm also
> >confused about what Native string and Foreign string are I'll skip it.
> >Except to say that some clarification here may help, and explicitly
> >mentioning UTF-8 (even to say it won't be a core type and provide a
> >reference to why) would be good.
> 
> I didn't put UTF-8 in on purpose, because I'd just as soon not deal with it 
> internally. Variable length character data's a pain in the butt, and if we 
> can avoid having the internals deal with it except as a source that gets 
> converted to UTF-32, that's fine with me.

I agree with Branden that a default 4x memory bloat would not be popular.

> The native and foreign string data types were an attempt to accommodate 
> UTF-8, as well as ASCII and EBCDIC character data. One of the three will 
> likely be the native type, and the rest will be foreign strings. I'm not 
> sure if perl should have only one foreign string type, or if we should have 
> a type tag along with the other bits for strings.

Umm, one way or another I suspect UTF-8 will be in there.

> > > =item is_same
> > >
> > >BOOL   is_same(PMC1, PMC2[, key]);
> > >
> > > Returns TRUE if C and C refer to the same value, and FALSE
> > > otherwise.
> >
> >I think that needs more clarification, especially where they are of
> >different types. Contrast with is_equal() below.
> 
> If they're different types they can't be the same. This would be used to 
> check if two references have the same referent, or if two magic variables 
> (database handles, say) pointed to the same thing.

Okay, so say so in the PPD. "refer to the same value" isn't very clear
(the word value is probably the problem).

> > > =item concatenate
> > >
> > >void   concatenate(PMC1, PMC2, PMC3[, key]); ##
> > >
> > > Concatenates the strings in C and C, storing the result in
> > > C.
> >
> >and insert (ala sv_insert)  etc?
> 
> Hadn't considered them. Care to elaborate on the etc?

Er, I haven't looked at sv.c for ages but basically all the kinds of
string manipulations that ended up in there for good reason will
probably need to be in perl6. sv_insert is a good example (and possibly
the only one :-)

> > > =item logical_or
> > > =item logical_and
> > > =item logical_not
> >
> >Er, why not just use get_bool? The only reason I can think of is to
> >support three-value-logic but that would probably be better handled
> >via a higher-level overloading kind of mechanism. Either way, clarify.
> 
> Well, there's overloading. Plus the potential that a class will do 
> something odd with it--if you || on two custom arrays in list context you 
> might get an array with each pair (left[0] || right [0] and so on) 
> logically or'd.

Okay, don't forget xor then :)

> > > =item match
> > >
> > >void   match(PMC1, PMC2, REGEX[, key]);
> > >
> > > Performs a regular expression match on C against the expression
> > > C, placing the results in C.
> >
> >Results, plural => container => array or hash. Needs clarifying.
> 
> Yep, especially since I'd considered tossing the match destination 
> entirely. (Though that means special variables, and I'm not sure I want to 
> go there) It'll likely just return true or false. I'll rethink it.

A BOOL return would be good. But "placing the results in C" is
also good (assuming 'results' are equiv to $1, $2 etc in perl5).

> > > =head1 REFERENCES
> > >
> > > PDD 3: Perl's Internal Data Types.
> >
> >Some references to any other vtable based languages would be good.
> >(I presume people have looked at some and learnt lessons.)
> 
> Alas not. This is pretty much head of zeus stuff, modulo some ego. (Mine's 
> not *that* big...)

:-)

Without studying history we may be doomed to repeat it.

So can anyone point to vtable based language implementations?

Tim.

Re: PDD 2, vtables

[Tim Bunce]

On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
> 
> >On the other side, for a string that is matched against regexps, it doesn't
> >matter much if it has variable character length, since regexps normally read
> >all the string anyway, and indexing characters isn't much of a concern.
> 
> You underestimate the impact of variable-length data, I think. Regexes 
> should go rather faster on fixed-length than variable length data. How much 
> so depends on your processor. (I can guarantee that Alphas will run a 
> darned sight faster on UTF-32 than UTF-8...)

Umm, don't cpu data cache size issues complicate that? What if the ~4x
bigger UTF-32 string doesn't fit in the cache but the UTF-8 one does?
(I'm obviously simplifying somewhere here, but you get the idea.)

Tim.

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

[Tim Bunce]

On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> Hong Zhang
> > > A deterministic finalization means we shouldn't need to force
> programmers
> > > to have good ideas. Make it easy, remember? :)
> >
> > I don't believe such an algorithm exists, unless you stick with reference
> > count.
> 
> Either doesn't exist, or is more expensive than refcounting. I guess we have
> to make a decision between deterministic finalization and not using
> refcounting as GC, because both together sure don't exist.
> 
> And don't forget that if we stick with refcounting, we should try to find a
> way to break circular references, too.

As a part of that the weak reference concept, bolted recently into perl5,
could be made more central in perl6.

Around 92.769% of the time circular references are known to be circular
by the code that creates them (like a 'handy' ref back to a parent node).
Having a weakref, or similar, operator in the language would help greatly.

Tim.

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

[Tim Bunce]

On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
> >>>>> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
> 
>   TB> As a part of that the weak reference concept, bolted recently into
>   TB> perl5, could be made more central in perl6.
> 
>   TB> Around 92.769% of the time circular references are known to be
>   TB> circular by the code that creates them (like a 'handy' ref back to
>   TB> a parent node).  Having a weakref, or similar, operator in the
>   TB> language would help greatly.
> 
> i second this. i am doing just what tim mentions. i have a child and
> parent object referring back to each other for callback purposes. the
> parent needs to own the child and the child has to have a parent ref to
> make a method callback in the parent. there is no way out of creating
> circular refs in that situation. i have to do an explicit object
> shutdown so i don't leak ram. this isn't a big problem in stem since you
> have to explicitly unregister stuff as well (that can't be done with
> scope exit) but it would still be nice not to have to worry about the
> ref loops.

So why not use the WeakRef module (or whatever it's called)?

Tim.

Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test

[Tim Bunce]

On Mon, Feb 19, 2001 at 09:03:00AM -0600, Jarkko Hietaniemi wrote:
> On Mon, Feb 19, 2001 at 04:01:25PM +0100, H.Merijn Brand wrote:
> > On Mon, 19 Feb 2001 08:49:04 -0600, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > > On Mon, Feb 19, 2001 at 03:47:12PM +0100, Johan Vromans wrote:
> > > > As an active non-smoker, I'd appreciate a different name.
> > > 
> > > Likewise.  What's wrong with builders?
> > 
> > Same here. Testers?
> 
> perl-builders?

Or to be more whimsical:

perl-night-shift
perl-night-build

It probably needs a name that'll both indicate its role and avoid confusion
with 'porters' (who do most of the 'building' to the untrained eye).

Tim.

Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test

[Tim Bunce]

On Mon, Feb 19, 2001 at 10:50:04AM -0500, Chris Nandor wrote:
> At 15:45 + 2001.02.19, Tim Bunce wrote:
> >On Mon, Feb 19, 2001 at 09:03:00AM -0600, Jarkko Hietaniemi wrote:
> >> On Mon, Feb 19, 2001 at 04:01:25PM +0100, H.Merijn Brand wrote:
> >> > On Mon, 19 Feb 2001 08:49:04 -0600, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> >> > > On Mon, Feb 19, 2001 at 03:47:12PM +0100, Johan Vromans wrote:
> >> > > > As an active non-smoker, I'd appreciate a different name.
> >> > >
> >> > > Likewise.  What's wrong with builders?
> >> >
> >> > Same here. Testers?
> >>
> >> perl-builders?
> >
> >Or to be more whimsical:
> >
> > perl-night-shift
> > perl-night-build
> >
> >It probably needs a name that'll both indicate its role and avoid confusion
> >with 'porters' (who do most of the 'building' to the untrained eye).
> 
> I dunno; I dislike smoking, but I like the idea of "smoking-camels" or
> something.  :)

Umm, I recall something from my geography lessons about nomadic tribes
smoking camel dung. I can't remember now if it was on the fire or in
the mouth (yeach). Anyway...

perl-dung
perl-droppings

Umm, maybe not. Er...

perl-smoke-trail  (thinking of the night-by-night progress, kind'a)

I dunno. I'm off...

Tim.

Re: Larry's Apocalypse 1

[Tim Bunce]

On Mon, Apr 09, 2001 at 12:58:23PM -0400, Andy Dougherty wrote:
> 
> Let's leave -e alone for now and worry about handling specific
> incompatibilities when we in fact have some specific incompatibilities to
> worry about.

Amen.

Tim.

Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)

[Tim Bunce]

On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote:
> I don't get it.
> 
> The first and foremost duty of Perl 6 is to parse and execute Perl 6.
> If it doesn't, it's not Perl 6.  I will call this the Prime Directive.

Great, but don't loose sight of the fact that a key feature of "Perl 6",
as far as Larry's sketched it out, is the ability to dynamically alter
the parser in both dramatic and subtle ways.

Following your lead, I will call this the Prime Language Feature :)

> People seem to think that telling Perl 5 apart from Perl 6 is trivial.

My reading of Larry's comments is that it will be _made_ trivial at the
file scope level. If the file doesn't start with Perl 6 thingy then
it's Perl 5. Period.

> Truly detecting Perl5ness is hard: you will have to in essence
> replicate the Perl 5 parsing, and we all know the amount of hair
> in that code.  We really want to include such a hairball in our
> new beautiful code?

My reading of Larry's comments is that it won't be "in" our ``new
beautiful code''?   [Umm, pride before a fall?]

That beautiful code will be beautifully _open_ to _external_ extensions.
And that is how I imagine that Perl 5 support should be implemented.
The parser is, ooops, the parsers are (plural) going to be in perl, remember.

> Thinking about the 5->6 migration and coexistence is good and useful,
> but since that doesn't advance the Prime Directive,

I disagree.

> thinking about it *too* much now or fighting over the niggly details
> is somewhat wasted effort.

Now this I agree with. It's quite staggering how much hot air has been
generated from Larry's first significant outline. Much of it missing,
or casually disregarding, key points of deep or subtle meaning.

I'm reminded of the long threads about bignum support that seemed to
be lost in the details of _a_ bignum implementation rather than
focusing on the design of a generic type extension mechanism that would
then enable multiple bignum implementations to coexist.

Tim.

Re: Flexible parsing (was Tying & Overloading)

[Tim Bunce]

On Sat, Apr 28, 2001 at 03:44:25PM -0700, Larry Wall wrote:
> Dan Sugalski writes:
> : I hadn't really considered having a separate module for each type of site 
> : policy decision.
> 
> Er, neither had I.  Each site only has one policy file.  I just want it
> named after the actual site, not some generic name like "Policy".  I
> think policy files are inherently non-portable, so they should be named
> that way.

FYI, the module list has said this for several years:

: If developing modules for private internal or project specific use,
: that will never be released to the public, then you should ensure that
: their names will not clash with any future public module. You can do
: this either by using the reserved Local::* category or by using an
: underscore in the top level name like Foo_Corp::*.

Tim.

Re: Multi-dimensional arrays and relational db data

[Tim Jenness]

On Sun, 10 Jun 2001, Sam Tregar wrote:

> On Sun, 10 Jun 2001, Me wrote:
>
> > Agreed. So long as you are talking about Perl 5's arrays.
> >
> > I disagree, if you are talking about 2 dimensional structures.
>
> You appear to have some fundamental misunderstanding about Perl 5.  Perl 5
> does indeed support multidimentional arrays:
>
>my @matrix = ( [ 1 2 3 ]
>   [ 4 5 6 ]
>   [ 7 8 9 ] );
>print $matrix[1][2];
>
> You could easily use either "tie" or the new "->[]"  overloading in Perl 5
> to access relational databases in Perl 5.  Are you going to make me show
> you an example before you believe me?
>

At the risk of receiving a flame perl5 does not have multi-dimensional
arrays. It has something that will do the job with a massive memory
overhead ands lots of pain when dimensionality is high. If it had true
support for N-dim arrays then PDL would never have been invented. The main
problem PDL has is that Perl does not have a syntax for N-dim slices so it
has to bolt something on the side by specifying a slice as a string. (see
eg PDL::Slices). Numerical applications will get a significant boost if
N-dim arrays with native slicing are possible in perl6.

-- 
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj

Re: Perl 6 modules plan

[Tim Bunce]

On Sat, Aug 11, 2001 at 02:31:47PM -0400, Kirrily Robert wrote:
> Ask wrote:
> >On Thu, 9 Aug 2001, Kirrily Robert wrote:
> >
> >[...]
> >> =head2 The role of CPAN
> >>
> >> Will CPAN's role remain unchanged?  Will there be a separate space for
> >> Perl 6 modules (6PAN)?
> >>
> >> If we do want to make changes to CPAN then Perl 6 gives us an
> >> opportunity for a "flag day" if we need one.  OK, not an actually flag
> >> *day*, but at least a point where we can say "Things are different for
> >> Perl 6" and to hell with backwards compatibility ;)

No. Larry has said quite clearly that backwards compatibility is very important.
There will be no flag day.

> >Eh, that doesn't sound like something we want to do for quite a few
> >years.
> 
> What makes you say that?  I can imagine a number of scenarios in which
> we decide to do things differently for Perl 6, which could mean that
> lots of Perl 5 modules don't come across cleanly and must be rewritten.

If it's "must" then Perl 6 has not met it's self-declared goals. I doubt
very much that'll happen.

> One very simple example is if we required each module to have $VERSION.

There will be ways round that, and most if not all other issues.

Tim.

Re: Perl 6 modules plan

[Tim Bunce]

On Mon, Aug 13, 2001 at 10:45:27AM +0100, Graham Barr wrote:
> On Sat, Aug 11, 2001 at 07:20:11PM -0400, [EMAIL PROTECTED] wrote:
> > On Sat, Aug 11, 2001 at 02:16:49PM -0500, Jarkko Hietaniemi wrote:
> > > One silliness is that the implementation "style" of the module
> > > seems to creep to the naming:
> > > 
> > > (1) Foo vs Foo_XS
> > 
> > Well then, how do you name it?  For example, Text::CSV.  There's a
> > pure perl implementation and an XS implementation.  If they're both in
> > the same tarball, it should probably be Text::CVS::Perl and
> > Text::CVS::XS with Text::CSV acting as a little wrapper to choose
> > which one.  Simple enough.
> 
> Why do they need to be named differently ? Only one will be installed.
> 
> I did this with the Scalar-List-Utils distribution. It contained both
> a perl implementation and an XS implementation. But decided which to
> install at build time.

The XS version of Data::Dumper has slightly less functionality, sadly.

Tim.

Re: Perl 6 modules plan

[Tim Bunce]

On Mon, Aug 13, 2001 at 10:02:29AM -0500, Jarkko Hietaniemi wrote:
> On Mon, Aug 13, 2001 at 09:46:13AM -0500, Garrett Goebel wrote:
> > From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]]
> > > 
> > > Remember, the goal for Perl 6 is to allow several modules sharing
> > > the same name.
> > 
> > Don't you mean several modules sharing a common named interface?
> 
> For now, module name.
> 
> There is no spec for our mythical 'interfaces' yet so it's quite
> pointless to state much anything about them.

Other than that they are a desirable goal that Larry's thinking about.

But I'd expect a names interface mechanism to be layered on top of the
underlying name + author + version mechanism anyway.

Tim.

Re: musings: write some perl ops in perl

[Tim Bunce]

Larry's already said (from memory) that the distinction between ops and
subs should be minimized or eliminated.

That, together with the desire to keep parrot fairly language netural,
leads naturally to having 'heavy' ops actually be be subs.

Tim.

On Fri, Aug 17, 2001 at 06:02:44PM -0400, Uri Guttman wrote:
> 
> i was musing about the parrot last night and came up with an idea. what
> about writing some of the perl ops in perl itself (or in hand coded
> parrot assembler)? the origin of this, of course, is gnu emacs where
> many of the common functions are written in lisp and not c. now i fully
> expect most of the parrot ops will be written in c for speed. but some
> ops are not known for speed and may be harder to write properly in c
> than in perl. in particular the do/require/use ops spend most of their
> time doing i/o and calling eval. but they do some other stuff like
> searching @INC, updating %INC, etc. all of that can be easily coded in
> perl but would be a pain to do in c even with a better internal api. the
> slower speed won't matter since much of the work is i/o and eval and
> only the side stuff will actually be done with perl ops. the eval op
> will be in c (or actually perl will do the parsing).
> 
> also parrot and perl will have ops for handling i/o so why have the
> internals use a special API to do that. we can write the i/o parts of
> those file ops in perl/parrot and simplify the i/o and its api. this is
> even more true with the idea of async file i/o in the internals. by
> isolating that to ops, it becomes easier to integrate and to support
> various platforms. we only have to write async i/o code for a parrot op
> api and then let the rest of perl use it.
> 
> just another musing,
> 
> uri
> 
> -- 
> Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
> SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
> Search or Offer Perl Jobs  --  http://jobs.perl.org

Re: Math functions? (Particularly transcendental ones)

[Tim Conrow]

>Okay, I'm whipping together the "fancy math" section of the interpreter 
>assembley language. I've got:
> ...
>Can anyone think of things I've forgotten? It's been a while since I've 
>done numeric work.

HP calculators sometimes define 

lnp1(x)  = ln(1 + x) 
expm1(x) = exp(x) - 1 

to deal accurately and quickly with the special case where x<<1. This may not be
useful in an environment of pseudo-infinite precision, unless speed begins to
matter alot. Maybe they could be called automagically when the compiler sees
something like the RHS of the above as an optimization.

--

-- Tim Conrow [EMAIL PROTECTED]   |

ncidef2pasm - generate PIR?

[Tim Bunce]

In runtime/parrot/library/ I see

ncurses.declarations
ncurses.pasm
ncurses.pbc
ncurses.pir

and I see tools/utils/ncidef2pasm.pl that'll convert
ncurses.declarations into ncurses.pasm.

But where did ncurses.pir come from? (Originally ncurses.imc?)

ncidef2pasm.pl can't generate pir, though I see that being suggested
by chromatic in http://www.nntp.perl.org/group/perl.perl6.internals/21353

Was it written by hand, or is there some utility I'm missing?

Tim.

NCI 'v' vs '' in function parameter signatures

[Tim Bunce]

What's the difference between 'v' and '' for NCI function parameters?

Here, for example, is the code for 'fv' and 'f':

  static void
  pcf_f_v(Interp *interpreter, PMC *self)
  {
  typedef float (*func_t)(void);
  func_t pointer;
  struct call_state st;
  float return_data;
  Parrot_init_arg_nci(interpreter, &st, "v");
  pointer =  (func_t)D2FPTR(PMC_struct_val(self));
  return_data =  (float)(*pointer)();
  set_nci_N(interpreter, &st, return_data);
  }

  static void
  pcf_f(Interp *interpreter, PMC *self)
  {   
  float (*pointer)(void);
  float return_data;
  struct call_state st;
  pointer =  (float (*)(void))D2FPTR(PMC_struct_val(self));
  return_data =  (float)(*pointer)();
  set_nci_N(interpreter, &st, return_data);
  }

The code is a little different but it's not clear (to me) if there's any
practical difference.

I ask because both 'fv' and 'f' are in src/call_list.txt
In fact there are several 'duplicated' signatures:

  Ignored signature 'cv' on line 52 (previously seen on line 49)
  Ignored signature 'dv' on line 58 (previously seen on line 54)
  Ignored signature 'fv' on line 85 (previously seen on line 82)
  Ignored signature 'iv' on line 150 (previously seen on line 87)
  Ignored signature 'lv' on line 162 (previously seen on line 155)
  Ignored signature 'pv' on line 187 (previously seen on line 170)
  Ignored signature 'sv' on line 190 (previously seen on line 189)
  Ignored signature 'tv' on line 202 (previously seen on line 192)
  Ignored signature 'vv' on line 217 (previously seen on line 204)

Those warnings come from a version of tools/build/nativecall.pl I've
modified to 'normalize' the signatures to use 'v' and detect duplicates.
(As a side effect the nci.o file dropped from 354K to 347K.)

Also, what's the protocol for adding signatures to call_list.txt?
I've at least one I want to add ('p itl' for mysql_real_connect)
and may have more soon. Should I just post a patch here?

Tim.

Re: NCI 'v' vs '' in function parameter signatures

[Tim Bunce]

On Tue, Feb 14, 2006 at 02:48:41PM +0100, Leopold Toetsch wrote:
> Tim Bunce wrote:
> >What's the difference between 'v' and '' for NCI function parameters?
> 
> There isn't any, except the extra 'v' char.
> 
> >I ask because both 'fv' and 'f' are in src/call_list.txt
> 
> Yeah.
> 
> >In fact there are several 'duplicated' signatures:
> 
> [ ... ]
> 
> I'd say, we should drop all the '?v' variants. The extra 'v' doesn't 
> cover any information, it's just causing an init call to the argument 
> passing code.
> 
> >Those warnings come from a version of tools/build/nativecall.pl I've
> >modified to 'normalize' the signatures to use 'v' and detect duplicates.
> >(As a side effect the nci.o file dropped from 354K to 347K.)
> 
> Good. But as said, I'd prefer the shorter signature.
> 
> >Also, what's the protocol for adding signatures to call_list.txt?
> >I've at least one I want to add ('p itl' for mysql_real_connect)
> >and may have more soon. Should I just post a patch here?
> 
> Yep.
> 
> >Tim.
> 
> Thanks for looking into this,

I'll aim to work up a patch this week.

The runtime dlfunc code will need to be altered to normalize away the
trailing v so old code won't break. Should it warn about that?

Tim.

Rare failure of t/dynoplibs/myops alarm sequence

[Tim Bunce]

FYI I saw this once but haven't been able to repeat it:

t/dynoplibs/myopsok 6/7  
# Failed test (t/dynoplibs/myops.t at line 107)
#  got: '1
# alarm1
# 2
# alarm2
# 3
# alarm3
# alarm1
# alarm3
# alarm3
# 4
# alarm3
# alarm3
# 5
# done.
t/dynoplibs/myopsNOK 7# '
# expected: '1
# alarm1
# 2
# alarm2
# 3
# alarm3
# alarm1
# alarm3
# 4
# alarm3
# alarm3
# alarm3
# 5
# done.
# '
# Looks like you failed 1 test of 7.
t/dynoplibs/myopsdubious 
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 7
Failed 1/7 tests, 85.71% okay

Tim [using r11741]

Re: NCI 'v' vs '' in function parameter signatures

[Tim Bunce]

On Tue, Feb 14, 2006 at 10:04:59PM +0100, Leopold Toetsch wrote:
> On Feb 14, 2006, at 18:29, Tim Bunce wrote:
> 
> >The runtime dlfunc code will need to be altered to normalize away the
> >trailing v so old code won't break. Should it warn about that?
> 
> Yes, a warning please.

Here's the patch.

 - removes 'v' argument entries from src/call_list.txt
 - adds mysqlclient signatures to src/call_list.txt [*]
 - tweaks docs/pdds/clip/pdd16_native_call.pod to match
 - adds list of definition files used into generated nci.c
 - adds sanity checking of return and argument sig chars
 - adds compile time warning for deprecated 'v' argument
 - adds optional duplicate signature warning (disabled)
 - adds runtime warning for deprecated 'v' argument

Tim.

[*] I'm planning a followup patch that splits src/call_list.txt
into multiple files in a subdirectory. The mysqlclient defs would then
be in their own file. With the current arrangement no one can safely
remove a signature because there's no indication of what that signature
exists for.

The same ncidef file could then be used for both tools/build/nativecall.pl
and tools/util/ncidef2pasm.pl (which I also plan to work on).

Any objections or comments?
Index: src/call_list.txt
===
--- src/call_list.txt   (revision 11741)
+++ src/call_list.txt   (working copy)
@@ -49,14 +49,12 @@
 c# t/pmc/nci.t
 c  p
 c  pi
-c  v
 
 d# t/pmc/nci.t
 d  d
 d  JOd  # Parrot builtins
 I   JOS
 S   JOS  # ParrotIO.readline
-d  v
 I  JI   # Parrot_is_char_*
 v   JOSP # String.trans
 v   JOS  # String.reverse
@@ -83,7 +81,6 @@
 f# t/pmc/nci.t
 f  ff   # t/pmc/nci.t
 f  is
-f  v
 
 i
 i  b# t/pmc/nci.t
@@ -148,7 +145,6 @@
 i  
 i  t
 i  ti
-i  v
 i  4
 i  4i
 i  42p
@@ -160,7 +156,6 @@
 l  pi
 l  pii
 l  p33l
-l  v
 l  33l
 
 P  Ji   # Needed for parrot threads
@@ -185,10 +180,8 @@
 p  t
 p  tpp
 p  ttt
-p  v
 
 s # t/pmc/nci.t
-s  v
 
 t # t/pmc/nci.t
 t  i
@@ -200,7 +193,6 @@
 t  t
 t  tl4
 t  t4
-t  v
 
 v
 v  Jiiip# examples/japh/japh11.pasm
@@ -215,7 +207,6 @@
 v  p
 v  pl
 v  pp
-v  v
 
 # These are needed for parrotio.pmc
 i  JP
@@ -343,3 +334,77 @@
 
 # Make lua stop panic'ing.
 P  JOI
+
+
+# --- start mysqlclient library ---
+# Created from mysql.h using the following manual method:
+# Edited copy of mysql.h using vi by doing g/, *$/j (repeat) then g/\* *$/j 
(repeat)
+# to get all functions on one line each.
+# Extracted list of api func names from 
http://dev.mysql.com/doc/refman/4.1/en/c-api-functions.html
+# and copied to a temporary file to clean up (mysql_api_names.txt)
+# Stripped down to bare names and merged into one line separated by |
+# then egrep -w `cat mysql_api_names.txt` mysql.h > mysql_api.ncidef
+# then edit mysql_api.ncidef in vi: %s/^/   #  /
+# to create space for nci signatures and to use original definition as a # 
comment.
+# This method isn't ideal, I'm just noting it here in case it helps others.
+# Ideally the process should be automated - but there be many dragons along # 
that path.
+#
+# long long values (my_ulonglong) aren't handled by nci - spec'd as just long 
for now
+#
+#  MYSQL_FIELD and MYSQL_RES are structs
+#  typedef char **MYSQL_ROW;   /* return data as array of 
strings */
+#  typedef unsigned int MYSQL_FIELD_OFFSET; /* offset to current field */
+#  typedef MYSQL_ROWS *MYSQL_ROW_OFFSET;   /* offset to current row */
+#
+l p#! my_ulonglong mysql_num_rows(MYSQL_RES *res)
+i p#  unsigned int mysql_num_fields(MYSQL_RES *res)
+c p#  my_bool mysql_eof(MYSQL_RES *res)
+p pi   #  MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *res, unsigned int 
fieldnr)
+p p#  MYSQL_FIELD * mysql_fetch_fields(MYSQL_RES *res)
+p p#  MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *res)
+i p#  MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *res)
+i p#  unsigned int mysql_field_count(MYSQL *mysql)
+l p#! my_ulonglong mysql_affected_rows(MYSQL *mysql)
+l p#! my_ulonglong mysql_insert_id(MYSQL *mysql)
+i p#  unsigned int mysql_errno(MYSQL *mysql)
+t p#  const char * mysql_error(MYSQL *mysql)
+t p#  const char * mysql_info(MYSQL *mysql)
+l p#  unsigned long mysql_thread_id(MYSQL *mysql)
+t p#  const char * mysql_character_set_name(MYSQL *mysql)
+p p#  MYSQL * mysql_init(MYSQL *mysql)
+i pt   #  int mysql_ssl_set(MYSQL *mysql, const char *key, const char 
*cert, const char *ca, const char *capath, const char *cipher)
+c pttt #  my_bool mysql_change_user(MYSQL *mysql, const char *user, 
const char *passwd, con

Re: Rare failure of t/dynoplibs/myops alarm sequence

[Tim Bunce]

On Tue, Feb 28, 2006 at 03:37:23PM +0100, Leopold Toetsch wrote:
> 
> On Feb 28, 2006, at 14:59, Tim Bunce wrote:
> 
> >FYI I saw this once but haven't been able to repeat it:
> >
> >t/dynoplibs/myopsok 6/7
> 
> This can happen if the machine is busy.

Okay. Can't the test be made more robust? Or emit a warning note?

(Not a big issue, just wondering if there's some reason for it.
I might look at it myself if there isn't a reason it can't be fixed.)

Ti.

Re: NCI 'v' vs '' in function parameter signatures

[Tim Bunce]

Any news on this? Is it okay? Should I send it via parrotbug?

Tim.

On Tue, Feb 28, 2006 at 03:36:20PM +, Tim Bunce wrote:
> On Tue, Feb 14, 2006 at 10:04:59PM +0100, Leopold Toetsch wrote:
> > On Feb 14, 2006, at 18:29, Tim Bunce wrote:
> > 
> > >The runtime dlfunc code will need to be altered to normalize away the
> > >trailing v so old code won't break. Should it warn about that?
> > 
> > Yes, a warning please.
> 
> Here's the patch.
> 
>  - removes 'v' argument entries from src/call_list.txt
>  - adds mysqlclient signatures to src/call_list.txt [*]
>  - tweaks docs/pdds/clip/pdd16_native_call.pod to match
>  - adds list of definition files used into generated nci.c
>  - adds sanity checking of return and argument sig chars
>  - adds compile time warning for deprecated 'v' argument
>  - adds optional duplicate signature warning (disabled)
>  - adds runtime warning for deprecated 'v' argument
> 
> Tim.
> 
> [*] I'm planning a followup patch that splits src/call_list.txt
> into multiple files in a subdirectory. The mysqlclient defs would then
> be in their own file. With the current arrangement no one can safely
> remove a signature because there's no indication of what that signature
> exists for.
> 
> The same ncidef file could then be used for both tools/build/nativecall.pl
> and tools/util/ncidef2pasm.pl (which I also plan to work on).
> 
> Any objections or comments?

> Index: src/call_list.txt
> ===
> --- src/call_list.txt (revision 11741)
> +++ src/call_list.txt (working copy)
> @@ -49,14 +49,12 @@
>  c# t/pmc/nci.t
>  cp
>  cpi
> -cv
>  
>  d# t/pmc/nci.t
>  dd
>  dJOd  # Parrot builtins
>  I   JOS
>  S   JOS  # ParrotIO.readline
> -dv
>  IJI   # Parrot_is_char_*
>  v   JOSP # String.trans
>  v   JOS  # String.reverse
> @@ -83,7 +81,6 @@
>  f# t/pmc/nci.t
>  fff   # t/pmc/nci.t
>  fis
> -fv
>  
>  i
>  ib# t/pmc/nci.t
> @@ -148,7 +145,6 @@
>  i
>  it
>  iti
> -iv
>  i4
>  i4i
>  i42p
> @@ -160,7 +156,6 @@
>  lpi
>  lpii
>  lp33l
> -lv
>  l33l
>  
>  PJi   # Needed for parrot threads
> @@ -185,10 +180,8 @@
>  pt
>  ptpp
>  pttt
> -pv
>  
>  s # t/pmc/nci.t
> -sv
>  
>  t # t/pmc/nci.t
>  ti
> @@ -200,7 +193,6 @@
>  tt
>  ttl4
>  tt4
> -tv
>  
>  v
>  vJiiip# examples/japh/japh11.pasm
> @@ -215,7 +207,6 @@
>  vp
>  vpl
>  vpp
> -vv
>  
>  # These are needed for parrotio.pmc
>  iJP
> @@ -343,3 +334,77 @@
>  
>  # Make lua stop panic'ing.
>  P  JOI
> +
> +
> +# --- start mysqlclient library ---
> +# Created from mysql.h using the following manual method:
> +# Edited copy of mysql.h using vi by doing g/, *$/j (repeat) then g/\* *$/j 
> (repeat)
> +# to get all functions on one line each.
> +# Extracted list of api func names from 
> http://dev.mysql.com/doc/refman/4.1/en/c-api-functions.html
> +# and copied to a temporary file to clean up (mysql_api_names.txt)
> +# Stripped down to bare names and merged into one line separated by |
> +# then egrep -w `cat mysql_api_names.txt` mysql.h > mysql_api.ncidef
> +# then edit mysql_api.ncidef in vi: %s/^/   #  /
> +# to create space for nci signatures and to use original definition as a # 
> comment.
> +# This method isn't ideal, I'm just noting it here in case it helps others.
> +# Ideally the process should be automated - but there be many dragons along 
> # that path.
> +#
> +# long long values (my_ulonglong) aren't handled by nci - spec'd as just 
> long for now
> +#
> +#MYSQL_FIELD and MYSQL_RES are structs
> +#typedef char **MYSQL_ROW;   /* return data as array of 
> strings */
> +#typedef unsigned int MYSQL_FIELD_OFFSET; /* offset to current field */
> +#typedef MYSQL_ROWS *MYSQL_ROW_OFFSET;   /* offset to current row */
> +#
> +l p  #! my_ulonglong mysql_num_rows(MYSQL_RES *res)
> +i p  #  unsigned int mysql_num_fields(MYSQL_RES *res)
> +c p  #  my_bool mysql_eof(MYSQL_RES *res)
> +p pi #  MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *res, unsigned int 
> fieldnr)
> +p p  #  MYSQL_FIELD * mysql_fetch_fields(MYSQL_RES *res)
> +p p  #  MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *res)
> +i p  #  MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *r

DBI2 reborn with DBI1 facade

[Tim Bunce]

On Sat, May 13, 2006 at 04:34:19PM -0500, Jonathan Scott Duff wrote:
> Apparently it's my lot in life to think about dbdi once a year
> as it was almost exactly 1 year ago that I asked the following:
> 
> 1. Is this list alive?
> 2. Is anyone working on the dbdi?
> 
> So, consider this my annual ping on the subject. Only now I've got a
> third question:
> 
> 3. What can your average programmer-type person do to help?
> 
> I understand that parrot maturity was a a bit of a problem before, but
> maybe it's far enough along now that isn't a problem?

It's certainly a lot further, and so is Pugs and thus Perl 6.

On Sat, May 13, 2006 at 06:21:26PM -0700, Darren Duncan wrote:
> 
> I don't know whether it was meant to replace dbdi-dev@perl.org or 
> not, but there is a newer dbi2-dev@perl.org list now that you may 
> want to check out.

'DBDI' relates to the interface to db drivers that's 'underneath' the
DBI (and similar db abstraction layers). The idea is that Parrot needs
something like DBDI so all the languages targeting Parrot can share db
drivers.

'DBI2' relates to evolving the DBI API. Initially to redesign the API,
but now with a new interim mission...

> That said, it has next to no traffic as well; waiting for something, I 
> presume.

Real Life (tm), in the form of a new baby, and $work have hampered by
ability to devote time to these activities.

That's partly why I added the following idea to The Perl Foundation's Summer of 
Code
project list (http://www.perl.org/advocacy/summerofcode/ideas.html):

  Reimplement the DBI v1 API in Pugs
  Design an implementation of the DBI API in Perl 6 using Pugs.
  The goal is to maintain the familiar DBI API while radically refactoring
  the internals to make best use of Perl 6 and so enable greater
  functionality and extensibility. (Likely mentor: Tim Bunce)

Trying to come up with both a new architecture and a new API was too much.
A great deal can be achieved by radically refactoring the internals
while keeping the same old API (i.e. don't move the goal posts).
I'm sure a new API will naturally emerge from this work, but it won't be
the primary goal.

I'm delighted to say that Szilakszi Bálint has submitted a proposal
and it looks like it'll be accepted (on May 23rd) and I'll be the mentor.
Audrey is keen to help, which is a big plus.

So, we're about to have a fire lit under us when Bálint gets going and
needs design input!

I think the dbi2-dev mailing list is the best place for most discussion
related to this, though some Perl 6 issues may need input from perl6-language.

Tim.

Perl 6 implmenentation of the Java JDBC API?

[Tim Bunce]

On Tue, May 16, 2006 at 11:59:48PM +0100, Tim Bunce wrote:
> That's partly why I added the following idea to The Perl Foundation's Summer 
> of Code
> project list (http://www.perl.org/advocacy/summerofcode/ideas.html):
> 
>   Reimplement the DBI v1 API in Pugs
>   Design an implementation of the DBI API in Perl 6 using Pugs.
>   The goal is to maintain the familiar DBI API while radically refactoring
>   the internals to make best use of Perl 6 and so enable greater
>   functionality and extensibility. (Likely mentor: Tim Bunce)
> 
> Trying to come up with both a new architecture and a new API was too much.
> A great deal can be achieved by radically refactoring the internals
> while keeping the same old API (i.e. don't move the goal posts).
> I'm sure a new API will naturally emerge from this work, but it won't be
> the primary goal.

One of the issues facing a Perl 6 implementation of the DBI is how to
implement drivers. Specifically the DBI->DBD API and the supporting
framework to enable drivers to be written with little effort as possible.

The current DBI->DBD API is essentially undocumented and only a few brave
souls have ventured into it to produce drivers. We need to do better.

The 'DBDI' project was started a couple of years ago to define a new
DBI->DBD API with a focus on Parrot. The goal being a database API
(and drivers) for Parrot that could be shared by all languages
targeting Parrot. That project was ahead of it's time and floundered.

I came to the conclusion a year or so ago that rather than try to create
a new Driver API from scratch we should simply adopt an existing one.

The most widely know object oriented database API that's a close fit to
the DBI's needs and most database client APIs is the Java JDBC API.
It's also suitable as a Parrot API, which is a key goal for DBDI.

So I'm specifying that the DBI->DBD API will be based closely on JDBC.
How close? Very close. Specifically, closely enough that we can refer
users JDBC documentation and only document differences and (inevitable)
extensions.

Although a key goal is a Parrot API it makes most sense to work with
Pugs at this stage.

So, is anyone interested in working on mapping the JDBC API to Pugs
and implementing an underlying framework for drivers to use?

Tim.

Re: [perl #39255] Revision 12862 fails tests on OS X

[Tim Bunce]

On Fri, Jun 02, 2006 at 09:35:00AM -0400, Will Coleda wrote:
> Per leo, "As of r12867 this is fixed."

Fixed for me. Thanks Leo!

Tim.

> On Jun 2, 2006, at 8:24 AM, Will Coleda wrote:
> 
> >Known failures.
> >
> >Per Leo, failing tests were committed for these features to  
> >"encourage" development.
> >
> >We've tried to let head be usable for this long, we should probably  
> >have some kind of procedure for dealing with this this sort of  
> >development to avoid this sort of confusion.
> >
> >Thanks for the report!
> >
> >On Jun 1, 2006, at 11:56 AM, Tim Bunce (via RT) wrote:
> >
> >># New Ticket Created by  Tim Bunce
> >># Please include the string:  [perl #39255]
> >># in the subject line of all future correspondence about this issue.
> >># https://rt.perl.org/rt3/Ticket/Display.html?id=39255 >
> >>
> >>
> >>---
> >>osname= darwin
> >>osvers= 8.0
> >>arch=   darwin-thread-multi-2level
> >>cc= cc
> >>---
> >>Flags:
> >>category=core
> >>severity=critical
> >>ack=no
> >>---
> >>
> >>Failed Test Stat Wstat Total Fail  List of Failed
> >>- 
> >>--
> >>t/pmc/mmd.t2   512382  37-38
> >>t/pmc/sub.t1   256491  47
> >>
> >>
> >>t/pmc/mmdok 33/38
> >># Failed test (t/pmc/mmd.t at line 1228)
> >>#  got: 'Called wrong multi
> >># '
> >># expected: 'Called multi for class
> >># '
> >>t/pmc/mmdNOK 37
> >>t/pmc/mmdNOK 38# Failed test (t/ 
> >>pmc/mmd.t at line 1254)
> >>#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>)  
> >>was not found. Check the type and number of the arguments
> >># in file '/Users/timbo/perl/parrot/t/pmc/mmd_38.pir' line 15
> >># '
> >># expected: 'String:what
> >># Int:23
> >># '
> >># './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/ 
> >>mmd_38.pir"' failed with exit code 18
> >># Looks like you failed 2 tests of 38.
> >>
> >>
> >>t/pmc/subok 37/49
> >># Failed test (t/pmc/sub.t at line 1178)
> >>#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>)  
> >>was not found. Check the type and number of the arguments
> >># in file '/Users/timbo/perl/parrot/t/pmc/sub_47.pir' line 7
> >># '
> >># expected: 'ok
> >># '
> >># './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/ 
> >>sub_47.pir"' failed with exit code 18
> >>
> >>
> >>---
> >>Summary of my parrot 0.4.4 (r12862) configuration:
> >>  configdate='Thu Jun  1 16:08:34 2006'
> >>  Platform:
> >>osname=darwin, archname=darwin-thread-multi-2level
> >>jitcapable=1, jitarchname=i386-darwin,
> >>jitosname=DARWIN, jitcpuarch=i386
> >>execcapable=1
> >>perl=perl
> >>  Compiler:
> >>cc='cc', ccflags='-fno-common -no-cpp-precomp -DDEBUGGING  - 
> >>pipe -I/usr/local/include -I/opt/local/include -pipe -fno-common - 
> >>Wno-long-double ',
> >>  Linker and Libraries:
> >>ld='c++', ldflags=' -L/usr/local/lib -L/opt/local/lib - 
> >>flat_namespace ',
> >>cc_ldflags='',
> >>libs='-lm'
> >>  Dynamic Linking:
> >>share_ext='.dylib', ld_share_flags='-dynamiclib -undefined  
> >>suppress',
> >>load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
> >>  Types:
> >>iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
> >>ptrsize=4, ptr_alignment=1 byteorder=1234,
> >>nv=double, numvalsize=8, doublesize=8
> >>
> >>---
> >>Environment:
> >>DYLD_LIBRARY_PATHHOMELANGLANGUAGE 
> >>LD_LIBRARY_PATHLOGDIRPATHPERL5LIBPERLCRITIC 
> >>PERLTIDYSHELL
> >>
> >
> >--
> >Will "Coke" Coleda
> >[EMAIL PROTECTED]
> >
> >
> >
> 
> --
> Will "Coke" Coleda
> [EMAIL PROTECTED]
> 
> 
> 
>  

Re: Revised Perl++ Wiki Proposal / $1k bounty

[Tim Bunce]

On Tue, Jun 20, 2006 at 08:29:54AM -0700, Conrad Schneiker wrote:
> Here's my latest proposal. Feedback welcome.
> 
> I propose to install twiki (http://www.twiki.org/) on Feather. This is
> a GPL'd Perl-based industrial-strength wiki. This would serve as the
> general Perl 6 wiki, aka Perl++. 

I believe some would disagree with 'industrial-strength'. I'd recommend
reading http://blogs.sun.com/roller/page/alanbur?entry=twiki_rant

Tim.

> The source code would be placed in the Pugs .../other/... subtree for
> us to incrementally convert parts of it to Perl 6, and to also
> add/change functionality. A perpetual beta version of this would also
> be available on Feather. From time to time this beta version would
> replace the pervious Perl++ wiki code. In the mean time, we would have
> the initial Perl++ wiki.
> 
> The previously proposed bounty would then instead be offered for the
> following subproject. Create a subsection of the Perl++ wiki that
> mirrored the Pugs svn doc tree. Provide a means of hacking on the docs
> through the Perl++ wiki. Implement whatever protocol the @Larry people
> on #perl6 deem appropriate for handing commit bit access issues. I
> think that that this simplification and convenience would greatly
> expand participation in generating Perl 6 documentation.
> 
> Best regards,
> Conrad Schneiker
> 
> http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
> 6 Wiki.)
> 
> www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
> technology.)
> 
> 

Module::Dependency 1.84

[Tim Bunce]

I needed some code to trawl through a directory tree parsing perl
modules and scripts to determine their dependencies.

The closest existing CPAN code was Module::Dependency but it fell short
of what I needed. The original author (P Kent) has passed over
maintenance to me. My latest release is:

  file: $CPAN/authors/id/T/TI/TIMB/Module-Dependency-1.84.tar.gz
  size: 52161 bytes
   md5: 90a83b2aee39f5d25060ebdb6cc3105d

With the changes I've made I've pretty much 'scratched my own itch'
for the time being. (Most recently with a completely new query
script - docs appended below.) But the core code is still basically as
it was when I came to it.

I'm posting this here to see if anyone would like to contribute to it.
The code is in subversion on perl.org and I'll happily give write
access to anyone interested.

Some random things I'd like to see done:

 - make items be real objects with methods etc
 - use overloading to stringify to $obj->{key}
 - move some pmd_dump.pl subs into object methods
 - abstract the modules and give them proper APIs
 - move to using Sqlite with a proper schema
for example to handle multiple packages per file,
not to mention supporting arbitrary queries
 - Look at using Graph::Easy to rewrite/replace Module::Dependency::Grapher.

Tim.

=head1 NAME

pmd_dump.pl - Query and print Module::Dependency info

=head1 SYNOPSIS

pmd_dump.pl [options] object-patterns

object-patterns can be:

f=S- Select objects where field f equals string S
f=~R   - Select objects where field f matches regex R
S$ - Same as filename=~S$ to match by file suffix
S  - Same as key=S

For example:

package=Foo::Bar - that specific package
package=~^Foo::  - all packages that start with Foo::
filename=~sub/dir/path   - everything with that path in the filename
filename=~'\.pm$'- all modules
restart.pl$  - all files with names ending in restart.pl
foo  - same as key=foo

Fields available are:

filename - "dir/subdir/foo.pl"
package  - "strict"
key  - same as package for packages, or filename for other files
filerootdir  - "/abs/path"
depends_on   - "Carp strict Foo::Bar"
depended_upon_by - "Other::Module dir/subdir/foo.pl dir2/bar.pl 
Another:Module"

Selected objects can be augmented using:

-P=N   Also pre-select N levels of parent objects
-C=N   Also pre-select N levels of child objects

Then filtered:

-F=P   Filter OUT objects matching the object-pattern P
-S=P   Only SELECT objects matching the object-pattern P

Then merged:

-M Merge data for selected objects into a single pseudo-object.
   Removes internally resolved dependencies.
   Handy to see all external dependencies of a group of files.
   The -P and -C flags are typically only useful with -M.

Then modified:

-D Delete dependencies on modules which weren't indexed but can
   be found in @INC

Then dumped:

-f=f1,f2,... - only dump these fields (otherwise all)

And for each one dumped:

-p=N   Recurse to show N levels of indented parent objects first
-c=N   Recurse to show N levels of indented child objects after
-i=S   Use S as the indent string (default is a tab)
-u Unique - only show a child or parent once
-k Don't show key in header, just the fieldname
-h Don't show header (like grep -h), used with -f=fieldname
-s sort by name
-r=P   Show the relationship between the item and those matching P

Other options:

-help Displays this help
-t Displays tracing messages
-o the location of the datafile (default is /var/tmp/dependence/unified.dat)
-r State the relationship, if any, between item1 and item2 - both may be 
scripts or modules.

=head1 EXAMPLE

pmd_dump.pl -o ./unified.dat Module::Dependency::Info

Select and merge everything in the database (which removes internally resolved
dependencies) and list the names of all unresolved packages:

pmd_dump.pl -f=depends_on -h -M ''

Do the same but feed the results back into pmd_dump.pl to get details of what
depends on those unresolved items:

pmd_dump.pl -f=depended_upon_by `pmd_dump.pl -f=depends_on -h -M ''` | less 
-S

=cut

Re: CPANDB - was: Module::Dependency 1.84

[Tim Bunce]

On Wed, Jul 12, 2006 at 03:03:14AM +0200, Tels wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Moin Tim,
> 
> On Tuesday 11 July 2006 18:34, Tim Bunce wrote:
> > I needed some code to trawl through a directory tree parsing perl
> > modules and scripts to determine their dependencies.
> >
> > The closest existing CPAN code was Module::Dependency but it fell short
> > of what I needed. The original author (P Kent) has passed over
> > maintenance to me. My latest release is:
> >
> >   file: $CPAN/authors/id/T/TI/TIMB/Module-Dependency-1.84.tar.gz
> >   size: 52161 bytes
> >md5: 90a83b2aee39f5d25060ebdb6cc3105d
> 
> Thats sort of cool, although I havent looked at it yet :-D
> 
> My real-grand-plan was always to have a CPANDB module that does exactly the 
> following:
> 
> maintains a database with:
> 
> * every CPAN author with all details (ID, email, name)
> * every package with all details (author id, version, name etc etc)

> This database could then be used by all the following modules:
> 
>   Module::Dependency
>   Graph::Dependency
>   CPANPLUS
>   CPANTS
>   CPAN
>   Module::Author
> 
> and a few others I forgot. Basically by every module out there that 
> re-invents the wheel over and over again just to be able to query stuff 
> about CPAN modules. (some of them do really horrible stuff like accessing 
> search.cpan.org - I know I wrote one of them :D

A key point about those modules (other than Module::Dependency) is that they
don't work for private modules (the so called "Dark CPAN") nor for scripts.

Module::Dependency handles both (details changed to protect the guilty):

$ pmd_dump.pl adnetwork/www/cron/cv.pl
adnetwork/www/cron/cv.pl depended_upon_by: 
adnetwork/www/cron/cv.pl depends_on: strict File::Basename lib Env wConfig 
vConfig Churl::Log Churl::MyDBI Churl::Util

$ pmd_dump.pl Churl::MyDBI 
Churl::MyDBI depended_upon_by: www/cron/cv.pl www/cron/pub_login.pl
Churl::MyDBI depends_on: Exporter strict warnings Carp DBIx::DWIW 
File::Basename Sys::Syslog vars
Churl::MyDBI filename: clcyt/Churl/lib/Churl/MyDBI.pm


> And up until today it is still not possible to get easily the answer "what 
> modules do I need install for Foo::Bar 1.23 when using Perl 5.8.x".

Or what module may be affected if I upgrade Foo::Bar.

> My idea was to build _only_ the database, and do it right, simple and easy 
> to use and then get everyone else to just use the DB instead of fiddling 
> with their own. (simple by having the database being superior to every 
> other hack thats in existance now :-)
> 
> I even got so far as to do a mockup v0.02 - but then went back to playing 
> Guildwars.
> 
> Is this a project that would be of general interest?

Yes! But widen your horizon, and schema, beyond just CPAN.
I'd be interested in helping out and, if it works out, perhaps migrate
Module::Dependency to use it.

Tim.

Re: PDD 22 - I/O release candidate 1

[Tim Bunce]

On Tue, Sep 26, 2006 at 04:44:53PM -0700, Allison Randal wrote:
> I've committed an updated I/O PDD. I'm close to pronouncing this ready 
> to implement, so get in your comments now.
> 
> One piece that is currently missing is a discussion of which lightweight 
> concurrency model we're going to use for the asynchronous operations. 
> I've had ongoing back-channel conversations with various people, but I 
> need to congeal them. Pitch in your own 2 cents.
> 
> Also, any reactions to the distinction that async ops return status 
> objects while sync ops return integer error codes? Sync opcodes could 
> have 2 signatures, one with an integer return type (int error code) and 
> one with a PMC return type (status object).

What's the relative cost of creating a PMC vs passing one in?
I assume passing one in is significantly faster.

If so, then perhaps speed-sensitive ops that are likely to be used in
loops can be given the PMC to (re)use.

Tim.

Re: Runtime Role Issues

[Tim Bunce]

On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote:
> Hi all,
> 
> In doing a bit of work with traits (roles) in Perl 5
> (http://perlmonks.org/?node_id=577477), I've realized some edge cases
> which could be problematic.
> 
> First, when a role is applied to a class at runtime, a instance of that
> class in another scope may specifically *not* want that role.

I always thought when a role is applied to a class at runtime you
get a new (anonymous) subclass. The original class isn't affected.

Tim.

> Is there
> a way of restricting a role to a particular lexical scope short of
> merely applying that role to instances instead of classes?
> 
> Second, how can I remove roles from classes?  I've create some code
> which adds an "is_selected" method to some classes but when I'm done,
> I'd like top easily remove that role.  How do I do that?  Seems closely
> related to my first question, but it's still a distinct issue, I think.
> 
> Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says:
> 
>   You can also mixin a precomposed set of roles:
> 
> $fido does Sentry | Tricks | TailChasing | Scratch;
> 
> Should that be the following?
> 
> $fido does Sentry & Tricks & TailChasing & Scratch;
> 
> Cheers,
> Ovid
> 
> --
> 
> Buy the book -- http://www.oreilly.com/catalog/perlhks/
> Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Synposis 26 - Documentation [alpha draft]

[Tim Bunce]

On Thu, Oct 12, 2006 at 02:55:57PM +1000, Damian Conway wrote:
> Dave Whipp wrote:
> 
> >I'm not a great fan of this concept of "reservation" when there is no 
> >mechanism for its enforcement (and this is perl...).
> 
> What makes you assume there will be no mechanism for enforcement? The 
> standard Pod parser (of which I have a 95% complete Perl 5 implementation) 
> will complain bitterly--as in cyanide--when unknown pure-upper or 
> pure-lower block names are used.

That's going to cause pain when people using older parsers try to read
docs written for newer ones. Would a loud warning plus some best-efforts
fail-safe parsing be possible?

Tim.

> The whole point of reserving these namespaces is not to prevent users from 
> misusing them, but to ensure that when we eventually get around to using a 
> particular block name, and those same users start screaming about it, we 
> can mournfully point to the passage in the original spec and silently shake 
> our heads. ;-)
> 
> Damian

Re: Synposis 26 - Documentation [alpha draft]

[Tim Bunce]

On Thu, Oct 12, 2006 at 03:57:01PM -0700, Jonathan Lang wrote:
> Tim Bunce wrote:
> >Damian Conway wrote:
> >> Dave Whipp wrote:
> >> >I'm not a great fan of this concept of "reservation" when there is no
> >> >mechanism for its enforcement (and this is perl...).
> >>
> >> What makes you assume there will be no mechanism for enforcement? The
> >> standard Pod parser (of which I have a 95% complete Perl 5 
> >implementation)
> >> will complain bitterly--as in cyanide--when unknown pure-upper or
> >> pure-lower block names are used.
> >
> >That's going to cause pain when people using older parsers try to read
> >docs written for newer ones.
> 
> If I understand you correctly, the pain to which you're referring
> would come from the possibility of a name that's reserved by the newer
> version of Pod, but not by the older version.

Yes.

> Wouldn't the simplest solution be to let a Pod document announce its
> own version, much like Perl can?

How would that actually help? The old parser still wouldn't know what
new keywords have been added or how to parse them.

Tim.

Re: Perl 6 Microgrants. Now accepting proposals.

[Tim Bunce]

On Wed, Mar 21, 2007 at 11:04:29PM -0400, Jesse Vincent wrote:
> I'm pleased to announce the inaugural Perl 6 Microgrants program.  
> Best Practical Solutions (my company) has donated USD5,000 to The  
> Perl Foundation to help support Perl 6 Development.  Leon Brocard,  
> representing The Perl Foundation's grants committee, will work with  
> me to select proposals and evaluate project success.  We'll be making  
> USD500 grants to worthy Perl 6 related efforts. We're hoping to fund  
> a range of Perl 6-related projects over the life of the grant  
> program.  Accepted grants might be for coding, documentation, testing  
> or even writing articles about Perl 6. The program isn't tied to any  
> one implementation of Perl 6 -- We're interested in seeing proposals  
> related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl  
> 6 implementation.  Generally, we're interested in seeing projects  
> that can be completed in 4-6 calendar weeks.
> 
> Submitting a grant proposal
> ---
> 
> To submit a grant proposal, please email us at perl6- 
> [EMAIL PROTECTED] with the following information:
> 
> * A two to three paragraph summary of the work you intend to do
> * A quick bio - Who are you? Is there opensource work you've done  
> that we should have a look at?
> * A brief description of what "success" will mean for your project -  
> How will we know you're done?
> * Where (if anywhere) you've discussed your project in the past
> * Where you'll be blogging about your progress. (Twice-weekly blog  
> posts are a requirement for getting your grant money)
> 
> We'll be accepting proposals on a rolling schedule. We expect to pay  
> out these first 10 grants over the course of the summer. Depending on  
> how things go, we'll then either find more money for more grant  
> programs or we'll wind up the program and move on to other endeavors.
> 
> We're really excited to get rolling. Submit your proposals early and  
> often. Don't let somebody else beat you to the punch ;)

I'd like to suggest an idea for *someone else* to submit a proposal for:

As part of the work on DBI2 I want to create a Perl API that closely
matches the JDBC API.

I need a tool that can parse the java .h files that that define the JDBC API,
e.g., 
http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621&view=markup
and generate roughly equivalent Perl 6 (roles etc).

Some knowledge of Java would be helpful to get a reasonable initial
mapping of concepts from Java to Perl, but that's bound to evolve over
time - hence the need for a tool to do, and redo, the translation.

[ I'd probably then use the tool to also generate implementation code
  that bridges the Perl6 JDBC with the Perl5 JDBC module on CPAN.
  That would give Perl6 a working JDBC API.
  (The next step might be to parse the Java code of the JDBC test suite
  and translate that to Perl6...)
]

There are two parts to this: a Java parser (good enough for at least the
JDBC .h files), and a Perl6 code (role) generator. They could be combined,
but I'd like the Java parser to be reusable by others.

Here's a related idea: write a tool that reads BNF grammar, such as
http://java.sun.com/docs/books/jls/third_edition/html/syntax.html
http://java.sun.com/docs/books/jls/third_edition/html/grammars.html
and writes a parser in Perl 6 for that grammar.

Anyone interested in those ideas?

Tim.

p.s. The .h files for JDBC can be found here
http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/
http://gcc.gnu.org/viewcvs/trunk/libjava/javax/sql/

p.p.s. The funding for these could come from the DBI Development fund
(which hasn't been used for anything yet) and so not impact the donation
from Best Practical Solutions.

Re: 6PAN (was: Half measures all round)

[Tim Bunce]

On Thu, Jun 13, 2002 at 12:00:13AM +0300, [EMAIL PROTECTED] wrote:
> 
> |On 6/4/02 12:22 PM, David Wheeler wrote:
> |> I think that if we can agree to forego backwards compatibility, we might
> |> also be in a better position to set up a CP6AN with much better quality
> |> control. All of the most important modules will be ported very quickly
> |> (e.g., the DBI),

Actually I doubt that complex extensions with lots of XS/C code
will get ported "very quickly" since the work involved may be
considerable.

That's one of the reasons I've put so much effort into making
DBI::PurePerl a viable tool. It'll automatically give people a
working Perl6 DBI (for pure-perl drivers) as soon as there's a
working perl5-to-perl6 translator.

Tim.

Re: Perl5 humor

[Tim Bunce]

On Mon, Jun 17, 2002 at 07:59:33PM -0400, David J. Goehrig wrote:
> 
> qw/ who is praying for parrot to support XS code, 
>   cause he doesn't want to rewrite
>   SDL_perl's 11,000 lines /;

I'm sure that's not going to happen.

Much more likely is some kind of wrapper that manages a simple
perl5-like run-time environment (stacks, marks, gimme, symboltable
etc) plus source-code compatibility support (macros, functions etc)
that's just sufficient to keep old XS code happy.

If someone wants to champion that work I'll certainly contribute.

Tim [who doesn't want to rewrite the DBI's ~4000 lines or tell the
many DBD authors that they have to rewrite their drivers].

Re: Perl5 humor

[Tim Bunce]

On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> On Mon, Jun 24, 2002 at 05:21:45PM -0400, David J. Goehrig wrote:
> > On Sun, Jun 23, 2002 at 09:50:02PM +0100, Tim Bunce wrote:
> > > Much more likely is some kind of wrapper that manages a simple
> > > perl5-like run-time environment (stacks, marks, gimme, symboltable
> > > etc) plus source-code compatibility support (macros, functions etc)
> > > that's just sufficient to keep old XS code happy.
> > 
> > That's all I'd ask for, but the scope of that project is truly incredible.
> > Granted that the one could get most of their bang for their buck out of
> > just handling those found in perlguts, but the devil is in the details.
> 
> Of course, another approach is to embed the existing Perl5 interpreter
> within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs
> which calls perl5 XS.

How would you deal with passing references?

Tim.

Re: Perl5 humor

[Tim Bunce]

On Mon, Jun 24, 2002 at 05:58:23PM -0500, Dan Sugalski wrote:
> At 9:50 PM +0100 6/23/02, Tim Bunce wrote:
> >On Mon, Jun 17, 2002 at 07:59:33PM -0400, David J. Goehrig wrote:
> >>
> >>  qw/ who is praying for parrot to support XS code,
> >>cause he doesn't want to rewrite
> >>SDL_perl's 11,000 lines /;
> >
> >I'm sure that's not going to happen.
> >
> >Much more likely is some kind of wrapper that manages a simple
> >perl5-like run-time environment (stacks, marks, gimme, symboltable
> >etc) plus source-code compatibility support (macros, functions etc)
> >that's just sufficient to keep old XS code happy.
> 
> Right. Parrot's not going to have XS as an interface--that'd be insane.
> 
> I'd like to have at least a partially compatible interface that can 
> be used to help the transition. Plain SV type things (getting/setting 
> values), and some of the AV/HV things should be doable as well.
> 
> Simple sub calling and suchlike things ought to also be doable with a 
> thunking layer of some sort. I don't expect most of the stuff in 
> perlguts, most of which is nasty to deal with, to be provided, though.
> 
> If someone wants to start a list of *sensible* entries in perl 5's 
> API that should be provided, we can work from there.

Perhaps start with a perl script that reads extension source code
(xs|c|h) and spits out details of what perlapi/guts have been used.

Feed it N popular extensions, sort the results by frequency and
we'd get a (self maintaining) list of what we'd need to support.

Tim.

Re: Perl5 humor

[Tim Bunce]

On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote:
> On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote:
> > On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> > > Of course, another approach is to embed the existing Perl5 interpreter
> > > within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs
> > > which calls perl5 XS.
> > 
> > How would you deal with passing references?
> 
> (wild hand waving follows)
> 
> a perl6 reference is substituted with a perl5 scalar that has attached
> magic that 'does the right thing'.

I don't think that'll fly.

Tim.

Re: Perl5 humor

[Tim Bunce]

On Tue, Jun 25, 2002 at 05:17:56PM +0100, Dave Mitchell wrote:
> On Tue, Jun 25, 2002 at 04:45:37PM +0100, Tim Bunce wrote:
> > On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote:
> > > On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote:
> > > > On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> > > > > Of course, another approach is to embed the existing Perl5 interpreter
> > > > > within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs
> > > > > which calls perl5 XS.
> > > > 
> > > > How would you deal with passing references?
> > > 
> > > (wild hand waving follows)
> > > 
> > > a perl6 reference is substituted with a perl5 scalar that has attached
> > > magic that 'does the right thing'.
> > 
> > I don't think that'll fly.
> 
> Quite possibly not. But Larry's reply to one of my postings on p6l led me
> to belive that was the direction we were going to head in. I may have
> misunderstood him:

There's more than one way to do it :)

Having a perl5 interpreter (or parts of one) embeded in perl6 may
be useful for some things. But the reference passing problem makes
me think it's not going to be practical for XS.

But we might not know for sure till we try.

Tim.


> > From: Larry Wall <[EMAIL PROTECTED]>
> > To: Dave Mitchell <[EMAIL PROTECTED]>
> > cc: Simon Cozens <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > Date: Tue, 4 Jun 2002 10:06:44 -0700 (PDT)
> > Subject: Re: Half measures all round
> >   
> > On Tue, 4 Jun 2002, Dave Mitchell wrote:
> > > Having said that, I have real, real doubts that Perl 6 will ever be able
> > > to execute Perl 5 code natively. Its not just a case a writing a new
> > > parser and some P5-specific ops; P5 has so many special features, boundary 
> > > conditions and pecularies, that to get P6 to execute P5 is a task
> > > equivalent to reimplementing P5 from scratch. I'm wondering if instead,
> > > we continue to maintain the P5 src tree, and embed P5 within P6 (embed in
> > > the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical
> > > than the alternatives. It also means that the P6 src doesn't have to be
> > > saddled with knowing (much) about P5.  Eventually of course the P5 bit
> > > would have to be thrown away.
> >  
> > That's exactly what I've been arguing for all along.  Grr
> >  
> > And that's why I see the "package" hack and the new :p5 modifier as
> > having the weight of two features, not the weight of an entire
> > re-implementation of Perl 5.
> >  
> > It's really not that difficult to run two interpreters in the
> > same process.  I already made Perl and Java run together nicely.
> > If anything the impedence mismatch between Perl 5 and Perl 6 will be
> > even less.
> >  
> > Scaffolding is supposed to be ugly.  You wouldn't believe how ugly 
> > the transitional form between Perl 4 and Perl 5 was, when half the
> > opcodes were interpreted by the old stacked interpreter, and half by
> > the new stackless one.
> >  
> > Larry   
> 
> 
> -- 
> In England there is a special word which means the last sunshine
> of the summer. That word is "spring".

Re: matrix design

[Tim Jenness]

On Wed, 19 Jun 2002, Ashley Winters wrote:

> I don't think you need to worry about optimizing complex operations too much, 
> the PDL people have come up with miracles before... they just need the tools.
> 

Sorry yo come in late but I would hope that the PDL people would not have 
to come up with miracles to fit PDL into perl 6 :-)  PDL in Perl5 is an 
amazing hack but no-one would say that it is all that "perl-ish" (although 
the new slicing syntax via a filter helps). The hope is that perl6 would 
provide an infrastructure in which PDL can be slotted with very little 
effort - the issues of syntax support in perl6 the language and N-dim 
array support in parrot are distinct. 

Also, don't fall into the trap of thinking that PDL "just does matrices". 
It has support for threading over redundant axes, dataflow, and the 
ability for changes in a slice to propogate back into the parent data 
structure.

-- 
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj

Re: Perl 6, The Good Parts Version

[Tim Bunce]

On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote:
> 
> I'm also trying to think of more bits to throw in.  Particularly in terms of
> the OO system, this being a conference about OO.  From what I've heard so
> far, Perl 6's OO system will be largely playing catch up with other
> languages.

Don't forget Apocalypse 5.

Personally I believe the elegant and thorough integration of regular
expressions and backtracking into the large-scale logic of an
application is one of the most radical things about Perl 6.

Tim.

Re: Perl 6, The Good Parts Version

[Tim Bunce]

On Wed, Jul 03, 2002 at 05:13:01PM -0400, Michael G Schwern wrote:
> On Wed, Jul 03, 2002 at 09:20:01PM +0100, Dave Mitchell wrote:
> > On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote:
> > >  Hopefully the Cabal [2] can debunk that.
> > [snip]
> > > [2] Of which there is none.
> > 
> > and http://www.perlcabal.com/ doesn't exist, right? ;-)
> 
>   Not Found
>   The requested URL / was not found on this server.
>   TINPC/1.3.14 Server at www.perlcabal.com Port 80
> 
> *snort* :)

Odd how that text isn't what it seems...

Tim.

Re: What's MY.line?

[Tim Bunce]

On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote:
> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> >>  The place where you'll run into problems in where you have multiple
> >>  variables of the same name at the same level, which you can do in
> >>  perl 5.
> >
> >can it?
> 
> Yes.
> 
> >can you give an example?
> 
> [localhost:~] dan% perl
> my $foo = 12;
> print $foo;
> my $foo = "ho";
> print $foo;
> 12ho[localhost:~] dan%

Of course it's a -w warning now:

"my" variable $foo masks earlier declaration in same scope at - line 3.

and I can imagine it becoming a mandatory warning in later versions
of perl5 (and/or perhaps in future they'll be a way to enable
warnings relevant to migration to perl6).

Tim.

Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening

[Tim Bunce]

On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote:
> "Sean O'Rourke" <[EMAIL PROTECTED]> wrote:
> 
> > languages/perl6/README sort of hides it, but it does say that "If you have
> > Perl <= 5.005_03, "$a += 3" may fail to parse."  I guess we can upgrade
> > that to "if you have < 5.6, you lose".
> 
> I notice that DBI no longer supports Perl releases <5.6.

Not true. The DBI supports 5.5.3.

The most recent release announcement did say:

  NOTE: Future versions of the DBI may not support for perl 5.5 much longer.
  : If you are still using perl 5.005_03 you should be making plans to
  : upgrade to at least perl 5.6.1, or 5.8.0. Perl 5.8.0 is due to be
  : released in the next week or so.  (Although it's a "point 0" release,
  : it is the most throughly tested release ever.)

But that's just a "shot across the bows" alerting people to think about
upgrading. I'm unlikely to actually require 5.6.1 for quite some time yet.

Tim.

Re: Would a getting started guide help

[Tim Bunce]

On a related note, are there any good tools for static code analysis
around?  The usual cross-reference stuff would be handy, but ideally
something that goes further.

Graphical would be good, interactive better (or at least cooler :).
Perhaps something like www.kartoo.com (needs flash) or
http://www.touchgraph.com/TGGoogleBrowser.html (needs java) that
lets you "explore" the relationships between things.

And, in case you're not familar with it, the "ID database" is a
very useful tool (quite old and alomost lost in the mists of time):
http://www.math.utah.edu/docs/info/mkid_toc.html
I highly recommend it.

Tim.

On Sat, Sep 28, 2002 at 10:46:36PM -0400, Erik Lechak wrote:
> Hello All,
> 
> I hope this is the correct place for my post.  I have not seen many (or 
> any) newbie parrot questions on this group.  Please direct me to the 
> correct group and forgive my intrusion if this message is misposted.
> 
> I would like to start helping in the development of parrot.  I have read 
> the documentation, the design docs, and went over the source, but I am 
> still a little lost.  I would eventually like to help with the coding, 
> but it appears that there may be a pressing need for a document helping 
> newbie developers figure out how to get started.  I would be willing to 
> take on this task (Well at least until I learn enough so that I can code.)
> 
> 1)If you would like me to do it, who would I send the document and its 
> updates to?
> 
> 2)I am a diagram oriented person.  If I include diagrams (gifs, png ...) 
> in the document, how would you want me to do this (html, ref the image 
> file ...)?  Any prefs in the image format?
> 
> 3)Do I have to use pod?  No offense, but I can't stand pod.  The pdd 
> design document states that pod is the "...documentation language for 
> All Things Perl", but this is Parrot not Perl.  And this document would 
> not be a design doc.  If Parrot is supposed to be a cross language VM, 
> why do people need to know pod to read (or write) the docs?  I know that 
> it is easy to convert pod to an easy to read format, but would a 
> developer with little perl experience know that?  Parrot is trying to 
> encourage developers from areas other than perl, so why discourage them 
> by introducing them to parrot with pod documents.
> 
> Could there possibly be a parrot comment style?  It could be used 
> instead of other comment styles internal to parrot.  Use it in the 
> c-code, the perl code, the parrot assembly code, and to write the 
> documentation.  Then a (perl) preprocessor could strip it out before it 
> is compiled or run.  Normally I would not suggest such a thing, but 
> there is a lot of code generation and manipulation going on anyway.  It 
> could allow for document generation of all the parrot source, assembly, 
> tests, and documents into a javadoc-like html reference.  Or maybe I'm 
> just dreaming.
> 
> Please go easy on me for not liking pod.
> 
> Thanks,
> Erik Lechak
> 

Re: Would a getting started guide help

[Tim Bunce]

On Wed, Oct 02, 2002 at 12:28:57PM -0400, Dan Sugalski wrote:
> At 12:15 PM +0100 10/2/02, Tim Bunce wrote:
> >On a related note, are there any good tools for static code analysis
> >around?  The usual cross-reference stuff would be handy, but ideally
> >something that goes further.
> 
> If someone wants to build some and there are things that parrot 
> doesn't provide that would make it easier, speak up--while I won't 
> promise we'll design in things for it, we certainly can't if we don't 
> know.

Seeing my post mentioned 'in brief' in Leon's summary made me think I
should at least do some googling of my own...

I turned up this one:

http://www.gnu.org/software/gcc/news/egcs-vcg.html
http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html

Tim.

Re: Copyright notices and license stuff

[Tim Bunce]

On Tue, Oct 29, 2002 at 05:18:53AM -0800, James Michael DuPont wrote:
> 
> The gcc interface project has been offically restarted.
> http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html

Congratulations. I think it's an important project.

Tim.

Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)

[Tim Bunce]

On Tue, Nov 12, 2002 at 11:40:05AM -0800, Larry Wall wrote:
> On Mon, Nov 11, 2002 at 03:50:34PM -0800, Damien Neil wrote:
> : I'd love to see a cleaner POD, with tables, better support for lists,
> : and the ability to turn syntax inferencing on a per-document basis.
> 
> We used a preprocessor to put tables into the POD for the Camel.
> Lists don't seem to occur all that often in technical docs, so it
> doesn't seem to be all that big a problem in practice, though we
> could certainly talk about improvements.  As for per-document policy,
> there should certainly be some kind of
> 
> =use module
> 
> directive that, like Perl's C, is something more than just an
> "include".

And has the freedom to change the grammar for pod text? And beyond?

Tim.

Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)

[Tim Bunce]

On Tue, Nov 12, 2002 at 07:15:23PM -0700, Sean M. Burke wrote:
> 
> That's vaguely like the verbatim-formatted stuff that I've been 
> experimenting with lately, where the second line here:
> flock COUNTER, LOCK_EX;
> #: ^^^
> bolds the characters above the "^".

I'd like to see an easy way to declare that a verbatim block
(or all following verbatim blocks till told otherwise?) should
be parsed for formatting code like B, I, E, X, and L. The loss of
vertical alignment in the pod source would rarely be a concern.

Tim.

Source code analysis (was: Would a getting started guide help)

[Tim Bunce]

On Sun, Oct 06, 2002 at 10:26:23PM +0100, Tim Bunce wrote:
> On Wed, Oct 02, 2002 at 12:28:57PM -0400, Dan Sugalski wrote:
> > At 12:15 PM +0100 10/2/02, Tim Bunce wrote:
> > >On a related note, are there any good tools for static code analysis
> > >around?  The usual cross-reference stuff would be handy, but ideally
> > >something that goes further.
> > 
> > If someone wants to build some and there are things that parrot 
> > doesn't provide that would make it easier, speak up--while I won't 
> > promise we'll design in things for it, we certainly can't if we don't 
> > know.
> 
> Seeing my post mentioned 'in brief' in Leon's summary made me think I
> should at least do some googling of my own...
> 
> I turned up this one:
> 
>   http://www.gnu.org/software/gcc/news/egcs-vcg.html
>   http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html

This is slightly different:

"Infrastructure for C Program Analysis and Transformation"
http://manju.cs.berkeley.edu/cil/

I wonder if it might be useful to occasionally use the related
"CCured" tool (built using CIL) as an extra sanity check on the
parrot code:

"CCured is a source-to-source translator for C, which
analyzes the program to determine the smallest number of
run-time checks that must be inserted in the program to
prevent all memory safety violations."

http://manju.cs.berkeley.edu/ccured/index.html

Tim.

Re: Test failures on OSX

[Tim Bunce]

On Thu, May 12, 2005 at 10:31:06PM +0200, Leopold Toetsch wrote:
> Tim wrote:
> >Fresh (and first) checkout and build of parrot (#8075)
> 
> first???\   :-)

I know, I know. Real life, real work and all that. I've been "watching
from afar" though at all this great work. I still won't have much time
but figured I ought to do *something*!

> Fixed - rev 8082.
> leo

Thanks Leo.

Tim.

Re: [Maybe Spam] Re: DBD-mysql coverage == 56% - am I on drugs ??

[Tim Bunce]

On Fri, May 13, 2005 at 10:51:56AM +0200, Paul Johnson wrote:
> On Fri, May 13, 2005 at 03:00:39PM +1000, [EMAIL PROTECTED] wrote:
> 
> > [EMAIL PROTECTED] wrote:
> > 
> > >Covering the XS portion of the code with gcov is possible, and Devel::Cover
> > >will create all kinds of nice webpages and statistics for you too.  
> > >Paul Johnson may have this written up somewhere, but, if not, I should 
> > >really write something up about this since I've used it to determine Perl's
> > >test coverage.
> 
> I don't think I have written anything except the docs for gcov2perl,
> which are minimal and incomplete.  I'd be happy to take doc patches for
> gcov2perl if you think that's the right place to document this.
> 
> > Generating coverage tests for XS code - why are my hands shaking ?
> 
> It's not really that difficult.  You just need to get the right options
> to gcc, either by compiling your perl with those options which means
> they will automatically be passed to your XS code, or by making sure
> your XS code is compiled with those options.  Then, on running your
> tests, you will get one or more gcov files which you can run through
> gcov2perl to add the gcov data to your perl coverage database.  Then,
> running one of Devel::Cover's reports will report on your XS code along
> with your Perl code.
> 
> OK.  In principle it's not really that difficult.

Would be _great_ if that could all be automated as far as possible.
I presume the gcov files could be automatically detected and processed,
for example.

Tim.

DBI v2 - The Plan and How You Can Help

[Tim Bunce]

Once upon a time I said:

  
http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=source&hl=en

and wrote

  http://search.cpan.org/~timb/DBI/Roadmap.pod

which yielded:

  https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Details&selfund=102

(A little over $500 of that I effectively put in myself.)

My *sincere* thanks to all those who donated to the fund, especially
individuals. I had hoped for more corporate response with less from
individuals and I'm touched by the personal generosity shown.

I've not drawn any money from it yet and doubt that I will myself.
(I'm considering suggesting that the Perl Foundation make payments
from the fund to people making specific contributions to the DBI.
I'm thinking especially of work on a comprehensive test harness.
But I'll see how the developments below pan out before making
specific arrangements.)


So, that lead to:

  
http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/thread/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0

Which sums up fairly well where I'm at: DBI v1 will rumble on for Perl 5
and DBI v2 will be implemented for Perl 6.


--- digression ---

At this point I'd like to make a slight digression to highlight the
amazing work going on in the Perl 6 community at the moment.
Especially Autrijus' Pugs project which has brought Perl 6 to life.
Literally. Take a look at:

http://pugscode.org/talks/yapc/slide1.html
http://use.perl.org/~autrijus/journal

and especially:

http://use.perl.org/~autrijus/journal/24898

Yes, that really is Perl 6 code using the DBI being executed by Pugs.

That's great, and I was truly delighted to see it because it takes the
pressure off the need to get a DBI working for Perl 6 - because it
already is working for Perl 6. At least for Pugs. (The Ponie project
is also likely to provide access to Perl 5 DBI from Perl 6 by enabling
future versions of Perl 5 to run on Parrot.)

--- digression ---


I have recently come to an arrangement that will enable me to put some
worthwhile development time into DBI (still very much part-time, but
enough to give it focus and move forward).

My initial goals are:

 1. to work on a more detailed specification for the DBI v2 API that
takes advantage of appropriate features of Perl 6.

 2. to work on a more detailed specification for the DBDI API
http://groups-beta.google.com/group/perl.perl6.internals/msg/cfcbd9ca7ee6ab4

 3. to work on tools to automate building Parrot NCI interfaces to
libraries (such as database client libraries, obviously :)


But I'm hoping you'll join in and help out.

I've kept an eye on Perl 6 and Parrot developments but I'm no expert in
either. What I'd like *you* to do is make proposals (ideally fairly
detailed proposals, but vague ideas are okay) for what a Perl 6 DBI API
should look like.

Keep in mind that the role of the DBI is to provide a consistent
interface to databases at a fairly low level. To provide a *foundation*
upon which higher level interfaces (such as Class::DBI, Tangram, Alzabo
etc. in Perl 5) can be built.

So, if you have an interest in the DBI and Perl 6, put your thinking
cap on, kick back and dream a little dream of how the DBI could be.
How to make best use of the new features in Perl 6 to make life easier.

Then jot down the details and email them to me (or to dbi-users@perl.org
if you want to kick them around in public for a while first).

I'm about to fly off for two weeks vacation (in a few hours), blissfully
absent of any hi-tech gear beyond a mobile phone. When I get back I'll
gather up your emails and try to distill them into a coherent whole.

Have fun!

Tim.

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote:
> 
>  When I go to the donation page and attempt to make a donation, the
> drop-down box does not give DBI as a valid recipient.  Is it possible
> several people may not have donated as they noticed the same results, or
> maybe they did and it all went into the Perl Development Fund instead?

The Perl Foundation default donation page doesn't list the DBI
Development Fund (for various reasons). To get that option you can use
http://dbi.perl.org/donate/ which will redirect you[1]

Thank you.

Tim.

[1] 
https://donate.perlfoundation.org/index.pl?node=Contribution%20Info&selfund=102

> 
> 
> > -----Original Message-
> > From: Tim Bunce [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, July 01, 2005 7:06 PM
> > To: perl6-language@perl.org; dbi-users@perl.org
> > Subject: DBI v2 - The Plan and How You Can Help
> > 
> > 
> > Once upon a time I said:
> > 
> >   
> > http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=source&hl=en
> > 
> > and wrote
> > 
> >   http://search.cpan.org/~timb/DBI/Roadmap.pod
> > 
> > which yielded:
> > 
> >   
> > https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det
> > ails&selfund=102
> > 
> > (A little over $500 of that I effectively put in myself.)
> > 
> > My *sincere* thanks to all those who donated to the fund, especially
> > individuals. I had hoped for more corporate response with less from
> > individuals and I'm touched by the personal generosity shown.
> > 
> > I've not drawn any money from it yet and doubt that I will myself.
> > (I'm considering suggesting that the Perl Foundation make payments
> > from the fund to people making specific contributions to the DBI.
> > I'm thinking especially of work on a comprehensive test harness.
> > But I'll see how the developments below pan out before making
> > specific arrangements.)
> > 
> > 
> > So, that lead to:
> > 
> >   
> > http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/th
> > read/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0
> > 
> > Which sums up fairly well where I'm at: DBI v1 will rumble on 
> > for Perl 5
> > and DBI v2 will be implemented for Perl 6.
> > 
> > 
> > --- digression ---
> > 
> > At this point I'd like to make a slight digression to highlight the
> > amazing work going on in the Perl 6 community at the moment.
> > Especially Autrijus' Pugs project which has brought Perl 6 to life.
> > Literally. Take a look at:
> > 
> > http://pugscode.org/talks/yapc/slide1.html
> > http://use.perl.org/~autrijus/journal
> > 
> > and especially:
> > 
> > http://use.perl.org/~autrijus/journal/24898
> > 
> > Yes, that really is Perl 6 code using the DBI being executed by Pugs.
> > 
> > That's great, and I was truly delighted to see it because it takes the
> > pressure off the need to get a DBI working for Perl 6 - because it
> > already is working for Perl 6. At least for Pugs. (The Ponie project
> > is also likely to provide access to Perl 5 DBI from Perl 6 by enabling
> > future versions of Perl 5 to run on Parrot.)
> > 
> > --- digression ---
> > 
> > 
> > I have recently come to an arrangement that will enable me to put some
> > worthwhile development time into DBI (still very much part-time, but
> > enough to give it focus and move forward).
> > 
> > My initial goals are:
> > 
> >  1. to work on a more detailed specification for the DBI v2 API that
> > takes advantage of appropriate features of Perl 6.
> > 
> >  2. to work on a more detailed specification for the DBDI API
> > 
> > http://groups-beta.google.com/group/perl.perl6.internals/msg/c
> > fcbd9ca7ee6ab4
> > 
> >  3. to work on tools to automate building Parrot NCI interfaces to
> > libraries (such as database client libraries, obviously :)
> > 
> > 
> > But I'm hoping you'll join in and help out.
> > 
> > I've kept an eye on Perl 6 and Parrot developments but I'm no 
> > expert in
> > either. What I'd like *you* to do is make proposals (ideally fairly
> > detailed proposals, but vague ideas are okay) for what a Perl 
> > 6 DBI API
> > should look like.
> > 
> > Keep in mind that the role of the DBI is to provide a consistent
> > interface to databases at a fairly low level. To provide a 
> > *fo

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

On Sat, Jul 02, 2005 at 01:06:02AM +0100, Tim Bunce wrote:
> Once upon a time I said:

I'm back now and, after digesting a small mountain of non-DBI related
emails, I'll start digesting all your replies and getting up to speed
with Perl 6.

Many thanks to all who replied on and off-list.

Tim.

Re: Container model - pictures and questions

[Tim Bunce]

[I'm going to be a little pedantic here because I think it's worth it
given the need for clarity.]

On Sun, Aug 07, 2005 at 12:55:53AM +0800, Autrijus Tang wrote:
> On Sat, Aug 06, 2005 at 12:43:13PM -0400, Matt Fowles wrote:
> > The pictures are pretty and the compilation one makes a great deal of
> > sense, but I must admit to being enitrely confused by the container
> > one.  I think part of the problem is that I don't have a good footing
> > from which to understand it.  Is there somewhere I can look for a
> > gentle explanation of the whole container/tied/untied thing?
> 
> Hm, I'm afraid there are not much material on this beyond the Synopses,
> so I'll try to describe that picture a bit.
> 
> First off, all the lines you see are "has-a" relationships.  To wit:
> 
> Pad has-a Scalar Container that you can look up with "$name".
> 
> my $name;
> 
> The Container either has-a mutable cell, or has-a constant cell.
> 
> my $mut = 3;
> my $con := 3;
> 
> Use ":=" to change the cell inside a container:

How about:

  Use ":=" to change the container to have a different cell.

because "change the cell" could be misleading. The cell itself
isn't modified.

This is (I presume) essentially the same this Perl 5 snippet:

$mut = 3;
*mut = \3; # change the SCALAR slot in the GLOB called 'mut'

> my $x = 3;
> my $y = 4;
> my $z = 5;
> $x := $y;   # $x and $y now contain the same cell
> $x := $z;   # not anymore; $x now shares the cell with $z
> 
> Each cell has a Id.  Use "=:=" to check whether two containers have
> cells of the same Id:
> 
> $x =:= $y;# false
> $x =:= $z;# true

It's hard to imagine two "containers" both containing the same cell.
The cell isn't really in two places at the same time.

What's missing from the description is that there's some form of
'pointer' from a container to the cell it currently contains.
(I'm trying to avoid using the term reference.)

The description of the container model might benefit from making that
pointer more explicit. It would help to clarify the action of the :=
operator. (And =:= ?)

Please correct me if I'm laboring under too much perl5 baggage or
confused in other ways.

Tim.

Translating (or at least parsing) Java interface definitions

[Tim Bunce]

Anyone done any work on parsing Java interface definitions?

And, ideally, translating them into roughly equivalent Perl 6?

Tim.

Parrot <-> Java integration

[Tim Bunce]

Anyone given any thought to Parrot <-> Java integration?

Possible?
Practical?
How much would would be involved?

Tim.

t/dynclass/gdbmhash.t failures

[Tim Bunce]

Configure.pl said

Determining if your platform supports gdbm.yes.

But t/dynclass/gdbmhash.t fails completely:

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
t/dynclass/gdbmhash.t   13  332813   13 100.00%  1-13

with errors like:

t/dynclass/gdbmhashNOK 1 
# Failed test (t/dynclass/gdbmhash.t at line 43)
#  got: 'no extension: file 'libgdbm'
# '
# expected: 'GDBMHash
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/dynclass/gdbmhash_1.pir"' 
failed with exit code 42
t/dynclass/gdbmhashNOK 2 
# Failed test (t/dynclass/gdbmhash.t at line 56)
#  got: 'no extension: file 'libgdbm'
# '
# expected: '0
# 1
# 0
# '

The compiler complained about gdbmhash.c but didn't fail:

cc -c -fno-common -no-cpp-precomp -DDEBUGGING  -pipe 
-I/opt/local/include -pipe -fno-common -Wno-long-double-g -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual 
-Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused 
-Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked 
-Wdisabled-optimization -falign-functions=16 -Wno-shadow  -DHAS_JIT -DPPC 
-DHAVE_COMPUTED_GOTO   -o gdbmhash.o -I/Users/timbo/perl/parrot/include 
-I/Users/timbo/perl/parrot/classes gdbmhash.c
In file included from gdbmhash.pmc:49:
/opt/local/include/gdbm.h:85: warning: function declaration isn't a 
prototype
gdbmhash.pmc: In function `Parrot_GDBMHash_get_integer':
gdbmhash.pmc:145: warning: function call has aggregate value
gdbmhash.pmc:147: warning: function call has aggregate value
gdbmhash.pmc: In function `Parrot_GDBMHash_get_string_keyed':
gdbmhash.pmc:229: warning: function call has aggregate value
gdbmhash.pmc: In function `Parrot_GDBMHash_get_bool':
gdbmhash.pmc:171: warning: function call has aggregate value

/opt/local/include/gdbm.h:85 reads:

extern GDBM_FILE gdbm_open __P((char *, int, int, int, void (*)()));

This is on OSX 10.4 with a recent svn update:

    Last Changed Rev: 8966
Last Changed Date: 2005-08-15 04:57:58 +0100 (Mon, 15 Aug 2005)

Tim.

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

On Sat, Jul 09, 2005 at 10:25:32PM +1000, Adam Kennedy wrote:
> >In particular, the DBI must not mandate impossible levels of support from 
> >the drivers. It will benefit you nothing if the DBI is immaculate and 
> >wonderful and incredibly all-singing and all-dancing, but no-one can write 
> >a driver for it because the requirements cannot be met by the actual DBMS 
> >that Perl + DBI needs to work with.
> 
> I concur. Like CPAN as a whole, DBI's strength is in it's complete and 
> near universal coverage of all databases, and insanely great (and 
> occasisionally greatly insane) drivers that do strange and wonderful things.
> 
> If we start sacrificing drivers by raising the bar too high, DBI as a 
> whole suffers. Anyone proposing new features for DBI needs to be 
> extremely careful of CYJ syndrome.
> 
> Can't You Just (or sometimes Could You Just) syndrome is described here.
> 
> http://c2.com/cgi/wiki?CouldYouJust
> http://www.oreillynet.com/pub/wlg/3593
> http://c2.com/cgi/wiki?JustIsaDangerousWord
> 
> Go read them now. I'll wait...

That's a significant part of what happened to perl5-porters in The Bad Years.

Many more talkers than doers and much use of "we could do ..." when
the doing would clearly have to be done by someone else.

> I have an increasing suspicion that having open design processes like 
> the Tim's call for comments plays a big part in it as well.

Did I ever say we'd have an open design process?  :-)

I just called for suggestions, proposals, and random thoughts.
It's my job to mix those in with my own random thoughts and
try to distill something reasonably coherent and Practical.

Then we'll go round the loop a few (dozen) times kicking the tires
and mixing metaphors till enough people are happy enough.
(I get the casting vote on behalf of the silent majority :)

I was a little dissapointed that there wasn't greater focus on using
Perl6 features - especially as it would have helped kick-start my own
understanding of Perl6 topics that I expect to be significant (such as
Roles and Pairs, to pick two at random). Perhaps the community of
Perl6+DBI users is too small at this point.

And nobody mentioned JDBC as a potential model. Odd that.

Still, I'm sure things will liven up once I've put an initial sketch
together...

Tim.

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote:
> On 8/16/05, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > I was a little dissapointed that there wasn't greater focus on using
> > Perl6 features - especially as it would have helped kick-start my own
> > understanding of Perl6 topics that I expect to be significant (such as
> > Roles and Pairs, to pick two at random). Perhaps the community of
> > Perl6+DBI users is too small at this point.
> 
> I'm afraid that DBI2 for Perl 6 will fall into the trap that I sometimes
> feel like DBI1 fell into: the curse of being designed before the idioms and
> Best Practices of API design in the language have been established.
>
> I think it'll take years, and much actual production experience building
> Perl 6 modules before the community learns what works and what doesn't for a
> Perl 6 API (let alone implementation).  So trying to pin down a "properly
> Perl-6-ish" API before Perl 6 is even through the language design process
> strikes me as a Very Bad Idea.

I remember the early years of Perl 5 development, when a new feature was
added there'd be a period of over-zealous use followed by a hangover as
all the problems and edge-cases became apparent.

With Perl 6 there's going to be some almighty hangovers :)

> That could explain why there were so few Perl 6 related suggestions: no one
> knows how to design a good Perl 6 API yet, and any guess is very likely to
> be wrong.  Instead, suggestions have focused on what we do know: DBI in Perl
> 5 and Perl 5 API design.  In that spirit, here's my suggestion: no more
> configuration through magic/tied hashes. (e.g., $dbh->{'AutoCommit'} = 1)
> (Probably goes without saying, but I wanted to make sure someone said it ;)

Hey, it seemed like a good idea at the time :)

(Actually it's still a good idea in many ways, especially in relation to
its behaviour for unknown driver-private attributes and DBI version skew.
But it does need rethinking for DBI2.)

> Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999
> after that.  Basically, get one or two willing DBD authors who will help you
> to test and then throw away the first two attempts at a Perl 6 DBI API.
> Then at least you'll have some confidence when you commit to a DBI 2.0
> API...which will be several years after Perl 6 is released, I hope.

It'll be DBI 2 as DBI 1 still has a very long life ahead of it, but
it'll be DBI 2.0.00xxx for quite a while :)

> Of course, *someone* has to "go first" so we can all learn what works best
> in Perl 6.  I'm just saying that maybe DBI, which took the bullet in Perl 5
> to some degree, is under no obligation to do so again.  (This assumes that
> we'll have some way to use Perl 5 DBI within Perl 6 to tide us over, of
> course...) 

I'm in no great rush as one of my core assumptions is that DBI v1 will
be available in Perl 6 via either Ponie or direct embedding of libperl5.so.

Tim.

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

On Tue, Aug 16, 2005 at 01:16:19PM -0700, Darren Duncan wrote:
> At 4:04 PM +0100 8/16/05, Tim Bunce wrote:
> >I was a little dissapointed that there wasn't greater focus on using
> >Perl6 features - especially as it would have helped kick-start my own
> >understanding of Perl6 topics that I expect to be significant (such as
> >Roles and Pairs, to pick two at random). Perhaps the community of
> >Perl6+DBI users is too small at this point.
> 
> One way that the Perl 6 thought process can be started is in 
> considering the design principles laid out in Damian's new Best 
> Practices book.  I said to Damian at OSCON that I thought the 
> practices he was putting forward were intended to get people thinking 
> now in Perl 5 about ways of doing things that will be the natural way 
> of doing them in Perl 6; he said something along the lines that I had 
> good insight.  So these practices are probably some good things to 
> keep in mind as we move forward.

Yeap. I'm awaiting delivery of that one, plus several others including
MJDs Higher Order Perl.

> Now, speaking specifically in Perl 6 terms ...
> 
> I suggest that DBI v2 has a more formal separation between interface 
> and implementation.  The parts of DBI can be grouped into these 
> categories:
> 
> 1. Role definitions for the public behaviour/API that DBI-using apps see.
> 2. Role definitions for the behaviour/API that DBI drivers/engines must have.
> 3. Class definitions that implement #1 and invoke #2.
> 4. Class definitions having a generic implementation of #2 or parts 
> thereof, which a driver/engine can complete or override.
> 5. Basic utility classes that exist to the side of the above, which 
> such as DBI drivers can optionally use to do some common things 
> without rolling their own.
> 6. A basic test suite.

I agree entirely - except for the word "basic" in item 6 :)

One of the key things missing from DBI 1 was a test suite that could be
reused to test/validate different drivers.

Note that what you've described is essentially just what JDBC is.
Only JDBC has a comprehensive driver test/validate suite.

At the moment I'm thinking in terms of a Parrot-level DBDI modeled on
JDBC, with a thin Perl6-specific DBI layered on top. Other languages
targeting Parrot would have their own thin language adaption layers.

> I also recommend expelling some parts of the DBI distro into their 
> own distros and/or leaving them to third parties.  A prime example is 
> the proxy server/client stuff; that should be a separate project.

I'd like to see someone do a stateless proxy sometime (as I've
outlined previously) and I'll be ensuring there's a serializable RowSet
object available - but, yes, such things should be separate.

Tim.

Re: Parrot <-> Java integration

[Tim Bunce]

On Tue, Aug 16, 2005 at 04:39:06PM +0200, Nattfodd wrote:
> Tim Bunce wrote:
> 
> >Anyone given any thought to Parrot <-> Java integration?
> >
> >Possible?
> >Practical?
> >How much would would be involved?
> >
> >Tim.
>
> If I'm not mistaken, it's even one of the summer of code projects (see 
> http://www.perlfoundation.org/gc/grants/2005-googlesoc.html and 
> http://www.perlfoundation.org/news/2005/socperljavaintegration.html).

I'd looked at that and it's certainly interesting, but it's focused on
Perl 5, like Inline::Java.

> May be should you drag David Rusek to p6i :)

I've CC David, and also Patrick LeBoutillier, author of Inline::Java.

Hi Dave. Any news on progress? (The last blog update was several weeks
ago and the code repository's isn't available yet.)

Hello Patrick. Would you be interested in working on Parrot <-> Java
integration?

Tim.

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

On Tue, Aug 16, 2005 at 12:12:02PM -0700, Dean Arnold wrote:
> Tim Bunce wrote:
> 
> >And nobody mentioned JDBC as a potential model. Odd that.
> 
> I was sorely tempted to do so (and did mention it a few times in
> my posts, along w/ ODBC and ADO.NET), but there are some things about
> JDBC which rub me the wrong way (e.g., explicit set/get methods for every
> data type no true binding support; the lame "bulk" interface; etc.).
> I'm not crazy about all the DataSource business, either.

I think all those are fixable for Perl/Parrot. Same for the painful
need for try & catch every few lines.

> But the threading support, the Factory pattern presented by Statement
> classes, the nice separation of metadata from
> statements/resultsets/connections, and XA would certainly be nice
> models to follow.

That's what I'm thinking. Not only nice but also well proven and widely
understood.

> One area of concern I have is the ability to subclass. I've been
> struggling w/ trying to subclass+extend JDBC the same way I subclass
> DBI for some things, and haven't found any app-neutral solutions just
> yet (trying to wrap another JDBC driver and expose its driver specific
> methods seems to require a lot of extra heavy lifting).

There are lots of people who have problems or complaints about
subclassing the DBI :)

Tim.

Re: Perl 6 Summary for 2005-08-15 through 2005-08-22

[Tim Bunce]

On Mon, Aug 22, 2005 at 09:43:41PM -0400, Matt Fowles wrote:
> 
>Java on Parrot
> Tim Bunce asked some preliminary questions about Java on Parrot. I
> provide preliminary answers, and Nattfodd and Autrijus posted links to
> related work. The important question of what it should be called
> remained unraised. I vote for "Jot".
> <http://xrl.us/g8b9>

For the record, my interest isn't so much "Java ON Parrot" as "Java WITH 
Parrot".
Bidirectional interface between the Parrot VM and a linked-in Java VM.

Tim.

Re: Call for B0rked

[Tim Bunce]

On Wed, Aug 31, 2005 at 04:04:45PM -0700, chromatic wrote:
> Hi all,
> 
> In a recent discussion with Chip and Leo, the idea came up to ask for a
> list of very specific TODO items -- specifically things that should work
> but don't.  

Not very specific, but: "whatever Ponie needs most".

I'm sure Nicholas can come up with something more specific!

Tim.

Re: HLL Namespace Design

[Tim Bunce]

On Mon, Sep 05, 2005 at 01:43:20PM -0400, Matt Diephouse wrote:
> In order to help finish Parrot's HLL namespace support, I've compiled
> a list of features and information that I believe is necessary to
> support the target languages. I've done so after doing a survey of
> these languages. I may have missed something or misunderstood
> something: please check that this information matches what you know
> about these languages.
> 
> It is my intent that this be merely a factual document. I want to
> begin on the implementation details only after we have a clear
> specification.
>
> Naming Strategies and Storage
> 
>   Different languages store their variables and subroutines/methods in 
> different
>   ways and places. Parrot must support all of these and, if possible, allow
>   interoperability.
> 
>   Types
> 1. Python: Variable and subroutine/method names overlap; you cannot have 
> two
>items that share the same name.
> 2. Ruby, Tcl: Variable and subroutine/method names do *not* overlap.
> 3. Perl 5: Globs prevent overlap.
> 4. Perl 6: Sigils prevent name collisions.


> Default Namespaces
> 
>   Python:   __main__
>   Ruby: main
>   Tcl:  ::
>   Perl5:main
>   Perl6:::*Main

I think it would be worth mentioning if the namespace is hierarchical
(nested) or flat (the delimiters are part of the name).

Another issue is whether there's an underlying hierarchy that can be
accessed (at leaf and/or non-leaf nodes) to do things like namespace aliasing:

  *Short:: = \%Very::Long::Name::; # (possibly incorrect p5 syntax :)

> Namespace Capabilities
> 
>   - Importing
>   Items must be imported from one namespace to another. Tcl requires that
>   this be a snapshot - meaning that changes in the original namespace do
>   not affect the imported items - while other languages use aliases.
> 
>   Items can be specified by tags (:all, :default), by patterns (c*), or by
>   names.

How items are specified for import/export seems to me a HLL-private issue
and not one that need to be part of this specification.

>   - Exporting
>   Not all items can be exported; a list must be kept of which items can 
> be. 
>   These items can also be specified by tags, patterns, and names. Patterns
>   are not expanded until the time of the import (which may occur more 
> than once).

Same here.

(I'm just trying to keep focused on the Parrot-relevant issues.)
I think it would be a bad idea to try to implement direct support for
specific HLL behaviours in Parrot. Better to distill a set of primitives
that HLLs can use as a foundation.

Perhaps you're more focused on the HLL issues because of the need for
interoperability. I'd argue that interoperability doesn't need to be
easy, it just needs to be a) possible, and b) encapsulate-able.
Given those then "easy" can be implemented via add-on modules
that encapsulate the messy details.

To give a more concrete example: Parrot itself shouldn't have to
understand the semantics of the Perl5 Exporter module in order for
a Python module to import symbols from a Perl5 module.
That kind of understanding belongs in a separate module.

It may help to think of the HLLs as objects with methods that handle
HLL-specific details. Perhaps HLL_specific subclasses of a Namespace PMC.
Something vaguely like:

  $python_namespace->foreign_import( $perl5_namespace->foreign_export(...) )

The issues then become: what gets passed between them, and what
few basic underlying parrot primitives are needed to support them.

The same applies to unimporting and querying.

---

Having said all that, I don't think it's worth worrying about
inter-language issues until more fundamental namespace co-existance
issues are more settled.

Will a Python module clash with a Perl6 module of the same name?
(That way lies insanity so I certainly hope not.)

If not then separate namespace hierarchies are required.

The most natural way to do that is to give each HLL its own
'virtual root' near the top of a shared namespace hierarchy.

See this thread, especially message 16 (and then 13,14,15 :)
http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/678fbfc5a14813b5

How close is Parrot to supporting that functionality now?
(Please excuse me and point me to the docs if this is already settled.)

Tim.

Re: HLL Namespace Design

[Tim Bunce]

On Tue, Sep 06, 2005 at 02:22:23PM +0100, Jonathan Worthington wrote:
> "Tim Bunce" <[EMAIL PROTECTED]> wrote:
> >Having said all that, I don't think it's worth worrying about
> >inter-language issues until more fundamental namespace co-existance
> >issues are more settled.
> >
> >Will a Python module clash with a Perl6 module of the same name?
> >(That way lies insanity so I certainly hope not.)
> >
> >If not then separate namespace hierarchies are required.
> >
> >The most natural way to do that is to give each HLL its own
> >'virtual root' near the top of a shared namespace hierarchy.
>
> It seems to me that this would mean that to use a module we always have to 
> care about what language it is written in.

Not a great hardship, and probably even important for non-trivial cases.

> Yes, I agree that we don't want 
> clashes and it's for sure that some languages we support will have clashing 
> name spaces even in their standard libraries.  So something like what is 
> suggested here is very much needed.
> 
> At the same time, glancing at the .NET platform, if I remember correctly 
> you don't have to care what language another class was implemented in to 
> use it - you just go ahead and use it - which is nice.

.NET started with a clean slate. We don't have that luxury.

> (It means, for example, that the Perl 5 module that a Python program
> was using, on conversion to Perl 6, doesn't break the Python program
> because it's still looking in the Perl 5 namespace.)

That ought to be a one line change (and here I'm ignoring the same heap
of practical difficulties that you are :-).

Having said that, it's possible that perl5 and perl6 could share the
same namespace.

> But maybe "look everywhere by default" is the wrong behaviour and could 
> create all kinds of confusion.  So maybe (assuming we're writing in P6):-
> 
> use perl5:What::Ever;   # Only look in the Perl 5 namespace.
> use What::Ever;# Only look in the Perl 6 namespace.
> use *:What::Ever; # Look in any name space - not sure * will work 
> though.

Perl6 will have a layer of indirection between the short module name
in the code and the long module name that gets loaded. So there's
flexibility that can be used to get the behaviour you desire.

> I can think some stuff up on a Parrot level for this, if anyone believes 
> this idea worth considering.

This is certainly an area that needs more thought.

Tim.

Class::Role, Class::Roles, and run-time role composition for Perl5

[Tim Bunce]

The Class::Role and Class::Roles modules on CPAN implement a form of
compile-time Perl6 role composition for Perl5.

Neither supports run-time role composition, as-in:
http://dev.perl.org/perl6/doc/design/syn/S12.html#Roles

The does operator returns the object so you can nest mixins:

$fido does Sentry does Tricks does TailChasing does Scratch;

Unlike the compile-time role composition, each of these layers on a new
mixin with a new level of inheritance, creating a new anonymous class
for dear old Fido, so that a .chase method from TailChasing hides a
.chase method from Sentry.

To help with DBI v2 I need a Perl5 implementation of roles that supports
run-time role composition.

I figure it just needs to generate a new class with @ISA set to
ref($random_object), link-in the methods, then rebless $random_object into it.
Plus a cache to avoid setting up a new class if it's already generated
one for ref($random_object)+$role_name.

I'd work on it myself but I'm busier than usual at the moment[1] and I
don't know which of Class::Role or Class::Roles I should add it to.
If no one volunteers I'll have a go in a week or three.

Tim.

[1] Our second child will be arriving 'any day'.

p6d gatewayed by nntp.perl.org?

[Tim Conrow]

I'm not seeing it. My problem, or is it not being mirrored yet?

-- Tim

Re: p6d gatewayed by nntp.perl.org?

[Tim Conrow]

Simon Cozens wrote:


[EMAIL PROTECTED] (Tim Conrow) writes:

>I'm not seeing it. My problem, or is it not being mirrored yet?


I'm reading it via NNTP.



Right, I've got it now. Don't know why I didn't see it there before.

-- Tim

Re: purge: opposite of grep

[Tim Conrow]

Michael Lazzaro wrote:


I worry that C sounds too much like something class-related,
and would confuse people.  What about C or something?  Decent
thesaurus entries for  include:

assign, classify, comb, compartmentalize, discriminate, distribute,
group, order, segregate, sift, winnow, amputate, cut, dismember, excise,
lop, disunite, divorce, estrange, part, wean, detach, disconnect,
disengage, dissociate, extract, isolate, part, steal, take, uncouple,
withdraw



designate?

-- Tim

The Judy algorithm

[Tim Bunce]

I think this might be interesting to some of you...

  "Judy is a general purpose dynamic array implemented as a C callable
  library. Judy's speed and memory usage are typically better than
  other data storage models and improves with very large data sets."

http://judy.sourceforge.net/application/10minutes.htm
http://judy.sourceforge.net/application/
http://sourceforge.net/projects/judy

I've appended a few extracts from the "10minutes.htm" url given above.

Tim.

A (CPU) cache-line fill is additional time required to do a read
reference from RAM when a word is not found in cache. In today's
computers the time for a cache-line fill is in the range of 50..2000
machine instructions. Therefore a cache-line fill should be avoided
when fewer than 50 instructions can do the same job. (Modern machines
tend to pipeline writes to RAM. They often take no additional time
in the Judy design.)

Some of the reasons Judy outperforms binary trees, b-trees, and skip-lists:

* Judy rarely compromises speed/space performance for simplicity
  (Judy will never be called simple except at the API).

* Judy is designed to avoid cache-line fills wherever possible.
  (This is the main design criteria for Judy.)

* A b-tree requires a search of each node (branch), resulting
  in more cache-line fills.

* A binary-tree has many more levels (about 8X), resulting in
  more cache-line fills.

* A skip-list is roughly equivalent to a degree-4 (4-ary) tree,
  resulting in more cache-line fills

>From a speed point of view Judy is chiefly a 256-ary digital tree
or trie (per D. Knuth Volume 3 definitions). A degree of 256-ary
is a somewhat "magic" N-ary for a variety of reasons -- but mostly
because a byte (the least addressable memory unit) is 8 bits. Also
a higher degree means reduced cache-line fills per access. You see
the theme here -- avoid cache-line fills like the plague.

The presence of a CPU cache in modern machines has changed many of
the ways to write a performance algorithm. To take advantage of a
cache, it is important to leverage as much as possible. In a Judy
tree, the presence of a cache results in 1..3 (or more) fewer
cache-line fills per lookup than would be possible without a cache.

Judy adapts efficiently to a wide range of populations and data set
densities. Since the Judy data structure is a tree of trees, each
sub-tree is a static expanse that is optimized to match the "character"
or density of the keys it contains.

Notice that to insert or delete a key is almost as simple as setting
or clearing a bit.

Re: The Judy algorithm

[Tim Bunce]

On Mon, Mar 10, 2003 at 03:33:38PM +0100, Elizabeth Mattijsen wrote:
> At 10:37 + 3/10/03, Tim Bunce wrote:
> >I think this might be interesting to some of you...
> >  "Judy is a general purpose dynamic array implemented as a C callable
> >  library. Judy's speed and memory usage are typically better than
> >  other data storage models and improves with very large data sets."
> >
> >http://judy.sourceforge.net/application/10minutes.htm
> >http://judy.sourceforge.net/application/
> >http://sourceforge.net/projects/judy
> >I've appended a few extracts from the "10minutes.htm" url given above.
> 
> This looks very interesting (particularly for a project I'm working 
> on now, which was the reason I looked into this right now), but the 
> project really seems quite silent if not dead.

I emailed Doug [CC'd] with your concerns. Here's his reply.

Tim.

From: [EMAIL PROTECTED]
Subject: Re: (Fwd) Re: The Judy algorithm
Date: Mon, 10 Mar 2003 22:40:25 

Tim:

I will try to reply to your concerns below.

> Doug,
> 
> I've just flagged Judy to the perl6-internals list (who are developing
> the 'parrot' virtual machine) and they've raised some concerns (below).
> 
> Could you tell me about the status of the Judy code.
> Is it being maintained?

Yes, but I am not much of a process person.  The versions that install and
compile other platforms are prelimary and need more testing.  They are 
available in <http://judy.sourceforge.net/downloads> (see README).  


> 
> Tim.
> 
> - Forwarded message from Elizabeth Mattijsen <[EMAIL PROTECTED]> -
> 
> Delivered-To: [EMAIL PROTECTED]
> In-Reply-To: <[EMAIL PROTECTED]>
> Date: Mon, 10 Mar 2003 15:33:38 +0100
> To: Tim Bunce <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> From: Elizabeth Mattijsen <[EMAIL PROTECTED]>
> Subject: Re: The Judy algorithm
> 
> At 10:37 + 3/10/03, Tim Bunce wrote:
> >I think this might be interesting to some of you...
> >  "Judy is a general purpose dynamic array implemented as a C callable
> >  library. Judy's speed and memory usage are typically better than
> >  other data storage models and improves with very large data sets."
> >
> >http://judy.sourceforge.net/application/10minutes.htm
> >http://judy.sourceforge.net/application/
> >http://sourceforge.net/projects/judy
> >I've appended a few extracts from the "10minutes.htm" url given above.
> 
> This looks very interesting (particularly for a project I'm working 
> on now, which was the reason I looked into this right now), but the 
> project really seems quite silent if not dead.
> 
> 
> Some more info:
> Only HP-UX and Linux seem to be supported out of the box (only tried 
> Linux and Mac OS X).
> 
> I adapted the indexSL program to just be a filter and piped 
> /usr/share/dict/words through it.  Then let it run with Valgrind. 
> That reports:
> 
> ==11948== LEAK SUMMARY:
> ==11948==definitely lost: 11 bytes in 1 blocks.
> ==11948==possibly lost:   26 bytes in 2 blocks.
> ==11948==still reachable: 0 bytes in 0 blocks.
> 
> Not a whole lot of leakage, but still.

I agree any leakage is unacceptable.  However, Judy is tested carefully
to not have leakage.  Memory usage (from malloc()) is kept internally to the 
structure and must subtract (free()) to exactly zero when the last element is 
deleted from the array. Perhaps there is a problem in the measurement.
I would like to know more about the measurement to be certain that the 
problem is not in Judy.  JudyL and Judy1 only allocate blocks in multiples
of 4 bytes.

> 
> 
> I got the configure script into believing that MacOS X is really 
> Linux.  Compilation then halts on
> byteswap.h being missing.  I didn't look any further then.

The versions in the download directory (mentioned above) should solve 
this problem.  However, I think it requires gmake.

> 
> 
> The forum seems to be missing answers from the primary (only) 
> developer.  Bug reports with patches have not been applied (such as 
> trivial bashisms in the configure script).
> 
> 
> The application directory contains some nice examples that might be 
> applicable to Parrot: especially the "best of both worlds" approach 
> in which Judy arrays are used to handle hash value collisions on a 
> rather small (256 or 64K keys) hash.

If a hashing scheme (of strings) is able to solve your problem (just store and 
retrieves) then I suggest using JudyL inplace of your normal hash table.  This 
makes a very scalable hashing method.  The performance is better than any known
tree method (including JudySL).

> 
> 
> 
> Just my 2 eurocents worth (which appear to be worth more than 2.1 US$ 
> cents nowadays ;-)
> 
> 
> Liz
> 
> - End forwarded message -
>
 
I will be available for your questions and comments.

Doug Baskins <[EMAIL PROTECTED]>

Re: Type Conversion Matrix, Pragmas (TAKE 4)

[Tim Bunce]

On Tue, Jun 10, 2003 at 12:04:14PM -0700, Michael Lazzaro wrote:
> 
> *: (undefness and properties lost)
> 
>Using/converting an uppercase type as/to a lowercase (primitive)  
> type is silently allowed.  If you're sending an Int to something that  
> requires an C, you know that the 'something' can't deal with the  
> undef case anyway -- it doesn't differentiate between undef and zero.   
> Thus, you meant to do that: it's an "intentionally destructive"  
> narrowing, and the C becomes a C<0>.
> 
>   my Int $a = undef;
>   my int $b = $a; # $b is now C<0>, NOT C

I'm not sure what "silently allowed" means here (compile time perhaps?)
but I'd certainly want that to generate the traditional "Use of undefined
value" warning (controlable via the perl6 equiv of the warnings pragma,
but defaulting to enabled).


> F: (float to int)
> 
>Historically, accidentally using a float as an int can be a  
> significant source of errors.  Proposed pragma variants:
> 
>use strict conversions allow => << num_to_int >>;   # which is the default?
>use strict conversions  warn => << num_to_int >>;
>use strict conversions  fail => << num_to_int >>;

I don't see a problem with compile time warnings by default *if*
there's an easy way for the developers to express the fact that
they know what they're doing (easier, that is, than wrapping the
assignment in a { use strict conversions allow ... } block).
Something like a cast function would fit: $int = int($num);


> N: (numeric range)
> 
>This one is a giant pain.  Converting, say, an Int to an int will,  
> in fact, fail to do the right thing if you're in BigInt territory, such  
> that the number would have to be truncated to fit in a standard .   
> But 99% of the time, you won't be working with numbers like that, so it  
> would seem a horrible thing to disallow Int --> int and Num --> num  
> conversions under the remote chance you *might* be hitting the range  
> boundary.  Then again, it would seem a horrible thing to hit the range  
> boundary and not be informed of that fact.  Thus, deciding the default  
> state here will be a challenge:
> 
>use strict conversions allow => << Int_to_int >>;   # which is the default?
>use strict conversions  warn => << Int_to_int >>;
>use strict conversions  fail => << Int_to_int >>;
> 
>use strict conversions allow => << Num_to_num >>;   # which is the default?
>use strict conversions  warn => << Num_to_num >>;
>use strict conversions  fail => << Num_to_num >>;

Same as above. I could live with a compile time warning if it's
trivial to silence it for a particular assignment.

But I'd also like separate control over the detection and behaviour
of underflow / overflow / loss of precision etc at runtime.
So if I assign an int a value that's too big (from a Int, or Num,
or untyped scalar), I would like to know about it. Similarly for num.


> (v)  Alternative Pragma Form 
> 
>   An alternative pragma form could possibly allow finer control over  
> every individual possible conversion.  The disadvantage of this form is  
> that it would be very difficult to "correctly" set each of the >100  
> cells of the matrix, or even the 14 "critical" cells that most often  
> change:

Perhaps it would be better to think in terms of "styles of coding"
or "policies", and aim to meet those needs with simple pragmas
(implemented on top of a more general mechanism).

Basically, do both. The simple forms could just be an interface to
the more general.


> (vi)  Conversions of User Defined Types/Classes 
> 
>   It may be useful to allow the same level of pragma-based control for  
> user-defined types and classes.  For example, a given class Foo may  
> wish to be "silently" convertable to an C.  One proposed syntax to  
> declare the method of coercion/conversion might be:
> 
> class Foo {
> ...
> 
> to int {...}  # or C?
> }
> 
> However, users of such a class could adjust the warning level of the  
> given conversion using the alternate syntax given above (v):
> 
> use strict conversions warn { Foo => int };

For
my int $int = $foo;

isn't the int() method (vtable entry) called on $foo? (effectively)
So the $foo object is asked to provide an int for assigment to $int.
So the Foo class gets to decide how to do that.

In which case what you're proposing requires either
- the compiler to write the code to pass extra flags to the int method
- the compiler to write call a different int method (eg, int_warn())
- for the int method to look at the calling context to get flags

Please correct me if I'm wrong (which I could easily be as I've not
been following any of thise closely).

I think this is an important topic because it may reflect back on
how the specific Int/Num/Str classes should also be handled.

Tim [quite possibly talking nonsense]

Re: printf-like formatting in interpolated strings

[Tim Bunce]

On Mon, Jun 16, 2003 at 05:48:58PM +0100, Simon Cozens wrote:
> 
> But then I'm one of those freaks who likes the idea of keeping core Perl 6
> generic, extensible, clean and small, and letting all the clever stuff go 
> into extensions, a heretical position which is way out of favour with the
> more influential listfolk, so feel free to ignore my opinion.

FWIW I agree with you completely, and strongly.

If it can be outside the core it should be, unless there's a very
good reason why not.

But I guess I'm far from being an influential listfolk these days...

I console myself with a high level of trust in the core design team.

Tim [wandering off into the sunset to ruminate on DBI issues...]

Re: printf-like formatting in interpolated strings

[Tim Bunce]

Perhaps someone could post a summary of how the issue has been
tackled in other languages that support a similar concept.

I've not seen one (but then I've not been paying attention, so
forgive me if it's need done already, and perhaps point me to a url).

Tim.

Re: async i/o (was Re: This week's summary)

[Tim Bunce]

On Thu, Jul 03, 2003 at 05:10:23PM -0400, Uri Guttman wrote:
> >>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
> 
>   AB> Dan Sugalski wrote:
>   >> The more I think about this the more I want to punt on the whole
>   >> idea. Cross-platform async IO is just one big swamp.
> 
>   AB> Agreed.  Glug, glug, glug ;-)
> 
> who here will be at oscon (or yapc::eu)? i would like to get a small BOF
> going on this subject. i agree it is a morass but i have some ideas and
> i know dan has plenty. but we had better learn to swim these swamps and
> not get eaten by the gators. we can drain them, convert them to dry
> deserts and make them safe for camel caravans. :)

Has any other language learnt to swim well in these swamps?

Tim.

OT: Will the State of the Onion be posted online?

[Tim Howell]

Sorry for a slightly off-topic post, but will Larry's State of the Onion
be posted online soon?  Where would I find it?

Thanks!  =)

--TWH

Where can I help?

[Tim Howell]

I've got some extra time to spend on Parrot in the next few months and
I'd really like to get involved.  I have decent C and perl skills.
Where would I be most useful?

Thanks!  =)

--Tim Howell

Q: pdd06 Missing Operations...

[Tim Howell]

I've spent the past day reading through the parrot documentation.  I'm a
little confused by pdd06--shouldn't this contain a listing of ALL parrot
opcodes?  The first thing I noticed is that print isn't listed there;
shouldn't it be?  I'm sure there are lots of other opcodes missing as
well.  Is this something that I should take a crack at updating?

--TWH

Socket IO

[Tim Howell]

The TODO list from the current parrot CVS mentions socket IO.  Have
opcodes been designated for socket IO yet?  Is this up for someone to
start working on?

--TWH

make fails on MacOS X 10.2.6

[Tim Howell]

?tches from a few days ago to allow executable creation, the current CVS no longer 
compiles properly on my MacOS X 10.2.6 box.  The error I get is:

exec_save.c:319:16: #if with no expression
make: *** [exec_save.o] Error 1

The following patch seems to fix things, although I don't know if this is the best way 
to do it:

--- exec.hMon Jul 28 16:37:58 2003
+++ exec.h  Mon Jul 28 16:38:17 2003
@@ -25,7 +25,7 @@
 # define EXEC_A_OUT
 #   endif
 #   if EXEC_OS == DARWIN
-# define EXEC_MACH_O
+# define EXEC_MACH_O 1
 #   endif
 #   if (EXEC_OS == FREEBSD) || (EXEC_OS == LINUX)
 # define EXEC_ELF

Information on Just-in-Time compilers?

[Tim Howell]

Does anyone know of a website with good information on just-in-time
compilers?  I'm really intrigued by the idea of JIT (especially WRT
Parrot), but I don't have much background at all.

Thanks!  =)

--TWH