Re: [Pharo-users] About patterns, UML and documentation

[Peter Uhnak]

> > with the tool and layout and stuff rather than concentrate on what is

Well there are tools such as PlantUML that generate it for you, you can provide 
some hints, but generally it tends to be good enough to not be worried about 
layout.

I have a Pharo -> PlantUML generator for class, object, and sequence diagrams 
somewhere, as I've used it to gain insight about some subsystems on several 
occasions, but I never published it... it's a bit of hacky code around Pharo's 
metaprogramming and reflecting capabilities... so you could in principle write 
it by hand in an hour or so... in fact doing so by hand might be beneficial for 
specific problem, because you can reverse-engineer only the parts that you care 
about instead of having everything or having a complex generator 
parametrization...


> > Take Sven's NeoCSV package as an example. Great documentation and very
> > good method names. and a complete set of tests.
> >
> > Sounds frightening at first if you come from a static typing background,
> > but in my experience it works quite well.

I don't think that this is a good example. From user perspective you usually 
interact with only two classes (reader and writer)... and I don't really see 
how UML could help you there. The internal architecture on the other hand, or 
tools with models could benefit from it much more (at least in class diagrams, 
the relationships between elements tends to be the most important part, so if 
you have one or two classes... then you won't have much connections...).

Peter

On Thu, Jun 08, 2017 at 08:40:34AM +0200, Marc Hanisch via Pharo-users wrote:
> Date: Thu, 8 Jun 2017 08:40:34 +0200
> From: Marc Hanisch 
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] About patterns, UML and documentation
> 
> Thanks Todd and Joachim for your fast responses,
> 
> your examples are very interesting! I think I got the point! ...And you are
> so true about your experience with UML and the struggle to group / align
> all graphical objects so it is still understandable ;-)
> 
> Best regards,
> Marc
> 
> 2017-06-08 7:53 GMT+02:00 jtuc...@objektfabrik.de :
> 
> > I think the key to this is intention revealing names and comments. And
> > shipping unit tests that are the best example of "running documentation".
> >
> > Take Sven's NeoCSV package as an example. Great documentation and very
> > good method names. and a complete set of tests.
> >
> > Sounds frightening at first if you come from a static typing background,
> > but in my experience it works quite well.
> >
> > There are UML tools. Some even allow round-trips where the UML diagrams
> > can be generated from code (e.g. IBM/Instantiations have the UML Designer
> > add-on), but to be honest, these only put you in high danger of playing
> > with the tool and layout and stuff rather than concentrate on what is
> > important. UML is fine for communicating the raw structure and basic ideas.
> > Generating UML from code on the fly can help understand code, but I've seen
> > too many projects that made the UML design documents an art of itself, and
> > most of the times the diagrams were out of sync anyways...
> >
> > Just my 2 cents,
> >
> > Joachim
> >
> >
> > --
> > ---
> > Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
> > Fliederweg 1 http://www.objektfabrik.de
> > D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
> >
> >
> >

Re: [Pharo-users] Some Metacello issue

