Hello everyone, 1. NBSQLite3 seems to be missing from "Tools" -> "Configuration Browser" so I had to use the Gopher script. 2. I can't seem to get the around to installing the sqlite engine on my mac. What is the default folder there? Do I need this? 2a. On the same page with the one above. What is the location where the db.sqlite file must be copied to? On the mac I can put it in the same folder (no go) or "show package contents" on Pharo itself to see the folders inside the package, tried Contents/Resources there but no dice. No matter what I try I get a NBSQLite3Error: unable to open database file form one of the reasons above. Thank you, Mir S.
InstallationYou can access NBSQLite3 from the Pharo configuration browser. Just select "Tools" -> "Configuration Browser" from the world menu, enter "NBSQLite3" and install the stable version. Alternatively to install the packages manually into your Pharo image just evaluate:
If you need access to the SQLite3 database engine you need at a minimum the "NBSQLite3-Core" package which is loaded by the ConfigurationOfNBSQLite3 class. This package includes all necessary API to access the sqlite engine. Use in your own applicationProviding the library filesTo use the sqlite3 database engine in own Pharo projects you need to install the "sqlite3" database engine first. Basically it is only a shared library component that has to be found by the Pharo virtual machine. For instance on Windows operating system you can download the "sqlite3.dll" component from http://www.sqlite.org/ and copy it into the same directory where the Pharo VM (Pharo.exe) is. After loading NBSQLite3 as described before you can run the unit tests to see if anything is correctly setup and the virtual machine is able to find the sqlite3 engine. Use in your codeCreating a connectionThe most important class to use for creating a database is the class NBSQLite3Connection. For instance the following expression:
|
Forgot to mention I want to use a relative path if at all possible.
|
Hi Mircea,
- About the library: You can either install the sqlite library close to the VM or, as mac is a unix, in /usr/lib. I have for example mine in here: /usr/lib/libsqlite3.dylib The VM loads the libraries dinamically, so putting the library in one of those locations should IIRC by default look at those places. - about the db file: do you already have a db file you want to open? Usually the db file is next to the image again IIRC ^^. What you can actually try is opening an unexistent database, what will create a new file for you. That will give you an idea of where the database file should be placed. Hope that helps, Guille El Mon Jan 19 2015 at 9:54:56 AM, Mircea S. <[hidden email]> escribió:
|
Thank you for the fast response. 1. You are right. OS X 10.9 Mavericks and 10.10 Yosemite come with libsqlite3.dylib built in as SQLite3 is used in Safari and a number of other places. This is the reason Pharo and NBSQLite3 never complained about a missing library to start with. 2. The default location for the myfile.db still eludes me somehow. You are again right about NBSQLite3Connection on: '/Volumes/MacHDD/Users/Shared/myfile.db'. actually creating the file if none is found, however just using NBSQLite3Connection on: 'myfile.db'. without a path leaves me dumbfounded as to where this file is created, searching for produces no results. Maybe it's created inside the image itself somewhere?
|
On Mon, Jan 19, 2015 at 07:26:28PM +0200, Mircea S. wrote:
> NBSQLite3Connection on: 'myfile.db'. Without sending "open" to the resulting NBSQLite3Connection instance, no file gets created, IIRC. That's why I added "openOn:" in newer versions, although the tests may not be using openOn:. |
Hmm. Both "(NBSQLite3Connection on: 'test.db') open". or "NBSQLite3Connection openOn: 'test.db' " produce an "unable to open database file" error and no file gets created. Even tried to move the image to a FAT32 usb stick to make sure it wasn't a permission issue.
This is on a Pharo 3.0 image with NBSqlite3 installed via the Gopher script on github. Pe 24 ian. 2015, la 07:27, Pierce Ng <[hidden email]> a scris: >> On Mon, Jan 19, 2015 at 07:26:28PM +0200, Mircea S. wrote: >> NBSQLite3Connection on: 'myfile.db'. > > Without sending "open" to the resulting NBSQLite3Connection instance, no file > gets created, IIRC. That's why I added "openOn:" in newer versions, although > the tests may not be using openOn:. > > > |
On Mac OS X 10.10
Pe 25 ian. 2015, la 00:57, Mircea S. <[hidden email]> a scris: > Hmm. Both "(NBSQLite3Connection on: 'test.db') open". or "NBSQLite3Connection openOn: 'test.db' " produce an "unable to open database file" error and no file gets created. Even tried to move the image to a FAT32 usb stick to make sure it wasn't a permission issue. > > This is on a Pharo 3.0 image with NBSqlite3 installed via the Gopher script on github. > > Pe 24 ian. 2015, la 07:27, Pierce Ng <[hidden email]> a scris: > >>> On Mon, Jan 19, 2015 at 07:26:28PM +0200, Mircea S. wrote: >>> NBSQLite3Connection on: 'myfile.db'. >> >> Without sending "open" to the resulting NBSQLite3Connection instance, no file >> gets created, IIRC. That's why I added "openOn:" in newer versions, although >> the tests may not be using openOn:. >> >> >> > |
In reply to this post by basilmir
On Sun, Jan 25, 2015 at 12:57:22AM +0200, Mircea S. wrote:
> Hmm. Both "(NBSQLite3Connection on: 'test.db') open". or "NBSQLite3Connection > openOn: 'test.db' " produce an "unable to open database file" error and no > file gets created. Even tried to move the image to a FAT32 usb stick to make > sure it wasn't a permission issue. I get the same error on my OSX Mavericks, whereas on my Linux Mint 17 installation test.db is created in my image's directory. On OSX, "OSProcessAccessor forThisOSProcess primGetCurrentWorkingDirectory" gives "/", while on Linux the same gives "/home/pierce/work/pharo30". (Above requires the OSProcess package which is available from the Config Browser.) Hence I think this is a permission issue based on the default current directory of the VM operating system process being / on OSX. This suggests to use openOn: with a FQPN on OSX. Curiously, when I run Pharo.app as root via $ sudo ~/pkg/Pharo.app/Contents/MacOS/Pharo pharo30.image NBSQLite3Connection openOn: 'test.db' works, test.db -- owned by root -- is created in the directory where pharo30.image lives, and "OSProcessAccessor forThisOSProcess primGetCurrentWorkingDirectory" gives "/Users/pierce/working/pharo30"! Alright, it is not that curious. Taking away the sudo above, meaning invoking the VM on the command line as my regular UID, still gives the "correct" working directory. So this looks like some strange difference between the Cocoa (or Carbon?) OSX application Pharo.app and the Mach-O executable Pharo. |
> On 25 Jan 2015, at 07:13, Pierce Ng <[hidden email]> wrote: > > On OSX, "OSProcessAccessor forThisOSProcess primGetCurrentWorkingDirectory" > gives "/", while on Linux the same gives "/home/pierce/work/pharo30". (Above > requires the OSProcess package which is available from the Config Browser.) Why not just use FileSystem disk workingDirectory ? |
On Sun, Jan 25, 2015 at 09:54:12AM +0100, Sven Van Caekenberghe wrote:
> > On 25 Jan 2015, at 07:13, Pierce Ng <[hidden email]> wrote: > > On OSX, "OSProcessAccessor forThisOSProcess primGetCurrentWorkingDirectory" > > gives "/", while on Linux the same gives "/home/pierce/work/pharo30". (Above > > requires the OSProcess package which is available from the Config Browser.) > > Why not just use > FileSystem disk workingDirectory > ? It gives the expected answer on OSX, which is the directory where the image lives, and does not "explain" the OP's problem. :-) Pierce |
In reply to this post by Sven Van Caekenberghe-2
On Sun, Jan 25, 2015 at 09:54:12AM +0100, Sven Van Caekenberghe wrote:
> > > On 25 Jan 2015, at 07:13, Pierce Ng <[hidden email]> wrote: > > > > On OSX, "OSProcessAccessor forThisOSProcess primGetCurrentWorkingDirectory" > > gives "/", while on Linux the same gives "/home/pierce/work/pharo30". (Above > > requires the OSProcess package which is available from the Config Browser.) That sounds right. It calls getcwd() from the VM process. primGetCurrentWorkingDirectory "Call getcwd() to get the current working directory." The current working directory of the VM process will ("man 3 getcwd" for an exact description) will vary depending on how you launch the VM. Dave > > Why not just use > > FileSystem disk workingDirectory > > ? |
Free forum by Nabble | Edit this page |