October 2014 - Pharo-dev - lists.pharo.org

GT-Inspector for SmallDictionary

by Sven Van Caekenberghe

Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.64 Author: SvenVanCaekenberghe Time: 6 October 2014, 1:52:40.640585 pm UUID: 060f943c-eae0-426b-8cb2-8ac2e559ba44 Ancestors: GT-InspectorExtensions-Core-AndreiChis.63 Copy Dictionary>>#gtInspectorItemsIn: to SmallDictionary Remove Dictionary>>#gtInspectorVariableValuePairs as it is not needed (showing the named instance variables is OK) Sven

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector silly titles

by Sven Van Caekenberghe

On 06 Oct 2014, at 13:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > It is not crazy. You will see that these will follow just like creating new presentations will follow. I didn't mean the idea was crazy, I understand and agree with the reasoning, it is just that expecting all existing code to change is totally unrealistic. > But, we can certainly make it easier. I like the idea of removing the class prefix if it exists. It can be done in the default implementation from Object>>#gtDisplayOn: OK, propose something and we'll see. > Doru > > On Mon, Oct 6, 2014 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > So what, everybody has to either rewrite all old printStrings or add new gtDisplayStrings ? That is crazy, especially for cross platform packages. > > It would be quite easy to rewrite GTInspector>>#printObjectAsAnItem: to not add the prefix if it is already present. > > On 06 Oct 2014, at 13:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Yes, the label does introduce redundancy in some cases, but that is because the use of printString has to be rethought :) > > > > printString was used for a long time as a primary inspection tool. Because of that it tries to do too much (like adding the class name), and it is certainly not suitable for a label. > > > > gtDisplayString is meant for labeling the content of the object. It is used also for things like a list. As soon as you will do something with your objects, you will want to have something smaller. There is no need to have the class part of that string. Relying on that convention is brittle, as it is easy for people to not have the class name in there. But, for an inspector, having the class at all times is a prerequisite, so that will be displayed always separately (to ensure that the right information is offered). > > > > gtDisplayString relies on printString by default, so people can provide the labels at their convenience. > > > > Cheers, > > Doru > > > > > > On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I think the titles of GT-Inspector windows/panes are a bit silly: > > > > <Screen Shot 2014-10-06 at 13.13.41.png> > > > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a Dictionary(...))' where the class name is repeated. > > > > I think it is very important to honour the standard/general Smalltalk approach and assume the #printString already contains the class name. If not, you are basically punishing everybody who went through the trouble of writing custom #printString implementation (like me, I do this for most classes). > > > > I saw the whole #display thing, but you can't force everybody to rewrite #printString to #gtDisplayString or whatever. > > > > Sven > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector silly titles

by Tudor Girba

It is not crazy. You will see that these will follow just like creating new presentations will follow. But, we can certainly make it easier. I like the idea of removing the class prefix if it exists. It can be done in the default implementation from Object>>#gtDisplayOn: Doru On Mon, Oct 6, 2014 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > So what, everybody has to either rewrite all old printStrings or add new > gtDisplayStrings ? That is crazy, especially for cross platform packages. > > It would be quite easy to rewrite GTInspector>>#printObjectAsAnItem: to > not add the prefix if it is already present. > > On 06 Oct 2014, at 13:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Yes, the label does introduce redundancy in some cases, but that is > because the use of printString has to be rethought :) > > > > printString was used for a long time as a primary inspection tool. > Because of that it tries to do too much (like adding the class name), and > it is certainly not suitable for a label. > > > > gtDisplayString is meant for labeling the content of the object. It is > used also for things like a list. As soon as you will do something with > your objects, you will want to have something smaller. There is no need to > have the class part of that string. Relying on that convention is brittle, > as it is easy for people to not have the class name in there. But, for an > inspector, having the class at all times is a prerequisite, so that will be > displayed always separately (to ensure that the right information is > offered). > > > > gtDisplayString relies on printString by default, so people can provide > the labels at their convenience. > > > > Cheers, > > Doru > > > > > > On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I think the titles of GT-Inspector windows/panes are a bit silly: > > > > <Screen Shot 2014-10-06 at 13.13.41.png> > > > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a > Dictionary(...))' where the class name is repeated. > > > > I think it is very important to honour the standard/general Smalltalk > approach and assume the #printString already contains the class name. If > not, you are basically punishing everybody who went through the trouble of > writing custom #printString implementation (like me, I do this for most > classes). > > > > I saw the whole #display thing, but you can't force everybody to rewrite > #printString to #gtDisplayString or whatever. > > > > Sven > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector silly titles

by Sven Van Caekenberghe

