[squeak-dev] Re: SecureSqueak and packages
Michael van der Gulik
mikevdg at gmail.com
Tue Apr 17 21:04:00 UTC 2012
Replying to an email from Frank that I realised the list would be
interested in too:
On Tue, Apr 17, 2012 at 10:18 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 17 April 2012 03:44, Michael van der Gulik <mikevdg at gmail.com> wrote:
>> On Mon, Apr 16, 2012 at 10:45 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
<snip - SecureSqueak description>
>> What do you want to use it for?
> I've been doing a ton of reading on modules, in Newspeak and ML
> mainly. There's been a bunch of talk recently in both the Squeak and
> Pharo communities on reviving modularisation efforts.
> Mainly, I want to see if your work on packages can enable something
> like Newspeak and ML, where you may have multiple versions of the same
> package loaded in the same image, where packages don't have full
> access to other package's bits (unless you explicitly enable said
> access). In essence I'd like to carve up the flat, known-by-everything
> global-state-ish namespace we currently have.
That's a fairly accurate description of what I did, although I'm
unfamiliar with Newspeak and ML. I have done the following, all of it
less than alpha-quality code. All of this is code in their own
Namespaces and they don't appear in the SystemDictionary:
* Namespaces and Packages implemented and used. Namespace is a
subclass of Dictionary (mapping Symbols -> Classes and other
Namespaces), Package is a subclass of Namespace.
* NamespaceBrowser implemented (based on an old buggy PlusTools
browser), tools fixed up just enough to work with namespaces.
* Kernel, Collections, Morphic, Graphics, Files and System converted
* OpalCompiler, AST, SUnit, PlusTools converted to Packages.
OpalCompiler still needs to be used - currently I'm using the old
Compiler with modifications for namespaces.
* more stuff.
The new Kernel package is partially used, coincident with the original
classes. I made a new Metaclass / Class singularity and all of my
other classes (usually) use these. Special objects such as true,
false, SmallIntegers, BlockContext, etc etc still all need porting. I
haven't uncompacted any classes yet either.
I'm currently working on export and import of source code to files. I
hope to abandon squeak.changes and Squeak*.sources, and instead store
code in the image with regular exports to a directory structure for
backup and version control. I looked at Monticello and abandoned
trying to modify it in preference to exporting/importing code
predictably enough to be able to use existing version control tools
such as Subversion or Git. I'm separating source management from
Class. My philosophy here is that source code is only for developers,
and that the canonical source code lives as objects in an image.
I haven't touched much of this code for ages. If there is interest, I
could work towards another release. The latest versions only exist in
images on my local machine; I've gone far beyond being able to use
Monticello now. I can't work on it particularly quickly either; I only
have time for one or two hours a week.
More information about the Squeak-dev