[Cuis] Cuis base image reduced by 25%!

[Casey Ransberger]

Inline


On Tue, Jun 25, 2013 at 8:37 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
>
> A few days ago I started playing with the idea of extracting non-essential
> functionality into .pck.st files. The result is that I could reduce Cuis
> by about 25%. Now it is below 500 classes and below 100kLOC :) . The new
> packages are:
>
> - Compression
> - Graphic-Files-Additional (only png and tiff, as bmp and jpg are in the
> base image)
> - Sound
> - Theme-Themes (Only the default class Theme is included in the base image)
> - Network-Kernel
> - LinearAlgebra
> - Test
>

I had a feeling this would happen. Not bad. How are sounds represented in
the source, are they base-64 encoded? It might be good to have the actual
sounds in a content pack, partly because I've wanted to replace them for
some time, and just got ahold of a digital audio workstation (weeeeeeeee!)


> If you update your image, all this code will be removed. If you download
> the updated image, it is no longer there. The packages themselves are also
> available at github, together with a txt file with a possible load order. I
> hope you'll find this more convenient when contributing code.
>

I'd put the tests back in for our development image. They don't necessarily
need to live in "release" images though. If we're still thinking of making
such a distinction. I think it's been talked about. Not having them
resident without going through an extra step will probably mean (path of
least resistance) almost no one will run them. I should get CI working one
of these days and take some of the burden of running tests off of human
shoulders.


> There are several open questions, and I ask for your opinions and thoughts.
>
> 1) The "official" Cuis image can have none/some/all of these preloaded. We
> need to allow for clean unload of packages, but if there are no overrides,
> I think it is not a big deal. I'm not sure what's best. Maybe all these
> packages (and maybe others) should be preloaded by default.
>

I like the full image + minimal dev image with tests idea. But we should
have CI before we start juggling two images so we know when loading a
package or not loading a package causes problems IMHO.


> 2) I'm starting to believe that it is best to have those packages that are
> kept up to date in the same git repo as the base image. This will make it
> very easy to know what is the proper snapshot of some package to be used
> with a particular Cuis update level. Besides, it makes sense to have a
> Cuis-Smalltalk organization. Therefore I created https://github.com/Cuis-*
> *Smalltalk <https://github.com/Cuis-Smalltalk> , although I haven't saved
> anything there yet. I'd like to discuss with you the repositories to keep
> and their structure. I think that we might store there those packages that
> are preloaded, and those that are well maintained and actually used. But on
> the other hand, folks wanting to have better control of their code might
> prefer to host them in their own repositories...
>

Yes, definitely.


> After all this, https://github.com/jvuletich/**Cuis<https://github.com/jvuletich/Cuis>should be deleted or marked as historic.
>
> BTW, there are a few other fixes and enhancements in this last batch of
> updates. #reduceCuis now produces a 3.6Mb image with less than 80kLOC.
> Another tweak was to no longer kill the active changeset on image save. I
> hope this fits people who usually save the dev image at the end of the day.
>

Sweet!


> Let's discuss and think of better ways to manage the Cuis codebase.
>
> Cheers,
> Juan Vuletich
>
> ______________________________**_________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>



-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130627/9e2dc423/attachment-0003.html>