So what, everybody has to either rewrite all old printStrings or add new gtDisplayStrings ? That is crazy, especially for cross platform packages. It would be quite easy to rewrite GTInspector>>#printObjectAsAnItem: to not add the prefix if it is already present. On 06 Oct 2014, at 13:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Yes, the label does introduce redundancy in some cases, but that is because the use of printString has to be rethought :) > > printString was used for a long time as a primary inspection tool. Because of that it tries to do too much (like adding the class name), and it is certainly not suitable for a label. > > gtDisplayString is meant for labeling the content of the object. It is used also for things like a list. As soon as you will do something with your objects, you will want to have something smaller. There is no need to have the class part of that string. Relying on that convention is brittle, as it is easy for people to not have the class name in there. But, for an inspector, having the class at all times is a prerequisite, so that will be displayed always separately (to ensure that the right information is offered). > > gtDisplayString relies on printString by default, so people can provide the labels at their convenience. > > Cheers, > Doru > > > On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think the titles of GT-Inspector windows/panes are a bit silly: > > <Screen Shot 2014-10-06 at 13.13.41.png> > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a Dictionary(...))' where the class name is repeated. > > I think it is very important to honour the standard/general Smalltalk approach and assume the #printString already contains the class name. If not, you are basically punishing everybody who went through the trouble of writing custom #printString implementation (like me, I do this for most classes). > > I saw the whole #display thing, but you can't force everybody to rewrite #printString to #gtDisplayString or whatever. > > Sven > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector silly titles

by Tudor Girba

Hi, Yes, the label does introduce redundancy in some cases, but that is because the use of printString has to be rethought :) printString was used for a long time as a primary inspection tool. Because of that it tries to do too much (like adding the class name), and it is certainly not suitable for a label. gtDisplayString is meant for labeling the content of the object. It is used also for things like a list. As soon as you will do something with your objects, you will want to have something smaller. There is no need to have the class part of that string. Relying on that convention is brittle, as it is easy for people to not have the class name in there. But, for an inspector, having the class at all times is a prerequisite, so that will be displayed always separately (to ensure that the right information is offered). gtDisplayString relies on printString by default, so people can provide the labels at their convenience. Cheers, Doru On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think the titles of GT-Inspector windows/panes are a bit silly: > > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a Dictionary(...))' > where the class name is repeated. > > I think it is very important to honour the standard/general Smalltalk > approach and assume the #printString already contains the class name. If > not, you are basically punishing everybody who went through the trouble of > writing custom #printString implementation (like me, I do this for most > classes). > > I saw the whole #display thing, but you can't force everybody to rewrite > #printString to #gtDisplayString or whatever. > > Sven > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] Problems with loading Voyage-Mongo

by Esteban Lorenzano

