- Pharo-dev - lists.pharo.org

Esteban's ChangeLog week of 19 February 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 19 February 2018 to 25 February 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=19/2/2018&to=25/2/2018 ChangeLog ========= 21 February 2018: ----------------- * So well... I spent some hours yesterday to make the backport of Iceberg 0.6.8 to Pharo 6.1 to actually happen. Now it should be there ;) cheers! Esteban

Feb. 26, 2018

Re: [Pharo-dev] Pharo 7.0 does not includes "Metacello support for GitFileTree metadata-less mode"

by Cyril Ferlicot D.

Le 20/02/2018 Ã 14:29, Juraj Kubelka a Ã©critÂ : > Hi, > > > In the following email [1], Dale Henrichs explains that there was an update to support correctly GitFileTree metadata-less mode. While I can see the mentioned class MetacelloCypressBaselineProject in Pharo 6.1, I cannot find it in Pharo 7.0. > > Is it supposed to include the Metacello update to Pharo 7.0 too? > > Thanks! > Juraj > > [1] http://forum.world.st/ANN-Metacello-support-for-GitFileTree-metadata-less-m… > Hi! This support is in this PR: https://github.com/pharo-project/pharo/pull/950 It was not added in Pharo 7 during the last sync but was in Pharo 6.1. I hope in the future we will depend on Metacello as a project during the bootstrap instead of having the sources directly in the Pharo repository. It will help but it needs work. -- Cyril Ferlicot https://ferlicot.fr

Feb. 25, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #593: 21390-Do-not-store-any-non-literals-in-the-literal-array

by Stephane Ducasse

I really like this idea of read only literals :) Tx for pushing it. On Thu, Feb 22, 2018 at 11:52 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > This fixes the Reflectivity compiler to not store normal objects in the literalArrayâ¦ so instead of âpushLiteral:â is now uses > âpushLiteralVariable:â. > > This is needed as we do now have a compiler option to compile methods with read-only literals. > > Marcus > >> On 22 Feb 2018, at 11:45, ci-pharo-ci-jenkins2(a)inria.fr wrote: >> >> There is a new Pharo build available! >> >> The status of the build #593 was: SUCCESS. >> >> The Pull Request #932 was integrated: "21390-Do-not-store-any-non-literals-in-the-literal-array" >> Pull request url: https://github.com/pharo-project/pharo/pull/932 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/21390 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > >

Feb. 25, 2018

Re: [Pharo-dev] Pharo 7.0 does not includes "Metacello support for GitFileTree metadata-less mode"

by Stephane Ducasse

I do not know the detail but we will have metacello around for some years so better have an updated version :) On Tue, Feb 20, 2018 at 2:29 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi, > > > In the following email [1], Dale Henrichs explains that there was an update to support correctly GitFileTree metadata-less mode. While I can see the mentioned class MetacelloCypressBaselineProject in Pharo 6.1, I cannot find it in Pharo 7.0. > > Is it supposed to include the Metacello update to Pharo 7.0 too? > > Thanks! > Juraj > > [1] http://forum.world.st/ANN-Metacello-support-for-GitFileTree-metadata-less-m…

Feb. 25, 2018

Re: [Pharo-dev] Monticello file out bug during bootstrap

by Stephane Ducasse

