- Pharo-users - lists.pharo.org

Re: [Pharo-users] ZnClient: how to emulate a curl command

by Offray Vladimir Luna CÃ¡rdenas

Hi Sven, I was making a silly mistake in the server URL. I just forgot the extra "/" after servers port number, so it was "8081/json" instead of "8081json". I imagine that maybe is a test for validating properly form urls, but also I will have a more trained eye for such errors next time. Now is working properly. The code at [1], shows the fix and includes the ZnEasy convenience. [1] http://ws.stfx.eu/PLUA8QCSI4X0 Cheers, Offray On 07/06/17 12:20, Sven Van Caekenberghe wrote: > Hi Offray, > >> On 7 Jun 2017, at 17:21, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Hi, >> >> I'm prototyping some integration between Fossil and Pharo for the >> creation of dynamic distributed web sites [1]. Now I would like to send >> some messages to store serialized STON domain objects as Fossil wiki >> pages. The command that makes this, using curl, is: >> >> curl -H "Content-Type: application/json" -d '{"authToken": "mytoken", >> "payload": {"name": "foo", "content": "bar"}}' >> http://localhost:8081/json/wiki/create >> >> and I thought that a similar command would be the one at [2], but there >> is something about ZnEntity that I'm not understanding. >> >> How can I replicate the curl command using ZnClient? >> >> [1] http://smalltalkhub.com/#!/~Offray/Brea >> [2] http://ws.stfx.eu/D61ZOA1LEQNG >> >> Thanks, >> >> Offray > That [2] looks about right to me. Though the URL is strange (the json part). What do you get as response ? Maybe the authentication just fails. Or you made some other mistake ? > > I would personally never write JSON manually, but like this: > > STONJSON toString: { #authToken->'foo'. #payLoad->({ #name->'test'. #content->'something' } asDictionary) } asDictionary. > > Or this: > > (NeoJSONObject new authToken: 'foo'; payLoad: (NeoJSONObject new name: 'test'; content: 'something')) asString. > > Different styles/frameworks, same result. > > Sven > > >

June 8, 2017

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

by Glenn CavarlÃ©

Hi Marc, It would be so cool but no, it's not planned. Like SDL and Morphic, Gtk is only used as a backend for windowing. This means that only primitives related to windowing are currently implemented (i.e GtkWindow related apis). Working on widget binding with Gtk or Qt is something i would like to start, maybe next year but it is quite hard/long to do well. The Mars framework built by Esteban was a really good starting point but it is not maintained. Thanks for your interest, Cheers, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Brick-Spec-tp4949591p4950514.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 8, 2017

Re: [Pharo-users] Pharo6 server deployment and no home directory

by Holger Freyther

> On 17. Apr 2017, at 21:30, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi Holger, Hey Juraj! > Basically it tests `FileLocator home exists`, if false, it does not touch disk. We could also add a #disablePersistence method if necessary. I thought I tested it but somehow it is broken (again)? Looks like FileLocator>>#exists fails instead of answering false? Can you reproduce it? $ unset HOME $ pharo ... Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver>>preferences UnixResolver(FileSystemResolver)>>resolve: SystemResolver(FileSystemResolver)>>unknownOrigin: SystemResolver(FileSystemResolver)>>resolve: InteractiveResolver>>unknownOrigin: [ self unknownOrigin: origin ] in InteractiveResolver>>resolve: in Block: [ self unknownOrigin: origin ] IdentityDictionary(Dictionary)>>at:ifAbsent: InteractiveResolver>>resolve: FileLocator>>resolve FileLocator(AbstractFileReference)>>exists GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>shouldCallPreviousPersistence GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:

June 8, 2017

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

by Attila Magyar

Vitor Medina Cruz wrote > This is exactly my concern! Sure, for small stuff that is not a problem, > but what if you have a big app? I don't think it makes any difference. You have to decide in each case whether an object is an internal (implementation detail) and therefore it must be created from inside the class that uses it, or a dependency (or peer) that should be passed as an argument. In the later case you instantiate the object from the outside and hand it over to the object that requires it. Most applications have a few major top level abstractions. Let's call them subsystems. I would use more domain specific names in a concrete case but this is a general example. These subsystems are instantiated at the entry point of the application. If there are shared dependencies between them, those are instantiated here as well. Then each subsystem can build up some object graph that is required by the actual subsystem (Not everything needs to know about everything else. There are clusters of objects that represent domain level abstractions). The same things applies here as well. Some dependencies are passed through (peers), others are instantiated (internals) from the inside. This can go on and on further and it will result a fractal like structure. The whole application is one object. It consists of few other objects. Those object consists of further objects. In a typical Spring application there is big blob of object soup with full of equivalent objects, everyone can access to everything else and this fractal structure is missing. -- 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] Porting Transducers to Pharo

by Denis Kudriashov

2017-06-08 15:37 GMT+02:00 Steffen MÃ¤rcker <merkste(a)web.de>: > In fact, I moved from Mocketry to DoubleAgents quite some time ago... =) It was greatly updated from VW version. (look for details here http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html)

June 8, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Steffen MÃ¤rcker

In fact, I moved from Mocketry to DoubleAgents quite some time ago... =) Am .06.2017, 23:04 Uhr, schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-06-07 22:04 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> 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 think Mocketry can easily replace DoubleAgents but API is different and > most tests will needed rewrites

June 8, 2017

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