...

...

...

...

"Austin" == Austin Seipp writes:

Austin> Have you tried the simple sqlite3 bindings available? Austin> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite Not (yet), but those are the one I mentioned (besides HDBC) under d) ;) Austin> Takusen is based on the (unique) concept of a left-fold Austin> enumerator. Having a left-fold interface guarantees timely Austin> (nearly perfect, really) deallocation of resources while still Austin> having the benefits of a 'lazy' stream. This interface has (as Austin> shown by Oleg and others) proven to be very efficient in a Austin> number of cases as well as favorable for many. The idea is very Austin> novel, and truly worth exploring if you ask me. Thank you very much. I went through the docs for which you provided some references - I cannot claim I understood everything, but it sounds/looks quite interesting and worth exploring. Is there any simple tutorial about using Takusen available somewhere? Austin> NB: I have *just* (about 5 minutes ago) sent in a patch for Austin> takusen to get it to build on GHC 6.10.1 to Oleg. Hopefully an Austin> updated version will appear on hackage in the next few days. Great news! Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

Hi Austin, could you post the patch please? So far there is no updated version of takusen that builds with ghc 6.10 Günther On 3 Jan., 11:25, Austin Seipp wrote:

Excerpts from Gour's message of Sat Jan 03 03:48:44 -0600 2009:

...

Hi!

...

I'd like to use sqlite3 as application storage in my haskell project...

...

Browsing the available database options in Haskell it seems that:

...

a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10)

...

b) haskelldb is also not in a good shape - build fails with 6.8 & 6.10

...

For Haskell-newbie as myself, it looks that haskelldb is the one which provide(ed)s the most secure API (I was reading draft paper about MetaHDBC but, apparently, the type inference support in open-source databases is poor and that's why, according to the author "This is unfortunately as it makes MetaHDBC a lot less valuable."

...

What remains is:

...

c)Takusenwhich is also not up-to-date (it fails with 6.10) and

...

d) HDBC and sqlite bindings which are the only packages which build with 6.10.

Have you tried the simple sqlite3 bindings available?http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite

...

I'm not familiar withTakusenwhich says: "Takusen'sunique selling point is safety and efficiency..." and I would appreciate if someone could shed some more light to its 'safety' and the present status?

Takusenis based on the (unique) concept of a left-fold enumerator. Having a left-fold interface guarantees timely (nearly perfect, really) deallocation of resources while still having the benefits of a 'lazy' stream. This interface has (as shown by Oleg and others) proven to be very efficient in a number of cases as well as favorable for many. The idea is very novel, and truly worth exploring if you ask me.

For more information about left-fold enumerators andtakusen, see here:

http://okmij.org/ftp/papers/LL3-collections-enumerators.txthttp://okmij.org/...

NB: I have *just* (about 5 minutes ago) sent in a patch fortakusen to get it to build on GHC 6.10.1 to Oleg. Hopefully an updated version will appear on hackage in the next few days.

Austin _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe

I recently got an email back from Alstair Bayley who is one of the Takusen authors, and they said they are preparing a GHC 6.10 release (I was *not* the only person to submit a patch for ghc 6.10 building) but it may take a little while. You might want to get in contact with Alstair and ask what the current progress is.

I've got it building (tests pass etc) but the haddock docs won't build at present (with ghc-6.10.1). I want to get these little problems sorted out before I package up the next release. If you're desperate then I could push what I have so far into the repo and you could build from that. Alistair

2009/1/30 guenni68 :

Hi Alistair,

yes, please, pretty please do!

I really am desparate, I'm running into so much trouble because I have to export to MS-Access and I'm a little out of luck with HDBC. HDBC works like a charm unless you have to use MS-Access.

Hmm... it's not likely you'll have much success with Takusen either, as you will also have to use the ODBC bindings for MS Access, and I have not tested this combination. Perhaps you can consider an alternative route for export, like CSV? Alistair

...

...

...

...

"Henning" == writes:

Henning> No, it is maintained by frederik@ofb.net . I have also Henning> contributed Oracle/OCI code a half year ago. Oops, I stand corrected...nice to hear. Still, it would be nice to present some info 'cause web site still shows 1.7 from Dec '05 as the latest release :-( Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

...

...

...

...

"Johannes" == Johannes Waldmann writes:

Johannes> see Johannes> http://article.gmane.org/gmane.comp.lang.haskell.libraries/10490 Thanks. Is it just a 'fix' or HSQL will be properly maintained as well? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

Gour wrote:

John> HDBC is a low-level abstraction, which can be used on its own or, John> of course, as a layer underlying HaskellDB or some such. I do not John> dispute the use of tools such as HaskellDB or others that try to John> automate the business of representing a database's schema -- and John> queries against it -- using a language's type system. There are a John> lot of these systems in a lot of languages. I've used some of John> them.

Have you maybe tried Takusen (HaskellDB which you reference above does not seem very much alive)?

No, I haven't, unfortunately.

Otoh, I believe that, considering it is mentioned in RWH, HDBC does not need much commercial, just contrary, you can expect new feature requests From the new army of Haskell developers cultivated by the book :-)

That's great. Even better if accompanied by a patch ;-)

I'll e.g. open ticket for BLOB support :-D

