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

Dictionary newFromKeys: andValues:

by Stephane Ducasse

Hi I was looking at the Dictionary instance creation API and I would like to add newFromKeys:andValues: Because I do not see why I have to create associations when I have already the two collections. What do you think? Stef

Dec. 15, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

On Thu, Dec 14, 2017 at 2:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Works for me :-) > > This update will simplify things a lot because as soon as you create a > branch from FogBugz issue, the Iceberg does following [1]: > - fetches the pharo-project repository > - checkouts to the particular commit from which the image was bootstrapped > - creates a new branch > > That means that: > - you do not need to keep your fork up-to-date manually > - things should be cleaner Ahhhhhh it looks like a huge improvement. Because keeping manually our fork was a pain. I will use my super nasty powers and try because I have some pending fixes :) > So as soon as your local repository is created as clone of your fork > repository (your fork is origin), you do not need to set push and pull > target nor synchronize your fork with pharo-project repository. > > Esteban will fix me if I'm wrong ;-) > > [1] see IcePharoCreateBranchFromIssue>>#createBranchNamed: > > -- Pavel > > > 2017-12-14 13:19 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> Hi! >> >> Iâm working on simplifying the contribution process, after collecting >> opinions/experiences last couple of months. >> As you know, Pharo contribution process is still WIP and we aim to have it >> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >> the âsystem repositoriesâ was a bad idea because it introduced extra and non >> standard âpathâ to contribution, I managed to remove that to reestablish >> âthe regular wayâ: you will now need to add pharo repository just as any >> other repository you add, by cloning or adding local repository. >> >> I took Guilleâs doc and moved it to pharo project (it does not has sense >> to have it living in a contributorâs repository when is so important). You >> can find it here: >> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> This document is also updated to reveal this new process, please read it. >> >> How to update your startup scripts? >> Some people has added startup scripts to easy the first part of >> contribution. Instead enabling system repositories, etc. you now need to >> replace that with this: >> >> (IceRepositoryCreator new >> location: '/path/to/pharo-project/pharo' asFileReference; >> subdirectory: 'src'; >> createRepository) >> register >> >> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is >> very important that document reflects new process and works reliable in >> different scenarios (I validated it on macOS and Windows, and assumed it >> worked fine on linux but you knowâ¦ bad assumptions is the base of failure ;) >> ) >> >> Iâm eager to hear your feedback and continue enhancing the process. >> >> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >> >> cheers! >> Esteban > >

Dec. 15, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

Cumbersome was not the first adjective that came to me mind :) but you know it :) On Thu, Dec 14, 2017 at 1:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi! > > Iâm working on simplifying the contribution process, after collecting > opinions/experiences last couple of months. > As you know, Pharo contribution process is still WIP and we aim to have it > as smooth as possible for Pharo 7.0 release. Now, after observe the idea of > the âsystem repositoriesâ was a bad idea because it introduced extra and non > standard âpathâ to contribution, I managed to remove that to reestablish > âthe regular wayâ: you will now need to add pharo repository just as any > other repository you add, by cloning or adding local repository. > > I took Guilleâs doc and moved it to pharo project (it does not has sense to > have it living in a contributorâs repository when is so important). You can > find it here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > This document is also updated to reveal this new process, please read it. > > How to update your startup scripts? > Some people has added startup scripts to easy the first part of > contribution. Instead enabling system repositories, etc. you now need to > replace that with this: > > (IceRepositoryCreator new > location: '/path/to/pharo-project/pharo' asFileReference; > subdirectory: 'src'; > createRepository) > register > > PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very > important that document reflects new process and works reliable in different > scenarios (I validated it on macOS and Windows, and assumed it worked fine > on linux but you knowâ¦ bad assumptions is the base of failure ;) ) > > Iâm eager to hear your feedback and continue enhancing the process. > > (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) > > cheers! > Esteban

