1. sqlite users?
Hi
Is any body out there using sqlite3?
If so, have you tried downloading the latest library (3.4.2). I believe it may
be broken when being used with euphoria on Linux.
I am currently using the 3.3.6 binary downloaded from the sqlite.org site a
while
back, and wanted to check a very occasional possible updating error in the
database by updating the library, so I downloaded version 3.4.2, and installed
it in /usr/lib (the same place as 3.3.6), ran ldconfig, adjusted sqlite3.ew,
and tried to run the program again - unfortunately sqlite3.ew reported that
it could not find it.
Checks run
eusqlite3.ew back to sqlite-3.3.6.so - worked again
eusqlite.ew back to sqlite-3.4.2.so - not working.
sqlite-3.4.2.so put into /usr/local/lib, ldconfig run.
The program runs on a 64 bit system - so I ran it on a 32 bit system - 3.3.6
worked, but 3.4.2 did not.
The sqlite3 tool that comes with the package (after compiling the src tree
on the 64 bit system) works.
Tried redirecting eusqlite3.ew to /usr/local/lib/libsqlite3.so, where the
sqlite compilation deposits the .so
If anybody else can run sqlite-3.4.2.so then I would be grateful to know.
However, I believe this brings up an important point. This is one of euphorias
greatest stumbling points - its inability to interface with certain external
libraries.
Why do I have to jump through hoops to try to get a fairly simple lib like
sqlite working? Sometimes it seems like pot luck trying to get a library
working, that clearly works with compiled c programs.
Why is there so little feedback from the routines that call external libraries?
Why is it so complex to interface with C++ dlls?
Why does eu differentiate between calling conventions (the '+'), and rely
on the user to define them - could eu not detect, and modify internally its
calling conventions.
Why can't eu itemise the symbol table in .dlls / .so s, so that they would
become
immediately useable?
I realise these are highly simplistic, and possible some unrealistic musings
but I firmly believe that this is where language development should be
concentrated. Perhaps creating structure types is a first step on easier
library accessibility.
I'm quite frustrated by this. As far as sqlite goes, if they have changed some
compilation method, then in order to allow eusqlite3.ew to run with future
versions, it may either need a rewrite, or stagnate at 3.3.6. And that rewrite
only becomes possible if a NULL isn't returned trying to open the library.
Chris
2. Re: sqlite users?
ChrisBurch3 wrote:
>
> Hi
>
> Is any body out there using sqlite3?
>
> If so, have you tried downloading the latest library (3.4.2). I believe it may
> be broken when being used with euphoria on Linux.
<snip>
> However, I believe this brings up an important point. This is one of euphorias
> greatest stumbling points - its inability to interface with certain external
> libraries.
>
> Why do I have to jump through hoops to try to get a fairly simple lib like
> sqlite working? Sometimes it seems like pot luck trying to get a library
> working, that clearly works with compiled c programs.
It depends on what was changed. It's not clear to me exactly what you
tried. Did you try building (or downloaded?) something that used
v3.4.2? There could be some changes to the underlying libraries, some of
which could be incompatible with what Euphoria uses (i.e., libc).
> Why is there so little feedback from the routines that call external
> libraries?
>
> Why is it so complex to interface with C++ dlls?
C++ is difficult, unless you're writing C++ and using the same compiler.
And compiler version is important, because the ABI often changes. There
are also issues about which allocator is used to construct and destroy
objects.
In short, if you're dealing with C++, my advice would be to write your
own thin wrapper around the C++ and expose a C interface that accepts
euphorian data types. This is what I've done with wxEuphoria, and I
can't tell you how many headaches it has prevented. It's also really
sped up development.
> Why does eu differentiate between calling conventions (the '+'), and rely
> on the user to define them - could eu not detect, and modify internally its
> calling conventions.
On Linux, it's automatically cdecl. There's no way to automatically detect
the calling convention on windows.
> Why can't eu itemise the symbol table in .dlls / .so s, so that they would
> become
>
> immediately useable?
>
> I realise these are highly simplistic, and possible some unrealistic musings
> but I firmly believe that this is where language development should be
> concentrated. Perhaps creating structure types is a first step on easier
> library accessibility.
I think that if we had real OOP structures (as I've semi-proposed here
lately) it would be fairly straightforward to write code to automate
structures and other memory structures.
> I'm quite frustrated by this. As far as sqlite goes, if they have changed some
> compilation method, then in order to allow eusqlite3.ew to run with future
> versions, it may either need a rewrite, or stagnate at 3.3.6. And that rewrite
> only becomes possible if a NULL isn't returned trying to open the library.
Have you tried building it (SQLLite) yourself? Again, since you're on
a 64 bit native system, this may complicate things, as you may need to
force 32-bit to work with eu.
Matt
3. Re: sqlite users?
- Posted by ChrisBurch3 <crylex at ?ma?l.com>
Aug 29, 2007
-
Last edited Aug 30, 2007
Matt Lewis wrote:
>
> ChrisBurch3 wrote:
> >
> > Hi
> >
> > Is any body out there using sqlite3?
> >
> > If so, have you tried downloading the latest library (3.4.2). I believe it
> > may
> > be broken when being used with euphoria on Linux.
>
> <snip>
>
> > However, I believe this brings up an important point. This is one of
> > euphorias
> > greatest stumbling points - its inability to interface with certain external
> > libraries.
> >
> > Why do I have to jump through hoops to try to get a fairly simple lib like
> > sqlite working? Sometimes it seems like pot luck trying to get a library
> > working, that clearly works with compiled c programs.
>
> It depends on what was changed. It's not clear to me exactly what you
> tried. Did you try building (or downloaded?) something that used
> v3.4.2? There could be some changes to the underlying libraries, some of
> which could be incompatible with what Euphoria uses (i.e., libc).
Yes, I built, from source, sqlite 3.4.2, it worked with the sqlite tool (a
command line tool for accessing sqlite databases), but didn't work with eu
>
> > Why is there so little feedback from the routines that call external
> > libraries?
> >
> > Why is it so complex to interface with C++ dlls?
>
> C++ is difficult, unless you're writing C++ and using the same compiler.
> And compiler version is important, because the ABI often changes. There
> are also issues about which allocator is used to construct and destroy
> objects.
>
> In short, if you're dealing with C++, my advice would be to write your
> own thin wrapper around the C++ and expose a C interface that accepts
> euphorian data types. This is what I've done with wxEuphoria, and I
> can't tell you how many headaches it has prevented. It's also really
> sped up development.
Yes, I know, but my point is that it _should_ be easier than that.
>
> > Why does eu differentiate between calling conventions (the '+'), and rely
> > on the user to define them - could eu not detect, and modify internally its
> > calling conventions.
>
> On Linux, it's automatically cdecl. There's no way to automatically detect
> the calling convention on windows.
Thanks, I didn't know that.
>
> > Why can't eu itemise the symbol table in .dlls / .so s, so that they would
> > become
> >
> > immediately useable?
> >
> > I realise these are highly simplistic, and possible some unrealistic musings
> > but I firmly believe that this is where language development should be
> > concentrated. Perhaps creating structure types is a first step on easier
> > library accessibility.
>
> I think that if we had real OOP structures (as I've semi-proposed here
> lately) it would be fairly straightforward to write code to automate
> structures and other memory structures.
>
> > I'm quite frustrated by this. As far as sqlite goes, if they have changed
> > some
> > compilation method, then in order to allow eusqlite3.ew to run with future
> > versions, it may either need a rewrite, or stagnate at 3.3.6. And that
> > rewrite
> > only becomes possible if a NULL isn't returned trying to open the library.
>
> Have you tried building it (SQLLite) yourself? Again, since you're on
> a 64 bit native system, this may complicate things, as you may need to
> force 32-bit to work with eu.
Yes I have, I also have access to 32 bit machines, and tried building on there -
same result. Libc / eu incompatabilities may be at fault again, (you can't build
euphoria
on a 62 bit linux machine - rephrase - I can't, with gcc 4.02 at least)
I have similar problems with your current wx euphoria, which won't run, whereas
the old one
(built on 32 bit machines) runs fine. It's incredibly frustrating.
Thanks for replying.
Chris
>
> Matt
