MySQL and mzscheme 
Author Message
 MySQL and mzscheme

Hi!

        Is there any package equivalent to squile (for guile) for
mzscheme? I'd like to manage MySQL from scheme scripts. O:-)

//-----------------------------------------------
//      Fernando Rodriguez Romero
//
//      frr at mindless dot com
//------------------------------------------------



Tue, 02 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme


Quote:
> Hi!

>    Is there any package equivalent to squile (for guile) for
> mzscheme? I'd like to manage MySQL from scheme scripts. O:-)

plt has an odbc interface (SrPersist?).  combined with myodbc this
should provide what you are looking for.  in case you are running a
unixy os: there is a odbs for unix available now (www.unixodbc.org or
some such)

--

Hartmann Schaffer

It is better to fill your days with life than your life with days



Tue, 02 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:

>    Is there any package equivalent to squile (for guile) for
> mzscheme? I'd like to manage MySQL from scheme scripts. O:-)

PLT offers SrPersist, an ODBC interface.  SrPersist has been tested
and works portably on Windows, the Mac and Unix.  It has been tested
with both commercial and free database managers, including MySQL.

  http://www.cs.rice.edu/CS/PLT/packages/srpersist/

We have been using SrPersist to manage applications to our summer
teacher workshop, hooking it up to our CGI interface.  It's worked out
very well.

SrPersist currently provides only a thin layer atop ODBC.  We're not
happy with this as a programming interface.  We're looking for
interested people to help us implement a better programming model that
integrates better with the rest of Scheme.  Anyone interested?

Use SrPersist -- we'd love more feedback!

'shriram



Tue, 02 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme


: >  Is there any package equivalent to squile (for guile) for
: > mzscheme? I'd like to manage MySQL from scheme scripts. O:-)
:
: plt has an odbc interface (SrPersist?).  combined with myodbc this
: should provide what you are looking for.  in case you are running a
: unixy os: there is a odbs for unix available now (www.unixodbc.org or
: some such)

SrPersist is available at

    http://www.cs.rice.edu/CS/PLT/packages/srpersist/

In fact, at Rice we're using SrPersist in Scheme CGI scripts to
communicate with MySQL.  We use unixODBC as the Driver
Manager under Solaris.

Currently, SrPersist is ODBC-in-Scheme, and not much else.
We're working on a higher-level layer that should be
easier to use.

-- Paul

 ----------------------------------------------------------------
| Paul Steckler              |     Rice University PLT           |

| Tel:  713/348-3814         |     http://www.cs.rice.edu/~steck |
| FAX:  713/348-5930         |     *** Ad astra per hackera ***  |
 ----------------------------------------------------------------



Tue, 02 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:
> SrPersist currently provides only a thin layer atop ODBC.  We're not
> happy with this as a programming interface.  We're looking for
> interested people to help us implement a better programming model that
> integrates better with the rest of Scheme.  Anyone interested?
> Use SrPersist -- we'd love more feedback!

Certainly interested... though I wouldn't consider myself *yet* skilled
enough at Scheme to be of much use! I have, however, had a brief (but
successful) attempt at using SrPersist, so here's my two pence:

 - 1. Treating a record set (hstmt) as a port, so lots of code which used to
use files can switch to using databases with min hassle. (Including "load",
of course!)
 - 2. "Scheme-ising" the SQL: a statement like (select (fields name age)
(from people)) would be much easier to manipulate & dissect than the
corresponding SQL string. Perhaps a thin SQL-generating layer on top would
suffice. Or, of course, doing away with the whole SQL model (this can be
done in a still higher layer), which can use the existing class system and
map fields onto it. My gut feeling though is that ODBC's funny data typing
and general (but understandable) lack of orthogonality will put paid to any
hopes of having an idealogically sound system, but a practical system yes.

b



Wed, 03 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme
On 14 Jan 2000 16:36:26 -0600, Shriram Krishnamurthi

Quote:


>Use SrPersist -- we'd love more feedback!

        Thanks. I'll download it and start playing with it ASAP. :-)

//-----------------------------------------------
//      Fernando Rodriguez Romero
//
//      frr at mindless dot com
//------------------------------------------------



Wed, 03 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme
On Sat, 15 Jan 2000 09:14:27 -0000, Brendan Fernandes