there was a typo in the configuration. it should work now. > On 06 Oct 2014, at 10:13, phil(a)highoctane.be wrote: > > My CI started failing on Voyage-Mongo. > > This used to work as of last week. > > Help... > > Loading 1.3.1 of ConfigurationOfVoyageMongo... > Fetched -> ConfigurationOfMongoTalk-NorbertHartl.32 --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> > Loaded -> ConfigurationOfMongoTalk-NorbertHartl.32 --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> --- /var/lib/jenkins/jobs/BaseWorker/workspace/package-cache > Project: Magritte3 stable [3.1.5] > Project: Grease release1.1 [1.1.11] > Project: Seaside3 release3.1 [3.1.3] > Project: Grease release1.1 [1.1.11] > Project: Grease Core Tests release1.1 [1.1.11] > Project: SPort2 2.34 > Fetched -> FileSystem-Legacy-JohanBrichau.2 --- http://smalltalkhub.com/mc/PharoExtras/FileSystemLegacy/main/ <http://smalltalkhub.com/mc/PharoExtras/FileSystemLegacy/main/> --- http://smalltalkhub.com/mc/PharoExtras/FileSystemLegacy/main/ <http://smalltalkhub.com/mc/PharoExtras/FileSystemLegacy/main/> > Project: Zinc Project stable [2.5.3] > Project: Grease Slime release1.1 [1.1.11] > Project: MongoTalk stable [1.6.1] > Project: Grease 1.1.8 [1.1.11] > Fetched -> Mongo-Squeak-NorbertHartl.16 --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> > Fetched -> Mongo-BSON-NorbertHartl.40 --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> > Fetched -> Mongo-Core-NorbertHartl.37 --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> > Fetched -> MongoQueries-NorbertHartl.7 --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> --- http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/ <http://smalltalkhub.com/mc/MongoTalkTeam/mongotalk/main/> > ...RETRY-> Voyage-Model-Core-EstebanLorenzano.16 > ...RETRY-> Voyage-Model-Core-EstebanLorenzano.16 > ...FAILED-> Voyage-Model-Core-EstebanLorenzano.16'Errors in script loaded from /var/lib/jenkins/jobs/BaseWorker/workspace/BuildBaseWorker.st' > [31mCould not resolve: Voyage-Model-Core [ Voyage-Model-Core-EstebanLorenzano.16] in /var/lib/jenkins/jobs/BaseWorker/workspace/package-cache http://smalltalkhub.com/mc/estebanlm/Voyage/main/ <http://smalltalkhub.com/mc/estebanlm/Voyage/main/> > [0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: in Block: linearLoadPackageSpec: packageSpec gofer: gofer... > MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: > MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: > MetacelloPackageSpec>>loadUsing:gofer: > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [ :pkg | pkg loadUsing: self gofer: gofer ] > OrderedCollection>>do: > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: > MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: in Block: [ super linearLoadPackageSpecs: packageSpecs repos...etc... > BlockClosure>>ensure: > MetacelloLoaderPolicy>>pushLoadDirective:during: > MetacelloLoaderPolicy>>pushLinearLoadDirectivesDuring:for: > MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load > MetacelloMCVersionSpecLoader>>load > MetacelloMCVersion>>executeLoadFromArray: > MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ :dict | ^ self executeLoadFromArray: anArray ] > MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ] > BlockClosure>>on:do: > MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ ... > BlockClosure>>ensure: > MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ ... > MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: > MetacelloMCVersion>>fetchRequiredFromArray: > MetacelloMCVersion>>doLoadRequiredFromArray: in Block: [ ... > BlockClosure>>ensure: > MetacelloMCVersion>>doLoadRequiredFromArray: > MetacelloMCVersion>>load > GoferMetacelloLoad>>loadConfiguration

Oct. 6, 2014

GT-Inspector silly titles

by Sven Van Caekenberghe

I think the titles of GT-Inspector windows/panes are a bit silly: Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a Dictionary(...))' where the class name is repeated. I think it is very important to honour the standard/general Smalltalk approach and assume the #printString already contains the class name. If not, you are basically punishing everybody who went through the trouble of writing custom #printString implementation (like me, I do this for most classes). I saw the whole #display thing, but you can't force everybody to rewrite #printString to #gtDisplayString or whatever. Sven

Oct. 6, 2014

Re: [Pharo-dev] WhatsUp from: 2014-10-06 until: 2014-10-19

by Thierry Goubier

2014-10-06 7:00 GMT+02:00 <seaside(a)rmod.lille.inria.fr>: > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > - Fighting with the AST code generation in SmaCC with the help of John Brant - Write a LLVM-IR parser - Extract the core Tree-based GUI framework from AltBrowser - Write a SmaCC AST to source code Browser (based on the core Tree-based GUI) - Write and document a small tutorial to query, load and display OpenStreetMap shape data in Roassal > > ### What's next, until 2014-10-19 (*): > > - Finish the port of the new SmaCC from Dolphin. - Write a AST splitting algorithm to split too long methods in SmaCC parser generation (would be nice if I could tune it for perf as well). > > (*) we'll be expecting results by then ;) > >

Oct. 6, 2014

Re: [Pharo-dev] WhatsUp from: 2014-10-06 until: 2014-10-19

by Santiago Bragagnolo

### Here's what I've been up to since the last WhatsUp: - Adding a new concept in TaskIT with Guille. to split tasks and futures into task definition and task execution and futures (some part of task and some part of futures went to taskexecution concept) - MetaDDS project, is a DDS (data delivery service) skeleton based on OMG design and ROS design decisions. It has a ROS based implementation ### What's next, until 2014-10-19 (*): - Keep on MetaDDS - finish ROS based DDS - do a Pharo based DDS discovery, ROS compatible (for robotic programming debugging) - Release it for non-standar DDS for Pharo. (*) we'll be expecting results by then ;) 2014-10-06 7:00 GMT+02:00 <seaside(a)rmod.lille.inria.fr>: > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS > > ### What's next, until 2014-10-19 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > > (*) we'll be expecting results by then ;) > >

Oct. 6, 2014

Re: [Pharo-dev] WhatsUp from: 2014-10-06 until: 2014-10-19

by phil＠highoctane.be

### Here's what I've been up to since the last WhatsUp: - Continuing Pharo-based commercial solution development for a customer (Seaside) - Now having a local Jenkins CI building the application from scratch Phil

Oct. 6, 2014