Re: [Pharo-users] Dark theme and white vs. green color

[john pfersich]

Thanks, I was looking for "color" in an already open settings browser. That 
doesn't work. 

Sent from my iPhone

> On Apr 28, 2017, at 18:15, Ben Coman  wrote:
> 
> 
> 
>> On Sat, Apr 29, 2017 at 5:02 AM, john pfersich  wrote:
>> I agree, that dark theme is harder to read than green on black. I just want 
>> the old light theme, how do I get it?
>> 
>> Sent from my iPhone
>> 
>> > On Apr 28, 2017, at 09:42, Juraj Kubelka  wrote:
>> >
>> > it:
> 
> Go to System > Settings and search for "theme".
> 
> cheers -ben 
> 

Re: [Pharo-users] Dark theme and white vs. green color

[Ben Coman]

On Sat, Apr 29, 2017 at 5:02 AM, john pfersich  wrote:

> I agree, that dark theme is harder to read than green on black. I just
> want the old light theme, how do I get it?
>
> Sent from my iPhone
>
> > On Apr 28, 2017, at 09:42, Juraj Kubelka 
> wrote:
> >
> > it:
>

Go to System > Settings and search for "theme".

cheers -ben

Re: [Pharo-users] Spec Adapter Advice

[Ben Coman]

On Sat, Apr 29, 2017 at 4:20 AM, Rob Rothwell 
wrote:

> Hi Peter,
>
> Thanks again for the advice. I've reduced my number of infinite loops and
> crashes by creating copies of pertinent classes and using them for testing,
> but I have quickly learned to save my image after inserting a halt anywhere!
>

Its a bit of a trick to learn to change the wheels on the car while its
still driving, but also very useful.
Try using #haltOnce instead.

cheers -ben


