The problem for an open source community as this one is time and money As Stef says "give me a million dollars and I will give you a Pharo million times better" that's the dream world in real world we all have very limited time that we focus on the sides of Pharo that interest us the most. Obviously we are here to help people use Pharo under any condition and requirement. As such I think and hope that I speak for everyone that we are more than happy to offer advice to help Pharo extend its influence on other platforms. To actually contribute code will need Pharo developers that are experienced Java developers too (I am not). Problem is that neither Java nor Javascript have good reputation and as such people who can avoid them do so. For example even though we can justify the freeze of a project like Redline Smalltalk because of the tiny size of the Smalltalk community but take something huge in popularity like Python, the official release of Python is CPython with an estimate of over 2 million developers world wide , Jython which is the port of Python in JVM has actually smaller community than we have at least last time I checked few gears ago. Just think about it for a minute. Its super hard to convince a python developer to switch to jython and so is for a java developer. This applies for all languages, I think the reasoning is that each language is not just a tool but an entire culture and people pick them for specific reasons, Javascript situation is more or less the same, python has no actively supported javascript equivelant. Again I am using Python as an example, different languages same or similar scenario. This is why I suggested to bring Redline closer to Pharo rather than porting some Pharo classes to JVM. Amber failed to gain traction because it did the opposite of what I am suggesting , tried to convince people to give up Pharo and move completely to Amber (for the JS part) which is why it implemented its own IDE etc. Obviously it did not work and Amber is barely alive. PharoJS seem on the right path , at least for me, so maybe there is still hope. In any case its not hard to use libraries from other programming language in Pharo with some form of IPC, I do this for using python libraries from Pharo and I making something similar for C++. Took me only a few hundred lines of code to do it for both and works pretty well. IPC can work with pretty much any language and as many languages at the same time as you want or your processor can handle. There are a ton of projects out there that use multiple languages that work together as one unit. Problem is that you can approach this through a billion diffirent angles and it will depend on the specific problem you want to solve. I build my own IPC tools to fit my specific needs which are Unreal (game engine) and Blender (3d application). There was a cool idea from a presentation a Smalltalker once gave about moving a DigiTalk implementation to JVM whithout changing a thing inside the image. Instead they ported the bytecode from smalltalk to JVM and used JNI for the C libraries. Sound too good to be true, they supposed to release it open source ages ago but that turned out to be another vaporware. I also agree that Cuis is a very good start to find the most essential libraries for Pharo. There is also a minimal image for pharo on the dowload section of the website which should give a good idea. But as it is to be expected its impossible to predict what is essential for each Pharo user and there lies the challenge. On Fri, Dec 30, 2016 at 1:59 PM Tim Mackinnon <tim@testit.works> wrote:

Actually I think James is on to something and we should try and support him.

Having recently played with AWS Lambda and written a few Alexa services in JS, I was intrigued how you would approach such end points in Smalltalk and whether it would be a productive language and environment to run them in. (Btw - the lambda environment is very interesting - scalable infrastructure that is peanuts to run).

To try this, the basic building blocks provided by these services are either JS or Java - so for Smalltalkers that sounds like Smalltalk running on Amber or Redline.

I find Amber and all the JS infrastructure very daunting - gulp, amd etc. And for Lambda you also get caught into this world of package management and loading up JS dependencies.

I'm intrigued how a jvm Smalltalk might approach this problem (as well as many others I'm sure). We seem to achieve a lot with quite a small image of building blocks.

As pharo is a research community, can we help James explore this a bit more? Certainly there is a drive to a minimal Smalltalk image - so that work can immediately feed into this.

To add to the research'y side context - these service infrastructures seem to feel a lot like callable blocks of code. We are used to thinking in this way in our image - we use blocks everywhere. How might they run in a scaleable environment vs straight function call languages?

Tim

Sent from my iPhone

On 30 Dec 2016, at 09:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

I think what most people would want is to use Java libraries from inside Pharo. You seem to want to bring Pharo classes to Redline Runtime .

I have the opposite idea of bringing Redline Runtime inside Pharo and give us Pharo developers an easy way to use Java libraries and mix pharo with java code. I think also Pharo would serve great as an IDE for Redline Smalltalk.