Of course :-)

Database abstraction offered by HDBC is very nice feature allowing one to change back-end driver without too much hassle, so I'll try to investigate a bit about possible BLOB support on HDBC-level.

That would be wonderful.

It's definitely something used in real-world databases...

Yes, I'm quite aware of that. Just not *my* particular ones ;-) -- John

Gour wrote:

...

...

...

...

...

"John" == John Goerzen writes:

John> That's great. Even better if accompanied by a patch ;-)

Heh, one of the things which prevents me advancing with my own Haskell project is lack of enough skills to provide bindings for one C-lib and here I see the same pattern...It looks I have to cross it over :-)

...

...

I'll e.g. open ticket for BLOB support :-D

John> Of course :-)

I did it - have you seen the notice about problems with HDBC-forums?

Yes. I am thoroughly displeased with Ruby on Rails at the moment. It is less maintainable than a network of DOS boxes. There are a host of mysterious crashes in Redmine at the moment -- including one where pulling up the page for one specific bug (but none others) crashes the server. I could upgrade Redmine, but that requires a Ruby stack that is partly newer than what's in Debian, and the upgrade for that process appears to succeed, but then fails in mysterious ways at the end. To anyone annoyed with Haskell's library install process: you have no idea how good you have it unless you've tried Ruby and rails. -- John

* John Goerzen [2009-01-13 12:37:45 -0600]:

Gour wrote:

...

...

...

...

...

> "John" == John Goerzen writes:

John> That's great. Even better if accompanied by a patch ;-)

Heh, one of the things which prevents me advancing with my own Haskell project is lack of enough skills to provide bindings for one C-lib and here I see the same pattern...It looks I have to cross it over :-)

...

...

I'll e.g. open ticket for BLOB support :-D

John> Of course :-)

I did it - have you seen the notice about problems with HDBC-forums?

Yes. I am thoroughly displeased with Ruby on Rails at the moment. It is less maintainable than a network of DOS boxes. There are a host of mysterious crashes in Redmine at the moment -- including one where pulling up the page for one specific bug (but none others) crashes the server.

I could upgrade Redmine, but that requires a Ruby stack that is partly newer than what's in Debian, and the upgrade for that process appears to succeed, but then fails in mysterious ways at the end.

Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable releases, so I think an upgrade of your ruby stack is very reasonable.

To anyone annoyed with Haskell's library install process: you have no idea how good you have it unless you've tried Ruby and rails.

Disagree. Rubygems is fairly easy to use. At lease, I can guess how to uninstall a package by trying 'gem uninstall foobar', but failed by trying 'cabal uninstall/remove foobar' :-) Jan

-- John

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- jan=callcc{|jan|jan};jan.call(jan)

* John Goerzen [2009-01-13 20:53:40 -0600]:

Xie Hanjian wrote:

...

* John Goerzen [2009-01-13 12:37:45 -0600]:

Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable releases, so I think an upgrade of your ruby stack is very reasonable.

It also requires a newer version of rake than is in Debian. Not a problem as such, but you start working with gem install commands (and their friends), and eventually find that after spending 30 minutes installing/upgrading stuff, it bombs at the very end saying that some component needed a newer version of something than is available, and it can't install that component, so it's left the server hosed -- too new to run the old version, not ready to accept the new. Great.

It ought to have checked the dependencies *before* messing with my system. And it ought not to have failed mysteriously anyhow.

...

...

To anyone annoyed with Haskell's library install process: you have no idea how good you have it unless you've tried Ruby and rails.

Disagree. Rubygems is fairly easy to use. At lease, I can guess how to

It is completely poorly documented on how to gem install something when you don't have root. The gem(1) manpage is a joke. The online help doesn't help much either. Turns out there is a magic combination of undocumented environment variables and documented command-line options that does it. Or at least, I *thought* it does it.

The other problem about Rails is that code and data are inseparably mixed. It will be just about impossible to install a rails app as a Debian package because it needs write access to its install directory, and this stuff is not easily configured to use /usr and /etc as appropriate.

From your description it seems debian's rails stack mess you up, not ruby/rails itself. And I think install a rails app as a debian package is not a good idea.

Anyhow, this is a Haskell list, so I'm not going to rant any more about this here. I can give you details off-list if you like. It's touched a

ok :-| Jan

nerve lately.

-- John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- jan=callcc{|jan|jan};jan.call(jan)

Mauricio> I've been doing a lot of low level sqlite3 lately (it's going Mauricio> to be on a hackage package as soon as I finish my current Mauricio> work).

Have you done any work with BLOBs?

No. Only sqlite3_exec with INSERT, SELECT stuff, and saving everything that needs structure in pseudo-xml strings. Not that efficient, but easy to change to blobs when everything is ready and tested. Maurício

Mauricio> No. Only sqlite3_exec with INSERT, SELECT stuff, Mauricio> and saving everything that needs structure in pseudo-xml Mauricio> strings. Not that efficient, but easy to change to blobs when Mauricio> everything is ready and tested.

I see...I'm thinking to maybe store only paths for bigger BLOBs, but still there is need to store smaller (thumbnails pics) ones...

You can always uuencode the pictures. Package 'dataenc' seems nice, although I have not used it. Best, Maurício