December 2015 - Pharo-users

Re: [Pharo-users] Mongo configuration for Pharo40

by Esteban Lorenzano

> On 04 Dec 2015, at 17:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > According to http://bsonspec.org/spec.html there are indeed 2 different types > > "\x09" e_name int64 UTC datetime > > "\x11" e_name int64 Timestamp > > I would guess that you need 2 different (sub)classes in Pharo if you want to honour this spec. It has little to do with the almost empty TimeStamp subclass of DateAndTime having been removed. This is an API design issue (decide on the Pharo to BSON type mapping). yes, often in databases datetime and timestamps are different beasts. Thatâs why I was thinking on importing a real timestamp, to honor mongo designâ¦ but I need to review what mongo (and others) consider actually as a timestamp :) Esteban > >> On 04 Dec 2015, at 16:40, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> >>> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> Yes I thinkâ¦ I still do not update voyage to Pharo5 (there are not TimeStamps anymore). >>> >>> Esteban >>> >>>> On 04 Dec 2015, at 15:43, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Does it make sense to have >>>> >>>> Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 >>>> Author: EstebanLorenzano >>>> Time: 9 May 2015, 8:40:27.23963 am >>>> UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 >>>> Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 >>>> >>>> fixed a problem with the versionner tool >>>> >>>> in the Catalog for Pharo 40? >>>> >>>> Stef >>>> >>> >>> >> >> I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... >> If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/ >> >> Cheers, >> Henry > >

Dec. 4, 2015

Re: [Pharo-users] Mongo configuration for Pharo40

by Norbert Hartl

> Am 04.12.2015 um 16:40 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > >> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Yes I thinkâ¦ I still do not update voyage to Pharo5 (there are not TimeStamps anymore). >> >> Esteban >> >>> On 04 Dec 2015, at 15:43, stepharo <stepharo(a)free.fr> wrote: >>> >>> Does it make sense to have >>> >>> Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 >>> Author: EstebanLorenzano >>> Time: 9 May 2015, 8:40:27.23963 am >>> UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 >>> Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 >>> >>> fixed a problem with the versionner tool >>> >>> in the Catalog for Pharo 40? >>> >>> Stef >>> >> >> > > I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... > If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/ > Wouldn't it then be possible to include a timestamp class in Mongo? Norbert

Dec. 4, 2015

Re: [Pharo-users] How can we verify that a daemon is listening on a TCP socket

by Norbert Hartl

> Am 04.12.2015 um 16:07 schrieb stepharo <stepharo(a)free.fr>: > > Hi guys > > I would like to know if a daemon (mongo) is listening on a given TCP socket? Of course it is :) Default port is 27017 Norbert

Dec. 4, 2015

Re: [Pharo-users] Mongo configuration for Pharo40

by Sven Van Caekenberghe

According to http://bsonspec.org/spec.html there are indeed 2 different types "\x09" e_name int64 UTC datetime "\x11" e_name int64 Timestamp I would guess that you need 2 different (sub)classes in Pharo if you want to honour this spec. It has little to do with the almost empty TimeStamp subclass of DateAndTime having been removed. This is an API design issue (decide on the Pharo to BSON type mapping). > On 04 Dec 2015, at 16:40, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Yes I thinkâ¦ I still do not update voyage to Pharo5 (there are not TimeStamps anymore). >> >> Esteban >> >>> On 04 Dec 2015, at 15:43, stepharo <stepharo(a)free.fr> wrote: >>> >>> Does it make sense to have >>> >>> Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 >>> Author: EstebanLorenzano >>> Time: 9 May 2015, 8:40:27.23963 am >>> UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 >>> Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 >>> >>> fixed a problem with the versionner tool >>> >>> in the Catalog for Pharo 40? >>> >>> Stef >>> >> >> > > I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... > If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/ > > Cheers, > Henry

Dec. 4, 2015

Re: [Pharo-users] Mongo configuration for Pharo40

by Esteban Lorenzano

I was thinking what to doâ¦ maybe couple voyage with ZTimestamp could be a good idea? > On 04 Dec 2015, at 16:40, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Yes I thinkâ¦ I still do not update voyage to Pharo5 (there are not TimeStamps anymore). >> >> Esteban >> >>> On 04 Dec 2015, at 15:43, stepharo <stepharo(a)free.fr> wrote: >>> >>> Does it make sense to have >>> >>> Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 >>> Author: EstebanLorenzano >>> Time: 9 May 2015, 8:40:27.23963 am >>> UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 >>> Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 >>> >>> fixed a problem with the versionner tool >>> >>> in the Catalog for Pharo 40? >>> >>> Stef >>> >> >> > > I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... > If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/ > > Cheers, > Henry

Dec. 4, 2015

Re: [Pharo-users] evolutions of squeakelib & crypto (Reed Solomon)

by Robert Withers

