Re: [Jython-dev] poor man freezing and loading from other sources: proposals and ideas

[<bc...@wo...>]

On Wed, 21 Mar 2001 15:44:02 +0100 (MET), you wrote:

>> ... It's just that I can already hear the
>> complaints that jython can't load java class: "I know the classloader
>> works because I can load classes from java". It is painfull that the
>> complaint is actually valid.
>> 
>> Maybe a different worded ImportError should be printed when
>> sys.classLoader is set.
>I can hear them too <wink>, once I imagined the following ?ugly? solution
>(but no import * or dir) that technically means having the packageManager
>existsPacakage return always true <wink>. Not a good default but as special
>option ...

I suppose it would silence a lot of the valid complaints. It would make
debugging a erroneous setup more difficult and it feels somewhat
unpythonic: "Errors should never pass silently".

I can't think of a good way of enabling this right now, but as a special
option it is worth remembering.

>> >To be honest this one  is the more complicated of the proposed changes,
>> >here some concrete ideas:
>> >
>> >0. have a tool to "index" a jar in a way that supports dir (maybe the same
>> >  as above under different options)
>> 
>> I believe that a .jar should only be scanned once. That means that if
>> the scan result isn't cached we should reject un-indexed jars. Why don't
>> you want to cache the scan result?
>> 
>> All in all this is my favorite.
>Having the tool? caching things?

I don't mind caching the scan result, but if we decide that we shouldn't
cache it, a tool that stores the scan result inside the jar is just as
good IMO.

Rescanning for every session is wrong. I can't remember any complains
about the initial scanning of jars but it is unacceptable to do it every
time.

>I would cache things per session but not across sessions. The problem is that
>we never cleanup the global cache and this is absolute-path based, for trying
>an api once that then is maybe discarded this is bad, for things moving around
>the file-system is bad too, it's ok for jdk libraries or extension or ...

I just checked my cachedir/packages directory. It only contained 290Kb.
Even the 13Mb rt.jar only takes up 45Kb of index. I don't mind that the
cache can accumulate old crud. A user can delete it whenever she wants
without severe side effects.

>> >c. the overkill solution [maybe not that much but implies that we must live
>> >   forever with the following CPython incompatibility (which is quite marginal):
>> >      L=UserList.UserList()
>> >      sys.path=L
>> >   works in CPython but not in Jython, for c) we will have to even enforce this]
>> >   add to builtin lists the possibility to have an observer (it costs
>> >   the comparision between a ref and a null on every update method)
>> >   that is notified for changes, so we can open, scan and close things
>> >   on sys.path changes. Why every list? to make rare things work:
>> >      L=['.','foodir']
>> >      sys.path=L
>> >      L.append('bazdir')
>> >   When a list is assigned to sys.path its observer field is assigned,
>> >   the field of the old one is reset...
>> 
>...
>> 
>> Or wrap the list 'L' above with an observable wrapper that intercepts
>> __XXXitem__ calls. That would close the archive immeditatly but cause
>> the value returned by 'sys.path' to be different from the value
>> assigned. My favorite solution.
>Ok for me but the example above that modifies sys.path trough L will not work (?)

ohh right. No it won't work. My bad.

regards,
finn