Re: [Pharo-users] STON Question

[Stephane Ducasse]

Sven I know what Ston is :)

Now Pillar dev used Ston as input and it works. Then with some hooks they
let the user convert the strings
into specific objects and this is ok.
Now I want to add export in Ston and for configurations I need to control
for the application and not as a ston object the value saved.
For example a file reference should not be just a file reference in Ston
but
a string relative the the baseDirectory of the configuration.

So I thought that I can build a hook and control the call to Ston (convert
the object before to the correct values) and export.
It should be working now doing this I found myself redoing the output of
Ston.
So I will do it. Then I thought that may be I could reuse this logic.

Stef



On Sun, Jun 4, 2017 at 11:49 PM, Sven Van Caekenberghe  wrote:

> Stef,
>
> STON is like FUEL, it can write any object to a stream and read it back.
> Although you can customise how this is done, only one way of doing so is
> supported (i.e. you cannot change the format for each application).
>
> People have used STON for various applications now, including for
> configuration stuff (because it is a textual format that is easy to read).
>
> I would suggest you just try to see what your config looks like once you
> have the objects in Pharo.
>
>   STON toStringPretty: myConfig.
>
> Then we can see how to tune the representation.
>
> Sven
>
> > On 4 Jun 2017, at 22:58, Stephane Ducasse 
> wrote:
> >
> > Hi sven
> >
> > I'm working on a new configuration frameworks similar to the one use
> pillar.conf.
> >
> > So basically I have
> >
> > ston := '{
> >"newLine":#unix,
> >   "separateOutputFiles":true
> >   }'.
> > and I want to recreate it.
> >
> > So I did
> >
> > Object >> toConfigurationString
> >
> >   ^ STON toString: self
> >
> > SimpleConfiguration >> exportStream
> >
> >   ^ String streamContents: [ :str |
> >   str << '{' .
> >   self propertiesKeysAndValuesDo: [ :key :value|
> >   str << key toConfigurationString.
> >   str << ':'.
> >   str << value toConfigurationString.
> >   str << ','.
> >   str lf.
> >   ].
> >   str << '}'.
> >   str contents
> >   ]
> >
> > The idea is that for special configuration values people should be able
> to define
> > how to go from the object to configuration.
> > For example for some FileReference I want to have just the path up to
> the baseDirectory.
> >
> > Now I wonder if I could not better reuse ston.
> > I saw the stonOn:
> > but I did not look further because I was wondering how the writer where
> passed.
> >
> > Any feedback is welcome.
> >
> > Stef (now bed time).
> >
>
>
>

Re: [Pharo-users] Porting Transducers to Pharo

[Stephane Ducasse]

We do not work with fileouts :)
You should produce packages with also a configuration and published them on
smalltalkhub or git and
in the MetaRepository.
You can also add package comments

On Sat, Jun 3, 2017 at 10:29 PM, Steffen Märcker  wrote:

> Dear all,
>
> attached are updated file-outs. I fixed a couple of annoyances that
> slipped through yesterday evening. Most notable:
>
> 1) Random generator now works.
> 2) Early termination via Reduced exception does MNU anymore.
> 3) Printing a transducer holding a block does not MNU anymore.
>
> Please, give it a spin and tell me your impressions. (At least) The
> coin-flipping the example from the package comment works now:
>
> scale := [:x | (x * 2 + 1) floor] map.
> sides := #(heads tails) replace.
> count := 1000 take.
> collect := [:bag :c | bag add: c; yourself].
> experiment := (scale * sides * count) transform: collect.
> "experiment cannot be re-used"
> samples := Random new
>   reduce: experiment
>   init: Bag new.
> "transform and reduce in one step"
> samples := Random new
>   transduce: scale * sides * count
>   reduce: collect
>   init: Bag new.
> "assemble coin (eduction) and flip (reduction) objects"
> coin := sides <~ scale <~ Random new.
> flip := Bag <~ count.
> "flip coin =)"
> samples := flip <~ coin.
>
> Cheers!
> Steffen
>
>
>
> Am .06.2017, 23:08 Uhr, schrieb Steffen Märcker :
>
> Thanks, this appears to work.  Attached you'll find the file-out from
>> VisualWorks and the file-out from Pharo (includes package comment).
>>
>> Cheers!
>> Steffen
>>
>>
>> Am .06.2017, 20:06 Uhr, schrieb Yanni Chiu :
>>
>> To get the extension methods into the Transducers package, the following
>>> worked for me - edit the category to have the prefix '*Transducers-'
>>>
>>> 2710c2710
>>>
>>> < !Number methodsFor: 'transforming' stamp: ' 2/6/17 15:38'!
>>>
>>> ---
>>>
>>> !Number methodsFor: '*Transducers-transforming' stamp: ' 2/6/17 15:38'!

>>>
>>>
>>> On Fri, Jun 2, 2017 at 11:05 AM, Steffen Märcker  wrote:
>>>
>>> Dear all,

 thanks for the many suggestions. I didn't had time to test all
 import/export ways yet. But for now, I can report on two:

 1) NGFileOuter
 Unfortunately It raised several MNUs in my image. I'll investigate them
 later.

 2) FileOut30 (VW Contributed)
 I was able to file out the code except for the package definition.
 Replacing {category: ''} in the class definitions with {package:
 'Transducers'} fixed that. However, methods that extend existing classes
 did not end up in the Transducers package. Is there a similar easy
 change
 to the file-out making that happen? Also I'd like to add the package
 comment if that's possible.

 Most things appear to work as far as I can see. Two exceptions:
 1) Random is a subclass of Stream in VW and in Pharo it is not. Hence,
 I'll have to copy some methods from Stream to Random.
 2) I used #beImmutable in VW but I couldn't yet figure out how to make
 objects immutable in Pharo.

 However, until the tests are ported, I cannot guarantee. Porting the
 test
 suite will be another beast, since I rely on the excellent
 mocking/stubbing
 library DoubleAgents by Randy Coulman. I am not sure how I will handle
 that. In general, I think it would be really worth the effort to be
 ported
 to Pharo, too. DoubleAgents is pretty powerful and produces easy to read
 and understand mocking/stubbing code. Personally, I prefer it clearly,
 e.g., over Mocketry (no offence intended!).

 Attached you'll find the file-out that I loaded into Pharo. The issues
 above are not addressed yet. However, the following example works:

 | scale sides count collect experiment random samples coin flip |
 scale := [:x | (x * 2 + 1) floor] map.
 sides := #(heads tails) replace.
 count := 1000 take.
 collect := [:bag :c | bag add: c; yourself].
 experiment := (scale * sides * count) transform: collect.
 random := #(0.1 0.3 0.4 0.5 0.6 0.7 0.8 0.9).

 samples := random
   reduce: experiment
   init: Bag new.

 samples := random
   transduce: scale * sides * count
   reduce: collect
   init: Bag new.

 coin := sides <~ scale <~ random.
 flip := Bag <~ count.

 samples := flip <~ coin.


 Best, Steffen



 Am .06.2017, 08:16 Uhr, schrieb Stephane Ducasse
 >>> >:

 There is a package for that NGFileOuter or something like that on cincom

> store.
> We used it for mobydic code.
>
> On Wed, May 31, 2017 at 6:35 PM, Alexandre Bergel <
> alexandre.ber...@me.com>
> wrote:
>
> If I remember correctly, there is a parcel in VisualWorks to export a
> file
>
>> out (Squeak format).
>>
>> @Milton, can 