I already have JNIPort thats does that but none will complain to have another tool around, I am sure it will come very handy.

On Fri, Dec 30, 2016 at 2:08 AM James Ladd <ladd.james@gmail.com> wrote:

Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

-- View this message in context: http://forum.world.st/Redline-Talking-Runtime-basics-tp4928375.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com>.

Thanks Tim. I even tried to find the old Potatoe Smalltalk which was a port of an old Smalltalk-80 image as it had a working ide and yet the smallest count of classes. Sent from my Commodore 64

On 31 Dec 2016, at 1:01 am, Tim Mackinnon <tim@testit.works> wrote:

I think we've gone off topic - James would simply like advice on what a minimal image could/should be composed of.

That doesn't sound like a lot of work to help with that.

I know there is a minimal image project in Pharo, but I'm not sure how minimal it got. I recall Marcus once telling me that the trick might be to get things to a place where you could bootstrap metacello and load in whatever you needed. I'm not sure if that is still the goal? But that would strike me as the core library he's interested in?

Equally there was some work around having a scripting language using a command line Pharo for build type things. I don't recall its name - but again I'm sure it relies on a core set of classes that are used to bootstrap stuff as well.

If someone can point to either of those two things that might help James enough.

I know his actual project is hosted in GitHub and doesn't really distract anything going on here. It's on my todo list to check it out.

Tim

Sent from my iPhone

...

On 30 Dec 2016, at 13:49, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

The problem for an open source community as this one is time and money

As Stef says "give me a million dollars and I will give you a Pharo million times better"

that's the dream world

in real world we all have very limited time that we focus on the sides of Pharo that interest us the most. Obviously we are here to help people use Pharo under any condition and requirement. As such I think and hope that I speak for everyone that we are more than happy to offer advice to help Pharo extend its influence on other platforms.

To actually contribute code will need Pharo developers that are experienced Java developers too (I am not).

Problem is that neither Java nor Javascript have good reputation and as such people who can avoid them do so.

For example even though we can justify the freeze of a project like Redline Smalltalk because of the tiny size of the Smalltalk community but take something huge in popularity like Python, the official release of Python is CPython with an estimate of over 2 million developers world wide , Jython which is the port of Python in JVM has actually smaller community than we have at least last time I checked few gears ago. Just think about it for a minute.

Its super hard to convince a python developer to switch to jython and so is for a java developer.

This applies for all languages, I think the reasoning is that each language is not just a tool but an entire culture and people pick them for specific reasons,

Javascript situation is more or less the same, python has no actively supported javascript equivelant.

Again I am using Python as an example, different languages same or similar scenario.

This is why I suggested to bring Redline closer to Pharo rather than porting some Pharo classes to JVM.

Amber failed to gain traction because it did the opposite of what I am suggesting , tried to convince people to give up Pharo and move completely to Amber (for the JS part) which is why it implemented its own IDE etc. Obviously it did not work and Amber is barely alive.

PharoJS seem on the right path , at least for me, so maybe there is still hope.

In any case its not hard to use libraries from other programming language in Pharo with some form of IPC, I do this for using python libraries from Pharo and I making something similar for C++. Took me only a few hundred lines of code to do it for both and works pretty well. IPC can work with pretty much any language and as many languages at the same time as you want or your processor can handle.

There are a ton of projects out there that use multiple languages that work together as one unit. Problem is that you can approach this through a billion diffirent angles and it will depend on the specific problem you want to solve. I build my own IPC tools to fit my specific needs which are Unreal (game engine) and Blender (3d application).

There was a cool idea from a presentation a Smalltalker once gave about moving a DigiTalk implementation to JVM whithout changing a thing inside the image. Instead they ported the bytecode from smalltalk to JVM and used JNI for the C libraries. Sound too good to be true, they supposed to release it open source ages ago but that turned out to be another vaporware.

I also agree that Cuis is a very good start to find the most essential libraries for Pharo. There is also a minimal image for pharo on the dowload section of the website which should give a good idea. But as it is to be expected its impossible to predict what is essential for each Pharo user and there lies the challenge.

...

