[Thousand-oaks-pm] In anticipation of Perl 6 Hackathon

[Todd Presta]

I had to truncate this email thread and resend it. pm.org rejected it based on content length > 40K.

Yes. A mixed approach, phasing in Perl 6 where capable.

On the DB front, I did do some more hacking with the SQLite3 in Parrot/Rakudo, but with mixed results on Windows.


Here are some of my findings with respect to Perl 6 and SQLite3 on WinTel.

The
SQLite3 implementation in Parrot is seems hardwired for a *nix
environment, that is the NCI call for the SQLite3 dynamic library looks
for libsqlite3 whereas on WinTel I believe it is sqlite3 by default.
After downloading the sqlite3.dll from SQLite.org I was able to use the
NCI functionality in Parrot and was able to open SQLite3 databases when
using Parrot/PIR (still working on the correct param string for the
native sqlite3_exec call though).

In Parrot there is an /ext
directory that doesn't appear to get bundled with Parrot during the
make install phase (not sure if this is the case on *.nix though). Perl
6 can run PIR inline and load it from the file system as well. To get
the Perl 6 versions of the DBDI.pm and SQLite3.pm to work I had to copy
over the "runtime" directory from the parrot source tree (after the
build) to my project working directory. I also copied over the SQLite3
directory under /ext to a subdirectory under my project directory and
set the PERL6LIB environment variable to that directory.

I
used the sample Perl 6 code from the PerlBuzz article, but I am getting
a silent exception during the connection phase. Once I compiled the
SQLite3.pir to bytecode in Parrot, I received some more clues.

C:\t\dv\rakudo-perl6\perl6-playground>perl6  chksql.p6
Null PMC access in invoke()
in method DBDI::Driver::SQLite3::getConnection (\t\dv\rakudo-perl6\perl6-playground\libSQLite3/DBDI/Driver/SQLite3.pm:17)
called from method DBDI::DriverManager::getConnection (\t\dv\rakudo-perl6\perl6-playground\libSQLite3/DBDI.pm:21)
called from Main (chksql.p6:5)

Running perl6 with a trace flag produces a inordinate volume of output.

I believe the root cause stems from the SQLite3.pir

.sub 'open'
  .param string connectstr
  .local pmc dbhandle
 
 .local pmc open_raw
  .local int rc

  open_raw = get_global 'open_raw'
  dbhandle = new 'Pointer'
  rc = open_raw(connectstr, dbhandle)
  .return(dbhandle)
.end


I can't help to think that Windows might just be the problem :). I
don't have a Linux environment currently. Maybe I can install a Ubuntu
VMWare virtual appliance with the VMWare Player and try again on that
platform.

If the current Perl 6/Parrot database interface
implementation proves to be problematic on all platforms, maybe REST is
the best interim approach.

T

-- Todd Presta

-- http://www.asciiville.com

-- Todd Presta

-- http://www.asciiville.com

--- On Mon, 7/13/09, Jonathan Brown <jbrown at reachlocal.com> wrote:

From: Jonathan Brown <jbrown at reachlocal.com>
Subject: RE: [Thousand-oaks-pm] In anticipation of Perl 6 Hackathon
To: "'Todd Presta'" <toddpresta at sbcglobal.net>, "'Andrew Grangaard'" <agrangaard at rubiconproject.com>
Cc: thousand-oaks-pm at pm.org
Date: Monday, July 13, 2009, 5:45 PM



 
 
I can take a look into the XML parsing.  Those services 
likely have JSON options as well that may or may not be preferable.  I 
haven't really looked at Perl 6's regex support at all yet though, so it might 
take me a bit longer.
 
We could certainly take a mixed Perl 5 and 6 approach, if 
that's what you meant for implementing the REST services for components too hard 
to do in Perl 6 yet.  Another clean separation point is the actual html + 
js web UI; we could expose the data the UI needs in a JSON service, for 
instance, and consume that from JS and get Joose in here 
too.
...
...
...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/thousand-oaks-pm/attachments/20090714/1c679d88/attachment.html>