January 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Call of projects of open-dev lectures

by Serge Stinckwich

PolyMath issues are here: https://github.com/PolyMathOrg/PolyMath/issues On Wed, Jan 4, 2017 at 3:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 4, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Dimitris Chloupis

My project may be too advanced for a student but if students are interested in Game Development and Unreal , it can a very fun experience for them. I am in a process of constructing a Unreal API for Pharo. What students can learn 1) How to combine Pharo with C++ 2) How to use Unreal 3) How to use Pharo's UFFI 4) How to utilize shared memory and sockets 5) How to generate 3D graphics using Blender 6) How to profile Pharo 7) How to use git and github And a ton more, game development is a massive field What is required 1) basic knowledge of Pharo 2) basic knowledge of C++ Main website http://www.kilon-alios.com Github repos https://github.com/kilon/Ephestos (umbrella project) https://github.com/kilon/CPP (tool for using Unreal from Pharo) Online chat Slack - Ephestos room , or Discord Mailing list Github issues page of Ephestos can be used as forum On Wed, 4 Jan 2017 at 16:49, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef >

Jan. 4, 2017

Call of projects of open-dev lectures

by Stephane Ducasse

Hi We are organising a lecture where students should - learn pharo - learn how to communicate with open source community - learn how to reverse engineer, fix bugs.... They should work by 3/4. We are looking for projects that would like to accept - propose some bugs to be fixed - to communicate with newbies and from time to time I was thinking about - MDL - Roassal - Moose ? - Pillar ? but nobody beside me and I do not have the time - DRGeoII - Telescope - Artefact - Scale - Ecstatic So if you have a project and you want to participate. We would like to have - web page? - mailing-list - bug trackers/todo? Stef

Jan. 4, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Henrik Johansen

