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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Paul DeBruicker

Would using Metacello's knowledge of the platform work for you? e.g. (MetacelloPlatform current defaultPlatformAttributes includes: '#squeak') ifTrue:[ ... ] (MetacelloPlatform current defaultPlatformAttributes includes: '#pharo1.2') ..... (MetacelloPlatform current defaultPlatformAttributes includes: '#gemstone2.4') ..... Or are you trying to get very very cross platform (e.g. GST, VAST, etc...) ? Jan Vrany wrote > On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote: >> Itâs true that when you do a lot of cross-dialect development, such a >> method is often what you desire. >> However, I think itâs better to do feature detection instead of dialect >> detection. So, something like: >> >> ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ >> stream := CharacterWriteStream on: (String new: 10) >> ] ifFalse:[ >> stream := WriteStream on: (String new: 10) >> ] >> > > Right, in this example it could eventually work. Another concrete > example I bumped just yesterday. The "feature testing" code would look > like > > ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) > ifTrue:[ > ... > ] ifFalse:[ > ... > ]. > > (true, in this very case you may be able to get around using different > method, but you get the point, no?) > > Some time ago Hilaire posted a very nice, 15 lines long code that does > reliable "feature detection" whether the system is Pharo 2.0 or 3.0 > (or similar, I don't remember exactly). > > Is the interval testing code above more robust? Perhaps. Is it more > readable, more intention revelaling? I doubt it. > > While I can agree that feature testing is is better, however, in my > experience it is very tricky if the code does not provide support for > such tests. > >> And yes: use Grease where applicable. We try to maintain Grease across >> Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. >> > That's great. But having such dependency is exactly what I, and not only > me, don't want if it would be for only one or two methods. The aim is to > provide a simple solution for simple cases, not a silver bullet. > > Jan > > >> cheers >> Johan >> >> On 05 Oct 2014, at 09:00, stepharo < > stepharo@ > > wrote: >> >> > Hi jan >> > >> > Thanks for the proposal. >> > I thought about it and I'm against because it goes again the idea of >> dispatch. >> > I prefer to have a class and some dispatch. Seaside with Grease is the >> way to go from my perspective. >> > Finally I do not want such methods in the systems because I spent my >> time removing isXXXX because of bad design. >> > Let us see what other people think. >> > >> > Stef >> > >> > On 4/10/14 22:14, Jan Vrany wrote: >> >> Hi guys, >> >> >> >> I've just opened: >> >> >> >> >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… >> >> >> >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods >> to >> >> SmalltalkImage to ease multi-dialect development. >> >> >> >> RATIONALE: >> >> >> >> Commonly used approach to solve differences among dialect is to use a >> >> sort of platform object and dispatch there for troublesome operations >> >> that has to be specialized. This platform object is usually in >> platform >> >> specific package. >> >> Other option is to load some library like Grease or Sport. >> >> >> >> The problem of the first approach is that brings to much (unnecessary) >> >> burden when used for two, three things. The amount of of the code and >> >> management is way to bigger then the amount of the code that has to be >> >> specialized. Loading Grease/Sport on the other hand introduces a >> >> dependency on an external package - not worth of for two or three >> >> things. >> >> >> >> The proposed dialect testing messages would allow for simple, >> >> #ifdef-like idiom like: >> >> >> >> | stream | >> >> ... >> >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk >> >> isSomeCoolDialect]) ifTrue:[ >> >> stream := CharacterWriteStream on: (String new: 10) >> >> ] ifFalse:[ >> >> stream := WriteStream on: (String new: 10) >> >> ] >> >> >> >> The #respondsTo: check, while not nice, is required as at the moment >> not >> >> all dialects could be trusted to have these testing messages. >> >> >> >> Putting these methods may not stick with Pharo standard (whatever it >> >> is), but Smalltalk global is probably one of the >> >> very few that are present in pretty much every Smalltalk >> implementation. >> >> Other option would be to place them to the class side of an Object >> >> (which is amost certainly present everywhere), however >> >> >> >> Smalltalk isPharo >> >> >> >> reads better than >> >> >> >> Object isPharo. >> >> >> >> Best, Jan >> >> >> >> >> >> >> > >> > >> >> >> -- View this message in context: http://forum.world.st/Issue-14160-Introduce-isXXX-dialect-testing-methods-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 6, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Alexandre Bergel