Now I do not understand what is this classSide here. If we have a trait apparently we do not file out a class method as class but as classSide.... Super strange. Stef On Sun, Feb 25, 2018 at 9:46 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Apparently this method was like that in Pharo 60 so this is not my edit. > > fullClassName > "Using #class selector for classes for backwards compatibility" > > ^ self classIsMeta > ifFalse: [self className] > ifTrue: [ > (self actualClass isNil or: [ self actualClass isTrait ]) > ifFalse: [self className, ' class'] > ifTrue: [self className, ' classSide']] > > Now it does not mean that this is not a bug I introduced. > > > > > On Sun, Feb 25, 2018 at 9:42 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> the problem is here of course but I need my mind back (In the train to >> home). ... >> >> >> MCMethodDefinition>>fullClassName >> "Using #class selector for classes for backwards compatibility" >> >> ^ self classIsMeta >> ifFalse: [self className] >> ifTrue: [ >> (self actualClass isNil or: [ self actualClass isTrait ]) >> ifFalse: [self className, ' class'] >> ifTrue: [self className, ' classSide']] >> >> >> >> >> >> On Sun, Feb 25, 2018 at 9:41 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> Hi Alistair >>> >>> This is my mistake! I introduced this bug when I transformed >>> theMetaClass to classSide >>> Now I was paying super attention and I did not touch theMetaClass even >>> when class would have been far enough. >>> So do you have a scenario? So that I can try to have a look. >>> Unfortunately I was away from home and lab since a week and I may have >>> problem to allocate concentrated time. >>> But I will try. >>> Tx for reporting this! >>> >>> Stef >>> >>> >>> On Sun, Feb 25, 2018 at 3:48 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>> Hi Everyone, >>>> >>>> I'm working on integrating the file attribute primitives in to the main >>>> code during bootstrap. >>>> >>>> Class methods for FileAttributesPluginPrims are written out as: >>>> >>>> >>>> >>>> !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp: 'nil'! >>>> reset >>>> "Reload the masks" >>>> >>>> Default := nil.! ! >>>> >>>> >>>> As you can see, the class name is written with "classSide" instead of >>>> "class", resulting in the method quietly being ignored during file in. >>>> >>>> This comes about in: >>>> >>>> >>>> MCStWriter>>writeMethodPreamble: definition >>>> self chunkContents: [:str | >>>> stream bang. >>>> str nextPutAll: definition fullClassName; >>>> nextPutAll: ' methodsFor: '; >>>> nextPutAll: definition category asString printString; >>>> nextPutAll: ' stamp: '; >>>> nextPutAll: definition timeStamp asString printString >>>> ] >>>> >>>> >>>> which calls: >>>> >>>> >>>> MCMethodDefinition>>fullClassName >>>> "Using #class selector for classes for backwards compatibility" >>>> >>>> ^ self classIsMeta >>>> ifFalse: [self className] >>>> ifTrue: [ >>>> (self actualClass isNil or: [ self actualClass isTrait ]) >>>> ifFalse: [self className, ' class'] >>>> ifTrue: [self className, ' classSide']] >>>> >>>> >>>> >>>> Because FileAttributesPluginPrims doesn't exist in the image (the code >>>> is read in from the git repository and being written out to a .st file), >>>> #actualClass returns nil, resulting in "classSide" being used instead of >>>> "class". >>>> >>>> I've never seen "classSide" used in chunk format. Is there any time >>>> "classSide" is valid, and any suggestions on how this should be fixed? >>>> (My first thought is to just change MCStWriter>>writeMethodPreamble: to >>>> only write "class"). >>>> >>>> >>>> >>>> Thanks, >>>> Alistair >>>>

Feb. 25, 2018

Re: [Pharo-dev] Monticello file out bug during bootstrap

by Stephane Ducasse

Apparently this method was like that in Pharo 60 so this is not my edit. fullClassName "Using #class selector for classes for backwards compatibility" ^ self classIsMeta ifFalse: [self className] ifTrue: [ (self actualClass isNil or: [ self actualClass isTrait ]) ifFalse: [self className, ' class'] ifTrue: [self className, ' classSide']] Now it does not mean that this is not a bug I introduced. On Sun, Feb 25, 2018 at 9:42 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > the problem is here of course but I need my mind back (In the train to > home). ... > > > MCMethodDefinition>>fullClassName > "Using #class selector for classes for backwards compatibility" > > ^ self classIsMeta > ifFalse: [self className] > ifTrue: [ > (self actualClass isNil or: [ self actualClass isTrait ]) > ifFalse: [self className, ' class'] > ifTrue: [self className, ' classSide']] > > > > > > On Sun, Feb 25, 2018 at 9:41 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Hi Alistair >> >> This is my mistake! I introduced this bug when I transformed >> theMetaClass to classSide >> Now I was paying super attention and I did not touch theMetaClass even >> when class would have been far enough. >> So do you have a scenario? So that I can try to have a look. >> Unfortunately I was away from home and lab since a week and I may have >> problem to allocate concentrated time. >> But I will try. >> Tx for reporting this! >> >> Stef >> >> >> On Sun, Feb 25, 2018 at 3:48 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> Hi Everyone, >>> >>> I'm working on integrating the file attribute primitives in to the main >>> code during bootstrap. >>> >>> Class methods for FileAttributesPluginPrims are written out as: >>> >>> >>> >>> !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp: 'nil'! >>> reset >>> "Reload the masks" >>> >>> Default := nil.! ! >>> >>> >>> As you can see, the class name is written with "classSide" instead of >>> "class", resulting in the method quietly being ignored during file in. >>> >>> This comes about in: >>> >>> >>> MCStWriter>>writeMethodPreamble: definition >>> self chunkContents: [:str | >>> stream bang. >>> str nextPutAll: definition fullClassName; >>> nextPutAll: ' methodsFor: '; >>> nextPutAll: definition category asString printString; >>> nextPutAll: ' stamp: '; >>> nextPutAll: definition timeStamp asString printString >>> ] >>> >>> >>> which calls: >>> >>> >>> MCMethodDefinition>>fullClassName >>> "Using #class selector for classes for backwards compatibility" >>> >>> ^ self classIsMeta >>> ifFalse: [self className] >>> ifTrue: [ >>> (self actualClass isNil or: [ self actualClass isTrait ]) >>> ifFalse: [self className, ' class'] >>> ifTrue: [self className, ' classSide']] >>> >>> >>> >>> Because FileAttributesPluginPrims doesn't exist in the image (the code >>> is read in from the git repository and being written out to a .st file), >>> #actualClass returns nil, resulting in "classSide" being used instead of >>> "class". >>> >>> I've never seen "classSide" used in chunk format. Is there any time >>> "classSide" is valid, and any suggestions on how this should be fixed? >>> (My first thought is to just change MCStWriter>>writeMethodPreamble: to >>> only write "class"). >>> >>> >>> >>> Thanks, >>> Alistair >>>