Dec. 15, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Esteban, I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps. I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one. Cheers, Alistair On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi! > > Iâm working on simplifying the contribution process, after collecting > opinions/experiences last couple of months. > As you know, Pharo contribution process is still WIP and we aim to have it > as smooth as possible for Pharo 7.0 release. Now, after observe the idea of > the âsystem repositoriesâ was a bad idea because it introduced extra and non > standard âpathâ to contribution, I managed to remove that to reestablish > âthe regular wayâ: you will now need to add pharo repository just as any > other repository you add, by cloning or adding local repository. > > I took Guilleâs doc and moved it to pharo project (it does not has sense to > have it living in a contributorâs repository when is so important). You can > find it here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > This document is also updated to reveal this new process, please read it. > > How to update your startup scripts? > Some people has added startup scripts to easy the first part of > contribution. Instead enabling system repositories, etc. you now need to > replace that with this: > > (IceRepositoryCreator new > location: '/path/to/pharo-project/pharo' asFileReference; > subdirectory: 'src'; > createRepository) > register > > PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very > important that document reflects new process and works reliable in different > scenarios (I validated it on macOS and Windows, and assumed it worked fine > on linux but you knowâ¦ bad assumptions is the base of failure ;) ) > > Iâm eager to hear your feedback and continue enhancing the process. > > (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) > > cheers! > Esteban

Dec. 15, 2017

Re: [Pharo-dev] 60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Ben Coman