Hi Maximiliano! The legend problem is now fixed. Can you double check please? What would be the best way to exclude some methods? This question slightly rephrased: how do you run Hapao? Programmatically or using the World menu? Cheers, Alexandre On Oct 2, 2014, at 11:34 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > Hi Alexandre. > > Yes, now it works. Thank you. But, the box with the legends don't show very well. Like in the attached image: > > <RelativeDate.png> > > And, a question. Is there a way to exclude some methods from the analysis? I have some class methods, used for initialize some singletons for example, that I do not want to be considered for coverage. > > Regards. > Maxi > > 2014-10-02 18:39 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Sorry, we somehow slightly messed up with the configurations. > I just took the last Pharo 4.0, and loaded Roassal2: > > -=-=-=-=-=-=-=-=-=-=-=-= > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > (Smalltalk at: #ConfigurationOfRoassal2) loadDevelopment > -=-=-=-=-=-=-=-=-=-=-=-= > > Then I loaded S2py: > -=-=-=-=-=-=-=-=-=-=-=-= > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'S2py'; > package: 'S2py'; > load. > -=-=-=-=-=-=-=-=-=-=-=-= > > It works here. > Can you confirm? > > Sorry for having taken long to answer... > > Cheers, > Alexandre > > On Sep 24, 2014, at 8:24 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > > > Hi Alexandre, > > > > I want to try Hapao2 to check the coverage level of Chalten, but it's not working (at least for me). > > I load Roassal2 and S2py in a fresh 3.0 image like you say and the new entries appear in the world menu, but the only option that partially works is the one for a particular class (Hapao @ Class ...) and after run all the tests (I see the progress showing that) a MNU is raised in the method #addMethodEdges:scope:view: of Hapa2 class because RTEdgeBuilder is not loaded. > > > > So, could you tell me what I missed please? I need to load another thing, which?, at least the package which defines RTEdgeBuilder. > > > > Thanks for your help. > > > > Regards. > > Maxi > > > > 2014-09-16 20:10 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > Excellent! > > > > Alexandre > > > > Le 16-09-2014 Ã 16:15, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > > >> Great! > >> > >> I will go over it more thoroughly in the following weeks and get back to you with feedback. > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Dear all, > >> > >> We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for Pharo) and Hapao2. > >> Hapao2 is about assessing the test coverage of your code and is a major revamp of Hapao1, which was presented a couple of years ago by Vanessa. > >> Hapao2 does not only list covered and uncovered methods, as most test coverage tool on Earth will do. Hapao gives a great visualization to easily navigate in your code, assess its complexity, and give you a great visual output telling its coverage. > >> > >> You need Roassal in your image: > >> > >> Gofer new smalltalkhubUser: 'ObjectProfile' > >> project: 'Roassal2'; > >> package: 'ConfigurationOfRoassal2'; > >> load. > >> (Smalltalk at: #ConfigurationOfRoassal2) load > >> > >> > >> and you need S2py: > >> MCHttpRepository > >> location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' > >> user: '' > >> password: '' > >> > >> > >> New entries will appear in the world menu: > >> <Screen Shot 2014-09-16 at 11.49.06 AM.png> > >> > >> You can run the test coverage on : > >> - the class classes you have modified, > >> - on a particular > >> - on a particular class category > >> - on the last class categories you have modified > >> - on the last packages you have modified > >> > >> Here is a portion of a large coverage: > >> > >> <Screen Shot 2014-09-16 at 12.00.11 PM.png> > >> > >> A technical description of Hapao may be found on http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf > >> > >> We are daily using Hapao to help us understand our tests. > >> > >> Cheers, > >> Ricardo, Alejandro & Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2014

Third Addition to GT-Inspector

by Sven Van Caekenberghe

