February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Thierry Goubier

2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> I should say that I'm sick (gift from my little boy) so may be this is >> obvious. >> >> I'm looking at the code of Spec and I hate this code :) >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> >> I do not see why widgetDo: has to test for nil >> So I transformed >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> into >> >> >> widgetDo: aBlock >> >> ^ aBlock cull: self widget >> >> BTW I hate all the cull: call. They are connected with sloppiness). It is >> far too easy to use cull: >> I do not know how many arguments, I do not care I use cull: >> cull: is slow slow and help producing messing API. >> > aBlock value: value: value: does not much better than cull:, imho. Usually, the api documentation of the block are just what you'll find in existing code, nothing else. > >> And it broke. The methodBrowser example did not work anymore and many >> others. >> Debugger felt down.... >> I feel sad. Now my brain is dead so I cannot concentrate more. >> >> >> Stef >> >> > This is a big problem with morphic/spec ui elements. You never know for > sure > what code this > self update ---> search through all (dynamicly added) dependents and notify > will finally call. > I don't think there is any way around it. You have to decouple view(s) from model(s), and, hence have those propagation constraints by way of notifications. Of course, a true alternative would be to use a proper propagation constraint system... > In this example we are about to *built* the widgets and in this run , we > change a component that > will update all dependents goes back and forth between model, adapter and > widget. And all > before the widget is actually accessible for the widgetDo: call. > > (and, REALLY we need to clean this up. This is really bad code if we > announce a textChanged announcement for > a text component, if we *initialize* an *empty textcomponent* with an > *empty text*!). > In short, whatever way you look at it, this initialization difficulty is a hard problem. Morphic makes it a bit harder than expected because a Morph can be considered as active as soon as it is created, not just when it has been opened in the world. Thierry

Feb. 8, 2016

[pharo-project/pharo-core] 3d6dce: 50569

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3d6dce043ce1c1e48b9027eb2d0f82648117a26c https://github.com/pharo-project/pharo-core/commit/3d6dce043ce1c1e48b9027eb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-08 (Mon, 08 Feb 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version16_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version29_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version112_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version310_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version40_.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleAllSubclasses.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleClassVariables.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleInstanceVariables.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleSuperclasses.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleTraitComposition.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleTraitUsers.st R GT-SpotterExtensions-Core.package/extension/TBehavior/class/gtExampleTraits.st R GT-SpotterExtensions-Core.package/extension/TClassDescription/class/gtExamplePackage.st M GTInspector-Help.package/GTInspectorHelp.class/README.md M ScriptLoader50.package/ScriptLoader.class/instance/load primitives/loadConfiguration_version_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50568.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50569.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50568.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50569.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50569 GTInspector-Help http://files.pharo.org/image/50/50569.zip

Feb. 8, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 8, 2016

Re: [Pharo-dev] UUIDs are not so unique [WAS] Removing Object>>name

by Stephan Eggermont

On 08-02-16 14:13, Guille Polito wrote: > The thing is that it is not a monkey problem. The monkey asks > Smalltalkhub for the right file, but SmalltalkHub retrieves the wrong > mcz. And that's because Smalltalkhub associates a commit to an mcz file > by the UUID of the commit. So we lost source code? A slice in the inbox that has a duplicate UUID? Stephan

Feb. 8, 2016

Re: [Pharo-dev] UUIDs are not so unique [WAS] Removing Object>>name

by Guille Polito

