- Pharo-users - lists.pharo.org

crash.dmp of OSSubProcess on Pharo 6.0

by john pfersich

I got a seg fault when I tried to execute some OSSubProcess code in Pharo 6.0. Namely, | process | process := OSSUnixSubprocess new command: '/bin/cat'; redirectStdin; redirectStdout; run. process stdinStream nextPutAll: 'we are testing!'; nextPutAll: 'we again!'; close. process waitForExit. process stdoutStream upToEndOfFile inspect. process closeAndCleanStreams. Attached is the crash.dmp file

June 9, 2017

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

by Holger Freyther

> On 9. Jun 2017, at 11:09, Holger Freyther <holger(a)freyther.de> wrote: > > > a.) Behave like unix and resolve $HOME to '' > > $ unset HOME > $ echo $HOME/.config > /.config > > self home / '.config' => '/.config' Implementing UnixResolver>>#home as home ^ self directoryFromEnvVariableNamed: 'HOME' or: [self resolveString: ''] will lead to something creating /.config/pharo (if possible). By itself this change is not good enough but when adding --no-default-preferences. Comments? Opinions? holger

June 9, 2017

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

by Holger Freyther

> On 8. Jun 2017, at 23:16, Holger Freyther <holger(a)freyther.de> wrote: > > Hey Juraj! Hey! this will most likely block more people trying to deploy a headless Pharo6 image but I am not so sure how to properly fix it. > $ unset HOME > $ pharo ... > Error: Can't find the requested origin ... > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: $HOME is not set so cantFindOriginError will be executed. > UnixResolver>>home > [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] XDG_CONFIG_DIR can not be found and then "self home" will be executed... > FileLocator(AbstractFileReference)>>exists (FileLocator preferences / '.config' / ...) resolve exists a.) Behave like unix and resolve $HOME to '' $ unset HOME $ echo $HOME/.config /.config self home / '.config' => '/.config' b.) FileLocator>>#exists If something can not be resolved, one can argue that it doesn't exist? So I wonder if the exception should be catched and false be returned? c.) ??? I don't see an obvious/good approach. Do you? holger

June 9, 2017

PharoCloud drops VM hosting and focuses on Ephemeric Cloud

by mikefilonov

Hello, I just wanted to make some clarifications on what is going on with PharoCloud and how I see the future of the project. PharoCloud is not closing, but just dropping VM hosting support. We will continue to develop and maintain Ephemeric Cloud which allows you to publish Pharo web applications online much easier than any other VM hosting can offer. In some way PharoCloud just becomes more "cloudy" by dropping outdated technologies off :) Our plan is to make the project more community oriented. We integrated PharoCloud with Pharo.org SSO and provide *FREE* access to all *Pharo Association* members. You are welcome to log in to the cloud with your Pharo Association account at: https://www.pharocloud.com/manager/connect We are encouraging you to migrate your applications hosted as Pharocloud VMs to the Ephemeric Cloud. It is much more simple! We have some positive experience already. There are some examples I moved from VM hosting to Ephemeric Cloud: http://pharo.pharocloud.com http://seaside31.swarm.pharocloud.com/ http://eph-b147b6e2.swarm.pharocloud.com/ http://smalltalk.mikefilonov.ru/ Here you can find a quick start guide to Ephemeric cloud and some tips on how to publish your app: http://docs.swarm.pharocloud.com/article/getting_started Also there is a REST API you can use to manage the cloud. And there is also a Pharo wrapper around the REST-API: http://docs.swarm.pharocloud.com/article/pharo_library_reference We also have video guides: quickstart (sorry for old UI of the manager) https://www.youtube.com/watch?v=a1GfuT9M4qo curl example: https://www.youtube.com/watch?v=9dKBCpj96cU In case of any questions or issues with images, please feel free to contact me. -- View this message in context: http://forum.world.st/PharoCloud-drops-VM-hosting-and-focuses-on-Ephemeric-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 8, 2017

