- Pharo-users - lists.pharo.org

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Attila Magyar

> It seems to be broken. Here is an archived version. http://archive.li/GCbEY#selection-755.0-755.38 -- View this message in context: http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4950… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 8, 2017

Re: [Pharo-users] No need to move to Application folder for Pharo 6 32 and 64 bit versions

by Ben Coman

On Thu, Jun 8, 2017 at 5:59 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Nope the whole thing is a standalone, everything is included in the ".app" > folder, I use no external image or sources . Is just the typical mac app > which is a folder masquerading as a single application executable. > > This is not the first time, in the past also some people reported this > problem, I also tested it and experienced no such problem. I am still > curious why I do not have it and some of you do. > Do you have any problem with Pharo opening a text file in the /tmp directory? cheers -ben > > On Thu, Jun 8, 2017 at 11:31 AM Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> The whole âpath randomisationâ feature of macOS is very odd.. what they >> do is to set an extended >> attribute to enable tranlocation (copy the whole app to a random path, >> start it there). >> >> This seems to be enabled when you look at a mounted .dmg file *and* when >> you uncompress a .zip. >> >> The flag is removed by the finder when copying to /Applications. >> >> When you use a signed .dmg, the flag is turned off. When you start via >> command line, the flag is ignored. >> >> (this is my understanding of the whole mess). >> >> But it might be that it depends, too, which which program you uncompress >> the .zip... >> >> you can check from the command line: >> >> security translocate-policy-check Pharo.app/ >> Would not translocate >> >> This whole mechanism is only a problem when the applications tries to >> access files with a non-relative path. >> That means that the packaged download where the sources and image are >> inside the .app has a problem, >> if you use the VM standalone with .image, sources and .changes, it should >> not be a problem, I think. >> >> >> > On 8 Jun 2017, at 10:05, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> > >> > I have latest macos sierra , dowload , opened and saved image for both >> pharo 6 (32 and 64 bit) and I see no problem doing that from the dowload >> folder without moving the apps to the Application folder. Am I missing >> something here ? Because when I dowloaded them there was a warning dialog >> that said that this would not work. >> >> >>

June 8, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Vitor Medina Cruz