On 15 December 2017 at 19:28, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 December 2017 at 19:41, Ben Coman <btc(a)openinworld.com> wrote: > >> In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... >> 1. Open Playground >> 2. Evaluate... OpalCompler recompileAll >> 3. Try opening Iceberg, Playground or Spotter. >> ==> Error: A class or trait does not properly resolve a conflict between >> multiple traits it uses. >> >> System Browser, Test Runner and Monticello are okay. >> >> 60528 (32bit) is okay (what is different between 32bit and 64bit?) >> >> 60521-64 is broken >> 60520-64 is okay >> >> https://pharo.manuscript.com/f/cases/20867/OpalCompiler-reco >> mpileAll-GLM-trait-conflict >> >> cheers -ben >> >> > I've got to the limit of where I can go with this one, so I'm seeking > help. Copied from issue... > > Having isolated the build where the issue was introduced, > normally I'd search the mail list for "60521" to find reports like > these... > 60519 http://forum.world.st/update-6-0-60519-td5007498.html > 60522 http://forum.world.st/update-6-0-60522-td5056051.html > > and try applying the modifications to 60521 > manually to 60520 to see if I can break it. > But 60520 and 60521 reports are missing. > > Comparing file dates (http://files.pharo.org/image/60/) > 2017.11.07 60520 > 2017.11.29 60521 > 2017.11.29 60522 > > to Fogbuz... https://pharo.fogbugz.com/f/filters/?closedInLast=4& > fClosedBugs=true&ixFixFor=22&sColumns=Category-Favorite- > Case-TitleComment-Status-Priority-DateClosed-Milestone& > sSorts=DateClosed.descending-LastUpdated.descending&sView=grid-flat > > Issue Closed Note > 18760 2017.11.29 merged in 60522 > 20339 2017.11.29 resolved Fix To Include - Monkey was failing - removed > the testRenameClassUsingClass > 20250 2017.11.28 closed Fixed Upstream > 20260 2017.11.28 reopened, originally merged 2017.08.22 > 20586 2017.11.23 closed Wont Fix > 20709 2017.11.18 merged in ???? (and there is no such Slice in > Pharo6Inbox) > 20119 2017.11.07 merged in 60520 (pull/492 ??) > > applying Slice-20339 on top of 60520 doesn't break "OpalCompiler > recompileAll". > So I'm at a loss how to continue. > Maybe it was just a momentary glitch :( > and builds > 60520 need to be thrown out and their integrations re-run > with either same or newer build numbers. > > So we don't create additional rework, there should be no further > integrations to Pharo6, > so I've tentatively moved priority to "Show. Stopper" (not that that will > necessarily have any great effect with development moved to Pharo 7). > > ============================================ > > Putting a halt in CompiledMethod class >> conflictMarker > prior to running "OpalCompiler recompileAll" > stops in... > GLMBrick(Behaviour)>>#updateMethodDictionarySelector: #innerBounds > > where it calls... > methodDescription effectiveMethod > > which is... > TraitDescription>>#effectiveMethod > "Return the effective compiled method of this method description." > | method | > method := self providedMethod. > method isNil ifFalse: [^ method]. > method := self conflictMethod. "<<<<<<<<<" > method isNil ifFalse: [^ method]. > ^ self requiredMethod. > > with ivar... > .locatedMethods={GLMBrickGeometryTrait>>#innerBounds . > GLMBrickLayoutTrait>>#innerBounds} > > and evaluting "self providedMethod"... > TraitMethodDescription>>#providedLocatedMethod > | locatedMethod aLocatedMethod refOrigin | > locatedMethod := nil. > self locatedMethods ifEmpty: [ ^ nil]. > self locatedMethods size > 1 > ifTrue: [ > aLocatedMethod := self locatedMethods anyOne. > refOrigin := (aLocatedMethod methodClass >> aLocatedMethod > selector) origin. > (self locatedMethods allSatisfy: [:each | each origin == > refOrigin]) > ifTrue: [^ aLocatedMethod]. > ]. > self locatedMethods do: [:each | > each isProvided ifTrue: [ > locatedMethod isNil ifFalse: [^nil]. > locatedMethod := each] > ]. > ^locatedMethod > > shows... > * all locatedMethods don't have the same origin > i.e. self locatedMethods collect: [:e|e origin] > ==> {GLMBrickGeometryTrait, GLMBrickLayoutTrait} > > * all locatedMethods are provided > i.e. self asOrderedCollection collect: [:e|e isProvided] > ==> {true.true} > > Now System Browser shows these definitions... > 1. (T)GLMBrickGeometeryTrait>>#innerBounds > ^ self wrappedBounds innerBounds > > 2. (T)GLMBrickLayoutTrait>>#innerBounds > ^ self explicitRequirement > > 3. GLMBrickedMorph subclass: #GLMBrick > uses: GLMBrickPropertiesTrait > + GLMBrickLayoutTrait > + GLMBrickStructureTrait > + (GLMBrickGeometryTrait - {#privateBounds:}) > instanceVariableNames: 'brickBounds brickApi' > classVariableNames: '' > package: 'Glamour-Morphic-Brick-Widgets-Core' > > which from my limited understanding of Traits seems to have been > correctly flagged as a conflict. > But image 60520-64 similarly has... > > 1. (T)GLMBrickGeometeryTrait>>#innerBounds > ^ self wrappedBounds innerBounds > > 2. (T)GLMBrickLayoutTrait>>#innerBounds > ^ self explicitRequirement > > 3. GLMBrickedMorph subclass: #GLMBrick > uses: GLMBrickPropertiesTrait > + GLMBrickLayoutTrait > + GLMBrickStructureTrait > + (GLMBrickGeometryTrait - {#privateBounds:}) > instanceVariableNames: 'brickBounds brickApi' > classVariableNames: '' > package: 'Glamour-Morphic-Brick-Widgets-Core' > > so is the question really why 60520 doesn't flag a conflict? > > > Also my meta question... why did I need to debug deep into the compiler > to tune in on definitions [1.], [2.] & [3.] ? i.e why have... > > TraitMethodDescription>>#conflictMethod > | binary numberOfArguments | > self isConflict ifFalse: [^nil]. > binary := self isBinarySelector. > numberOfArguments := self numberOfArguments. > ^self > generateMethod: self selector > withMarker: CompiledMethod conflictMarker > forArgs: numberOfArguments > binary: binary > > and not... > > TraitMethodDescription>>#conflictMethod > self isConflict ifFalse: [^nil]. > self raise: CompileTimeTraitErrorReportWithGUI > > =================== > > P.S. Maybe not related, at various times stepping through "self > providedMethod" > for ivar "locatedMethod" the pane inspector showed "error obtaining field > value" > (in the 60521 image) > > > Here's hoping some guru can pick it up from there. > cheers -ben > So I noticed System Browser show GLMBrick is using the #innerBounds method from GLMBrickGeometryTrait. So guessing part of solving this is probably to redefine (in a fresh image)... GLMBrickedMorph subclass: #GLMBrick uses: GLMBrickPropertiesTrait + (GLMBrickLayoutTrait - {#innerBounds}) + GLMBrickStructureTrait + (GLMBrickGeometryTrait - {#privateBounds:}) instanceVariableNames: 'brickBounds brickApi' classVariableNames: '' package: 'Glamour-Morphic-Brick-Widgets-Core' but saving this produces error "Instance of GLMPrivacyAgreementBrick did not understand #onRemovedFrom:" and the Quality Assistant Nautilius Plugin dies. Trying to bypass this in another fresh image, opening System Browser then clicking on Settings in the QA area error when the Settings display. cheers -ben

