- Pharo-users - lists.pharo.org

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

by Holger Freyther

> On 30. Apr 2017, at 11:18, Mark Rizun <mrizun(a)gmail.com> wrote: > > > > Sorry, I wasn't very accurate in previous email. > Actually, my friend is using MongoTalk/Voyage, and she encountered a problem that it is not possible to work with databases created in 3.0+ versions of MongoDB. > Probably this issue is related to new storage types (connection part is fine). I am running a Pharo3.0 image (with an older Voyage) against MongoDB 3.2. I think I am already using "WiredTiger" as database. If you can reproduce it, we can have a look. The only issue I have seen is Sabines authentication failure with more "modern" schemes. holger

April 30, 2017

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

by Mark Rizun

oh? Is that written somewhere in the Voyage documentation? Sorry, I wasn't very accurate in previous email. Actually, my friend is using MongoTalk/Voyage, and she encountered a problem that it is not possible to work with databases created in 3.0+ versions of MongoDB. Probably this issue is related to new storage types (connection part is fine). MongoDB wire protocol is upwards compatible, so while one might not use the new features yet, your application will work. OK

April 30, 2017

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

by Holger Freyther

> On 30. Apr 2017, at 10:47, Mark Rizun <mrizun(a)gmail.com> wrote: > > Hi, Hi! > Holger, thank you, I will try your suggestion. > However, I use MongoDB 3.4, and I think that Voyage has support for only versions under 3.0. Am I right? oh? Is that written somewhere in the Voyage documentation? The MongoDB wire protocol is upwards compatible, so while one might not use the new features yet, your application will work. holger

April 30, 2017

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

by Mark Rizun

Hi, Holger, thank you, I will try your suggestion. However, I use MongoDB 3.4, and I think that Voyage has support for only versions under 3.0. Am I right? Stef, collection in mongo is a container for documents. For example, here three documents are inserted in collection "inventory": db.inventory.insertMany([ { item: "journal", qty: 25, tags: ["blank", "red"], size: { h: 14, w: 21, uom: "cm" } }, { item: "mat", qty: 85, tags: ["gray"], size: { h: 27.9, w: 35.5, uom: "cm" } }, { item: "mousepad", qty: 25, tags: ["gel", "blue"], size: { h: 19, w: 22.85, uom: "cm" } } ]) https://docs.mongodb.com/manual/tutorial/insert-documents/ Mark 2017-04-30 10:37 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > mark > > what is such collection? > > Stef > > On Fri, Apr 28, 2017 at 11:04 PM, Holger Freyther <holger(a)freyther.de> > wrote: > >> >> > On 28. Apr 2017, at 14:27, Mark Rizun <mrizun(a)gmail.com> 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 >> <mongoContainer> >> ^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 >> > >

April 30, 2017

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

by Stephane Ducasse

mark what is such collection? Stef On Fri, Apr 28, 2017 at 11:04 PM, Holger Freyther <holger(a)freyther.de> wrote: > > > On 28. Apr 2017, at 14:27, Mark Rizun <mrizun(a)gmail.com> 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 > <mongoContainer> > ^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 >

April 30, 2017

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

by volkert

of course :-) yes, i am trying to load the package GADM in Pharo 5, but it failed ... :-( Volkert Am 30.04.2017 um 09:57 schrieb Stephane Ducasse: > volkert > > Then what would be good is to code it as open-source so that people > can join effort. > Did you check the packages of geolocalisation developed by Hernan Morales? > Stef > > On Sat, Apr 29, 2017 at 4:18 PM, volkert <volkert(a)nivoba.de > <mailto:volkert@nivoba.de>> wrote: > > 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 <volkert(a)nivoba.de > <mailto:volkert@nivoba.de>> 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 > <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 > <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 > > > > >

April 30, 2017

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

by Stephane Ducasse

volkert Then what would be good is to code it as open-source so that people can join effort. Did you check the packages of geolocalisation developed by Hernan Morales? Stef On Sat, Apr 29, 2017 at 4:18 PM, volkert <volkert(a)nivoba.de> wrote: > 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 <volkert(a)nivoba.de> 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 >> >> >> > >

April 30, 2017

Re: [Pharo-users] Spec Adapter Advice

by 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 <i.uhnak(a)gmail.com>: > > > > > > > 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

April 29, 2017

Re: [Pharo-users] Spec Adapter Advice

by 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 <i.uhnak(a)gmail.com>: > > > 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

April 29, 2017

Re: [Pharo-users] Spec Adapter Advice

by Denis Kudriashov

2017-04-29 20:36 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > > 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?

April 29, 2017