[Cuis] Cuis base image reduced by 25%!

[Phil (list)]

Juan,

On Jun 25, 2013, at 11:37 PM, Juan Vuletich 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
> 

That sounds fantastic!

> 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.
> 
> 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.
> 

While the purist in me would probably say have nothing preloaded,  as a practical matter this might make it more difficult for newbies to get going with Cuis and even experienced users who don't want or care about an absolutely minimal image.  As long as it's easy to unload packages, it might make sense to keep them preloaded and let those who are interested (me! me! :-) unload what they don't need.

I'd also love to see Cuis move towards Casey's content pack idea with a twist: why restrict it to just sounds?  Why not have all binary assets (sound, images, whatever) broken out into content packs as appropriate?  Longer term, you could also go a step further and rather than base64 encoding them, just load them from the binary .wav (or whatever native file) instead of baking into the source.  There would seem to be some serious advantages to that extra step but it would also create some more work so I'm just throwing it out there as longer-term food for thought.

> 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 , 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...

Just to keep it simple, a single repo for the Cuis 'core' (whatever that ends up being defined as) seems to make sense, regardless of what package things gets put into.  Even if there end up being different maintainers of the various modules, Git makes that pretty easy to deal with without requiring multiple repos.

> 
> After all this, 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.
> 
> Let's discuss and think of better ways to manage the Cuis codebase.

Related to your multi-repo suggestion, I'm with Frank in thinking that dev/stable probably belong in the same repo as different branches as that's how most other projects handle it.  Historic seems to make more sense as a separate repo as that would just be a point in time snapshot of an image built from the main repo and would potentially appeal to a different subset of users.

> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Thanks,
Phil