From hatchond at labri.fr  Fri Aug 20 22:02:57 2004
From: hatchond at labri.fr (Iban Hatchondo)
Date: Sat, 21 Aug 2004 00:02:57 +0200
Subject: [eclipse-devel] Re: eclipse installation feedback
In-Reply-To: <87hdqxej2v.fsf@no-rom-basic.office.uk.clara.net>
References: <87hdqxej2v.fsf@no-rom-basic.office.uk.clara.net>
Message-ID: <41267511.9050906@labri.fr>

Daniel Barlow wrote:
> Robert Strandh has recently been on my case about documentation (or at
> least, it feels like it) so I thought I'd spread the pain around a
> little.  This is a rant.
> 
> I recently tried to install Eclipse, on a reasonably up-to-date Debian
> Linux box with SBCL 0.8.13.  I'm being discouraged by the 'fool-proof'
> installation that attempts to make Eclipse look just like an ordinary
> C program (because it doesn't work, for one thing) and if I can
> extrapolate from my experiences to other Lisp hackers then I think
> you're losing out on possible help for the project.  I suggest you'd
> be better off making it look more like a "normal" Lisp project with a
> defsystem of some kind (of course, I prefer asdf); spend more effort on the
> actual coding and less on the installomatic cruft

Well, I guess you're right on some point. Maybe Eclipse should then 
propose two compile+install methods ? One with a "? la" C program with 
the Makefile and a second one with the asdf/defsystem. In fact its 
already the case. In an hidden way I confess, but the asdf system and 
the mk-defsystem both exist. If you make a symbolic link from 
system.lisp to system.asd then you should (It used to work) be able to 
simply do a (require :eclipse) from sbcl.

> 1) there are two places where the code doesn't compile because you've
>    created local functions FIRST and FIND with the same name as
>    standard symbols.  That was easy (for a Lisp hacker; anyone who
>    needed the ./configure;make script would probably have been
>    discouraged already), so diff attached.

Ok. I never though the compiler could complain for that since it is 
local function definitions, but you're right, I will apply this part of 
your patch asap.

> 2) the documentation doesn't cover how to start eclipse once the build
>    has dumped a custom core.  I know enough about SBCL to run 
>    "sbcl --core /usr/local/src/eclipse/eclipse.core", but intuiting
>    the correct function to call after that is beyond me - I had to
>    look in the "eclipse" shell script to figure it out.

! oops. Ok, I/we have to document this.

> 3) every error thereafter makes the entire lisp quit.  This is Rude.
>    I accept that it's what non-Lispers are used to, but there are
>    better ways of giving them the brain-damage they deserve than by
>    denying potential contributors the ability to get into the debugger.

I know. it was my dilema. But th default config file should not raise 
error ! I'll try to investigate.

>    I would suggest that you remove all calls to %QUIT% from the ECLIPSE
>    function and anything that it calls, then add a new function called, 
>    say, ECLIPSE-OR-DIE
> 
> (defun eclipse-or-die (&rest args)
>    (handler-case (apply #'eclipse args)
>       (error (c) 
>         (format t "~a~%" condition) 
>         (%quit%))))
> 
>    which is only called when eclipse is started from the shell script

I like this idea. What's other opinion on that point ? If nobidy 
complain then I could apply Dan's patch on that point too ?

> 4) Even having removed the obvious call to %quit%, I find that
>    load-config-file has an ignore-errors clause.  If there is an error
>    in my config file (in fact I haven't even touched the confing file;
>    there's an error in the /default/ config file) I would rather be
>    able to debug it - with the aid of the debugger - than receive a
>    really rather uninformative error message with no potential for
>    further diagnosis.
> 
>    Having removed that ignore-errors I can see what's actually wrong
>    with the init file (remember, this is your init file, not mine; I
>    can'r even rely on the usual Unix strategy of "the error must be in
>    the last thing you changed", as i haven't changed anything yet)
> 
> The value #(0 0 0 0 0 0 0 0 0 0 ...)
> is not of type
>   (SIMPLE-ARRAY (UNSIGNED-BYTE 32) (*)).
>    [Condition of type TYPE-ERROR]
> 
> from PPM:IMAGE->CLX-IMAGE
> 
> I haven't looked at this too hard, but the problem seems to be the
> `of-type clx-array' clause for `res' in that function.  I removed that
> clause and now it's happy again.  

I am surprised. I'll try to look at it.

> 5) In 
>       (setf ...
> 	    *background1* (xlib:alloc-color colormap *background1*)
> 	    *background2* (xlib:alloc-color colormap *background2*)	    
> 
> xlib:alloc-color returns a number as its primary value, so on every
> run after the first this complains that
> 
> The value 52857 is not of type (OR (VECTOR NIL) BASE-STRING SYMBOL XLIB:COLOR).
> 
> I work around this by running
> (setf *background1* (xlib:make-color :red 0.8 :blue 0.8 :green 0.8))
> (setf *background2* (xlib:make-color :red 0.85 :blue 0.85 :green 0.85))
> 
> between each run.  I would suggest that you don't use the same global
> variable both for the COLOR object used as argument and the id
> returned by ALLOC-COLOR

True. I'll see how I can change this nicely.

> 6) Now I get 
> Condition ALREADY-HANDLED-XERROR was signalled.
>    [Condition of type ALREADY-HANDLED-XERROR]
> 
> which apparently is due to a previous
> X error CURSOR-ERROR with id
> => ASYNCHRONOUS T CURRENT-SEQUENCE 1351 RESOURCE-ID 2097156 MAJOR 2 MINOR 0 SEQUENCE 1350 
> 
> but GUESS WHAT?  I can't GET to that previous error to debug it,
> because you've surrounded it with more of this condition catching
> cruft to get in my way.  Why are you so determined not to let anyone
> debug your program?

Well kind of :). The thing is that in this particular case of error you 
have no chance to backtrace it: Indeed an _asynchronous_ X error, is 
relative to any request you made to the server and that is replyed now. 
So backtracing such errors will just tell you that it happens after some 
internal clx reply-buffer decoding.

The only X errors that are important for us are those that point out 
"dead" X resources your trying to use and that should just be removed 
from internal cache. Most of the non asynchronous are just a response to 
some requests you made on a destroyed resource, and so are "ignorable". 
I just print them in case it could shows some really wrong behavior of 
Eclipse.

So now if you want to be dropped in the debugger on any X error then you 
may need to prepare yourself to lost all your windows and to not be able 
to retreive them. For the same reason other errors are handled that way.

Plus when an X error is handled it is expected by CLX that the handler 
doesn't decline. For that reason they are signaled in my handler.

> Here is my patch.  I'm not suggesting you should apply it wholesale,
> but I'd be far more likely to use (and hack on) eclipse if it were a
> bit more welcoming and a bit less black box, so I'd really welcome it
> if you were to consider the issues raised.  For the moment, I'm going
> home instead.

Well, I'll be really happy to make it a bit less black box but I really 
don't know how to handle the error problem. All advices are welcomed.
Furthermore, I would be great if someone could help me on the 
documentation. I am currently completly out of time, so any help is welcome.

Thanks for all your comments.

Iban.