update of jed-extra

G. Milde g.milde@web.de
Mon, 11 Jul 2005 10:16:06 +0200


On  8.07.05, Jörg Sommer wrote:
> G. Milde schrieb am Thu 07. Jul, 11:36 (+0200):
> > On  6.07.05, Jörg Sommer wrote:
> > > G. Milde schrieb am Wed 06. Jul, 12:39 (+0200):
> > 
> > Preparsing files is a sensible default. If a file poses a problem, the
> > admin could set it on the exclusion list in jed.conf.
> 
> Do you mean, we should not give the admin the option to preparse or not?

No other than a custom variable for an exclusion list. Checked in
byte_compile_libdir(). Used for the problematic cases mentioned below.

> we should do it? Mmmh, are there any disadvantages of preparsing?

You loose the ability to do runtime decisions with preprocessor
directives like #ifdef or #ifexists, e.g.

 #ifnexists foo
   define foo() {message("foo");}
 #endif

or

 #ifdef XWINDOWS
   require ("cuamouse");              % CUA consistent mouse behaviour
   set_color_scheme ("yellow");
 #else
   set_color_scheme ("light-terminal-default");
 #endif
 
(I moved the latter example to my .jedrc which is not preparsed by
default.)
  


> > > > The "compile" script should
> > > >     * delete all *.slc files in site-lib and jed-init.d
> > > ...that it build before.
> > OK, the algorithm to find related *.slc files from *.sl files is easy,
> > isn't it?
> 
> You can tell it me? 

define find_slc_path(path)
{
   return path + "c";
}   

> I don't know how to find dfa cache files, whose name
> is set inside a SLang file.

This is a different problem, you could only grep in the SLang files.

However, both, slc files and dfa files are actually just "secondary" 
(temporary) files. A purist would place them under /var/. Is there a way
to tell dpkg that *.dfa files are of no special importance and can be
savely removed when removing the containign dir?

 
> > I see. So de-installation of jed-common should take care of removing
> > *.slc files?
> Yes.
Agreed. 


> > > > jed.conf should
> > > > 
> > > >   register_libdir(site-lib);
> > > >   % run the scripts in jed-init.d (might register more libraries)
> > > >   register_libdir(home-lib, local-lib);
> > > 
> > > But if a site admin decide to use a patched version of a file used in
> > > jed-init.d is version get not recognized. 
> > Do you mean: if a file in jed-init.d should use a file in local-lib or
> > home-lib instead of site-lib?
> Yes.
> 
> > Well, this is the prize we have to pay if we want packages to be able
> > to register their own libdirs. Otherwise this libdirs would take
> > precedence over local-lib and home-lib.
> 
> Why? If we register local-lib and home-lib in 30XX.sl it is still
> possible to register some mode, they can be overwritten in >30XX.sl

With this scheme, we had in jed-init.d

   00XX.sl        % files that might register package libraries
   ...
   29XX.sl
   30home-lib.sl  % register local-lib and home-lib
   31XX.sl        % files that can easily use modes from local-lib and
   ...            % home-lib but not register package libraries
   99XX.sl	  
   
I do not see the need for files >30XX.sl. Debian packages should not need
to use home-lib or local-lib. The sysadmin can put the configuration in
jed.conf instead.

Günter 
   

-- 
G.Milde web.de