[squeak-dev] Squeak license? Traits?

Hi all.

I need an image which has:
* No traits.
* Monticello.
* MIT / Apache 2.0 license.
* As few bugs as possible.

I need this to grab the code in the Kernel-* and Collections-* categories as a base for namespaced versions. This will be a fork and until I write special tools to manage namespaced changesets, it will be one-way.

What are my options?

Is Squeak now under the Apache 2.0 and MIT licenses, or are bits in Kernel and Collections still under Squeak-L? Was the relicensing effort successful? The Squeak web site says otherwise.

Is Cuis really released under the MIT license? Did Juan relicense it from Apache 2.0?

How difficult is it to remove traits from Squeak or Pharo?

How difficult is it to add Monticello to Cuis?

And the flamebait: which release has the fewest bugs in the Kernel-* and Collections-* categories?

Thanks,
Gulik.

--
http://gulik.pbwiki.com/

Michael van der Gulik wrote:
A sidenote - if you ever get the itch to do the "namespaced
changesets"-work, please check with me first to see if we can instead do
it in the realm of Deltas. They are much better :)

regards, Göran

On 15.09.2009, at 11:46, Michael van der Gulik wrote:

VPRI's relicensed Etoys 4.0 image does not have Monticello but  
otherwise fits the bill:
        http://www.vpri.org/vp_wiki

> Is Squeak now under the Apache 2.0 and MIT licenses, or are bits in  
> Kernel and Collections still under Squeak-L? Was the relicensing  
> effort successful? The Squeak web site says otherwise.

For practical purposes even Trunk is under Apache/MIT. We just have  
not received explicit relicensing statements from a few contributors.  
The Squeak Oversight Board is in contact with the Software Freedom  
Conservancy about the work remaining to be done to be legally safe.  
This will be called Squeak 4.0, and Matthew and a few others are  
working on this.

> How difficult is it to remove traits from Squeak or Pharo?

Would be great to find out. IMHO Traits should be in the Squeak image  
ready to be used, but not be employed by the Kernel itself. That makes  
them easily unloadable for purposes like yours.

> And the flamebait: which release has the fewest bugs in the Kernel-*  
> and Collections-* categories?


The most recent I would hope, that would be Trunk.

- Bert -

Hi Gulik,

Michael van der Gulik wrote:
Yes and yes. The relicense from Apache 2.0 applies to all the code in
Squeak 1.1. The rest is work of contributors who signed the VPRI
agreement, or more recent work licensed under MIT from day one. So it is
all MIT.

> How difficult is it to remove traits from Squeak or Pharo?
>
> How difficult is it to add Monticello to Cuis?

It shouldn't bee too hard I guess. Perhaps an afternoon of work. Not
sure, though.

> And the flamebait: which release has the fewest bugs in the Kernel-*
> and Collections-* categories?

That's hard to say. I guess the trunk has the best Collections. It also
has the best Kernel, although if you give up full compatibility there
are a couple of tweaks in Cuis that I think are improvements, in #fork
and friends and in MessageTally. Some time I plan to update Kernel and
Collections in Cuis to include the latest fixes and enhancements in trunk.

> Thanks,
> Gulik.
>
> --
> http://gulik.pbwiki.com/

Cheers,
Juan Vuletich

Michael van der Gulik wrote:
> And the flamebait: which release has the fewest bugs in the Kernel-* and
> Collections-* categories?

The latest trunk should be pretty good. Plus, if you can get MC to work,
you could just merge newer versions.

BTW, are you planning to support namespaces via Monticello? If so, can I
ask you to talk a little more about what you are planning? Personally, I
got completely stuck with Monticello's flat representation, i.e., the
issue that definitions aren't nested. Since a method definition isn't
located "inside" a class definition it makes it pretty much impossible
to determine the actual scope of the method definition. For a brief
(VERY brief) moment I considered rewriting Monticello but I quickly got
cured when looking at the actual code involved.

Cheers,
   - Andreas

Matthew Fulmer created an installer script which removes Traits:
<http://installer.pbworks.com/UnloadTraits>
Pbwiki has since changed name to pbworks so there appears to be some detective work required to find the required change sets.

Ken G. Brown

At 9:46 PM +1200 9/15/09, Michael van der Gulik apparently wrote:

Sure :-). I'll investigate that when I get that far.

I'm going to separate source code from byte codes in SecureSqueak. Packages will be loaded into an image in binary form and Class, CompiledMethod will no longer manage source code. The source code management will be in optional packages, and it will be "pluggable" such that any compiler / set of tools can be used, so implementing a set of tools that use Deltas can be done at any stage.

Gulik.

--
http://gulik.pbwiki.com/

I'll briefly describe what I'm planning below. I haven't started work on this yet; Namespaces are currently usable but urgently need major refactoring and then bug-fixing.

Documentation lives on http://gulik.pbwiki.com/Namespaces. Let me know if anything there is hard to understand and I'll fill it in more.

The core of Namespaces will be the following classes:

Package - subclass of Namespace, forms the root of a namespace hierarchy.
Namespace - subclass of Dictionary mapping #Symbols to other Namespaces, Classes and global variables.
Class - like it is now, sans source code but including intermediate-representation of code from compiler as well.
CompiledMethod - like it is now, sans source code, with closures, literals are strictly read-only.

and other classes to hold the intermediate representation of code, read-only literals, documentation, meta-class stuff, etc.

The intermediate-representation of code will be generated from the NewCompiler* with the IR (intermediate-representation) classes borrowed from there (from memory, I think they were called "IR classes", I forget). When packages are moved between images, the IR will be serialized and deserialized in binary form rather than using bytecodes because it is much easier to verify that IR is secure than bytecodes. Doing it this way also has some other benefits, such as letting the receiving VM have a completely different bytecode set.

The source code management will be external to the above. Any source code management system can be used as long as it generates a valid Package object structure. The source code tools will need to hold their own mirror objects of the structure of a package and its source. I'll be making a simple set of tools based on what I already have, and I hope that at some stage in the future, other people can make better tools.

(*) the NewCompiler would be an external source code management tool. It would be completely optional.

Gulik.

--
http://gulik.pbwiki.com/

On 9/15/09 5:10 PM, "Ken G. Brown" <[hidden email]> wrote:

> Matthew Fulmer created an installer script which removes Traits:
> <http://installer.pbworks.com/UnloadTraits>
> Pbwiki has since changed name to pbworks so there appears to be some detective
> work required to find the required change sets.
>
> Ken G. Brown

This work is inside ReleaseBuilder3dot11

ReleaseBuilderFor3dot11 new  prepareToUnloadTraits; unloadTraits

Edgar