My third addition to GT-Inspector: === Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.61 Author: SvenVanCaekenberghe Time: 5 October 2014, 11:07:12.742994 pm UUID: 5a40e21d-c56d-467a-ae31-7878678f6254 Ancestors: GT-InspectorExtensions-Core-AndreiChis.60 Allow items of String and ByteArray to be inspected (removed #gtInspectorItemsIn: for those classes) Switched index and item columns in SequenceableCollection>>#gtInspectorItemsIn: Added ByteArray>>#gtInspectorBytesIn: to show - a hex string - a set of formatted hex blocks - latin1 interpretation - utf8 interpretation - integer interpretation (big endian) - reversed integer interpretation (little endian) with error handling and interactive size protection === It looks like this: This is based on what we had in EyeByteArrayInspector. Needs to be looked at I guess. Sven

Oct. 5, 2014

[ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

Hi guys, Iâm sharing slides of my presentation at CampSmalltalkVI2014 http://www.slideshare.net/sebastianconcept/flow-39897704 >From flowâs readme at github: Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

Oct. 5, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Jan Vrany

On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote: > Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. > However, I think itâs better to do feature detection instead of dialect detection. So, something like: > > ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ > stream := CharacterWriteStream on: (String new: 10) > ] ifFalse:[ > stream := WriteStream on: (String new: 10) > ] > Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The "feature testing" code would look like ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ]. (true, in this very case you may be able to get around using different method, but you get the point, no?) Some time ago Hilaire posted a very nice, 15 lines long code that does reliable "feature detection" whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly). Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it. While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests. > And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. > That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet. Jan > cheers > Johan > > On 05 Oct 2014, at 09:00, stepharo <stepharo(a)free.fr> wrote: > > > Hi jan > > > > Thanks for the proposal. > > I thought about it and I'm against because it goes again the idea of dispatch. > > I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. > > Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. > > Let us see what other people think. > > > > Stef > > > > On 4/10/14 22:14, Jan Vrany wrote: > >> Hi guys, > >> > >> I've just opened: > >> > >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… > >> > >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to > >> SmalltalkImage to ease multi-dialect development. > >> > >> RATIONALE: > >> > >> Commonly used approach to solve differences among dialect is to use a > >> sort of platform object and dispatch there for troublesome operations > >> that has to be specialized. This platform object is usually in platform > >> specific package. > >> Other option is to load some library like Grease or Sport. > >> > >> The problem of the first approach is that brings to much (unnecessary) > >> burden when used for two, three things. The amount of of the code and > >> management is way to bigger then the amount of the code that has to be > >> specialized. Loading Grease/Sport on the other hand introduces a > >> dependency on an external package - not worth of for two or three > >> things. > >> > >> The proposed dialect testing messages would allow for simple, > >> #ifdef-like idiom like: > >> > >> | stream | > >> ... > >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk > >> isSomeCoolDialect]) ifTrue:[ > >> stream := CharacterWriteStream on: (String new: 10) > >> ] ifFalse:[ > >> stream := WriteStream on: (String new: 10) > >> ] > >> > >> The #respondsTo: check, while not nice, is required as at the moment not > >> all dialects could be trusted to have these testing messages. > >> > >> Putting these methods may not stick with Pharo standard (whatever it > >> is), but Smalltalk global is probably one of the > >> very few that are present in pretty much every Smalltalk implementation. > >> Other option would be to place them to the class side of an Object > >> (which is amost certainly present everywhere), however > >> > >> Smalltalk isPharo > >> > >> reads better than > >> > >> Object isPharo. > >> > >> Best, Jan > >> > >> > >> > > > > > > >

Oct. 5, 2014

Re: [Pharo-dev] structuring widget examples

by Tudor Girba

Hi Stef, I was not clear. The E.g. presentation for a class lists all examples. So, it is expected that we get more examples for a class. Take a look at the attached screenshot showing the examples of FileReference. Let's call it <example> and then we use it consistently throughout the system. Is that Ok? Cheers, Doru [image: Inline image 1] On Sun, Oct 5, 2014 at 5:58 PM, stepharo <stepharo(a)free.fr> wrote: > > On 5/10/14 15:10, Tudor Girba wrote: > > Hi Stef, > > Great. GT is already prepared for this :). If you define a <gtExample> > on the class side, you will get an "E.g." tab with those examples. > > It's called gtExample because we did not want to interfere with other > pragmas, but perhaps we can change it to <eg>, or <example>. What do you > think? > > > for a given class I would like to have potentially multiple examples. I > already have that in certain classes. > Then since these examples are for core classes I do not really like the > idea to get gt* > > Now first we should have many more and renaming a pragma is just the easy > part of the game. > Because I'm turning WidgetExamples into class methods examples and trying > to understand the API of UITheme > and reducing the mess. > > I want > > - UITheme to call widgets class methods > - but I have to understand the theme impact on the API. > > a kind of gigantic task. but we will see. > Stef > > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 2:25 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> I started to systematically defined widget example using the pragram >> <exampleWidget> >> >> >> rowPrototype >> "Answer a prototypical row" >> "self rowPrototype openInHand" >> <exampleWidget> >> >> | sampleMorphs aRow | >> sampleMorphs := (1 to: (2 + 3 atRandom)) collect: >> [:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @ (80 >> + ((20 atRandom)))); color: Color random; setNameTo: ('egg', integer >> asString); yourself]. >> aRow := self inARow: sampleMorphs. >> aRow setNameTo: 'Row'. >> aRow enableDragNDrop. >> aRow cellInset: 6. >> aRow layoutInset: 8. >> aRow setBalloonText: 'Things dropped into here will automatically be >> organized into a row. Once you have added your own items here, you will >> want to remove the sample colored eggs that this started with, and you will >> want to change this balloon help message to one of your own!'. >> aRow color: Color veryVeryLightGray. >> ^ aRow >> >> This means that GTool will get instances for free to play with and the >> finder get really handy to browse widgets. >> >> If you want to join the effort you are welcome. >> >> Stef >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] gt issues