The thing is that it is not a monkey problem. The monkey asks Smalltalkhub for the right file, but SmalltalkHub retrieves the wrong mcz. And that's because Smalltalkhub associates a commit to an mcz file by the UUID of the commit. On 02/08/2016 01:21 PM, Ben Coman wrote: > > > On Mon, Feb 8, 2016 at 4:47 PM, Guille Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > I detach the conversation from the Object>>name issue. > > So, to summarize the conversation: > > For some reason, the UUIDs generated by my Pharo in my new machine > (Debian Jessie 64bit) are not unique at all. They keep clashing > with UUIDs of existing packages in Smalltalkhub. I mean with this > that it is not an isolated case or a random thing. I can reproduce > it every time I commit. I opened a bug for this [1]. And I marked > it as show stopper, as I believe we cannot release pharo5 with > this bug that prevents people from doing a commit. > > > Should there be any concern that the CI monkey may have picked up any > wrong slices? > > cheers -ben > > > Then, I tested the NeoUUIDGenerator and it works better in that > sense. Or at least it gives me better guarantees. I propose to > replace the existing UUID generator by NeoUUID generator. The > latter is not only better, but it also includes tests. What do you > think? > > > > > Guille > > > [1] https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique > > -------- Forwarded Message -------- > Subject: Re: [Pharo-dev] [Need help with Monkey] Removing > Object>>name > Date: Fri, 5 Feb 2016 14:12:10 +0100 > From: Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > <mailto:henrik.s.johansen@veloxit.no> > Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> > <mailto:pharo-dev@lists.pharo.org> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > <mailto:pharo-dev@lists.pharo.org> > > > > > > On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > On 04 Feb 2016, at 14:02, Henrik Johansen > <henrik.s.johansen(a)veloxit.no > <mailto:henrik.s.johansen@veloxit.no>> wrote: > > > >> > >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> > >> > >>> On 04 Feb 2016, at 11:55, Guille Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> > wrote: > >>> > >>> Good news, so far, installing NeoUUID and replacing UUID > class >> new by: > >>> > >>> UUID class >> new > >>> ^NeoUUIDGenerator new next > >>> > >>> seems to work. At it looks that I can trust again my commits. > >>> > >>> Thanks Sven :) > >> > >> OK. > >> > >> Now, the idea is that one instance of the generator is kept > around, this is way more efficient, but also more correct, as > the random generator should not be created anew each time. > >> > >>> Now I do not know how this should be solved, nor if this > is reproducible in a machine other than mine... > >> > >> I seriously doubt the plugin is better (more random, more > unique) then anything that we can do in Pharo itself. I like > Pharo code way better, because we all see what it does. > >> > >> Anyone else with an opinion ? > > > > More random for certain, at least much faster than we could > do in Pharo, is certainly possible with a plugin. > > More unique... well, depends on whether you can trust the > source RNG (seeded from data with enough entropy, period much > greater than 2^128, etc). > > > > A single next:into:startingAt: primitive filling random data > (obtained using platform primitives and/or RDRAND/RDSEED) into > a buffer would be much nicer/more flexible than the current > UUID primitive though. (the linked UUID library is basically > just a thin wrapper around the platform primitives, plus > setting variant/version bits in the returned UUID bytes) > > > > As a stopgap, one could instead use another, more general > primitive (but with a less flexible api than > next:into:startingAt:) in an otherwise unrelated plugin (but > that is built internal to all Cog VM's, at least): > > rand: aBuffer > > <primitive: 'primitiveGatherEntropy' module: > 'CroquetPlugin'> > > ^self primitiveFail > > > > (which, iirc, resolves to the same platform primitives as > UUID lib) > > > > Also, the meaning of different UUID versions are well > defined in the RFC, marking NeoUUID's as being a version 4 > UUID seems somewhat ... disingenuous. > > Yes, but to 99.99% of developers, a UUID is something > special/magic where some effort was made to generate something > as unique as possible. > > If we insist on it being just 128 random bits, then why all > the fuss ? Why do we even need so called standards ? > > In my mind, you just answered that :) > The standard provides 4 well-defined ways to implement something > where it's guaranteed that some effort has been made to generate > something as unique as possible. > > Why do we need a plugin, an implementation even ? It makes no > sense. Just read 16 bytes from /dev/[u]random, or the > equivalent use of a RNG and be done with it. > > > > But if you tell developers that their database IDs are just > plain random numbers, they will probably feels less good about > them. > > > But... that's *exactly* what you tell them by marking UUID's as > being of type 4. > > To me UUID is a specific concept: << The intent of UUIDs is to > enable distributed systems to uniquely identify information > without significant central coordination. In this context the > word unique should be taken to mean "practically unique" > rather than "guaranteed unique". >> > > Not including any 'node' information (identifying process, > image, VM, machine, network endpoint), nor 'counter' does not > feel right. > > > And I agree Neo-UUID fits that bill nicely, the values it returns > *are* practically unique. > The two things I disagreed with was: > 1) The statement that it is possible to implement purely in > Smalltalk UUID's as random as those returned by the plugin (Which, > as you say, is basically reading 16 bytes from /dev/random), at > least as performant, without consulting an external trusted > randomness source. > 2) Misrepresenting the way the UUID was generated (a combination > of node identifier + timestamp + random value, similar to type 3, > but with differently sized/ordered fields) by marking it as being > of type 4, which is defined to be UUID consisting of random bytes. > IOW, I think it should be marked as type 0 instead of 4, so for > the 1 person in each country who might be found to assume > something about the implementation based on the type field, won't > later feel he's been duped when checking the generator. > > Cheers, > Henry > > >