Dec. 15, 2017

Re: [Pharo-dev] 60528-64 OpalCompiler recompileAll ==> GLM trait conflict

by Ben Coman

On 13 December 2017 at 19:41, Ben Coman <btc(a)openinworld.com> wrote: > In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04... > 1. Open Playground > 2. Evaluate... OpalCompler recompileAll > 3. Try opening Iceberg, Playground or Spotter. > ==> Error: A class or trait does not properly resolve a conflict between > multiple traits it uses. > > System Browser, Test Runner and Monticello are okay. > > 60528 (32bit) is okay (what is different between 32bit and 64bit?) > > 60521-64 is broken > 60520-64 is okay > > https://pharo.manuscript.com/f/cases/20867/OpalCompiler- > recompileAll-GLM-trait-conflict > > cheers -ben > > I've got to the limit of where I can go with this one, so I'm seeking help. Copied from issue... Having isolated the build where the issue was introduced, normally I'd search the mail list for "60521" to find reports like these... 60519 http://forum.world.st/update-6-0-60519-td5007498.html 60522 http://forum.world.st/update-6-0-60522-td5056051.html and try applying the modifications to 60521 manually to 60520 to see if I can break it. But 60520 and 60521 reports are missing. Comparing file dates (http://files.pharo.org/image/60/) 2017.11.07 60520 2017.11.29 60521 2017.11.29 60522 to Fogbuz... https://pharo.fogbugz.com/f/filters/?closedInLast=4&fClosedBugs=true&ixFixF… Issue Closed Note 18760 2017.11.29 merged in 60522 20339 2017.11.29 resolved Fix To Include - Monkey was failing - removed the testRenameClassUsingClass 20250 2017.11.28 closed Fixed Upstream 20260 2017.11.28 reopened, originally merged 2017.08.22 20586 2017.11.23 closed Wont Fix 20709 2017.11.18 merged in ???? (and there is no such Slice in Pharo6Inbox) 20119 2017.11.07 merged in 60520 (pull/492 ??) applying Slice-20339 on top of 60520 doesn't break "OpalCompiler recompileAll". So I'm at a loss how to continue. Maybe it was just a momentary glitch :( and builds > 60520 need to be thrown out and their integrations re-run with either same or newer build numbers. So we don't create additional rework, there should be no further integrations to Pharo6, so I've tentatively moved priority to "Show. Stopper" (not that that will necessarily have any great effect with development moved to Pharo 7). ============================================ Putting a halt in CompiledMethod class >> conflictMarker prior to running "OpalCompiler recompileAll" stops in... GLMBrick(Behaviour)>>#updateMethodDictionarySelector: #innerBounds where it calls... methodDescription effectiveMethod which is... TraitDescription>>#effectiveMethod "Return the effective compiled method of this method description." | method | method := self providedMethod. method isNil ifFalse: [^ method]. method := self conflictMethod. "<<<<<<<<<" method isNil ifFalse: [^ method]. ^ self requiredMethod. with ivar... .locatedMethods={GLMBrickGeometryTrait>>#innerBounds . GLMBrickLayoutTrait>>#innerBounds} and evaluting "self providedMethod"... TraitMethodDescription>>#providedLocatedMethod | locatedMethod aLocatedMethod refOrigin | locatedMethod := nil. self locatedMethods ifEmpty: [ ^ nil]. self locatedMethods size > 1 ifTrue: [ aLocatedMethod := self locatedMethods anyOne. refOrigin := (aLocatedMethod methodClass >> aLocatedMethod selector) origin. (self locatedMethods allSatisfy: [:each | each origin == refOrigin]) ifTrue: [^ aLocatedMethod]. ]. self locatedMethods do: [:each | each isProvided ifTrue: [ locatedMethod isNil ifFalse: [^nil]. locatedMethod := each] ]. ^locatedMethod shows... * all locatedMethods don't have the same origin i.e. self locatedMethods collect: [:e|e origin] ==> {GLMBrickGeometryTrait, GLMBrickLayoutTrait} * all locatedMethods are provided i.e. self asOrderedCollection collect: [:e|e isProvided] ==> {true.true} Now System Browser shows these definitions... 1. (T)GLMBrickGeometeryTrait>>#innerBounds ^ self wrappedBounds innerBounds 2. (T)GLMBrickLayoutTrait>>#innerBounds ^ self explicitRequirement 3. GLMBrickedMorph subclass: #GLMBrick uses: GLMBrickPropertiesTrait + GLMBrickLayoutTrait + GLMBrickStructureTrait + (GLMBrickGeometryTrait - {#privateBounds:}) instanceVariableNames: 'brickBounds brickApi' classVariableNames: '' package: 'Glamour-Morphic-Brick-Widgets-Core' which from my limited understanding of Traits seems to have been correctly flagged as a conflict. But image 60520-64 similarly has... 1. (T)GLMBrickGeometeryTrait>>#innerBounds ^ self wrappedBounds innerBounds 2. (T)GLMBrickLayoutTrait>>#innerBounds ^ self explicitRequirement 3. GLMBrickedMorph subclass: #GLMBrick uses: GLMBrickPropertiesTrait + GLMBrickLayoutTrait + GLMBrickStructureTrait + (GLMBrickGeometryTrait - {#privateBounds:}) instanceVariableNames: 'brickBounds brickApi' classVariableNames: '' package: 'Glamour-Morphic-Brick-Widgets-Core' so is the question really why 60520 doesn't flag a conflict? Also my meta question... why did I need to debug deep into the compiler to tune in on definitions [1.], [2.] & [3.] ? i.e why have... TraitMethodDescription>>#conflictMethod | binary numberOfArguments | self isConflict ifFalse: [^nil]. binary := self isBinarySelector. numberOfArguments := self numberOfArguments. ^self generateMethod: self selector withMarker: CompiledMethod conflictMarker forArgs: numberOfArguments binary: binary and not... TraitMethodDescription>>#conflictMethod self isConflict ifFalse: [^nil]. self raise: CompileTimeTraitErrorReportWithGUI =================== P.S. Maybe not related, at various times stepping through "self providedMethod" for ivar "locatedMethod" the pane inspector showed "error obtaining field value" (in the 60521 image) Here's hoping some guru can pick it up from there. cheers -ben