by kmo

By video controls I meant /first, previous, next, last /buttons - but that's not a good idea now I think about it. I still think "page" numbers might be better than dots. But, as you say, I managed to use the dots so they can't be that bad, Still, I think the dots would look more obviously like navigation controls if they were embedded in a small sunken or raised panel. But perhaps as you suggest with more contrast in colour even that might not be necessary. I'm a bit more concerned about how easy it is to end up with lots of panes that are identical. For example, in the screenshots of smallInteger(42) in this thread. Every pane reads the same. Isn't that confusing? No doubt I'll get used to it, though. I don't like the idea of flashing the controls by the way - that seems very artificial to me. -- View this message in context: http://forum.world.st/gt-issues-tp4782476p4782808.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Ben Coman

Tudor Girba wrote: > Hi, > > On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > Tudor Girba wrote: > > Hi Esteban, > > I know it's a usability principle, but usability should also > take into account culture. Programmers are not every-day users, > and the assumptions we take should adapt to their needs. This is > why it is worth exploring what might or might not be needed. > > I cannot believe that programmers do not know the shortcuts, > > > But programmers new to Pharo don't know the shortcuts. Menus > enhance the explorability of the system, and lower the cognitive > load of remembering everything all at once, and helps with video > tutorials. > cheers -ben > > > Perhaps it was not clear, but the current discussion is about > copy/cut/paste :). > > Cheers, > Doru > > Yes, it was not clear. I was thinking more of the "Extended search..." and suchlike, but I see you've mentioned addressing that already. cheers -ben > > > but I did not consider the case in which people go through > multiple virtual boxes to get to the image. This is a legitimate > issue, so these actions are back. > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > On 04 Oct 2014, at 22:43, Tudor Girba > <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com> > <mailto:tudor@tudorgirba.com > <mailto:tudor@tudorgirba.com>>> wrote: > > Hi HernÃ¡n, > > Thanks for the feedback. Just a question: Was there > anything you > do like? :) > > The rest of the reply is inline. > > > On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com > <mailto:hernan.morales@gmail.com> > <mailto:hernan.morales@gmail.__com > <mailto:hernan.morales@gmail.com>>> wrote: > > Sorry if following issues were reported. I have seen > so many > mails about GT that I wanted to try it. These are my > first > notes and personal tastes, don't take them as > negative just > want to provide some feedback: > > - First weird thing: The Workspace doesn't open a > Workspace > anymore, it opens a Playground window. > > > That is because it is still a work in progress. > > - When I select code, right click gives no "Copy, > Cut, Delete" > commands. > > > This was reported. The menu is missing on purpose. I > still have a > hard time understanding why a developer needs those menu > entries, > but we will add them back. Btw, the shortcuts do work. > > > Is an usability principle: A system should provide visual > feedback > about what happens and about what it can do. How can we > know what can or cannot do the playground? > But of course, using menus as documentation is not always a good > idea, soâ¦ we need to find a balance here :) > I always use OSX design guidelines as a base on what I want > to do > (not that we should take it literally, but is always good to see > what others with time to invest have to say). And this > is all what they say about > menus: > https://developer.apple.com/__library/mac/documentation/__userexperience/co… > <https://developer.apple.com/library/mac/documentation/userexperience/concep…> > > Esteban > > > - Selecting an instance variable from the "State" tab, > completely shift the code view and scrolls to a new > Inspector. > Is not that I would love to scroll back everytime to > get a > view on my code. > > > The usage depends on the scenario in which you are. In > most cases, > when you do want to drill through many objects, you are > likely to > only use the playground as an entry point. When you > build a more > elaborate piece of code in the playground, you typically > do not > need to drill too much. In any case, if you want to > scroll back, > there are also keybindings that allow you to navigate: > Cmd+Alt+Left/Right. > > - I cannot find how to close new Inspector tabs. > > > This is a feature that is already planned. > > - "Print it" seems broken. It seems to print > evaluation result > but suddenly dissapears. > > > What do you mean? Can you elaborate on that? Print it should > behave like here: > > - Debugger buttons Into, Through, etc. > -- They are too small and close themselves for the > importance > they have. > -- They have no caption, so you have to mouse over > to know > what they do (until you get used to) > -- They are like "too distant" from the code view. > > > The debugger is not in the Pharo image, so I think you > are trying > the Moose image. Is that so? > In any case, the positioning of the icons will be the same > everywhere in GT (to the right of the scope they relate > to). We > are still fiddling with the right balance in the debugger. > > Cheers, > Doru > > > Cheers, > > HernÃ¡n > > > > > > -- www.tudorgirba.com <http://www.tudorgirba.com> > <http://www.tudorgirba.com/> > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 5, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 5, 2014

