From: ··············@gmail.com
Subject: What I miss about Ruby
Date: 
Message-ID: <1155554428.733131.284680@m79g2000cwm.googlegroups.com>
The thing I miss most about Ruby is that whatever helper library you
might need to get your real project done, chances are it's already
written. And fairly easy to use.

For example, for my current project there is some data I need which is
scattered over many tables on many pages  at a particular website (each
table representing data for a month and year over a 20-year period).
And just to trip us up, to get to each table you must select the month
and year from two drop-down lists on the main page and click a button,
not simply follow a link. Sounds like a job for a web walker/testing
library, one which supports buttons and selection lists.

In Ruby, the Watir library does exactly what I need in 6 lines of code:

   ie = Watir::IE.new
   ie.goto("http://coolsitewithdata.com/datayouneed.aspx")
   ie.select_list(:name, "year-list").select("2006")
   ie.select_list(:name, "month-list").select("January")
   ie.button(:value, "Button-name").click
   data_array = ie.table(:id, "data-table").to_a

I just need to wrap this in two nested loops to get all the data. The
last line takes the data from a table and stores it in an array of the
correct size and dimensions -- which is cool and all, but it's the
other stuff I really need.

So, I've got 2 choices for my project. 1) Extend an existing Lisp HTML
library[*] with the functionality I need to get at the data; or 2) Use
Ruby to pull the data to use in my Lisp program. Well, if the Lisp
library itself was my project, then choice 2 would be obvious. Since
it's not, and my project can't go forward without the data, I'm going
with choice 1. It is, after all, the practical thing to do, right?

The purist in me rebels. But I'm sure Graham would approve.

[*] BTW, if anyone knows of an existing Lisp library with this kind of
selection-list and button functionality (even without the
table-to-array stuff), I'd love to hear about it.

From: Rob Thorpe
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155563718.434510.218020@m73g2000cwd.googlegroups.com>
··············@gmail.com wrote:
> The thing I miss most about Ruby is that whatever helper library you
> might need to get your real project done, chances are it's already
> written. And fairly easy to use.
>
> For example, for my current project there is some data I need which is
> scattered over many tables on many pages  at a particular website (each
> table representing data for a month and year over a 20-year period).
> And just to trip us up, to get to each table you must select the month
> and year from two drop-down lists on the main page and click a button,
> not simply follow a link. Sounds like a job for a web walker/testing
> library, one which supports buttons and selection lists.
>
> In Ruby, the Watir library does exactly what I need in 6 lines of code:
>
>    ie = Watir::IE.new
>    ie.goto("http://coolsitewithdata.com/datayouneed.aspx")
>    ie.select_list(:name, "year-list").select("2006")
>    ie.select_list(:name, "month-list").select("January")
>    ie.button(:value, "Button-name").click
>    data_array = ie.table(:id, "data-table").to_a
>
> I just need to wrap this in two nested loops to get all the data. The
> last line takes the data from a table and stores it in an array of the
> correct size and dimensions -- which is cool and all, but it's the
> other stuff I really need.
>
> So, I've got 2 choices for my project. 1) Extend an existing Lisp HTML
> library[*] with the functionality I need to get at the data; or 2) Use
> Ruby to pull the data to use in my Lisp program. Well, if the Lisp
> library itself was my project, then choice 2 would be obvious. Since
> it's not, and my project can't go forward without the data, I'm going
> with choice 1. It is, after all, the practical thing to do, right?
>
> The purist in me rebels. But I'm sure Graham would approve.
>
> [*] BTW, if anyone knows of an existing Lisp library with this kind of
> selection-list and button functionality (even without the
> table-to-array stuff), I'd love to hear about it.

I agree with your point.

You could try:-
http://common-lisp.net/project/cl-curl/