On Fri, Dec 30, 2016 at 1:59 PM Tim Mackinnon <tim@testit.works> wrote: Actually I think James is on to something and we should try and support him.

Having recently played with AWS Lambda and written a few Alexa services in JS, I was intrigued how you would approach such end points in Smalltalk and whether it would be a productive language and environment to run them in. (Btw - the lambda environment is very interesting - scalable infrastructure that is peanuts to run).

To try this, the basic building blocks provided by these services are either JS or Java - so for Smalltalkers that sounds like Smalltalk running on Amber or Redline.

I find Amber and all the JS infrastructure very daunting - gulp, amd etc. And for Lambda you also get caught into this world of package management and loading up JS dependencies.

I'm intrigued how a jvm Smalltalk might approach this problem (as well as many others I'm sure). We seem to achieve a lot with quite a small image of building blocks.

As pharo is a research community, can we help James explore this a bit more? Certainly there is a drive to a minimal Smalltalk image - so that work can immediately feed into this.

To add to the research'y side context - these service infrastructures seem to feel a lot like callable blocks of code. We are used to thinking in this way in our image - we use blocks everywhere. How might they run in a scaleable environment vs straight function call languages?

Tim

Sent from my iPhone

...

On 30 Dec 2016, at 09:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

I think what most people would want is to use Java libraries from inside Pharo. You seem to want to bring Pharo classes to Redline Runtime .

I have the opposite idea of bringing Redline Runtime inside Pharo and give us Pharo developers an easy way to use Java libraries and mix pharo with java code. I think also Pharo would serve great as an IDE for Redline Smalltalk.

I already have JNIPort thats does that but none will complain to have another tool around, I am sure it will come very handy.

On Fri, Dec 30, 2016 at 2:08 AM James Ladd <ladd.james@gmail.com> wrote: Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

-- View this message in context: http://forum.world.st/Redline-Talking-Runtime-basics-tp4928375.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

I'll check it out. The version I remember was black n white. Sent from my Commodore 64

On 31 Dec 2016, at 9:04 pm, Stefan Marr <smalltalk@stefan-marr.de> wrote:

Hi James:

...

On 30 Dec 2016, at 22:50, James Ladd <ladd.james@gmail.com> wrote:

I even tried to find the old Potatoe Smalltalk which was a port of an old Smalltalk-80 image as it had a working ide and yet the smallest count of classes.

Did you find it? https://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/

Best regards Stefan

-- Stefan Marr Johannes Kepler Universität Linz http://stefan-marr.de/research/

Let's do that Stef Jamesladd67 is my Skype Thank you so much Sent from my Commodore 64

On 1 Jan 2017, at 1:21 am, Stephane Ducasse <stepharo.self@gmail.com> wrote:

James,

Nice to hear that you are still pushing. I would love to be able to developed in Pharo and deployed on red. Noury is working on the same scenario for PharoJS.

May be we should organise a skype with Guille because we can use his infrastructure (hespel) to create out of Pharo automatically a kernel for Red.

Guille has an infrastructure Hespel (check his phd) to - bootstrap different kernels such as Candlelight, microsqueak.. - tailor application (you give a seed expression and it collects all the mandatory methods and classes) probably like spoon

He bootstrapped different small kernels during his phd. In tornado the tailoring version of Hespel we can create imae that are as small as 12k :)

We put a list of the class in a techreport. https://hal.inria.fr/hal-00996908

In Pharo 70 we will use in production a bootstrap kernel: basically Pharo core with some better handled mechanisms (such as the startup) We should remove the traits from class/metaclasses to gain some space. Now our goal for this version is not to have the smallest core but a full process based on a bootstrap image. We shuffled/repackaged many classes around and we will continue to cut spurious dependencies.

Stef

...

On Sat, Dec 31, 2016 at 12:50 PM, James Ladd <ladd.james@gmail.com> wrote: I'll check it out. The version I remember was black n white.

Sent from my Commodore 64

...

On 31 Dec 2016, at 9:04 pm, Stefan Marr <smalltalk@stefan-marr.de> wrote:

Hi James:

...

On 30 Dec 2016, at 22:50, James Ladd <ladd.james@gmail.com> wrote:

I even tried to find the old Potatoe Smalltalk which was a port of an old Smalltalk-80 image as it had a working ide and yet the smallest count of classes.

Did you find it? https://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/

Best regards Stefan

-- Stefan Marr Johannes Kepler Universität Linz http://stefan-marr.de/research/

Dimitris, To contribute you do not need to code Java at all, never, period. Sent from my Commodore 64

On 30 Dec 2016, at 11:49 pm, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

The problem for an open source community as this one is time and money

As Stef says "give me a million dollars and I will give you a Pharo million times better"

that's the dream world

in real world we all have very limited time that we focus on the sides of Pharo that interest us the most. Obviously we are here to help people use Pharo under any condition and requirement. As such I think and hope that I speak for everyone that we are more than happy to offer advice to help Pharo extend its influence on other platforms.

To actually contribute code will need Pharo developers that are experienced Java developers too (I am not).

Problem is that neither Java nor Javascript have good reputation and as such people who can avoid them do so.

For example even though we can justify the freeze of a project like Redline Smalltalk because of the tiny size of the Smalltalk community but take something huge in popularity like Python, the official release of Python is CPython with an estimate of over 2 million developers world wide , Jython which is the port of Python in JVM has actually smaller community than we have at least last time I checked few gears ago. Just think about it for a minute.

Its super hard to convince a python developer to switch to jython and so is for a java developer.

This applies for all languages, I think the reasoning is that each language is not just a tool but an entire culture and people pick them for specific reasons,

Javascript situation is more or less the same, python has no actively supported javascript equivelant.

Again I am using Python as an example, different languages same or similar scenario.

This is why I suggested to bring Redline closer to Pharo rather than porting some Pharo classes to JVM.

Amber failed to gain traction because it did the opposite of what I am suggesting , tried to convince people to give up Pharo and move completely to Amber (for the JS part) which is why it implemented its own IDE etc. Obviously it did not work and Amber is barely alive.

PharoJS seem on the right path , at least for me, so maybe there is still hope.

In any case its not hard to use libraries from other programming language in Pharo with some form of IPC, I do this for using python libraries from Pharo and I making something similar for C++. Took me only a few hundred lines of code to do it for both and works pretty well. IPC can work with pretty much any language and as many languages at the same time as you want or your processor can handle.

There are a ton of projects out there that use multiple languages that work together as one unit. Problem is that you can approach this through a billion diffirent angles and it will depend on the specific problem you want to solve. I build my own IPC tools to fit my specific needs which are Unreal (game engine) and Blender (3d application).

There was a cool idea from a presentation a Smalltalker once gave about moving a DigiTalk implementation to JVM whithout changing a thing inside the image. Instead they ported the bytecode from smalltalk to JVM and used JNI for the C libraries. Sound too good to be true, they supposed to release it open source ages ago but that turned out to be another vaporware.

I also agree that Cuis is a very good start to find the most essential libraries for Pharo. There is also a minimal image for pharo on the dowload section of the website which should give a good idea. But as it is to be expected its impossible to predict what is essential for each Pharo user and there lies the challenge.

...

On Fri, Dec 30, 2016 at 1:59 PM Tim Mackinnon <tim@testit.works> wrote: Actually I think James is on to something and we should try and support him.

Having recently played with AWS Lambda and written a few Alexa services in JS, I was intrigued how you would approach such end points in Smalltalk and whether it would be a productive language and environment to run them in. (Btw - the lambda environment is very interesting - scalable infrastructure that is peanuts to run).

To try this, the basic building blocks provided by these services are either JS or Java - so for Smalltalkers that sounds like Smalltalk running on Amber or Redline.

I find Amber and all the JS infrastructure very daunting - gulp, amd etc. And for Lambda you also get caught into this world of package management and loading up JS dependencies.

I'm intrigued how a jvm Smalltalk might approach this problem (as well as many others I'm sure). We seem to achieve a lot with quite a small image of building blocks.

As pharo is a research community, can we help James explore this a bit more? Certainly there is a drive to a minimal Smalltalk image - so that work can immediately feed into this.

To add to the research'y side context - these service infrastructures seem to feel a lot like callable blocks of code. We are used to thinking in this way in our image - we use blocks everywhere. How might they run in a scaleable environment vs straight function call languages?