Thanks for the links Attila, do you have an alternative one to the http://higherorderlogic.com/2011/07/is-dependency-injection-like-facebook? It seems to be broken. I also started to also think containers don't worth the effort, but I am still concerned with problems faced with hand wiring everything as Peter clearly exemplified, thanks for the excellent summary and exemplification Peter! And this is just a basic example. Imagine that the PeopleService also needs > other services for it's use, and those services need more services, and you > want to keep everything separated as much as possible... instantiation by > hand will simply not cut it This is exactly my concern! Sure, for small stuff that is not a problem, but what if you have a big app? Now, my experience with containers and Java may be shadowing my vision: people in Java community tend to use anemic model and to create gazzilions layers for even simple stuff, which make the wiring problem even worse. My experiments with a more OO approach and Smalltalk tells me one would need much less need of containers by using proper OO and a less verbose language, but I am not sure. Keep in mind however that relates primarily to using application > frameworks, where the framework mandates the control, and the framework is > the one calling you, and therefore it will also provide you with necessary > parts. After all you are not even creating PeopleService class, the > framework instantiates it for you and gives it to another services/classes > that needed it. This is true for IoC DI containers, but I don't think it applies for service locator, which, I think, could not be considered a framework approach. Actually, I think being a framework is the big problem of the of the former, since when I start to use an IoC container to create objects I got tied to it in a very basic and pervasive operation of an OO system: object creation. Suddenly everything must be created through the DI container, but that is not true for Service Locator. However I wouldn't be surprised if the liveness of Smalltalk/Pharo > environment eliminated some of the problems that DI is trying to solve. That is precisely what I wanted to know. It seems there are no DI counterpart in the Pharo/Smalltalk environment, ok, so what people do to to deal with the above mentioned problem? Hand wiring is suffice? Is there anything in the liveness of Smalltalk/Pharo that eliminates the need for it? People use simple Service Locator, or variations of it? cheers! Vitor On Wed, Jun 7, 2017 at 9:32 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar <m.magyar3(a)gmail.com> > wrote: > >> I don't think using a DI container worth the effort. They add lots of >> complexities and solve very little. For some reason DI containers became >> very popular in the Java world, but if you take a look at other >> programming >> communities you'll realize that many people are perfectly happy without >> using these containers. Using DI and using a DI container is orthogonal. >> As >> you also said you can just pass dependencies to objects to achieve loose >> coupling. Yes, you have to do this manually but what's the big deal? We're >> talking about code with cyclomatic complexity of 1. Calling a constructor >> is >> not a problem that need to be solved. Using an external XML configuration >> to >> describe object wiring is the worst idea ever. >> >> Here is an article about using plain old object composition to do DI >> >> http://blog.davidpeterson.co.uk/2011/01/object-oriented-example.html >> >> Some more thoughts about the problems associated with DI containers: >> >> http://www.natpryce.com/articles/000783.html > > > I liked this... "the [Dependency Injection] pattern also used to be > called "third-party binding" or "third-party connect": some third party is > responsible for connecting an object satisfying the service requirements of > a component" > This makes the subject seem less esoteric. It reminds me of hearing that > the first (secret) task when doing a PhD is to invent new terms for common > ones, and base your writings on that. Perhaps its the same for consultants > and framework developers. ;P Or maybe everything seems esoteric until you > have experience with it and I've not done much with Java, certainly not big > applications. > > Thx Peter for your example and how you prior experience compares to Pharo. > > cheers -ben > > >> http://higherorderlogic.com/2011/07/is-dependency-injection-like-facebook >> >> >> >> -- >> View this message in context: http://forum.world.st/Wiring-o >> bjects-IoC-and-Service-Locator-tp4949280p4949720.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >

June 8, 2017

Re: [Pharo-users] No need to move to Application folder for Pharo 6 32 and 64 bit versions

by Dimitris Chloupis

Nope the whole thing is a standalone, everything is included in the ".app" folder, I use no external image or sources . Is just the typical mac app which is a folder masquerading as a single application executable. This is not the first time, in the past also some people reported this problem, I also tested it and experienced no such problem. I am still curious why I do not have it and some of you do. On Thu, Jun 8, 2017 at 11:31 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The whole âpath randomisationâ feature of macOS is very odd.. what they do > is to set an extended > attribute to enable tranlocation (copy the whole app to a random path, > start it there). > > This seems to be enabled when you look at a mounted .dmg file *and* when > you uncompress a .zip. > > The flag is removed by the finder when copying to /Applications. > > When you use a signed .dmg, the flag is turned off. When you start via > command line, the flag is ignored. > > (this is my understanding of the whole mess). > > But it might be that it depends, too, which which program you uncompress > the .zip... > > you can check from the command line: > > security translocate-policy-check Pharo.app/ > Would not translocate > > This whole mechanism is only a problem when the applications tries to > access files with a non-relative path. > That means that the packaged download where the sources and image are > inside the .app has a problem, > if you use the VM standalone with .image, sources and .changes, it should > not be a problem, I think. > > > > On 8 Jun 2017, at 10:05, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I have latest macos sierra , dowload , opened and saved image for both > pharo 6 (32 and 64 bit) and I see no problem doing that from the dowload > folder without moving the apps to the Application folder. Am I missing > something here ? Because when I dowloaded them there was a warning dialog > that said that this would not work. > > >

June 8, 2017

Re: [Pharo-users] Traits, method flatten

by Nicolai Hess