>
> The parallel Spec implementation conversation is interesting too, but
> unfortunately I don't understand enough to participate very much yet.
>
> However, I have discovered by creating new ComposableModel, WindowModel,
> and MorphicWindowAdapter classes that even the SpecInterpreter itself is
> hard-wired to use Morphic.
>
> If you take a look at
>
> WindowModel>>privateAdapterFromModel: aModel withSpec: aSpec
> "apparently when looking at the implementation, it does not return a
> widget but an adapter so it should be called adapter :)"
> self halt.
> ^ SpecInterpreter private_buildWidgetFor: self withSpec: aSpec.
>
> You see from the correct comment that an adapter is created during this
> operation, which I think (I'm not that far yet) comes from
>
> SpecInterpreter class>>defaultBindings
> ^ MorphicAdapterBindings new
>
> In other words, I think that regardless of WindowModel class>>adapterName
> (and presumably all other "Model" classes, the actual adapter used is at
> present determined by the SpecInterpreter via MorphicAdapterBindings>>
> initializeBindings.
>
> You can set the bindings on the class side, but I currently don't see a
> way to say "open this spec using these bindings."  In other words,
> something like:
>
> MyApplication new openWithSpecAndBindings: MorphicAdapterBindings.
>
> or simply
>
> MyApplication openAsMorphicSpec, MyApplication openAsCocoaSpec, etc...
>
> It's starting to make some sense at a high level, though.  Eventually I'll
> find a spot where I can create a CocoaWindow and start figuring out the
> minimum interface requirements!
>
> Take care,
>
> Rob
>
>
>
>
>
>
> On Fri, Apr 28, 2017 at 6:13 AM, Peter Uhnak  wrote:
>
>> Hi Rob,
>>
>> > I need to find a good starting point because you can't poke at the
>> existing
>> > code too much since even the debugger is built with Spec!
>>
>> I don't know what Pharo you are on, but this is not the case. Debugger
>> itself is based on Glamour (there used to be SpecDebugger, but it is no
>> longer used).
>>
>> What is blowing up on you is the predebugger window, which is in Spec.
>> You can disable this in your settings or by calling
>>
>> GTGenericStackDebugger alwaysOpenFullDebugger: true
>>
>> this will skip the debugger.
>>
>> But keep in mind that other tools might be using spec too (like the
>> Browser window that opens when you are listing senders/implementors.
>>
>> overriding the #windowClass (or whatever the name was) is a good start.
>>
>> (also FML because apparently I've deleted my image with my spec changes
>> by accident -_-)
>>
>> Peter
>>
>> >
>> > It's pretty exciting, though, because it feels like all the right pieces
>> > are there and a lot of this could mostly be "just work" once I get
>> going.
>> >
>> > Thanks again,
>> >
>> > Rob
>> >
>> > On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak  wrote:
>> >
>> > > Hi Rob,
>> > >
>> > > I guess the best resource at the moment is to just look at existing
>> > > adapters.
>> > >
>> > > But here are some thoughts to get you started:
>> > >
>> > > (Spec) ComposableModel has as its widget (Spec) Adapter
>> > > Adapter has as its widget the actual visual component, which currently
>> > > means Morphic.
>> > >
>> > >
>> > > The simplest example: LabelModel
>> > >
>> > > 1. model to adapter
>> > >
>> > > LabelModel is adapted by MorphicLabelAdapter:
>> > >
>> > > you can see on the class side in method `defaultSpec`.
>> > > There is only `LabelAdapter` there because there is some extra
>> mapping for
>> > > some classes, but you can specify directly the class of the Adapter,
>> so the
>> > > following would work just as well:
>> > >
>> > > LabelModel class>>defaultSpec
>> > > 
>> > >
>> > > ^ #(MorphicLabelAdapter
>> > > adapt: #(model))
>> > >
>> > >
>> > > LabelModel -> LabelAdapter direct event propagation (pushing changes)
>> > >
>> > > in Model world you can call changed:with: to execute code on the
>> Adapter,
>> > > e.g.
>> > >
>> > > self changed: #emphasis: with: {emphasis}
>> > >
>> > > which in turn will call the #emphasis: method on the LabelAdapter.
>> > >
>> > > LabelModel -> LabelAdapter events (pulling changes)
>> > >
>> > > preferred alternative is to do the opposite; properties of models are
>> > > often held in ValueHolders, which can be observed on ValueChange, so
>> the
>> > > Adapter can register to event change and react on itself;
>> > >
>> > > you can see this best in MorphicTabAdapter (but you will see that
>> > > TabAdapter looks a bit different from the rest, becau

Re: [Pharo-users] Voyage - collecting data from Mongo

[Holger Freyther]

> On 28. Apr 2017, at 14:27, Mark Rizun  wrote:
> 
> Hi,

Hi!


> Is it possible to retrieve data from Mongo collection if it was not created
> via Voyage?
> Meaning that I do not have a class in Pharo that would correspond to said
> collection (should I implement one?).

Yes. But you probably need to customize a bit.

1.) Make sure you refer to the right collection...

descriptionContainer

^VOMongoContainer new
collectionName: 'yourExistingCollectionName'
yourself


2.) For materialization.. you should at least have
_id (okay every entry does that)
VOMongoSerializer fieldVersion (#version on my old Voyage)
VOMongoSerializer fieldType (#instanceOf)

and then things should work out. You can probably add #version and #instanceOf 
to your existing objects?



holger

Re: [Pharo-users] Dark theme and white vs. green color

[john pfersich]

I agree, that dark theme is harder to read than green on black. I just want the 
old light theme, how do I get it?

Sent from my iPhone

> On Apr 28, 2017, at 09:42, Juraj Kubelka  wrote:
> 
> it:

Re: [Pharo-users] Spec Adapter Advice

[Rob Rothwell]

Hi Peter,

Thanks again for the advice. I've reduced my number of infinite loops and
crashes by creating copies of pertinent classes and using them for testing,
but I have quickly learned to save my image after inserting a halt anywhere!

The parallel Spec implementation conversation is interesting too, but
unfortunately I don't understand enough to participate very much yet.

However, I have discovered by creating new ComposableModel, WindowModel,
and MorphicWindowAdapter classes that even the SpecInterpreter itself is
hard-wired to use Morphic.

If you take a look at

WindowModel>>privateAdapterFromModel: aModel withSpec: aSpec
"apparently when looking at the implementation, it does not return a widget
but an adapter so it should be called adapter :)"
self halt.
^ SpecInterpreter private_buildWidgetFor: self withSpec: aSpec.

You see from the correct comment that an adapter is created during this
operation, which I think (I'm not that far yet) comes from

SpecInterpreter class>>defaultBindings
^ MorphicAdapterBindings new

In other words, I think that regardless of WindowModel class>>adapterName
(and presumably all other "Model" classes, the actual adapter used is at
present determined by the SpecInterpreter via
MorphicAdapterBindings>>initializeBindings.

You can set the bindings on the class side, but I currently don't see a way
to say "open this spec using these bindings."  In other words, something
like:

MyApplication new openWithSpecAndBindings: MorphicAdapterBindings.

or simply

MyApplication openAsMorphicSpec, MyApplication openAsCocoaSpec, etc...

It's starting to make some sense at a high level, though.  Eventually I'll
find a spot where I can create a CocoaWindow and start figuring out the
minimum interface requirements!

Take care,

Rob






On Fri, Apr 28, 2017 at 6:13 AM, Peter Uhnak  wrote:

> Hi Rob,
>
> > I need to find a good starting point because you can't poke at the
> existing
> > code too much since even the debugger is built with Spec!
>
> I don't know what Pharo you are on, but this is not the case. Debugger
> itself is based on Glamour (there used to be SpecDebugger, but it is no
> longer used).
>
> What is blowing up on you is the predebugger window, which is in Spec. You
> can disable this in your settings or by calling
>
> GTGenericStackDebugger alwaysOpenFullDebugger: true
>
> this will skip the debugger.
>
> But keep in mind that other tools might be using spec too (like the
> Browser window that opens when you are listing senders/implementors.
>
> overriding the #windowClass (or whatever the name was) is a good start.
>
> (also FML because apparently I've deleted my image with my spec changes by
> accident -_-)
>
> Peter
>
> >
> > It's pretty exciting, though, because it feels like all the right pieces
> > are there and a lot of this could mostly be "just work" once I get going.
> >
> > Thanks again,
> >
> > Rob
> >
> > On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak  wrote:
> >
> > > Hi Rob,
> > >
> > > I guess the best resource at the moment is to just look at existing
> > > adapters.
> > >
> > > But here are some thoughts to get you started:
> > >
> > > (Spec) ComposableModel has as its widget (Spec) Adapter
> > > Adapter has as its widget the actual visual component, which currently
> > > means Morphic.
> > >
> > >
> > > The simplest example: LabelModel
> > >
> > > 1. model to adapter
> > >
> > > LabelModel is adapted by MorphicLabelAdapter:
> > >
> > > you can see on the class side in method `defaultSpec`.
> > > There is only `LabelAdapter` there because there is some extra mapping
> for
> > > some classes, but you can specify directly the class of the Adapter,
> so the
> > > following would work just as well:
> > >
> > > LabelModel class>>defaultSpec
> > > 
> > >
> > > ^ #(MorphicLabelAdapter
> > > adapt: #(model))
> > >
> > >
> > > LabelModel -> LabelAdapter direct event propagation (pushing changes)
> > >
> > > in Model world you can call changed:with: to execute code on the
> Adapter,
> > > e.g.
> > >
> > > self changed: #emphasis: with: {emphasis}
> > >
> > > which in turn will call the #emphasis: method on the LabelAdapter.
> > >
> > > LabelModel -> LabelAdapter events (pulling changes)
> > >
> > > preferred alternative is to do the opposite; properties of models are
> > > often held in ValueHolders, which can be observed on ValueChange, so
> the
> > > Adapter can register to event change and react on itself;
> > >
> > > you can see this best in MorphicTabAdapter (but you will see that
> > > TabAdapter looks a bit different from the rest, because I was
> experimenting
> > > with cleaning up Adapters...)
> > >
> > > 2. adapter to morphic
> > >
> > > Every adapter implements #buildWidget method that returns a Morphic
> Object.
> > > Typically the adapter registers itself as the model of the adapter (so
> > > adapter's model is Spec, and Morphic's model is the adapter). This
> depends
> > > a lot on the API of morphic. (in TabAdapter 

Re: [Pharo-users] Neural Networks in Pharo

[francesco agati]

now work all good with last version of polymath
thanks :-)

2017-04-27 17:29 GMT+02:00 Oleks :

> Hello,
>
> I have finally added a configuration to the NeuralNetwork project. Now you
> can use this Metacello script to load it into your Pharo image:
>
> Metacello new
>   repository: 'http://smalltalkhub.com/mc/Oleks/NeuralNetwork/main';
>   configuration: 'MLNeuralNetwork';
>   version: #development;
>   load.
>
> Sorry for the delay
>
> Oleks
>
> On Tue, Apr 25, 2017 at 4:13 PM, francescoagati [via Smalltalk] <[hidden
> email] > wrote:
>
>> thanks ;-)
>>
>> 2017-04-25 15:09 GMT+02:00 Oleks <[hidden email]
>> >:
>>
>>> Hello,
>>>
>>> There isn't one yet. But I will try to create it today. I will let you
>>> know
>>>
>>> Cheers,
>>> Oleks
>>>
>>> On Apr 25, 2017 16:10, "francescoagati [via Smalltalk]" <[hidden email]
>>> > wrote:
>>>
 Hi Oleks,
 there is a mode for install neural network from metacello?

 2017-04-25 13:00 GMT+02:00 Alexandre Bergel <[hidden email]
 >:

> Continue to push that topic Oleks. You are on the right track!
>
> Alexandre
>
> > On Apr 24, 2017, at 1:43 AM, Oleks <[hidden email]
> > wrote:
> >
> > Hello,
> >
> > Thanks a lot for your advice! It was very helpful and educating (for
> > example, I thought that we store biases in the weight matrix and
> prepend 1
> > to input to make it faster, but now I see why it's actually slower
> that
> > way).
> >
> > I've implemented a multi-layer neural network as a linked list of
> layers
> > that propagate the input and error from one to another, similar to
> the Chain
> > of Responsibility pattern. Also, now I represent biases as separate
> vectors.
> > The LearningAlgorithm is a separate class with Backpropagation as its
> > subclass (though at this point the network can only learn through
> > backpropagation, but I'm planning to change that). I'm trying to
> figure out
> > how the activation and cost functions should be connected. For
> example,
> > cross-entropy works best with logistic sigmoid activation etc. I
> would like
> > to give the user a freedom to use whatever he wants (plug in
> whatever you
> > like and see what happens), but it can be very inefficient (because
> some
> > time-consuming parts of activation and cost derivatives cancel out
> each
> > other).
> >
> > Also, there is an interface for setting the learning rate for the
> whole
> > network, which can be used to choose the learning rate prior to
> learning, as
> > well as to change the learning rate after each iteration. I am
> planning to
> > implement some optimization algorithms that would automize the
> process of
> > choosing a learning rate (adagrad for example), but this would
> require a bit
> > different design (maybe I will implement the Optimizer, as you
> suggested).
> >
> > I'm attaching two images with UML diagrams, describing my current
> > implementation. Could you please tell me what you think about this
> design?
> > The first image is a class diagram that shows the whole
> architecture, and
> > the second one is a sequence diagram of backpropagation.
> >
> > mlnn.png 
> > backprop.png 
> >
> > Sincerely yours,
> > Oleksandr
> >
> >
> >
> > --
> > View this message in context: http://forum.world.st/Neural-N
> etworks-in-Pharo-tp4941271p4943698.html
> > Sent from the Pharo Smalltalk Users mailing list archive at
> Nabble.com.
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>


 --
 If you reply to this email, your message will be added to the
 discussion below:
 http://forum.world.st/Neural-Networks-in-Pharo-tp4941271p4944025.html
 To unsubscribe from Neural Networks in Pharo, click here.
 NAML
 

>>>
>>> --
>>> View this message in context: Re: Neural Networks in Pharo
>>> 

Re: [Pharo-users] Dark theme and white vs. green color

[Offray Vladimir Luna Cárdenas]

I think that green reads better. Something like solarized will be really 
nice [1]. But maybe that is a lot of work now.


[1] http://ethanschoonover.com/solarized

Cheers,

Offray

On 28/04/17 11:42, Juraj Kubelka wrote:

Hi,

While we were improving the DiffMorph for the dark theme, we conclude 
that it is much harder to read the text.


I personally also often miss a new debugger window on a big screen. 
Something I have not experienced before.


And this discussion reminds me the old computers where the background 
was black and text green. There are two screenshot to compare it:



A personally feel that it is much easier to read the green text.

What do you think?
Juraj

Re: [Pharo-users] MOOC offline download

[Ben Coman]

On Fri, Apr 28, 2017 at 5:11 PM, Stephane Ducasse 
wrote:

> Hi ben
>
> I do not really get the request?
> Because people can download the file and the portal.
>

I could not find a whole zip file of entire course, only the individual
files which would be a pain to download,
and did not know of the git repo.  Peter's suggestion should works fine.

Consider the case that someone is stocking up on reading material
before going on a trip with limited internet access.

cheers -ben



> I wanted to get a CD delivery services but I failed to find one (because I
> have all the files to be uploaded).
>
> Stef
>
> On Thu, Apr 27, 2017 at 5:50 PM, Ben Coman  wrote:
>
>> I was just chatting with someone with limited Internet who was looking to
>> odownload the mooc files [1] for use offline.  Does such exist?
>>
>> [1]  http://files.pharo.org/mooc
>>
>> cheers -ben
>>
>
>

[Pharo-users] Dark theme and white vs. green color

[Juraj Kubelka]

Hi, 

While we were improving the DiffMorph for the dark theme, we conclude that it 
is much harder to read the text. 

I personally also often miss a new debugger window on a big screen. Something I 
have not experienced before. 

And this discussion reminds me the old computers where the background was black 
and text green. There are two screenshot to compare it:

   

A personally feel that it is much easier to read the green text. 

What do you think?
Juraj

[Pharo-users] Voyage - collecting data from Mongo

[Mark Rizun]

Hi,

Is it possible to retrieve data from Mongo collection if it was not created
via Voyage?
Meaning that I do not have a class in Pharo that would correspond to said
collection (should I implement one?).

Cheers,
Mark



--
View this message in context: 
http://forum.world.st/Voyage-collecting-data-from-Mongo-tp4944784.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Basic controls does not change selection

[Denis Kudriashov]

2017-04-28 12:58 GMT+02:00 bachitoph :

> Is there any recommendation about the different morphs. What is the best
> button, droplist, input field .., because this is a great bulk of classes.
>

For input field look at Twisty
http://forum.world.st/ANN-Twisty-text-with-active-state-framework-td4863625.html

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

2017-04-28 12:59 GMT+02:00 Denis Kudriashov :

> 2017-04-28 12:26 GMT+02:00 Peter Uhnak :
>
>> > backend specific like createMorphicView: and we need hierarchy of
>> backends
>> > here which will choose appropriate message.
>>
>> Which is exactly what we do not want, to directly bind model to the view;
>> but I feel I am missing your point, can you rephrase it please?
>
>
> This is exactly what I mean. Now there is no cases where anybody defines
> special adapter for existing model. And you can't do it because then you
> will need modify global MorphicAdapterBindings to specify new morph class.
> And my sentence was: if we now live with that then we can simplify design
> a lot by directly asking model for a view. It will be still
> platform independent because concrete backend will use specific message
> like createMorphicView or createCocoaView.
>

And it is not too far from supporting multiple view.
Imaging that we have ItemSelectionModel. It can be shown as comboBox, radio
button group or list. In spec methods ( #defaultSpec) we can use logical
name for views: #comboBoxView, #radioGroupView, #listView. Then spec
interpreter will call this methods on current backend which will return
view instances. MorphicBackend will return concrete morph instances. Then
view will be passed to model for initialisation:

view := backend perform: spec viewName.

model showItemsOn: view.

view layoutWith: spec layout.


Example is of course simplistic but I hope it shows that we can model spec
without extra adapter component.

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

2017-04-28 12:26 GMT+02:00 Peter Uhnak :

> > In fact they are not adapters. They are factories which creates backend
> > views (morphs). And now there are completely no logic behind them: every
> > adapter just passes state received from model to view instance.
>
> This depends heavily on what the respective APIs provide.
>
> In TabAdapter I connect SpecTab and MorphicTab directly, so it no longer
> lives during runtime.
>
> In LabelAdapter the emphasis is being transcoded from symbol to random
> numbers (so this is not simple delegation)
> In MenuItemAdapter you can see much more behavior.


All they do is asking model about set of options. For example menu adapter
ask

 self model autoRefresh ifTrue: ifFalse:

And this logic can be moved to model itself and represented by different
model classes if necessary. (I talk about model as a presenter)

Re: [Pharo-users] Basic controls does not change selection

[bachitoph]

Hi Esteban,

>>why you say you cannot doit with Spec? 
As I understand Spec it depends on a SpecLayout which uses columns and rows
instead of rectangles. Is there any way to define in Spec a dialog with
explicite setting to any control view, something like aControlMorph bounds:
(50@50 extent: 100@30).

>>Using a FTTableMorph (or FTEasyListMorph), which are the ones I recommend
you to use, you would do something like this: 
I will give it a try.

Is there any recommendation about the different morphs. What is the best
button, droplist, input field .., because this is a great bulk of classes.

Thanks
cjb





--
View this message in context: 
http://forum.world.st/Basic-controls-Normal-List-does-not-change-selection-tp4944700p4944751.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

2017-04-28 12:26 GMT+02:00 Peter Uhnak :

> > backend specific like createMorphicView: and we need hierarchy of
> backends
> > here which will choose appropriate message.
>
> Which is exactly what we do not want, to directly bind model to the view;
> but I feel I am missing your point, can you rephrase it please?


This is exactly what I mean. Now there is no cases where anybody defines
special adapter for existing model. And you can't do it because then you
will need modify global MorphicAdapterBindings to specify new morph class.
And my sentence was: if we now live with that then we can simplify design a
lot by directly asking model for a view. It will be still
platform independent because concrete backend will use specific message
like createMorphicView or createCocoaView.

Re: [Pharo-users] improving audio/video quality of pharo days recordings

[Stephane Ducasse]

Ok we will have a mic now I do not know how to record it.


On Thu, Apr 27, 2017 at 5:18 AM, Sean P. DeNigris 
wrote:

> Peter Uhnak wrote
> > clip-on microphone
>
> Yes! Even a cheap lapel mic like the Sony ECM-CS3 would make a world of
> difference
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/
> improving-audio-video-quality-of-pharo-days-recordings-
> tp4944070p4944334.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Spec Adapter Advice

[Peter Uhnak]

On Fri, Apr 28, 2017 at 11:50:48AM +0200, Denis Kudriashov wrote:

> In fact they are not adapters. They are factories which creates backend
> views (morphs). And now there are completely no logic behind them: every
> adapter just passes state received from model to view instance.

This depends heavily on what the respective APIs provide.

In TabAdapter I connect SpecTab and MorphicTab directly, so it no longer lives 
during runtime.

In LabelAdapter the emphasis is being transcoded from symbol to random numbers 
(so this is not simple delegation)
In MenuItemAdapter you can see much more behavior.

So the naming is appropriate, but it is overall poorly connected.

> Now Spec allows very restricted relationship between model and view. We can
> only have single kind of view per model (MorphicAdapterBindings defines
> this relation). There is no way to use different kind of views for same
> model in single application.

As I've shown in my previous answer this is not the case. The connection is 
done via the class-side spec method where you can specify any class at all; 
MorphicAdapterBindings is just a convenience, you can put there whatever you 
want.

Likewise when you are composing widgets, you can specify what layout to use, 
something like (don't remember the precise naming out of my head)

^ SpecRowLayout composed add: #textModel withSpec: #cocoaSpec

> But it not works.

I've used it several times so it does work, if you had troubles then maybe it 
doesn't work with all models.

> Now you can imaging that if we always use same view class for same model
> class then we can directly ask model to instantiate view. Message can be
> backend specific like createMorphicView: and we need hierarchy of backends
> here which will choose appropriate message.

Which is exactly what we do not want, to directly bind model to the view; but I 
feel I am missing your point, can you rephrase it please?

> 
> P.S. Every time I read word model in Spec I feel something bad. It should
> be named to presenter. But it is quite difficult due to compatibility. And
> I am not sure that others agree with this.

When you go the the internals, then depending on the context spec can mean: 
spec layout, adapter, spec model; and in some parts all contexts overlap, so 
it's fun to read. :)


Now Pharo 7 will have new SpecInterpreter (it took me two weeks and I've 
created two extra tools to understand the old one and there are still some 
special exceptions), so then we can rethink the way it is done.

Peter

> 
> 2017-04-28 0:04 GMT+02:00 Peter Uhnak :
> 
> > Hi Rob,
> >
> > I guess the best resource at the moment is to just look at existing
> > adapters.
> >
> > But here are some thoughts to get you started:
> >
> > (Spec) ComposableModel has as its widget (Spec) Adapter
> > Adapter has as its widget the actual visual component, which currently
> > means Morphic.
> >
> >
> > The simplest example: LabelModel
> >
> > 1. model to adapter
> >
> > LabelModel is adapted by MorphicLabelAdapter:
> >
> > you can see on the class side in method `defaultSpec`.
> > There is only `LabelAdapter` there because there is some extra mapping for
> > some classes, but you can specify directly the class of the Adapter, so the
> > following would work just as well:
> >
> > LabelModel class>>defaultSpec
> > 
> >
> > ^ #(MorphicLabelAdapter
> > adapt: #(model))
> >
> >
> > LabelModel -> LabelAdapter direct event propagation (pushing changes)
> >
> > in Model world you can call changed:with: to execute code on the Adapter,
> > e.g.
> >
> > self changed: #emphasis: with: {emphasis}
> >
> > which in turn will call the #emphasis: method on the LabelAdapter.
> >
> > LabelModel -> LabelAdapter events (pulling changes)
> >
> > preferred alternative is to do the opposite; properties of models are
> > often held in ValueHolders, which can be observed on ValueChange, so the
> > Adapter can register to event change and react on itself;
> >
> > you can see this best in MorphicTabAdapter (but you will see that
> > TabAdapter looks a bit different from the rest, because I was experimenting
> > with cleaning up Adapters...)
> >
> > 2. adapter to morphic
> >
> > Every adapter implements #buildWidget method that returns a Morphic Object.
> > Typically the adapter registers itself as the model of the adapter (so
> > adapter's model is Spec, and Morphic's model is the adapter). This depends
> > a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> > there's no buildWidget, and it is in #buildWidgetWith:).
> >
> > It is all kinds of messy, but if you have other widgets then it will be a
> > good test how well Spec can handle it... or rather we'll see how it can be
> > improved...
> >
> > Peter
> >
> >
> >
> > On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > > Hello,
> > >
> > > I have recently been lucky enough to get the Cocoa portion of Mars
> > working
> > > on Pharo 5.0.  While there are some issues, it has 

Re: [Pharo-users] Spec Adapter Advice

[Peter Uhnak]

Hi Rob,

> I need to find a good starting point because you can't poke at the existing
> code too much since even the debugger is built with Spec!

I don't know what Pharo you are on, but this is not the case. Debugger itself 
is based on Glamour (there used to be SpecDebugger, but it is no longer used).

What is blowing up on you is the predebugger window, which is in Spec. You can 
disable this in your settings or by calling

GTGenericStackDebugger alwaysOpenFullDebugger: true

this will skip the debugger.

But keep in mind that other tools might be using spec too (like the Browser 
window that opens when you are listing senders/implementors.

overriding the #windowClass (or whatever the name was) is a good start.

(also FML because apparently I've deleted my image with my spec changes by 
accident -_-)

Peter

> 
> It's pretty exciting, though, because it feels like all the right pieces
> are there and a lot of this could mostly be "just work" once I get going.
> 
> Thanks again,
> 
> Rob
> 
> On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak  wrote:
> 
> > Hi Rob,
> >
> > I guess the best resource at the moment is to just look at existing
> > adapters.
> >
> > But here are some thoughts to get you started:
> >
> > (Spec) ComposableModel has as its widget (Spec) Adapter
> > Adapter has as its widget the actual visual component, which currently
> > means Morphic.
> >
> >
> > The simplest example: LabelModel
> >
> > 1. model to adapter
> >
> > LabelModel is adapted by MorphicLabelAdapter:
> >
> > you can see on the class side in method `defaultSpec`.
> > There is only `LabelAdapter` there because there is some extra mapping for
> > some classes, but you can specify directly the class of the Adapter, so the
> > following would work just as well:
> >
> > LabelModel class>>defaultSpec
> > 
> >
> > ^ #(MorphicLabelAdapter
> > adapt: #(model))
> >
> >
> > LabelModel -> LabelAdapter direct event propagation (pushing changes)
> >
> > in Model world you can call changed:with: to execute code on the Adapter,
> > e.g.
> >
> > self changed: #emphasis: with: {emphasis}
> >
> > which in turn will call the #emphasis: method on the LabelAdapter.
> >
> > LabelModel -> LabelAdapter events (pulling changes)
> >
> > preferred alternative is to do the opposite; properties of models are
> > often held in ValueHolders, which can be observed on ValueChange, so the
> > Adapter can register to event change and react on itself;
> >
> > you can see this best in MorphicTabAdapter (but you will see that
> > TabAdapter looks a bit different from the rest, because I was experimenting
> > with cleaning up Adapters...)
> >
> > 2. adapter to morphic
> >
> > Every adapter implements #buildWidget method that returns a Morphic Object.
> > Typically the adapter registers itself as the model of the adapter (so
> > adapter's model is Spec, and Morphic's model is the adapter). This depends
> > a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> > there's no buildWidget, and it is in #buildWidgetWith:).
> >
> > It is all kinds of messy, but if you have other widgets then it will be a
> > good test how well Spec can handle it... or rather we'll see how it can be
> > improved...
> >
> > Peter
> >
> >
> >
> > On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > > Hello,
> > >
> > > I have recently been lucky enough to get the Cocoa portion of Mars
> > working
> > > on Pharo 5.0.  While there are some issues, it has a wonderful set of
> > > examples that allowed me create new Cocoa classes and delegate methods
> > and
> > > see a straightforward path to learning how to use Coco widgets from
> > Pharo.
> > >
> > > I'd like to do that by creating appropriate Spec adapters, but
> > > unfortunately the new Spec booklet wasn't designed for that!
> > >
> > > Can anyone give me any insight into creating (and using) a new Spec
> > > adapter?  Maybe just some high level steps to help me orient my
> > > investigation into how Spec works?
> > >
> > > Thank you,
> > >
> > > Rob
> >
> >

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

>From design point of view I think we should remove adapters at all. They
bring parallel hierarchy which is always bad.
In fact they are not adapters. They are factories which creates backend
views (morphs). And now there are completely no logic behind them: every
adapter just passes state received from model to view instance.
I think full hierarchy of adapters can be easily substituted by single
backend factory class like MorphicViewFactory. Every model will ask it to
create concrete view instance. Actually I have another idea: we do not need
this factory at all.

Now Spec allows very restricted relationship between model and view. We can
only have single kind of view per model (MorphicAdapterBindings defines
this relation). There is no way to use different kind of views for same
model in single application.
Maybe current design tried to address this issue. But it not works. And
interesting that all Spec based tools do not require such kind of
flexibility which means that it is not really an issue.

Now you can imaging that if we always use same view class for same model
class then we can directly ask model to instantiate view. Message can be
backend specific like createMorphicView: and we need hierarchy of backends
here which will choose appropriate message.

P.S. Every time I read word model in Spec I feel something bad. It should
be named to presenter. But it is quite difficult due to compatibility. And
I am not sure that others agree with this.

2017-04-28 0:04 GMT+02:00 Peter Uhnak :

> Hi Rob,
>
> I guess the best resource at the moment is to just look at existing
> adapters.
>
> But here are some thoughts to get you started:
>
> (Spec) ComposableModel has as its widget (Spec) Adapter
> Adapter has as its widget the actual visual component, which currently
> means Morphic.
>
>
> The simplest example: LabelModel
>
> 1. model to adapter
>
> LabelModel is adapted by MorphicLabelAdapter:
>
> you can see on the class side in method `defaultSpec`.
> There is only `LabelAdapter` there because there is some extra mapping for
> some classes, but you can specify directly the class of the Adapter, so the
> following would work just as well:
>
> LabelModel class>>defaultSpec
> 
>
> ^ #(MorphicLabelAdapter
> adapt: #(model))
>
>
> LabelModel -> LabelAdapter direct event propagation (pushing changes)
>
> in Model world you can call changed:with: to execute code on the Adapter,
> e.g.
>
> self changed: #emphasis: with: {emphasis}
>
> which in turn will call the #emphasis: method on the LabelAdapter.
>
> LabelModel -> LabelAdapter events (pulling changes)
>
> preferred alternative is to do the opposite; properties of models are
> often held in ValueHolders, which can be observed on ValueChange, so the
> Adapter can register to event change and react on itself;
>
> you can see this best in MorphicTabAdapter (but you will see that
> TabAdapter looks a bit different from the rest, because I was experimenting
> with cleaning up Adapters...)
>
> 2. adapter to morphic
>
> Every adapter implements #buildWidget method that returns a Morphic Object.
> Typically the adapter registers itself as the model of the adapter (so
> adapter's model is Spec, and Morphic's model is the adapter). This depends
> a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> there's no buildWidget, and it is in #buildWidgetWith:).
>
> It is all kinds of messy, but if you have other widgets then it will be a
> good test how well Spec can handle it... or rather we'll see how it can be
> improved...
>
> Peter
>
>
>
> On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > Hello,
> >
> > I have recently been lucky enough to get the Cocoa portion of Mars
> working
> > on Pharo 5.0.  While there are some issues, it has a wonderful set of
> > examples that allowed me create new Cocoa classes and delegate methods
> and
> > see a straightforward path to learning how to use Coco widgets from
> Pharo.
> >
> > I'd like to do that by creating appropriate Spec adapters, but
> > unfortunately the new Spec booklet wasn't designed for that!
> >
> > Can anyone give me any insight into creating (and using) a new Spec
> > adapter?  Maybe just some high level steps to help me orient my
> > investigation into how Spec works?
> >
> > Thank you,
> >
> > Rob
>
>

Re: [Pharo-users] Basic controls does not change selection

[Esteban Lorenzano]

Hi, 

why you say you cannot doit with Spec?
If I understand correctly, what you want to do is to attach the windows you do 
to the Pharo world. For doing that with Spec you would do something like this: 

myMorph := mySpecModel buildWithSpec.
World addMorph: myMorph fullFrame: LayoutFrame identity. 
myMorph beSticky.
(also you have to change the layout of myMorph, etc.)

anyway… the other thing you ask is how to attach one list to another? Let’s say 
you have listA and listB, you want to change selection on listB when listA 
changes?
That you have to doit listening the change event. 
Using a FTTableMorph (or FTEasyListMorph), which are the ones I recommend you 
to use, you would do something like this: 

listB := FTEasyListMorph new
elements: myElementsForB;
display: [ :each | each asString ]; 
yourself.

listA := FTEasyListMorph new
elements: myElementsForA;
display: [ :each | each asString ]; 
onAnnouncement: FTSelectionChanged do: [ :ann | listB selection: 
newSelectionForB ];
yourself.

then you can add your list morph whenever you want. 

hope this helps :)
Esteban

> On 28 Apr 2017, at 10:57, bachitoph  wrote:
> 
> Hello,
> 
> porting my digitalk / dolphin application to pharo (www.trimfox.com) I have
> to port my dialog creation part. Unfortunately I can't use Spec because my
> dialog creation depends on boundingBox: (Pharo bounds:) by calculation
> position and extent in pixels. So I have to use Morphic. There is the nice
> class WidgetExamples which helped me very much. But the Normal List control
> does not change selection if there is a click on another item. You can see
> the behavior evaluating the code below, and click maybe on the  item. 
> Same behavior in my Dialog class. Any hint!
> 
> WidgetExamples exampleBasicControls
> 
> thanks
> cjb
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Basic-controls-Normal-List-does-not-change-selection-tp4944700.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Modal Menu in Pharo5

[bachitoph]

Peter

Thanks, that's it :)

cjb



--
View this message in context: 
http://forum.world.st/Re-Modal-Menu-in-Pharo5-tp4944703p4944716.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Modal Menu in Pharo5

[PBKResearch]

Christoph

It looks as though MenuMorph>>invokeModal should do what you want. The method 
comment has a useful code demo.

HTH

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Christoph J. Bachinger
Sent: 28 April 2017 09:25
To: pharo-users@lists.pharo.org.
Subject: [Pharo-users] Modal Menu in Pharo5

Hello,

I'm looking for a modal menu. It should stop method code execution until any 
left mouse klick. I tried MenuMorph with code like below, but this does not 
stop execution. Any hint?

thank you

cjb

ComposableModel subclass: #BachitophTestWindow
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 category: 'Trimfox'.

BachitophTestWindow compile: 'initializeWidgets'.

 |window menu choice|
 window := BachitophTestWindow new openWithSpecLayout: SpecLayout composed.
 menu := MenuMorph new
 defaultTarget: window;
 color: (window theme menuColorFor: window);
 addToggle: 'abcabcabcabc' target: window selector: 
#yourself"(labels at: 1)";
 addToggle: 'cdfgcdfgcdfg' target: window selector: #yourself;
 addLine;
 addToggle: 'hijkhijkhijk' target: window selector: #yourself;
 yourself.
 choice := menu popUpInWorld.
 choice selectedItem isNil
 ifTrue: [ choice := 'abc' ] ifFalse: [choice := choice selectedItem 
contents].
 self halt.

Re: [Pharo-users] MOOC offline download

[Stephane Ducasse]

Hi ben

I do not really get the request?
Because people can donwload the file and the portal.
I wanted to get a CD delivery services but I failed to find one (because I
have all the files to be uploaded).

Stef

On Thu, Apr 27, 2017 at 5:50 PM, Ben Coman  wrote:

> I was just chatting with someone with limited Internet who was looking to
> odownload the mooc files [1] for use offline.  Does such exist?
>
> [1]  http://files.pharo.org/mooc
>
> cheers -ben
>

[Pharo-users] Basic controls does not change selection

[bachitoph]

Hello,

porting my digitalk / dolphin application to pharo (www.trimfox.com) I have
to port my dialog creation part. Unfortunately I can't use Spec because my
dialog creation depends on boundingBox: (Pharo bounds:) by calculation
position and extent in pixels. So I have to use Morphic. There is the nice
class WidgetExamples which helped me very much. But the Normal List control
does not change selection if there is a click on another item. You can see
the behavior evaluating the code below, and click maybe on the  item. 
Same behavior in my Dialog class. Any hint!

WidgetExamples exampleBasicControls

thanks
cjb



--
View this message in context: 
http://forum.world.st/Basic-controls-Normal-List-does-not-change-selection-tp4944700.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

Hi Ben

2017-04-28 4:32 GMT+02:00 Ben Coman :

>
> Would your remote IDE [1] be suitable to help Rob to hack around Spec
> without blowing up his IDE?
>

Yes. But I think it is easy to just use Calypso tools to hack Spec. Calypso
not depends on Spec. And it would be not a problem to break Spec based
MessageBrowser.

To use remote tools generally refactorings should be fixed. Right now they
are not working from remote browser.


> But I think its only available on Pharo 6?
>

Yes.


>
> [1] http://forum.world.st/Ann-PharmIDE-Pharo-remote-IDE-to-
> develop-farm-of-Pharo-images-remotely-td4930602.html
>

[Pharo-users] Modal Menu in Pharo5

[Christoph J. Bachinger]

Hello,

I'm looking for a modal menu. It should stop method code execution until 
any left mouse klick. I tried MenuMorph with code like below, but this 
does not stop execution. Any hint?


thank you

cjb

ComposableModel subclass: #BachitophTestWindow
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Trimfox'.

BachitophTestWindow compile: 'initializeWidgets'.

|window menu choice|
window := BachitophTestWindow new openWithSpecLayout: SpecLayout 
composed.

menu := MenuMorph new
defaultTarget: window;
color: (window theme menuColorFor: window);
addToggle: 'abcabcabcabc' target: window selector: 
#yourself"(labels at: 1)";

addToggle: 'cdfgcdfgcdfg' target: window selector: #yourself;
addLine;
addToggle: 'hijkhijkhijk' target: window selector: #yourself;
yourself.
choice := menu popUpInWorld.
choice selectedItem isNil
ifTrue: [ choice := 'abc' ] ifFalse: [choice := choice 
selectedItem contents].

self halt.

Re: [Pharo-users] Spec Adapter Advice

[Stephane Ducasse]

This is a cool news.
We could have a new adapter for Mars.
I'm really interested in getting this working.

Stef

On Thu, Apr 27, 2017 at 11:10 PM, Rob Rothwell 
wrote:

> Hello,
>
> I have recently been lucky enough to get the Cocoa portion of Mars working
> on Pharo 5.0.  While there are some issues, it has a wonderful set of
> examples that allowed me create new Cocoa classes and delegate methods and
> see a straightforward path to learning how to use Coco widgets from Pharo.
>
> I'd like to do that by creating appropriate Spec adapters, but
> unfortunately the new Spec booklet wasn't designed for that!
>
> Can anyone give me any insight into creating (and using) a new Spec
> adapter?  Maybe just some high level steps to help me orient my
> investigation into how Spec works?
>
> Thank you,
>
> Rob
>
>
>

[Pharo-users] Smalltalk job offer in Germany [ collphir-bewerb...@collogia.de ]

[Stephane Ducasse]

Dear Pharoers


For our business unit Pension Management we are currently looking for a
*Software-Developer (m/w) **About us*
Collogia Unternehmensberatung AG is based in Cologne (Germany) and focused
on IT-Consulting and software development. Since 1979 we successfully carry
out projects and maintain IT-systems for the banking and insurance branch,
public organisations or companies in all industries. Our competence centers
are SAP-Consulting, Project management, IT-Services und Pension-Management.
The business unit „Pension Management“ is specialised on pension
administration and actuarial services. CollPhir® (*www.collphir.de
) *is an in-house development. CollPhir® is an
administration system for pension funds and other company pension solutions.
*Your Pro le*
*• *Successfully completed study of computer
science, mathematics oder a comparable quali cation
*• *Profound knowledge in object-oriented soft- ware development, software
engineering, e.g. methods, technologies, process design, data modeling,
OOA/OOD, UML
*• *Experience with project management
*• *Team-oriented and *w*orking in a structured,
systematic and deadline-focused way
*• *Good knowledge with MS-Of ce
*• *Working language is German, therefore a very good knowledge of the
German language (written/spoken) is needed
*Your Tasks*
• Development of high quality Client-/ Server-Software based on Visual
Works Smalltalk
• Technological evolution of our in- house development CollPhir® (
www.CollPhir.de)
• Development of functional and technical speci cations based on the
analysis and requirements of our clients
• Consulting of our clients in requests regarding information technology
• Technical support CollPhir®
*Your Bene ts*
• Inviting projects
• Attrractive workplace
• Mentoring
• Targeted training
• Fexible working hours model • Attractive salary model

Contact *Dr. Michael Höhnerbach*
CEO Pension Management E-Mail: collphir-bewerb...@collogia.de
Ubierring 11 • 50678 Köln Web: collogia.de | collphir.de