> On 3 Jan 2017, at 22:40 , Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > > On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: > It was my impression there was a procedure in place earlier for moving methods from SmalltalkImage to classes with a more singular responsibility that ensures a smooth upgrade experience; > > Yes, but it depends mostly on the user and there is no automated check for it... > So it happens that people (myself also) sometimes remove stuff without going into the deprecation phase... :/ > > > 1) create accessor method on Smalltalk (if none of the existing are appropriate) > 2) implement the old methods on new class in backwards compatability category > 3) Deprecate method on SmalltalkImage, on the form: > doX: someThing > self deprecated: 'Use Smalltalk specializedArea x: someThing instead' on: 'foo' in: 'bar'. > ^self specializedArea x: someThing > > (Ref: #os, #vm) > > I don't think step 1 is mandatory. Actually I would say it should be forbidden. > Why should Smalltalk be a facade for every library in the system? > > I agree however that for library/method rewrites we should at least keep the old interface if possible. Now, when it happens that the new API is not compatible with the old one, only the migration should be nicely documented... Not every library, and definitely not as the default for any new functionality, but (imho) at least for preexisting functionality on SmalltalkImage that is moved, ref the original discussion: http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-td1574575i20.html <http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-td1574575i20.html> > > > I've run into a few cases where this is not the case when moving to Pharo 5, should they be changed, or am I wrong, and the procedure above is no longer considered valuable? > > Case 1: > SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) > self deprecated: > 'Please use registration methods provided in SessionManager / registration category.', > String cr, > 'ex: SessionManager default unregisterClassNamed: self name'. > > There's a new #session accessor on SmalltalkImage, but... > 1) SessionManager does not implement a backwards compatible protocol. > > I'd say that's life... > > 2) The deprecated message above is wrong, the Smalltalk session unregisterClassNamed: is preferrable to referencing the class directly. > > And that this requires a fix om the docs. > > 3) The deprecated method does nothing, rather than redirect to the new place. Silent errors when deprecation warnings are turned of, yay. > > Well redirection should be done wether it is possible. > But if it is not, then the method should be cancelled with an exception? Like that even if the deprecation is ignored, the error does not go silent. I guess the point I was trying to make; even if it's rare to unregister from startup/shutdown individually, and the new recommended approach is to use unregisterClass: to do both, when you replace such core functionality, you *need* to provide a backwards compatible protocol as well (especially since there's no 1-1 mapping between existing and previous behaviour), not just refer to unregisterClass: and let the old usage (potentially) silently do nothing. When there's still a caller in the *base* image (#deinstall in InputEventFetcher), you know the frequency by which this code is actually called/tested. Sampling the Pharo5 version of a major package like Seaside, the included GrPharoPlatform still does removeFromStartUpList: anObject "Remove anObject from the startup list in the system." Smalltalk removeFromStartUpList: anObject Would it be tested in time for the version where the deprecated method is actually removed? No one knows. But in the mean time, trying to remove Seaside, or any other existing package which tries to play nice and unregister itself, will not clean up correctly when you press proceed, as is expected when you encounter a deprecation warning. The less nice alternative, is indeed to raise an exception after the deprecation, indicating this *must* be rewritten now to continue working as intended. > > 4) The deprecation message uses the deprecated form which does not include the parameters needed to know when to expect it removed forever. > > Did not get this one deprecated: tells you nothing about when, and in which version, the method was considered obsolete. By using the expanded deprecated:on:in:, it's easier to tell when it should be expected to be gone for good (for instance, if it says it was deprecated in: 'Pharo5', you'd expect to have to migrate code by the time Pharo7 rolls around) http://forum.world.st/what-about-deprecating-deprecated-td2306905.html > > > Also, the corresponding addTo... methods have not been deprecated, but redirect to SessionManager directly rather than through #session... > > Case 2: > EndianDetector: Used to be Smalltalk #endianness > > 1) The method on SmalltalkImage has simply been removed, no deprecation. > > I agree we should've deprecated. > Maybe we can deprecate it now in Pharo6 for Pharo7 (before removing the methods from Smalltalk definitively?) Not backporting such a missing deprecation to Pharo5 would sort of defeat the purpose of using deprecations to ensure a smooth upgrade experience, no? Cheers, Henry

Jan. 4, 2017

Re: [Pharo-dev] [Ann] Calypso system browser

by Denis Kudriashov

2017-01-04 8:32 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Also... > 8. Select ASTCacheReset > 9. Tick "inherited methods" > 10. Select #addIfNotPresent:ifPresentDo: without expanding any method > groups > ==> "inherited methods" and "extensions" are highlighted, which is okay > > but now... > 11. Expanding "extensions" > ==> Collections not highlighted, and extensions lost it highlight > Yes, it is known issue which I think explain others from your feedback too. Problem that now highlighting is not restored as selection. For example if you select accessing group and then expand inherited methods (which is first) selection will stay correct although accessing is now shifted. I not put same logic for highlighting just to save time. It is feature kind of "nice to have" but not really critical IMO. So it is for future

Jan. 4, 2017

Re: [Pharo-dev] [Ann] Calypso system browser

by Ben Coman

On Tue, Jan 3, 2017 at 8:40 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-12-31 16:57 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> Maybe it is the checkbox doubling the size of the whitespace (??) such >> that it would be better placed to the right (??), or maybe I just need >> to adapt. > > > In last version (dev) I push it to the right. That for giving this a go. It looks good when "inherited methods" is unexpanded. When expanded, at first I wasn't sure about the other checkboxes remaining left-aligned, but I think its fine and actually an advantage since "inherited methods" checkbox is a slightly different function to the per-superclass checkbox. btw I think pushing the per-superclass checkbox to the right wouldn't work. > Also I moved extensions group to the top at second place. I think this works well. > And all groups now support highlighting as owner of selected methods Cool. I tried this... 1. Select AST-Core > ASTCache 2. Tick "inherited methods" then expand it and "extensions" 3. Select #addIfNotPresent:ifPresentDo: ==> highlights "inherited methods", "Collection", "extensions" and "Fuel" Not sure if all four should be highlighted but its okay. and something tricky... 4. Select Fuel 5. Select #fuelAccept: 6. Click Fuel to unselect it ==> Fuel keeps a highlight, which is very nice. however... 7. Select Fuel again and unclick it ==> Fuel has lost its highlight. Also... 8. Select ASTCacheReset 9. Tick "inherited methods" 10. Select #addIfNotPresent:ifPresentDo: without expanding any method groups ==> "inherited methods" and "extensions" are highlighted, which is okay but now... 11. Expanding "extensions" ==> Collections not highlighted, and extensions lost it highlight 12. Expanding "inherited methods" ==> WeakIdentityKeyDictionary highlighted rather than expected Collection highlight "inherited methods" remains highlighted, which is different behaviour to "extensions" at step 11. cheers -ben

Jan. 4, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Eliot Miranda

Hi Guille, On Tue, Jan 3, 2017 at 1:40 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> > [snip] > 2) Accessor remains the same, but all references in the base image has >>> been rewritten to use EndianDetector directly... >>> 2) Would not Smalltalk platform be a reasonable place to put this >>> responsiblity, letting it use an EndianDetector behind the scenes? Both the >>> preexisting #endianness, as well as the new #isLittleEndian and >>> #isBigEndian? >> >> > Here I am not sure of agreeing. > > Going through Smalltalk is evil. > > Maybe asking the platform is better, to hide the "EndianDetector". > > >> +1. EndianDetector is a monstrosity. >> > > Ok, EndianDetector is maybe an ugly name. > No, that's not the reason this is a monstrosity. Extracting one method into a class of its own, a method that answers something trivial, that as Hwnrik points out is logically to do with Smalltalk platform, that's what's a monstrosity. I could care less what its called. But it gratuitously broke lots of code that used it in a very ugly way while adding a large overhead for trivial functionality. It's a monstrosity. > But it has a reason to be. Before, to test endianess the system used a > Bitmap. And we wanted a standalone class that we could use whether Bitmap > is there or not (by becoming an instance of a float into a bitmap or so... > I don't remember the details). > Yeah, well, there's a VM parameter, there are no end of ways to compute it, but the point is, it can be a single method on Smalltalk platform not a whole class. _,,,^..^,,,_ best, Eliot

