[Cuis] Cuis base image reduced by 25%!

[Angel Java Lopez]

Great news!

Before I forgot to mention...

I'm started to use npm (from node.js, node package manager) to manage a
project dependencies, in AjTalk, Mass, AjGenesis, RunIt.

That is: you can publish a directory to npm, with .st or whatever (I asked
in npm mailing list and it's OK, they accept not node-related package)

Each publish package has a .json describing its dependencies (including
versions).

A project can have a .json describing its dependencies too.

So, any Cuis/AjTalk/whatever project can have a package.json at project
directory, and the only thing to do is:

npm install

and voila!

In AjTalk, I adopted the module pattern, so if a module A needs B at 0.1.0, it
can be loaded, and if module C needs B at 0.2.0, then the other version is
loaded. See npm/node for more detailed explanation. Some ideas at:
http://ajlopez.wordpress.com/2012/12/26/ajtalk-in-c-3-environments/

Angel "Java" Lopez
@ajlopez
gh:ajlopez



On Wed, Jun 26, 2013 at 12:37 AM, 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
>
> 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.
>
> 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...
>
> 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.
>
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130626/96c2796a/attachment-0004.html>