Taking a quick look at the source, and not knowing CMUCL FFI's,
it appears that MaiSQL is quite specific for CMUCL.
Has anyone heard of an available port of MaiSQL to Allegro?
--
Kevin Rosenberg
·····@rosenberg.net
Kevin Rosenberg <·····@rosenberg.net> writes:
> Taking a quick look at the source, and not knowing CMUCL FFI's,
> it appears that MaiSQL is quite specific for CMUCL.
The FFI bindings are CMU CL specific, and a little bit of the main
package is (see e.g. map-query, which uses a CMU CL internal function
to create the result sequence).
Porting itself isn't all that difficult, depending on the backend:
MySQL requires a far more intricate FFI than PostgreSQL. But writing
the FFI stuff should be fairly straight-forward.
In the version available from the public PMSF CVS repository you'll
find a new native backend to PostgreSQL, that talks to the PostgreSQL
process using the documented socket-level protocol. Porting that
backend should be even easier (probably only the connect call will
have to be changed). But beware that this backend is as yet not well
tested, so a number of bugs might remain.
> Has anyone heard of an available port of MaiSQL to Allegro?
IIRC then Stig Erik Sandoe did port MaiSQL to ACL for a project of
his, so maybe he could give more information... Searching for his
name in c.l.l through groups.google.com should provide you with a
recent email adress...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, Pierre R. Mai wrote:
> The FFI bindings are CMU CL specific, and a little bit of the main
> package is (see e.g. map-query, which uses a CMU CL internal function
> to create the result sequence).
>
> Porting itself isn't all that difficult, depending on the backend:
> MySQL requires a far more intricate FFI than PostgreSQL. But writing
> the FFI stuff should be fairly straight-forward.
>
> In the version available from the public PMSF CVS repository you'll
> find a new native backend to PostgreSQL, that talks to the PostgreSQL
> process using the documented socket-level protocol. Porting that
> backend should be even easier (probably only the connect call will
> have to be changed). But beware that this backend is as yet not well
> tested, so a number of bugs might remain.
>
>> Has anyone heard of an available port of MaiSQL to Allegro?
>
> IIRC then Stig Erik Sandoe did port MaiSQL to ACL for a project of
> his, so maybe he could give more information... Searching for his
> name in c.l.l through groups.google.com should provide you with a
> recent email adress...
Thanks for the very informative post. I'll let you know if I end up
doing any work with MaiSQL that you might want to merge with your
distribution.
Thanks for your public domain contribution!
--
Kevin Rosenberg
·····@rosenberg.net
* "Pierre R. Mai" <····@acm.org>
|
| Porting itself isn't all that difficult, depending on the backend:
| MySQL requires a far more intricate FFI than PostgreSQL. But writing
| the FFI stuff should be fairly straight-forward.
I wrote bindings to MySQL's client library for Allegro CL a couple of
years ago. If the code can help in porting MaiSQL to Allegro, I'd be
happy to contribute it; email me for a copy.
--
Vebjorn Ljosa
Kevin Rosenberg wrote:
>
> Has anyone heard of an available port of MaiSQL to Allegro?
I have a MaiSQL port to ACL using PosgreSQL backend only.
--
Vladimir Zolotykh ······@eurocom.od.ua
In article <·················@eurocom.od.ua>, Vladimir Zolotykh wrote:
>> Has anyone heard of an available port of MaiSQL to Allegro?
> I have a MaiSQL port to ACL using PosgreSQL backend only.
I know it is application dependent, but can you share the magnitude of
any performance improvements by talking directly to PostgreSQL
vs. using Allegro's ODBC interface?
Secondly, have you published your code for others to use? I'd be interested
in how you converted CMUCL's FFI to Allegro's in case I decice to do the
same for MySQL.
Thanks!
--
Kevin Rosenberg
·····@rosenberg.net
Kevin Rosenberg wrote:
>
> > I have a MaiSQL port to ACL using PosgreSQL backend only.
>
> I know it is application dependent, but can you share the magnitude of
> any performance improvements by talking directly to PostgreSQL
> vs. using Allegro's ODBC interface?
Didn't compare.
>
> Secondly, have you published your code for others to use? I'd be interested
> in how you converted CMUCL's FFI to Allegro's in case I decice to do the
> same for MySQL.
Didn't publish it. First, I don't know MySQL. Second, I'm new to Lisp
and not sure the porting was done the proper way. Don't you think that
the author will be able to make better use of it if we send a copy to him?
--
Vladimir Zolotykh ······@eurocom.od.ua
In article <·················@eurocom.od.ua>, Vladimir Zolotykh wrote:
> Kevin Rosenberg wrote:
>> any performance improvements by talking directly to PostgreSQL
> ...
> Didn't compare.
That would be my goal. ODBC works fine for me and I like to
flexibility of plugging in a new SQL backend. I am hoping, though, for
1.5 - 2x performance improvement in my application by cutting out the
ODBC middleman.
> Didn't publish it. First, I don't know MySQL. Second, I'm new to Lisp
> and not sure the porting was done the proper way. Don't you think that
> the author will be able to make better use of it if we send a copy to him?
I think that is a great idea. Pierre should know best how your style
and changes fit into his model. If your code is working or near
working, it should be a significant feature improvement for the
package.
--
Kevin Rosenberg
·····@rosenberg.net
Kevin Rosenberg wrote:
> ..... If your code is working ...
Its working. I tested it carefully Beside that I used it in moreor less real
tasks, which finds bugs better than anything else.
In article <················@eurocom.od.ua>, Vladimir Zolotykh wrote:
>
> Kevin Rosenberg wrote:
> Its working. I tested it carefully Beside that I used it in moreor less real
> tasks, which finds bugs better than anything else.
Great. Yes, I find that diverse aspects of "real tasks" tend to test
the assumptions made during coding.
I'll send e-mail.
--
Kevin Rosenberg
·····@rosenberg.net