Tim

Sent from my iPhone

...

On 30 Dec 2016, at 09:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

I think what most people would want is to use Java libraries from inside Pharo. You seem to want to bring Pharo classes to Redline Runtime .

I have the opposite idea of bringing Redline Runtime inside Pharo and give us Pharo developers an easy way to use Java libraries and mix pharo with java code. I think also Pharo would serve great as an IDE for Redline Smalltalk.

I already have JNIPort thats does that but none will complain to have another tool around, I am sure it will come very handy.

On Fri, Dec 30, 2016 at 2:08 AM James Ladd <ladd.james@gmail.com> wrote: Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

-- View this message in context: http://forum.world.st/Redline-Talking-Runtime-basics-tp4928375.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

I have been looking at Amber :) Sent from my Commodore 64

On 31 Dec 2016, at 6:26 am, philippe.back@highoctane.be <philippe.back@gmail.com> wrote:

Amber took a bunch of classes and this could be a nice starting point for fundamentals.

Phil

Le 30 déc. 2016 18:14, "Ben Coman" <btc@openinworld.com> a écrit :

...

On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james@gmail.com> wrote:

...

Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

Nice to hear you are continuing. I'm not very knowledgable on this, but I'll show you how to pull some data from the work on producing a minimal image.

1. From PharoLauncher > Templates > Pharo 6.0(beta) download/create an image of build "60334-minimal". 2. Right-click on the image and choose [Copy pathname] 3. In a shell, change to that directory, and execute the following $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses size" ==> 2801 $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class allSubclasses size" ==> 1399. $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt

I've attached the output of that last one.

4. For comparison, in a standard 60334 image, Object allSubclasses size "==>11923". Object class allSubclasses size "==>5959".

Now in Pharo 6, the minimal image starts with a standard image and strips these things out... https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/ws/output.tx...

In Pharo 7, there will be a new build system that it will start with a minimal image and build it up to a normal image. So this may provide a better way to understand the order that things need to be implemented.

cheers -ben

So for curiosity... $ $PHARO bootstrap.image eval "Object allSubclasses size" 1677 $ $PHARO bootstrap.image eval "Object allSubclasses size" 837 $ $PHARO bootstrap.image eval "Object class printHierarchy" > /tmp/60334-bootstrap-hierarchy.txt (see attached) cheers -ben On Sat, Dec 31, 2016 at 4:42 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

It is better to use smaller bootstrapped image without Monticello but it is still quite big.

https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-01-00-Bootstra...

-- Pavel

2016-12-30 18:13 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james@gmail.com> wrote:

...

Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

Nice to hear you are continuing. I'm not very knowledgable on this, but I'll show you how to pull some data from the work on producing a minimal image.

1. From PharoLauncher > Templates > Pharo 6.0(beta) download/create an image of build "60334-minimal". 2. Right-click on the image and choose [Copy pathname] 3. In a shell, change to that directory, and execute the following $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses size" ==> 2801 $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class allSubclasses size" ==> 1399. $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt

I've attached the output of that last one.

4. For comparison, in a standard 60334 image, Object allSubclasses size "==>11923". Object class allSubclasses size "==>5959".

Now in Pharo 6, the minimal image starts with a standard image and strips these things out...

https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/ws/output.tx...

In Pharo 7, there will be a new build system that it will start with a minimal image and build it up to a normal image. So this may provide a better way to understand the order that things need to be implemented.

cheers -ben

Hi Phil, On Sat, Dec 31, 2016 at 10:14 AM, philippe.back@highoctane.be < philippe.back@gmail.com> wrote:

Isn't there a typo in the first exptession?

Also the list contains a lot of RB things. What purpose do they have in a bootstrap image?

Yes, that is because the bootstrap image contains the compiler. And the compiler requires (amongst others) the AST, implemented initially as part of the refactoring browser, and so it has the RB prefix. However, the bootstrap does not contain the refactoring browser.

Same for RelationSlot and X11 something.