But it says it's an alpha release.
From: ··········@gmail.com
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155569552.288487.77730@m79g2000cwm.googlegroups.com>
··············@gmail.com wrote:
> The thing I miss most about Ruby is that whatever helper library you
> might need to get your real project done, chances are it's already
> written. And fairly easy to use.
>
> For example, for my current project there is some data I need which is
> scattered over many tables on many pages  at a particular website (each
> table representing data for a month and year over a 20-year period).
> And just to trip us up, to get to each table you must select the month
> and year from two drop-down lists on the main page and click a button,
> not simply follow a link. Sounds like a job for a web walker/testing
> library, one which supports buttons and selection lists.
>
> In Ruby, the Watir library does exactly what I need in 6 lines of code:
>
>    ie = Watir::IE.new
>    ie.goto("http://coolsitewithdata.com/datayouneed.aspx")
>    ie.select_list(:name, "year-list").select("2006")
>    ie.select_list(:name, "month-list").select("January")
>    ie.button(:value, "Button-name").click
>    data_array = ie.table(:id, "data-table").to_a
>
> I just need to wrap this in two nested loops to get all the data. The
> last line takes the data from a table and stores it in an array of the
> correct size and dimensions -- which is cool and all, but it's the
> other stuff I really need.
>
> So, I've got 2 choices for my project. 1) Extend an existing Lisp HTML
> library[*] with the functionality I need to get at the data; or 2) Use
> Ruby to pull the data to use in my Lisp program. Well, if the Lisp
> library itself was my project, then choice 2 would be obvious. Since
> it's not, and my project can't go forward without the data, I'm going
> with choice 1. It is, after all, the practical thing to do, right?
>
> The purist in me rebels. But I'm sure Graham would approve.
>
> [*] BTW, if anyone knows of an existing Lisp library with this kind of
> selection-list and button functionality (even without the
> table-to-array stuff), I'd love to hear about it.

I have been down this road myself, and I went with a combination of
Ruby and wget.  Use what works or write a really nice library and share
it with us:)
From: Petter Gustad
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <877j1bml05.fsf@gustad.com>
··············@gmail.com writes:

> not simply follow a link. Sounds like a job for a web walker/testing
> library, one which supports buttons and selection lists.

Have you looked at Allegroserve's do-http-request?

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: ············@gmail.com
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155573383.819766.272350@74g2000cwt.googlegroups.com>
Definitely, current Ruby has a richer set of libraries, which I think
the advantage it's over Lisp is single implementation with no dialect.
Lisp is a big family with many dialects and more implementations, If
Lisp has as large as the user base of C, it's fine, but with a smaller
community, it should be more focused. That is, components being built
for a single implementation as Ruby is easier than Lisp, which you need
to test in which implementation it works or not.I would like to say,
it's the root that why Lisp is not popular.
From: Pierre THIERRY
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <pan.2006.08.15.09.25.13.721008@levallois.eu.org>
Le Mon, 14 Aug 2006 09:36:23 -0700, ············@gmail.com a écrit :
> That is, components being built for a single implementation as Ruby is
> easier than Lisp, which you need to test in which implementation it
> works or not.I would like to say, it's the root that why Lisp is not
> popular.

That cannot be. Writing portable code is far more difficult in C or C++,
and in those languages, testing and tuning portability is really a pain
in the ass. Compare to the conditional evaluation and *features*
varaible of Lisp, combined with macros.

Most people won't try or use Lisp because they know it's an
over-parenthesed slow language, it seems.

Comparatively,
Nowhere man
-- 
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
From: Rob Thorpe
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155636172.735395.109570@h48g2000cwc.googlegroups.com>
Pierre THIERRY wrote:
> Le Mon, 14 Aug 2006 09:36:23 -0700, ············@gmail.com a écrit :
> > That is, components being built for a single implementation as Ruby is
> > easier than Lisp, which you need to test in which implementation it
> > works or not.I would like to say, it's the root that why Lisp is not
> > popular.
>
> That cannot be. Writing portable code is far more difficult in C or C++,
> and in those languages, testing and tuning portability is really a pain
> in the ass. Compare to the conditional evaluation and *features*
> varaible of Lisp, combined with macros.

The problem is the writing of modules for interface. In a language like
Ruby, Python or Perl this is much easier than lisp, one simply writes
them in C targetting the language interpreter.  In Lisp generally it's
also necessary to write them in C, but you must target several
different implementations.

Writing other types of modules is fairly simple in Lisp.
From: Frank Buss
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <lv5wsdkhwekq.11pelnscgedtq$.dlg@40tude.net>
Rob Thorpe wrote:

> The problem is the writing of modules for interface. In a language like
> Ruby, Python or Perl this is much easier than lisp, one simply writes
> them in C targetting the language interpreter.  In Lisp generally it's
> also necessary to write them in C, but you must target several
> different implementations.