[pharo-project/pharo-core] 32845c: 40284

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 32845c46176f43f87157c4ccc34157cf9392aa05 https://github.com/pharo-project/pharo-core/commit/32845c46176f43f87157c4cc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-05 (Sun, 05 Oct 2014) Changed paths: M KernelTests.package/IVsAndClassVarNamesConflictTest.class/definition.st A KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/running/setUp.st A KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/running/tearDown.st R KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/setup/setUp.st R KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/setup/tearDown.st M KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/tests/testOneCanProceedWhenIntroducingCapitalizedInstanceVariables.st M KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/tests/testOneCanProceedWhenIntroducingClasseVariablesBeginingWithLowerCaseCharacters.st M KernelTests.package/ObsoleteTest.class/definition.st A KernelTests.package/ObsoleteTest.class/instance/running/setUp.st A KernelTests.package/ObsoleteTest.class/instance/running/tearDown.st R KernelTests.package/ObsoleteTest.class/instance/testing/testClassObsolete.st R KernelTests.package/ObsoleteTest.class/instance/testing/testTraitObsolete.st A KernelTests.package/ObsoleteTest.class/instance/tests/testClassObsolete.st A KernelTests.package/ObsoleteTest.class/instance/tests/testFixObsoleteSharedPools.st A KernelTests.package/ObsoleteTest.class/instance/tests/testTraitObsolete.st M MonticelloGUI.package/MCSliceMaker.class/instance/actions/downloadIssueSummary.st A MonticelloGUI.package/MCSliceMaker.class/instance/actions/informFailedWith_.st A Morphic-Base.package/StringMorph.class/class/examples/exampleManyStringMorphs.st R Morphic-Base.package/StringMorph.class/class/testing/test.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/examples/example.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/examples/exampleDisable.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/labelFont.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/newLabelFor_label_getEnabled_.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/newLabel_.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/examples/exampleButtonNoAction.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/instance creation/newButtonFor_action_label_help_.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/instance creation/newButtonFor_getState_action_arguments_getEnabled_label_help_.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/class/example/example.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/class/example/exampleWithMenu.st R Polymorph-Tools-Diff.package/DiffChangeMorph.class/class/as yet unclassified/from_label_to_label_contextClass_.st A Polymorph-Tools-Diff.package/DiffChangeMorph.class/class/instance creation/from_label_to_label_contextClass_.st M SUnit-Core.package/ClassFactoryForTestCase.class/definition.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/accessing/nextCount.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/cleaning/deleteClass_.st M SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newClassName.st M SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newSubclassOf_uses_instanceVariableNames_classVariableNames_category_.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newSubclassOf_uses_instanceVariableNames_classVariableNames_poolDictionaries_category_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script284.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40284.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteBindings.st M System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteReferences.st A System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteSharedPools.st M Traits.package/TBehavior.class/instance/accessing/sharedPoolNames.st M Traits.package/TClassDescription.class/instance/printing/sharedPoolsString.st Log Message: ----------- 40284 13905 entering non existing issue numbers in slice maker https://pharo.fogbugz.com/f/cases/13905 14164 using exampleWidget and not widgetExample https://pharo.fogbugz.com/f/cases/14164 13088 Deleting class that is used in pool dictionaries leaves a "private" class pool entry https://pharo.fogbugz.com/f/cases/13088 http://files.pharo.org/image/40/40284.zip

Oct. 5, 2014