2017-06-08 6:00 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > HilaireFernandes wrote > > I made another attempt to > > persist this time with filetree://. The net result is the same, the > > Traits logic is lost in the classes using the Traits: all traits methods > > are duplicated !! > > I just got burned by this in ##50768. Methods inherited from traits were > saved as part of the package containing the extended class, as well as the > package containing the Trait itself. Ugh. Was this ever fixed by Pharo 6? > yes, it should. See issue 19938 <https://pharo.fogbugz.com/f/cases/19938/Traits-methods-flattened> Traits methods flattened (now in Pharo 60466 ) 19974 <https://pharo.fogbugz.com/f/cases/19974/backport-Traits-methods-flattened-c…> backport Traits methods flattened (case 19938) (now in Pharo 50772 ) But AFAIK the bug, that new trait methotds are put into the "RPackage" of the trait that is "using" this trait , still exists. We only reject this entities when building the mc-package > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Traits-method-flatten- > tp4941799p4950378.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 8, 2017

Re: [Pharo-users] No need to move to Application folder for Pharo 6 32 and 64 bit versions

by Marcus Denker

Hi, The whole âpath randomisationâ feature of macOS is very odd.. what they do is to set an extended attribute to enable tranlocation (copy the whole app to a random path, start it there). This seems to be enabled when you look at a mounted .dmg file *and* when you uncompress a .zip. The flag is removed by the finder when copying to /Applications. When you use a signed .dmg, the flag is turned off. When you start via command line, the flag is ignored. (this is my understanding of the whole mess). But it might be that it depends, too, which which program you uncompress the .zip... you can check from the command line: security translocate-policy-check Pharo.app/ Would not translocate This whole mechanism is only a problem when the applications tries to access files with a non-relative path. That means that the packaged download where the sources and image are inside the .app has a problem, if you use the VM standalone with .image, sources and .changes, it should not be a problem, I think. > On 8 Jun 2017, at 10:05, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I have latest macos sierra , dowload , opened and saved image for both pharo 6 (32 and 64 bit) and I see no problem doing that from the dowload folder without moving the apps to the Application folder. Am I missing something here ? Because when I dowloaded them there was a warning dialog that said that this would not work.

June 8, 2017

Re: [Pharo-users] [Pharo-dev] PharoDays17 Slides and some Videos

by Marcus Denker

> On 7 Jun 2017, at 20:08, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, Jun 7, 2017 at 10:24 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Hi, > > I have uploaded the Slides and Videos of PharoDays2017. Slides are complete (minus those > talks that were due demos). For the Videos we have right now 8 talks and the âShow Us Your > Projectâ session. More might come in the future (I need to check). > > Slides: > - https://www.slideshare.net/pharoproject/presentations <https://www.slideshare.net/pharoproject/presentations> > - http://files.pharo.org/conferences/2017PharoDays/ <http://files.pharo.org/conferences/2017PharoDays/> > > PlayList: https://www.youtube.com/playlist?list=PL4actYd6bfnw7ous5We-XnWq0NZquP3gM <https://www.youtube.com/playlist?list=PL4actYd6bfnw7ous5We-XnWq0NZquP3gM> > > > > I liked the UI metalinks on mouse clicks. Now what would be really cool is a metalink to bring up a debugger for the next click on a button, to help learn how the system implements that feature. > Yes, it would be nice to experiment in that direction! Marcus

June 8, 2017

No need to move to Application folder for Pharo 6 32 and 64 bit versions

by Dimitris Chloupis

I have latest macos sierra , dowload , opened and saved image for both pharo 6 (32 and 64 bit) and I see no problem doing that from the dowload folder without moving the apps to the Application folder. Am I missing something here ? Because when I dowloaded them there was a warning dialog that said that this would not work.

June 8, 2017

Re: [Pharo-users] Some Metacello issue

by Diego Lont

