Discussion:
[Axiom-developer] axiom porting
d***@axiom-developer.org
2005-04-28 17:37:54 UTC
Permalink
Lots of discussion and interest on this subject I see...

My current thinking on the matter is that the first priority will
be to just get it working the way it was. This has several dimensions.

The code is now in C/X11, neither of which is very portable. C has
more ifdefs than code and X11 won't work on windows.

The cygwin path could potentially allow a direct port but is not of
interest for other reasons. I've tried cygwin before as the initial
porting platform and it was painful. Plus, having both cygwin and msys
would be a bit much. So this rules out the X11-on-windows version.

Which implies a rewrite to use a different code base and a
different windowing scheme.

With respect to a code rewrite I've decided to rebuild the code in
common lisp for several reasons. First, it is easier to port. Second,
it is a language I know well. Third, it will allow us to "lift" the
windowing functions up into the axiom system proper so other people
can create windows in their code. Fourth, it will allow the unification
of windowing/graphing data structures and spad data structures.

With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality. For example,
http://daly.axiom-developer.org/TimothyDaly_files/pamphlets/jman.pamphlet

The current plan is to have some sort of dumb front-end that implements
some low-level graphics API and move the rest of the code into lisp.
The graphics API needs to cover both the browser and graphics abilities.

As I've mentioned I've tried various paths. Camm, Bill, and I had a
discussion about these during the sprint day. Camm pointed me at the
sources for TK. I've already written a piece of a TK replacement in Java.

TK might work. I'm going to the bookstore today to get educated about
the details. Since both TK and my Java code use sockets it would seem
that we could use a common syntax. Such an approach would make it easy
to shift between the two front ends. I'm not sure how feasible this is.

I've looked at GNUPLOT but their license does not seem to allow me to
modify and distribute. And their code has more ifdefs than C code which
is a sure sign of a porting headache.

I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.

The graphics and browser run in separate threads using sockets to
communicate to the algebra. Due to the run-process issue in GCL the
front end is being done using CLISP but nothing in the code cares
which lisp is used.

I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
it is not ready for production use.

The SVG, VRML, CSG, and Flash enhancements would be nice but are
definitely in the future development categories. There is still a
huge amount of algebra work to be done before any work gets applied
to enhancing the graphics.

Of course, it's all open to discussion.

Tim
C Y
2005-04-28 18:10:01 UTC
Permalink
Post by d***@axiom-developer.org
With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality.
Tim, by working you mean something that communitcates with Axiom?

[snip]
Post by d***@axiom-developer.org
I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.
Well, since I'm the McCLIM advocate I'll see what I can come up with.
(Gulp.) You might ask the McCLIM developer list about specific
problems/issues - they tend to be very helpful.

CY

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
d***@axiom-developer.org
2005-04-28 18:45:14 UTC
Permalink
Post by C Y
Post by d***@axiom-developer.org
With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality.
Tim, by working you mean something that communitcates with Axiom?
Nope. Just something that communicates with lisp as a back end and
some drawing front end.
Post by C Y
Post by d***@axiom-developer.org
I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.
Well, since I'm the McCLIM advocate I'll see what I can come up with.
(Gulp.) You might ask the McCLIM developer list about specific
problems/issues - they tend to be very helpful.
I asked a few questions there but I'm too much of a newbie. My questions
make it look like I'm asking them to write the code (which I'm not).
Once I have a simple working example I can reverse-engineer the rest
of it.

t
Camm Maguire
2005-04-28 22:20:46 UTC
Permalink
Greetings!
Post by d***@axiom-developer.org
Post by C Y
Post by d***@axiom-developer.org
With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality.
Tim, by working you mean something that communitcates with Axiom?
Nope. Just something that communicates with lisp as a back end and
some drawing front end.
Post by C Y
Post by d***@axiom-developer.org
I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.
Well, since I'm the McCLIM advocate I'll see what I can come up with.
(Gulp.) You might ask the McCLIM developer list about specific
problems/issues - they tend to be very helpful.
If anyone pursues this, please let me know of any issues on GCL and
I'll make them go away :-). clx, on which mcclim rests, worked on gcl
out of the box last time I checked, but no one is using it at
present.

Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire
2005-04-28 22:18:03 UTC
Permalink
Hi Tim!
Post by d***@axiom-developer.org
Lots of discussion and interest on this subject I see...
My current thinking on the matter is that the first priority will
be to just get it working the way it was. This has several dimensions.
I think this is great!
Post by d***@axiom-developer.org
The code is now in C/X11, neither of which is very portable. C has
more ifdefs than code and X11 won't work on windows.
The cygwin path could potentially allow a direct port but is not of
interest for other reasons. I've tried cygwin before as the initial
porting platform and it was painful. Plus, having both cygwin and msys
would be a bit much. So this rules out the X11-on-windows version.
Which implies a rewrite to use a different code base and a
different windowing scheme.
But here we're doing something new upfront, no? Would a small initial
stage project of rewriting the xlib calls to MS equivalents in the
hypertex C code give us a little more time to evaluate different lisp
options? After all, this only need be done on one port, Windows.
Post by d***@axiom-developer.org
With respect to a code rewrite I've decided to rebuild the code in
common lisp for several reasons. First, it is easier to port. Second,
it is a language I know well. Third, it will allow us to "lift" the
windowing functions up into the axiom system proper so other people
can create windows in their code. Fourth, it will allow the unification
of windowing/graphing data structures and spad data structures.
This is a terrific goal. Might take some time, but as you say -- we
have thirty years!
Post by d***@axiom-developer.org
With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality. For example,
http://daly.axiom-developer.org/TimothyDaly_files/pamphlets/jman.pamphlet
Are you primarily aiming at the graphics, or the hypertex, or both?
What do you think of Bill Page's idea using a system browser for the
latter, as I assume it could not handle the former?
Post by d***@axiom-developer.org
The current plan is to have some sort of dumb front-end that implements
some low-level graphics API and move the rest of the code into lisp.
The graphics API needs to cover both the browser and graphics abilities.
As I've mentioned I've tried various paths. Camm, Bill, and I had a
discussion about these during the sprint day. Camm pointed me at the
sources for TK. I've already written a piece of a TK replacement in Java.
TK might work. I'm going to the bookstore today to get educated about
the details. Since both TK and my Java code use sockets it would seem
that we could use a common syntax. Such an approach would make it easy
to shift between the two front ends. I'm not sure how feasible this is.
Well, run-process will talk to any external windowing program. The
trick is in abstracting all the options to one lisp api, and this
would appear hopeless. My opinion is that we need to choose one that
will last us at least ten of the next thiry years, and make it work
well.

Let me just briefly bring up the issue of performance, which is likely
of little concern to us. Talking down a pipe to an external program
will never be as fast as making the windowing calls directly from the
image, which is also possible. Unless we're contemplating animation,
I don't think we'll ever see the difference.
Post by d***@axiom-developer.org
I've looked at GNUPLOT but their license does not seem to allow me to
modify and distribute. And their code has more ifdefs than C code which
is a sure sign of a porting headache.
gnuplot is completely free software -- it passes the widely accepted
definitions found in the Debian Free Software Guidelines, and is thus
in Debian's main (not non-free or contrib) archive. You can
distribute any modifications you wish in the form of patches.

As to portability, this is perhaps the most widely portable option at
the present moment. It might not have been an easy job, but someone
else already has done it, and is continuing to do so, which appears to
me highly attractive from axiom's vantage point.
Post by d***@axiom-developer.org
I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.
The graphics and browser run in separate threads using sockets to
communicate to the algebra. Due to the run-process issue in GCL the
front end is being done using CLISP but nothing in the code cares
which lisp is used.
Did you get my fix for this posted yesterday?
Post by d***@axiom-developer.org
I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
it is not ready for production use.
Perhaps, but all the solutions will require work, alas, and what one
gets with gtk is glade. Please take a moment and play with the
program. The entire interface is generated graphically, with no
coding in any language, and dumped as a purely portable xml file.
There is cl-glade which loads this interface into acl. I've
downloaded it, and it can be made to work in GCL, but I'll refrain
from spending time here unless we are sure this is the way we'd like
to go.
Post by d***@axiom-developer.org
The SVG, VRML, CSG, and Flash enhancements would be nice but are
definitely in the future development categories. There is still a
huge amount of algebra work to be done before any work gets applied
to enhancing the graphics.
Agreed!
Post by d***@axiom-developer.org
Of course, it's all open to discussion.
Thank you so much for your work here and everywhere, Tim!

Take care,
Post by d***@axiom-developer.org
Tim
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Mike Thomas
2005-04-28 22:53:40 UTC
Permalink
Hi all.

| > The graphics and browser run in separate threads using sockets to
| > communicate to the algebra. Due to the run-process issue in GCL the
| > front end is being done using CLISP but nothing in the code cares
| > which lisp is used.
| >
|
| Did you get my fix for this posted yesterday?

In case my other email is swamped by the volume on this family of issues,
note also that a fix for Windows is now in GCL CVS HEAD.

| > I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
| > it is not ready for production use.
| >
|
| Perhaps, but all the solutions will require work, alas, and what one
| gets with gtk is glade. Please take a moment and play with the
| program. The entire interface is generated graphically, with no
| coding in any language, and dumped as a purely portable xml file.

That is actually very interesting. Note however that GTK on Windows is not
as stable as it is on Unix.


Cheers

Mike Thomas.
Camm Maguire
2005-04-28 23:12:03 UTC
Permalink
Greetings!
Post by Mike Thomas
Hi all.
| > The graphics and browser run in separate threads using sockets to
| > communicate to the algebra. Due to the run-process issue in GCL the
| > front end is being done using CLISP but nothing in the code cares
| > which lisp is used.
| >
|
| Did you get my fix for this posted yesterday?
In case my other email is swamped by the volume on this family of issues,
note also that a fix for Windows is now in GCL CVS HEAD.
| > I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
| > it is not ready for production use.
| >
|
| Perhaps, but all the solutions will require work, alas, and what one
| gets with gtk is glade. Please take a moment and play with the
| program. The entire interface is generated graphically, with no
| coding in any language, and dumped as a purely portable xml file.
That is actually very interesting. Note however that GTK on Windows is not
as stable as it is on Unix.
OK, but how bad is bad? And how temporary might this be? Anyway to
try a quick glade example on Windows to get a 30min idea of where the
issues are?

Take care,
Post by Mike Thomas
Cheers
Mike Thomas.
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
d***@axiom-developer.org
2005-04-28 23:17:08 UTC
Permalink
I'm a bit overwhelmed by the volume of suggestions.

The browser idea has promise except that I don't see how to handle
the graphics. I also don't see how to "command" a browser
through a socket to do things like open a new tab.

But it does give us the advantage of an already portable front
end. The dynamic content doesn't seem to be much of an issue.
There is an asq command that can compute answers to database queries.
And if Axiom could handle server requests it would be easy to
serve up algebra (might even be a reason to send Bill to China).

I've been clinging to reproducing the prior work as it gives me a
fixed target to achieve. Otherwise it becomes an open-ended design
problem and it will never be finished. Perhaps this is misguided.

I actually have no idea what gtk is despite the fact that my son was
involved in developing it. And I'm not sure what glade is.

I did try to "rewrite the xlib calls to MS equivalents" but the model
for graphics is wildly different. I suppose this is why no one has
taken this path.

I did get the run-process patch you sent but have not yet applied it.
I'm still working on merging the BSD patches which have been hanging-fire
behind the axiom conference work. Hopefully I'll complete that tonight.

Then I need to look at the GUESS domain and see what it will take to
merge that.

THEN I'll look at the G/B (graphics/browser) issue. Since I'm not
actively coding this is a good time to debate the issue.

t
Martin Rubey
2005-04-29 21:18:25 UTC
Permalink
Post by d***@axiom-developer.org
Then I need to look at the GUESS domain and see what it will take to
merge that.
A prerequesite for that is consensus about the (Rational)Interpolation
package. William Sit posted quite a few very good comments (see MathAction) and
I think it would be sensible to consider them. Since these comments concern the
current PolynomialInterpolation packages as well, it might be wise to make this
a priority. I guess that we cannot change the interface of these packages
without upsetting users, once we have some...

Martin
Camm Maguire
2005-04-29 15:15:21 UTC
Permalink
Greetings!
Post by d***@axiom-developer.org
I'm a bit overwhelmed by the volume of suggestions.
The browser idea has promise except that I don't see how to handle
the graphics. I also don't see how to "command" a browser
through a socket to do things like open a new tab.
Just a suggestion here -- use the browser for hyperdoc, and something
else (like gnuplot) for graphics.
Post by d***@axiom-developer.org
But it does give us the advantage of an already portable front
end. The dynamic content doesn't seem to be much of an issue.
There is an asq command that can compute answers to database queries.
And if Axiom could handle server requests it would be easy to
serve up algebra (might even be a reason to send Bill to China).
Remote access should be straightforward if you can get around your
local firewall. Is this useful?
Post by d***@axiom-developer.org
I've been clinging to reproducing the prior work as it gives me a
fixed target to achieve. Otherwise it becomes an open-ended design
problem and it will never be finished. Perhaps this is misguided.
I actually have no idea what gtk is despite the fact that my son was
involved in developing it. And I'm not sure what glade is.
gtk+ it the core C grapics toolkit use by the desktop you are using at
the present moment, virtually every application on it. (You use
redhat/gnome, if memory serves). The comparable alternate is kde
which is analogously built atop the qt library. The Linux world is
roughly evenly divided between the two, by my estimation.

glade is a program whereby you can create any gui without writing a
line of code, but rather by selecting and placing widgets with a mouse
alone. A *massive* productivity saver, IMHO.
Post by d***@axiom-developer.org
I did try to "rewrite the xlib calls to MS equivalents" but the model
for graphics is wildly different. I suppose this is why no one has
taken this path.
I did get the run-process patch you sent but have not yet applied it.
I'm still working on merging the BSD patches which have been hanging-fire
behind the axiom conference work. Hopefully I'll complete that tonight.
Then I need to look at the GUESS domain and see what it will take to
merge that.
THEN I'll look at the G/B (graphics/browser) issue. Since I'm not
actively coding this is a good time to debate the issue.
OK, thanks as always for your work!

Take care,
Post by d***@axiom-developer.org
t
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Mike Thomas
2005-04-29 01:49:16 UTC
Permalink
Hi Camm.

| > That is actually very interesting. Note however that GTK on
| Windows is not
| > as stable as it is on Unix.
| >
|
| OK, but how bad is bad?

Here are some examples.

