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

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

by Guillermo Polito

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-Bootstrap/lastSuccessfulBuild/artifact/bootstrap.zip >> > >> > -- 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-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 >> > >> > >> >

Jan. 3, 2017

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

by Denis Kudriashov

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. Also I moved extensions group to the top at second place. And all groups now support highlighting as owner of selected methods

Jan. 3, 2017

Deprecations on Smalltalk Image in Pharo 5

by Henrik Johansen

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? Cheers, Henry

Jan. 3, 2017

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Hilaire

In Europe a lot of people take one week off during the Christmas time. In academic and education, most have two weeks off. I am suspecting tomorrow the Pharo lists will return to its crazy flow of messages ;-) My best wishes to all of you for a healthy and happy 2017 year! Hilaire Le 29/12/2016 Ã 19:04, Dale Henrichs a Ã©crit : > No messages on list since yesterday morning? > > Dale -- Dr. Geo http://drgeo.eu

Jan. 2, 2017

Re: [Pharo-dev] :: Separator in class names

by GÃ¶ran Krampe

Hi all! On 01/02/2017 02:16 PM, Henrik Nergaard wrote: > +100 > > I do not think that there should be restrictions on the number of :: separators. > Modified to allow #A::B::Object etc.. Just wanted to mention that ... I am amused! :) My Namespace implementation in Squeak from a bunch of years back used this notation. And I am also using it in Spry, but as syntactic sugar for Dictionary access so that: aDict at: #x ...can be expressed as: aDict::x regards, GÃ¶ran

Jan. 2, 2017

Re: [Pharo-dev] :: Separator in class names

by Henrik Nergaard

+100 I do not think that there should be restrictions on the number of :: separators. Modified to allow #A::B::Object etc.. ------------------------------- isValidGlobalName self ifEmpty: [ ^ false ]. "reserverd default names" self = #NameOfSubclass ifTrue: [ ^ false ]. self = #TNameOfTrait ifTrue: [ ^ false ]. (self splitOn: '::') allSatisfy: [: part | Character supportsNonASCII ifTrue: [ (part first isLetter and: [ part first isUppercase]) and: [ part allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]] ] ifFalse: [ (part first between: $A and: $Z) and: [ part allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]] ] ] ------------------------------------- As long as the :: only serve as a visual separator between "namespace(s)" and class name then it should not be harder much more harder than to do a #copyReplaceAll: '::' with: '' when filing in|out the class to use in a system that do not allow :: in class names. Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Torsten Bergmann Sendt: 02 January 2017 12:57 Til: Pharo Development List <pharo-dev(a)lists.pharo.org> Emne: Re: [Pharo-dev] :: Separator in class names First of all: happy new year to all Pharo supporters! Not many of you answered this thread in 2016. Maybe I have more luck in 2017 ;) So please tell me about the requested change of #isValidGlobalName to allow an optional separator in class names. I already communicated possible usages and still do not share the fears of Dale that we easily get unportable code with that. I guess it will allow us to experiment much easier. Thanks for taking the time to response and share your own thoughts! Bye Torsten

Jan. 2, 2017

Re: [Pharo-dev] :: Separator in class names

by Norbert Hartl

> Am 02.01.2017 um 12:57 schrieb Torsten Bergmann <astares(a)gmx.de>: > > First of all: happy new year to all Pharo supporters! > > Not many of you answered this thread in 2016. Maybe > I have more luck in 2017 ;) > > So please tell me about the requested change of #isValidGlobalName > to allow an optional separator in class names. I already communicated > possible usages and still do not share the fears of Dale that we > easily get unportable code with that. I guess it will allow us to > experiment much easier. > If we allow it now what would be the scenario rolling that back? Taking it away again seems to be much harder. My gut feeling tells me this would be a change we will regret later. Norbert > Thanks for taking the time to response and share your own thoughts! > > Bye > Torsten > >

Jan. 2, 2017

Re: [Pharo-dev] :: Separator in class names

by Torsten Bergmann

First of all: happy new year to all Pharo supporters! Not many of you answered this thread in 2016. Maybe I have more luck in 2017 ;) So please tell me about the requested change of #isValidGlobalName to allow an optional separator in class names. I already communicated possible usages and still do not share the fears of Dale that we easily get unportable code with that. I guess it will allow us to experiment much easier. Thanks for taking the time to response and share your own thoughts! Bye Torsten

Jan. 2, 2017

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

by Yuriy Tymchuk

> On 30 Dec 2016, at 19:18, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Yuriy > > 2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Wow, Denis, this is super cool! I really like that you have these âNew methodâ tabs because I find it super confusing that you have to either select no methods or change the existing method to create a new one. > > I would be really happy on any feedback about the Renraku (critiques model) integration as I want to make it easily usably by any tool, and feedback from tool developers is very valuable. > > Now critiques are only supported as in MessageBrowser because it was just one line of code. By the way, for classes it works in the same way. In fact the method the annotates a text model is defined in object, so theoretically every object that can produce critiques (renraku properties in general) can add then to a text area. > > To support Nautilus style (footer pane) we first need to decide who is responsible for it. Because In Calypso there are two ways how to achieve it: it could be part of method/class editor tool or it could be global browser footer pane independent from tabs. So it needs some analysis. > For example first way will hide critiques when user switch to comment tab or other tab which is not method/class editor. Is it desired or not? And what is desired? I donât think that we have to have a list at the bottom, but what we can do is to make some plugins that will show all the critiques for a class or package, etcâ¦ > > Another thing from you which I want support is matcher/rewriter tool. I opened issue for this https://github.com/dionisiydk/Calypso/issues/10. <https://github.com/dionisiydk/Calypso/issues/10.> I can help you with this :) > > Anyway all these features require documentation from me on how extend things. It is first in my todo.

Jan. 2, 2017

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

by James Ladd

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(a)openinworld.com> wrote: > >> On Sat, Dec 31, 2016 at 5:53 AM, James Ladd <ladd.james(a)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(a)highoctane.be > <philippe.back(a)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" >

Jan. 1, 2017