> On 08 Jun 2017, at 09:36, Diego Lont <diego.lont(a)delware.nl> wrote: > > Hi all, > > To keep the common projects in smalltalkhub stable, we agreed that those should use symbolic versions like release3 // release3.5 etc. This way we can add bug fixes and avoiding loading of different versions through different projects. > > But I might have done something stupid to the configuration of magritte, especially release3: > > When I added some features to Magritte, I saw that that the stable version in the configuration of Magritte3 was unstable for pharo2, 3 and 4 for quite some time. Basically the tests failed, because some changes were made for pharo 5 in order to let Magritte version 3.5 run. > > Since I did not have time to make a proper fix (and the error was there for quite a lot of builds) for the older pharo versions and I believe the tests for the stable version ought to be green, I thought the best way to fix it, was to changed the #release3 magritte version back to release 3.2 for the older pharo versions. Perhaps this is the cause of some of the problems. Tomorrow I have time to look into this problem and make a proper fix. > > Stephane already notified me this is at least a problem for Pillar â¦ > Just a small addition: I just looked at Pillar, but the build of Pillar was building fine until beginning of this month. My change is from the beginning of May â¦

June 8, 2017

Re: [Pharo-users] Some Metacello issue

by Diego Lont

Hi all, To keep the common projects in smalltalkhub stable, we agreed that those should use symbolic versions like release3 // release3.5 etc. This way we can add bug fixes and avoiding loading of different versions through different projects. But I might have done something stupid to the configuration of magritte, especially release3: When I added some features to Magritte, I saw that that the stable version in the configuration of Magritte3 was unstable for pharo2, 3 and 4 for quite some time. Basically the tests failed, because some changes were made for pharo 5 in order to let Magritte version 3.5 run. Since I did not have time to make a proper fix (and the error was there for quite a lot of builds) for the older pharo versions and I believe the tests for the stable version ought to be green, I thought the best way to fix it, was to changed the #release3 magritte version back to release 3.2 for the older pharo versions. Perhaps this is the cause of some of the problems. Tomorrow I have time to look into this problem and make a proper fix. Stephane already notified me this is at least a problem for Pillar â¦ Regards, Diego > On 07 Jun 2017, at 20:01, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 06/07/2017 03:46 AM, Holger Freyther wrote: >>> On 7. Jun 2017, at 14:09, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> Never refer to fixed versions unless you know why (you need to avoid a >>> specific bug fix). >> When wanting to have repeatable builds (e.g. for bugfixes) and in the >> absence of other means to lock/define versions externally, I think using >> a fixed version is the way to go. >> >> >>> What is most likely is that there is some overconstrained configuration. >>> Does your ConfigurationOfVoyageMongo or one of the configurations it >>> pulls in refer to different versions of grease or magritte? Another >>> issue can be that there are older configurations already loaded that >>> conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk >>> is broken, refering to a fixed and older version of Grease. >>> ConfigurationOfVoyageMongo should probably be using #'release3' of >>> Magritte, but that doesn't break it. >> Right. So we have a "OsmocomUniverse" build job that pulls in all the >> apps into a single image. This helps to make API modifications and not >> forget any of the client code. >> >> The configuration has such dependencies: >> >> ConfigurationOfOsmocomUniverse >> -> ConfigurationOfHLR >> -> ConfigurationOfVoyageMongo >> -> Mongotalk >> -> Grease A >> -> Magritte3 >> -> Grease B >> -> ConfigurationOfSMPPRouter >> -> ConfigurationOfVoyageMongo >> -> Mongotalk >> -> Grease A >> -> Magritte3 >> -> Grease B >> >> What happens is that somehow "Grease A" gets loaded, then "Grease B" and >> when it is time for "Grease A" again.. the system kind of explodes and this >> is for Pharo3 and Pharo6. Now the question to me is.. why is this coming >> up right now? Did MongoTalk change or Magritte3 or something else? >> >> Is there an easy way for Metacello to try a mirror instead of the original, >> e.g. to inject an older ConfigurationOfMagritte3? >> > > I think that the `lock` command[1] is what you are looking for ... > > Dale > > [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… <https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse…>

June 8, 2017