- Pharo-dev - lists.pharo.org

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

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

by Damien Cassou

### Here's what I've been up to since the last WhatsUp: - migration of launcher's job to pharo/ Jenkins (instead of pharo-contribution) - launchers are now uploaded to http://files.pharo.org/platform/launcher/blessed/ - update of the mac os launcher's .app - package pharo-vm and pharo-launcher for nixos (will be in the next release of NixOS later this month) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 6, 2014

Android VM update

by Jean Baptiste Arnaud

Hi, I just comeback from holiday, and I realise that I do not have done a announcement yet. Now the prototype of the Pharo Android VM work. - Event is managed - Resolution up to 1080p is managed. - Most of the plugins seems worked. - File plugin allow you to browse the sd card. Next: - fix the generator then jenkins. Merge with Pharo/Cog main and Make it available for the public. - die under the mountain of bug entry open by the first public release. First release will be perfect and bugless. - allow easy personalisation of the packaging, allow you to rename and change icon easily (for your own application, Squeak/Pharo Android VM, Phratch, DR geo, etc.). - refined the jumpout logic for have a better graphical update and a better idle process (less consumption, faster reactive UI, UI updating during heavy computation, etc. ). - package the android feature in the android plugin, show/hide the keyboard via primitive, etc. etc. + init configuration. - a lot of cool idea but later Here is a youtube video to show the result: http://youtu.be/lB9UV9Z7Kss You can forward this to other mailing list, I do not have access to all of them. Best Regards Dr Arnaud jbaptiste.arnaud(a)gmail.com

Oct. 6, 2014

Problems with loading Voyage-Mongo

by phil＠highoctane.be

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/ Loaded -> ConfigurationOfMongoTalk-NorbertHartl.32 --- 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/ 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/ Fetched -> Mongo-BSON-NorbertHartl.40 --- 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/ Fetched -> MongoQueries-NorbertHartl.7 --- 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/ [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