by knowing that:

Quote:
>> SrPersist currently provides only a thin layer atop ODBC.  We're not
>> happy with this as a programming interface.  We're looking for
>> interested people to help us implement a better programming model that
>> integrates better with the rest of Scheme.  Anyone interested?

>> Use SrPersist -- we'd love more feedback!

>Certainly interested... though I wouldn't consider myself *yet* skilled
>enough at Scheme to be of much use! I have, however, had a brief (but
>successful) attempt at using SrPersist, so here's my two pence:

> - 1. Treating a record set (hstmt) as a port, so lots of code which used to
>use files can switch to using databases with min hassle. (Including "load",
>of course!)
> - 2. "Scheme-ising" the SQL: a statement like (select (fields name age)
>(from people)) would be much easier to manipulate & dissect than the
>corresponding SQL string. Perhaps a thin SQL-generating layer on top would
>suffice. Or, of course, doing away with the whole SQL model (this can be
>done in a still higher layer), which can use the existing class system and
>map fields onto it. My gut feeling though is that ODBC's funny data typing
>and general (but understandable) lack of orthogonality will put paid to any
>hopes of having an idealogically sound system, but a practical system yes.

Flip side of the coin:

I've been doing some design work for GnuCash on a Scheme-based
reporting language.  The basic idea being that there's need to have a
way of producing financial reports.

I've come up with the thought of having a sort of "reporting language"
where the basic abstraction is that a "report" consists of a set of
lines that contain fields.

And so we'd have (oversimplifying somewhat) a report that might look
somewhat like:

(let*
    ((rp (create-report-port output-port 'html 2))
          ;;; Report with 2 columns, sending output to
          ;;; a particular port
     (income-total (create-counter))
     (expense-total (create-counter))
     (grand-total (create-counter)))
  (report-line rp
    (report-string rp "Income" 1 'Title))
  (report-line rp
    (report-string rp "Salary" 1 'Account)
    (report-amount rp 2500.00 2 income-total 'Credit-Amount))
  (report-line rp
    (report-string rp "Interest" 1 'Account)
    (report-amount rp 25.50 2 income-total 'Credit-Amount))
  (report-line rp
   (report-string rp "Total Income" 1 'Subtotal)
   (report-total rp income-total 2 grand-total 'Credit-Subtotal))
  (report-line rp
    (report-string rp "Expenses" 1 'Title))
  (report-line rp
    (report-string rp "Rent" 1 'Account)
    (report-amount rp 900.00 2 expense-total 'Debit-Amount))
  (report-line rp
    (report-string rp "Groceries" 1 'Account)
    (report-amount rp 140 2 expense-total 'Debit-Amount))
  (report-line rp
   (report-string rp "Total Expenses" 1 'Subtotal)
   (report-total rp expense-total 2 grand-total 'Debit-Subtotal))
  (report-line rp
   (report-string rp "Net Income" 1 'Total)
   (report-total rp grand-total 2 #f 'Credit-Total)))
;;; It should be obvious that this is hand coding something that
;;; would normally be produced by writing a program that loops
;;; against some form of database.  
;;; The bit that has been particularly elided is the manner in
;;; which header/footer data would be specified...

This would then dispatch methods for a particular output format:

- In ASCII, you'd want to have a fixed number of lines per page, and
each line ultimately gets rendered as a string.  And you'd want any
headers/footers to get repeated on each page.

- In HTML, this would get expressed as a big table.  And values get
rendered into numbers before pushing them out.  And style indicators
like 'Credit-Amount would establish what CSS style would be associated
with each cell.

- One might generate a spreadsheet output form.  (I have Gnumeric in
mind, which uses an XML-based data format.)  In that case, formulae
should get generated, so that rather than computing the totals,
(report-amount) should collect the names of the cells that get
generated into the total "object," and then (report-total) would
generate a spreadsheet formula referencing the cells.

- Generating{*filter*}would involve having a non-fixed number of lines
per page, but some widow/orphan management.  Probably it would be
necessary to use some table-like environment that allows jumping to
new pages.

The set of basic operators, (report-line), (report-string),
(report-total), (report-amount), (create-report-port), perhaps with
other data types (dates?)  represents a "reporting language," in the
same way that the SrPersist code represents a "database access
language."

The bit that I think is elegant is to attach "styles" to the fields so
that we can, in the same manner as in CSS, significantly modify the
way documents look without having to recode reports.

It would be quite nice to have some people hammer on the ideas for a
while to poke any necessary holes in it.

< http://www.*-*-*.com/ ; describes BRL, the "Beautiful
Reporting Language," which looks like it's *somewhat* similar, except
that it is strongly tied to generating web pages.
--
"[In 'Doctor' mode],  I spent a good ten minutes  telling Emacs what I
thought of it.   (The response was, 'Perhaps you could  try to be less
abusive.')"  -- Matt Welsh



Sat, 06 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme
You may want to read my paper "From Macros to Reusable Generative
Programming", which is available (in tech report format, for those of
you Springer-Verlag sleuths reading this post <-:) at

  http://www.cs.rice.edu/CS/PLT/Publications/#gcse99-kfd

It discusses the idea of data languages in a little detail.  (Much
more on it in my upcoming thesis.)

'shriram



Thu, 11 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:
> It discusses the idea of data languages in a little detail.  (Much
> more on it in my upcoming thesis.)

When's the thesis out? Will it be on the PLT site too?


Fri, 12 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:

> When's the thesis out?

Just as soon as I stop posting here. (-:

Quote:
>                     Will it be on the PLT site too?

Yep.  It'll be done in a few months, but many of the core ideas
(except the most central one!) are already in my papers, which are
available off the PLT publications page.

'shriram



Fri, 12 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:
> Yep.  It'll be done in a few months, but many of the core ideas
> (except the most central one!) are already in my papers, which are
> available off the PLT publications page.

Fantastic! I've been getting through these papers (slowly), and every one a
good read. Can't wait for the thesis now, I'm intrigued....

cheers,
b



Fri, 12 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:
>   http://www.cs.rice.edu/CS/PLT/Publications/#gcse99-kfd

Maybe it's me, but from where the McMicMac package be found? Apparently it
used to be part of Zodiac, but I can't find it.

'Scuse my stupidity if it's in a really obvious place!

cheers,
Brendan



Mon, 15 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:

>        Is there any package equivalent to squile (for guile) for
>mzscheme? I'd like to manage MySQL from scheme scripts. O:-)

I wrote once the glue program for MzScheme, which uses the same scheme interface
to work both with MySQL and Informix. It worked fine with MzScheme 50-3 (I did
not try it with the latest releases of MzScheme), with latest versions of MySQL
and with INFORMIX 6.1-7.23

The interface description may be found on the web at
http://tsichevski.bizland.com/htdocs/rdbms.html

I plan to re-test, collect and upload the distributove too, as time allows. If
somebody is interested, feel free to contact me.

May be the following is out of context, but the ideas of high-level DBMS client
wrapper you may borrow in system named ObjectLens, implemented in Smalltalk
(VisualWorks from ParcPlace).

Regards,
Vladimir V. Tsychevski
expert

______________________________________________________
Jet Infosystems
Krasnoproletarskaya 6,  Tel. (+7 095) 972-1182
Moscow 103006, Russia  Fax  (+7 095) 972-0791
______________________________________________________
Any opinions or recommendations herein are those of the
author and not of his computer.



Thu, 18 Jul 2002 03:00:00 GMT  
 MySQL and mzscheme

Quote:

> >   http://www.cs.rice.edu/CS/PLT/Publications/#gcse99-kfd

> Maybe it's me, but from where the McMicMac package be found? Apparently it
> used to be part of Zodiac, but I can't find it.

It's built into DrScheme.

If you need additional details, please email me privately (I don't
always follow threads on the newsgroup).

'shriram



Thu, 18 Jul 2002 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. MySQL locally vs. MySQL on server

2. MzScheme namespaces question

3. mzscheme and mredit for Mac?

4. MzScheme: trouble with read-line

5. Threads in embedded MzScheme

6. MzScheme and low-level macros.

7. Is Dr Scheme a frontend for MzScheme?

8. mzscheme has a _weird_ bug

9. nonstandard error output from MzScheme running with -r

10. MzScheme commandline arguments error?

11. mzscheme

12. SRFI34 problems in mzscheme

 

 
Powered by phpBB® Forum Software