Teapot: Managing authentication by a third party (Fossil)

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm trying to make some test on a distributed wiki provided by Fossil as a backend for storage/auth, Mustache + Material Design Lite for the frontend and Teapot using as middleware for logic and connecting frontend and backend. Teapot is connected with Fossil via JSON and domain objects are stored as Fossil wiki pages. So far the experiment is going well, but now I'm wondering about how to make authentication. In my experiments I use the Fossil user and password to get an auth token that is used via the Fossil's JSON API to make all the operations that require permissions on the repository and now I wonder how this strategy should be implemented for "real" (for the tests, I read the password data from a local temporal file). - There is some User Management Framework or project for Teapot or Zinc, without going to more complex frameworks like Seaside or Aida? - Should I have some "Sessions" object that stores logged users, passwords and/or auth tokens inside the image and deletes them once the user have logoff and/or on a time basis? - Any other strategy or lite user auth framework that I have not thought ? Any advice or experience in dealing with similar scenario is greatly appreciated. Cheers, Offray

June 8, 2017

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

by Attila Magyar

Peter Uhnak wrote > Scale can make all the difference. I don't think it should. If you have a small cluster of objects where you can manage the dependencies yourself, you can compose larger objects from them and manage the dependencies the same way. By doing so, you'll get an object that is simpler from the outside than it's parts in the inside, and you'll need to solve the smaller problem again. In other words we shouldn't write large software, but compose large software from smaller ones. But the same can be done with objects (that's why I'm not a big fan of microservices despite they solve this problem similarly). If you have a flat structure (where objects don't form higher level abstractions) and everything needs to know about everything else, then the DI container will make it easier to work with this structure. But I don't think this is the right way to organize a software. -- 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] Wiring objects, IoC and Service Locator

by Peter Uhnak

On Thu, Jun 08, 2017 at 08:02:04AM -0700, Attila Magyar wrote: > 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. Scale can make all the difference. Imagine the complexity of connecting N elements. If you have just tree objects/classes/systems... you need just two connections, but you if double the number of elements, you need more than seven times more connections (to form a complete graph). Of course in practice that number will be smaller, but certainly more than linear to the number of elements. So what works in small scale doesn't necessarily translate to bigger scale, not to mention that brand new concerns are probably going to arise... just like when you are constructing a taller building, you cannot just slap it twice on each other, because the foundations will collapse, and when you want to build a space elevator, you need technology that hasn't been invented yet.

June 8, 2017

Re: [Pharo-users] Traits, method flatten

by Hilaire

Yes, Nicolai proposed a fix, and it worked well enough. So it should make you happy. Hilaire Le 08/06/2017 Ã 06:00, Sean P. DeNigris a Ã©crit : > 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? > -- Dr. Geo http://drgeo.eu

June 8, 2017

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

by Peter Uhnak

On Thu, Jun 08, 2017 at 08:46:15AM -0300, Vitor Medina Cruz wrote: > 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. Well that is the objective of DI to handle the object creation on your behalf. Of course no class is prohibited from creating instances directly, provided it had the necessary dependencies to give to the instance. > Suddenly everything must be created through the DI container, but that is not true for Service Locator. As I've noted above, DI doesn't restrict you from creating instances. Service Locator gives you a more flexible approach, however it follows that it can be also harder to manage, as the services registered in the locator can (and typically do) change at runtime, which inhibits static reasoning about the dependencies, compared to a pre-fixed configuration. > > 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? In my previous mail I've mentioned Spec doing something of the sorts, but I don't think I've seen it anywhere else. The hand-wiring mostly suffices; sometimes you can see having a method containing the name of the class it will instantiate (and which can be altered in a subclass). My best guess would be that the capabilities of Pharo, such as pluggable closures, and being a live already-running system are more likely to push the programmer towards a different architecture, where incidentally DI's are not such a concern, but I would certainly love to see some deep analysis on this. Peter > > > 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] is it related to Freetype or Athens?

by Hilaire

Another good reason to migrate Dr. Geo to Pharo 6 ;) Le 07/06/2017 Ã 21:53, Peter Uhnak a Ã©crit : > There were couple GC/memory related issues in the VM's plugin, that were fixed or worked around in the Pharo 6 VM that apparently were present for a long time... so maybe that's also part of what you've experienced... > -- Dr. Geo http://drgeo.eu

June 8, 2017