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

[pharo-project/pharo-core] 3f85b9: 30638

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 3f85b941eaab5b182b2139d9d3f889ad2f059cfa https://github.com/pharo-project/pharo-core/commit/3f85b941eaab5b182b2139d9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-12 (Thu, 12 Dec 2013) Changed paths: M Graphics-Display Objects.package/DisplayMedium.class/instance/private/highLightBitmaps.st M Graphics-Display Objects.package/DisplayMedium.class/instance/private/initializeHighLights.st M Keymapping-Tools-Spec.package/KMDescription.class/class/specs/defaultSpec.st M Keymapping-Tools-Spec.package/KMDescription.class/definition.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/accessing/categoryList.st R Keymapping-Tools-Spec.package/KMDescription.class/instance/accessing/displayList.st R Keymapping-Tools-Spec.package/KMDescription.class/instance/accessing/dropList.st R Keymapping-Tools-Spec.package/KMDescription.class/instance/accessing/list.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/accessing/orderingList.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/accessing/shortcutList.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/collectDescriptionShortcut.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/collectShortcutDescription.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/initCategoryList_.st M Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/initialize.st M Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/initializePresenter.st M Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/initializeWidgets.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/updateShortcutList.st M Keymapping-Tools-Spec.package/KMDescription.class/instance/protocol/categories_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/buildPackageSearch.st A Nautilus.package/PackageTreeNautilusUI.class/instance/package/fileOutPackages_.st M Nautilus.package/extension/RPackage/instance/fileOut.st A Nautilus.package/extension/RPackageTag/instance/fileOut.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script293.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30638.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Settings.package/SettingBrowser.class/README.md Log Message: ----------- 30638 12409 DNU RPackage>>#item when FileOut https://pharo.fogbugz.com/f/cases/12409 12402 Display reverse: leads to error https://pharo.fogbugz.com/f/cases/12402 12384 Package filter dialog: Make the feature more apparent https://pharo.fogbugz.com/f/cases/12384 12396 SystemNavigation class comment uses deprecated message https://pharo.fogbugz.com/f/cases/12396 12094 Drop down does show the items wrongly https://pharo.fogbugz.com/f/cases/12094 http://files.pharo.org/image/30/30638.zip

Dec. 12, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30638 Home: https://github.com/pharo-project/pharo-core

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0004] - Run code using a key command to speedup development

by Max Leske

