Re: Java::2Perl6API formerly Java::Javap
On Wed, Sep 01, 2010 at 05:32:52PM +0100, Tim Bunce wrote:
>
> So instead of method USELESS_CONSTANT (--> Int) is export { 4 }
> it now does method USELESS_CONSTANT (--> Int) is export { return 4; }
I've switched to the compact form and added escaping of embedded quotes
for string. I'm sure there are bugs lucking here if there are
mismatches between how java and perl handle backslashes, but it's good
enough for now and easy to fix later if need be.
> If you've time, I'd be delighted if you could update the TODO, to remove
> the section on constants, and start exploring anything else in there
> that takes your fancy.
If you, or anyone else, wants to take a stab at any of these, just go
ahead. No need to ask.
Tim.
Re: Java::2Perl6API formerly Java::Javap
On Tue, Aug 31, 2010 at 05:04:51PM -0500, Phil Crow wrote:
> I've figured out git, which you probably noticed.
Yeah!
> The error you found was not so subtle. When I tested previously I only
> tried an interface. Their methods have no code and thus no verbose output.
> I've just taught the grammar to handle at least the simplest case of verbose
> output for genuine methods.
Great.
> By the way, when I cloned I didn't get a manifest or a makefile.pl or
> build.pl. This makes it less convenient to run the tests.
Dist::Zilla (http://dzil.org/) is used to manage builds, installs and releases.
See the dist.ini file.
I normally run tests using:
$ prove -l lib t
(Though I think t/70_java2perl6.t will probably run the installed
java2perl6api script in that case.)
Speaking of tests, one fails now because your commit undid I change I'd
made to lib/Java/Javap/Generator/Perl6.pm to make constants less verbose:
http://github.com/timbunce/java2perl6/commit/0bed1ac2185789d196493e8c1d0a3487d6450b4b#diff-0
So instead of method USELESS_CONSTANT (--> Int) is export { 4 }
it now does method USELESS_CONSTANT (--> Int) is export { return 4; }
Was that accidental?
If you've time, I'd be delighted if you could update the TODO, to remove
the section on constants, and start exploring anything else in there
that takes your fancy.
Thanks again Phil!
Tim.
> Phil
>
> On Sun, Aug 29, 2010 at 4:33 PM, Tim Bunce wrote:
>
> > On Sat, Aug 28, 2010 at 06:40:10AM -0500, Phil Crow wrote:
> > >I've finished numeric and string constant handling through to
> > generation. To activate the feature add
> > >-verbose to your -javapopts. Without that you get the old ... behavior
> > regardless of constant type.
> >
> > Excellent! It's great to see the constant values in the generated perl6
> > code.
> >
> > I've committed the patch plus a few followups:
> > http://github.com/timbunce/java2perl6/commits/master
> >
> > I hit a couple of problems with the parser that I worked around:
> >
> > http://github.com/timbunce/java2perl6/commit/31c4259ba3d00e3a810e394c90caebbc3335eb17
> > but then I hit a similar one (with 'Code: ...') and realised there
> > might be a deeper problem here if the output of your javap -v isn't
> > the same as mine.
> >
> > I've tweaked t/00_load.t to report the java version. Mine says:
> ># java version "1.6.0_20"
> ># Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> ># Java HotSpot(TM) Client VM (build 16.3-b01-279, mixed mode)
> > What does yours say? And what OS are you developing on?
> >
> > I've left the code with javap -v enabled and t/03_class.t and t/55_final.t
> > failing. They now dump the javap output if the parse fails. The start of
> > the output for t/03_class.t on my system looks like this:
> >
> > ---snip---
> > Compiled from "FinalClassTest.java"
> > public final class FinalClassTest extends java.lang.Object
> > SourceFile: "FinalClassTest.java"
> > minor version: 0
> > major version: 49
> > Constant pool:
> > const #1 = Method #4.#13; // java/lang/Object."":()V
> > const #2 = String #14;//
> > const #3 = class#15;// FinalClassTest
> > const #4 = class#16;// java/lang/Object
> > const #5 = Asciz;
> > const #6 = Asciz()V;
> > const #7 = AscizCode;
> > const #8 = AscizLineNumberTable;
> > const #9 = AscizopenStream;
> > const #10 = Asciz ()Ljava/lang/String;;
> > const #11 = Asciz SourceFile;
> > const #12 = Asciz FinalClassTest.java;
> > const #13 = NameAndType #5:#6;// "":()V
> > const #14 = Asciz;
> > const #15 = Asciz FinalClassTest;
> > const #16 = Asciz java/lang/Object;
> >
> > {
> > public FinalClassTest();
> > Code:
> > Stack=1, Locals=1, Args_size=1
> > 0: aload_0
> > 1: invokespecial #1; //Method java/lang/Object."":()V
> > 4: return
> > LineNumberTable:
> > line 1: 0
> >
> > ---snip---
> >
> > It's seems like the Code block trips it up.
> >
> > (I don't know why "javap -classpath testjavas -v FinalClassTest" includes
> > "Code: ..." but "javap -classpath testjavas -v java.sql.PreparedStatement"
> > doesn't. I presume it's related to java.sql.PreparedStatement being a
> > class bundled with the system.)
> >
> > Could you "git pull" the current code and teach the parser what it needs
> > to know?
> >
> > Thanks Phil!
> >
> > Tim.
> >
Re: Java::2Perl6API formerly Java::Javap
On Sat, Aug 28, 2010 at 06:40:10AM -0500, Phil Crow wrote:
>I've finished numeric and string constant handling through to generation.
> To activate the feature add
>-verbose to your -javapopts. Without that you get the old ... behavior
> regardless of constant type.
Excellent! It's great to see the constant values in the generated perl6
code.
I've committed the patch plus a few followups:
http://github.com/timbunce/java2perl6/commits/master
I hit a couple of problems with the parser that I worked around:
http://github.com/timbunce/java2perl6/commit/31c4259ba3d00e3a810e394c90caebbc3335eb17
but then I hit a similar one (with 'Code: ...') and realised there
might be a deeper problem here if the output of your javap -v isn't
the same as mine.
I've tweaked t/00_load.t to report the java version. Mine says:
# java version "1.6.0_20"
# Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
# Java HotSpot(TM) Client VM (build 16.3-b01-279, mixed mode)
What does yours say? And what OS are you developing on?
I've left the code with javap -v enabled and t/03_class.t and t/55_final.t
failing. They now dump the javap output if the parse fails. The start of
the output for t/03_class.t on my system looks like this:
---snip---
Compiled from "FinalClassTest.java"
public final class FinalClassTest extends java.lang.Object
SourceFile: "FinalClassTest.java"
minor version: 0
major version: 49
Constant pool:
const #1 = Method #4.#13; // java/lang/Object."":()V
const #2 = String #14;//
const #3 = class#15;// FinalClassTest
const #4 = class#16;// java/lang/Object
const #5 = Asciz;
const #6 = Asciz()V;
const #7 = AscizCode;
const #8 = AscizLineNumberTable;
const #9 = AscizopenStream;
const #10 = Asciz ()Ljava/lang/String;;
const #11 = Asciz SourceFile;
const #12 = Asciz FinalClassTest.java;
const #13 = NameAndType #5:#6;// "":()V
const #14 = Asciz;
const #15 = Asciz FinalClassTest;
const #16 = Asciz java/lang/Object;
{
public FinalClassTest();
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: return
LineNumberTable:
line 1: 0
---snip---
It's seems like the Code block trips it up.
(I don't know why "javap -classpath testjavas -v FinalClassTest" includes
"Code: ..." but "javap -classpath testjavas -v java.sql.PreparedStatement"
doesn't. I presume it's related to java.sql.PreparedStatement being a
class bundled with the system.)
Could you "git pull" the current code and teach the parser what it needs
to know?
Thanks Phil!
Tim.
Re: Java::2Perl6API formerly Java::Javap
On Sat, Aug 21, 2010 at 05:37:19AM -0500, Phil Crow wrote: >I've modified the grammar to accept verbose output from javap and >to capture constant values. I'm one change away from making those >work generally in generated output. Wonderful! >So, I need a commit bit. Sure, I'll need a github account name for you. >I'm not much of an irc user. This four year old mac has no client. >So, I didn't ask on the freenode channel. Colloquy should work for you (http://colloquy.info/downloads.html) if you want to try it out. >I did sign up for the mailing list this morning. Great. Thanks Phil. Tim.
Re: Java::2Perl6API formerly Java::Javap
[CC'd to dbdi-...@perl.org] On Fri, Aug 13, 2010 at 08:41:35AM -0500, Phil Crow wrote: >Gmail confused my reading of this thread, so I didn't get to reply to this: > > I've a quick question for you (since I know practically zero Java)... > Given some large Java project, like a JDBC driver such as > [1]http://jdbc.postgresql.org/download.html > [2]http://dev.mysql.com/downloads/connector/j/ > what IDE-like tools would you recommend for browsing around the > files and visualizing the class structure? > >Eclipse is the best IDE for Java. It is an apache project (or so I >recall). It makes it very easy to browse structure by package, then >lets you build jar files with exactly what you want in them for >deployment. With subclipse ([3]http://subclipse.tigris.org/) it can >check out from svn, but the ones I've installed have always had cvs >support by default. Thnaks. I guessed it would be Eclipse. I'll install it when I get back home next week. (I'm on a semi-holiday in Italy at the moment). >Personal Update: >I've installed rakudo star and read the book that came with it. >Last night I wrote my first small grammar. So, now I'm ready to >ask: What do you have in mind for the Java-Perl translation? Looking at http://github.com/timbunce/java2perl6/blob/master/TODO I think the most important one is extracting the actual constant values and reproducing them in the perl6 role. I *think* the best way (or at least one way) is to extend the existing parser to parse the output of java -p. I think that's best done in perl5 otherwise we'd end up rewriting the whole thing. (Umm, unless we go with a perl6->json->perl5 approach but that seems rather twisted.) Another useful item would be better handling of enums, or pretty much anything else in the TODO that takes your fancy. Tim.
Re: [java2perl6] r100 committed - Implemented method to invoke the javap subprocess (invoke_javap)....
On Mon, Oct 05, 2009 at 05:19:23PM +0200, Cosimo Streppone wrote:
> Tim wrote:
>
>> To detect errors from javap I'd add something like
>>
>> or die "$JAVAP_EXECUTABLE @{[ %$options ]} @$classes failed.\n";
>>
>
> Is this ok?
>
> http://code.google.com/p/java2perl6/source/detail?r=101
It needs to be on the close() as well. A piped open will only fail if
the pipe(), fork(), or exec() syscals fail. It won't detect the javap
command exiting with an error status.
Tim.
Re: [java2perl6] r99 committed - Now the comp_stmt(?) rule triggers correctly....
That's great. Many thanks Cosimo! Tim. On Tue, Sep 29, 2009 at 09:29:11PM +0200, Cosimo Streppone wrote: > Cosimo committed r99: > >> Revision: 99 >> Author: cosimo.streppone >> Date: Mon Sep 28 13:29:30 2009 >> Log: Now the comp_stmt(?) rule triggers correctly. >> Fixed the grammar properly to allow clean regen of Java::Javap::Grammar. >> >> http://code.google.com/p/java2perl6/source/detail?r=99 >> >> Modified: >> /trunk/lib/Java/Javap/Grammar.pm >> /trunk/lib/Java/Javap/javap.grammar >> >> === >> --- /trunk/lib/Java/Javap/Grammar.pm Sun Sep 27 12:37:52 2009 >> +++ /trunk/lib/Java/Javap/Grammar.pm Mon Sep 28 13:29:30 2009 > > [...] > > The changes to Java/Javap/Grammar.pm look scary, > but this is just because the file has been regenerated > with the most recent Parse::RecDescent... > > -- > Cosimo
Re: [java2perl6] r98 committed - Tests pass successfully now....
On Sun, Sep 27, 2009 at 07:38:52PM +, codesite-nore...@google.com wrote:
> Revision: 98
> Author: cosimo.streppone
> Date: Sun Sep 27 12:37:52 2009
> Log: Tests pass successfully now.
> I think this is a bad hack, and probably doesn't make sense,
> as this file is probably autogenerated (?)
Yeap. It'll get blown away the next time it's rebuilt. That'll happen
if lib/Java/Javap/javap.grammar ever gets touched, because Makefile.PL
adds these rules to the Makefile:
all :: lib/Java/Javap/Grammar.pm
lib/Java/Javap/Grammar.pm: lib/Java/Javap/javap.grammar
cd lib/Java/Javap && perl -MParse::RecDescent - javap.grammar
Java::Javap::Grammar
We need to find a fix via the lib/Java/Javap/javap.grammar file.
Tim.
> use vars qw($skip $AUTOLOAD );
> $skip = '\s*';
>
> @@ -3132,9 +3133,16 @@
> q{comp_unit},
> $tracelevel)
> if defined $::RD_TRACE;
> - $item{q{comp_stmt(?)}} = $_tok;
> +
> + # Not sure why this was failing, but it appears to be matching
> only
> arrays
> + #$item{q{comp_stmt(?)}} = $_tok;
> +
> + # Assert comp_stmt result is array
> + if (ref $_tok ne 'ARRAY') {
> + Carp::croak "comp_stmt should match an array?";
> + }
> + $item{q{comp_stmt}} = $_tok->[0];
> push @item, $_tok;
> -
>
>
> Parse::RecDescent::_trace(q{Trying subrule: [comp_unit_decl]},
Re: Join the DBDI project
On Tue, Aug 11, 2009 at 10:41:01AM +0200, Cosimo Streppone wrote: > Hi Tim, > > I just read the recent messages on the DBDI mailing list, > and I'd like to join the list and the project. Wonderful. Welcome. Thanks! I believe joining the list just requires an (e.g., empty) email to dbdi-dev-subscr...@perl.org For commit access, send me an email address associated with a google account. Also hang out on the irc.freenode.org #dbdi channel. The're a log at http://irclog.perlgeek.de/dbdi/today > I will check out the current code and try to understand > how it works. Great. Having read the list you'll know that currently 'the code' is the java2perl6 tool. That's a steping stone on the path to DBDI. I'm aiming to write up "the plan" this week (before my vacation) so that'll force me to put some "flesh on the bones" on my hazy vision and mixed metaphors! > My motivation on this is to push perl6 forward. > We need applications. Agreed! The time has come. > Is there a tiny practical task I can start with? Good question. Apart from playing with java2perl6, start experimenting with the SQLite support in parrot. I haven't yet but it's probably one of the directions we'll need to move in soon so getting more experience in the team would be good. > Thanks! Thank you! Tim.
Re: [PATCH] Don't check for leading blank lines in
In and working (for me at least) now. Thanks!
Tim.
On Mon, Aug 10, 2009 at 04:40:18PM +0100, Tim Bunce wrote:
> On Mon, Aug 10, 2009 at 09:26:56AM +0100, Tim Bunce wrote:
> > Thanks, applied!
>
> But not committed. I'll try to sort out the underlying failure first.
> It's almost certainly a side effect of my messing with the type mapping.
>
> Tim.
>
> > Send me an email address associated with a google account and I'll add you
> > to the project so you can commit directly.
> >
> > Tim.
> >
> > On Mon, Aug 10, 2009 at 12:37:06AM +0200, Moritz Lenz wrote:
> > > Hi,
> > >
> > > attached patch for java2perl6 makes the tests files not check leading
> > > blank lines so strictly, which makes one test pass (and two others fail
> > > with more interesting diag() messages).
> > >
> > > Cheers,
> > > Moritz
> >
> > > Index: t/02_interface.t
> > > ===
> > > --- t/02_interface.t (revision 78)
> > > +++ t/02_interface.t (working copy)
> > > @@ -197,15 +197,10 @@
> > > );
> > > #warn $perl_6;
> > > $perl_6=~ s/^#.*//gm;
> > > +$perl_6=~ s/^\s+//;
> > > #diag($perl_6);
> > > my @perl_6 = split /\n/, $perl_6;
> > > -
> > > my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6';
> > > -
> > > -
> > > -
> > > -
> > > -
> > > use com::example::Second;
> > >
> > > role com::example::NestedIntTest {
> > > Index: t/03_class.t
> > > ===
> > > --- t/03_class.t (revision 78)
> > > +++ t/03_class.t (working copy)
> > > @@ -153,15 +153,11 @@
> > > );
> > > #warn $perl_6;
> > > $perl_6=~ s/^#.*//gm;
> > > +$perl_6=~ s/^\s+//;
> > > my @perl_6 = split /\n/, $perl_6;
> > > #use Data::Dumper::Simple;
> > > #diag($perl_6);
> > > my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6';
> > > -
> > > -
> > > -
> > > -
> > > -
> > > use java::lang::Object;
> > >
> > > class ClassTest is java::lang::Object {
> > > @@ -199,14 +195,10 @@
> > >);
> > >#warn $perl_6;
> > >$perl_6=~ s/^#.*//gm;
> > > + $perl_6=~ s/^\s+//;
> > >my @perl_6 = split /\n/, $perl_6;
> > > # diag("got: $perl_6");
> > >my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6_a';
> > > -
> > > -
> > > -
> > > -
> > > -
> > > use java::lang::Object;
> > >
> > > class dupMethodTest is java::lang::Object {
> > > @@ -229,4 +221,4 @@
> > > EO_Correct_Perl_6_a
> > >
> > >is_deeply( \...@perl_6, \...@correct_perl_6, 'emission - duplicate
> > > method signatures removed' );
> > > -}
> > > \ No newline at end of file
> > > +}
> >
Re: [PATCH] Don't check for leading blank lines in
On Mon, Aug 10, 2009 at 09:26:56AM +0100, Tim Bunce wrote:
> Thanks, applied!
But not committed. I'll try to sort out the underlying failure first.
It's almost certainly a side effect of my messing with the type mapping.
Tim.
> Send me an email address associated with a google account and I'll add you
> to the project so you can commit directly.
>
> Tim.
>
> On Mon, Aug 10, 2009 at 12:37:06AM +0200, Moritz Lenz wrote:
> > Hi,
> >
> > attached patch for java2perl6 makes the tests files not check leading
> > blank lines so strictly, which makes one test pass (and two others fail
> > with more interesting diag() messages).
> >
> > Cheers,
> > Moritz
>
> > Index: t/02_interface.t
> > ===
> > --- t/02_interface.t(revision 78)
> > +++ t/02_interface.t(working copy)
> > @@ -197,15 +197,10 @@
> > );
> > #warn $perl_6;
> > $perl_6=~ s/^#.*//gm;
> > +$perl_6=~ s/^\s+//;
> > #diag($perl_6);
> > my @perl_6 = split /\n/, $perl_6;
> > -
> > my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6';
> > -
> > -
> > -
> > -
> > -
> > use com::example::Second;
> >
> > role com::example::NestedIntTest {
> > Index: t/03_class.t
> > ===
> > --- t/03_class.t(revision 78)
> > +++ t/03_class.t(working copy)
> > @@ -153,15 +153,11 @@
> > );
> > #warn $perl_6;
> > $perl_6=~ s/^#.*//gm;
> > +$perl_6=~ s/^\s+//;
> > my @perl_6 = split /\n/, $perl_6;
> > #use Data::Dumper::Simple;
> > #diag($perl_6);
> > my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6';
> > -
> > -
> > -
> > -
> > -
> > use java::lang::Object;
> >
> > class ClassTest is java::lang::Object {
> > @@ -199,14 +195,10 @@
> >);
> >#warn $perl_6;
> >$perl_6=~ s/^#.*//gm;
> > + $perl_6=~ s/^\s+//;
> >my @perl_6 = split /\n/, $perl_6;
> > # diag("got: $perl_6");
> >my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6_a';
> > -
> > -
> > -
> > -
> > -
> > use java::lang::Object;
> >
> > class dupMethodTest is java::lang::Object {
> > @@ -229,4 +221,4 @@
> > EO_Correct_Perl_6_a
> >
> >is_deeply( \...@perl_6, \...@correct_perl_6, 'emission - duplicate
> > method signatures removed' );
> > -}
> > \ No newline at end of file
> > +}
>
Re: [PATCH] require Data::Dumper::Simple
"Data::Dumper::Simple is actually a source filter that ..."
Eeek! I'd be happy to loose the dependency. I don't think it's worth it.
Tim.
On Mon, Aug 10, 2009 at 12:21:32AM +0200, Moritz Lenz wrote:
> Hi,
>
> java2perl6 uses Data::Dumper::Simple (at least for the tests, it seems)
> but doesn't note it as a prerequisite. This patch adds it to Makefile.PL.
>
> Cheers,
> Moritz
> Index: Makefile.PL
> ===
> --- Makefile.PL (revision 78)
> +++ Makefile.PL (working copy)
> @@ -13,6 +13,7 @@
> PREREQ_PM => {
> Template => '2.0',
> Parse::RecDescent => '1.0',
> +Data::Dumper::Simple => 0,
> }, # e.g., Module::Name => 1.1
> EXE_FILES => [ $java2perl6 ],
> ABSTRACT_FROM => 'lib/Java/Javap.pm', # retrieve abstract from module
Re: [PATCH] Don't check for leading blank lines in
Thanks, applied!
Send me an email address associated with a google account and I'll add you
to the project so you can commit directly.
Tim.
On Mon, Aug 10, 2009 at 12:37:06AM +0200, Moritz Lenz wrote:
> Hi,
>
> attached patch for java2perl6 makes the tests files not check leading
> blank lines so strictly, which makes one test pass (and two others fail
> with more interesting diag() messages).
>
> Cheers,
> Moritz
> Index: t/02_interface.t
> ===
> --- t/02_interface.t (revision 78)
> +++ t/02_interface.t (working copy)
> @@ -197,15 +197,10 @@
> );
> #warn $perl_6;
> $perl_6=~ s/^#.*//gm;
> +$perl_6=~ s/^\s+//;
> #diag($perl_6);
> my @perl_6 = split /\n/, $perl_6;
> -
> my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6';
> -
> -
> -
> -
> -
> use com::example::Second;
>
> role com::example::NestedIntTest {
> Index: t/03_class.t
> ===
> --- t/03_class.t (revision 78)
> +++ t/03_class.t (working copy)
> @@ -153,15 +153,11 @@
> );
> #warn $perl_6;
> $perl_6=~ s/^#.*//gm;
> +$perl_6=~ s/^\s+//;
> my @perl_6 = split /\n/, $perl_6;
> #use Data::Dumper::Simple;
> #diag($perl_6);
> my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6';
> -
> -
> -
> -
> -
> use java::lang::Object;
>
> class ClassTest is java::lang::Object {
> @@ -199,14 +195,10 @@
>);
>#warn $perl_6;
>$perl_6=~ s/^#.*//gm;
> + $perl_6=~ s/^\s+//;
>my @perl_6 = split /\n/, $perl_6;
> # diag("got: $perl_6");
>my @correct_perl_6 = split /\n/, <<'EO_Correct_Perl_6_a';
> -
> -
> -
> -
> -
> use java::lang::Object;
>
> class dupMethodTest is java::lang::Object {
> @@ -229,4 +221,4 @@
> EO_Correct_Perl_6_a
>
>is_deeply( \...@perl_6, \...@correct_perl_6, 'emission - duplicate method
> signatures removed' );
> -}
> \ No newline at end of file
> +}
Re: What needs doing...
On Fri, Aug 07, 2009 at 03:05:33PM -0700, Todd Presta wrote: >I gave it a whirl on the Win32 platform and all but one of the tests > failed after attempting to build >java2perl6, apparently due to the system calls to javap using backticks. I > did a quick workaround >locally with IPC::Open2 instead and got a bit further, but progress is > still incomplete at this point. >Will post more details when my local sandbox is Win32-ified. Great. Thanks Todd. Send me a goggle account email and I'll give you commit access so you can just check it in. Tim. > >-- Todd Presta >-- [1]http://www.asciiville.com > > > -------- > >From: Tim Bunce >To: dbdi-dev@perl.org >Cc: Tim Bunce ; crow.p...@gmail.com >Sent: Tuesday, August 4, 2009 5:00:08 PM >Subject: What needs doing... >I've applied a bunch of changes today. > >The current output of the [2]mkjdbc.pl script is appended below. >It's looking pretty good. (I'm using the latest rakudo from git) > >There are a few immediate issues... > >. . java.sql.SQLXML: jdbclib/java/sql/SQLXML.pm >ERROR (line 1): Invalid comp unit: Was expecting comp stmt > >javap normally outputs a line like "Compiled from "ByteOrder.java"" >for most classes, and that's assumed by the grammar. It seems that >that line isn't output for some classes. The grammar need updating >to account for that. (about 12 of the failures are due to that.) > >. . . . java.sql.DatabaseMetaData: checking > jdbclib/java/sql/DatabaseMetaData.pm >Can't find ./java/util/Properties in @*INC >in Main (src/gen_setting.pm:445) >[...] >. . . . java.util.Properties: jdbclib/java/util/Properties.pm > >For some reason the fact that java.sql.DatabaseMetaData references >java.util.Properties wasn't noticed, so the generated >[3]DatabaseMetaData.pm was checked before java.util.Properties was >generated. Assorted other classes are affected in a similar way. >That needs fixing. > >There are a couple of problems with the generated perl6 code: > >. . . java.security.PermissionCollection: checking > jdbclib/java/security/PermissionCollection.pm >Malformed method definition at line 11, near "add(\n" >in Main (src/gen_setting.pm:3363) > >. . java.security.Permission: checking > jdbclib/java/security/Permission.pm >Unable to parse multisig; couldn't find final ')' at line 38, near > "--> java::" >in Main (src/gen_setting.pm:3363) > >It'll probably be a few days before I get back to this. >Volunteers are most welcome to hack at any of these issues. > >Thanks! > >Tim. > >. java.sql.ResultSet: jdbclib/java/sql/ResultSet.pm >. . [4]java.io.Reader: jdbclib/java/io/Reader.pm >. . . java.nio.CharBuffer: jdbclib/java/nio/CharBuffer.pm >. . . . java.lang.Appendable: jdbclib/java/lang/Appendable.pm >. . . . . java.lang.CharSequence: jdbclib/java/lang/CharSequence.pm >. . . . . java.lang.CharSequence: checking > jdbclib/java/lang/CharSequence.pm >syntax OK >. . . . java.lang.Appendable: checking jdbclib/java/lang/Appendable.pm >syntax OK >. . . . java.nio.Buffer: jdbclib/java/nio/Buffer.pm >. . . . java.nio.Buffer: checking jdbclib/java/nio/Buffer.pm >syntax OK >. . . . java.nio.ByteOrder: jdbclib/java/nio/ByteOrder.pm >. . . . java.nio.ByteOrder: checking jdbclib/java/nio/ByteOrder.pm >syntax OK >. . . java.nio.CharBuffer: checking jdbclib/java/nio/CharBuffer.pm >syntax OK >. . java.io.Reader: checking jdbclib/java/io/Reader.pm >syntax OK >. . java.math.BigDecimal: jdbclib/java/math/BigDecimal.pm >. . . java.math.MathContext: jdbclib/java/math/MathContext.pm >. . . . java.math.RoundingMode: jdbclib/java/math/RoundingMode.pm >. . . . . java.lang.Enum: jdbclib/java/lang/Enum.pm >. . . . . java.lang.Enum: checking jdbclib/java/lang/Enum.pm >syntax OK >. . . . java.math.RoundingMode: checking jdbclib/java/math/RoundingMode.pm >syntax OK >. . . java.math.MathContext: checking jdbclib/java/math/MathContext.pm >syntax OK >. . java.math.BigDecimal: checking jdbclib/java/math/BigDecimal.pm >Can't find ./Float in @*INC <== I've fixed this. >in Main (src/gen_setting.pm:445) >. . java.sql.Blob: jdbclib/java/sql/Blob.pm >. . . [5]java.io.Outpu
What needs doing...
I've applied a bunch of changes today. The current output of the mkjdbc.pl script is appended below. It's looking pretty good. (I'm using the latest rakudo from git) There are a few immediate issues... . . java.sql.SQLXML: jdbclib/java/sql/SQLXML.pm ERROR (line 1): Invalid comp unit: Was expecting comp stmt javap normally outputs a line like "Compiled from "ByteOrder.java"" for most classes, and that's assumed by the grammar. It seems that that line isn't output for some classes. The grammar need updating to account for that. (about 12 of the failures are due to that.) . . . . java.sql.DatabaseMetaData: checking jdbclib/java/sql/DatabaseMetaData.pm Can't find ./java/util/Properties in @*INC in Main (src/gen_setting.pm:445) [...] . . . . java.util.Properties: jdbclib/java/util/Properties.pm For some reason the fact that java.sql.DatabaseMetaData references java.util.Properties wasn't noticed, so the generated DatabaseMetaData.pm was checked before java.util.Properties was generated. Assorted other classes are affected in a similar way. That needs fixing. There are a couple of problems with the generated perl6 code: . . . java.security.PermissionCollection: checking jdbclib/java/security/PermissionCollection.pm Malformed method definition at line 11, near "add(\n " in Main (src/gen_setting.pm:3363) . . java.security.Permission: checking jdbclib/java/security/Permission.pm Unable to parse multisig; couldn't find final ')' at line 38, near "--> java::" in Main (src/gen_setting.pm:3363) It'll probably be a few days before I get back to this. Volunteers are most welcome to hack at any of these issues. Thanks! Tim. . java.sql.ResultSet: jdbclib/java/sql/ResultSet.pm . . java.io.Reader: jdbclib/java/io/Reader.pm . . . java.nio.CharBuffer: jdbclib/java/nio/CharBuffer.pm . . . . java.lang.Appendable: jdbclib/java/lang/Appendable.pm . . . . . java.lang.CharSequence: jdbclib/java/lang/CharSequence.pm . . . . . java.lang.CharSequence: checking jdbclib/java/lang/CharSequence.pm syntax OK . . . . java.lang.Appendable: checking jdbclib/java/lang/Appendable.pm syntax OK . . . . java.nio.Buffer: jdbclib/java/nio/Buffer.pm . . . . java.nio.Buffer: checking jdbclib/java/nio/Buffer.pm syntax OK . . . . java.nio.ByteOrder: jdbclib/java/nio/ByteOrder.pm . . . . java.nio.ByteOrder: checking jdbclib/java/nio/ByteOrder.pm syntax OK . . . java.nio.CharBuffer: checking jdbclib/java/nio/CharBuffer.pm syntax OK . . java.io.Reader: checking jdbclib/java/io/Reader.pm syntax OK . . java.math.BigDecimal: jdbclib/java/math/BigDecimal.pm . . . java.math.MathContext: jdbclib/java/math/MathContext.pm . . . . java.math.RoundingMode: jdbclib/java/math/RoundingMode.pm . . . . . java.lang.Enum: jdbclib/java/lang/Enum.pm . . . . . java.lang.Enum: checking jdbclib/java/lang/Enum.pm syntax OK . . . . java.math.RoundingMode: checking jdbclib/java/math/RoundingMode.pm syntax OK . . . java.math.MathContext: checking jdbclib/java/math/MathContext.pm syntax OK . . java.math.BigDecimal: checking jdbclib/java/math/BigDecimal.pm Can't find ./Float in @*INC <== I've fixed this. in Main (src/gen_setting.pm:445) . . java.sql.Blob: jdbclib/java/sql/Blob.pm . . . java.io.OutputStream: jdbclib/java/io/OutputStream.pm . . . java.io.OutputStream: checking jdbclib/java/io/OutputStream.pm syntax OK . . java.sql.Blob: checking jdbclib/java/sql/Blob.pm syntax OK . . java.sql.Clob: jdbclib/java/sql/Clob.pm . . . java.io.Writer: jdbclib/java/io/Writer.pm . . . java.io.Writer: checking jdbclib/java/io/Writer.pm syntax OK . . java.sql.Clob: checking jdbclib/java/sql/Clob.pm syntax OK . . java.sql.Date: jdbclib/java/sql/Date.pm . . . java.util.Date: jdbclib/java/util/Date.pm . . . java.util.Date: checking jdbclib/java/util/Date.pm syntax OK . . java.sql.Date: checking jdbclib/java/sql/Date.pm syntax OK . . java.sql.NClob: jdbclib/java/sql/NClob.pm . . java.sql.NClob: checking jdbclib/java/sql/NClob.pm syntax OK . . java.sql.Ref: jdbclib/java/sql/Ref.pm . . . java.util.Map: jdbclib/java/util/Map.pm . . . . java.util.Collection: jdbclib/java/util/Collection.pm . . . . . java.lang.Iterable: jdbclib/java/lang/Iterable.pm . . . . . . java.util.Iterator: jdbclib/java/util/Iterator.pm . . . . . . java.util.Iterator: checking jdbclib/java/util/Iterator.pm syntax OK . . . . . java.lang.Iterable: checking jdbclib/java/lang/Iterable.pm syntax OK . . . . java.util.Collection: checking jdbclib/java/util/Collection.pm syntax OK . . . . java.util.Set: jdbclib/java/util/Set.pm . . . . java.util.Set: checking jdbclib/java/util/Set.pm syntax OK . . . java.util.Map: checking jdbclib/java/util/Map.pm syntax OK . . java.sql.Ref: checking jdbclib/java/sql/Ref.pm syntax OK . . java.sql.ResultSetMetaData: jdbclib/java/sql/ResultSetMetaData.pm . . . java.sql.Wrapper: jdbclib/java/sql/Wrapper.pm . . . java.sql.Wrapper: checking jdbclib/java/sql/Wrapper.pm syntax OK . . java.sql.ResultSetMetaData: ch
Re: DBDI Status
On Thu, Jul 16, 2009 at 01:49:02AM -0700, Darren Duncan wrote: > Tim Bunce wrote: >> On Wed, Jul 15, 2009 at 03:46:08PM +0100, Sentra Systems wrote: >>> Do you want these to be typecast to 'Any'? >> >> In the short term, yes. In the longer term we'll need to be more >> flexible. I envisage a 'type map' file that, for each Java type, >> specifies the corresponding Perl6 type (either builtin or in a module). >> Any types not in the file would generate a warning and map to Any. >> >> Feel free to add that in! I'd guess it would be straight-forward. > > On that note, I've been using what influence I have over the Perl 6 > language design in the last few years to try and improve its savvy for > relational database features and semantics. > > I currently believe, as also documented indirectly in my Muldis D language > spec, that every SQL data type of any consequence already has a direct Perl > 6 counterpart, but that in general Perl 6's version is better where different. While that's likely to be useful in general for perl6 later, it's probably not that useful for the current goals of DBDI. We just need to be able to map the Java types used in the JDBC API to perl6 types that have sufficiently similar semantics. Remember that one of the goals of DBDI is to provide a common database API for _all_ the languages targeting Parrot. So we should avoid getting 'too clever' at this level. The Perl 6 types will be useful to whatever software is layered over the (relatively low-level) DBDI code. That's where the mythical "DBI 2" comes in. Having said all that... I expect DBDI to grow into a superset of JDBC that includes concepts and methods that enable greater performance and functionality. One significant idea here is that the higher level could should be able to supply DBDI with a row object that DBDI will just 'set' the fields of when it fetches a row. That sounds dull but it's actually significant for two reasons: a) it enables much higher performance as the same row with the same column variables (PMCs) can be reused for each row (assuming the app doesn't want to save them). That saves a huge amount of memory allocation and freeing. (That's a big part of why the DBI is so fast.) b) the field variables can be 'smart'. So, for example, the column in the row object that corresponds to an INTERVAL type could be an instance of a Perl6 Instant. Or any other object that will 'do the right thing' when the DBDI stores the value into it. Tim.
Re: DBDI Status
On Wed, Jul 15, 2009 at 03:46:08PM +0100, Sentra Systems wrote: > Tim > > They fixed a bug in rakudo last night that means a lot more of the pm's > build, still investigating the rest. There a number of additional classes > being discovered by javap (above the list you supplied). Yes, that list was just the top level classes. There's lots of extras that get referenced by those classes. > Do you want these to be typecast to 'Any'? In the short term, yes. In the longer term we'll need to be more flexible. I envisage a 'type map' file that, for each Java type, specifies the corresponding Perl6 type (either builtin or in a module). Any types not in the file would generate a warning and map to Any. Feel free to add that in! I'd guess it would be straight-forward. > Rakudo currently doesn't support 'Array of' - so the returns parameters are > now returning 'Array' without a type, I've included the type info in a > comment at the end of line. Method parameters just get the appropriate > sigil now. > > Typecasting was causing several multi methods to end up with the same > signature, I've amended the generator to remove the duplicates. Great. > I added them to a copy of the list and it starts bring in stuff like the > Java print system classes etc. when run against java2perl. Not quite sure what you mean there Dave. > Do you want a snapshot of what I've done so far, or would you rather wait > until it's more complete? Commit early, commit often :) > What sort of Google account do I need to commit? Go to google.com. Click 'Sign in' in the top righthand corner. Click 'Create an account now'. Enter your email address etc. Send me the email address when you're done. Or, if you already have a google account, just send me one of the email addresses associated with the account. Thanks! Tim.
Re: DBDI Status
Many thanks Dave. Applied!
Tim.
On Fri, Jul 10, 2009 at 11:45:46PM +0100, Sentra Systems wrote:
> Tim
>
> Attached is a modified copy of the Generator::Std that emits current perl6.
> It's been amended to add the correct sigils and 'use' statements. Do you
> want to give it a try and see if it does what you want?
>
> :)
> Dave
>
>
> Tim Bunce wrote:
>> On Mon, Jul 06, 2009 at 02:08:17PM +0100, Sentra Systems wrote:
>>
>>> Tim
>>>
>>> Is there a particular reference implementation of java.sql(x) you're
>>> planning on running the java2perl on? A quick google shows a reference
>>> API but no obvious reference implementation.
>>>
>>
>> Any implementation that has the classes will do. java2perl6 is only
>> concerned with the class interfaces. It just runs javap on the class
>> you give it, parses the class and interfaces definitions it outputs, and
>> writes corresponding perl6 clasess and roles definitions.
>>
>> Try running
>>
>> java2perl6 --outdir jdbc --recurse --nest java.sql.Connection
>>
>> I've just checked in a file I had on my disk that lists all the
>> java.sql and javax.sql classess, so you can run
>>
>> java2perl6 --outdir jdbc --recurse --nest $(cat jdbc_classes.txt)
>>
>> Tim.
>>
>>
>>> Regards
>>> Dave
>>>
>>>
>>> Tim Bunce wrote:
>>>
>>>> On Sat, Jul 04, 2009 at 07:09:20PM +0100, Sentra Systems wrote:
>>>>
>>>>> Hi
>>>>>
>>>> Hi Dave.
>>>>
>>>>
>>>>> Has anything happened with a Parrot JDBC implementation?
>>>>> Is Parrot stable enough yet?
>>>>> Has anyone mapped out the minimun subset of JDBC that would be required
>>>>> to get DBI working in Perl6?
>>>>>
>>>> Here's the (current) plan...
>>>>
>>>> 1. Dust off java2perl6
>>>> http://search.cpan.org/perldoc?java2perl6
>>>> http://code.google.com/p/java2perl6/
>>>> and update it to generate valid current perl6 code.
>>>>
>>>> 2. Add a type aliasing mechanism (ie "for the Java URL type use a Perl
>>>> Str type") to java2perl6 so we don't have to implement loads of Java
>>>> types before we can get started.
>>>>
>>>> 3. Write some kind of very dumb "Hello World" skeleton JDBC driver,
>>>> as a proof of concept that uses the interfaces generated by java2perl
>>>>
>>>> 4. Refactor Simon Cozens's SQLite3 DBDI driver to use ('consume') the
>>>> generated JDBC interfaces.
>>>>
>>>> http://dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
>>>> That's not working right now, so here's a cached version:
>>>>
>>>> http://google.com/search?q=cache:T8FN2WYvgm0J:dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
>>>>
>>>> Making a move on this has been high on my list of pre-OSCON tasks
>>>> but working on NYTProf has remained a higher priority (there are some
>>>> great new features in the next release).
>>>>
>>>> If anyone wants to help out with 1 and 2, you'd be more than welcome!
>>>> Send me your email address and I'll give you a commit bit.
>>>>
>>>> Tim.
>>>>
>>>>
>>
>>
>
Re: DBDI Status
On Fri, Jul 10, 2009 at 11:45:46PM +0100, Sentra Systems wrote: > Tim > > Attached is a modified copy of the Generator::Std that emits current perl6. > It's been amended to add the correct sigils and 'use' statements. Do you > want to give it a try and see if it does what you want? Try running the mkjdbc.pl script (I've just updated). It now runs perl6 on the generated files to validate them. Lots of errors are generated, like the one below, but I'd guess there are only a few underlying problems. Any chance you could take a look? Tim. /Users/timbo/perl6/rakudo/perl6 jdbclib/java/sql/CallableStatement.pm Malformed method definition at line 11, near "read(\n" in Main (src/gen_setting.pm:3340)
Re: DBDI Status
Uh, I meant to add... give me an email address associated with a google
account and I'll give you a commit bit on http://code.google.com/p/java2perl6/
(I may move to github but it probably won't happen till after OSCON.)
Tim.
On Sat, Jul 11, 2009 at 01:03:25AM +0100, Tim Bunce wrote:
> Many thanks Dave. Applied!
>
> Tim.
>
> On Fri, Jul 10, 2009 at 11:45:46PM +0100, Sentra Systems wrote:
> > Tim
> >
> > Attached is a modified copy of the Generator::Std that emits current perl6.
> > It's been amended to add the correct sigils and 'use' statements. Do you
> > want to give it a try and see if it does what you want?
> >
> > :)
> > Dave
> >
> >
> > Tim Bunce wrote:
> >> On Mon, Jul 06, 2009 at 02:08:17PM +0100, Sentra Systems wrote:
> >>
> >>> Tim
> >>>
> >>> Is there a particular reference implementation of java.sql(x) you're
> >>> planning on running the java2perl on? A quick google shows a reference
> >>> API but no obvious reference implementation.
> >>>
> >>
> >> Any implementation that has the classes will do. java2perl6 is only
> >> concerned with the class interfaces. It just runs javap on the class
> >> you give it, parses the class and interfaces definitions it outputs, and
> >> writes corresponding perl6 clasess and roles definitions.
> >>
> >> Try running
> >>
> >> java2perl6 --outdir jdbc --recurse --nest java.sql.Connection
> >>
> >> I've just checked in a file I had on my disk that lists all the
> >> java.sql and javax.sql classess, so you can run
> >>
> >> java2perl6 --outdir jdbc --recurse --nest $(cat jdbc_classes.txt)
> >>
> >> Tim.
> >>
> >>
> >>> Regards
> >>> Dave
> >>>
> >>>
> >>> Tim Bunce wrote:
> >>>
> >>>> On Sat, Jul 04, 2009 at 07:09:20PM +0100, Sentra Systems wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>> Hi Dave.
> >>>>
> >>>>
> >>>>> Has anything happened with a Parrot JDBC implementation?
> >>>>> Is Parrot stable enough yet?
> >>>>> Has anyone mapped out the minimun subset of JDBC that would be required
> >>>>> to get DBI working in Perl6?
> >>>>>
> >>>> Here's the (current) plan...
> >>>>
> >>>> 1. Dust off java2perl6
> >>>> http://search.cpan.org/perldoc?java2perl6
> >>>> http://code.google.com/p/java2perl6/
> >>>> and update it to generate valid current perl6 code.
> >>>>
> >>>> 2. Add a type aliasing mechanism (ie "for the Java URL type use a Perl
> >>>> Str type") to java2perl6 so we don't have to implement loads of Java
> >>>> types before we can get started.
> >>>>
> >>>> 3. Write some kind of very dumb "Hello World" skeleton JDBC driver,
> >>>> as a proof of concept that uses the interfaces generated by java2perl
> >>>>
> >>>> 4. Refactor Simon Cozens's SQLite3 DBDI driver to use ('consume') the
> >>>> generated JDBC interfaces.
> >>>>
> >>>> http://dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
> >>>> That's not working right now, so here's a cached version:
> >>>>
> >>>> http://google.com/search?q=cache:T8FN2WYvgm0J:dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
> >>>>
> >>>> Making a move on this has been high on my list of pre-OSCON tasks
> >>>> but working on NYTProf has remained a higher priority (there are some
> >>>> great new features in the next release).
> >>>>
> >>>> If anyone wants to help out with 1 and 2, you'd be more than welcome!
> >>>> Send me your email address and I'll give you a commit bit.
> >>>>
> >>>> Tim.
> >>>>
> >>>>
> >>
> >>
> >
>
>
Re: DBDI Status
On Mon, Jul 06, 2009 at 02:08:17PM +0100, Sentra Systems wrote:
> Tim
>
> Is there a particular reference implementation of java.sql(x) you're
> planning on running the java2perl on? A quick google shows a reference API
> but no obvious reference implementation.
Any implementation that has the classes will do. java2perl6 is only
concerned with the class interfaces. It just runs javap on the class
you give it, parses the class and interfaces definitions it outputs, and
writes corresponding perl6 clasess and roles definitions.
Try running
java2perl6 --outdir jdbc --recurse --nest java.sql.Connection
I've just checked in a file I had on my disk that lists all the
java.sql and javax.sql classess, so you can run
java2perl6 --outdir jdbc --recurse --nest $(cat jdbc_classes.txt)
Tim.
> Regards
> Dave
>
>
> Tim Bunce wrote:
>> On Sat, Jul 04, 2009 at 07:09:20PM +0100, Sentra Systems wrote:
>>
>>> Hi
>>>
>>
>> Hi Dave.
>>
>>
>>> Has anything happened with a Parrot JDBC implementation?
>>> Is Parrot stable enough yet?
>>> Has anyone mapped out the minimun subset of JDBC that would be required
>>> to get DBI working in Perl6?
>>>
>>
>> Here's the (current) plan...
>>
>> 1. Dust off java2perl6
>> http://search.cpan.org/perldoc?java2perl6
>> http://code.google.com/p/java2perl6/
>> and update it to generate valid current perl6 code.
>>
>> 2. Add a type aliasing mechanism (ie "for the Java URL type use a Perl
>> Str type") to java2perl6 so we don't have to implement loads of Java
>> types before we can get started.
>>
>> 3. Write some kind of very dumb "Hello World" skeleton JDBC driver,
>> as a proof of concept that uses the interfaces generated by java2perl
>>
>> 4. Refactor Simon Cozens's SQLite3 DBDI driver to use ('consume') the
>> generated JDBC interfaces.
>>
>> http://dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
>> That's not working right now, so here's a cached version:
>>
>> http://google.com/search?q=cache:T8FN2WYvgm0J:dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
>>
>> Making a move on this has been high on my list of pre-OSCON tasks
>> but working on NYTProf has remained a higher priority (there are some
>> great new features in the next release).
>>
>> If anyone wants to help out with 1 and 2, you'd be more than welcome!
>> Send me your email address and I'll give you a commit bit.
>>
>> Tim.
>>
>>
>
Re: DBDI Status
On Sun, Jul 05, 2009 at 01:58:11PM -0700, Harry wrote:
>
> Hi all,
Hi Harry.
> Is the parrot DBDI being worked on again.
I certainly plan to, as outlined below. If not by OSCON then certainly
at and after it.
Want to help out?
Tim.
> Harry
> Join team plico.
> http://www.hjackson.org/cgi-bin/folding/index.pl
>
>
>
> - Original Message
> From: Tim Bunce
> To: Sentra Systems
> Cc: dbdi-dev@perl.org; Simon Cozens
> Sent: Saturday, July 4, 2009 11:36:32 PM
> Subject: Re: DBDI Status
>
> On Sat, Jul 04, 2009 at 07:09:20PM +0100, Sentra Systems wrote:
> > Hi
>
> Hi Dave.
>
> > Has anything happened with a Parrot JDBC implementation?
> > Is Parrot stable enough yet?
> > Has anyone mapped out the minimun subset of JDBC that would be required to
> > get DBI working in Perl6?
>
> Here's the (current) plan...
>
> 1. Dust off java2perl6
> http://search.cpan.org/perldoc?java2perl6
> http://code.google.com/p/java2perl6/
> and update it to generate valid current perl6 code.
>
> 2. Add a type aliasing mechanism (ie "for the Java URL type use a Perl
> Str type") to java2perl6 so we don't have to implement loads of Java
> types before we can get started.
>
> 3. Write some kind of very dumb "Hello World" skeleton JDBC driver,
> as a proof of concept that uses the interfaces generated by java2perl
>
> 4. Refactor Simon Cozens's SQLite3 DBDI driver to use ('consume') the
> generated JDBC interfaces.
> http://dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
> That's not working right now, so here's a cached version:
>
> http://google.com/search?q=cache:T8FN2WYvgm0J:dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
>
> Making a move on this has been high on my list of pre-OSCON tasks
> but working on NYTProf has remained a higher priority (there are some
> great new features in the next release).
>
> If anyone wants to help out with 1 and 2, you'd be more than welcome!
> Send me your email address and I'll give you a commit bit.
>
> Tim.
>
>
>
>
Re: DBDI Status
On Sat, Jul 04, 2009 at 07:09:20PM +0100, Sentra Systems wrote:
> Hi
Hi Dave.
> Has anything happened with a Parrot JDBC implementation?
> Is Parrot stable enough yet?
> Has anyone mapped out the minimun subset of JDBC that would be required to
> get DBI working in Perl6?
Here's the (current) plan...
1. Dust off java2perl6
http://search.cpan.org/perldoc?java2perl6
http://code.google.com/p/java2perl6/
and update it to generate valid current perl6 code.
2. Add a type aliasing mechanism (ie "for the Java URL type use a Perl
Str type") to java2perl6 so we don't have to implement loads of Java
types before we can get started.
3. Write some kind of very dumb "Hello World" skeleton JDBC driver,
as a proof of concept that uses the interfaces generated by java2perl
4. Refactor Simon Cozens's SQLite3 DBDI driver to use ('consume') the
generated JDBC interfaces.
http://dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
That's not working right now, so here's a cached version:
http://google.com/search?q=cache:T8FN2WYvgm0J:dev.simon-cozens.org/6pan/browser/trunk/DBDI/DBDI/Driver/SQLite3.pm
Making a move on this has been high on my list of pre-OSCON tasks
but working on NYTProf has remained a higher priority (there are some
great new features in the next release).
If anyone wants to help out with 1 and 2, you'd be more than welcome!
Send me your email address and I'll give you a commit bit.
Tim.
Re: For your encouragement
On Fri, Dec 05, 2008 at 11:11:30AM -0800, Geoffrey Broadwell wrote: > On Fri, 2008-12-05 at 09:10 -0600, Andy Lester wrote: > > On Dec 5, 2008, at 4:13 AM, Simon Cozens wrote: > > > > > I just ran this code, which worked with the expected results: > > > > > > Beautiful. Posted to Perlbuzz. > > > > http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html > > Someone needs to reply to the comments from readers who have confused > DBI and DBDI, and have thus decided we are turning Perl into Java. I've just posted this as a comment... ---snip--- Re "I think thats because DBI 2.0 uses JDBC as its API" - that's not quite right in two ways. "DBI 2.0" doesn't exist anywhere other than in my head and, so far, I've been unsuccessful in making time to actually work on it. "JDBC as its API" is a little misleading - DBI 2.0 uses JDBC as the *driver* API, i.e., the interface between the DBI and the underlying driver (DBD), not the interface between applications and the DBI. That's why Simon's example looks like Java JDBC, and that's a very good thing. It means that he doesn't need me, or anyone else, to agree on the API or semantics. They're all specified in great detail in the JDBC docs and the JDBC test suite. Anyone wanting to follow Simon's example can work to the same well defined standard API. There are two main areas of concern though: 1. There may be subtle issues in how data types and calling conventions translate between Java and Parrot/Perl6. 2. JDBC is a big API, effort should be made to factor out as much code as possible into modules that can be shrface between applications and the DBI. The dbdi-dev@perl.org (note the 'i' in dbdi) mailing list is a good place to discuss these and related issues. Email [EMAIL PROTECTED] to subscribe. ---snip--- There's an archive at http://www.mail-archive.com/dbdi-dev@perl.org/index.html which shows almost no activity since Feb 2004. It would be great to get some life into it. Tim.
DBI2 reborn with DBI1 facade
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?
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: First DBDI draft
On Tue, Feb 03, 2004 at 04:35:46PM +, Harry Jackson wrote: > [... ] > Question: > Since Dan has said that objects are nearly finished is there any point > spending too much time working on this. Would our time be better spent > helping to get objects finished pronto. I think so. It's basically a (considerable) waste of time trying to come up with ways around the current, and hopefully short term, limitations. I had thought Parrot was a little further along than it seems to be. Sadly I think it's best to consider the DBDI project shelved until Parrot and IMCC get reasonably usable objects and method calls. I *really* hope that can happen for the February release. I'm CC'ing this to [EMAIL PROTECTED] in the hope that it'll spur on development. Tim. p.s. I just saw Leo quoting Dan as saying "The low-level object design will be done by Jan 30th." so hopefully it won't be long now, and hopefully IMCC won't be far behind.
Re: First DBDI draft
On Fri, Jan 30, 2004 at 02:26:27PM +, Harry Jackson wrote: > > >> dbstring = "host=lhost dbname=name user=user password=pass" > >> .pcc_begin prototyped > >> .arg dbstring > >> .pcc_call connect > >> retconnect: > >> .result dbh > >> .pcc_end > >> print "New $dbh successful\n" > > > > > >When we move to objects we'll add in the driver handle and call connect > >as a method on that. > > The actual connect call above is the DBDI call which then calls the > connect function on the driver. Nooo. Ultimately it should be a method call on a dbr object which will be blessed into DBDdr (the driver class). There should be no "DBDI" intercepting calls up front (as far as possible), only providing default methods in the base classes. (I appreciate you're having to hack around the lack of method calls so maybe that's why you're going that way, but it's not ideal.) > I would like to put each arg in an array and pass that in rather than > having a massive arg list or would you rather have them all seperate. Separate, "as per the DBI spec". > >Is that returning a new PerlArray each time? > >I think that should be another reference and have fetch() return > >a reference to the same (internal) PerlArray each time. > > It is buried in the driver somewhere so I will need to dig to find out. > If it is it should be easy to fix. Would you prefer to have the array > passed in as a parameter. This means we can create it before the loop > and reuse it. No, "as per the DBI spec" "as per the DBI spec" "as per the DBI spec" :) fetch() is a method on the sth that takes no params and returns an array ref. Period. Thanks. Tim.
Re: First DBDI draft
On Fri, Jan 30, 2004 at 03:11:05PM +, Harry Jackson wrote: > > .pcc_sub _MAIN prototyped > .param pmc argv > .include "/home/parrot/dbdi/lib/dbdi/dbdi_header.imc" > > .sym pmc dbh > .sym string dbstring > dbstring = "host=lhost dbname=name user=user password=pass" > .sym string dbh_name > dbh_name = "dbh" > .pcc_begin prototyped > .arg dbstring > .arg dbh_name > .pcc_call connect > retconnect: > .result dbh > .pcc_end > print "New $dbh successful\n" I don't see the need for this naming. Why not just do: .sym string dbstring dbstring = "host=lhost dbname=name user=user password=pass" .sym pmc dbh1 .sym pmc dbh2 .pcc_begin prototyped .arg dbstring .pcc_call connect retconnect: .result dbh1 .pcc_end .pcc_begin prototyped .arg dbstring .pcc_call connect retconnect: .result dbh2 .pcc_end ? > # Now that we have a $dbh we can pass it into > # the prepare funtion with the SQL statement. > # We must also name our statement handle which > # allows us to have multiple statement handles > # per dbh object. Name collisions are being > # checked. We also check to make sure that the > # dbh that is passed in is valid otherwise we > # abort. > .sym pmc sth > .sym string sql > sql = "select * from parrot" > .sym string sth_name > sth_name = "sth" > > .pcc_begin prototyped > .arg dbh_name > .arg sth_name > .arg sql > .pcc_call prepare > retprepare: > .result sth > .pcc_end That needs to be more like this: .sym string sql sql = "select * from parrot" .sym pmc sth1 .pcc_begin prototyped .arg dbh1 .arg sql .pcc_call prepare retprepare: .result sth1 .pcc_end No dbh name, no sth name. They're not needed and not in the spec. Am I missing something? The returned sth thingy holds a copy (ref) of its parent dbh. Tim.
Re: Things are afoot
On Fri, Jan 30, 2004 at 02:44:33PM +, Harry Jackson wrote: > Tim Bunce wrote: > > Get as close to my "design notes" (reposted this morning) as > > possible. > > eg set_err(), err(), errstr(), new_child() get_row_array() > > etc > > This is an area that will involve some work. At the moment I am building > up structures in a hierarchal nature. I have only got as far as > > .sym dbh_container PerlHash > dbh_container['DBD::_::db'] > This hols all the dbh objects which at this point are "PerlHash" Why do you need a container? > All this will become apparrent when I release the next example. This all > came about trying to get multiple handles working although it has not > been fully tested it is working for single handles ;-) I don't see why multiple handles need any kind of container holding multiple handles. What am I missing? > >2. Make example less hard coded: > > take dsn, user, password from command line > > loop, asking for sql then execute, fetch, loop. > > There are areas that concern me at the back end because they are hard > coded due to not having runtime loading of the driver byt this is > unavoidable. I will change them to more versatile methods where I can. Having a hard coded driver isn't such a big deal. Just use a .include which names a smylink and have the symlink point to the driver code. That'll do us for quite a while. > >4. An NCI interface for mysql would greatly increase the potential early > >userbase. > > I am going to get some of this stuff in some sort of priority order. > Doing the MySQL driver will eat a fair bit of my time but I am more than > happy to do it if it gets us a lot more users. The docs would take me a > day to get something working which is probably the biggest win for the > least effort. Leave the mysql driver till you're totally stuck elsewhere. I may tackle it once we have subversion up. Tim.
Re: Things are afoot
On Fri, Jan 30, 2004 at 03:19:45AM +, Harry Jackson wrote: > Harry Jackson wrote: > > >Some of the code is only half finished ie We can connect and prepare but > >not execute and fetch. > > > >Watch this space. > > We can now execute and fetch as can be seen from the bit of code I just > posted. I am now working on handling multiple database/statement handles. > > I am also very open to suggestions about what people want to see here. > If there are no suggestions I will just continue along as I am doing and > it will probably all need to be changed when we start getting some > feedback. If you think of me as your humble servant start firing > questions/abuse and I will see what I can do. > > Some questions of my own: > > 1. Where are we going to put all the source. > > Thoughts: > I am asking this because I am not sure that the Parrot source tree is > the correct place to put it (neither is Tim). There are various reasons > for this which I am sure Tim is bored explaining, not least of which > will be namespaces etc. > > I am able to create a source tarball and hang it off my website but this > if it happens should be a temporary measure and you will still need to > have the Parrot source which is unavoidable. I'm in the process of moving the DBI source to Subversion hosted by perl.org. I think that would be a good home for DBDI as well. > 2. What are people expecting/wanting to see first. > > Thoughts: > At the moment I am rummaging around having a whale of a time doing what > I _think!_ is correct. This is not necessarily a good idea so we really > need some people to start making suggestions as to what they want to see > done first. We also need some discussion on the Parrot DBDI and what > people would like to see in it. 1. A clean stable application API as close to the DBI as practical. That means: Method names, parameters, return values as per DBI Opaque handles (I think ".sym pmc dbh" will work rather than a named reference type I suggested earlier) Method calls (though if IMCC will get a clean syntax for them soon it maybe best to wait and avoid the messy name mangling meanwhile.) Get as close to my "design notes" (reposted this morning) as possible. eg set_err(), err(), errstr(), new_child() get_row_array() etc 2. Make example less hard coded: take dsn, user, password from command line loop, asking for sql then execute, fetch, loop. 3. Some docs for "How to get started with Parrot and IMCC" that just lists pointers to other docs plus a walk-through to get setup: fetch parrot from unpack, cd, configure, build, install these files are the dbdi source ... run this command to execute the dbdi example So newcomers can hit the ground running. 4. An NCI interface for mysql would greatly increase the potential early userbase. 5. Get into subversion as soon as it's available I've asked Ask & Rob at perl.org to set it up. Anyone wanting access should start by geting an account at auth.perl.org Tim.
Parrot DBDI Design Notes
Here's something I sketched out for Harry when we started. Seems worth repeating to the list. This is where we're aiming to get to. Tim =head1 Parrot DBD Design Notes These notes for a rough sketch of a class hirearchy based on that use for the Perl DBI drivers: the DBD's. =head1 Handle Objects There are three kinds of handles: Driver, Database, and Statement. These are often refered to as drh, dbh, and sth respectively. =head1 Classes A driver implements a class for each type of handle. The name of the classes are DBDdr, DBDdb, and DBDst where if the name of the driver, e.g., DBDdr. The DBD library provides base classes for those driver classes. The hierarchy looks like this: DBD::_::common DBD::_::dr DBDdr DBDdr DBD::_::db DBDdb DBDdb DBD::_::st DBDst DBDst See %DBI::DBI_methods and @Common_IF in DBI.pm =head2 DBD::_::common class =item err() Returns scalar (typically int but can be string) or undef =item errstr() Returns scalar (typically string) or undef =item set_err(err, errstr) Sets the err and errstr values of the handle =item new_child(attr) Create a new handle in the appropriate child class of the calling handle. The new class is determined by changing the last component of the calling handles class name. If the last component of the class name is "dr" then the new class ends in "db", it's it's "db" then the new class ends in "st". Anything else is an error. The attr param is ignored for now. =head2 DBD::_::dr class =item connect(dsn, user, pass, attr) Effectively does $dbh = $drh->new_child(attr) or return; $dbh->connect(dsn, user, pass) or return; return $dbh =head2 DBD::_::db class =item connect(dsn, user, pass) *DRIVER* Connects to the database and stores the underlying connection in the handle object. =item prepare(statement, attr) Effectively does $sth = $dbh->new_child(attr) or return; $sth->prepare(statement, attr) or return; return $sth =item do(statement, attr) Effectively does $sth = $dbh->prepare(statement, attr) or return; $sth->execute() or return; my $rows = $sth->rows; $sth->some-method-that-destroys-the-handle return $rows =head2 DBD::_::st class =item prepare(statement, attr) *DRIVER* Prepares the statement for execution and stores the underlying information in the handle object. (Initially, and for some drivers always, this can simply store a copy of the statement string in handle and postpone any real work till execute() is called.) If it's a select statement it sets NUM_OF_FIELDS attribute if it can. =item execute(statement)*DRIVER* Executes the prepared statement. If it's a select statement it sets NUM_OF_FIELDS attribute if it wasn't set by prepare(). Returns an integer row count (which may be meaningless for stetelct statements) =item get_row_array() If the handle object does not already have a row buffer then an array of NUM_OF_FIELDS elements is allocated. Increments the row count in the handle. Returns the array. (The same one on each call). =item fetch() *DRIVER* Fetches the next row from the database. If there are no more rows then calls finish() and return undef. If there is a row then it calls get_row_array() and sets each element of the array to the corresponding field value. Returns the array. =item finish() Discards any pending results from the select statement. =head1 Driver Summary A driver only has to implement these few methods: DBDdb::connect() DBDst::prepare() DBDst::execute() DBDst::fetch() to get something working! =head1 Leading Issues Attributes vs properties? Methods to set/get attribute values. (Driver needs to be able to bypass the methods in some cases) Define basic set of attributes for each class Define object 'structure': what is a handle made of? (e.g., an Array with elements assigned specific uses?) Define and document parameter and return types (method prototypes) =cut
Re: First DBDI draft
On Thu, Jan 29, 2004 at 09:00:56PM +, Harry Jackson wrote:
> Ok.
>
> I have managed to knock up an initial draft. You will see straight away
> that it is very limited in what it does. I have managed to run the
> select statement as shown in the code and it does return 1 records
> although I have not checked for any boundary conditions. Although I
> expect there are a few of them lurking due to the way the driver has
> been written but we can ignore the driver bugs for now ;-) or at least
> until Dan finds them.
>
> .pcc_sub _MAIN prototyped
> .param pmc argv
> .include "/home/parrot/dbdi/lib/dbdi/dbdi_header.imc"
>
> .sym string dbstring
> .sym PerlHash dbh
The application shouldn't need to know the type of the thing returned.
Can you use a 'reference' type here instead of PerlHash?
> dbstring = "host=lhost dbname=name user=user password=pass"
> .pcc_begin prototyped
> .arg dbstring
> .pcc_call connect
> retconnect:
> .result dbh
> .pcc_end
> print "New $dbh successful\n"
When we move to objects we'll add in the driver handle and call connect
as a method on that.
I'd like to see username and password moved to separate parameters
and an attributes parameter added. (To get as close to the final
API as early as possible).
> # Now that we have a $dbh we can pass it into
> # the prepare funtion with the SQL statement
> .sym Sub sth
Er, Sub for sth?
> .sym int rows
> .pcc_begin prototyped
> .arg sth
> .pcc_call execute
> retexecute:
> .result rows
> .pcc_end
> .PRINT("Execution Successful ", rows, " Affected\n" )
>
> .sym PerlArray rowarray
> .sym int rowcount
> .sym PerlString field0
> .sym PerlString field1
> .sym PerlString field2
> .sym PerlString field3
> .sym PerlString field4
> fetchnext:
> .pcc_begin prototyped
> .pcc_call fetch
> retfetch:
> .result rowarray
> .result rowcount
> .pcc_end
> if rowcount == 0 goto finish
Is that returning a new PerlArray each time?
I think that should be another reference and have fetch() return
a reference to the same (internal) PerlArray each time.
rowcount shouldn't be returned (could be a global for now).
Use a nil/null reference in rowarray to indicate no more data.
Looking good. Thanks Harry.
> =head1 TODO
>
> =item Returning objects from functions
>
> I want to return some object like structures back
> from the functions above rather than hiding
> everything in the background. This will make it
> easier to see and know what is going on between calls.
I'm not sure what that means.
> =item We need objects
Very true.
> =item We need runtime loading
Yes, not urgent though.
Tim.
"Parrot DBDI" - Announcement and Firmly Anticipated Questions
I wanted to use a different name to avoid any implication that the goal was to create "one true Parrot DBI" in the image of the Perl DBI. That's not the goal. The goal is for many languages to benefit from pooling development effort on a common database infrastructure I the "DBI" level. =head2 What about Drivers? I anticipate that drivers will be implemented using the Parrot Native Call Interface (NCI) to interface with the underlying database API. This has the significant advantage, if it works well, that drivers shouldn't need to be compiled on each platform. =head2 Links to database interfaces for various HLLs Ruby: http://ruby-dbi.sourceforge.net/ Python: http://www.python.org/topics/database/ Perl: http://dbi.perl.org/ PHP: http://freshmeat.net/projects/php-dbi/ (Please let me know about any other similar database interface projects for languages that may target Parrot.) =head2 Developers Harry Jackson <[EMAIL PROTECTED]> has volunteered to lead the development effort with design input from me, Tim Bunce. We're hoping that others interested in database interfaces for Parrot will join us and contribute. I expect a public code repository will be established soon. =head2 Mailing List The [EMAIL PROTECTED] mailing list has been created for this project. Archives can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/ Send email to [EMAIL PROTECTED] to subscribe. =cut
Welcome to dbdi-dev@perl.org
This list is for anyone developing database drivers for Parrot and especially for those developing the Parrot Database Driver Interface library or a database driver that use it. I'll post an announcement and answer some Firmly Anticipated Questions in a day or two. Tim.