Feb. 8, 2016

Re: [Pharo-dev] UUIDs are not so unique [WAS] Removing Object>>name

by Ben Coman

On Mon, Feb 8, 2016 at 4:47 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > I detach the conversation from the Object>>name issue. > > So, to summarize the conversation: > > For some reason, the UUIDs generated by my Pharo in my new machine (Debian > Jessie 64bit) are not unique at all. They keep clashing with UUIDs of > existing packages in Smalltalkhub. I mean with this that it is not an > isolated case or a random thing. I can reproduce it every time I commit. I > opened a bug for this [1]. And I marked it as show stopper, as I believe we > cannot release pharo5 with this bug that prevents people from doing a > commit. > Should there be any concern that the CI monkey may have picked up any wrong slices? cheers -ben > > Then, I tested the NeoUUIDGenerator and it works better in that sense. Or > at least it gives me better guarantees. I propose to replace the existing > UUID generator by NeoUUID generator. The latter is not only better, but it > also includes tests. What do you think? > > > Guille > > > [1] https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique > > -------- Forwarded Message -------- > Subject: Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name > Date: Fri, 5 Feb 2016 14:12:10 +0100 > From: Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > <henrik.s.johansen(a)veloxit.no> > Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> > <pharo-dev(a)lists.pharo.org> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > <pharo-dev(a)lists.pharo.org> > > > > On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe < <sven(a)stfx.eu> > sven(a)stfx.eu> wrote: > >> >> > On 04 Feb 2016, at 14:02, Henrik Johansen < >> <henrik.s.johansen(a)veloxit.no>henrik.s.johansen(a)veloxit.no> wrote: >> > >> >> >> >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> >> >>> On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito(a)gmail.com> >> wrote: >> >>> >> >>> Good news, so far, installing NeoUUID and replacing UUID class >> new >> by: >> >>> >> >>> UUID class >> new >> >>> ^NeoUUIDGenerator new next >> >>> >> >>> seems to work. At it looks that I can trust again my commits. >> >>> >> >>> Thanks Sven :) >> >> >> >> OK. >> >> >> >> Now, the idea is that one instance of the generator is kept around, >> this is way more efficient, but also more correct, as the random generator >> should not be created anew each time. >> >> >> >>> Now I do not know how this should be solved, nor if this is >> reproducible in a machine other than mine... >> >> >> >> I seriously doubt the plugin is better (more random, more unique) then >> anything that we can do in Pharo itself. I like Pharo code way better, >> because we all see what it does. >> >> >> >> Anyone else with an opinion ? >> > >> > More random for certain, at least much faster than we could do in >> Pharo, is certainly possible with a plugin. >> > More unique... well, depends on whether you can trust the source RNG >> (seeded from data with enough entropy, period much greater than 2^128, etc). >> > >> > A single next:into:startingAt: primitive filling random data (obtained >> using platform primitives and/or RDRAND/RDSEED) into a buffer would be much >> nicer/more flexible than the current UUID primitive though. (the linked >> UUID library is basically just a thin wrapper around the platform >> primitives, plus setting variant/version bits in the returned UUID bytes) >> > >> > As a stopgap, one could instead use another, more general primitive >> (but with a less flexible api than next:into:startingAt:) in an otherwise >> unrelated plugin (but that is built internal to all Cog VM's, at least): >> > rand: aBuffer >> > <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> >> > ^self primitiveFail >> > >> > (which, iirc, resolves to the same platform primitives as UUID lib) >> > >> > Also, the meaning of different UUID versions are well defined in the >> RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... >> disingenuous. >> >> Yes, but to 99.99% of developers, a UUID is something special/magic where >> some effort was made to generate something as unique as possible. >> >> If we insist on it being just 128 random bits, then why all the fuss ? >> Why do we even need so called standards ? > > In my mind, you just answered that :) > The standard provides 4 well-defined ways to implement something where > it's guaranteed that some effort has been made to generate something as > unique as possible. > > Why do we need a plugin, an implementation even ? It makes no sense. Just >> read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be >> done with it. >> > > >> But if you tell developers that their database IDs are just plain random >> numbers, they will probably feels less good about them. >> >> > But... that's *exactly* what you tell them by marking UUID's as being of > type 4. > > >> To me UUID is a specific concept: << The intent of UUIDs is to enable >> distributed systems to uniquely identify information without significant >> central coordination. In this context the word unique should be taken to >> mean "practically unique" rather than "guaranteed unique". >> >> >> Not including any 'node' information (identifying process, image, VM, >> machine, network endpoint), nor 'counter' does not feel right. >> > > And I agree Neo-UUID fits that bill nicely, the values it returns *are* > practically unique. > The two things I disagreed with was: > 1) The statement that it is possible to implement purely in Smalltalk > UUID's as random as those returned by the plugin (Which, as you say, is > basically reading 16 bytes from /dev/random), at least as performant, > without consulting an external trusted randomness source. > 2) Misrepresenting the way the UUID was generated (a combination of node > identifier + timestamp + random value, similar to type 3, but with > differently sized/ordered fields) by marking it as being of type 4, which > is defined to be UUID consisting of random bytes. > IOW, I think it should be marked as type 0 instead of 4, so for the 1 > person in each country who might be found to assume something about the > implementation based on the type field, won't later feel he's been duped > when checking the generator. > > Cheers, > Henry > > >