RelationSlot belongs to the class builder package, which is needed to create classes. Of course RelationSlot is part of an 'Examples', and as such it could be packaged separately, but this was not done yet. Regarding the X11 thingy, this is probably X11Encoding that you're talking about. This one belongs to the Multilingual-encondings package, and if we are picky you'll see this package is required because it contains mainly Unicode, which is required by the Kernel so far to do a lot of stuff. See for example: Character>>asLowercase "If the receiver is uppercase, answer its matching lowercase Character." ^ self characterSet toLowercase: self Character>>characterSet ^ EncodedCharSet charsetAt: self leadingChar ... What lead to EncodedCharSet (and the default charset that is Unicode).

Is there a scope and purpose statement for the bootstrap somewhere?

Not writen that I know of. Maybe we should do it. But from many discussions here in the team I'd define the pharo bootstrap as a pharo environment that is - minimal (in the sense that it keeps only stuff required to run) - clean (in the sense that there is the less dead code and dead dependencies as possible) - and is able to grow (in the sense that you can install new code on it). Think that Pharo is not just the bootstrap. People will not accept a Pharo without a development environment, without a debugger or a workspace. These three points are a long term goal I woud say, and particularly the last point is in big conflict with the first one. You can have an image that executes code but has no compiler for example. So making a trade-off but always going towards that goal, what we decided with Christophe one year and a half ago to: - select a minimal set of packages that would belong to the bootstrap image * To run, you need the Kernel. * To be able to install new code you need some kind of I/O and some way to transform the input as classes/methods. Thus we chose to put also basic command line handlers, files, and the compiler. We discussed about putting a flavour of Fuel (say Tanker) instead of the compiler, but Tanker was not stable as it was only experimental and nobody used it for real; the compiler was much more stable as we use it everyday; and besides, Tanker was depending on the class builder, so it only allowed us to remove the compiler but not the class builder. * To be clean, we started looking at the dependencies of those packages. - We finished in a selection of about 53 packages. Remember that Pharo itself has nowadays around 464 packages... RPackageOrganizer default packages size "464" So this was as good as a ~10% of the original image. Good enough to have a first version. - And we started working on dependency analyses on them. The following report made by Christophe lists all the bootstrap packages and their dependencies, and reports when a new dependency is introduced. https://ci.inria.fr/pharo/view/6.0-Analysis/job/Pharo-6.0-DependencyAnalysis... See what the dependency graph looks of the bootstrap https://ci.inria.fr/pharo/view/6.0-Analysis/job/Pharo-6.0-DependencyAnalysis... and extrapolate to the entire image :). And that, after we worked a LOT to cut off/separate/untangle/decouple those 53 packages from the rest, rewrite parts of the system (a big example of it is the SessionManager). Now, this is of course not the end. There are still lots of things to do. - the kernel can be still cleaned up even more - we could implement some sort of binary serializer specialized for classes and methods to shrink even more the bootstrap - the rest of the image has still to be cleaned. Nowadays on top of the bootstrap Monticello and Metacello are bootstrapped using manual a approach and afterwards, the rest of the image is loaded by using a Baseline https://github.com/guillep/pharo-core/tree/66666949ceffbd806ff39188548d65797... That baseline can be enhanced, splitted in smaller baselines. This require non-bootstrap packages to be revisited, have checked their dependencies and so on... So what you see in that list is the result of several decisions and a lot of work. And the focus was to release something and not die in the process. Hope that answers the question (I will copy past this and put it into some wiki btw) Guille

Phil

Le 31 déc. 2016 05:47, "Ben Coman" <btc@openinworld.com> a écrit :

...

So for curiosity...

$ $PHARO bootstrap.image eval "Object allSubclasses size" 1677

$ $PHARO bootstrap.image eval "Object allSubclasses size" 837

$ $PHARO bootstrap.image eval "Object class printHierarchy" > /tmp/60334-bootstrap-hierarchy.txt (see attached)

cheers -ben

On Sat, Dec 31, 2016 at 4:42 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

...

It is better to use smaller bootstrapped image without Monticello but it is still quite big.

https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0- Step-01-00-Bootstrap/lastSuccessfulBuild/artifact/bootstrap.zip

-- Pavel

2016-12-30 18:13 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james@gmail.com>

wrote:

...

...

Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