Re: [Pharo-users] Porting Transducers to Pharo

[Stephane Ducasse]

About NG this is strange but may be we were working on an old VW version.

- I can help producing a nice document :)
>>
>
> Do you mean like the booklets published over the last weeks? This would be
> great.
>

yes now I do not want to help promoting a syntax that alienates me (and
others because other people reported the saem to me). :)


Do you have an idea, how to add a package comment to the simple file-out it
> used? I think, a simple message send should suffice.
>

produce a monticello package, select the package and comment.


>>>

Re: [Pharo-users] Porting Transducers to Pharo

[Stephane Ducasse]

Hi Steffen


> The short answer is that the compact notation turned out to work much better
> for me in my code, especially, if multiple transducers are involved. But
> that's my personal taste. You can choose which suits you better. In fact,
>
>   1000 take.
>
> just sits on top and simply calls
>
>   Take number: 1000.

To me this is much much better.


> If the need arises, we could of course factor the compact notation out into
> a separate package.
Good idea

 Btw, would you prefer (Take n: 1000) over (Take number:
> 1000)?

I tend to prefer explicit selector :)


> Damien, you're right, I experimented with additional styles. Right now, we
> already have in the basic Transducer package:
>
>   (collection transduce: #squared map * 1000 take. "which is equal to"
>   (collection transduce: #squared map) transduce: 1000 take.
>
> Basically, one can split #transduce:reduce:init: into single calls of
> #transduce:, #reduce:, and #init:, depending on the needs.
> I also have an (unfinished) extension, that allows to write:
>
>   (collection transduce map: #squared) take: 1000.

To me this is much mre readable.
I cannot and do not want to use the other forms.


> This feels familiar, but becomes a bit hard to read if more than two steps
> are needed.
>
>   collection transduce
>map: #squared;
>take: 1000.

Why this is would hard to read. We do that all the time everywhere.


> I think, this alternative would reads nicely. But as the message chain has
> to modify the underlying object (an eduction), very snaky side effects may
> 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?



Stef

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.


>
> Best,
> Steffen
>
>
>
>
>
> Am .06.2017, 21:28 Uhr, schrieb Damien Pollet
> :
>
>> If I recall correctly, there is an alternate protocol that looks more like
>> xtreams or the traditional select/collect iterations.
>>
>> On 2 June 2017 at 21:12, Stephane Ducasse  wrote:
>>
>>> I have a design question
>>>
>>> why the library is implemented in functional style vs messages?
>>> I do not see why this is needed. To my eyes the compact notation
>>> goes against readibility of code and it feels ad-hoc in Smalltalk.
>>>
>>>
>>> I really prefer
>>>
>>> square := Map function: #squared.
>>> take := Take number: 1000.
>>>
>>> Because I know that I can read it and understand it.
>>> From that perspective I prefer Xtreams.
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 31, 2017 at 2:23 PM, Steffen Märcker  wrote:
>>>
 Hi,

 I am the developer of the library 'Transducers' for VisualWorks. It was
 formerly known as 'Reducers', but this name was a poor choice. I'd like
 to
 port it to Pharo, if there is any interest on your side. I hope to learn
 more about Pharo in this process, since I am mainly a VW guy. And most
 likely, I will come up with a bunch of questions. :-)

 Meanwhile, I'll cross-post the introduction from VWnc below. I'd be very
 happy to hear your optinions, questions and I hope we can start a
 fruitful
 discussion - even if there is not Pharo port yet.

 Best, Steffen



 Transducers are building blocks that encapsulate how to process elements
 of a data sequence independently of the underlying input and output
 source.



 # Overview

 ## Encapsulate
 Implementations of enumeration methods, such as #collect:, have the
 logic
 how to process a single element in common.
 However, that logic is reimplemented each and every time. Transducers
 make
 it explicit and facilitate re-use and coherent behavior.
 For example:
 - #collect: requires mapping: (aBlock1 map)
 - #select: requires filtering: (aBlock2 filter)


 ## Compose
 In practice, algorithms often require multiple processing steps, e.g.,
 mapping only a filtered set of elements.
 Transducers are inherently composable, and hereby, allow to make the
 combination of steps explicit.
 Since transducers do not build intermediate collections, their
 composition
 is memory-efficient.
 For example:
 - (aBlock1 filter) * (aBlock2 map)   "(1.) filter and (2.) map elements"


 ## Re-Use
 Transducers are decoupled from the input and output sources, and hence,
 they can be reused in different contexts.
 For example:
 - enumeration of collections
 - processing of streams
 - communicating via channels



 # Usage by Example

 We build a coin flipping experiment and count the

Re: [Pharo-users] snap morphs/windows to each other when dragging

[Stephane Ducasse]

I do not know that by default.
Especially since the drag and drop is when the mous is inside.
this is anice scenario for bloc :)

On Sun, Jun 4, 2017 at 2:51 PM, Peter Uhnak  wrote:
> Hi,
>
> is it possible to tell windows to "snap" to other windows when dragging?
>
> So e.g. when I am dragging Playground window, it will try to snap side by 
> side with a close-by another window, so they don't overlap (unless I e.g. 
> press shift or something).
>
> Thanks,
> Peter
>

Re: [Pharo-users] Saving selected changes in Monticello

[Peter Uhnak]

Komitter could indeed help you, see 
https://www.peteruhnak.com/blog/2016/08/12/fine-grained-committing-and-extending-nautilus/

Peter

On Mon, Jun 05, 2017 at 08:27:23AM +0200, serge.stinckw...@gmail.com wrote:
> Kommiter available in default image allows you do cherry pick quite easily.
> 
> Envoyé de mon iPhone
> 
> > Le 5 juin 2017 à 07:14, Ben Coman  a écrit :
> > 
> > 
> > 
> >> On Mon, Jun 5, 2017 at 10:12 AM, Andreas Sunardi  
> >> wrote:
> >> I have a half done changes in my image, but I need to distribute the other 
> >> changes that are done. I thought I was going to do this all at once, but 
> >> now I realize I should split this into 2 commit versions.
> >> 
> >> Is there a way in Monticello to say save my changes, but not this and that 
> >> changes? I can't seem to find it nor in books. How do people deal with 
> >> this situation?
> > 
> > AFAIK, Monticello cannot cherry pick.  One work around is probably 
> > something like... 
> > 1. Save the mcz locally
> > 2. Merge back into a fresh image selecting only the bits you want.  
> > 3. Save as a second mcz.
> > One issue is that the second mcz will have the first mcz as an ancestor, so 
> > before 2 you might create a new changeset to file out after 2, and load 
> > that into a second new image. yuck!
> > 
> > Another alternative might be to use Tools > ChangeSorter to move the code 
> > you want to exclude from the mcz to a changeset, file that out and then 
> > revert that code in the image. After save the package to a mcz, reload the 
> > changeset. 
> > 
> > cheers -ben

Re: [Pharo-users] Porting Transducers to Pharo

[p...@highoctane.be]

Coupling this with Olek's work on the DataFrame could really come handy.

Phil

On Mon, Jun 5, 2017 at 9:14 AM, Stephane Ducasse 
wrote:

> Hi Steffen
>
>
> > The short answer is that the compact notation turned out to work much
> better
> > for me in my code, especially, if multiple transducers are involved. But
> > that's my personal taste. You can choose which suits you better. In fact,
> >
> >   1000 take.
> >
> > just sits on top and simply calls
> >
> >   Take number: 1000.
>
> To me this is much much better.
>
>
> > If the need arises, we could of course factor the compact notation out
> into
> > a separate package.
> Good idea
>
>  Btw, would you prefer (Take n: 1000) over (Take number:
> > 1000)?
>
> I tend to prefer explicit selector :)
>
>
> > Damien, you're right, I experimented with additional styles. Right now,
> we
> > already have in the basic Transducer package:
> >
> >   (collection transduce: #squared map * 1000 take. "which is equal to"
> >   (collection transduce: #squared map) transduce: 1000 take.
> >
> > Basically, one can split #transduce:reduce:init: into single calls of
> > #transduce:, #reduce:, and #init:, depending on the needs.
> > I also have an (unfinished) extension, that allows to write:
> >
> >   (collection transduce map: #squared) take: 1000.
>
> To me this is much mre readable.
> I cannot and do not want to use the other forms.
>
>
> > This feels familiar, but becomes a bit hard to read if more than two
> steps
> > are needed.
> >
> >   collection transduce
> >map: #squared;
> >take: 1000.
>
> Why this is would hard to read. We do that all the time everywhere.
>
>
> > I think, this alternative would reads nicely. But as the message chain
> has
> > to modify the underlying object (an eduction), very snaky side effects
> may
> > 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?
>
>
>
> Stef
>
> 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.
>
>
> >
> > Best,
> > Steffen
> >
> >
> >
> >
> >
> > Am .06.2017, 21:28 Uhr, schrieb Damien Pollet
> > :
> >
> >> If I recall correctly, there is an alternate protocol that looks more
> like
> >> xtreams or the traditional select/collect iterations.
> >>
> >> On 2 June 2017 at 21:12, Stephane Ducasse 
> wrote:
> >>
> >>> I have a design question
> >>>
> >>> why the library is implemented in functional style vs messages?
> >>> I do not see why this is needed. To my eyes the compact notation
> >>> goes against readibility of code and it feels ad-hoc in Smalltalk.
> >>>
> >>>
> >>> I really prefer
> >>>
> >>> square := Map function: #squared.
> >>> take := Take number: 1000.
> >>>
> >>> Because I know that I can read it and understand it.
> >>> From that perspective I prefer Xtreams.
> >>>
> >>> Stef
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, May 31, 2017 at 2:23 PM, Steffen Märcker 
> wrote:
> >>>
>  Hi,
> 
>  I am the developer of the library 'Transducers' for VisualWorks. It
> was
>  formerly known as 'Reducers', but this name was a poor choice. I'd
> like
>  to
>  port it to Pharo, if there is any interest on your side. I hope to
> learn
>  more about Pharo in this process, since I am mainly a VW guy. And most
>  likely, I will come up with a bunch of questions. :-)
> 
>  Meanwhile, I'll cross-post the introduction from VWnc below. I'd be
> very
>  happy to hear your optinions, questions and I hope we can start a
>  fruitful
>  discussion - even if there is not Pharo port yet.
> 
>  Best, Steffen
> 
> 
> 
>  Transducers are building blocks that encapsulate how to process
> elements
>  of a data sequence independently of the underlying input and output
>  source.
> 
> 
> 
>  # Overview
> 
>  ## Encapsulate
>  Implementations of enumeration methods, such as #collect:, have the
>  logic
>  how to process a single element in common.
>  However, that logic is reimplemented each and every time. Transducers
>  make
>  it explicit and facilitate re-use and coherent behavior.
>  For example:
>  - #collect: requires mapping: (aBlock1 map)
>  - #select: requires filtering: (aBlock2 filter)
> 
> 
>  ## Compose
>  In practice, algorithms often require multiple processing steps, e.g.,
>  mapping only a filtered set of elements.
>  Transducers are inherently composable, and hereby, allow to make the
>  combination of steps explicit.
>  Since transducers do not build intermediate collections, their
>  composition
>  is memory

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

[Stephane Ducasse]

Why don't you simply pass the class and use that class in your MovieLister?

MovieLister new
 finderClass: MySuperCoolFinderClass

...
MovieLister finder
  finderClass new .

What is wrong with that.

If you do not want to have a reference at runtime to a Finder then you
need to use announcement and registration.

Stef



On Sun, Jun 4, 2017 at 11:17 PM, Vitor Medina Cruz  wrote:
> Hello,
>
> I would like to know how people in Pharo ecosystem do to deal with object
> wiring, as described by Marting Fowler in
> https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection:
>
> "A common issue to deal with is how to wire together different elements: how
> do you fit together this web controller architecture with that database
> interface backing when they were built by different teams with little
> knowledge of each other."
>
> He gives an example, I will leave it in java as it is simple enough to
> understand:
>
> "class MovieLister...
>
>   public Movie[] moviesDirectedBy(String arg) {
>   List allMovies = finder.findAll();
>   for (Iterator it = allMovies.iterator(); it.hasNext();) {
>   Movie movie = (Movie) it.next();
>   if (!movie.getDirector().equals(arg)) it.remove();
>   }
>   return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
>
>   }"
>
> The question is how to provide the finder object in a decoupled matter, a
> naive approach would be:
>
> " private MovieFinder finder;
>
>   public MovieLister() {
> finder = new ColonDelimitedMovieFinder("movies1.txt");
>
>   }"
>
> Which couples the MovieLister to the specific ColonDelimitedMovieFinder
> class.
>
> Fowler explains how to decouple using an IoC framework or a Service Locator.
> In Java and .Net IoC is used most of the time. I Googled how this problem is
> approached in Smalltalk/Pharo, and I generally I found answers "that is easy
> to do in Smalltalk, so there is no need of a framework", what I miss is a
> description on *how* to do that:
>
> https://stackoverflow.com/questions/243905/smalltalk-and-ioc
> https://stackoverflow.com/questions/2684326/is-there-a-dependency-injection-framework-for-smalltalk
> https://stackoverflow.com/questions/243905/smalltalk-and-ioc/347477#347477
>
> I know that in Smalltalk I can make MovieLister to receive, upon
> construction, a class representing MovieFinder and call it construction
> message. As long an object that responds to this message is provided, I can
> create as many derivations I want and the MovieLister will be decoupled from
> the MovieFinder. That way, however, I still have to wire things by hand, and
> I am not sure if this is what I am supposed to do in order to solve the
> decouple problem.
>
> Can you explain me how this is done in Pharo? It's is usually wiring by
> hand? Is there a simple construction that deals with the wiring problem that
> I cannot foresee?
>
> Thanks in advance,
> Vitor
>
>
>

Re: [Pharo-users] Deprecating Auto-fix: WOW

[Stephane Ducasse]

:)
little improvements one at a time but many many many times :)

On Sat, Jun 3, 2017 at 3:32 PM, Sean P. DeNigris  wrote:
> Either I died and went to heaven, or my Pharo 6 image just ported all my
> deprecated methods auto-magically. Very cool! Thanks!!!
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Deprecating-Auto-fix-WOW-tp4949164.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

[Pharo-users] XPath has unresolved dependencies

[Henrik Nergaard]

Hi,


Loading XPath from the catalog browser into the latest image raises a warning 
that there are unresolved references, and that the package depends on the 
following classes: XMLHighlighter, XMLHighlighterDefaults, 
GLMXMLHighlighterTextStylerDecorator.


The regular XPath works fine ignoring the warnings, but inspecting an XML 
document and clicking the XPath pane gives an error.


