Re: [isabelle] Disk usage in ~/.isabelle/contrib



I always carry a large bag of workarounds and little hope of upstream
changes. So while your question awaits a more comprehensive answer, some
observations:

- you can delete the .tar.gz files in contrib, they don't get
  re-downloaded as long as the component itself exists
- inside the jdk directories, you can delete the platforms you don't
  need; e.g. jdk-8u72 is 1.4GB, but its x86_64-linux dir is only 353MB
- everything else doesn't occupy much space - closest candidate is
  polyml weighing in at a whopping 83MB

The above can be written into a script, although since component updates
happen about twice a year I haven't bothered. On that note, could you
send me your isabelle components mirror fallback mod?

Raf.

On 07/02/16 22:33, Matthew Fernandez wrote:
> Hi all,
> 
> The latest candidates for the upcoming Isabelle release contain some
> changes to reduce disk usage of heap images. So I
> thought it might be a good time to ask other disk usage related
> questions. None of the below is intended to be
> interpreted as a request for changes to the upcoming release; just
> questions seeking clarification.
> 
> When Isabelle detects that it is missing a component (Poly/ML, JDK,
> etc.) it fetches a tarball of this to
> ~/.isabelle/contrib and then decompresses it here. Each tarball contains
> necessary files for all supported platforms.
> I.e. in the extreme, a component like Poly/ML contains subdirectories
> for 32-bit Linux, 64-bit Linux, 32-bit Mac OS,
> 64-bit Mac OS and 32-bit Cygwin. My question is, why is Isabelle
> fetching all these things that will remain unused on my
> platform? Is this the result of a "disk space and bandwidth are free"
> mode of thought? Or a decision made for ease of
> packaging? None of this is meant as a criticism, I would just like to
> understand the motivation(s).
> 
> My interest is driven by one of my machines where disk space *is* an
> issue. A quick scan of ~/isabelle/contrib reveals
> 2.7GB of files I could easily do without. A minimal first step to
> reducing this in future would seem to be to download
> the tarballs to a temporary location, then delete them after
> decompressing. Is there a need for them to persist? Perhaps
> there are some deeper issues I'm not aware of here.
> 
> Thanks,
> Matt
> 
> ________________________________
> 
> The information in this e-mail may be confidential and subject to legal
> professional privilege and/or copyright. National ICT Australia Limited
> accepts no liability for any damage caused by this email or its
> attachments.
> 




This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.