Feb. 25, 2018

Re: [Pharo-dev] Simplified AST "Suggestions" menu definitions

by Peter UhnÃ¡k

This is cool! Could this "help" also be included in Pharo's Help Browser? Peter On Sun, Feb 25, 2018 at 9:30 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Marcus I thought that the context was about to represent what the > tools selected like the class currently selected. > You have this information in the AST? > > Stef > > On Sun, Feb 25, 2018 at 9:25 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > This is cool! > > This is also why I started to do a pass (first reverse engineering how > > ecompletion is working) > > We should regularly improve the infrastructure of our tools to enable > > the next generation. > > I love that! > > > > marcus because indeed this code needs love. > > > > On Sun, Feb 25, 2018 at 7:23 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, > >> > >> I started to simplidy the âSmartSuggestionsâ code. What does it do? It > adds the âsuggestionsâ menu to the editor context menu, > >> this shows operations that make sense for the AST node a the cursor > position. > >> > >> -> removed lots of state from SugsSuggestion (label, position, â¦). > Instead uses methods. > >> -> simplified how to define new suggestions. > >> > >> Here is a small example: a menu to browse the defintion of variables. > First we need to make a suclass of > >> SugsSuggestion. > >> > >> 1) add a subclass of SugsSuggestion > >> > >> SugsSuggestion subclass: #SugsBrowseVariableDefintion > >> instanceVariableNames: '' > >> classVariableNames: '' > >> package: 'SmartSuggestions-Suggestion' > >> > >> > >> 2) define on the class side a method that defines for which AST nodes > you want the menu > >> to be shown. Here is is all Variable Nodes: > >> > >> nodes > >> ^{RBVariableNode} > >> > >> 3) On the instance side, we just need to define a label > >> > >> > >> label > >> ^ 'Browse Variable definition' translated > >> > >> 4) and we need to define #execute which just implements what is > supposed to happen: > >> > >> execute > >> | semanticVariable | > >> semanticVariable := context selectedNode binding. > >> semanticVariable isInstance ifTrue: [ ^semanticVariable slot > definingClass browse ]. > >> semanticVariable isTemp ifTrue: [ ^semanticVariable scope node > method browse ]. > >> semanticVariable isClassVariable ifTrue: [ ^semanticVariable > scope getClass browse ]. > >> semanticVariable isGlobal ifTrue: [ Smalltalk globals inspect ]. > >> > >> DONE. The simplified SmartSuggestions are in the latest Pharo7, so you > can play with the code > >> there, the SugsBrowseVariableDefintion is not (yet?) in Pharo7. (maybe > someone wants to submit it?) > >> > >> > >> Next steps: > >> - get rid of the âContextâ and instead embed the AST in the > editor. This will be nice for *many* > >> other clients (AST Node navigation, code completion, syntax > highlightingâ¦) > >> > >> - liberate the AST menu entries from the âsuggestionsâ submenu: > they should just appear > >> in the standard editor context menu. > >> > >> > >> Marcus > >

Feb. 25, 2018

Re: [Pharo-dev] Monticello file out bug during bootstrap

by Stephane Ducasse