Now I think you are right on with your observation. Additionally, the number of dialects could increase further with Fuel serialization, just port SecureSession and bits. Alright, I came up with a name and it may border on the egregious ... presenting ... "Maelstrom" A new distributed metric will be established in Maelstrom to measure intra- & inter-vat activity: "Sanguinity". Robert PS. thanks for pointing out Fuel support for older squeaks. On 12/04/2015 10:25 AM, Sven Van Caekenberghe wrote: > Another suggestion: if you intend to make something cross dialect and hope to get traction, I would not use a project name which contains one dialect, but something more general like Cryptography, or some cool project name, like Seaside, Fuel, ... > >> On 04 Dec 2015, at 15:43, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I use squeak 5.0 and would want the Fuel support to customize for wire serializations and substitutions, such that Squeak and Pharo could talk to each other, and all other Fuel environments. The Fuel changes I made are in the Pharo port of SqueakElib in the SqueakElib-CapTP-Serialization category and consist of a Decoder, Materializer and a Materialization. >> >> Robert >> >> On 12/04/2015 09:35 AM, Esteban Lorenzano wrote: >>> which squeak version? >>> of what? >>> >>>> On 04 Dec 2015, at 12:15, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>>> >>>> I just realized that the squeak version uses ReferenceStream while the Pharo version uses Fuel, so the binary serializations are different and they won't speak to each other. Any chance that Fuel is ported to Squeak? >>>> >>>> Regards, >>>> Robert >>>> >>>> On 12/04/2015 06:11 AM, Robert Withers wrote: >>>>> I am unable to import these files into SqueakSource, so it may be best done from inside Pharo with Monticello. Here are working Crypto and SqueakElib in Pharo, prior to SecureSession refactoring and Reed Solomon. I include the correct version of LayeredProtocol. >>>>> >>>>> Regards, >>>>> Robert >>>>> >>>>> >>>>> On 12/04/2015 05:47 AM, Robert Withers wrote: >>>>>> Best Regards >>>>>> >>>>>> http://www.squeaksource.com/Cryptography.html >>>>>> http://www.squeaksource.com/squeakelib.html >>>>>> >>>>>> >>>>>> On 12/04/2015 05:44 AM, Robert Withers wrote: >>>>>>> After my password reset on squeaksource, I committed to both Cryptography and SqueakElib, project links below. >>>>>>> >>>>>>> In the case of Cryptography, I had a version ported to Pharo ... I will organize Pharo ports of both after Reed Solomon is stable, and announce them to the Pharo list. This way both environments can be supported through this one repository. >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> On 12/04/2015 04:35 AM, Stephan Eggermont wrote: >>>>>>>> On 03-12-15 23:06, Robert Withers wrote: >>>>>>>>> Are any of these used by both squeak and Pharo? That would be the right >>>>>>>>> move I think. I will ask about getting my password reset for >>>>>>>>> squeaksource, since that is where the old code resides. >>>>>>>> All of them. Mostly timing of project start/high activity and who are >>>>>>>> maintaining it decided on platforms. There was a time when squeaksource was not so stable and then many projects migrated, and I currently hear least about stability issues from ss3, but the load on smalltalkhub is much higher, I assume, as that is used for the pharo ci. >>>>>>>> >>>>>>>> In the not so far future Pharo is likely to move to a git based infrastructure, using libgit2. Early adopters are already using it. >>>>>>>> I haven't heard the squeak ideas about that. >>>>>>>> >>>>>>>> Stephan >>>>>>>> >>>>>>>> >>>>>>>> >

Dec. 4, 2015

Re: [Pharo-users] How can we verify that a daemon is listening on a TCP socket

by Robert Withers

> netstat -a | grep LISTEN | grep <port> that should get you there. Robert On 12/04/2015 10:07 AM, stepharo wrote: > Hi guys > > I would like to know if a daemon (mongo) is listening on a given TCP > socket? > > Stef >

Dec. 4, 2015

Re: [Pharo-users] Mongo configuration for Pharo40

by Henrik Johansen

> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Yes I thinkâ¦ I still do not update voyage to Pharo5 (there are not TimeStamps anymore). > > Esteban > >> On 04 Dec 2015, at 15:43, stepharo <stepharo(a)free.fr> wrote: >> >> Does it make sense to have >> >> Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 >> Author: EstebanLorenzano >> Time: 9 May 2015, 8:40:27.23963 am >> UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 >> Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 >> >> fixed a problem with the versionner tool >> >> in the Catalog for Pharo 40? >> >> Stef >> > > I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/ Cheers, Henry

Dec. 4, 2015

Re: [Pharo-users] Mongo configuration for Pharo40

by stepharo

so can you push it? Le 4/12/15 15:49, Esteban Lorenzano a Ã©crit : > Yes I thinkâ¦ I still do not update voyage to Pharo5 (there are not TimeStamps anymore). > > Esteban > >> On 04 Dec 2015, at 15:43, stepharo <stepharo(a)free.fr> wrote: >> >> Does it make sense to have >> >> Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 >> Author: EstebanLorenzano >> Time: 9 May 2015, 8:40:27.23963 am >> UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 >> Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 >> >> fixed a problem with the versionner tool >> >> in the Catalog for Pharo 40? >> >> Stef >> > >

Dec. 4, 2015

Re: [Pharo-users] How can we verify that a daemon is listening on a TCP socket

by Sven Van Caekenberghe

Depending on the protocol you just connect to it and see if that works ;-) With a short timeout, of course. I would just use the matching client in Pharo. > On 04 Dec 2015, at 16:07, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > I would like to know if a daemon (mongo) is listening on a given TCP socket? > > Stef

Dec. 4, 2015