With CFFI need to write it only once.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Rob Thorpe
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155636836.201669.46380@m79g2000cwm.googlegroups.com>
Frank Buss wrote:
> Rob Thorpe wrote:
>
> > The problem is the writing of modules for interface. In a language like
> > Ruby, Python or Perl this is much easier than lisp, one simply writes
> > them in C targetting the language interpreter.  In Lisp generally it's
> > also necessary to write them in C, but you must target several
> > different implementations.
>
> With CFFI need to write it only once.

Yes. But do you use CFFI or UFFI?
And once you've used one or the other you have to test the code in the
implementations you're targetting.
From: Marko Kocic
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155641301.512169.279070@i42g2000cwa.googlegroups.com>
> > With CFFI need to write it only once.
>
> Yes. But do you use CFFI or UFFI?
> And once you've used one or the other you have to test the code in the
> implementations you're targetting.

Doesn't matter, CFFI has UFFI compatibility layer.
From: Frank Buss
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1xeip2w8448os.64t7dgt09jf4.dlg@40tude.net>
Rob Thorpe wrote:

> Yes. But do you use CFFI or UFFI?

I'm using CFFI, which is some kind of de facto standard if you want to use
C from Common Lisp.

> And once you've used one or the other you have to test the code in the
> implementations you're targetting.

Yes, you have to test it, but if it doesn't work, CFFI needs to be fixed,
not your program :-) And e.g. for http://www.lispbuilder.org all CFFI
wrappings are working unchanged for all tested implementations.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Rob Thorpe
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155650395.611859.299500@75g2000cwc.googlegroups.com>
Frank Buss wrote:
> Rob Thorpe wrote:
>
> > Yes. But do you use CFFI or UFFI?
>
> I'm using CFFI, which is some kind of de facto standard if you want to use
> C from Common Lisp.
>
> > And once you've used one or the other you have to test the code in the
> > implementations you're targetting.
>
> Yes, you have to test it, but if it doesn't work, CFFI needs to be fixed,
> not your program :-)

True.

> And e.g. for http://www.lispbuilder.org all CFFI
> wrappings are working unchanged for all tested implementations.

Very nice, I didn't know about this project.  How finished is it?

This is just a suggestion, but maybe the interface to MSWindows GDI
someone mentioned recently could be incorporated into this collection.
From: Frank Buss
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1mql921yyiq0q.4jtt20ituw7y.dlg@40tude.net>
Rob Thorpe wrote:

>> And e.g. for http://www.lispbuilder.org all CFFI
>> wrappings are working unchanged for all tested implementations.
> 
> Very nice, I didn't know about this project.  How finished is it?

It works on multiple implementations on Linux and Windows. There are
problems on Mac and it needs some refactoring with objects and the new CFFI
finalizer concept, because if you don't use the with-macros, memory leaks
are possible, but there are already some small demo applicaitons.

> This is just a suggestion, but maybe the interface to MSWindows GDI
> someone mentioned recently could be incorporated into this collection.

Do you have a link? I've already started a lispbuilder-windows package (see
"Windows CFFI mapping and examples" on the main page), but it is very
incomplete at the moment, just enough for my platform independant (at least
it is intended in some future to be platform independant :-) GUI Eval
program. Maybe this can be merged.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Rob Thorpe
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155651560.082369.101310@m79g2000cwm.googlegroups.com>
Frank Buss wrote:
> Rob Thorpe wrote:
>
> >> And e.g. for http://www.lispbuilder.org all CFFI
> >> wrappings are working unchanged for all tested implementations.
> >
> > Very nice, I didn't know about this project.  How finished is it?
>
> It works on multiple implementations on Linux and Windows. There are
> problems on Mac and it needs some refactoring with objects and the new CFFI
> finalizer concept, because if you don't use the with-macros, memory leaks
> are possible, but there are already some small demo applicaitons.

Great.

> > This is just a suggestion, but maybe the interface to MSWindows GDI
> > someone mentioned recently could be incorporated into this collection.
>
> Do you have a link? I've already started a lispbuilder-windows package (see
> "Windows CFFI mapping and examples" on the main page), but it is very
> incomplete at the moment, just enough for my platform independant (at least
> it is intended in some future to be platform independant :-) GUI Eval
> program. Maybe this can be merged.