Apart from the slowness of launching GIMP (by far the slowest to launch on
my system) as the vast quantity of Unix emulation dlls and other GTK
machinery loads, common items such as the file selectors are completely
foreign to Windows users and considerably less usable than their Windows
equivalents. Occasionally one ends up with menus which somehow become
detached from the parent program and which can't be closed and which
simultaneously lock the parent so that the program has to be killed through
the process manager - perhaps fixed now, I am certainly out of date, but
then again, what a hassle to continually update and harmonise stuff I don't
want to know about.


| And how temporary might this be?

Who would know? Probably a long time. The only major GTK applications I'm
aware of on Windows are Glade and the GIMP which means that a large segment
of GTK is presumably largely untested on Windows.

Here is a link:

http://www.gimp.org/~tml/gimp/win32/

Added to this is the issue of potential clashes between various application
builds and the currently installed version of GTK, which is the reason

| Anyway to
| try a quick glade example on Windows to get a 30min idea of where the
| issues are?

Not at the moment as I suspect it will clash with my version of GTK and
GIMP! Perhaps over the weekend. Hopefully you can see roughly where it's
at from the comments above.

Although Glade definitely sounds like a very big plus, it also seems there
is a lot more work involved with GTK than just getting GCL/Tk up on Windows
both for developers and end users.

Cheers

Mike Thomas.
Mike Thomas
2005-04-29 01:57:54 UTC
Permalink
Hi again.

A quick postscript:

| Anyway to
| try a quick glade example on Windows to get a 30min idea of where the
| issues are?

Couldn't help myself - installed Glade and sure enough there was a GTK
version clash (missing entry points in the relevant DLLs), so this will have
to wait I'm sorry.

Cheers

Mike Thomas.
C Y
2005-04-29 03:08:06 UTC
Permalink
--- Mike Thomas <***@brisbane.paradigmgeo.com> wrote:

[snip]
Post by Mike Thomas
common items such as the file selectors are completely
foreign to Windows users and considerably less usable than their
Windows equivalents.
Amen. KDE users on Linux have been making fun of GTK's file selection
for a very long time - it's improving in the most recent versions but I
still find it a tad iffy at times.
Post by Mike Thomas
The only major GTK applications I'm aware of on Windows are Glade
and the GIMP which means that a large segment of GTK is presumably
largely untested on Windows.
This is my sense too - I know a few other GTK applications have been
ported but I do not have the sense it is a major movement. Hence my
excitement at GPL QT4, which up until version 4 was commercial ONLY on
Windows - indicating it must work reasonably well. With any luck an
McCLIM backend to that could be made to work well and reliably on both
platforms.

CY



__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
Mike Thomas
2005-04-29 04:00:02 UTC
Permalink
Actually, I just gave in to temptation again and installed the latest
Windows GDK; Glade is a bit of a mess. Background windows pop up when the
mouse moves in other windows, menus are left hanging etc. My suspicion is
that this is caused by trying to map the GTK signal structure onto the
Windows event loop system.

| Amen. KDE users on Linux have been making fun of GTK's file selection
| for a very long time - it's improving in the most recent versions but I
| still find it a tad iffy at times.

Even on Linux running on a really fast box X always feels slow to me after
Windows.

| > The only major GTK applications I'm aware of on Windows are Glade
| > and the GIMP which means that a large segment of GTK is presumably
| > largely untested on Windows.
|
| This is my sense too - I know a few other GTK applications have been
| ported but I do not have the sense it is a major movement. Hence my
| excitement at GPL QT4, which up until version 4 was commercial ONLY on
| Windows - indicating it must work reasonably well. With any luck an
| McCLIM backend to that could be made to work well and reliably on both
| platforms.

If someone was planning (I'm certainly not) to write a cross platform
backend to McClim I personally would be telling them to use WxWidgets, which
has been connected up very nicely in both the Scheme and Haskell worlds and
is much lighter weight than GTK while retaining good cros-platform
performance and appearance.

Cheers

Mike Thomas.
Camm Maguire
2005-04-29 14:52:50 UTC
Permalink
Greetings!
Post by Mike Thomas
Actually, I just gave in to temptation again and installed the latest
Windows GDK; Glade is a bit of a mess. Background windows pop up when the
mouse moves in other windows, menus are left hanging etc. My suspicion is
that this is caused by trying to map the GTK signal structure onto the
Windows event loop system.
OK, so glade on windows is only part there, I take it. What is really
central is whether libglade can open up a glade-output xml interface
on windows, which might be somewhat less onerous.

Did a little searching for the opinions of others. Thought this ruby
user's summary was perhaps most relevant for us:

http://www.wonko.com/content.php?id=301

wxwidgets has the native 'look and feel', but glade is 'By far the
easiest to use'... To me, we are far from being able to design high
quality gui's, let alone contribute to the cross-platform gui
development model. All we can hope for is passable, serviceable, and
cross-platform, I'd think. With these resources, ease of use appears
paramount.

There is also wxglade, but this appears in its infancy, and it is
unclear if there is xml/libglade support:

http://wxglade.sourceforge.net/

Needess to say, if it proves to be as functional as glade, this is
definitely the way to go, at least in the long term. Don't have time
to investigate right now, alas.
Post by Mike Thomas
| Amen. KDE users on Linux have been making fun of GTK's file selection
| for a very long time - it's improving in the most recent versions but I
| still find it a tad iffy at times.
Even on Linux running on a really fast box X always feels slow to me after
Windows.
Fair enough, but in the absense of some well-polished, very easy to
use, open source, massively exercised, cross-platform alternative,
this would appear the least of our concerns at this juncture.

Whatever we choose will be less than desirable -- what we need is to
select wisely given a carefully chosen set of priorities.
Post by Mike Thomas
| > The only major GTK applications I'm aware of on Windows are Glade
| > and the GIMP which means that a large segment of GTK is presumably
| > largely untested on Windows.
|
| This is my sense too - I know a few other GTK applications have been
| ported but I do not have the sense it is a major movement. Hence my
| excitement at GPL QT4, which up until version 4 was commercial ONLY on
| Windows - indicating it must work reasonably well. With any luck an
| McCLIM backend to that could be made to work well and reliably on both
| platforms.
If someone was planning (I'm certainly not) to write a cross platform
backend to McClim I personally would be telling them to use WxWidgets, which
has been connected up very nicely in both the Scheme and Haskell worlds and
is much lighter weight than GTK while retaining good cros-platform
performance and appearance.
The scheme hooks you mention argue strongly in wxwidgets' favor, of
course.

Here are my summary opinions at this point -- feedback most
appreciated! (Just a note of clarification -- tcl/tk, which exists in
GCL now and is a portable scripting language, is *not the same* as
GTK+, an extremely widely used C library with multi-language bindings
running 'in-process')

=============================================================================
Goal: generic GCL gui -- short term
=============================================================================

1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
working on all platforms as quickly as possible (Need feedback from
Mike and/or Bill)

2) make sure gcl-tk can display bitmaps (I'll take care of this)

=============================================================================
Goal: generic GCL gui -- long term
=============================================================================

Choose an in-process gui option according to the following ranked
priorities:

1) open source

2) massively exercised in the open source world, which for all
intents and purposes means the core C libraries used by the
open source desktops with a thin lisp binding option

3) universally portable

4) easy to use, preferrably with a graphical gui builder.

5) native 'look and feel'

6) supports the option of a higher level lisp layer like
mcclim. This to my understanding can just be layered on
top of a thin lisp binding layer.

7) lgpl better than gpl. Just to be clear here, if qt4 is
selected, all apps using this will be GPL when distributed
in binary form -- Mike Thomas has voiced reservations about
this in the past, but it doesn't particularly bother me.

We should not do any work on this, IMHO, unless we have a
confirmed user of such a system. As I state below, axiom and the
other systems currently using gcl might be more easily serviced in
other ways.

My feeling is that depending on wxglade functionality, this would
result in wxwidgets > gtk+ > qt4

=============================================================================

Goal: portable axiom hypertex

=============================================================================

This would appear best served by Bill Page's browser idea with GCL
server sockets. For now, I will work on providing
fork()/CreateProcess() options, and select/stdio multiplexing options,
to the si::socket function call. We will postpone threads unless
someone wants to volunteer some work here. The windows fork() analog
of CreateProcess() will require some work in this context, as
basically the code will have to save the server function in a .lsp or
.o file, and restart gcl or axiom with a command line instruction to
load and execute the file (or do same with pipes). I suggest we don't
bother working on this again unless we have a confirmed user -- axiom
might be serviced by the user invocation and/or stdio multiplexing
options. But fork() is a great option to have on Linux, so we should
put it in, IMHO.

=============================================================================

Goal: portable axiom graphics

=============================================================================

This is unlikely to be well serviced by a web browser, and only
modestly well-serviced by a standard gui, as axiom's demands on plot
manipulation are likely to require such detail as canned 'widgets' are
unlikely to be available. I really feel gnuplot is the best tool here
in the medium term, which can be fully accessed cross-platform under
GCL at the present time via run-process. Please check out the maxima
webpages for soem very pretty pictures (aka dazzling eye candy :-))!

=============================================================================

These are just my thoughts, of course. Feedback always most welcome!

Take care,
Post by Mike Thomas
Cheers
Mike Thomas.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire
2005-05-01 05:09:39 UTC
Permalink
Greetings! I've created the 2.6.7pre branch. Everything is basically
there minus a few gcl-tk demos fixes and possibly a stdin read
multiplexer option (using select) for server sockets. Please test.

I've added a :daemon keyword to the si::socket function which
backgrounds a process to handle incoming connections via the specified
function automatically. If :daemon is set to :persistent, then the
backgrounded process will survive when the parent exists. This appears
to work in my preliminary testing. It should be #ifdef'ed so as not
to interfere with windows, as I imagine it will take some considerable
work to achieve the same there. Mike it would be nice to get your
opinions on how some windows compatibility code might be put together
at some point. For now, the option should simply be ignored on non
BSD based systems. It would of coure also be nice if someone could
kindly give a quick sanity check on windows to make sure the build
hasn't been accidentally ruined :-).

Here is the changelog thus far vis a vis 2.6.6:

gcl (2.6.6-2) unstable; urgency=low

* Fix (listen) with readline on
* fix control-d with readline
* libreadline5 support for Debian
* Support for pre-compiled regexps and new texinfo format
* Reenable run-process
* Push function 'accept into lisp, use select for 'listen on socket
streams
* New Upstream release version
* Native-reloc feature
* Add daemon capabilities to server sockets, document socket and
accept

-- Camm Maguire <***@enhanced.com> Sun, 1 May 2005 04:12:16 +0000

Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire
2005-04-30 21:55:08 UTC
Permalink
Greetings!
Post by Camm Maguire
...
Here are my summary opinions at this point -- feedback most
appreciated! (Just a note of clarification -- tcl/tk, which exists in
GCL now and is a portable scripting language, is *not the same* as
GTK+, an extremely widely used C library with multi-language bindings
running 'in-process')
=========================================================================
Goal: generic GCL gui -- short term
=========================================================================
1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
working on all platforms as quickly as possible (Need feedback from
Mike and/or Bill)
For axiom's purposes on Windows I am not fond of this idea until and
unless we already had a gcl-tk frontend for Axiom working under Linux.
So I wouldn't push the "all platforms" requirement until we see how far
this can go on a platform where this would (in principle) be easier (Linux).
But as I said before, perhaps there are good reasons to pursue this
in GCL other than Axiom.
Am happy to report that the top page of the hyperdoc browser can
already be implemented within axiom as currently distributed (at least
on Linux) using gcl-tk!

Just edit the 'gcl and 'gif variables at the top of the following to
point to your built or installed gcl directory and to the path of the
distributed axiom gif logo respectively, save it to e.g. "foo.lisp"
and within axiom do ')lisp (load "foo.lisp")':

