Hi, Stef -

>This is fun because I was rereading the miniimage contents and started to 
>think in terms of package reorganization to support a mini image.
>I reread also Spoon a bit and I was looking at the nuturning.
>Dan it would be nice if you could merge the potatoe change into Jsqueak?

Potato is JSqueak.  I don't get it.

>Dan, Mariano for his PhD did some analysis about number of object used during 
>typical coding session and we got around 17 %.
>So mariano would like to see how we can get something like LOOM to dispose 
>unused objects :)

Are you aware of the work I did that enables class fault detection in Squeak?

If a class has a nil methodDictionary, it causes a fault (ie it sends 
recoverFromMDFault to the class).   That code then restores the MD in addition 
to any anyalysis you want. I never cleaned it up for posterity, but it enabled 
lots of interesting work...

        By nilling all but a few MDs, and then running some application, you 
could
                tell exactly what classes were needed and which were not.
                See the method discoverActiveClasses.
        A special feature even recorded the call stack that caused each class 
to be
                touched.
        What I was doing was restructuring the entire system as a bunch of
                image segments that could be swapped out and brought in
                on demand -- a sort of user-programmable swapping memory.
        This all worked at one point.  Swapping of projects was a bit flakier
                because of our weak discipline on pointer scope, but it
                even worked in many cases.

Where I was going with the whole "reorganizeEverything" project was that the 
SystemDictionary would be partitioned into many separate dictionaries in each 
project, and that namespaces would be the same as the project swapping unit, 
and the whole thing would be simple and fast.  It actually worked once (;-) 
also.

Loom was cool, but it could never come close to the speed of imageSegments.  I 
played around with swapping out the entire VM Support category with all classes 
and methods, and it would swap in the entirety in less than 200 milliseconds, 
and this was a decade ago.

Sorry for the long digression, but maybe some of this thinking or even the 
actual mechanism can be of use to your experiments.

        - Dan

>
>>  James Ladd <[email protected]> wrote...
>>>> Hi Pharo-ites,
>>>>
>>>> I'm working on a port of Pharo to the Java Virtual Machine called Redline 
>>>> Smalltalk.
>>>> (read more here: http://jamesladdcode.com/?p=323)
>>>>
>>>> I'm wanting to port every single class over time, but initially enough to 
>>>> get the
>>>> compiler working and have a minimum runtime.
>>>>
>>>> Of the 1600+/- classes which are those necessary to make a small workable 
>>>> compiler
>>>> and runtime environment?
>>
>> Hi, James -
>>
>> Bert Freudenberg forwarded this along to me, as I'm not on a Pharo mailing 
>> list.
>>
>> I think you know of my JSqueak project (a.k.a. Potato) -- a Squeak VM 
>> written in Java.  The image that I used with it, is the same that I always 
>> use for this kind of experiment -- mini.image built in Squeak 2.2.
>>
>> The reason it is so cool is that it includes browser, editor, compiler, 
>> inspector debugger, and files -- everything you need for self-support.  Plus 
>> it has the decompiler, and special temp-name hack, so you can actually 
>> browse sources with temp names before any file system works.  My favorite 
>> thing about this image is that although it is only 600k, if you decompile 
>> all its sources, it comprises over 850k of Smalltalk, so it's like a 
>> compressed version of the sources with a full-function IDE thrown in for 
>> free ;-).
>>
>> As I said, the image is about 600k, of which 240k is code -- 202 classes (x2 
>> if you count the metas) with 4590 methods.  This should be a good guide for 
>> you in choosing classes to start with.
>>
>> You can actually run this image live in JSqueak on the web if you have Java 
>> installed and the planets are aligned correctly...
>>         http://Weather-dimensions.com/Dan/JSqueak.jnlp
>> Another interesting statistic is that the Java .jar file is only 433k, 
>> including not only the VM, but also the entire image!  This is possible 
>> because the image is so small that the pointers in it are mostly zeroes, so 
>> it compresses nicely.  I just checked that this runs, and was happy to see 
>> that it putts along at 21 million bytecodes/sec on my laptop.
> >
>> I haven't looked recently, but I think you'll find Mini2.2.image or 
>> something like it in the same place where all the historical releases of 
>> Squeak are kept.  Let me know if you can't find it.
>>
>> Have fun with your project!  I hope this helps
>>
>>         - Dan
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>_______________________________________________
>Pharo-project mailing list
>[email protected]
>http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to