Jan. 4, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Guillermo Polito

On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> It was my impression there was a procedure in place earlier for moving >> methods from SmalltalkImage to classes with a more singular responsibility >> that ensures a smooth upgrade experience; >> > Yes, but it depends mostly on the user and there is no automated check for it... So it happens that people (myself also) sometimes remove stuff without going into the deprecation phase... :/ > 1) create accessor method on Smalltalk (if none of the existing are >> appropriate) >> 2) implement the old methods on new class in backwards compatability >> category >> 3) Deprecate method on SmalltalkImage, on the form: >> doX: someThing >> self deprecated: 'Use Smalltalk specializedArea x: someThing >> instead' on: 'foo' in: 'bar'. >> ^self specializedArea x: someThing >> >> (Ref: #os, #vm) >> > I don't think step 1 is mandatory. Actually I would say it should be forbidden. Why should Smalltalk be a facade for every library in the system? I agree however that for library/method rewrites we should at least keep the old interface if possible. Now, when it happens that the new API is not compatible with the old one, only the migration should be nicely documented... >> I've run into a few cases where this is not the case when moving to Pharo >> 5, should they be changed, or am I wrong, and the procedure above is no >> longer considered valuable? >> >> Case 1: >> SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) >> self deprecated: >> 'Please use registration methods provided in >> SessionManager / registration category.', >> String cr, >> 'ex: SessionManager default unregisterClassNamed: self >> name'. >> >> There's a new #session accessor on SmalltalkImage, but... >> 1) SessionManager does not implement a backwards compatible protocol. >> > I'd say that's life... > 2) The deprecated message above is wrong, the Smalltalk session >> unregisterClassNamed: is preferrable to referencing the class directly. >> > And that this requires a fix om the docs. > 3) The deprecated method does nothing, rather than redirect to the new >> place. Silent errors when deprecation warnings are turned of, yay. >> > Well redirection should be done wether it is possible. But if it is not, then the method should be cancelled with an exception? Like that even if the deprecation is ignored, the error does not go silent. > 4) The deprecation message uses the deprecated form which does not include >> the parameters needed to know when to expect it removed forever. >> > Did not get this one > >> Also, the corresponding addTo... methods have not been deprecated, but >> redirect to SessionManager directly rather than through #session... >> >> Case 2: >> EndianDetector: Used to be Smalltalk #endianness >> >> 1) The method on SmalltalkImage has simply been removed, no deprecation. >> > I agree we should've deprecated. Maybe we can deprecate it now in Pharo6 for Pharo7 (before removing the methods from Smalltalk definitively?) > 2) Accessor remains the same, but all references in the base image has >> been rewritten to use EndianDetector directly... >> 2) Would not Smalltalk platform be a reasonable place to put this >> responsiblity, letting it use an EndianDetector behind the scenes? Both the >> preexisting #endianness, as well as the new #isLittleEndian and >> #isBigEndian? > > Here I am not sure of agreeing. Going through Smalltalk is evil. Maybe asking the platform is better, to hide the "EndianDetector". > +1. EndianDetector is a monstrosity. > Ok, EndianDetector is maybe an ugly name. But it has a reason to be. Before, to test endianess the system used a Bitmap. And we wanted a standalone class that we could use whether Bitmap is there or not (by becoming an instance of a float into a bitmap or so... I don't remember the details). So, it is a badly name little child only. We can rename it. Suggestions? > >> Cheers, >> Henry >> > > _,,,^..^,,,_ > best, Eliot >

Jan. 3, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Eliot Miranda

On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > It was my impression there was a procedure in place earlier for moving > methods from SmalltalkImage to classes with a more singular responsibility > that ensures a smooth upgrade experience; > 1) create accessor method on Smalltalk (if none of the existing are > appropriate) > 2) implement the old methods on new class in backwards compatability > category > 3) Deprecate method on SmalltalkImage, on the form: > doX: someThing > self deprecated: 'Use Smalltalk specializedArea x: someThing > instead' on: 'foo' in: 'bar'. > ^self specializedArea x: someThing > > (Ref: #os, #vm) > > I've run into a few cases where this is not the case when moving to Pharo > 5, should they be changed, or am I wrong, and the procedure above is no > longer considered valuable? > > Case 1: > SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) > self deprecated: > 'Please use registration methods provided in > SessionManager / registration category.', > String cr, > 'ex: SessionManager default unregisterClassNamed: self > name'. > > There's a new #session accessor on SmalltalkImage, but... > 1) SessionManager does not implement a backwards compatible protocol. > 2) The deprecated message above is wrong, the Smalltalk session > unregisterClassNamed: is preferrable to referencing the class directly. > 3) The deprecated method does nothing, rather than redirect to the new > place. Silent errors when deprecation warnings are turned of, yay. > 4) The deprecation message uses the deprecated form which does not include > the parameters needed to know when to expect it removed forever. > > Also, the corresponding addTo... methods have not been deprecated, but > redirect to SessionManager directly rather than through #session... > > Case 2: > EndianDetector: Used to be Smalltalk #endianness > > 1) The method on SmalltalkImage has simply been removed, no deprecation. > 2) Accessor remains the same, but all references in the base image has > been rewritten to use EndianDetector directly... > 2) Would not Smalltalk platform be a reasonable place to put this > responsiblity, letting it use an EndianDetector behind the scenes? Both the > preexisting #endianness, as well as the new #isLittleEndian and > #isBigEndian? > +1. EndianDetector is a monstrosity. > Cheers, > Henry > _,,,^..^,,,_ best, Eliot

Jan. 3, 2017

Re: [Pharo-dev] Redline: Talking Runtime basics ...

by stepharong

Thanks Guillermo. @pharoers I think that one of the key point to understand what we did is that we decided not to go deep first to produce a minimal minimal image. Because we have one: Guille produced candlelight and it is working on Pharo and it can do beep and nothing else because it does not have a compiler and no UI :) But it is working and small, we debuged it writing on files. Guilllermo also produced images that are 11k :) yes 11k but doing only 2+3 or any addition not producing large integers. So we decided to deliver a working bootstrap with a process to maintain it and improve it over the year. This is the key catch. Making sure that we are able to remove / repackage it and continue to clean it while building the entire pharo on it. Stef On Tue, 03 Jan 2017 16:38:30 +0100, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Phil, > > On Sat, Dec 31, 2016 at 10:14 AM, philippe.back(a)highoctane.be > <philippe.back(a)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-DependencyAnalysi… > > See what the dependency graph looks of the bootstrap > > https://ci.inria.fr/pharo/view/6.0-Analysis/job/Pharo-6.0-DependencyAnalysi… > > 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/66666949ceffbd806ff39188548d6579… > > 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(a)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(a)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-Bootstr… >>>> >>>> -- Pavel >>>> >>>> 2016-12-30 18:13 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>> >>>>> On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james(a)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.t… >>>>> >>>>> 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 >>>> >>>> > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 3, 2017