=============================================================================
(in-package 'tk)
(let ((gcl "/usr/lib/gcl-2.6.6/")
(gif "/usr/lib/axiom-20050201/doc/axiom_tutorialu/images/axiom_logo.gif"))
(reset-sys-paths gcl)
(tkconnect)
(unless (fboundp '|image create photo|)
(def-widget |image create photo|))
(defun ahtll ( gif &optional (w '.ahtll))
(if (winfo :exists w :return 'boolean)
(destroy w))
(if (winfo :exists w :return 'boolean) (destroy w))
(toplevel w)
(wm :title w "AXIOM HyperDoc")
(wm :iconname w "HyperDoc")
(let ((f1 (conc w '.frame1))
(f2 (conc w '.frame2))
(f3 (conc w '.frame3)))

(frame f1 :relief "raised" :bd 2)
(frame f2 :relief "raised" :bd 2)
(frame f3 :relief "raised" :bd 2)

(let ((b1 (conc f1 '.exit))
(b2 (conc f1 '.help))
(m1 (conc f1 '.msg))
(b3 (conc f1 '.blank1))
(b4 (conc f1 '.blank2)))

(button b1 :text "Exit" :command (tk-conc "destroy " w))
(button b2 :text "Help")
(button b3 :text "")
(button b4 :text "")
(message m1 :font :Adobe-Times-Medium-R-Normal--*-180-* :width "13c" :bd 2 :relief "flat"
:text "AXIOM HyperDoc TopLevel" :justify "center")

(pack b1 :side "left" :pady 5)
(pack b2 :side "left" :pady 5)
(pack m1 :side "left" :pady 5 :fill "x" :expand "yes")
(pack b3 :side "right" :pady 5)
(pack b4 :side "right" :pady 5)

(pack f1 :side "top" :fill "both" :expand "yes"))

(let ((c (conc f2 '.c)))

(canvas c :scrollregion "0c 0c 30c 24c" :width "15c" :height "10c"
:relief "flat" :borderwidth 2)
(let ((l (conc c '.logo))
(i (conc c '.img)))
(|image create photo| i :format "gif"
:file gif)
(label l :image i :relief "flat" :borderwidth 2)
(pack l :side "top" :anchor "center"))
(pack c :side "top" :anchor "center")
(pack f2 :side "top" :fill "both" :expand "yes"))
(let ((m (conc f3 '.msg)))
(message m :text "What do you want to do?" :width "13c" :bd 2 :justify "left")
(pack m :side "top" :anchor "w"))
(let ((f4 (conc f3 '.frame4)))
(frame f4 :relief "flat" :bd 2)
(let ((l '(|Basic Commands| |Reference| |Topics| |Browse|
|Examples| |Settings| |NAG Link| |About AXIOM| |What's New|))
(i 0))
(dolist (s l)
(let ((f (conc f4 (intern (format nil ".f~a" i)))))
(let ((b (conc f (intern (format nil ".b~a" i))))
(m (conc f (intern (format nil ".m~a" i)))))
(frame f :relief "flat" :bd 2)
(button b :command s)
(message m :text (string s) :width "13c" :bd 2 :justify "left")
(pack b :side "left")
(pack m :side "left")
(pack f :side "top" :fill "both" :expand "yes")))
(incf i)))
(pack f4 :side "left" :fill "both" :expand "yes"))
(let ((f5 (conc f3 '.frame5)))
(frame f5 :relief "raised" :bd 2)
(let ((l '("Solve problems by filling in templates."
"Scan on-line documentation for AXIOM."
"Learn how to use AXIOM, by topic."
"Browse through the AXIOM library."
"See examples of use of the libarry."
"Display and change the system environment."
"Link to NAG Numerical Library."
"See some basic information about AXIOM."
"Enhancements in this version of AXIOM."))
(i 0))
(dolist (s l)
(let ((m (conc f5 (intern (format nil "m~a" i)))))
(message m :text s :width "13c" :bd 2 :justify "left")
(pack m :side "top" :fill "y" :anchor "w" :expand "yes")
(incf i))))
(pack f5 :side "left" :fill "both" :expand "yes"))
(pack f3 :side "top" :fill "both" :expand "yes")
))
(ahtll gif))
=============================================================================

The only functional button is the exit button, for the purposes of
demonstration. Other buttons are connected to symbols naming
functions yet to be written to generate subpages.

The interface is quite powerful in its closeness to lisp, IMHO, which
I think should be attractive to Tim. Plus, the multiprocessing issues
have already been worked out, at least on Linux, via signalling with
SIGUSR1. More on this later, but this effectively means that one can
direct the process from the GUI and the command line simultaneously.
Plus, Dr. Schelter put together some great documentation which is
found in the gcl distribution under the name gcl-tk.{texi,info}.

Of course, some 'wish', e.g. some tcl and some tk, need to be
installed to do this. On Debian, just 'apt-get -q install tk8.4'.

More examples can be seen by firing up a built or installed gcl, doing
(tk::tkconnect), and loading the "...gcl-tk/demos/widget.lisp" file.
There are a few typos in the examples which I am cleaning up now.
Also, there is an older occasional difficulty in which a 'write
timeout' occurs between the gcl and gcltksrv process. This is simply
due to the buffer settings in sheader.h being fractional page sizes in
some cases, which I've also fixed here locally and will push into
2.6.7. Perhaps someone might dig up the old post to gcl-devel on this
issue and tell the submitter that the problem is apparently solved.

Mike, my guess now is that gcl-tk bombs on windows because of
sigusr1. I agree with your earlier statement that signals are a
mistake for portability to windows. However, I've just recently
recognized how much existing gcl functionality already exists using
signals. I agree that we should not build anything new in this
regard, at least without some clear portability breakthrough, but I'm
wondering if we can find a passable solution to get this stuff working
on Windows. sgc uses sigsegv processing, profil uses sigprof
processing, gcl-tk uses sigusr1 processing, and sockets can optionally
use sigio processing. You have previously written about gtk+ mapping
its signal mechanism onto windows' 'event loop' processing. I take it
that this is less than elegant, and gtk+ might have done same buggily,
but would this be a possibility for gcl on mingw, at least for these
four signals? It would be a real coup, IMHO, if we could discover a
serviceable way of doing this.

More later.

Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2005-04-29 19:22:14 UTC
Permalink
Post by Camm Maguire
...
Here are my summary opinions at this point -- feedback most
appreciated! (Just a note of clarification -- tcl/tk, which exists in
GCL now and is a portable scripting language, is *not the same* as
GTK+, an extremely widely used C library with multi-language bindings
running 'in-process')
=========================================================================
Goal: generic GCL gui -- short term
=========================================================================
1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
working on all platforms as quickly as possible (Need feedback from
Mike and/or Bill)
For axiom's purposes on Windows I am not fond of this idea until and
unless we already had a gcl-tk frontend for Axiom working under Linux.
So I wouldn't push the "all platforms" requirement until we see how far
this can go on a platform where this would (in principle) be easier (Linux).

But as I said before, perhaps there are good reasons to pursue this
in GCL other than Axiom.
Post by Camm Maguire
========================================================================
Goal: portable axiom hypertex
========================================================================
This would appear best served by Bill Page's browser idea with GCL
server sockets. For now, I will work on providing
fork()/CreateProcess() options, and select/stdio multiplexing options,
to the si::socket function call. ...
I would like to understand how this "stdio multiplexing" thing will
work. Will it allow Axiom to simultaneously answer both command
line input and input/output via HTTP in a manner similar to Axiom's
current HyperTex browser?

Or do we only have to modify the read-process-output loop in
Axiom so that it accepts HTTP input instead of Axiom's native
HyperTex session input?

Of course besides the HyperTex documentation, tutorial and Axiom
library navigation, there is still the issue of mathematical notation
support
in the browser. NAG also did a lot of work on OpenMath which in
principle could be salvaged to provide math output in MathML
format which is now becoming quite mature in the newer browsers.
Techexplorer provided inline LaTeX rendering in the browser and
that would be hard to duplicate on the desktop without adding
much more overhead with things like LaTeX and dvipng (the way
we work now on the MathAction server).
Post by Camm Maguire
=============================================================================
Goal: portable axiom graphics
=============================================================================
This is unlikely to be well serviced by a web browser, and only
modestly well-serviced by a standard gui, as axiom's demands on plot
manipulation are likely to require such detail as canned 'widgets' are
unlikely to be available.
As I currently understand in theory Axiom graphics can be served using
NAG's OpenInventor extensions of to the Axiom graphics program together
with either OpenInventor itself (now open source) or a compatible VRML
plug-in for a standard browser.
Post by Camm Maguire
I really feel gnuplot is the best tool here
in the medium term, which can be fully accessed cross-platform under
GCL at the present time via run-process. Please check out the maxima
webpages for soem very pretty pictures (aka dazzling eye candy :-))!
I have nothing against gnuplot per se, and I think it would be great
to have it as an add-on to Axiom (as is currently done in Maxima
and Reduce).. But I do not think that it in any way replaces Axiom's
native graphics capabilities - especially when it comes to 3-d graphics.

Regards,
Bill Page.
Camm Maguire
2005-05-02 15:36:58 UTC
Permalink
Greetings!
Post by Camm Maguire
...
Here are my summary opinions at this point -- feedback most
appreciated! (Just a note of clarification -- tcl/tk, which exists in
GCL now and is a portable scripting language, is *not the same* as
GTK+, an extremely widely used C library with multi-language bindings
running 'in-process')
=========================================================================
Goal: generic GCL gui -- short term
=========================================================================
1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
working on all platforms as quickly as possible (Need feedback from
Mike and/or Bill)
For axiom's purposes on Windows I am not fond of this idea until and
unless we already had a gcl-tk frontend for Axiom working under Linux.
So I wouldn't push the "all platforms" requirement until we see how far
this can go on a platform where this would (in principle) be easier (Linux).
But as I said before, perhaps there are good reasons to pursue this
in GCL other than Axiom.
The gcl-tk stuff I posted earlier is at least an option which works
with axiom as currently distributed on Linux. My feeling is that it
is likely also a low hanging fruit on Windows. In the longer term,
one might supplement or replace with lisp functions outputting html to
a browser over a server socket. This will be supported without
patches in 2.6.7. Anyone can experiment with cvs branch
Version_2_6_7pre should they desire.
Post by Camm Maguire
========================================================================
Goal: portable axiom hypertex
========================================================================
This would appear best served by Bill Page's browser idea with GCL
server sockets. For now, I will work on providing
fork()/CreateProcess() options, and select/stdio multiplexing options,
to the si::socket function call. ...
I would like to understand how this "stdio multiplexing" thing will
work. Will it allow Axiom to simultaneously answer both command
line input and input/output via HTTP in a manner similar to Axiom's
current HyperTex browser?
My thought was to provide a system variable naming a list of socket
streams to watch, and have the GCL call to read on stdin be preceded
by a call to select, effectively having GCL process stdin and any
socket connections one at a time in the order in which data presents
itself thereon. This serialization might bog things down if big jobs
are running on a given socket. I was not planning any transparent
interrupt facility, though this could also work, as is apparently the
mechanism in gcl-tk.

In cvs branch Version_2_6_7pre, I've already implemented the other
option of having GCL fork a background process to serve a socket,
effectively letting the OS do the multitasking. This will need a bit
more magic on windows. The final option of having the user call the
socket serving function should be available on all platforms now.
Or do we only have to modify the read-process-output loop in
Axiom so that it accepts HTTP input instead of Axiom's native
HyperTex session input?
I was thinking more low level than this, though axiom would have to
instruct gcl to multiplex any given socket, by pushing the stream to
a special list. The currently implemented fork option will be cleaner
if we can get similar working on Windows.
Of course besides the HyperTex documentation, tutorial and Axiom
library navigation, there is still the issue of mathematical notation
support
in the browser. NAG also did a lot of work on OpenMath which in
principle could be salvaged to provide math output in MathML
format which is now becoming quite mature in the newer browsers.
Techexplorer provided inline LaTeX rendering in the browser and
that would be hard to duplicate on the desktop without adding
much more overhead with things like LaTeX and dvipng (the way
we work now on the MathAction server).
We could also either inline some of the source from these projects for
these purposes into GCL (quite easy with compiler::link), or fork two
sockets to keep latex and/or dvipng processes running and waiting for
incremental input for performance reasons using run-process.
Post by Camm Maguire
=============================================================================
Goal: portable axiom graphics
=============================================================================
This is unlikely to be well serviced by a web browser, and only
modestly well-serviced by a standard gui, as axiom's demands on plot
manipulation are likely to require such detail as canned 'widgets' are
unlikely to be available.
As I currently understand in theory Axiom graphics can be served using
NAG's OpenInventor extensions of to the Axiom graphics program together
with either OpenInventor itself (now open source) or a compatible VRML
plug-in for a standard browser.
Sounds like another forked process. The complication here will be
working out the interprocess communication. client/server in either
direction is not a problem, but current gcl-tk style gui/terminal
process sharing will take some work.
Post by Camm Maguire
I really feel gnuplot is the best tool here
in the medium term, which can be fully accessed cross-platform under
GCL at the present time via run-process. Please check out the maxima
webpages for soem very pretty pictures (aka dazzling eye candy :-))!
I have nothing against gnuplot per se, and I think it would be great
to have it as an add-on to Axiom (as is currently done in Maxima
and Reduce).. But I do not think that it in any way replaces Axiom's
native graphics capabilities - especially when it comes to 3-d graphics.
Perhaps not for interactive rotations and the like, but gnuplot's
static 3d capabilities are impressive, at least to me. And those new
coloring extensions in version 4 and greater as illustrated on the
maxima page are outstanding in my opinion.

Take care,
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
d***@axiom-developer.org
2005-05-01 16:53:20 UTC
Permalink
Camm, Bill,

Great job. I've bought the book "Practical Programming in Tcl and TK"
and am about 1/2 way thru it. It appears that Tcl is similar to lisp
in that every line starts with a command and returns a value. It also
appears that it is possible to link C code to Tcl/TK which might be
a short term path to getting the graphics working. Tcl/TK also has a
browser plugin so it might be possible to meet Bill's goal of getting
the whole pile integrated in a browser.

In light of your work and my reading I'm stepping away from the Java
development path for the moment and restarting the TK path.

I need to also recover the windows build procedure and try to get
that working so I can bring windows up to date. Since this work is
supposed to be cross-platform it might help if I actually used both
platforms. I see the purchase of a windows box in my future.

I'm still in the midst of the freebsd merge and the month-end push to
publish so about all I'm doing is reading during compiles. The freebsd
working version will probably have to wait until gcl-2.6.7 because the
magic-loading code does not seem to be useful under 2.6.6 but it's
close. I plan to set up freebsd on one of my local machines.

t
C Y
2005-04-29 16:20:21 UTC
Permalink
Post by Camm Maguire
Post by Mike Thomas
If someone was planning (I'm certainly not) to write a cross
platform backend to McClim I personally would be telling them
to use WxWidgets, which has been connected up very nicely in both
the Scheme and Haskell worlds and is much lighter weight than GTK
while retaining good cros-platform performance and appearance.
The scheme hooks you mention argue strongly in wxwidgets' favor, of
course.
Would scheme bindings to wxWidgets translate well to lisp?
Post by Camm Maguire
===============================================================
Goal: generic GCL gui -- short term
===============================================================
1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
working on all platforms as quickly as possible (Need feedback
from Mike and/or Bill)
Agreed.
Post by Camm Maguire
2) make sure gcl-tk can display bitmaps (I'll take care of this)
Cool :-).
Post by Camm Maguire
===============================================================
Goal: generic GCL gui -- long term
===============================================================
Choose an in-process gui option according to the following ranked
1) open source
Agreed.
Post by Camm Maguire
2) massively exercised in the open source world, which for
all intents and purposes means the core C libraries used
by the open source desktops with a thin lisp binding
option
Well, QT is actually C++, but if you mean GTK and QT are
the two most attractive "back end" toolkits I agree.
Post by Camm Maguire
3) universally portable
There are two ways this can work:
a) Back end toolkit is ported to all platforms.
b) Interface logic written in Lisp toolkit which has working
bindings to different toolkits on different platforms.
Post by Camm Maguire
4) easy to use, preferrably with a graphical gui builder.
For GTK there is glade, for QT there is QT Designer. AFAIK
both are quite good.

Interestingly, Craig Lanning mentioned yesterday on the McCLIM
list that he had written a CLIM interface builder some years
ago. If it still works and he is willing to contribute it that
might help make McCLIM more attractive on the lisp level. Garnet
did have a UI builder but IIRC it had bugs and I never really
got the hang of it.
Post by Camm Maguire
5) native 'look and feel'
This is a major drawback for GTK on Windows.
Post by Camm Maguire
6) supports the option of a higher level lisp layer like
mcclim. This to my understanding can just be layered on
top of a thin lisp binding layer.
That's the theory I guess, although current McCLIM and Garnet bindings
seem to be below toolkit level if I understand correctly. (clx, and
the experimental MacOSX Beagle backend for McCLIM).
Post by Camm Maguire
7) lgpl better than gpl. Just to be clear here, if qt4 is
selected, all apps using this will be GPL when distributed
in binary form -- Mike Thomas has voiced reservations
about this in the past, but it doesn't particularly bother
me.
Mike? Would that matter? If the source code to Axiom+Interface itself
is more liberal, does the binary version being GPL when using QT matter
particularly?
Post by Camm Maguire
We should not do any work on this, IMHO, unless we have a
confirmed user of such a system. As I state below, axiom and the
other systems currently using gcl might be more easily serviced
in other ways.
Uh - you mean we should wait until someone develops a working GUI to
build on?
Post by Camm Maguire
My feeling is that depending on wxglade functionality, this would
result in wxwidgets > gtk+ > qt4
I guess I would disagree - my take on it would be (McCLIM+qt4) >
(McCLIM+wxwidgets) > (McCLIM+gtk+) > qt4 > wxwidgets > gtk+, based on
the following assumptions:

QT4 is more likely to be robust on Windows than either wxWidgets or
gtk, since one of trolltech's major revenue focuses is to sell
commercial licenses to Windows developers - they will be able to bring
more resources to the problem. On Linux this wouldn't tend to worry me
as much, but in the case of Windows I'm more inclined to trust QT to be
robust, and behave as Windows users expect in the look and feel
department. (That's just my personal opinion, not experience, and as
such deserves little weight.) QT works on Windows, Linux, and Mac.

wxWidgets is itself a layer on top of other toolkits, at least on
Linux. I'm not sure what it does on Windows, although presumably it
uses the "standard" Microsoft APIs. I almost view wxWidgets as a C++
McCLIM from the standpoint of how it relates to other GUI libraries.
My take on it is that bugs would be easier to track going from McCLIM
to QT or Gtk+ directly than McCLIM->wxWidgets->Gtk+ on Linux, although
that might not be true in practice.

gtk+ won't have a native look and feel on Windows, and I'm not sure
about its status on the Mac (anybody know?) There are stability and
robustness concerns on Windows.

Overall, (McCLIM+anything) or (Garnet+anything) is better than not
writing the UI in Lisp, IMO. Having all user interface code in one of
these toolkits allows flexibility in toolkit choice, based on what
backends are available or are created in the future. If available, one
could bypass the extra toolkit and do McCLIM+Win32GPI, or
McCLIM+Beagle, and get a totally native behavior without requiring QT.
QT would essentially be written as a backend to be used until all
platforms of interest have solid McCLIM backends. (On linux, of
course, in KDE you would want McCLIM+QT to fit with the desktop, and
McCLIM+Gtk for Gnome.)

But as always, proof is in the pudding. I'll try playing around with
McCLIM when I get the chance and see if I can recreate the axiom
hypertex start page (I got it to run last night, and I had forgotten
how basic it is. I'm going to be embarassed if I can't figure this out
eventually :-)

CY

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
d***@axiom-developer.org
2005-05-01 22:10:21 UTC
Permalink
*,

We're developing Axiom, a large, general purpose computer algebra
system similar in power to Mathematica and Maple.

Axiom consists of 3 pieces, the algebra, the browser, and the graphics.
The algebra is written on top of common lisp.

The graphics and browser (G/B) are written in C using X11.

The algebra portion of Axiom runs under Windows.
The G/B portion does not.

We have been discussing porting strategies and one of the possible
strategies is to use McClim.

Does McClim run on Windows under any common lisp?

Tim Daly
Axiom lead developer
***@axiom-developer.org
d***@axiom-developer.org
2005-05-01 22:32:36 UTC
Permalink
Ken, Jeffrey,

We're developing Axiom, a large, general purpose computer algebra
system similar in power to Mathematica and Maple.

Axiom consists of 3 pieces, the algebra, the browser, and the graphics.
The algebra is written on top of common lisp.

The graphics and browser (G/B) are written in C using X11.

The algebra portion of Axiom runs under Windows.
The G/B portion does not.

We have been discussing porting strategies and one of the possible
strategies is to use McClim.

I've seen the site http://openmap.bbn.com/~kanderso/lisp/scigraph
as well as some screenshots of the scigraph application. Is this
code free and open source? If so, where can I get this code? I'd
like to use it as a basis for experimenting.

The McClim site (http://mcclim.cliki.net/Examples) seems to think
scigraph will run on McClim. Do you know if this is still true?

Tim Daly
Axiom lead developer
***@axiom-developer.org
d***@axiom-developer.org
2005-05-01 22:45:57 UTC
Permalink
*,

Ok, somebody must be listen....

check out the article on slashdot. "Firefox 1.1 Plans Native SVG Support".
don't all look at once, though, as i don't want to slashdot the slashdot
site :-)

SVG built into the browser would be a win. It would be portable, it
would interact with our browser pages coded in html, it would allow
opening a separate browser window with control (maybe).

t
Bill Page
2005-05-02 00:15:18 UTC
Permalink
Post by d***@axiom-developer.org
SVG built into the browser would be a win. It would be portable, it
would interact with our browser pages coded in html, it would allow
opening a separate browser window with control (maybe).
Yes, I agree that SVG would be a neat addition to Axiom HyperTex and also
to MathAction. There are some very good plug-ins available that work in most
browsers and now both FireFox and Opera are planning to implement it as a
native capability.

How easily could SVG be integrate with Axiom graphics? Should we think of
SVG as being a new output format the what postscript generation works now?

I believe that SVG is primarily a static 2-d graphics format, right? So
I think
we would still need something like the OpenInventor plug-in to provide
Axiom's "control panel" like scaling, rotation and other 3-d graph
manipulations.

Regards,
Bill Page.
C Y
2005-05-02 01:40:37 UTC
Permalink
--- ***@axiom-developer.org wrote:

[snip]
Post by d***@axiom-developer.org
I've seen the site http://openmap.bbn.com/~kanderso/lisp/scigraph
as well as some screenshots of the scigraph application. Is this
code free and open source? If so, where can I get this code? I'd
like to use it as a basis for experimenting.
Sorry if I'm jumping in:

Scigraph is included in the McCLIM release in the Apps directory:
http://common-lisp.net/cgi-bin/viewcvs.cgi/mcclim/Apps/Scigraph/?cvsroot=mcclim
Post by d***@axiom-developer.org
The McClim site (http://mcclim.cliki.net/Examples) seems to think
scigraph will run on McClim. Do you know if this is still true?
Some fixes were checked in a while back and I tested it out - it did
work, except I think for pop-up menus. Haven't tried it recently -
I'll start building and see if it still does.

CY

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Mike Thomas
2005-05-03 01:47:39 UTC
Permalink
Hi Camm.


EXCUSES

'Twas a long weekend here and I made full use of it for non-programming
purposes. It looks from the CVS log and the Axiom/GCL 2.6.7 related email
that there's a lot to catch up with.

Random thoughts follow.


2.6.7PRE

I just checked that 2.6.7pre builds on Windows. Will likewise test Maxima
etc as the week progresses.

What I need is some Lisp test code and simple instructions to check whatever
network functionality you've added which you hope will work straight off
under Windows.

Please also tell me your time frame for getting 2.6.7 finalised and I'll try
without promises to address GCL-TK within those limits.


SIGNALS AND WINDOWS

Are you implying (in some other email over the past few days) that SIGUSR1
is used in the handshaking between the TK server and GCL?

I take it SIGUSR1 is a user definable signal?

The signal question you raise there is a can of worms partly because I'm not
au fait with their use, but also in the sense that although GCL already has
a mechanism for attempting to emulate the receipt within GCL of fake signals
passed by another process (or from withing GCL), that mechanism requires the
other process (or GCL) to implement it's own special code to actually send
the fake signal in the first place. That system (shared memory) is used by
XMaxima to fake up SIGKILL. Once you have reached this stage you have to
ask yourself whether it would have been better to just use a Windows
mechanism in the first place. The other signals you mention are completely
different in terms of the relevant Windows system functionality if such even
exists (I'm thinking here of the profiling, memory fault handling and
sigio).


FORK() VS THREADS

If you go too far in the emulation direction, you also then have to ask
yourself whether you shouldn't be using Cygwin in the first place,
particularly with respect to fork(). When last I heard (several years ago)
Cygwin fork() had problems with sockets after the clone is done. (GRASS used
this mechanism for it's display server on Unix and Cygwin and never really
resolved the issues. My memory is that the MLton compiler gave up on Cygwin
fork() just a few months ago.) Lets face it, forked socket servers are one
of the main reasons people fork() in the first place. Furthermore, Cygwin
fork() is not efficient in terms of either space or time. If you choose to
use Cygwin you then close the circle and have an application which is
problematic to distribute and support which means you might as well tell
your users to use Linux (I admire Linux/*BSD/Cygwin and even X by the way,
don't get me wrong).

Ultimately, threads are the way to go in respect of this kind of
functionality on Windows but of course, we have to find the time and
know-how.


GUI BACKENDS

Time and know-how again whatever the path - I originally chose JAPI
precisely because I could implement a GUI library in a couple of hours;
hopefully GCL-TK can be salvaged on Windows in a similarly short time frame.
Other compiler projects I am aware of farm library work (especially large
open ended GUI library projects such as GTK, OpenGL, WXWidgets bindings) out
to helpers. The GCL project is short staffed as it is, with you (Camm) the
only seriously committed developer we have.

Cheers

Mike Thomas.
Camm Maguire
2005-05-04 18:01:06 UTC
Permalink
Greetings!
Post by Mike Thomas
Hi Camm.
EXCUSES
'Twas a long weekend here and I made full use of it for non-programming
purposes. It looks from the CVS log and the Axiom/GCL 2.6.7 related email
that there's a lot to catch up with.
No problem! Life takes precedence!
Post by Mike Thomas
Random thoughts follow.
2.6.7PRE
I just checked that 2.6.7pre builds on Windows. Will likewise test Maxima
etc as the week progresses.
What I need is some Lisp test code and simple instructions to check whatever
network functionality you've added which you hope will work straight off
under Windows.
Really just the little server code Bill is playing with. Please let
me know if your results ever differ from his. Should not break in
ANSI. It would also be nice to confirm that the new :daemon keyword
to socket does nothing on Windows. Lastly, perhaps try reading and
writing a client socket, i.e. with :host instead of :server set in
#'socket.
Post by Mike Thomas
Please also tell me your time frame for getting 2.6.7 finalised and I'll try
without promises to address GCL-TK within those limits.
Thank you so much! I think it looks like a good short term option on
axiom. No extreme rush, but I was hoping this weekend. An assessment
of the time requirements for gcl-tk and any technical obstacles also
most welcome.
Post by Mike Thomas
SIGNALS AND WINDOWS
Are you implying (in some other email over the past few days) that SIGUSR1
is used in the handshaking between the TK server and GCL?
Yes. Currently ifdefed out of gcltkaux for mingw -- the cause of the
errors I'm assuming. Please note that you can set (debugging t) in
package 'tk and get lots of diagnostics. Shelter's info page is
pretty good here.
Post by Mike Thomas
I take it SIGUSR1 is a user definable signal?
Yes.
Post by Mike Thomas
The signal question you raise there is a can of worms partly because I'm not
au fait with their use, but also in the sense that although GCL already has
a mechanism for attempting to emulate the receipt within GCL of fake signals
passed by another process (or from withing GCL), that mechanism requires the
other process (or GCL) to implement it's own special code to actually send
the fake signal in the first place. That system (shared memory) is used by
XMaxima to fake up SIGKILL. Once you have reached this stage you have to
ask yourself whether it would have been better to just use a Windows
mechanism in the first place. The other signals you mention are completely
different in terms of the relevant Windows system functionality if such even
exists (I'm thinking here of the profiling, memory fault handling and
sigio).
OK I see it now. Am a little confused how the receiving process gets
interrupted when another writes to shared memory -- is this a windows
thing, or is there a periodic check on the shared mem contents
somewhere? I think we need the former.

Thankfully, all our signal needs except for the maxima one you refer
to above are within GCL shipped programs, hence under our control.

At some point, the 'windows mechanism' you refer to might be better,
but for now, and since we already have a template with SIGKILL, I
suggest we just extend it for SIGUSR1 in gcl-tk/tkMain.c and the
like. Perhaps you might explain it to me if time permits. The other
signals might be nice, but I don't know of any pressing need for them
on Windows, at least not that anyone has expressed.
Post by Mike Thomas
FORK() VS THREADS
If you go too far in the emulation direction, you also then have to ask
yourself whether you shouldn't be using Cygwin in the first place,
particularly with respect to fork(). When last I heard (several years ago)
Cygwin fork() had problems with sockets after the clone is done. (GRASS used
this mechanism for it's display server on Unix and Cygwin and never really
resolved the issues. My memory is that the MLton compiler gave up on Cygwin
fork() just a few months ago.) Lets face it, forked socket servers are one
of the main reasons people fork() in the first place. Furthermore, Cygwin
fork() is not efficient in terms of either space or time. If you choose to
use Cygwin you then close the circle and have an application which is
problematic to distribute and support which means you might as well tell
your users to use Linux (I admire Linux/*BSD/Cygwin and even X by the way,
don't get me wrong).
I'm hoping we don't have to go to cygwin, though the option might be
nice, only if someone else steps up to do the lion's share of work.
We're not that far away on mingw, I think, thanks to your outstanding
efforts. Working mind share is the most valuable commodity here. We
have three short term options

1) No socket multiutasking on windows, -- need to hear from axiom how
onerous this would be

2) run-process the commands to an entirely separate AXIOMsys (easiest
and most serviceable, I'd think) Or even (system ...)

3) multiplex stin with select, which should be portable.
Post by Mike Thomas
Ultimately, threads are the way to go in respect of this kind of
functionality on Windows but of course, we have to find the time and
know-how.
Yep to both. Maybe someone explains in detail reentrancy to me
someday, as I've never found the need for threads, with such a great
tool like fork.
Post by Mike Thomas
GUI BACKENDS
Time and know-how again whatever the path - I originally chose JAPI
precisely because I could implement a GUI library in a couple of hours;
hopefully GCL-TK can be salvaged on Windows in a similarly short time frame.
Other compiler projects I am aware of farm library work (especially large
open ended GUI library projects such as GTK, OpenGL, WXWidgets bindings) out
to helpers. The GCL project is short staffed as it is, with you (Camm) the
only seriously committed developer we have.
Agreed. It would be great to farm out completely here, but there are
not enough users. Thankfully it looks as though we have two working
options (presuming windows gcl-tk), so we can table the rest
indefinitely until more resources arise, if ever.

Take care,
Post by Mike Thomas
Cheers
Mike Thomas.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2005-05-03 11:08:47 UTC
Permalink
Post by Camm Maguire
The gcl-tk stuff I posted earlier is at least an option which works
with axiom as currently distributed on Linux. My feeling is that
it is likely also a low hanging fruit on Windows. In the longer
term, one might supplement or replace with lisp functions outputting
html to a browser over a server socket. This will be supported
without patches in 2.6.7. Anyone can experiment with cvs branch
Version_2_6_7pre should they desire.
This sounds like a good plan to me.
Post by Camm Maguire
Post by Bill Page
I would like to understand how this "stdio multiplexing" thing
will work. Will it allow Axiom to simultaneously answer both
command line input and input/output via HTTP in a manner similar
to Axiom's current HyperTex browser?
My thought was to provide a system variable naming a list of
socket streams to watch, and have the GCL call to read on stdin
be preceded by a call to select, effectively having GCL process
stdin and any socket connections one at a time in the order in
which data presents itself thereon.
...
Perhaps in the general case we might need to "multiplex" both
stdin and stdout in pairs. One process like the HyperTeX
browser might send commands to Axiom, then receive the output
(or a copy of the output) and format it for inline display in
the browser. Meanwhile, a user might also type input commands
directly to the Axiom windows.
Post by Camm Maguire
In cvs branch Version_2_6_7pre, I've already implemented the
other option of having GCL fork a background process to serve
a socket, effectively letting the OS do the multitasking.
This will need a bit more magic on windows. The final option
of having the user call the socket serving function should be
available on all platforms now.
Hmmm... perhaps that explains why I don't seem to be able to
get Version_2_6_7pre to run the web server program properly
under windows?

I guess I should revert to applying your patches to gcl 2.6.6
and see if I can at least get that to work on Windows...
Post by Camm Maguire
...
We could also either inline some of the source from these projects
for these purposes into GCL (quite easy with compiler::link), or
fork two sockets to keep latex and/or dvipng processes running and
waiting for incremental input for performance reasons using run-process.
I like that idea. Right now on MathAction new processes are started
by the Python latexwiki module (a Zope extension) for each call to
latex and ghostscript (used instead of dvipng in earlier versions
of latexwiki). This does represent a considerable overhead when
saving a page. And if we were to use latex and dvipng on the desktop
this would certainly be even more noticable.
Post by Camm Maguire
Post by Bill Page
As I currently understand in theory Axiom graphics can be served
using NAG's OpenInventor extensions of to the Axiom graphics
program together with either OpenInventor itself (now open source)
or a compatible VRML plug-in for a standard browser.
Sounds like another forked process. The complication here will be
working out the interprocess communication. client/server in either
direction is not a problem, but current gcl-tk style gui/terminal
process sharing will take some work.
OpenInventor can run as a browser plug-in. In that case the browser
would handle the interprocess communication via HTTP. If we chose
to run OpenInventor as a stand alone viewer, then it would of
course have to do handle this itself. I presume that NAG has
already addressed this issue in their extension of Axiom graphics
for Windows.
Post by Camm Maguire
[Bill Page claimed: Axiom graphics is superiou]
Post by Bill Page
Perhaps not for interactive rotations and the like, but
gnuplot's static 3d capabilities are impressive, at least
to me. And those new coloring extensions in version 4
and greater as illustrated on the maxima page are outstanding
in my opinion.
Have you seen the graphics examples in the Axiom book? :)

Regards,
Bill Page.
Camm Maguire
2005-05-03 14:04:03 UTC
Permalink
Greetings!
Post by Page, Bill
Post by Camm Maguire
The gcl-tk stuff I posted earlier is at least an option which works
with axiom as currently distributed on Linux. My feeling is that
it is likely also a low hanging fruit on Windows. In the longer
term, one might supplement or replace with lisp functions outputting
html to a browser over a server socket. This will be supported
without patches in 2.6.7. Anyone can experiment with cvs branch
Version_2_6_7pre should they desire.
This sounds like a good plan to me.
Post by Camm Maguire
Post by Bill Page
I would like to understand how this "stdio multiplexing" thing
will work. Will it allow Axiom to simultaneously answer both
command line input and input/output via HTTP in a manner similar
to Axiom's current HyperTex browser?
My thought was to provide a system variable naming a list of
socket streams to watch, and have the GCL call to read on stdin
be preceded by a call to select, effectively having GCL process
stdin and any socket connections one at a time in the order in
which data presents itself thereon.
...
Perhaps in the general case we might need to "multiplex" both
stdin and stdout in pairs. One process like the HyperTeX
browser might send commands to Axiom, then receive the output
(or a copy of the output) and format it for inline display in
the browser. Meanwhile, a user might also type input commands
directly to the Axiom windows.
lisp has a rich stream structure for such purposes. input streams,
output streams, two-way streams, synonym streams, concatenated streams
...
Post by Page, Bill
Post by Camm Maguire
In cvs branch Version_2_6_7pre, I've already implemented the
other option of having GCL fork a background process to serve
a socket, effectively letting the OS do the multitasking.
This will need a bit more magic on windows. The final option
of having the user call the socket serving function should be
available on all platforms now.
Hmmm... perhaps that explains why I don't seem to be able to
get Version_2_6_7pre to run the web server program properly
under windows?
If you are referring to the separately posted example, I am hoping
that the GCL code is working but your empty page results for a missing
system directory or file.
Post by Page, Bill
I guess I should revert to applying your patches to gcl 2.6.6
and see if I can at least get that to work on Windows...
Unless I really erred, which is quite possible, the patch to 2.6.6 is
already in 2.6.7pre.
Post by Page, Bill
Post by Camm Maguire
...
We could also either inline some of the source from these projects
for these purposes into GCL (quite easy with compiler::link), or
fork two sockets to keep latex and/or dvipng processes running and
waiting for incremental input for performance reasons using run-process.
I like that idea. Right now on MathAction new processes are started
by the Python latexwiki module (a Zope extension) for each call to
latex and ghostscript (used instead of dvipng in earlier versions
of latexwiki). This does represent a considerable overhead when
saving a page. And if we were to use latex and dvipng on the desktop
this would certainly be even more noticable.
Post by Camm Maguire
Post by Bill Page
As I currently understand in theory Axiom graphics can be served
using NAG's OpenInventor extensions of to the Axiom graphics
program together with either OpenInventor itself (now open source)
or a compatible VRML plug-in for a standard browser.
Sounds like another forked process. The complication here will be
working out the interprocess communication. client/server in either
direction is not a problem, but current gcl-tk style gui/terminal
process sharing will take some work.
OpenInventor can run as a browser plug-in. In that case the browser
would handle the interprocess communication via HTTP. If we chose
to run OpenInventor as a stand alone viewer, then it would of
course have to do handle this itself. I presume that NAG has
already addressed this issue in their extension of Axiom graphics
for Windows.
Post by Camm Maguire
[Bill Page claimed: Axiom graphics is superiou]
Post by Bill Page
Perhaps not for interactive rotations and the like, but
gnuplot's static 3d capabilities are impressive, at least
to me. And those new coloring extensions in version 4
and greater as illustrated on the maxima page are outstanding
in my opinion.
Have you seen the graphics examples in the Axiom book? :)
Perhaps I should take a second look :-). Can those pictures be
generated with our current C/X11 graphics on Linux?

Take care,
Post by Page, Bill
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2005-05-04 00:00:25 UTC
Permalink
Mike,
|
| Hmmm... perhaps that explains why I don't seem to be able to
| get Version_2_6_7pre to run the web server program properly
| under windows?
$ ./unixport/saved_ansi_gcl.exe
GCL (GNU Common Lisp) 2.6.7 ANSI May 3 2005 09:54:15
...
(load "c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp")
Loading c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp
Error in LET [or a callee]: Error "No such file or directory"
on accepting connction to #<two-way stream 104d45c4>
...
No it turns out that I was wrong. The attached file does run as
expected on my windows Version_2_6_7pre gcl. But notice two
things:

1) I am not using the ANSI build.
2) The input from the browser is very picky and the server
code does *no* error checking.

The url path coincides with the root. To display a directory
the url must end in / So on my system

http://localhost:8085/msys/1.0/home/

displays the directory `c:\msys\1.0\home'. If the url does
not end in / then it is assumed to be a file (html format in
my version, or plain text by default). If the directory or
file does not exist then the server program stops. It works
but there is a lot of room for improvement.
|
| I guess I should revert to applying your patches to gcl 2.6.6
| and see if I can at least get that to work on Windows...
I did not have to do this.
Interestingly, today I can't get that to work properly either
insofar as getting the directory listsing you obtain.
I think you must have one too many simultaneous variables that
are affecting your results ... :)

Here are a few links to other people doing http and html in lisp:

http://claws.sourceforge.net/

"The CLAWS is aimed to provide a complete framework for developing
Web applications in Common Lisp. The project is in very early
stage, so no actual code is released (though something can be found
in CVS)."

http://www.franz.com/support/tutorials/
http://www.franz.com/support/tutorials/aserve-tutorial.htm
http://www.franz.com/support/documentation/7.0/doc/aserve/aserve.html
http://opensource.franz.com/aserve/aserve-dist/doc/aserve.html

"AllegroServe is an HTTP server and HTML generator for Lisp. As
with other HTTP servers, such as Apache (Unix) or the Internet
Information Services (Windows), AllegroServe can be used to deliver
web pages and other data over a TCP/IP network (such as the Internet)
to internet browsers such as Firefox, Mozilla, and the Internet
Explorer."

http://sourceforge.net/projects/portableaserve

"A free and portable Common Lisp Webserver. Portable AllegroServe
is a variant of AllegroServe(tm) with an explicit emphasis on
portability between Lispsystems and Operating Systems."

http://www.ai.mit.edu/projects/iiip/doc/cl-http/server.html
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
http://www.ai.mit.edu/projects/iiip/conferences/luv95/tutorial.html

"Major components include a mature HTTP 1.1 server, a robust
caching proxy server, a programmatic client, a constraint-guided
Web Walker, a full-text indexation & retrieval, along with a
variety of Web-related tools and contributions."

etc. etc.


Regards,
Bill Page.
Camm Maguire
2005-05-04 17:41:02 UTC
Permalink
Greetings!
Post by Page, Bill
Mike,
|
| Hmmm... perhaps that explains why I don't seem to be able to
| get Version_2_6_7pre to run the web server program properly
| under windows?
$ ./unixport/saved_ansi_gcl.exe
GCL (GNU Common Lisp) 2.6.7 ANSI May 3 2005 09:54:15
...
(load "c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp")
Loading c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp
Error in LET [or a callee]: Error "No such file or directory"
on accepting connction to #<two-way stream 104d45c4>
...
No it turns out that I was wrong. The attached file does run as
expected on my windows Version_2_6_7pre gcl. But notice two
1) I am not using the ANSI build.
OK, I've just tested on Linux under ANSI, and it works the same for
me (as it should). If this is not the case on Windows, please someone
let me know asap.
Post by Page, Bill
2) The input from the browser is very picky and the server
code does *no* error checking.
The url path coincides with the root. To display a directory
the url must end in / So on my system
http://localhost:8085/msys/1.0/home/
displays the directory `c:\msys\1.0\home'. If the url does
not end in / then it is assumed to be a file (html format in
my version, or plain text by default). If the directory or
file does not exist then the server program stops. It works
but there is a lot of room for improvement.
OK, I think I finally understand your earlier comment about
directory/filename distinction. I've quickly scanned the hyperspec on
this and can't find the relevant section, so am referring this to our
resident expert Paul Dietz/

Paul -- Can a compliant lisp implementation return some discernibly
special type of stream yielding directory entries on read, perhaps in
list form, when a path like /mydir or /mydir/ is supplied to open?
What is the best way to do this?

As for bombing when the file is not there, this would appear to be an
error in probe-file on Windows. The 'server' example is supposed to
return a blank page and continue in this case. Please let me know if
there is a bug here. (si::use-fast-links nil) and :bt if thrown into
the debugger. (I do get an error on Linux when the file exists but
cannot be opened due to permissions, for example.)

Looking at this has made me notice a bug -- one can apparently open
streams with directory pathnames, but reading of course fails. I am
committing changes designed to fix this simply for now, by ensuring
that open_stream and probe-file (and file-write-length, file-author
...) fail (i.e. return nil) on directories. Eventually we might want
to allow open to succeed, returning a 'user-defined' stream, and have
read thereon return stat structures for the files therein. The only
standardized interface to directories under lisp I can find is
(directory ...), not surprisingly, so with this set of changes, this
will be the only thing you can do with a pathname that refers to a
directory, trailing slash or not. I.e.

=============================================================================
Post by Page, Bill
(open "/etc" :if-does-not-exist nil)
NIL
Post by Page, Bill
(open "/etc/" :if-does-not-exist nil)
NIL
Post by Page, Bill
(open "/etc/passwd" :if-does-not-exist nil)
#<input stream "/etc/passwd">
Post by Page, Bill
(directory "/etc")
(#p"/etc")
Post by Page, Bill
(directory "/etc/")
(#p"/etc/R" #p"/etc/X11" #p"/etc/adduser.conf" #p"/etc/adjtime"
#p"/etc/aliases" #p"/etc/aliases.O" #p"/etc/alternatives" #p"/etc/apm"
#p"/etc/apt" #p"/etc/at.deny" #p"/etc/autoconf2.13"
#p"/etc/bash.bashrc" #p"/etc/bash_completion"
#p"/etc/bash_completion.d" #p"/etc/bonobo-activation"
#p"/etc/calendar" #p"/etc/chatscripts" #p"/etc/common-lisp"
#p"/etc/console" #p"/etc/console-tools" #p"/etc/cron.d"
#p"/etc/cron.daily" #p"/etc/cron.hourly" #p"/etc/cron.monthly"
#p"/etc/cron.weekly" #p"/etc/crontab" #p"/etc/cups"
#p"/etc/cvs-cron.conf" #p"/etc/cxref" #p"/etc/debconf.conf"
#p"/etc/debian_version" #p"/etc/default" #p"/etc/defoma"
#p"/etc/deluser.conf" #p"/etc/devscripts.conf"
#p"/etc/dhclient-script" #p"/etc/dhclient.conf" #p"/etc/dhelp"
#p"/etc/dictionaries-common" #p"/etc/dpkg" #p"/etc/dupload.conf"
#p"/etc/emacs" #p"/etc/emacs21" #p"/etc/email-addresses"
#p"/etc/esound" #p"/etc/exim" #p"/etc/exim4" #p"/etc/fdmount.conf"
#p"/etc/fonts" #p"/etc/fstab" #p"/etc/gconf" #p"/etc/gnome-vfs-2.0"
#p"/etc/gnome-vfs-mime-magic" #p"/etc/groff" #p"/etc/group"
#p"/etc/group-" #p"/etc/gs-gpl" #p"/etc/gtk" #p"/etc/gtk-2.0"
#p"/etc/host.conf" #p"/etc/hostname" #p"/etc/hosts.allow"
#p"/etc/hosts.deny" #p"/etc/inetd.conf" #p"/etc/init.d"
#p"/etc/inittab" #p"/etc/inputrc" #p"/etc/issue" #p"/etc/issue.net"
#p"/etc/kernel-pkg.conf" #p"/etc/lam" #p"/etc/ld.so.cache"
#p"/etc/ld.so.conf" #p"/etc/ldap" #p"/etc/lintianrc"
#p"/etc/lisp-config.lisp" #p"/etc/locale.alias" #p"/etc/locale.gen"
#p"/etc/localtime" #p"/etc/login.defs" #p"/etc/logrotate.conf"
#p"/etc/logrotate.d" #p"/etc/lprng" #p"/etc/magic" #p"/etc/mail.rc"
#p"/etc/mailcap" #p"/etc/mailcap.order" #p"/etc/mailname"
#p"/etc/mailname.O" #p"/etc/manpath.config" #p"/etc/mediaprm"
#p"/etc/mime.types" #p"/etc/mkinitrd" #p"/etc/modules"
#p"/etc/modules.conf" #p"/etc/modutils" #p"/etc/motd"
#p"/etc/mozilla-firefox" #p"/etc/mpich" #p"/etc/mtab" #p"/etc/nanorc"
#p"/etc/network" #p"/etc/nsswitch.conf" #p"/etc/openoffice"
#p"/etc/opt" #p"/etc/pam.conf" #p"/etc/pam.d" #p"/etc/pango"
#p"/etc/papersize" #p"/etc/passwd" #p"/etc/passwd-" #p"/etc/perl"
#p"/etc/ppp" #p"/etc/prelink.cache" #p"/etc/prelink.conf"
#p"/etc/printcap" #p"/etc/profile" #p"/etc/protocols"
#p"/etc/python2.3" #p"/etc/rc0.d" #p"/etc/rc1.d" #p"/etc/rc2.d"
#p"/etc/rc3.d" #p"/etc/rc4.d" #p"/etc/rc5.d" #p"/etc/rc6.d"
#p"/etc/rcS.d" #p"/etc/reportbug.conf" #p"/etc/resolv.conf"
#p"/etc/rmt" #p"/etc/rpc" #p"/etc/securetty" #p"/etc/security"
#p"/etc/services" #p"/etc/sgml" #p"/etc/shells" #p"/etc/skel"
#p"/etc/sound" #p"/etc/ssh" #p"/etc/sysctl.conf" #p"/etc/syslog.conf"
#p"/etc/terminfo" #p"/etc/texdoctk" #p"/etc/texmf" #p"/etc/ucf.conf"
#p"/etc/updatedb.conf" #p"/etc/vga" #p"/etc/wgetrc" #p"/etc/xemacs21"
#p"/etc/xml" #p"/etc/xpdf")
Post by Page, Bill
(directory "/etc/passwd")
(#p"/etc/passwd" #p"/etc/passwd-")

(directory "/etc/passwd/")

NIL

=============================================================================

Here is a little modification to the server example:

(defun foo (s)
(let* ((get (read s nil 'eof))
(fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
(dn (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))
(dir (directory dn))
(file (unless dir (when (probe-file fn) fn))))
(format s "HTTP/1.1 ~S~%" (if fn 404 500))
(format s "Content-type: text/html~%~%")
(format t "get ~a fn ~a dn ~a~%" get fn dn)
(cond (file (with-open-file (q file) (si::copy-stream q s)))
(dir (dolist (l dir)
(let ((n (namestring l)))
(format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
(close s)))

=============================================================================

These are just toys of course, just meant to illustrate my limited
understanding of how one can distinguish files from directories in
*standard* lisp. We can add anything non-standard we might need, of
course.
Post by Page, Bill
|
| I guess I should revert to applying your patches to gcl 2.6.6
| and see if I can at least get that to work on Windows...
I did not have to do this.
Interestingly, today I can't get that to work properly either
insofar as getting the directory listsing you obtain.
I think you must have one too many simultaneous variables that
are affecting your results ... :)
http://claws.sourceforge.net/
"The CLAWS is aimed to provide a complete framework for developing
Web applications in Common Lisp. The project is in very early
stage, so no actual code is released (though something can be found
in CVS)."
http://www.franz.com/support/tutorials/
http://www.franz.com/support/tutorials/aserve-tutorial.htm
http://www.franz.com/support/documentation/7.0/doc/aserve/aserve.html
http://opensource.franz.com/aserve/aserve-dist/doc/aserve.html
"AllegroServe is an HTTP server and HTML generator for Lisp. As
with other HTTP servers, such as Apache (Unix) or the Internet
Information Services (Windows), AllegroServe can be used to deliver
web pages and other data over a TCP/IP network (such as the Internet)
to internet browsers such as Firefox, Mozilla, and the Internet
Explorer."
http://sourceforge.net/projects/portableaserve
"A free and portable Common Lisp Webserver. Portable AllegroServe
is a variant of AllegroServe(tm) with an explicit emphasis on
portability between Lispsystems and Operating Systems."
http://www.ai.mit.edu/projects/iiip/doc/cl-http/server.html
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
http://www.ai.mit.edu/projects/iiip/conferences/luv95/tutorial.html
"Major components include a mature HTTP 1.1 server, a robust
caching proxy server, a programmatic client, a constraint-guided
Web Walker, a full-text indexation & retrieval, along with a
variety of Web-related tools and contributions."
People have asked about allegro serve before, and it should work, but
I haven't had time to look at it. It is likely overkill for the
purpose at hand.

Take care,
Post by Page, Bill
etc. etc.
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2005-05-04 20:17:20 UTC
Permalink
Post by Camm Maguire
OK, I think I finally understand your earlier comment about
directory/filename distinction. I've quickly scanned the hyperspec on
this and can't find the relevant section, so am referring this to our
resident expert Paul Dietz/
...
Looking at this has made me notice a bug -- one can apparently open
streams with directory pathnames, but reading of course fails. I am
committing changes** designed to fix this simply for now, by ensuring
that open_stream and probe-file (and file-write-length, file-author
...) fail (i.e. return nil) on directories. Eventually we might want
to allow open to succeed, returning a 'user-defined' stream, and have
read thereon return stat structures for the files therein. The only
standardized interface to directories under lisp I can find is
(directory ...), not surprisingly, so with this set of changes, this
will be the only thing you can do with a pathname that refers to a
directory, trailing slash or not.
Camm,

Are these changes ** in cvs -r Version_2_6_7pre? If not can you send me
the patches?

Thanks,

Bill Page.
Bill Page
2005-05-05 02:53:23 UTC
Permalink
Post by Camm Maguire
OK, I've just tested on Linux under ANSI, and it works the same for
me (as it should). If this is not the case on Windows, please someone
let me know asap.
Perhaps Mike's test demonstrates that this is not working on the
Windows ANSI version, but it works fine for me on Windows XP
with the non-ANSI version.
Post by Camm Maguire
As for bombing when the file is not there, this would appear to be an
error in probe-file on Windows. The 'server' example is supposed to
return a blank page and continue in this case. Please let me know if
there is a bug here.
This works properly now with the most recent Version_2_6_7pre
from cvs *and* your revised `foo' routine below. Note that with
the new behaviour of (probe-file "xxx") which returns NIL if xxx
is a directory, the old version of `foo' no longer worked.
Post by Camm Maguire
=============================================================================
Post by Page, Bill
(open "/etc" :if-does-not-exist nil)
NIL
On Windows XP/sp2 with latest Version_2_6_7pre compiled non-ansi
Post by Camm Maguire
(open "/msys" :if-does-not-exist nil)
NIL
Post by Camm Maguire
Post by Page, Bill
(open "/etc/" :if-does-not-exist nil)
NIL
(open "/msys/" :if-does-not-exist nil)
NIL
Post by Camm Maguire
Post by Page, Bill
(open "/etc/passwd" :if-does-not-exist nil)
#<input stream "/etc/passwd">
(open "/msys/1.0/msys.bat" :if-does-not-exist nil)
#<input stream "/msys/1.0/msys.bat">
Post by Camm Maguire
Post by Page, Bill
(directory "/etc")
(#p"/etc")
(directory "/msys/1.0")
(#p"/msys/1.0")
Post by Camm Maguire
Post by Page, Bill
(directory "/etc/")
(#p"/etc/R" #p"/etc/X11" #p"/etc/adduser.conf" #p"/etc/adjtime"
...
#p"/etc/xml" #p"/etc/xpdf")
(directory "/msys/1.0/")
(#p"/msys/1.0/.bash_history" #p"/msys/1.0/bin" #p"/msys/1.0/doc"
#p"/msys/1.0/etc" #p"/msys/1.0/home" #p"/msys/1.0/lib"
#p"/msys/1.0/m.ico" #p"/msys/1.0/mingw" #p"/msys/1.0/msys.bat"
#p"/msys/1.0/msys.ico" #p"/msys/1.0/share" #p"/msys/1.0/uninstall")
Post by Camm Maguire
Post by Page, Bill
(directory "/etc/passwd")
(#p"/etc/passwd" #p"/etc/passwd-")
(directory "/msys/1.0/msys.bat")
(#p"/msys/1.0/msys.bat")

Perhaps this last one is a little strange since `msys.bat' is a file?
Post by Camm Maguire
=============================================================================
(defun foo (s)
(let* ((get (read s nil 'eof))
(fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
(dn (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))
(dir (directory dn))
(file (unless dir (when (probe-file fn) fn))))
(format s "HTTP/1.1 ~S~%" (if fn 404 500))
(format s "Content-type: text/html~%~%")
(format t "get ~a fn ~a dn ~a~%" get fn dn)
(cond (file (with-open-file (q file) (si::copy-stream q s)))
(dir (dolist (l dir)
(let ((n (namestring l)))
(format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
(close s)))
=============================================================================
These are just toys of course, just meant to illustrate my limited
understanding of how one can distinguish files from directories in
*standard* lisp. We can add anything non-standard we might need, of
course.
I like it. As I said, it works for me with the non-ansi gcl Version_2_6_7pre
on Windows XP/sp2. No aborts this time.

And I am learning a little lisp too :) Thanks.

Cheers,
Bill Page.
Camm Maguire
2005-05-05 14:19:14 UTC
Permalink
Greetings!
Post by Bill Page
Post by Camm Maguire
OK, I've just tested on Linux under ANSI, and it works the same for
me (as it should). If this is not the case on Windows, please someone
let me know asap.
Perhaps Mike's test demonstrates that this is not working on the
Windows ANSI version, but it works fine for me on Windows XP
with the non-ANSI version.
OK, if someone can verify that it is ansi which breaks, please let me
know.
Post by Bill Page
Post by Camm Maguire
As for bombing when the file is not there, this would appear to be an
error in probe-file on Windows. The 'server' example is supposed to
return a blank page and continue in this case. Please let me know if
there is a bug here.
This works properly now with the most recent Version_2_6_7pre
from cvs *and* your revised `foo' routine below. Note that with
the new behaviour of (probe-file "xxx") which returns NIL if xxx
is a directory, the old version of `foo' no longer worked.
Yes.
Post by Bill Page
Post by Camm Maguire
=============================================================================
Post by Page, Bill
(open "/etc" :if-does-not-exist nil)
NIL
On Windows XP/sp2 with latest Version_2_6_7pre compiled non-ansi
Post by Camm Maguire
(open "/msys" :if-does-not-exist nil)
NIL
Post by Camm Maguire
Post by Page, Bill
(open "/etc/" :if-does-not-exist nil)
NIL
(open "/msys/" :if-does-not-exist nil)
NIL
Post by Camm Maguire
Post by Page, Bill
(open "/etc/passwd" :if-does-not-exist nil)
#<input stream "/etc/passwd">
(open "/msys/1.0/msys.bat" :if-does-not-exist nil)
#<input stream "/msys/1.0/msys.bat">
Post by Camm Maguire
Post by Page, Bill
(directory "/etc")
(#p"/etc")
(directory "/msys/1.0")
(#p"/msys/1.0")
Post by Camm Maguire
Post by Page, Bill
(directory "/etc/")
(#p"/etc/R" #p"/etc/X11" #p"/etc/adduser.conf" #p"/etc/adjtime"
...
#p"/etc/xml" #p"/etc/xpdf")
(directory "/msys/1.0/")
(#p"/msys/1.0/.bash_history" #p"/msys/1.0/bin" #p"/msys/1.0/doc"
#p"/msys/1.0/etc" #p"/msys/1.0/home" #p"/msys/1.0/lib"
#p"/msys/1.0/m.ico" #p"/msys/1.0/mingw" #p"/msys/1.0/msys.bat"
#p"/msys/1.0/msys.ico" #p"/msys/1.0/share" #p"/msys/1.0/uninstall")
Post by Camm Maguire
Post by Page, Bill
(directory "/etc/passwd")
(#p"/etc/passwd" #p"/etc/passwd-")
(directory "/msys/1.0/msys.bat")
(#p"/msys/1.0/msys.bat")
Perhaps this last one is a little strange since `msys.bat' is a file?
This is all correct. #'directory is a wildcard matching function for
the filesystem (perhaps misleadingly named), so should return the
file path if supplied a file namestring.
Post by Bill Page
Post by Camm Maguire
=============================================================================
(defun foo (s) (let* ((get (read s nil 'eof)) (fn (and (eq
get 'get) (string-downcase (read s nil 'eof))))
(dn (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))
(dir (directory dn))
(file (unless dir (when (probe-file fn) fn))))
This last line should likely read

(file (or (probe-file fn) dir))

just to ensure that probe-file takes precedence.
Post by Bill Page
Post by Camm Maguire
(format s "HTTP/1.1 ~S~%" (if fn 404 500))
(format s "Content-type: text/html~%~%")
(format t "get ~a fn ~a dn ~a~%" get fn dn)
(cond (file (with-open-file (q file) (si::copy-stream q s)))
(dir (dolist (l dir)
(let ((n (namestring l)))
(format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
(close s)))
=============================================================================
These are just toys of course, just meant to illustrate my limited
understanding of how one can distinguish files from directories in
*standard* lisp. We can add anything non-standard we might need, of
course.
I like it. As I said, it works for me with the non-ansi gcl Version_2_6_7pre
on Windows XP/sp2. No aborts this time.
And I am learning a little lisp too :) Thanks.
Great!

Take care,
Post by Bill Page
Cheers,
Bill Page.
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Mike Thomas
2005-05-03 23:00:56 UTC
Permalink
Hi Bill/Camm.

| > In cvs branch Version_2_6_7pre, I've already implemented the
| > other option of having GCL fork a background process to serve
| > a socket, effectively letting the OS do the multitasking.
| > This will need a bit more magic on windows. The final option
| > of having the user call the socket serving function should be
| > available on all platforms now.
|
| Hmmm... perhaps that explains why I don't seem to be able to
| get Version_2_6_7pre to run the web server program properly
| under windows?

Looks like it Bill:

$ ./unixport/saved_ansi_gcl.exe
GCL (GNU Common Lisp) 2.6.7 ANSI May 3 2005 09:54:15
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
(load "c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp")
Loading c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp
Error in LET [or a callee]: Error "No such file or directory" on accepting
conn
ction to #<two-way stream 104d45c4>


Fast links are on: do (use-fast-links nil) for debugging
Broken at SYSTEM:ACCEPT. Type :H for Help.
1 (Continue) Retry loading file
"c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.l
p".
2 (Abort) Return to top level.
dbl:>>:bt

#0 ACCEPT {loc0=#<two-way stream 104d45c4>} [ihs=13]
#1 BAR {lambda-block=foo,} [ihs=8]
#2 CLCS-LOAD {file=nil,args=nil,g2549=nil,loc3=(lambda-block bar (p fn)
...),
oc4=8085,loc5=(...} [ihs=7]
#3 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function
conditions::clcs
load>,loc4...} [ihs=6]
#4 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7
"c:/cvs/stable/...} [ihs=5]
#5 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL

|
| I guess I should revert to applying your patches to gcl 2.6.6
| and see if I can at least get that to work on Windows...

Interestingly, today I can't get that to work properly either insofar as
getting the directory listsing you obtain.

Cheers

Mike Thomas
Mike Thomas
2005-05-05 00:36:34 UTC
Permalink
Hi Camm/Bill.

A bunch of Windows probe-file, directory and server output below. Basically
the server program is failing because accept won't deal with the "socket"
it's being passed and on first glance I suspect that this is because it is
not the right Winsock type. I'll look further later but I'm suspicious that
there may be a lot of work ahead here for me.

Cheers

Mike Thomas

| As for bombing when the file is not there, this would appear to be an
| error in probe-file on Windows. The 'server' example is supposed to
| return a blank page and continue in this case. Please let me know if
| there is a bug here. (si::use-fast-links nil) and :bt if thrown into
| the debugger. (I do get an error on Linux when the file exists but
| cannot be opened due to permissions, for example.)
(probe-file "/msys/1.0")
#p"c:/msys/1.0"
(probe-file "/msys/1.0/")
#p"c:/msys/1.0/"
(probe-file "c:/msys/1.0/")
#p"c:/msys/1.0/"
(probe-file "c:/msys/1.0")
#p"c:/msys/1.0"
(directory "c:/msys/1.0")
(#p"c:/msys/1.0")
(directory "c:/msys/1.0/")
(#p"c:/msys/1.0/bin" #p"c:/msys/1.0/doc" #p"c:/msys/1.0/etc"
#p"c:/msys/1.0/home" #p"c:/msys/1.0/include" #p"c:/msys/1.0/lib"
#p"c:/msys/1.0/local" #p"c:/msys/1.0/m.ico" #p"c:/msys/1.0/mingw"
#p"c:/msys/1.0/msys.bat" #p"c:/msys/1.0/msys.bat~"
#p"c:/msys/1.0/msys.ico" #p"c:/msys/1.0/share" #p"c:/msys/1.0/ssl"
#p"c:/msys/1.0/uninstall")
(open "/etc" :if-does-not-exist nil)
NIL
(open "c:/msys/1.0" :if-does-not-exist nil)
NIL
(open "c:/msys/1.0/" :if-does-not-exist nil)
NIL
(open "c:/msys/1.0/msys.bat" :if-does-not-exist nil)
#<input stream "c:/msys/1.0/msys.bat">
(bar 8085 #'foo)
Error in LET [or a callee]: Error "No such file or directory" on accepting
conne
ction to #<two-way stream 104c969c>


Broken at INVOKE-DEBUGGER. Type :H for Help.
1 (Abort) Return to top level.
dbl:>>:bt

#0 INVOKE-DEBUGGER
{datum=#<conditions::internal-simple-stream-error.0>,argume
nts=nil,loc2=#<condit...} [ihs=15]
#1 ERROR
{datum=conditions::internal-simple-stream-error,arguments=(:function-
name let :f...} [ihs=14]
#2 CLCS-UNIVERSAL-ERROR-HANDLER
{error-name=:error,correctable=nil,function-na
me=let,continue-format-string=("")...} [ihs=13]
#3 ACCEPT {loc0=#<two-way stream 104c969c>} [ihs=12]
#4 BAR {lambda-block=foo,} [ihs=7]
#5 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
...),loc4=80
87,loc5=(l...} [ihs=6]
#6 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7=
"c:/cvs/stable/...} [ihs=5]
#7 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
dbl:>>:h
Bill Page
2005-05-05 02:02:46 UTC
Permalink
Post by Mike Thomas
Hi Camm/Bill.
A bunch of Windows probe-file, directory and server output below. Basically
the server program is failing because accept won't deal with the "socket"
it's being passed and on first glance I suspect that this is because it is
not the right Winsock type. I'll look further later but I'm suspicious that
there may be a lot of work ahead here for me.
That is quite strange. I just re-build gcl Version_2_6_7pre (non-ansi)
from cvs on
another Windows XP/sp2 machine. Camm's web server program (latest version,
see Camm's email) continues to work fine for me.

What version of Windows are you using?

Cheers,
Bill Page.
Camm Maguire
2005-05-05 14:07:05 UTC
Permalink
Greetings, and thanks as always Mike for your heroic efforts!
Post by Mike Thomas
Hi Camm/Bill.
A bunch of Windows probe-file, directory and server output below. Basically
the server program is failing because accept won't deal with the "socket"
it's being passed and on first glance I suspect that this is because it is
not the right Winsock type. I'll look further later but I'm suspicious that
there may be a lot of work ahead here for me.
Your the expert here, but I'm confused as to how you found success
earlier on if this is the case.
Post by Mike Thomas
Cheers
Mike Thomas
| As for bombing when the file is not there, this would appear to be an
| error in probe-file on Windows. The 'server' example is supposed to
| return a blank page and continue in this case. Please let me know if
| there is a bug here. (si::use-fast-links nil) and :bt if thrown into
| the debugger. (I do get an error on Linux when the file exists but
| cannot be opened due to permissions, for example.)
(probe-file "/msys/1.0")
#p"c:/msys/1.0"
(probe-file "/msys/1.0/")
#p"c:/msys/1.0/"
(probe-file "c:/msys/1.0/")
#p"c:/msys/1.0/"
(probe-file "c:/msys/1.0")
#p"c:/msys/1.0"
With the commits to 2.6.7pre I made yesterday, all these probe-files
to directories should return nil. Please let me know asap if this is
not the case (still), and preferably why if you can discern the reason
easily.
Post by Mike Thomas
(directory "c:/msys/1.0")
(#p"c:/msys/1.0")
(directory "c:/msys/1.0/")
(#p"c:/msys/1.0/bin" #p"c:/msys/1.0/doc" #p"c:/msys/1.0/etc"
#p"c:/msys/1.0/home" #p"c:/msys/1.0/include" #p"c:/msys/1.0/lib"
#p"c:/msys/1.0/local" #p"c:/msys/1.0/m.ico" #p"c:/msys/1.0/mingw"
#p"c:/msys/1.0/msys.bat" #p"c:/msys/1.0/msys.bat~"
#p"c:/msys/1.0/msys.ico" #p"c:/msys/1.0/share" #p"c:/msys/1.0/ssl"
#p"c:/msys/1.0/uninstall")
(open "/etc" :if-does-not-exist nil)
NIL
(open "c:/msys/1.0" :if-does-not-exist nil)
NIL
(open "c:/msys/1.0/" :if-does-not-exist nil)
NIL
(open "c:/msys/1.0/msys.bat" :if-does-not-exist nil)
#<input stream "c:/msys/1.0/msys.bat">
All of this is right.
Post by Mike Thomas
(bar 8085 #'foo)
Error in LET [or a callee]: Error "No such file or directory" on accepting
conne
ction to #<two-way stream 104c969c>
At least on Linux, accept might fail with a EAGAIN or similar if no
connections are pending. It is critical to this example that the call
to #'listen in #'bar correctly return t iff a connection has been
made. You can test this with telnet from a separate shell window.
I.e.

(setq s (si::socket 8085 :server #'foo))
(listen s) -> nil (no telnet localhost 8085)
(listen s) -> t (after telnet localhost 8085)

Also, if you get a chance, perhaps you could share your opinion on
whether I may have broken what was working, or whether you feel the
initial reports of success were invalid, unstable, or premature.

Take care,
Post by Mike Thomas
Broken at INVOKE-DEBUGGER. Type :H for Help.
1 (Abort) Return to top level.
dbl:>>:bt
#0 INVOKE-DEBUGGER
{datum=#<conditions::internal-simple-stream-error.0>,argume
nts=nil,loc2=#<condit...} [ihs=15]
#1 ERROR
{datum=conditions::internal-simple-stream-error,arguments=(:function-
name let :f...} [ihs=14]
#2 CLCS-UNIVERSAL-ERROR-HANDLER
{error-name=:error,correctable=nil,function-na
me=let,continue-format-string=("")...} [ihs=13]
#3 ACCEPT {loc0=#<two-way stream 104c969c>} [ihs=12]
#4 BAR {lambda-block=foo,} [ihs=7]
#5 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
...),loc4=80
87,loc5=(l...} [ihs=6]
#6 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7=
"c:/cvs/stable/...} [ihs=5]
#7 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
dbl:>>:h
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2005-05-05 14:14:03 UTC
Permalink
Post by Camm Maguire
Post by Mike Thomas
(probe-file "/msys/1.0")
#p"c:/msys/1.0"
(probe-file "/msys/1.0/")
#p"c:/msys/1.0/"
(probe-file "c:/msys/1.0/")
#p"c:/msys/1.0/"
(probe-file "c:/msys/1.0")
#p"c:/msys/1.0"
With the commits to 2.6.7pre I made yesterday, all these probe-files
to directories should return nil. Please let me know asap if this is
not the case (still), and preferably why if you can discern the reason
easily.
I can confirm that these all do return nil on the build of gcl
Version_2_6_7pre
that I did last night.

Regards,
Bill Page.
Mike Thomas
2005-05-05 02:49:57 UTC
Permalink
Hi Bill.

| That is quite strange. I just re-build gcl Version_2_6_7pre (non-ansi)
| from cvs on
| another Windows XP/sp2 machine. Camm's web server program (latest version,
| see Camm's email) continues to work fine for me.

XP SP2 CVS 2.6.7pre and both of gcc versions 3.3.1 and 3.4.2, using Camm's
email version (and other versions at that).

CHeers

Mike Thomas
Camm Maguire
2005-05-05 14:08:35 UTC
Permalink
Greetings!

Would it be helpful for us to try to enlist the testing assistance of
other windows users/developers to lighten the load, e.g. Vadim and
David Billinghurst?

Take care,
Post by Mike Thomas
Hi Bill.
| That is quite strange. I just re-build gcl Version_2_6_7pre (non-ansi)
| from cvs on
| another Windows XP/sp2 machine. Camm's web server program (latest version,
| see Camm's email) continues to work fine for me.
XP SP2 CVS 2.6.7pre and both of gcc versions 3.3.1 and 3.4.2, using Camm's
email version (and other versions at that).
CHeers
Mike Thomas
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Mike Thomas
2005-05-05 04:32:18 UTC
Permalink
Hi Bill/Camm.

| >OK, I've just tested on Linux under ANSI, and it works the same for
| >me (as it should). If this is not the case on Windows, please someone
| >let me know asap.
| >
| >
| Perhaps Mike's test demonstrates that this is not working on the
| Windows ANSI version, but it works fine for me on Windows XP
| with the non-ANSI version.

I just tried the CLtL1 build - no joy.

There are definite problems with the new code as socket variables should be
defined with SOCKET (an unsigned int) rather than int and the error return
values on Windows are not the same as on BSD systems however I just tried to
eliminate those problems and still have the same trouble.

I'm using Internet Explorer. I'll keep looking perhaps tomorrow. Hopefully
this is due to a stupid mistake on my part.

Cheers

Mike Thomas.
Bill Page
2005-05-05 13:41:30 UTC
Permalink
Post by Mike Thomas
I just tried the CLtL1 build - no joy.
There are definite problems with the new code as socket variables should be
defined with SOCKET (an unsigned int) rather than int and the error return
values on Windows are not the same as on BSD systems however I just tried to
eliminate those problems and still have the same trouble.
I'm using Internet Explorer.
Ah, yes now I can confirm there are definite problems accessing the
"gcl simple web server" using IE 6. I have been testing using Firefox 1.0.3
and oddly exactly the same url works fine with no aborts.
Post by Mike Thomas
I'll keep looking perhaps tomorrow. Hopefully
this is due to a stupid mistake on my part.
No I think you are right (we are both right :). There is a problem
when using Internet Explorer. IE must be making rather different
socket calls than FireFox. That seems quite odd to me.

Using IE, the problem seems to intermittant. It works for a while
with some urls and not others.

Here is a typical failed test using IE.

---------
$ saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 May 4 2005 16:56:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Post by Mike Thomas
(load "test-http2.lsp")
Loading test-http2.lsp

----------

Then using Microsoft Explorer 6 sp2 and url
http://localhost:8085/msys/1.0/
I get the following error:

----------

get GET fn /msys/1.0/ dn /msys/1.0/

Error: error writing to socket: errno= 22
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by FORMAT.
Broken at FORMAT. Type :H for Help.
Post by Mike Thomas
Post by Camm Maguire
(si::use-fast-links nil)
NIL
Post by Mike Thomas
Post by Camm Maguire
:bt
#0 FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a href=\"~a\">~a</a>
<a href=\"~a/\"> /....} [ihs=19]
#1 FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a href=\"~a\">~a</a>
<a href=\"~a/\"> /....} [ihs=18]
#2 FOO {} [ihs=13]
#3 BAR {lambda-block=foo,} [ihs=8]
#4 LOAD {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
...),loc4=8085,loc5=(l...} [ihs=7]
#5 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function
load>,loc4=#p"test-http2.ls...} [ihs=6]
#6 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="C:/msys/1.0/ho...}
[ihs=5]
#7 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
--------------

Does this back trace help to see what's going wrong?

If I start again and do the same thing using FireFox I get:

$ saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 May 4 2005 16:56:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Post by Mike Thomas
(load "test-http2.lsp")
Loading test-http2.lsp
get GET fn /msys/1.0/ dn /msys/1.0/
get GET fn /favicon.ico dn /favicon.ico/

--------

And the list directories appears in the browser.

Let me know what I can try next.

Regards,
Bill Page.
Camm Maguire
2005-05-05 17:14:41 UTC
Permalink
Greetings!
Post by Bill Page
Post by Mike Thomas
I just tried the CLtL1 build - no joy.
There are definite problems with the new code as socket variables should be
defined with SOCKET (an unsigned int) rather than int and the error return
values on Windows are not the same as on BSD systems however I just tried to
eliminate those problems and still have the same trouble.
I'm using Internet Explorer.
Ah, yes now I can confirm there are definite problems accessing the
"gcl simple web server" using IE 6. I have been testing using Firefox 1.0.3
and oddly exactly the same url works fine with no aborts.
Post by Mike Thomas
I'll keep looking perhaps tomorrow. Hopefully
this is due to a stupid mistake on my part.
No I think you are right (we are both right :). There is a problem
when using Internet Explorer. IE must be making rather different
socket calls than FireFox. That seems quite odd to me.
Using IE, the problem seems to intermittant. It works for a while
with some urls and not others.
Does this mean that there are some errors that are 100% reproducible?
If so, start with those.
Post by Bill Page
Here is a typical failed test using IE.
---------
$ saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 May 4 2005 16:56:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Post by Mike Thomas
(load "test-http2.lsp")
Loading test-http2.lsp
----------
Then using Microsoft Explorer 6 sp2 and url
http://localhost:8085/msys/1.0/
----------
get GET fn /msys/1.0/ dn /msys/1.0/
Error: error writing to socket: errno= 22
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by FORMAT.
Broken at FORMAT. Type :H for Help.
Post by Mike Thomas
Post by Camm Maguire
(si::use-fast-links nil)
NIL
Post by Mike Thomas
Post by Camm Maguire
:bt
IE appears to be closing the socket before your write completes. The
odd thing is that you report that it is intermittent. There are two
possibiities that come to mind -- either ie insists on a complete set
of html headers from the server, or there is a timeout issue. You
need to do (si::use-fast-links nil) before the error, btw. There may
also be a carriage return/line feed problem, i.e. ie could insist that
all newlines be preceeded by carriage returns. Forget the lisp
sequence for cr's, but the docs should reveal it. Does ie appear to
still be waiting for input when the error triggers? Lastly, you could
try reproducing the error with the little utility 'netcat' listening
on the port, and typing the same text in once the connection is made.
I suppose if we cannot reproduce with this, then there must be some
other incompatible socket type/protocol (i.e. 'embrace and extend')
that ie is expecting in this case. Another idea is to fire up the
server on a Linux box on the same net and try to reproduce. IE might
treat foreign sockets in the standard way, but local sockets
proprietarily.

Of course, we could just use firefox for axiom, which would avoid
any other browser incompatibilities too.
Post by Bill Page
#0 FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a
href=\"~a\">~a</a> <a href=\"~a/\"> /....} [ihs=19]
#1 FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a
href=\"~a\">~a</a> <a href=\"~a/\"> /....} [ihs=18]
#2 FOO {} [ihs=13]
#3 BAR {lambda-block=foo,} [ihs=8]
#4 LOAD {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
...),loc4=8085,loc5=(l...} [ihs=7]
#5 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function
load>,loc4=#p"test-http2.ls...} [ihs=6]
#6 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="C:/msys/1.0/ho...}
[ihs=5]
#7 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
--------------
Does this back trace help to see what's going wrong?
$ saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 May 4 2005 16:56:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Post by Mike Thomas
(load "test-http2.lsp")
Loading test-http2.lsp
get GET fn /msys/1.0/ dn /msys/1.0/
get GET fn /favicon.ico dn /favicon.ico/
--------
And the list directories appears in the browser.
Let me know what I can try next.
Regards,
Bill Page.
Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2005-05-05 17:43:55 UTC
Permalink
Post by Camm Maguire
Post by Bill Page
Using IE, the problem seems to intermittant. It works for a while
with some urls and not others.
Does this mean that there are some errors that are 100% reproducible?
If so, start with those.
Yes.
Post by Camm Maguire
IE appears to be closing the socket before your write completes. The
odd thing is that you report that it is intermittent. There are two
possibiities that come to mind -- either ie insists on a complete set
of html headers from the server, or there is a timeout issue.
Ok, problem solved (I think). It turned out not to be so exotic an issue.
I modified the web server program as follows:

- (format s "HTTP/1.1 ~S~%" (if fn 404 500))
+ (format s "HTTP/1.1 ~S~%" (if fn 200 404 ))

If I understand HTTP correctly "404" in the header means "file not found".
"200" means "ok". "500" means server error. So we were both saying
"file not found" but then delivering the file anyway. If that's the case
then it is surprizing that FireFox worked and not surprizing that IE closes
the socket connection before we can send the file.

With this change both FireFox and IE now seem to work reliable
and identically for me.

Anyway, I will take a closer look at the HTTP standard to make sure
that our headers are correct and complete.

Regards,
Bill Page.
Camm Maguire
2005-05-05 18:35:54 UTC
Permalink
Greetings!
Post by Bill Page
Post by Camm Maguire
Post by Bill Page
Using IE, the problem seems to intermittant. It works for a while
with some urls and not others.
Does this mean that there are some errors that are 100% reproducible?
If so, start with those.
Yes.
Post by Camm Maguire
IE appears to be closing the socket before your write completes. The
odd thing is that you report that it is intermittent. There are two
possibiities that come to mind -- either ie insists on a complete set
of html headers from the server, or there is a timeout issue.
Ok, problem solved (I think). It turned out not to be so exotic an issue.
- (format s "HTTP/1.1 ~S~%" (if fn 404 500))
+ (format s "HTTP/1.1 ~S~%" (if fn 200 404 ))
Thanks! This is just what we need -- an html guy!

BTW, misspoke earlier re: suggested edit to #"foo. What I meant was:

(defun foo (s)
(let* ((get (read s nil 'eof))
(fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
(file (probe-file fn)))

(format s "HTTP/1.1 ~S~%" (if fn 200 404))
(format s "Content-type: text/html~%~%")

(if file
(with-open-file (q file) (si::copy-stream q s))
(let ((dir (directory (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))))
(dolist (l dir)
(let ((n (namestring l)))
(format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
(close s)))

which should function the same as what you have but express the
precedence better. This counts on probe-file returning nil for
directories.

Take care,
Post by Bill Page
If I understand HTTP correctly "404" in the header means "file not found".
"200" means "ok". "500" means server error. So we were both saying
"file not found" but then delivering the file anyway. If that's the case
then it is surprizing that FireFox worked and not surprizing that IE closes
the socket connection before we can send the file.
With this change both FireFox and IE now seem to work reliable
and identically for me.
Anyway, I will take a closer look at the HTTP standard to make sure
that our headers are correct and complete.
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2005-05-06 13:28:47 UTC
Permalink
Post by Camm Maguire
Post by Bill Page
Ok, problem solved (I think). It turned out not to be so exotic an issue.
- (format s "HTTP/1.1 ~S~%" (if fn 404 500))
+ (format s "HTTP/1.1 ~S~%" (if fn 200 404 ))
Thanks! This is just what we need -- an html guy!
Well, ah ...
Post by Camm Maguire
Post by Bill Page
If I understand HTTP correctly "404" in the header means "file not found".
"200" means "ok". "500" means server error. So we were both saying
"file not found" but then delivering the file anyway. If that's the case
then it is surprizing that FireFox worked and not surprizing that IE closes
the socket connection before we can send the file.
With this change both FireFox and IE now seem to work reliable
and identically for me.
Anyway, I will take a closer look at the HTTP standard to make sure
that our headers are correct and complete.
For quick reference here is a very easy introdution to HTTP:

http://www.jmarshall.com/easy/http


HTTP Made Really Easy


A Practical Guide to Writing Clients and Servers

--------

Bill Page.

Camm Maguire
2005-05-05 14:25:45 UTC
Permalink
Greetings!
Post by Mike Thomas
Hi Bill/Camm.
| >OK, I've just tested on Linux under ANSI, and it works the same for
| >me (as it should). If this is not the case on Windows, please someone
| >let me know asap.
| >
| >
| Perhaps Mike's test demonstrates that this is not working on the
| Windows ANSI version, but it works fine for me on Windows XP
| with the non-ANSI version.
I just tried the CLtL1 build - no joy.
OK, at least we have some consistency.
Post by Mike Thomas
There are definite problems with the new code as socket variables should be
defined with SOCKET (an unsigned int) rather than int and the error return
values on Windows are not the same as on BSD systems however I just tried to
eliminate those problems and still have the same trouble.
This could be the problem, but I'd be skeptical, as you had success
earlier. The accept error message reports the C strerror string,
which was "No such file ..." I think this is the first of the
following errors, whatever mingw's numbering system could be:

ERRORS
EAGAIN or EWOULDBLOCK
The socket is marked non-blocking and no connec-
tions are present to be accepted.

EBADF The descriptor is invalid.

ENOTSOCK
The descriptor references a file, not a socket.

EOPNOTSUPP
The referenced socket is not of type SOCK_STREAM.

EFAULT The addr parameter is not in a writable part of the
user address space.

EPERM Firewall rules forbid connection.

ENOBUFS, ENOMEM
Not enough free memory. This often means that the
memory allocation is limited by the socket buffer
limits, not by the system memory.



Sounds to me that #'listen is returning T before a connection is
present, i.e. the select code we've added there might not be working
for you. Just an idea.
Post by Mike Thomas
I'm using Internet Explorer. I'll keep looking perhaps tomorrow. Hopefully
this is due to a stupid mistake on my part.
Might want to start with telnet for simplicity. Might want to break
in gdb at the select in #'listen, and see if it is working, and if so,
whether it is accept that fails for some other reason.

Take care,
Post by Mike Thomas
Cheers
Mike Thomas.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Mike Thomas
2005-05-05 22:53:58 UTC
Permalink
Hi Camm/Bill.

Positive results on some basic tests per Cam's directory fix yesterday.

| > >(probe-file "/msys/1.0")
| >
| > #p"c:/msys/1.0"
| >
| > >(probe-file "/msys/1.0/")
| >
| > #p"c:/msys/1.0/"
| >
| > >(probe-file "c:/msys/1.0/")
| >
| > #p"c:/msys/1.0/"
| >
| > >(probe-file "c:/msys/1.0")
| >
| > #p"c:/msys/1.0"
| >
|
| With the commits to 2.6.7pre I made yesterday, all these probe-files
| to directories should return nil.
(probe-file "/msys/1.0")
NIL
(probe-file "c:/msys/1.0")
NIL
(probe-file "c:/msys/1.0/msys.bat")
#p"c:/msys/1.0/msys.bat"
(probe-file "c:/msys/1.0/")
NIL



| > >(bar 8085 #'foo)
| >
| > Error in LET [or a callee]: Error "No such file or directory"
| on accepting
| > conne
| > ction to #<two-way stream 104c969c>
| >
|
| At least on Linux, accept might fail with a EAGAIN or similar if no
| connections are pending. It is critical to this example that the call
| to #'listen in #'bar correctly return t iff a connection has been
| made. You can test this with telnet from a separate shell window.
| I.e.
|
| (setq s (si::socket 8085 :server #'foo))
| (listen s) -> nil (no telnet localhost 8085)
| (listen s) -> t (after telnet localhost 8085)

Using the local current state of the Windows socket code as I have no time
to revert to the original state (ie these tests after I fixed the winsock
return values and types; day of meetings ahead) these two tests work OK.

I probably won't have time to insert these patches (below) into CVS today
but hopefully over the weekend although I'm looking rather tight there too
at present.


cvs diff: Diffing o
Index: o/file.d
===================================================================
RCS file: /cvsroot/gcl/gcl/o/file.d,v
retrieving revision 1.21.4.1.2.8.10.5
diff -r1.21.4.1.2.8.10.5 file.d
2245a2246,2248
#ifdef _WIN32
SOCKET fd;
#else
2246a2250
#endif
2254c2258,2262
< if (fd < 0 )
---
#ifdef _WIN32
if ( INVALID_SOCKET == fd )
#else
if ( fd < 0 )
#endif
2290c2298,2303
< int fd,n;
---
#ifdef _WIN32
SOCKET fd;
#else
int fd;
#endif
int n;
2299c2312,2316
< if (fd <0) {
---
#ifdef _WIN32
if ( INVALID_SOCKET == fd ) {
#else
if ( fd < 0 ) {
#endif
2338a2356,2358
#ifdef _WIN32
SOCKET fd;
#else
2339a2360
#endif
2470c2491,2495
<
---
#ifdef _WIN32
if ( INVALID_SOCKET == fd ) {
FEerror("CreateSocket returned an invalid socket", 0);
}
#endif
Index: o/mingwin.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/mingwin.c,v
retrieving revision 1.8.6.3.2.1
diff -r1.8.6.3.2.1 mingwin.c
406c406
< int
---
SOCKET
432c432
< return -1;
---
return INVALID_SOCKET;
562c562
< return -1;
---
return INVALID_SOCKET;
***@WATER /c/cvs/stable/gcl-2.6.7pre
$ export CVS_RSH=ssh; cvs diff h
Enter passphrase for key '/home/miketh/.ssh/id_dsa':
? h/cmpinclude.h
? h/config.h
? h/gclincl.h
? h/new_decl.h
cvs diff: Diffing h
Index: h/protoize.h
===================================================================
RCS file: /cvsroot/gcl/gcl/h/protoize.h,v
retrieving revision 1.26.4.1.2.1.2.11.6.1.6.1.2.3
diff -r1.26.4.1.2.1.2.11.6.1.6.1.2.3 protoize.h
319a320,322
#ifdef _WIN32
/* mingwin.c:190:OF */ extern unsigned int CreateSocket (int port, char
*hos
int server, char *myaddr, int myport, int async); /* (port, host, server,
mya
r, myport, async) int port; char *host; int server; char *myaddr; int
myport;
t async; */
#else
320a324
#endif
Loading...