Reini Urban posted it recently, see the post "clisp gdi works again"

http://xarch.tu-graz.ac.at/publ/cygwin/release/clisp/gdi-0.2.tar.bz2

There is also a small MS Windows interface layer in the ECL contrib
directory, it's by Michael Goiffeul I think.

I don't know what licenses these interfaces have and haven't used them.
From: Pierre THIERRY
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <pan.2006.08.15.17.13.31.963248@levallois.eu.org>
Le Tue, 15 Aug 2006 03:02:52 -0700, Rob Thorpe a écrit :
> The problem is the writing of modules for interface. In a language
> like Ruby, Python or Perl this is much easier than lisp, one simply
> writes them in C targetting the language interpreter.

In the past, I've tried to write a very simple extension for PHP. I was
fairly good at writing PHP code and knew well C++ and a bit of C. It
proved to be much more complicated than it seems.

> In Lisp generally it's also necessary to write them in C, but you must
> target several different implementations.

I just looked at Clg (GTK+ bindings): there are 5 very simple C files,
for a total of 12 Kb. It was a matter of 20/30 seconds to skim through
them, and I'm sure there is nothing specific of a Lisp implementation.

The overall package without examples is made of 50 lisp files for a
total of 688 Kb... And it's very Lispish to use (i.e. it's not just a
mapping between C and Lisp functions)

Just to compare something I know a bit about, let's take the C++
binding, which also tries very hard to be a C++ idiomatic use of GTK+.
Although C++ is source compatible with C (you just need an ``extern "C"
{}'' block around C code), it is made of 518 files for a total of 9.8
Mb! And it has an horribly complex makefiles system.

Or the Perl binding, with 1.5 Mb in 182 files of it's home-made binding
language XS... (that is, you don't have to master very well Perl and C,
but XS also!)

So I'm not that convinced that it is more complicated to write interface
libraries in Lisp. On the contrary, I was absolutely delighted when I
discovered how it works, with FFI systems, compared to the way it's done
in other languages... The availibilty of libraries like UFFI or CFFI
makes the situation not far from ideal, from my point of view!

Alternatively,
Nowhere man
-- 
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
From: ··············@gmail.com
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155577839.194177.134440@i3g2000cwc.googlegroups.com>
[one suggestion]
>You could try:-
>http://common-lisp.net/project/cl-curl/

Because of cross-platform compatibility concerns, I need to stick with
CLISP for now, but UFFI support isn't finished yet an cl-curl requires
it.

[another suggestion]
> Have you looked at Allegroserve's do-http-request?

Neither of the above supports interacting with javascript controls,
which is one of the functionalities I need (if I'm wrong about either
package, someone please show how to do it).

Watir is so cool and easy to use that I may just look at converting it
to a lisp package when I'm done with my main project. One drawback is
that it's Windows-only -- it actually opens an IE window and issues
commands to the displayed page, so you can watch your code do it's
thing -- so that right there is a big warning sign with HAZARDOUS
written all over it.
From: Rob Thorpe
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155578949.236168.22210@m79g2000cwm.googlegroups.com>
··············@gmail.com wrote:
> [one suggestion]
> >You could try:-
> >http://common-lisp.net/project/cl-curl/
>
> Because of cross-platform compatibility concerns, I need to stick with
> CLISP for now, but UFFI support isn't finished yet an cl-curl requires
> it.

I see.

> [another suggestion]
> > Have you looked at Allegroserve's do-http-request?
>
> Neither of the above supports interacting with javascript controls,
> which is one of the functionalities I need (if I'm wrong about either
> package, someone please show how to do it).

I think you're right.  Javascript requires a whole browser.
Automating Firefox would be a reasonable way to do this if you had the
time.

> Watir is so cool and easy to use that I may just look at converting it
> to a lisp package when I'm done with my main project. One drawback is
> that it's Windows-only -- it actually opens an IE window and issues
> commands to the displayed page, so you can watch your code do it's
> thing -- so that right there is a big warning sign with HAZARDOUS
> written all over it.

Yep.  Messaging Windows apps is like that, IE may decide it doesn't
like this kind of behaviour in the future and prevent it.

