Hello all,
I would like to announce the release of SQLite3db.
This release represents a complete rewrite of the externals. It has been rolled into a single external library containing the externals [sqlite3db], [sqlite3query], [sqlite3rowid], and [sqlite3blob].
This release includes several features:
Database can be on disk or an in-memory database.
The [sqlite3query] object now supports Place Holders.
Comprehensive error reporting.
Includes a separate object for retrieving the ID for the last
record inserted (allows making links between tables)
You can get the archive for files at:
http://puredata.info/Members/mjmogo/SQLite3db_v0_03.zip/view
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Let me know if you have any suggestions, criticism, or general praises ;)
Mike
Sounds like a fast way to store a ton of preferences. I think I
remembered in our old discussions about it that sqlite was fast enough
that the Pd object didn't need to be threaded, which is nice.
I think the code would be a lot easier to read if the classes where
broken out into separate files. This is the standard way to do with
externals: one class per file. Then it would be possible to also
compile each class as a separate .pd_darwin, or compile it like you
have now.
.hc
On Mar 1, 2009, at 2:10 PM, Mike McGonagle wrote:
Hello all,
I would like to announce the release of SQLite3db.
This release represents a complete rewrite of the externals. It has been rolled into a single external library containing the externals [sqlite3db], [sqlite3query], [sqlite3rowid], and [sqlite3blob].
This release includes several features:
Database can be on disk or an in-memory database.
The [sqlite3query] object now supports Place Holders.
Comprehensive error reporting.
Includes a separate object for retrieving the ID for the last
record inserted (allows making links between tables)
- SSSAD plug-and-play panel for storing multiple sets of SSSAD
parameters.
You can get the archive for files at:
http://puredata.info/Members/mjmogo/SQLite3db_v0_03.zip/view
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Let me know if you have any suggestions, criticism, or general
praises ;)Mike
--
Jean-Luc Godard - "To be or not to be. That's not really a question."
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
¡El pueblo unido jamás será vencido!
Hi Hans,
The reason that I put them all into a single source file is because they share other C data structures. Basically, the method I was using (in the older version) to share info back and forth between the objects was to pass messages back and forth. That got to be a bit confusing to deal with, as it was difficult to know exactly when a message might get sent or received. I understood it, but even after being away from it for a couple of months, it got hard to remember exactly what was going on, let alone anyone else figuring things out.
Plus, another reason that I need to share access to the objects on the C level was so that when you close a database, it does not get corrupted because an SQL statement didn't get finalized (all prepared SQL statements need to be "destroyed" before a database can be closed safely).
Do you know of a way that different externals can share access to C level code and objects?
Mike On Sun, Mar 1, 2009 at 4:12 PM, Hans-Christoph Steiner hans@eds.org wrote:
Sounds like a fast way to store a ton of preferences. I think I remembered in our old discussions about it that sqlite was fast enough that the Pd object didn't need to be threaded, which is nice.
I think the code would be a lot easier to read if the classes where broken out into separate files. This is the standard way to do with externals: one class per file. Then it would be possible to also compile each class as a separate .pd_darwin, or compile it like you have now.
.hc
On Mar 1, 2009, at 2:10 PM, Mike McGonagle wrote:
Hello all,
I would like to announce the release of SQLite3db.
This release represents a complete rewrite of the externals. It has been rolled into a single external library containing the externals [sqlite3db], [sqlite3query], [sqlite3rowid], and [sqlite3blob].
This release includes several features:
Database can be on disk or an in-memory database.
The [sqlite3query] object now supports Place Holders.
Comprehensive error reporting.
Includes a separate object for retrieving the ID for the last
record inserted (allows making links between tables)
- SSSAD plug-and-play panel for storing multiple sets of SSSAD
parameters.
You can get the archive for files at:
http://puredata.info/Members/mjmogo/SQLite3db_v0_03.zip/view
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Let me know if you have any suggestions, criticism, or general praises ;)
Mike
--
Jean-Luc Godard - "To be or not to be. That's not really a question."
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
¡El pueblo unido jamás será vencido!
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Attached is a quickie makefile to compile a pd_linux. Use "make pd_linux".
Frank Barknecht Do You RjDj.me? _ ______footils.org__
2009/3/2 Frank Barknecht fbar@footils.org
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Attached is a quickie makefile to compile a pd_linux. Use "make pd_linux".
hey
thanks for that!
i will try on linux
abraço
glerm
Frank,
Thank you very much for the Linux Makefile. While I don't have access to a machine right at the moment, from reading this, it appears that this is set up to link to an SQLite3 LIBRARY file, right? If that is the case, the way that I am doing this on the Mac is to compile the object code of the compiled SQLite code, I am not linking to a library object.
I pretty much do that because the Mac uses SQLite for a LOT of system things, and I have heard that there can be some issues with updating the Library object for SQLite on your system, and then the Mac does one of it "auto updates", finds that the SQLite object file is DIFFERENT than the one currently installed, and then will overwrite the NEWER version you just compiled, with the older library object.
I don't know if this is a similar situation on Linux. At the same time, is it really necessary to have all the platforms do the same thing? I don't know how something like this might be handled in the Night Build system.
Thanks again, I will probably have to wait a day or two before I might be able to try this myself.
Mike
On Mon, Mar 2, 2009 at 3:56 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Attached is a quickie makefile to compile a pd_linux. Use "make pd_linux".
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Thank you very much for the Linux Makefile. While I don't have access to a machine right at the moment, from reading this, it appears that this is set up to link to an SQLite3 LIBRARY file, right? If that is the case, the way that I am doing this on the Mac is to compile the object code of the compiled SQLite code, I am not linking to a library object.
I pretty much do that because the Mac uses SQLite for a LOT of system things, and I have heard that there can be some issues with updating the Library object for SQLite on your system, and then the Mac does one of it "auto updates", finds that the SQLite object file is DIFFERENT than the one currently installed, and then will overwrite the NEWER version you just compiled, with the older library object.
It's true, my Linux makefile links to the system wide version of sqlite3 and thus requires that and its -dev(el) headers installed. While it can happen that the distribution's package managers install versions that are newer/incompatible to the one you are using with the Pd library, we Linux users don't care too much and just do another "make pd_linux". ;)
But my main reason was that I'm not good at writing makefiles at all so I just copied the standard snippet over with as little changes as possible. I only removed the -Werror (there is one warning when compiling which breaks on Linux) and added the library linking with -lsqlite3.
Frank
So, then do you think it would be better to link up to the system version? Or should I have it statically compile everything together into the external? While I don't know how large it is on Linux, but the Mac external (with the SQLite Amalgamated compile into the external) is about 660K.
I have had the discussion with many people who "advocate" Linux about how "user friendly" it really is, and something tells me that this 'and just do another "make pd_linux"' might not be what we want for NON-Technical users. I mean, so far there appears to be a few people who are interested in using this, but because there is no make file, they have not been able to try this.
Mike
On Mon, Mar 2, 2009 at 12:21 PM, Frank Barknecht fbar@footils.org wrote:
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Thank you very much for the Linux Makefile. While I don't have access to a machine right at the moment, from reading this, it appears that this is set up to link to an SQLite3 LIBRARY file, right? If that is the case, the way that I am doing this on the Mac is to compile the object code of the compiled SQLite code, I am not linking to a library object.
I pretty much do that because the Mac uses SQLite for a LOT of system things, and I have heard that there can be some issues with updating the Library object for SQLite on your system, and then the Mac does one of it "auto updates", finds that the SQLite object file is DIFFERENT than the one currently installed, and then will overwrite the NEWER version you just compiled, with the older library object.
It's true, my Linux makefile links to the system wide version of sqlite3 and thus requires that and its -dev(el) headers installed. While it can happen that the distribution's package managers install versions that are newer/incompatible to the one you are using with the Pd library, we Linux users don't care too much and just do another "make pd_linux". ;)
But my main reason was that I'm not good at writing makefiles at all so I just copied the standard snippet over with as little changes as possible. I only removed the -Werror (there is one warning when compiling which breaks on Linux) and added the library linking with -lsqlite3.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You should dynamically link to the libsqlite in the OS. Maybe for
Windows it would need to be statically linked.
.hc
On Mar 2, 2009, at 1:36 PM, Mike McGonagle wrote:
So, then do you think it would be better to link up to the system version? Or should I have it statically compile everything together into the external? While I don't know how large it is on Linux, but the Mac external (with the SQLite Amalgamated compile into the external) is about 660K.
I have had the discussion with many people who "advocate" Linux about how "user friendly" it really is, and something tells me that this 'and just do another "make pd_linux"' might not be what we want for NON-Technical users. I mean, so far there appears to be a few people who are interested in using this, but because there is no make file, they have not been able to try this.
Mike
On Mon, Mar 2, 2009 at 12:21 PM, Frank Barknecht fbar@footils.org
wrote:Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Thank you very much for the Linux Makefile. While I don't have
access to a machine right at the moment, from reading this, it appears that this is set up to link to an SQLite3 LIBRARY file, right? If that is the case, the way that I am doing this on the Mac is to compile the object code of the compiled SQLite code, I am not linking to a
library object.I pretty much do that because the Mac uses SQLite for a LOT of
system things, and I have heard that there can be some issues with updating the Library object for SQLite on your system, and then the Mac does one of it "auto updates", finds that the SQLite object file is DIFFERENT than the one currently installed, and then will overwrite the NEWER version you just compiled, with the older library object.It's true, my Linux makefile links to the system wide version of
sqlite3 and thus requires that and its -dev(el) headers installed. While it
can happen that the distribution's package managers install versions that are newer/incompatible to the one you are using with the Pd
library, we Linux users don't care too much and just do another "make
pd_linux". ;)But my main reason was that I'm not good at writing makefiles at
all so I just copied the standard snippet over with as little changes as possible. I only removed the -Werror (there is one warning when compiling which breaks on Linux) and added the library linking with -lsqlite3.Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
W. C. Fields - "I never drink water because of the disgusting things that fish do in it."
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you are not part of the solution, you are part of the problem.
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
I have had the discussion with many people who "advocate" Linux about how "user friendly" it really is, and something tells me that this 'and just do another "make pd_linux"' might not be what we want for NON-Technical users.
Well, usually you don't need to do it. But *if* something goes wrong, "make" to Linux users is what "reboot, reinstall app, reinstall Windows" is to Windows users. And if OS-X manages to update sqlite in a way that breaks simple objects using it (except for major version changes) than that's not very friendly to tech- and non-tech users.
I think, if you want to distribute general purppose binaries from your site or pd.info, then linking statically is fine for sqlite (and things like pdlua). But people who download the source and compile it on their own can make use of the system wide libraries, so the default in the Makefile should be dynamic linking IMO.
Frank Barknecht Do You RjDj.me? _ ______footils.org__