Best regards,

Henrik

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

[Vitor Medina Cruz]

Thanks for the answer Ben and Stephane.

I already read A Mentoring Course on Smalltalk, Valloud, there is nothing
there I could use in this case :( . I will look after for The Design
Patterns Smalltalk Companion. Most of the sources provided I already know
of or went in the same lines lines of what I have already found.

About TDD, I am experienced with the discipline and have tested it on Pharo
living system already, but I could not understand how this is related with
object wiring, DI and service locator.


>From ben:

"I'm not really familiar with IoC or DI patterns, so just taking your
> example at face value, in Pharo I'd do...
>
> MovieLister>>moviesDirectedBy: director
> allMovies := finder allMovies.
> ^ allMovies select: [ :movie | movie getDirector = director ].
> "although typically #getDirector would be renamed #director"
>
> MovieLister>>finder: movieFinder
> finder := movieFinder.
>
> to be used like this...
> lister := MovieLister new finder: (ColonDelimitedMovieFinder on:
> 'movies1.txt').
> movies := lister moviesDirectedBy: 'Tarantino'."


and Stephane:

Why don't you simply pass the class and use that class in your MovieLister?
>
> MovieLister new
>  finderClass: MySuperCoolFinderClass
>
> ...
> MovieLister finder
>   finderClass new .
>
> What is wrong with that.


That was what I meant when I said: "I know that in Smalltalk I can make
MovieLister to receive, upon construction, a class representing MovieFinder
and call it construction message.". The code I had in mind is a bit of mix
from the one provided by you both:

MovieLister>>moviesDirectedBy: director
allMovies := finder allMovies.
^ allMovies select: [ :movie | movie getDirector = director ].
"although typically #getDirector would be renamed #director"

MovieLister>>finder: aMovieFinderBuilder
finder := aMovieFinderClass new.

to be used like this...
lister := MovieLister new finder: (ColonDelimitedMovieFinder builderOn:
'movies1.txt').
movies := lister moviesDirectedBy: 'Tarantino'."

But that means I will have to wire dependencies by hand whenever I create a
MovieLister and seek through code when and if those dependencies change.
When there are lot's of dependencies it's is a considerable and tedious
work. Let's see an image from Fowlers article:

[image: Inline image 1]

In this case, the service locator provides me with an instance and I
configure the instance in the assembler, the scheme is alike for an IoC,
and that would mean my implementation could be like this:


MovieLister>>moviesDirectedBy: director
allMovies := finder allMovies.
^ allMovies select: [ :movie | movie getDirector = director ].
"although typically #getDirector would be renamed #director"

MovieLister>>initialize
finder := ServiceLocator locate: FinderClass   <--- This would bring
the instance of finder class configured by the assembler

to be used like this...
lister := MovieLister new.
movies := lister moviesDirectedBy: 'Tarantino'."

and the assembler:

Assember class>>configure:

aMap put: (ColonDelimitedMovieFinder builderOn: 'movies1.txt') at:
FinderClass

My assembler and service locator could be even more elaborated, and provide
a different MovieFinder in test scope, for different classes or wharever.

It is a little convenience for Smalltalk, I will give that, but I was
wandering if there was something alike in Pharo, by your answers I assuming
there is nothing like that.


If you do not want to have a reference at runtime to a Finder then you
> need to use announcement and registration.


I didn't understand that, could you elaborate?


On Mon, Jun 5, 2017 at 6:41 AM, Stephane Ducasse 
wrote:

> Why don't you simply pass the class and use that class in your MovieLister?
>
> MovieLister new
>  finderClass: MySuperCoolFinderClass
>
> ...
> MovieLister finder
>   finderClass new .
>
> What is wrong with that.
>
> If you do not want to have a reference at runtime to a Finder then you
> need to use announcement and registration.
>
> Stef
>
>
>
> On Sun, Jun 4, 2017 at 11:17 PM, Vitor Medina Cruz 
> wrote:
> > Hello,
> >
> > I would like to know how people in Pharo ecosystem do to deal with object
> > wiring, as described by Marting Fowler in
> > https://martinfowler.com/articles/injection.html#
> FormsOfDependencyInjection:
> >
> > "A common issue to deal with is how to wire together different elements:
> how
> > do you fit together this web controller architecture with that database
> > interface backing when they were built by different teams with little
> > knowledge of each other."
> >
> > He gives an example, I will leave it in java as it is simple enough to
> > understand:
> >
> > "class MovieLister...
> >
> >   public Movie[] moviesDirectedBy(String arg) {
> >   List allMovies = finder.findAll();
> >   for (Iterator it = allMovies.iterator(); it.hasNext();) {
> >   Movie movie = (Movie) it.next();
> >   if (!movie.getDirect

Re: [Pharo-users] STON Question

[Offray Vladimir Luna Cárdenas]

Hi,

Maybe what I'm doing in Grafoscopio could help.

I have a %metadata node which contains all configuration options for the
production of the document (as shown in the image below). Exporting a
document consist in looking for these nodes while traversing the
notebook tree and applying that options in the proper place. You can see
the source code of the current notebook STON file at [1], the exported
markdown file at [2] and the exported PDF at [3]. As you can see I have
pretty good control of the configuration of the document using this
option (and a single place to manage all, without endless small files
and folders for a document, but event that exporting options as split
folders and docs, could be added also).

[1] http://mutabit.com/repos.fossil/grafoscopio/artifact/fb25442038a0d4a1
[2]
http://mutabit.com/repos.fossil/grafoscopio/artifact?name=59245142cf93590b&txt=1
[3]
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf



Cheers,

Offray

On 05/06/17 01:58, Stephane Ducasse wrote:
> Sven I know what Ston is :) 
>
> Now Pillar dev used Ston as input and it works. Then with some hooks
> they let the user convert the strings
> into specific objects and this is ok. 
> Now I want to add export in Ston and for configurations I need to
> control for the application and not as a ston object the value saved.
> For example a file reference should not be just a file reference in
> Ston but 
> a string relative the the baseDirectory of the configuration. 
>
> So I thought that I can build a hook and control the call to Ston
> (convert the object before to the correct values) and export. 
> It should be working now doing this I found myself redoing the output
> of Ston. 
> So I will do it. Then I thought that may be I could reuse this logic. 
>
> Stef
>
>
>
> On Sun, Jun 4, 2017 at 11:49 PM, Sven Van Caekenberghe  > wrote:
>
> Stef,
>
> STON is like FUEL, it can write any object to a stream and read it
> back. Although you can customise how this is done, only one way of
> doing so is supported (i.e. you cannot change the format for each
> application).
>
> People have used STON for various applications now, including for
> configuration stuff (because it is a textual format that is easy
> to read).
>
> I would suggest you just try to see what your config looks like
> once you have the objects in Pharo.
>
>   STON toStringPretty: myConfig.
>
> Then we can see how to tune the representation.
>
> Sven
>
> > On 4 Jun 2017, at 22:58, Stephane Ducasse
> mailto:stepharo.s...@gmail.com>> wrote:
> >
> > Hi sven
> >
> > I'm working on a new configuration frameworks similar to the one
> use pillar.conf.
> >
> > So basically I have
> >
> > ston := '{
> >"newLine":#unix,
> >   "separateOutputFiles":true
> >   }'.
> > and I want to recreate it.
> >
> > So I did
> >
> > Object >> toConfigurationString
> >
> >   ^ STON toString: self
> >
> > SimpleConfiguration >> exportStream
> >
> >   ^ String streamContents: [ :str |
> >   str << '{' .
> >   self propertiesKeysAndValuesDo: [ :key :value|
> >   str << key toConfigurationString.
> >   str << ':'.
> >   str << value toConfigurationString.
> >   str << ','.
> >   str lf.
> >   ].
> >   str << '}'.
> >   str contents
> >   ]
> >
> > The idea is that for special configuration values people should
> be able to define
> > how to go from the object to configuration.
> > For example for some FileReference I want to have just the path
> up to the baseDirectory.
> >
> > Now I wonder if I could not better reuse ston.
> > I saw the stonOn:
> > but I did not look further because I was wondering how the
> writer where passed.
> >
> > Any feedback is welcome.
> >
> > Stef (now bed time).
> >
>
>
>



0x7095B7A1.asc
Description: application/pgp-keys

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

[Ben Coman]

On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz 
wrote:

> Thanks for the answer Ben and Stephane.
>
> I already read A Mentoring Course on Smalltalk, Valloud, there is nothing
> there I could use in this case :( . I will look after for The Design
> Patterns Smalltalk Companion. Most of the sources provided I already know
> of or went in the same lines lines of what I have already found.
>
> About TDD, I am experienced with the discipline and have tested it on
> Pharo living system already, but I could not understand how this is related
> with object wiring, DI and service locator.
>

I guess I don't properly understand your need and those topics.  That was
my quick pass.  Now if I take the time to actually read Fowler's long
article

"the inversion is about how they lookup a plugin implementation ... to
ensure that any user of a plugin follows some convention that allows a
separate assembler module to inject the implementation into the lister."

"The basic idea of the Dependency Injection is to have a separate object,
an assembler, that populates a field in the lister class with an
appropriate implementation for the finder interface. There are three main
styles of dependency injection. The names I'm using for them are
Constructor Injection, Setter Injection, and Interface Injection."

Now there was too much syntactical noise in those Java examples for me to
think clearly, so I converted them all to Smalltalk.


##CONSTRUCTOR INJECTION

Object subclass: MovieLister
instanceVariables: 'finder'


MovieLister class >> newWith: aFinder
^ self basicNew initializeWith: aFinder

MovieLister >> initializeWith: aFinder
finder := aFinder


ColonMovieFinder class >> newWith: aFilename
^ self basicNew initializeWith: aFilename

ColonMovieFinder >> initializeWith: aFilename
filename := aFilename.


ConstructorInjectionContainer >> new
container := DefaultContainer new.  "the article doesn't specify where
this comes from"
finderParams := ConstantParameter newWith: 'movies1.txt'.
container registerComponentInterface: MovieFinderInterface
  implementation: ColonMovieFinder
  params: finderParams.
container registerComponentImplementation: MovieLister
^container

to be used like this...
ConstructorInjectionTest >> testWithContainer
container := ConstructorInjectionContainer new.
lister := container getComponentInstance( MovieLister ).
movies = lister moviesDirectedBy: 'Sergio Leone'.
self assert: (movies includes: 'Once Upon a Time in the West')

The article poorly defines registerComponentXXX: or getComponentInstance:
methods, so I don't dwell on them.  I presume its little relevant to the
main theme.


##SETTER INJECTION

MovieLister >> setFinder: aFinder
finder := aFinder.

ColonMovieFinder >> setFilename: aFilename
filename := aFilename.

SetterInjectionTest >> testWithConfigurationFile
ctx := SomeXmlApplicationConfiguration on: 'config.xml'.
lister := ctx getConfigOf: 'MovieLister'.
movies = lister moviesDirectedBy: 'Sergio Leone'.
self assert: (movies includes: 'Once Upon a Time in the West')


##INTERFACE INJECTION

MovieLister >> injectFinder: aFinder
finder := aFinder

ColonMovieFinder >> injectFilename: aFilename
filename := aFilename

InterfaceInjectionTest >> configureContainer
container := InterfaceInjectionContainer new.
self registerComponents.
self registerInjectors.
container start.

InterfaceInjectionTest >> registerComponents
container registerComponent: 'MovieLister' with: MovieLister.
container registerComponent: 'MovieFinder' with: ColonMovieFinder.

InterfaceInjectionTest >> registerInjectors
container registerInjector: Injector  with: (container lookup:
'MovieFinder').
container registerInjector: InjectorFinderFilename  with:
FinderFilenameInjector new.

ColonMovieFinder >> inject: anObject
anObject injectFinder: self.

FinderFilenameInjector >> inject: anObject
anObject injectFilename: 'movies1.txt'.

InterfaceInjectionTester >> testInterface
self configureContainer.
lister := container lookup: 'MovieLister'.
movies = lister moviesDirectedBy: 'Sergio Leone'.
self assert: (movies includes: 'Once Upon a Time in the West')

The article doesn't define InterfaceInjectionContainer, but I guess it
could look like this...

InterfaceInjectionContainer >> registerComponent: componentName with:
aComponent
container ifNil: [ container := Dictionary new].
container at: componentName put: aComponent

InterfaceInjectionContainer >> lookup: componentName
^ container at: componentName


##SERVICE LOCATOR

"The basic idea behind a service locator is to have an object that knows
how to get hold of all of the services that an application might need. So a
service locator for this application would have a method that returns a
movie finder when one is needed. Of course this just shifts the burden a
tad, we still have 

Re: [Pharo-users] STON Question

[Stephane Ducasse]

Hi offray

Thanks but pillar ha a conf since several years and it is working well. Now
I'm revisiting the implementation of cocoon
because I want to have it simpler independent of magritte and better tested.

Now I just want to add a new functionality to output a configuration file
from the
objects and in Pillar the configuration objects hold more complex
***objects***.
So just taking the object and turning it in ston does not work.

Stef

On Mon, Jun 5, 2017 at 6:23 PM, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
> Maybe what I'm doing in Grafoscopio could help.
>
> I have a %metadata node which contains all configuration options for the
> production of the document (as shown in the image below). Exporting a
> document consist in looking for these nodes while traversing the notebook
> tree and applying that options in the proper place. You can see the source
> code of the current notebook STON file at [1], the exported markdown file
> at [2] and the exported PDF at [3]. As you can see I have pretty good
> control of the configuration of the document using this option (and a
> single place to manage all, without endless small files and folders for a
> document, but event that exporting options as split folders and docs, could
> be added also).
> [1] http://mutabit.com/repos.fossil/grafoscopio/artifact/fb25442038a0d4a1
> [2] http://mutabit.com/repos.fossil/grafoscopio/artifact?
> name=59245142cf93590b&txt=1
> [3] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/
> Docs/En/Books/Manual/manual.pdf
>
>
>
> Cheers,
>
> Offray
>
>
> On 05/06/17 01:58, Stephane Ducasse wrote:
>
> Sven I know what Ston is :)
>
> Now Pillar dev used Ston as input and it works. Then with some hooks they
> let the user convert the strings
> into specific objects and this is ok.
> Now I want to add export in Ston and for configurations I need to control
> for the application and not as a ston object the value saved.
> For example a file reference should not be just a file reference in Ston
> but
> a string relative the the baseDirectory of the configuration.
>
> So I thought that I can build a hook and control the call to Ston (convert
> the object before to the correct values) and export.
> It should be working now doing this I found myself redoing the output of
> Ston.
> So I will do it. Then I thought that may be I could reuse this logic.
>
> Stef
>
>
>
> On Sun, Jun 4, 2017 at 11:49 PM, Sven Van Caekenberghe 
> wrote:
>
>> Stef,
>>
>> STON is like FUEL, it can write any object to a stream and read it back.
>> Although you can customise how this is done, only one way of doing so is
>> supported (i.e. you cannot change the format for each application).
>>
>> People have used STON for various applications now, including for
>> configuration stuff (because it is a textual format that is easy to read).
>>
>> I would suggest you just try to see what your config looks like once you
>> have the objects in Pharo.
>>
>>   STON toStringPretty: myConfig.
>>
>> Then we can see how to tune the representation.
>>
>> Sven
>>
>> > On 4 Jun 2017, at 22:58, Stephane Ducasse 
>> wrote:
>> >
>> > Hi sven
>> >
>> > I'm working on a new configuration frameworks similar to the one use
>> pillar.conf.
>> >
>> > So basically I have
>> >
>> > ston := '{
>> >"newLine":#unix,
>> >   "separateOutputFiles":true
>> >   }'.
>> > and I want to recreate it.
>> >
>> > So I did
>> >
>> > Object >> toConfigurationString
>> >
>> >   ^ STON toString: self
>> >
>> > SimpleConfiguration >> exportStream
>> >
>> >   ^ String streamContents: [ :str |
>> >   str << '{' .
>> >   self propertiesKeysAndValuesDo: [ :key :value|
>> >   str << key toConfigurationString.
>> >   str << ':'.
>> >   str << value toConfigurationString.
>> >   str << ','.
>> >   str lf.
>> >   ].
>> >   str << '}'.
>> >   str contents
>> >   ]
>> >
>> > The idea is that for special configuration values people should be able
>> to define
>> > how to go from the object to configuration.
>> > For example for some FileReference I want to have just the path up to
>> the baseDirectory.
>> >
>> > Now I wonder if I could not better reuse ston.
>> > I saw the stonOn:
>> > but I did not look further because I was wondering how the writer where
>> passed.
>> >
>> > Any feedback is welcome.
>> >
>> > Stef (now bed time).
>> >
>>
>>
>>
>
>

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

[Stephane Ducasse]

Tx ben.
When I see all this complexity for something that looks not that complex: I
prefer to pass the class and get done.
May be I missed something obvious... but when I see something too complex I
start to get worried.

I think that thinking about the contract between classes at runtime is
important and to me a MovieLister should be using at runtime and instance
of the *Finder*
Now needing an extra class just to set this should really be evaluated with
the tradeoff: "flexibility win" (our simple solution is still really
flexible - I decide when I want to pass the correct finder) vs. the code
and conceptual bloat.


I'm happy not to face the hyper super over engineering of Java "solutions".

I like the "Of course this just shifts the burden a tad, we still have to
get the locator into the lister"
but the solution is super simple let us use another "Singleton and a
Factory" :)

Stef

On Mon, Jun 5, 2017 at 8:43 PM, Ben Coman  wrote:

>
>
> On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz 
> wrote:
>
>> Thanks for the answer Ben and Stephane.
>>
>> I already read A Mentoring Course on Smalltalk, Valloud, there is
>> nothing there I could use in this case :( . I will look after for The
>> Design Patterns Smalltalk Companion. Most of the sources provided I already
>> know of or went in the same lines lines of what I have already found.
>>
>> About TDD, I am experienced with the discipline and have tested it on
>> Pharo living system already, but I could not understand how this is related
>> with object wiring, DI and service locator.
>>
>
> I guess I don't properly understand your need and those topics.  That was
> my quick pass.  Now if I take the time to actually read Fowler's long
> article
>
> "the inversion is about how they lookup a plugin implementation ... to
> ensure that any user of a plugin follows some convention that allows a
> separate assembler module to inject the implementation into the lister."
>
> "The basic idea of the Dependency Injection is to have a separate object,
> an assembler, that populates a field in the lister class with an
> appropriate implementation for the finder interface. There are three main
> styles of dependency injection. The names I'm using for them are
> Constructor Injection, Setter Injection, and Interface Injection."
>
> Now there was too much syntactical noise in those Java examples for me to
> think clearly, so I converted them all to Smalltalk.
>
>
> ##CONSTRUCTOR INJECTION
>
> Object subclass: MovieLister
> instanceVariables: 'finder'
>
>
> MovieLister class >> newWith: aFinder
> ^ self basicNew initializeWith: aFinder
>
> MovieLister >> initializeWith: aFinder
> finder := aFinder
>
>
> ColonMovieFinder class >> newWith: aFilename
> ^ self basicNew initializeWith: aFilename
>
> ColonMovieFinder >> initializeWith: aFilename
> filename := aFilename.
>
>
> ConstructorInjectionContainer >> new
> container := DefaultContainer new.  "the article doesn't specify where
> this comes from"
> finderParams := ConstantParameter newWith: 'movies1.txt'.
> container registerComponentInterface: MovieFinderInterface
>   implementation: ColonMovieFinder
>   params: finderParams.
> container registerComponentImplementation: MovieLister
> ^container
>
> to be used like this...
> ConstructorInjectionTest >> testWithContainer
> container := ConstructorInjectionContainer new.
> lister := container getComponentInstance( MovieLister ).
> movies = lister moviesDirectedBy: 'Sergio Leone'.
> self assert: (movies includes: 'Once Upon a Time in the West')
>
> The article poorly defines registerComponentXXX: or getComponentInstance:
> methods, so I don't dwell on them.  I presume its little relevant to the
> main theme.
>
>
> ##SETTER INJECTION
>
> MovieLister >> setFinder: aFinder
> finder := aFinder.
>
> ColonMovieFinder >> setFilename: aFilename
> filename := aFilename.
>
> SetterInjectionTest >> testWithConfigurationFile
> ctx := SomeXmlApplicationConfiguration on: 'config.xml'.
> lister := ctx getConfigOf: 'MovieLister'.
> movies = lister moviesDirectedBy: 'Sergio Leone'.
> self assert: (movies includes: 'Once Upon a Time in the West')
>
>
> ##INTERFACE INJECTION
>
> MovieLister >> injectFinder: aFinder
> finder := aFinder
>
> ColonMovieFinder >> injectFilename: aFilename
> filename := aFilename
>
> InterfaceInjectionTest >> configureContainer
> container := InterfaceInjectionContainer new.
> self registerComponents.
> self registerInjectors.
> container start.
>
> InterfaceInjectionTest >> registerComponents
> container registerComponent: 'MovieLister' with: MovieLister.
> container registerComponent: 'MovieFinder' with: ColonMovieFinder.
>
> InterfaceInjectionTest >> registerInjectors
> container registerInjector: Injector  with: (container lookup:
> 'MovieFinder').
> container registerInjector: InjectorFinderFilen

Re: [Pharo-users] STON Question

[Offray Vladimir Luna Cárdenas]

Ok Stef. Happy that we're exploring different paths ;-).

Cheers,

Offray


On 05/06/17 13:56, Stephane Ducasse wrote:
> Hi offray
>
> Thanks but pillar ha a conf since several years and it is working
> well. Now I'm revisiting the implementation of cocoon 
> because I want to have it simpler independent of magritte and better
> tested.
>
> Now I just want to add a new functionality to output a configuration
> file from the 
> objects and in Pillar the configuration objects hold more complex
> ***objects***. 
> So just taking the object and turning it in ston does not work. 
>
> Stef
>
> On Mon, Jun 5, 2017 at 6:23 PM, Offray Vladimir Luna Cárdenas
> mailto:offray.l...@mutabit.com>> wrote:
>
> Hi,
>
> Maybe what I'm doing in Grafoscopio could help.
>
> I have a %metadata node which contains all configuration options
> for the production of the document (as shown in the image below).
> Exporting a document consist in looking for these nodes while
> traversing the notebook tree and applying that options in the
> proper place. You can see the source code of the current notebook
> STON file at [1], the exported markdown file at [2] and the
> exported PDF at [3]. As you can see I have pretty good control of
> the configuration of the document using this option (and a single
> place to manage all, without endless small files and folders for a
> document, but event that exporting options as split folders and
> docs, could be added also).
>
> [1]
> http://mutabit.com/repos.fossil/grafoscopio/artifact/fb25442038a0d4a1
> 
> [2]
> 
> http://mutabit.com/repos.fossil/grafoscopio/artifact?name=59245142cf93590b&txt=1
> 
> 
> [3]
> 
> http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf
> 
> 
>
>
>
> Cheers,
>
> Offray
>
>
> On 05/06/17 01:58, Stephane Ducasse wrote:
>> Sven I know what Ston is :) 
>>
>> Now Pillar dev used Ston as input and it works. Then with some
>> hooks they let the user convert the strings
>> into specific objects and this is ok. 
>> Now I want to add export in Ston and for configurations I need to
>> control for the application and not as a ston object the value saved.
>> For example a file reference should not be just a file reference
>> in Ston but 
>> a string relative the the baseDirectory of the configuration. 
>>
>> So I thought that I can build a hook and control the call to Ston
>> (convert the object before to the correct values) and export. 
>> It should be working now doing this I found myself redoing the
>> output of Ston. 
>> So I will do it. Then I thought that may be I could reuse this
>> logic. 
>>
>> Stef
>>
>>
>>
>> On Sun, Jun 4, 2017 at 11:49 PM, Sven Van Caekenberghe
>> mailto:s...@stfx.eu>> wrote:
>>
>> Stef,
>>
>> STON is like FUEL, it can write any object to a stream and
>> read it back. Although you can customise how this is done,
>> only one way of doing so is supported (i.e. you cannot change
>> the format for each application).
>>
>> People have used STON for various applications now, including
>> for configuration stuff (because it is a textual format that
>> is easy to read).
>>
>> I would suggest you just try to see what your config looks
>> like once you have the objects in Pharo.
>>
>>   STON toStringPretty: myConfig.
>>
>> Then we can see how to tune the representation.
>>
>> Sven
>>
>> > On 4 Jun 2017, at 22:58, Stephane Ducasse
>> mailto:stepharo.s...@gmail.com>> wrote:
>> >
>> > Hi sven
>> >
>> > I'm working on a new configuration frameworks similar to
>> the one use pillar.conf.
>> >
>> > So basically I have
>> >
>> > ston := '{
>> >"newLine":#unix,
>> >   "separateOutputFiles":true
>> >   }'.
>> > and I want to recreate it.
>> >
>> > So I did
>> >
>> > Object >> toConfigurationString
>> >
>> >   ^ STON toString: self
>> >
>> > SimpleConfiguration >> exportStream
>> >
>> >   ^ String streamContents: [ :str |
>> >   str << '{' .
>> >   self propertiesKeysAndValuesDo: [ :key :value|
>> >   str << key toConfigurationString.
>> >   str << ':'.
>> >   str << value toConfigurationString.
>> >   str << ','.
>> >   str

Re: [Pharo-users] Saving selected changes in Monticello

[Andreas Sunardi]

I definitely will check Komitter and I can use and fallback to Ben's
method. Thank you to all of you.

On Mon, Jun 5, 2017 at 12:58 AM, Peter Uhnak  wrote:

> Komitter could indeed help you, see https://www.peteruhnak.com/
> blog/2016/08/12/fine-grained-committing-and-extending-nautilus/
>
> Peter
>
> On Mon, Jun 05, 2017 at 08:27:23AM +0200, serge.stinckw...@gmail.com
> wrote:
> > Kommiter available in default image allows you do cherry pick quite
> easily.
> >
> > Envoyé de mon iPhone
> >
> > > Le 5 juin 2017 à 07:14, Ben Coman  a écrit :
> > >
> > >
> > >
> > >> On Mon, Jun 5, 2017 at 10:12 AM, Andreas Sunardi 
> wrote:
> > >> I have a half done changes in my image, but I need to distribute the
> other changes that are done. I thought I was going to do this all at once,
> but now I realize I should split this into 2 commit versions.
> > >>
> > >> Is there a way in Monticello to say save my changes, but not this and
> that changes? I can't seem to find it nor in books. How do people deal with
> this situation?
> > >
> > > AFAIK, Monticello cannot cherry pick.  One work around is probably
> something like...
> > > 1. Save the mcz locally
> > > 2. Merge back into a fresh image selecting only the bits you want.
> > > 3. Save as a second mcz.
> > > One issue is that the second mcz will have the first mcz as an
> ancestor, so before 2 you might create a new changeset to file out after 2,
> and load that into a second new image. yuck!
> > >
> > > Another alternative might be to use Tools > ChangeSorter to move the
> code you want to exclude from the mcz to a changeset, file that out and
> then revert that code in the image. After save the package to a mcz, reload
> the changeset.
> > >
> > > cheers -ben
>
>

[Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

I found this StackOverflow question:
https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pharo-image-without-changes-and-sources-files/14747328

and this older forum thread:
https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.html

I'm using Pharo5.0 and neither of these options is available anymore. What
is the new way to do this?

--
Andreas Sunardi

Re: [Pharo-users] XPath has unresolved dependencies

[monty]

Thanks, it should be fixed now.
 

Sent: Monday, June 05, 2017 at 6:50 AM
From: "Henrik Nergaard" 
To: "Any question about pharo is welcome" , "mon...@programmer.net" 
Subject: XPath has unresolved dependencies




Hi,

 

Loading XPath from the catalog browser into the latest image raises a warning that there are unresolved references, and that the package depends on the following classes: XMLHighlighter, XMLHighlighterDefaults, GLMXMLHighlighterTextStylerDecorator. 

 

The regular XPath works fine ignoring the warnings, but inspecting an XML document and clicking the XPath pane gives an error.

 

 

Best regards,

Henrik

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

[Ben Coman]

On Tue, Jun 6, 2017 at 5:11 AM, Stephane Ducasse 
wrote:

> Tx ben.
> When I see all this complexity for something that looks not that complex:
> I prefer to pass the class and get done.
> May be I missed something obvious... but when I see something too complex
> I start to get worried.
>
> I think that thinking about the contract between classes at runtime is
> important and to me a MovieLister should be using at runtime and instance
> of the *Finder*
> Now needing an extra class just to set this should really be evaluated
> with the tradeoff: "flexibility win" (our simple solution is still really
> flexible - I decide when I want to pass the correct finder) vs. the code
> and conceptual bloat.
>
>
> I'm happy not to face the hyper super over engineering of Java "solutions".
>
> I like the "Of course this just shifts the burden a tad, we still have to
> get the locator into the lister"
> but the solution is super simple let us use another "Singleton and a
> Factory" :)
>
> Stef
>
> On Mon, Jun 5, 2017 at 8:43 PM, Ben Coman  wrote:
>
>>
>>
>> On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz 
>> wrote:
>>
>>> Thanks for the answer Ben and Stephane.
>>>
>>> I already read A Mentoring Course on Smalltalk, Valloud, there is
>>> nothing there I could use in this case :( . I will look after for The
>>> Design Patterns Smalltalk Companion. Most of the sources provided I already
>>> know of or went in the same lines lines of what I have already found.
>>>
>>> About TDD, I am experienced with the discipline and have tested it on
>>> Pharo living system already, but I could not understand how this is related
>>> with object wiring, DI and service locator.
>>>
>>
>> I guess I don't properly understand your need and those topics.  That was
>> my quick pass.  Now if I take the time to actually read Fowler's long
>> article
>>
>> "the inversion is about how they lookup a plugin implementation ... to
>> ensure that any user of a plugin follows some convention that allows a
>> separate assembler module to inject the implementation into the lister."
>>
>> "The basic idea of the Dependency Injection is to have a separate object,
>> an assembler, that populates a field in the lister class with an
>> appropriate implementation for the finder interface. There are three main
>> styles of dependency injection. The names I'm using for them are
>> Constructor Injection, Setter Injection, and Interface Injection."
>>
>> Now there was too much syntactical noise in those Java examples for me to
>> think clearly, so I converted them all to Smalltalk.
>>
>>
>> ##CONSTRUCTOR INJECTION
>>
>> Object subclass: MovieLister
>> instanceVariables: 'finder'
>>
>>
>> MovieLister class >> newWith: aFinder
>> ^ self basicNew initializeWith: aFinder
>>
>> MovieLister >> initializeWith: aFinder
>> finder := aFinder
>>
>>
>> ColonMovieFinder class >> newWith: aFilename
>> ^ self basicNew initializeWith: aFilename
>>
>> ColonMovieFinder >> initializeWith: aFilename
>> filename := aFilename.
>>
>>
>> ConstructorInjectionContainer >> new
>> container := DefaultContainer new.  "the article doesn't specify
>> where this comes from"
>> finderParams := ConstantParameter newWith: 'movies1.txt'.
>> container registerComponentInterface: MovieFinderInterface
>>   implementation: ColonMovieFinder
>>   params: finderParams.
>> container registerComponentImplementation: MovieLister
>> ^container
>>
>> to be used like this...
>> ConstructorInjectionTest >> testWithContainer
>> container := ConstructorInjectionContainer new.
>> lister := container getComponentInstance( MovieLister ).
>> movies = lister moviesDirectedBy: 'Sergio Leone'.
>> self assert: (movies includes: 'Once Upon a Time in the West')
>>
>> The article poorly defines registerComponentXXX: or getComponentInstance:
>> methods, so I don't dwell on them.  I presume its little relevant to the
>> main theme.
>>
>>
>> ##SETTER INJECTION
>>
>> MovieLister >> setFinder: aFinder
>> finder := aFinder.
>>
>> ColonMovieFinder >> setFilename: aFilename
>> filename := aFilename.
>>
>> SetterInjectionTest >> testWithConfigurationFile
>> ctx := SomeXmlApplicationConfiguration on: 'config.xml'.
>> lister := ctx getConfigOf: 'MovieLister'.
>> movies = lister moviesDirectedBy: 'Sergio Leone'.
>> self assert: (movies includes: 'Once Upon a Time in the West')
>>
>>
>> ##INTERFACE INJECTION
>>
>> MovieLister >> injectFinder: aFinder
>> finder := aFinder
>>
>> ColonMovieFinder >> injectFilename: aFilename
>> filename := aFilename
>>
>> InterfaceInjectionTest >> configureContainer
>> container := InterfaceInjectionContainer new.
>> self registerComponents.
>> self registerInjectors.
>> container start.
>>
>> InterfaceInjectionTest >> registerComponents
>> container registerComponent: 'MovieLister' with: MovieLister.
>> container registerComponent: 'MovieFinder' 

Re: [Pharo-users] How to deploy headless app without changes and source files?

[Andreas Sunardi]

I had my changes and sources files in the bundle but has their write
permission removed, and that causes the error. Simply deploying the tool
without the changes file seems to fix it. Pharo5 doesn't complain if the
changes file isn't there.

However, without the sources file, I get this warning that pharo cannot
locate the sources file. Including the sources file in the deployed tool is
fine with me.

So, I think that's my solution. Thanks!


On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi  wrote:

> I found this StackOverflow question:
> https://stackoverflow.com/questions/14737695/is-it-
> possible-to-deploy-a-pharo-image-without-changes-and-
> sources-files/14747328
>
> and this older forum thread:
> https://www.mail-archive.com/pharo-project@lists.gforge.
> inria.fr/msg21170.html
>
> I'm using Pharo5.0 and neither of these options is available anymore. What
> is the new way to do this?
>
> --
> Andreas Sunardi
>

[Pharo-users] Bloc/Brick/Spec

[Brad Selfridge]

I'm confused. I see the latest news and documentation about Bloc. Is Brick
now dead and Bloc the default? I thought Brick was a layer on top of Bloc
and Spec was layer on top on Brick? What is the direction now? 

Brad Selfridge



-
Brad Selfridge
--
View this message in context: 
http://forum.world.st/Bloc-Brick-Spec-tp4949591.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] [Pharo-dev] GSoC Week 3 update - Enhancing Pharo Command Line

[Ben Coman]

On Thu, Jun 1, 2017 at 5:06 PM, Rajula Vineet 
wrote:

> Hi all,
>
> It has been about three weeks, I started working on my GSoC project. The
> first task I am working on is the new implementation for Current Working
> Directory. I have written the new implementation. Currently, I am testing
> the new code. Will soon share the work here.



> Meanwhile, for the week three, I have written a blog  post
> 
> on OSPlatfrom. Please do take a look and give your feedback.
>
> Thanks,
> Rajula
>
>
>
Hi Rajula,

Great to see an article on this subject.  Probably its at a good level for
pharo-users mail list as well, so I've copied there.  Don't worry about the
limited response.  Many in pharo-dev probably know this subject well.  It
is still good to have it laid out like you did for newcomers to google when
they need to know.

cheers -ben

[Pharo-users] Slant question

[john pfersich]

Slant has a question/poll out there

It's at 
https://www.slant.co/topics/25/~best-programming-language-to-learn-first?utm_source=Slant&utm_campaign=digest&utm_medium=email&utm_content=questions

Let's pile on it!

Sent from my iPhone

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

[Peter Uhnak]

* Bloc - low level library (think basic shapes, rectangles, ...)
* Brick - widget library on top of Bloc akin to the widget part of Morphic 
(buttons, checkboxes, ...)
* Spec - UI framework with adaptable backend; currently using Morphic as a 
backend, however once Bloc/Brick matures, Bloc/Brick will be added as another 
backend (without affecting Spec users)

(and below Bloc is Sparta, which is a vector canvas)

Peter

On Mon, Jun 05, 2017 at 06:20:47PM -0700, Brad Selfridge wrote:
> I'm confused. I see the latest news and documentation about Bloc. Is Brick
> now dead and Bloc the default? I thought Brick was a layer on top of Bloc
> and Spec was layer on top on Brick? What is the direction now? 
> 
> Brad Selfridge
> 
> 
> 
> -
> Brad Selfridge
> --
> View this message in context: 
> http://forum.world.st/Bloc-Brick-Spec-tp4949591.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>