February 2018 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] "curl https://get.pharo.org/64 | bash" does not work (on Mac)

by Stephane Ducasse

which page? https://pharo.fogbugz.com/f/cases/21407/should-update-curl-L-https-get-phar… On Sun, Feb 25, 2018 at 5:49 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Sunday 25 February 2018 09:54 PM, Bernhard Pieber wrote: >> >> Hi all, >> >> Here is the output: >> % Total % Received % Xferd Average Speed Time Time Time >> Current >> Dload Upload Total Spent Left >> Speed >> 100 237 100 237 0 0 899 0 --:--:-- --:--:-- --:--:-- >> 901 >> bash: line 1: syntax error near unexpected token `newline' >> bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' >> >> "curl https://get.pharo.org/64/ | bash" does work, though. It is just that >> in the documentation (https://get.pharo.org/64/) the link has no trailing >> slash. > > > The URL https://get.pharo.org/64 will return a 301 (Moved permanently) > redirect reply. Unlike wget, curl will follow the redirect only if -L option > is given, so > > curl -L https://get.pharo.org/64 | bash > > will also work fine. The document needs to be updated to use -L option for > curl. > > HTH .. Subbu >

Feb. 25, 2018

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

by Stephane Ducasse

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