Ladrillos (was SqueakCore System [proposal])

People:

Ladrillos is bricks in Argentina.
So I wish ladrillos small and versatile for building common houses, Empire
State, Kheops Piramide, Long Chinese Wall, etc.
For any future system, (Spoon, Kernel, SqueakCore, etc) I said we should not
use actual PI.
We should build new ladrillos.
Here I my first try for Kernel.
KernelCompression.1.cs should have
#CRCError
#DeflateStream
#FastInflateStream
#FileList
#InflateStream
#MessageTally
#StringHolder
#ZipConstants
#ZipEncoder
#ZipEncoderTree
#ZipWriteStream


Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Hi Edgar,

on Tue, 22 Aug 2006 13:13:33 +0200, you wrote:
> People:
>
> Ladrillos is bricks in Argentina.
> So I wish ladrillos small and versatile for building common houses,  
> Empire
> State, Kheops Piramide, Long Chinese Wall, etc.

Hey, ladrillos sounds cool in my ears :)

> For any future system, (Spoon, Kernel, SqueakCore, etc) I said we should  
> not
> use actual PI.
> We should build new ladrillos.

Excellent! This results in a well documented (w.r.t. the partitioning)  
image ;-)

> Here I my first try for Kernel.
> KernelCompression.1.cs should have
> #CRCError
> #DeflateStream
> #FastInflateStream
> #FileList
> #InflateStream
> #MessageTally

I'd like to see good old MessageTally being part of the kernel, it helped  
me debugging in many situations: just slow down execution of the method  
you're interested in and use MessageTally for finding out if that's called.

> #StringHolder
> #ZipConstants
> #ZipEncoder
> #ZipEncoderTree
> #ZipWriteStream

/Klaus

> Edgar

Hi Edgar,

That's great that you are trying to create packages for the kernel
image but remember that the image shloud be consistent after loading -
empty Undeclared etc. I don't know why you need to have FileList or
MessageTally in this package.

I think that we need better packaging system - maybe something like
Gentoo has. Packages use property named "use flags" that tell that for
example MessageTally package may be compiled with the compression
support.

Does anybody know next good packaging systems we can learn from?

-- Pavel

On 8/22/06, Lic. Edgar J. De Cleene <[hidden email]> wrote:

On Tue, Aug 22, 2006 at 03:13:01PM +0200, Klaus D. Witzel wrote:
Yes, this is a very good name! It sounds good to this English speaker
also, and the idea is good.

Dave

On 8/22/06, Pavel Krivanek <[hidden email]> wrote:
Mhhh difficult answer.
CPAN dependecy system seems good to me.
Even ruby gems works fine.
In the 2004 the Squeak maling list (I and  some other) tried to
"divide" the image in some uniform areas but was a very difficult
task.
I think we must aim to a lesser difficult task.
For instance an image with only these features can be quite good:
 Networking
 Base Stuff (Collection, Message Tally and so on)
 Math Base
 Minimal SqueakMap engine OR Minimal MCInstall

and optionally:
 Morph base

Pavel do you have a web page when can I study your "Image costruction kit"?
And yes, Landrillos sounds Good!

--
Software Architect
http://www.objectsroot.com/
Software is nothing

On 8/23/06, Giovanni Giorgi <[hidden email]> wrote:
I will try to prepare something soon, for now, start with this thread:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/096625.html

-- Pavel

Pavel Krivanek puso en su mail :
How I "guess" the class list.

I have for a while
Object > othersClassList
othersClassList
|classList metodosSospechosos |
 classList := Set new.
metodosSospechosos := self  methodDict .
metodosSospechosos isEmpty
        ifFalse: [metodosSospechosos
                collect: [:cm | cm literals
                        select: [:any | any isVariableBinding]
                        thenCollect: [:each | (Smalltalk at: each key
ifAbsent:[])
                                ifNotNil: [  classList add: each key]]]].
                   
metodosSospechosos := self class methodDict .
metodosSospechosos isEmpty
        ifFalse: [metodosSospechosos
                collect: [:cm | cm literals
                        select: [:any | any isVariableBinding]
                        thenCollect: [:each | (Smalltalk at: each key
ifAbsent:[])
                                ifNotNil: [classList add: each key]]]].
                    classList remove: self name  ifAbsent: [].
                    ^classList

On a fresh Squeak3.9g-7054.image.

 GZipReadStream othersClassList gives me a Set(#FileStream #Smalltalk
#Sensor #MultiByteBinaryOrTextStream #Array #OrderedCollection #ByteArray
#SimpleServiceEntry #ZipWriteStream #FileModifyingSimpleServiceEntry
#FileList #FileDirectory)


The goal is kernel could load the "wished" normal class without change any
on Squeak3.9g-7054.image and as little as possible on kernel.

So the "exploration" consists in exchange info between kernel as you
provides plus my first Ladrillo.
That is fileOut Network-Kernel.st from Squeak3.9g-7054.image and fileIn in
kernel, loading RemoteCommand.st and doing SmalltalkImage current
saveAsNewVersion.

Now I have your kernel as provided and KernelSqueak3.9b-7053.1.image
It's time to build the next Ladrillo, what I wish was the minimal code what
lets understand gzip on kernel without complaints, Undefined or odd things.

I have the process semi automatic.
The rest of classes what I thing should go in second Ladrillo comes from
this semi-automatic process.
When complete , also I polish this process.
And if I could proper load ZipConstants on kernel , I could continue

In the end , looooog time, we have a kernel with minimal change as you have
now, several Ladrilllos and I hope a beautiful, safer house for all.

Cheers.

Edgar
                   



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

"Pavel Krivanek" <[hidden email]> writes:
> I think that we need better packaging system - maybe something like
> Gentoo has. Packages use property named "use flags" that tell that for
> example MessageTally package may be compiled with the compression
> support.
>
> Does anybody know next good packaging systems we can learn from?

My take is that the package format itself is only of secondary
importance.  You need to think about how to manage *groups* of
packages.  Once you have an answer to that, everything else gets much
easier.

The idea is that packages come in groups, and groups can be composed
to larger groups.  The most frequent kind of grouping is simply to
have an index stored on a server.  This approach is widely used,
including by Debian and, IIUC, by Gentoo.

A pervasive bad idea is that you can get by with just dependencies and
skip having a notion of groups of packages to draw from.  If you have
no limit to what packages you can choose among, then your information
system has to be impossibly sophisticated.


This "package universes" approach is implemented for both Squeak and
the Scala.

  "Package Universes"
  http://minnow.cc.gatech.edu/squeak/3785
 
  "Scala Bazaars"
  http://www.lexspoon.org/sbaz/


It seems to work out fine.  It is the basis of a "Stable Squeak 3.7"
distribution with 200 packages in it, and that distribution has been
used without problem for hundreds of students at Georgia Tech.


-Lex