Re: isetl developments and updates

[jim@mercury.laney.edu]

Hi,

> Date:    Sun, 18 Jul 1999 01:35:44 EDT
> To:      seul-edu@seul.org
> From:    Jan Hlavacek <lahvak@math.ohio-state.edu>
> Subject: Re: isetl developments and updates
> 
> On Tue, Jul 13, 1999 at 12:03:19AM -0700, jim@mercury.laney.edu wrote:
> > OK, in other news, I have tried my build of isetl, having become familiar
> > a bit with the language. EVERYTHING I tried works fine! The only problem
> > is the interface, which just looks wrong. Works good, looks bad.
> > 
> > I get the feeling that isetl might be able to draw pictures; I am
> > currently considering that a wild unsubstantiated rumor :) So, isetl
> > as I have built it is text-only.
> 
> DOS, Mac, and windoze versions do have graphics, Unix version never did.
> I had some serious trouble with windoze graphics last year, when I tried
> it, but Ed Dobinsky claims that it must be a problem with my windows
> instalation. 

You think he might be willing to watch/help?? :) Does he have linux?
What about David Mathews? The machine where his web page was supposed
to be does not resolve from domain name to IP address (i.e., it's an
unknown name). Do you think Ed might be able to ask David for where his
web page moved to?

> It's possible, my windoze are all f@#$ed up.  I deleted
> lot of stuff which I probably should have kept.  But anything else I
> tried works.  Graphics is one of the things that will have to be done.
> It shouldn't be that hard, graphics in isetl is very simple, from what I
> saw in textbooks, you have to draw coordinate axis and points on the
> plane.  The idea is that you don't connect the dots when drawing graphs.
> The program should not pretend to do more than it really does, if you
> know what I mean.  

Hmmm,,, had you ever worked on the graphics? Maybe I should learn gtk++
later this year or next.

> > The original problem was it kept segfaulting in the function cbreak(),
> > a libcurses command that changes how keyboard input works. I added
> > code to initialize curses and code to undo the effect of initializing
> > curses for when the user wants out of isetl.
> 
> Yes, I remember that when I was compiling isetl on solaris, I had to fix
> this, too.  That was about 1.5 years ago.
> 
> > I was also very interested in making isetl rock solid, and having the 
> > compiler help me do that. I noticed that improvement in this area was
> > possible when I noticed that all the function definitions did not tell
> > the compiler the types of arguments, so I altered a lot of them so that
> > they would. Doing so would ensure that argument data is lined up properly
> > so that the function would look in the exact right places on the stack
> > for it.
> 
> That's great.  I think that it also improves the readability of the
> source.

I'll finish the solidifying work soon. Then, the resulting version will
REQUIRE a compiler with function prototypes, since they will be used in
each func definition. Maybe we should look into autoconf if we want auto-
matic portability.
 
> Anyway, I tried to compile your version on solaris with gcc, worked
> fine, now I have two isetls, both seem to be working the same.  I didn't
> do any extensive testing, but the test I did worked fine on both.  Your
> version is probably more stable, you did much more work on it than I.

GOOD! that tells us something... Yes, I didn't change anything of any
application significance.

> > YES, let's contact them, but remember, while the interpreter IS
> > working, it's not ready for much more than an evaluation.
> 
> My reason for contacting them was mostly to figure out the differences
> and improvements from isetl 3.0 (DOS, Mac, Unix) to ISETLW.  I think
> they did some improvements in the interpreter, but I don't know exactly
> what.

maybe we should continue to dig into that, and find out how portable it is.
Interpreter improvements? Hmmm, maybe we have to treat this as if it were
a totally separate app from 3.0.

> > So let's ask them for updated information on the C4L project, and suggest
> > they update their web pages. And let's let them know that isetl is close
> > to being ready for linux.
> 
> That sounds like a good idea.

Who would like to make contact?

> > I'm not sure my stuff will compile on solaris... On the other hand,
> > I'm also not sure the curses stuff won't be better either. If that's
> > the case, it means the curses libraries are somewhat different. As far
> > as I can see, curses support just wasn't completed.  
> 
> Se above.  It compiles with gcc, and the curses support doesn't work any
> better on solaris.  That part of code will definitely need some more
> work.  I think that two main parts that need improvement are the
> interface and graphics.  As for the interface, the DOS version uses some
> weird line editor (the only part of isetl that's not free software,
> AFAIK).  I don't know if unix version uses it, I don't think so.  Maybe
> that could be replaced with gnu readline?  We would have to look at the
> textbooks, if they make any reference to the editor, and how do they use
> its features (mostly history editing, as far as I can tell).  Gnu
> readline is fairly flexible, we may be able to do something with it.

Graphics would be nice, so would libreadline with a history file.
I wonder if curses can be done away with if libreadline is used?
Probably the only reason to use it is to get rid of line buffering
so the editor would work. If you concur, maybe we try that.

[...]
> > plan to run thru it again, this time encapsulating my changes into
> > #ifdef linux .... #endif directives.
> 
> I wouldn't use `linux', unless you do something really linux specific.
> Maybe use `gcc' instead?

Maybe UNIX then, or POSIX since it works on solaris

-Jim

---
Jim Lynch       Finger for pgp key
as Laney College CIS admin:  jim@laney.edu   http://www.laney.edu/~jim/
as Debian developer:         jwl@debian.org  http://www.debian.org/~jwl/