the problem is here of course but I need my mind back (In the train to home). ... MCMethodDefinition>>fullClassName "Using #class selector for classes for backwards compatibility" ^ self classIsMeta ifFalse: [self className] ifTrue: [ (self actualClass isNil or: [ self actualClass isTrait ]) ifFalse: [self className, ' class'] ifTrue: [self className, ' classSide']] On Sun, Feb 25, 2018 at 9:41 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Alistair > > This is my mistake! I introduced this bug when I transformed > theMetaClass to classSide > Now I was paying super attention and I did not touch theMetaClass even > when class would have been far enough. > So do you have a scenario? So that I can try to have a look. > Unfortunately I was away from home and lab since a week and I may have > problem to allocate concentrated time. > But I will try. > Tx for reporting this! > > Stef > > > On Sun, Feb 25, 2018 at 3:48 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Everyone, >> >> I'm working on integrating the file attribute primitives in to the main >> code during bootstrap. >> >> Class methods for FileAttributesPluginPrims are written out as: >> >> >> >> !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp: 'nil'! >> reset >> "Reload the masks" >> >> Default := nil.! ! >> >> >> As you can see, the class name is written with "classSide" instead of >> "class", resulting in the method quietly being ignored during file in. >> >> This comes about in: >> >> >> MCStWriter>>writeMethodPreamble: definition >> self chunkContents: [:str | >> stream bang. >> str nextPutAll: definition fullClassName; >> nextPutAll: ' methodsFor: '; >> nextPutAll: definition category asString printString; >> nextPutAll: ' stamp: '; >> nextPutAll: definition timeStamp asString printString >> ] >> >> >> which calls: >> >> >> MCMethodDefinition>>fullClassName >> "Using #class selector for classes for backwards compatibility" >> >> ^ self classIsMeta >> ifFalse: [self className] >> ifTrue: [ >> (self actualClass isNil or: [ self actualClass isTrait ]) >> ifFalse: [self className, ' class'] >> ifTrue: [self className, ' classSide']] >> >> >> >> Because FileAttributesPluginPrims doesn't exist in the image (the code >> is read in from the git repository and being written out to a .st file), >> #actualClass returns nil, resulting in "classSide" being used instead of >> "class". >> >> I've never seen "classSide" used in chunk format. Is there any time >> "classSide" is valid, and any suggestions on how this should be fixed? >> (My first thought is to just change MCStWriter>>writeMethodPreamble: to >> only write "class"). >> >> >> >> Thanks, >> Alistair >>

Feb. 25, 2018

Re: [Pharo-dev] Monticello file out bug during bootstrap

by Stephane Ducasse

Hi Alistair This is my mistake! I introduced this bug when I transformed theMetaClass to classSide Now I was paying super attention and I did not touch theMetaClass even when class would have been far enough. So do you have a scenario? So that I can try to have a look. Unfortunately I was away from home and lab since a week and I may have problem to allocate concentrated time. But I will try. Tx for reporting this! Stef On Sun, Feb 25, 2018 at 3:48 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Everyone, > > I'm working on integrating the file attribute primitives in to the main > code during bootstrap. > > Class methods for FileAttributesPluginPrims are written out as: > > > > !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp: 'nil'! > reset > "Reload the masks" > > Default := nil.! ! > > > As you can see, the class name is written with "classSide" instead of > "class", resulting in the method quietly being ignored during file in. > > This comes about in: > > > MCStWriter>>writeMethodPreamble: definition > self chunkContents: [:str | > stream bang. > str nextPutAll: definition fullClassName; > nextPutAll: ' methodsFor: '; > nextPutAll: definition category asString printString; > nextPutAll: ' stamp: '; > nextPutAll: definition timeStamp asString printString > ] > > > which calls: > > > MCMethodDefinition>>fullClassName > "Using #class selector for classes for backwards compatibility" > > ^ self classIsMeta > ifFalse: [self className] > ifTrue: [ > (self actualClass isNil or: [ self actualClass isTrait ]) > ifFalse: [self className, ' class'] > ifTrue: [self className, ' classSide']] > > > > Because FileAttributesPluginPrims doesn't exist in the image (the code > is read in from the git repository and being written out to a .st file), > #actualClass returns nil, resulting in "classSide" being used instead of > "class". > > I've never seen "classSide" used in chunk format. Is there any time > "classSide" is valid, and any suggestions on how this should be fixed? > (My first thought is to just change MCStWriter>>writeMethodPreamble: to > only write "class"). > > > > Thanks, > Alistair >

Feb. 25, 2018

Re: [Pharo-dev] Pull Request 20898-MultiByteFileStream-upToAll-does-not-work-correctly-with-UTF-8

by Stephane Ducasse

Hi bernhard sorry. Yes we should have a look. Stef On Sun, Feb 25, 2018 at 4:12 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Hi all, > > Can somebody please help me get my bugfix from December integrated? For some reason CI fails and I have no idea how to debug that. :-( > https://github.com/pharo-project/pharo/pull/632 > > Bernhard

Feb. 25, 2018