June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Porting Transducers to Pharo

by Steffen MÃ¤rcker

Hi Phil, thanks a lot for your effort and valuable input. I am having a look at STIG for VW in the hope that I can set up a common repository for the VW and Pharo version. Though, the next days I won't work on the port, because I am quite busy at the moment. > Tell me how it goes for you. I'll let you know soon. > I read your note about DoubleAgents for the tests, well, yeah this one we > do not have. I read about it on the blog of its maker and it looked > decent indeed. I'll check whether a port is doable with reasonable effort and the author's blessing. =) > Then look at the warnings. A bunch of them are non issues but there are > Undeclared things in need of a fix (e.g. IndexNotFoundError) Luckily, most of them are straight forward to resolve. However, I'd really like to hear your opinion on the name clash with #reduce: in the base (see other thread). A solution could be to use double-dispatching (or similar) to distinguish between the two cases - reduce: aBlock, and - reduce: aReduction However, I have a slight preference to redefine #fold: and #reduce:, since now (as far as I can see), they are redundant. E.g., - fold: aBlock "reduce as defined right now" - reduce: aBlock init: "value "reduce starting with an initial value" - reduce: aReduction "reduce with block and value from a reduction" Kind regards, Steffen > Best, > Phil > > > On Wed, Jun 7, 2017 at 11:29 AM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> Hi Phil, >> >> that's great. I do have a GitHub account (merkste) but none at >> SmalltalkHub. Is there a recommendable doc on how to use Git from Pharo? >> >> Best, Steffen >> >> >> >> Am .06.2017, 14:09 Uhr, schrieb phil(a)highoctane.be <phil(a)highoctane.be>: >> >> Hi Steffen, >>> >>> I am willing to help you create the package in SmalltalkHub or Github >>> based >>> on your files/changeset. >>> >>> Do you have a github and/or SmalltalkHub account? >>> >>> Best, >>> Phil >>> >>> >>> On Tue, Jun 6, 2017 at 1:08 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> Hi! >>>> >>>> If the need arises, we could of course factor the compact notation out >>>> into >>>> >>>>> a separate package. >>>>>> >>>>>> Good idea >>>>> [...] I do not want to help promoting a syntax that alienates me (and >>>>> others because other people reported the saem to me). >>>>> >>>>> >>>> I understand. Btw, I'd really, really appreciate if others post their >>>> thoughts and feedback here as well. Discussion helps moving things >>>> forward. >>>> =) >>>> >>>> >>>> (collection transduce map: #squared) take: 1000. >>>> >>>>> >>>>>> >>>>> To me this is much more readable. >>>>> >>>>> >>>> Well, I'll provide that extension once it is finished. >>>> >>>> I cannot and do not want to use the other forms. >>>> >>>>> >>>>> >>>> >>>> collection transduce >>>> >>>>> map: #squared; >>>>>> take: 1000. >>>>>> >>>>>> But as the message chain has to modify the underlying object >>>>>> (an eduction), very snaky side effects my occur. E.g., consider >>>>>> >>>>>> eduction := collection transduce. >>>>>> squared := eduction map: #squared. >>>>>> take := squared take: 1000. >>>>>> >>>>>> Now, all three variables hold onto the same object, which first >>>>>> squares >>>>>> all elements and than takes the first 1000. >>>>>> >>>>>> >>>>> This is because the programmer did not understand what he did. No? >>>>> >>>>> >>>> Sure. ;-) Nevertheless, it would be very hard to debug. All of which >>>> are >>>> the reasons I wouldn't implement that variant. ;-) >>>> >>>> >>>> PS: I played with infinite stream and iteration back in 1993 in CLOS. >>>> >>>>> Now I do not like to mix things because it breaks my flow of >>>>> thinking. >>>>> >>>>> >>>> >>>> I am not sure whether I understand what your mean by mixing. >>>> Concerning >>>> transducers, the ability to handle infinite sources in only a >>>> (natural) >>>> side-effect of the ability to finish reductions before all elements >>>> are >>>> processed, e.g., like #detect: and such. >>>> >>>> Best, Steffen >>>> >>>> >>>> >>>> >>>> >>>> >>

June 8, 2017

Re: [Pharo-users] Bloc/Brick/Spec

by Marc Hanisch

Hi Glenn, does this mean, that in the future we can build GTK applications via Bloc/Brick/Spec? Best regards, Marc 2017-06-08 14:46 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: > Hi all, > As well described by Peter, Bloc is a low level graphics library which > mainly manages multi-windowing (Morphic, SDL, Gtk soon), user interaction > (events) and drawing (using Sparta). > Brick is a widget framework on top of Bloc (button, inputField, ...) and > Spec is a "multi-backend" UI Builder. > > I know that the installation of Bloc can be confusing because of the > multiple possibilities. > For more information, Metacello and Zeroconf scripts are described here : > https://github.com/pharo-graphics/Bloc/blob/master/INSTALL.md. > > Cheers, > > Glenn. > > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/Bloc- > Brick-Spec-tp4949591p4950481.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 8, 2017

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

by phil＠highoctane.be

Also realize the Smalltalk image is a container... No need for fancy XML externalization because you can do that with code. I have an app where I wire all kinds of things together in a configuration file which is Smalltalk code and I just compile a method like "wireEverything" that as source has that configuration file. Or just do a Compiler evaluate: aLongConfigurationStringInSmalltalk Any Dictionary can be a "SpringContext" thing. Now decorators with specific features like transaction support etc is not something we have and things like Spring do have. We could take inspiration from Spring Boot. https://projects.spring.io/spring-boot/ Best Regards, Phil On Thu, Jun 8, 2017 at 1:46 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > 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] Bloc/Brick/Spec

by Glenn CavarlÃ©

Hi all, As well described by Peter, Bloc is a low level graphics library which mainly manages multi-windowing (Morphic, SDL, Gtk soon), user interaction (events) and drawing (using Sparta). Brick is a widget framework on top of Bloc (button, inputField, ...) and Spec is a "multi-backend" UI Builder. I know that the installation of Bloc can be confusing because of the multiple possibilities. For more information, Metacello and Zeroconf scripts are described here : https://github.com/pharo-graphics/Bloc/blob/master/INSTALL.md. Cheers, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Brick-Spec-tp4949591p4950481.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 8, 2017

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