Re: [Pharo-users] Spec Adapter Advice

[Peter Uhnak]

On Sat, Apr 29, 2017 at 09:24:28PM +0200, Denis Kudriashov wrote:
> 2017-04-29 20:36 GMT+02:00 Peter Uhnak :
> 
> > >
> > > 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.
> >
> > #openWithSpecLayout:
> > #buildWithSpecLayout:
> > and in layout #add:withSpec:
> 
> 
> How it will allow open MessageBrowser (based on Spec) on cocoa backend?

You would need to add cocoa-based layout for every model in the chain and then 
cross-reference them via #add:withSpec:, annoying, but should be possible.

Peter

Re: [Pharo-users] Spec Adapter Advice

[Peter Uhnak]

On Sat, Apr 29, 2017 at 09:22:46PM +0200, Denis Kudriashov wrote:
> Hi
> 
> 2017-04-29 20:36 GMT+02:00 Peter Uhnak :
> 
> > No, it is not. It has hard wired bindings from certain names to morphic
> > adapters, but only if you don't actually specify the target calss.
> > In other words, if in your #specLayout you specify a name that has a
> > binding, then the binding will be used; if there is no such binding, then
> > the class will be instantiated directly.
> >
> > So for example if you specify:
> > * LabelAdapter -> there is binding from LabelAdapter to
> > MorphicLabelAdapter, so MorphicLabelAdapter will be instantiated
> > * MorphicLabelAdapter -> there are no bindings for this name, so it will
> > be instantiated directly
> > * CocoaLabelAdapter -> there are no bindings for this name, so it will be
> > instantiated directly
> >
> 
> But we should not reference directly platform specific widgets when we
> define spec layout. Otherwise we will be forced to copy every layout method
> (like #defaultSpec) for each platform.
> And it breaks goal of Spec to be able open application with different
> backends without code modification.
> 
> I am sure you know what I wrote. So probably I not understand what you mean.

I was describing how it is possible to do it _now_, not how it ideally should 
be done (because there's no other way right now)... we will change this, 
because we will also need a better way for Bloc.

So Pharo7 again :)

Peter

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

2017-04-29 20:36 GMT+02:00 Peter Uhnak :

> >
> > 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.
>
> #openWithSpecLayout:
> #buildWithSpecLayout:
> and in layout #add:withSpec:


How it will allow open MessageBrowser (based on Spec) on cocoa backend?

Re: [Pharo-users] Spec Adapter Advice

[Denis Kudriashov]

Hi

2017-04-29 20:36 GMT+02:00 Peter Uhnak :

> No, it is not. It has hard wired bindings from certain names to morphic
> adapters, but only if you don't actually specify the target calss.
> In other words, if in your #specLayout you specify a name that has a
> binding, then the binding will be used; if there is no such binding, then
> the class will be instantiated directly.
>
> So for example if you specify:
> * LabelAdapter -> there is binding from LabelAdapter to
> MorphicLabelAdapter, so MorphicLabelAdapter will be instantiated
> * MorphicLabelAdapter -> there are no bindings for this name, so it will
> be instantiated directly
> * CocoaLabelAdapter -> there are no bindings for this name, so it will be
> instantiated directly
>

But we should not reference directly platform specific widgets when we
define spec layout. Otherwise we will be forced to copy every layout method
(like #defaultSpec) for each platform.
And it breaks goal of Spec to be able open application with different
backends without code modification.

I am sure you know what I wrote. So probably I not understand what you mean.

Re: [Pharo-users] Spec Adapter Advice

[Peter Uhnak]

On Fri, Apr 28, 2017 at 04:20:57PM -0400, Rob Rothwell wrote:
> Hi Peter,
> 
> However, I have discovered by creating new ComposableModel, WindowModel,
> and MorphicWindowAdapter classes that even the SpecInterpreter itself is
> hard-wired to use Morphic.

No, it is not. It has hard wired bindings from certain names to morphic 
adapters, but only if you don't actually specify the target calss.
In other words, if in your #specLayout you specify a name that has a binding, 
then the binding will be used; if there is no such binding, then the class will 
be instantiated directly.

So for example if you specify:
* LabelAdapter -> there is binding from LabelAdapter to MorphicLabelAdapter, so 
MorphicLabelAdapter will be instantiated
* MorphicLabelAdapter -> there are no bindings for this name, so it will be 
instantiated directly
* CocoaLabelAdapter -> there are no bindings for this name, so it will be 
instantiated directly

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

This comment just adds more confusion to people that don't understand what is 
going on. From Spec perspective widget is the same as adapter (so the name is 
just fine), and during SpecInterpreter execution both adapter and the final 
widgets are created. The naming is not wrong, but the same word (widget) means 
different things in different contexts, so it is confusing.

> 
> 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 should go re-read my original answer where I explained how you can do 
exactly that...

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

#openWithSpecLayout:
#buildWithSpecLayout:
and in layout #add:withSpec:

See the spec booklet section 4.3. where you can see how #add:withSpec: can be 
used (I've also mentioned this in one of the previous comments)

Peter

Re: [Pharo-users] Geocoder Services in Pharo?

[volkert]

Hi Sven,

thanks for your fast response and the snippets. I scanned the different 
geocoder classes from "geopy" and also the OSM Nominatim docs. Indeed, 
it is not hard, . but if there is already a package, why not using 
it :-)


maybe i start to write such a lib.

Thanks,
Volkert

Am 29.04.2017 um 15:54 schrieb Sven Van Caekenberghe:

Hi Volkert,


On 29 Apr 2017, at 15:01, volkert  wrote:

Dear all,

do we have a package to access the a geocoder service? Something similar to 
"geopy".

Volkert

As far as I know there is no such library.

We have it internally, but that part is not open source. But it is not so hard 
to do yourself.

Here is an example for forward geocoding (address -> coordinates):

ZnClient new
url: 'http://nominatim.openstreetmap.org/search';
queryAt: #format put: 'json';
queryAt: #addressdetails put: '1';
queryAt: #q put: 'Villerspark 5, 3500 Hasselt';
queryAt: #countrycodes put: 'be';
accept: ZnMimeType applicationJson;
contentReader: [ :entity | STONJSON fromString: entity contents ];
get.

Here is an example for reverse geocoding (coordinates -> address):

ZnClient new
url: 'http://nominatim.openstreetmap.org/reverse';
queryAt: #format put: 'json';
queryAt: #lon put: 5.33732 asString;
queryAt: #lat put: 50.926 asString;
accept: ZnMimeType applicationJson;
contentReader: [ :entity | STONJSON fromString: entity contents ];
get.

These are against the OpenStreetMap Nomatim service, others are similar.

HTH,

Sven

Re: [Pharo-users] Geocoder Services in Pharo?

[Sven Van Caekenberghe]

Hi Volkert,

> On 29 Apr 2017, at 15:01, volkert  wrote:
> 
> Dear all,
> 
> do we have a package to access the a geocoder service? Something similar to 
> "geopy".
> 
> Volkert

As far as I know there is no such library. 

We have it internally, but that part is not open source. But it is not so hard 
to do yourself.

Here is an example for forward geocoding (address -> coordinates):

ZnClient new
url: 'http://nominatim.openstreetmap.org/search';
queryAt: #format put: 'json';
queryAt: #addressdetails put: '1';
queryAt: #q put: 'Villerspark 5, 3500 Hasselt';
queryAt: #countrycodes put: 'be';
accept: ZnMimeType applicationJson;
contentReader: [ :entity | STONJSON fromString: entity contents ];
get.

Here is an example for reverse geocoding (coordinates -> address):

ZnClient new
url: 'http://nominatim.openstreetmap.org/reverse';
queryAt: #format put: 'json';
queryAt: #lon put: 5.33732 asString;
queryAt: #lat put: 50.926 asString;
accept: ZnMimeType applicationJson;
contentReader: [ :entity | STONJSON fromString: entity contents ];
get.

These are against the OpenStreetMap Nomatim service, others are similar.

HTH,

Sven

[Pharo-users] Geocoder Services in Pharo?

[volkert]

Dear all,

do we have a package to access the a geocoder service? Something similar 
to "geopy".


Volkert

Re: [Pharo-users] Neural Networks in Pharo

[Oleks]

And I have added a PolyMath dependency to the configuration file, so now
the Metacello script should update you to the latest stable versions of
everything automatically.
Thanks for pointing it out.

On Fri, Apr 28, 2017 at 11:05 PM, francescoagati [via Smalltalk] <
ml+s1294792n4944863...@n4.nabble.com> wrote:

> now work all good with last version of polymath
> thanks :-)
>
> 2017-04-27 17:29 GMT+02:00 Oleks <[hidden email]
> >:
>
>> 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 Neu