[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  
> wrote:
> 
> 
> 
> On 06/07/2017 03:46 AM, Holger Freyther wrote:
>>> On 7. Jun 2017, at 14:09, Stephan Eggermont  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/MetacelloUserGuide.md#locking
>  
> 

Re: [Pharo-users] Some Metacello issue

[Diego Lont]

> On 08 Jun 2017, at 09:36, Diego Lont  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 …

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

[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.

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

[Marcus Denker]

> On 7 Jun 2017, at 20:08, Ben Coman  wrote:
> 
> 
> 
> On Wed, Jun 7, 2017 at 10:24 PM, Marcus Denker  > 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 
> 
> - http://files.pharo.org/conferences/2017PharoDays/ 
> 
> 
> PlayList: 
> 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

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

[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  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. 

Re: [Pharo-users] Traits, method flatten

[Nicolai Hess]

2017-06-08 6:00 GMT+02:00 Sean P. DeNigris :

> 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 
Traits methods flattened (now in Pharo 60466 )
19974

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.
>
>

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

[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 
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 
> 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.
>
>
>

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

[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  wrote:

>
>
> On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar 
> 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.
>>
>>
>

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

[Ben Coman]

On Thu, Jun 8, 2017 at 5:59 PM, Dimitris Chloupis 
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 
> 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 
>> 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.
>>
>>
>>

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

[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-tp4949280p4950480.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[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.

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

[p...@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 
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  wrote:
>
>>
>>
>> On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar 
>> 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 sa

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

[Marc Hanisch via Pharo-users]

--- Begin Message ---
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é :

> 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.
>
>
--- End Message ---

Re: [Pharo-users] Porting Transducers to Pharo

[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  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 p...@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  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

Re: [Pharo-users] Porting Transducers to Pharo

[Steffen Märcker]

In fact, I moved from Mocketry to DoubleAgents quite some time ago... =)

Am .06.2017, 23:04 Uhr, schrieb Denis Kudriashov :


2017-06-07 22:04 GMT+02:00 p...@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

Re: [Pharo-users] Porting Transducers to Pharo

[Denis Kudriashov]

2017-06-08 15:37 GMT+02:00 Steffen Märcker :

> 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)

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

[Holger Freyther]

> On 17. Apr 2017, at 21:30, Juraj Kubelka  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:

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

[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-tp4949280p4950508.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[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.

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

[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 
>>  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
>
>
>

Re: [Pharo-users] is it related to Freetype or Athens?

[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

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

[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  wrote:
> 
> >
> >
> > On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar 
> > 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.
> >>
> >>
> >

Re: [Pharo-users] Traits, method flatten

[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

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

[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.

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

[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-tp4949280p4950535.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Pharo-users] Teapot: Managing authentication by a third party (Fossil)

[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

[Pharo-users] PharoCloud drops VM hosting and focuses on Ephemeric Cloud

[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-Cloud-tp4950562.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Holger Freyther]

> On 8. Jun 2017, at 23:16, Holger Freyther  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

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

[Holger Freyther]

> On 9. Jun 2017, at 11:09, Holger Freyther  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

[Pharo-users] crash.dmp of OSSubProcess on Pharo 6.0

[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


20170608crash.dmp
Description: Binary data

Re: [Pharo-users] PharoCloud drops VM hosting and focuses on Ephemeric Cloud

[Ben Coman]

On Fri, Jun 9, 2017 at 6:59 AM, mikefilonov  wrote:

> 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 :)
>

Thanks for the clarification Mike.


>
> 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 should remind us of this more often, maybe once a month.  Its a great
offer, but I'm not ready right now to try it, and in a few months I'll have
forgotten.
Or better, the Association should post here a monthly promotion
flyer/newletter that lists deals like this.

cheers -ben

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

[Sven Van Caekenberghe]

Why would $HOME not be set ?

And if it is not set / seems like a reasonable default.

> On 9 Jun 2017, at 06:06, Holger Freyther  wrote:
> 
> 
>> On 9. Jun 2017, at 11:09, Holger Freyther  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
> 
> 
> 

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

[Holger Freyther]

> On 9. Jun 2017, at 13:26, Sven Van Caekenberghe  wrote:

Hey,


> Why would $HOME not be set ?

In this specific case runit doesn't export HOME when starting my service but 
looking at systemd and picking a random service like exim4.service I see:

$ strings /proc/946/environ 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C
_SYSTEMCTL_SKIP_REDIRECT=true
PWD=/

I think it is safe to assume this applies to other services started by systemd 
as well.

> And if it is not set / seems like a reasonable default.

In Shell it would be "" but with >>resolveString: '' it seems to be / but that 
seems to be fair enough. E.g. as {home} / '.config' is used anyway.

holger