Doing it with Watir is probably the right way now, but it could well
change.
From: ··············@gmail.com
Subject: Automated Web Application UI Testing/Control (was: What I miss about Ruby)
Date: 
Message-ID: <1155581749.085927.218730@i42g2000cwa.googlegroups.com>
Rob Thorpe wrote:
> I think you're right.  Javascript requires a whole browser.
> Automating Firefox would be a reasonable way to do this if you had the
> time.

I had a little free time today and decided to look around for a
possible hook on which to build a possible Lisp library for doing the
kinds of browser control I need for my current project. I came across
Selenium, and more specifically the Selenium Remote-Control:
http://www.openqa.org/selenium-rc/
It's open source, cross-platform, and evidently supports several
languages as client drivers, Lisp not being one of them. But the
documentation claims that writing a new client driver for an
unsupported language is "as easy as pie. All you need to automate tasks
in the browser is to send HTTP commands to the Selenium Server, and to
parse their responses."

Definitely looks doable to me.
From: Bill Atkins
Subject: Re: Automated Web Application UI Testing/Control (was: What I miss about Ruby)
Date: 
Message-ID: <1155583401.779480.225670@b28g2000cwb.googlegroups.com>
··············@gmail.com wrote:
> Rob Thorpe wrote:
> > I think you're right.  Javascript requires a whole browser.
> > Automating Firefox would be a reasonable way to do this if you had the
> > time.
>
> I had a little free time today and decided to look around for a
> possible hook on which to build a possible Lisp library for doing the
> kinds of browser control I need for my current project. I came across
> Selenium, and more specifically the Selenium Remote-Control:
> http://www.openqa.org/selenium-rc/
> It's open source, cross-platform, and evidently supports several
> languages as client drivers, Lisp not being one of them. But the
> documentation claims that writing a new client driver for an
> unsupported language is "as easy as pie. All you need to automate tasks
> in the browser is to send HTTP commands to the Selenium Server, and to
> parse their responses."
> 
> Definitely looks doable to me.

Nice, thanks for this link.
From: Robert Uhl
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <m3ac66boyu.fsf@NOSPAMgmail.com>
··············@gmail.com writes:
>
> Because of cross-platform compatibility concerns, I need to stick with
> CLISP for now, but UFFI support isn't finished yet an cl-curl requires
> it.

That's something which has bitten me as well.  The project I'm
developing at work uses CLSQL, and so CLISP can't work, which is a pity
as in some ways I think it'd be preferable to SBCL for what I'm doing.

I suppose I should just bite the bullet and look at getting CLSQL
working.  But I'm nowhere near that good.

-- 
Robert Uhl <http://public.xdi.org/=ruhl>
Critics say that America is a lie because its reality falls so far short
of its ideals.  They are wrong.  America is not a lie; it is a
disappointment.  But it can be a disappointment only because it is also
a hope.                                             --Samuel Huntington
From: vanekl
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <1155637793.565717.210310@b28g2000cwb.googlegroups.com>
Robert Uhl wrote:
[snip]
>
> That's something which has bitten me as well.  The project I'm
> developing at work uses CLSQL, and so CLISP can't work, which is a pity
> as in some ways I think it'd be preferable to SBCL for what I'm doing.
>
> I suppose I should just bite the bullet and look at getting CLSQL
> working.  But I'm nowhere near that good.

It may not be widely advertised on their web site, but Clisp works with
CLSQL. I use this combo with MySQL on windows-xp/cygwin. Because of my
wacky, non-unixy platform this combination doesn't appear to be popular
so I had to make a few source code adjustments to get it to run, of
which I've posted at http://rubyforge.org/frs/?group_id=835. But I
think CLSQL and Clisp will work out-of-the-box on unix/linux.

Lou
--
President Kennedy used to say, "Life is not fair."
From: Stephen Compall
Subject: Re: What I miss about Ruby
Date: 
Message-ID: <MvdFg.139079$bN2.13338@fe09.news.easynews.com>
··············@gmail.com wrote:
> Because of cross-platform compatibility concerns, I need to stick with
> CLISP for now, but UFFI support isn't finished yet an cl-curl requires
> it.

CFFI (http://common-lisp.net/project/cffi/) offers two
CLISP-compatible alternatives:

1. Use the included UFFI compatibility layer.

2. Follow the tutorial, which revolves around the development of a
simple interface to libcurl functionality.

-- 
Stephen Compall
http://scompall.nocandysw.com/blog