Feb. 8, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Nicolai Hess

2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi guys > > I should say that I'm sick (gift from my little boy) so may be this is > obvious. > > I'm looking at the code of Spec and I hate this code :) > > widgetDo: aBlock > > ^ self widget ifNotNil: aBlock > > > I do not see why widgetDo: has to test for nil > So I transformed > > widgetDo: aBlock > > ^ self widget ifNotNil: aBlock > > into > > > widgetDo: aBlock > > ^ aBlock cull: self widget > > BTW I hate all the cull: call. They are connected with sloppiness). It is > far too easy to use cull: > I do not know how many arguments, I do not care I use cull: > cull: is slow slow and help producing messing API. > > And it broke. The methodBrowser example did not work anymore and many > others. > Debugger felt down.... > I feel sad. Now my brain is dead so I cannot concentrate more. > > > Stef > > This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call. (and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).

Feb. 8, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 8, 2016

[pharo-project/pharo-core] 9a770f: 50568

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9a770ffe7387272747c7bf65fc8c0b758371423f https://github.com/pharo-project/pharo-core/commit/9a770ffe7387272747c7bf65… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-08 (Mon, 08 Feb 2016) Changed paths: M Monticello.package/MethodAddition.class/instance/notifying/notifyObservers.st M Morphic-Base.package/HaloMorph.class/instance/private/addNameBeneath_string_.st R Morphic-Base.package/NameStringInHalo.class/README.md R Morphic-Base.package/NameStringInHalo.class/definition.st R Morphic-Base.package/NameStringInHalo.class/instance/drawing/drawOn_.st M Morphic-Base.package/StringMorph.class/definition.st A Morphic-Base.package/StringMorph.class/instance/accessing/backgroundColor.st A Morphic-Base.package/StringMorph.class/instance/accessing/backgroundColor_.st M Morphic-Base.package/StringMorph.class/instance/drawing/drawOn_.st M Morphic-Base.package/StringMorph.class/instance/initialization/initialize.st M ScriptLoader50.package/ScriptLoader.class/instance/load primitives/loadConfiguration_version_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50567.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50568.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50567.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50568.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClassDescription.class/instance/compiling/compile_classified_withStamp_notifying_logSource_.st A Traits.package/TClassDescription.class/instance/compiling/noteCompilationOfMethod_meta_.st Log Message: ----------- 50568 17531 add #noteCompilationOfMethod:meta: https://pharo.fogbugz.com/f/cases/17531 13209 StringMorph background https://pharo.fogbugz.com/f/cases/13209 http://files.pharo.org/image/50/50568.zip