Dec. 15, 2017

[Pharo 7.0-dev] Build #385: 20859-Update-Hermes-to-detect-new-Undeclared-and-overwritten-methods-and-classes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #385 was: SUCCESS. The Pull Request #597 was integrated: "20859-Update-Hermes-to-detect-new-Undeclared-and-overwritten-methods-and-classes" Pull request url: https://github.com/pharo-project/pharo/pull/597 Issue Url: https://pharo.fogbugz.com/f/cases/20859 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 15, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Juraj Kubelka

Hi Denis, I use it without critiques and it works fine. I have some observations: - test cases in an abstract class can be executed, it might be disabled as it does not make sense to execute them - test cases defined in a superclass cannot be executed separately (only as all test cases by clicking on the class icon) - it might be a good option to be able to execute failing test cases (there is a dedicated method group that appears in such situations) - and maybe also when browsing âinherited methodsâ Thanks for the great job! Juraj > On Dec 14, 2017, at 14:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I found some performance problem with this version. > I know the reason. It will be fixed soon. > Now you can try disable critiques plugin with github instructions. > > 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > > 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > Hi Denis, > > Congratulations on the new release! Two quick question: > > 1) does this work on latest Pharo 6.1 ; > > Yes > > 2) Is it safe to update images with Calypso already installed by doing the same baseline loading as the original installation ? > > I think not. But I not try. I just have impression that complex updates are not properly work in Pharo. All package structure is changed and it can be a problem for such update. > > > Thanks > > On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > Hello. > > I glad announce new Calypso version. It is a big refactoring on navigation model and browser pluggability. > > Look for details in my blog http://dionisiydk.blogspot.fr/2017/12/new-calypso-version-08-is-out.html <http://dionisiydk.blogspot.fr/2017/12/new-calypso-version-08-is-out.html>. > > Now I start document new design and will post progress on it. > > Notice: this version is not adopted for TelePharo and Cargo. It will be done soon. > > Best regards, > Denis > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > >

Dec. 14, 2017

Re: [Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

by Aliaksei Syrel

Hi, GLMRubScrolledTextBrick is a wrapper around RubScrollTextMorph. I see that it is a common practice in Pharo to implement decorator / wrapper pattern using doesNotUnderstand:. Reference: - AthensWrappedWorldDisplay - DictionaryValueHolder - MorphicTreeAdapter - RubEditingArea - RubParagraphDecorator - RTShapeBuilder - RTShowLabel Is there a better way to implement a decorator or a wrapper around the object with many api methods rather then doesNotUnderstand:? Cheers, Alex On 9 December 2017 at 17:45, Henrik-Nergaard <draagren(a)outlook.com> wrote: > >>GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I > cannot find the method. > This is because it is implemented in RubScrollTextMorph. > GLMRubScrolledTextBrick implements #doesNotUnderstand: to send it to the > rubric object. > see: > https://pharo.fogbugz.com/f/cases/17888/GLMRubScrolledTextBr > ick-relies-on-dnu-delegation > > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Dec. 14, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Denis Kudriashov

I found some performance problem with this version. I know the reason. It will be fixed soon. Now you can try disable critiques plugin with github instructions. 2017-12-12 13:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi Denis, >> >> Congratulations on the new release! Two quick question: >> > > >> 1) does this work on latest Pharo 6.1 ; >> > > Yes > > >> 2) Is it safe to update images with Calypso already installed by doing >> the same baseline loading as the original installation ? >> > > I think not. But I not try. I just have impression that complex updates > are not properly work in Pharo. All package structure is changed and it can > be a problem for such update. > > >> >> Thanks >> >> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hello. >>> >>> I glad announce new Calypso version. It is a big refactoring on >>> navigation model and browser pluggability. >>> >>> Look for details in my blog http://dionisiydk.blogspot.fr/ >>> 2017/12/new-calypso-version-08-is-out.html. >>> >>> Now I start document new design and will post progress on it. >>> >>> Notice: this version is not adopted for TelePharo and Cargo. It will be >>> done soon. >>> >>> Best regards, >>> Denis >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Dec. 14, 2017