Nice to hear you are continuing. I'm not very knowledgable on this, but I'll show you how to pull some data from the work on producing a minimal image.

1. From PharoLauncher > Templates > Pharo 6.0(beta) download/create an image of build "60334-minimal". 2. Right-click on the image and choose [Copy pathname] 3. In a shell, change to that directory, and execute the following $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses size" ==> 2801 $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class allSubclasses size" ==> 1399. $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt

I've attached the output of that last one.

4. For comparison, in a standard 60334 image, Object allSubclasses size "==>11923". Object class allSubclasses size "==>5959".

Now in Pharo 6, the minimal image starts with a standard image and strips these things out...

https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Mini mal/ws/output.txt

In Pharo 7, there will be a new build system that it will start with a minimal image and build it up to a normal image. So this may provide a better way to understand the order that things need to be implemented.

cheers -ben

This is very helpful thank you. Maybe I can rephrase things to help capture what I'm trying to do. In the Smalltalk-80 blue book there is a set of Kernel-Object/Kernel-Classes defined and I'm trying to find a full running implementation of these classes in a Smalltalk environment OR recreate Sent from my Commodore 64

On 31 Dec 2016, at 4:13 am, Ben Coman <btc@openinworld.com> wrote:

...

On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james@gmail.com> wrote: Hi Pharo People,

I have continued work on Redline Smalltalk and I'm wanting to discuss what the absolute minimum set of Classes and method should be included in the Redline Runtime.

Would anyone here like to participate in that discussion?

- James. Redline Smalltalk <http://redline.st>

Nice to hear you are continuing. I'm not very knowledgable on this, but I'll show you how to pull some data from the work on producing a minimal image.

1. From PharoLauncher > Templates > Pharo 6.0(beta) download/create an image of build "60334-minimal". 2. Right-click on the image and choose [Copy pathname] 3. In a shell, change to that directory, and execute the following $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses size" ==> 2801 $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class allSubclasses size" ==> 1399. $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt

I've attached the output of that last one.

4. For comparison, in a standard 60334 image, Object allSubclasses size "==>11923". Object class allSubclasses size "==>5959".

Now in Pharo 6, the minimal image starts with a standard image and strips these things out... https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/ws/output.tx...

In Pharo 7, there will be a new build system that it will start with a minimal image and build it up to a normal image. So this may provide a better way to understand the order that things need to be implemented.

cheers -ben <60334-minimal-class-hierarchy.txt>

Ben, That certainly is an approach. One key goal for Redline is for people using Java to be able to use their debugging tools and step from Java code into Smalltalk, and if that Smalltalk code calls other Java code then step into that code. Redline generates 100% compatible bytecode and class files (in memory) making this possible Redline also supports the generation of inline bytecode so no primitives just the equivalent Jvm bytecode - James Sent from my Commodore 64

On 2 Jan 2017, at 3:46 am, Ben Coman <btc@openinworld.com> wrote:

...

On Sat, Dec 31, 2016 at 5:53 AM, James Ladd <ladd.james@gmail.com> wrote: This is very helpful thank you.

Maybe I can rephrase things to help capture what I'm trying to do.

In the Smalltalk-80 blue book there is a set of Kernel-Object/Kernel-Classes defined and I'm trying to find a full running implementation of these classes in a Smalltalk environment OR recreate

Just my wandering mind.... an interesting experiment might be running SqueakJS [1] on top JVM8's Nashorn javascript engine [2][3], and then gradually converting parts to it to native Java code as profiling dictates.

cheers -ben

[1] http://freudenbergs.de/bert/publications/Freudenberg-2014-SqueakJS.pdf [2] https://ariya.io/2014/03/nashorn-the-new-rhino-on-the-block [3] https://www.infoq.com/articles/nashorn

--------------- On Sat, Dec 31, 2016 at 5:14 PM, philippe.back@highoctane.be <philippe.back@gmail.com> wrote:

...

Isn't there a typo in the first expression?

I've looked but don't see it. btw the first '$' is the shell prompt, the second '$' is a variable holding the vm location, since my download of bootstrap.image wasn't located under pharolauncher.

But I do notice the second expression should have been... $ $PHARO bootstrap.image eval "Object class allSubclasses size"