Feb. 8, 2016

Re: [Pharo-dev] Best way to access icons?

by Esteban Lorenzano

> On 07 Feb 2016, at 22:08, stepharo <stepharo(a)free.fr> wrote: > > > > Le 5/2/16 09:21, Esteban Lorenzano a Ã©crit : >> of course, but since we have not implemented such mechanism, we need to go one step at a timeâ¦ > > yes but this is good to think about a good solution. :) > At least this is good to know that you do not consider that as the final answer (because it sucks ;) câmonâ¦ *you* know I also thing this solution is ugly, is just less bad than the older oneâ¦ we have talked about this lots of times! :) Esteban > > >> >> first step is *not to have* everything as static as it was before. >> >> then we need to think on skins, injection, etc. >> >> Esteban >> >>> On 04 Feb 2016, at 22:21, stepharo < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Hi guys >>> >>> I do not have the answer but I hate such patterns >>> >>> Smalltalk ui icons iconNamed: #protocolExtension. >>> >>> To me a tools using an icon should declare the icons as a ***local*** ressources. >>> We could imagine that there is a IconContainer and that as a tool I declare that I want an >>> icons and I install it on myself. >>> >>> | t | >>> t := Tool new. >>> ic := IconContainer for: #darkTheme. >>> t askAninnstallIcon: ic iconFor: #button. >>> >>> Then if the IconContainer changes, then it can notify its users to ask for a new version of the icon. >>> >>> ic broadcastNewIcon: #button >>> >>> This way >>> >>> t does not have to use a plain bad global variable and does not care about the global namespace. >>> t should only use local resources held in classVar for example. >>> >>> >>> Such Smalltalk ui icons is a dynamic global variable! >>> >>> Stef >>> >>> >>> >>> >>> >>> Le 4/2/16 17:00, Esteban Lorenzano a Ã©crit : >>>> Smalltalk ui icons iconNamed: #protocolExtension. >>>> >>>> Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ they will never be enough and wellâ¦ is like a monolithic vision. >>>> Not that what we have is much better, but you can consider it an iteration :) >>>> >>>> Esteban >>>> >>>>> On 04 Feb 2016, at 16:19, Aliaksei Syrel < <mailto:alex.syrel@gmail.com>alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: >>>>> >>>>> Hi >>>>> >>>>> For ages to access an icon we used: >>>>> Smalltalk ui icons protocolPrivateIcon >>>>> >>>>> Smalltalk ui icons returns an instance of ThemeIcons. >>>>> After refactoring (caseÂ <https://pharo.fogbugz.com/f/cases/16651> <https://pharo.fogbugz.com/f/cases/16651>https://pharo.fogbugz.com/f/cases/16651 <https://pharo.fogbugz.com/f/cases/16651>) all methods to access icon (for example protocolPrivateIcon) were removed. >>>>> >>>>> ThemeIcons>>#doesNotUnderstand: aMessage converts message sent to iconNamed: aMessage selector which works. >>>>> >>>>> BUT we have this all over the image: >>>>> <Screen Shot 2016-02-04 at 16.13.03.png> >>>>> >>>>> So, what is the best practice to access icons to use in application? >>>>> >>>>> Cheers, >>>>> Alex >>>>> >>>> >>> >> >

Feb. 8, 2016