[Pharo-project] DBXTalk and Pharo 2.0
Guillermo wrote:
The last time I tried to load DBXTalk in 2.0 the image hang up when loading FFI :(. So probably we should think on switching to NB FFI, but it will take some time...
Mhhh ... when I load ConfigurationOfFFI configuration browser and then manually load "FFI-Tests-tbn.6" from http://source.squeakfoundation.org/FFI all tests are green on Windows. And yes - migrating to NB makes sense!
BTW, since Igor has worked on the bundling of native libraries, we can probably do that with the dbxtalk native libs also :)
OK - looks like the infrastructure is ready. What is required to do that? Will you send the libraries to Igor and he just bundles them? That would be cool and save many people a lot of time.
All dbxtalk should be working in 1.4 so far. I also try to update it with the contributions of people but sometimes my hands are full :).
thanks for that. It is a very important project and I would like to see it easily installable and working in Pharo 2.0 too. Sven wrote:
I use it in 2.0 to access Postgresql databases using Glorp + the native (socket based) PostgresV2 driver. This works fine.
So we should put the config into the working configs for 2.0? Thx T.
On Mar 5, 2013, at 12:52 PM, Torsten Bergmann <astares@gmx.de> wrote:
Guillermo wrote:
The last time I tried to load DBXTalk in 2.0 the image hang up when loading FFI :(. So probably we should think on switching to NB FFI, but it will take some time...
Mhhh ... when I load ConfigurationOfFFI configuration browser and then manually load "FFI-Tests-tbn.6" from http://source.squeakfoundation.org/FFI all tests are green on Windows.
And yes - migrating to NB makes sense!
BTW, since Igor has worked on the bundling of native libraries, we can probably do that with the dbxtalk native libs also :)
OK - looks like the infrastructure is ready. What is required to do that? Will you send the libraries to Igor and he just bundles them? That would be cool and save many people a lot of time.
But accessing sql libs is not core so I would like to avoid to have a vm with all the librairies people used. You do not ***Imagine*** the amount of energy and time igor spent on making cairo backend be working on the three platforms.
All dbxtalk should be working in 1.4 so far. I also try to update it with the contributions of people but sometimes my hands are full :).
thanks for that. It is a very important project and I would like to see it easily installable and working in Pharo 2.0 too.
Sven wrote:
I use it in 2.0 to access Postgresql databases using Glorp + the native (socket based) PostgresV2 driver. This works fine.
So we should put the config into the working configs for 2.0?
Thx T.
On Tue, Mar 5, 2013 at 8:22 PM, stephane ducasse <stephane.ducasse@free.fr>wrote:
On Mar 5, 2013, at 12:52 PM, Torsten Bergmann <astares@gmx.de> wrote:
Guillermo wrote:
The last time I tried to load DBXTalk in 2.0 the image hang up when loading FFI :(. So probably we should think on switching to NB FFI, but it will take some time...
Mhhh ... when I load ConfigurationOfFFI configuration browser and then manually load "FFI-Tests-tbn.6" from http://source.squeakfoundation.org/FFI all tests are green on Windows.
And yes - migrating to NB makes sense!
BTW, since Igor has worked on the bundling of native libraries, we can probably do that with the dbxtalk native libs also :)
OK - looks like the infrastructure is ready. What is required to do that? Will you send the libraries to Igor and he just bundles them? That would be cool and save many people a lot of time.
But accessing sql libs is not core so I would like to avoid to have a vm with all the librairies people used. You do not ***Imagine*** the amount of energy and time igor spent on making cairo backend be working on the three platforms.
Actually for dbxtalk, I normally end up compiling all the 1.4.6 libs by myself and distribute them since there is no official binaries for that... :/
All dbxtalk should be working in 1.4 so far. I also try to update it with the contributions of people but sometimes my hands are full :).
thanks for that. It is a very important project and I would like to see it easily installable and working in Pharo 2.0 too.
Sven wrote:
I use it in 2.0 to access Postgresql databases using Glorp + the native (socket based) PostgresV2 driver. This works fine.
So we should put the config into the working configs for 2.0?
Thx T.
stephane ducasse wrote:
On Mar 5, 2013, at 12:52 PM, Torsten Bergmann <astares@gmx.de> wrote:
Guillermo wrote:
The last time I tried to load DBXTalk in 2.0 the image hang up when loading FFI :(. So probably we should think on switching to NB FFI, but it will take some time...
Mhhh ... when I load ConfigurationOfFFI configuration browser and then manually load "FFI-Tests-tbn.6" from http://source.squeakfoundation.org/FFI all tests are green on Windows.
And yes - migrating to NB makes sense!
BTW, since Igor has worked on the bundling of native libraries, we can probably do that with the dbxtalk native libs also :)
OK - looks like the infrastructure is ready. What is required to do that? Will you send the libraries to Igor and he just bundles them? That would be cool and save many people a lot of time.
But accessing sql libs is not core so I would like to avoid to have a vm with all the librairies people used. You do not ***Imagine*** the amount of energy and time igor spent on making cairo backend be working on the three platforms.
Next best would be (is it possible?) for the Configuration to download libraries and the VM to dynamically load them without restarting, so this could be down with one click from the Configuration Browser (maybe this is already the case?) Of course it would also be nice to have DBXtalk as some part of the ecosystem CI.
All dbxtalk should be working in 1.4 so far. I also try to update it with the contributions of people but sometimes my hands are full :).
thanks for that. It is a very important project and I would like to see it easily installable and working in Pharo 2.0 too.
Sven wrote:
I use it in 2.0 to access Postgresql databases using Glorp + the native (socket based) PostgresV2 driver. This works fine.
So we should put the config into the working configs for 2.0?
Thx T.
participants (4)
-
Ben Coman -
Guillermo Polito -
stephane ducasse -
Torsten Bergmann