Nice! Didnât know about that one. On 12.12.2013, at 09:35, Torsten Bergmann <astares(a)gmx.de> wrote: > ----------------------------------------------------------------------------------- > [Pharo Trick: #0004] - Run code using a key command to speedup development > ----------------------------------------------------------------------------------- > Works in: Pharo3.0 Latest update: #30637 but should work in other 2.0/3.0 versions > ----------------------------------------------------------------------------------- > > If you have to run some code very often you typically have to evaluate it > from a workspace over and over again. > But to speed up you can assign a global keymapping which allows to run it with > a simple keyboard shortcut: > > World > on: $a shift command > do: [ Object browse ]. > > Evaluate this once in a workspace. After that anytime you press SHIFT, the > command button (on Windows this is ALT) and A together the block gets evaluated > and your code runs easily. > > Background: > =========== > In Pharo there is a global morph called "World" representing the desktop. > One can assign a key combination to any morph including this world. > If you are interested on the Keymappings then read http://playingwithobjects.wordpress.com/2013/03/19/keymappings-101-for-phar… > for more >

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Tudor Girba

Hi, I meant to say that projects that use pharo should rethink the tests and rules they run in order to ensure that they do not break the Pharo constraints. For example, for Moose, we should have, like Stephan suggested, an integration job that runs all tests in the image (at least). Ideally, it should also run other rules that ensure that the system does not break due to semantic mismatches. If we do it this way, we push the signals upstream and discover the problems sooner. Cheers, Doru On Thu, Dec 12, 2013 at 8:16 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > We need to reconsider how we approach continuous integration for > pharo-based images. > can you expand ? > > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 12, 2013

[Pharo Trick: #0004] - Run code using a key command to speedup development

by Torsten Bergmann

----------------------------------------------------------------------------------- [Pharo Trick: #0004] - Run code using a key command to speedup development ----------------------------------------------------------------------------------- Works in: Pharo3.0 Latest update: #30637 but should work in other 2.0/3.0 versions ----------------------------------------------------------------------------------- If you have to run some code very often you typically have to evaluate it from a workspace over and over again. But to speed up you can assign a global keymapping which allows to run it with a simple keyboard shortcut: World on: $a shift command do: [ Object browse ]. Evaluate this once in a workspace. After that anytime you press SHIFT, the command button (on Windows this is ALT) and A together the block gets evaluated and your code runs easily. Background: =========== In Pharo there is a global morph called "World" representing the desktop. One can assign a key combination to any morph including this world. If you are interested on the Keymappings then read http://playingwithobjects.wordpress.com/2013/03/19/keymappings-101-for-phar… for more

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Marcus Denker

On 12 Dec 2013, at 08:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 12 Dec 2013, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> >> On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 12 Dec 2013, at 06:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> > Hi Stephan, >> > >> > Thanks for pushing the #packages problem. >> > >> > >> > But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo? >> > >> the test tests that there is no #packages in Pharo on the class side other than the one that returns the >> rpackage istance. >> â> this is the case, the test is green. >> >> Oh, so the API classes were fixed. I should have checked before (I just did). Great. >> > But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy > and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever > implements #packages on the class side to return the system concept of package. > > What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? > What is itâs responsibility? wouldnât it be good enough to have a #gpackage method? Another idea: if there is #package in Grease, there should be a class GreasePackage (or Package?). Maybe the API of the class is actually good (grease apis tend to be good). So maybe that API makes sense to be provided by RPackage? The real question is: what is the implementation of #package in Grease, what does it return and what does that object do? Marcus

Dec. 12, 2013

Re: [Pharo-dev] Categories, packages, and tags [cont'd]

by Roberto Minelli

Thx Stef! I also found RPackage organizer packages ;) Cheers, R On Dec 12, 2013, at 8:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 11, 2013, at 1:40 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > >> Hi guys, >> >> I have a question about the new âPackageTreeModelââ¦ >> >> In a previous discussion (https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg09271.html) we discussed about the new package model. Now I understood it but I am wondering one thing. >> >> Since Stef said that categories will be removed, i.e., the ByteSymbol representation of what I used to call packages, I am wondering how one could ask the system which are the installed packages, tags, etc. >> >> In short I want to know which is the best method to ask what used to be âSystemOrganization categoriesâ. > > > PackageOrganizer default blblablabbleb packages

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by StÃ©phane Ducasse

+1 I do not really get it because we mentioned that several times. Grease maintainers should simply produce a new version and Seaside/users should use this new version. >> > But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy > and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever > implements #packages on the class side to return the system concept of package. > > What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? > What is itâs responsibility? wouldnât it be good enough to have a #gpackage method? > > In general, you should evaluate Grease and put all the *concepts* it adds into Pharo itself. This way even > the Core system can use them and everything gets better. > > Marcus

Dec. 12, 2013

Re: [Pharo-dev] Categories, packages, and tags [cont'd]

by StÃ©phane Ducasse

On Dec 11, 2013, at 1:40 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi guys, > > I have a question about the new âPackageTreeModelââ¦ > > In a previous discussion (https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg09271.html) we discussed about the new package model. Now I understood it but I am wondering one thing. > > Since Stef said that categories will be removed, i.e., the ByteSymbol representation of what I used to call packages, I am wondering how one could ask the system which are the installed packages, tags, etc. > > In short I want to know which is the best method to ask what used to be âSystemOrganization categoriesâ. PackageOrganizer default blblablabbleb packages

Dec. 12, 2013

[Pharo Trick: #0003] - halt in button

by StÃ©phane Ducasse

[Pharo Trick: #0003] - halt in button when you are building a user interface and you want to define the behavior of a button but you do not really know. you can use self halt or self inspect and you get an inspector/debugger on your application model Stef

Dec. 12, 2013