- Pharo-users - lists.pharo.org

Re: [Pharo-users] Athens error

by Pavel Krivanek

2017-12-26 14:32 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Running your drgeo.image on a recent linux pharo 64 bit vm gives this > error message first: > > /home/nicolai/devel/pharo/Pharo7.0-32bit-52a28a8.sources. > > With pharo 7, every (bootstrapped)image needs its own sources file? > Every Pharo 7 build creates own sources file but this sources file can be shared between several images based on this build. So for final Pharo 7 we may release one sources file but I doubt that we will do it. During bootstrap all code is loaded into the image as new code so at the end you have empty sources file and huge changes file. We condense such changes file and transform it into sources file so you have empty changes. But we would like have sources directly in the image in compressed form. -- Pavel > > > 2017-12-26 11:59 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > >> Just make a drgeo build with latest image as of today, the problem is the >> same with latest image, as long as the source file is not present. Here is >> the newest built[1] >> >> Hilaire >> >> >> [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 >> >> Le 26/12/2017 Ã 11:15, Pavel Krivanek a Ã©crit : >> >>> Hi Hilaire >>> >>> your P7 image is older and has problems with FreeType fonts >>> initialization that should be fixed in the newest builds. Maybe that is >>> cause of the Athens issues you are facing. Please upgrade. >>> >>> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >> >

Dec. 26, 2017

Iceberg regex

by Ian Ian

Yes. That is how it is on github but there are private hit serveers. My own, for example. I found it usable after I changed the regex in both classes where it exists. On Dec 26, 2017 4:14 AM, <pharo-users-request(a)lists.pharo.org> wrote: > Send Pharo-users mailing list submissions to > pharo-users(a)lists.pharo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-users_ > lists.pharo.org > or, via email, send a message with subject or body 'help' to > pharo-users-request(a)lists.pharo.org > > You can reach the person managing the list at > pharo-users-owner(a)lists.pharo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-users digest..." > > Today's Topics: > > 1. Re: Strange 'Connection closed while waiting for data.' Zinc > error (Yuriy Tymchuk) > 2. Re: Iceberg URL regex not matching how I would expect it to? > (Juli?n Maestri) > 3. Re: Strange 'Connection closed while waiting for data.' Zinc > error (Sven Van Caekenberghe) > 4. Breakpoints in Pharo (Andrei Stebakov) > 5. Re: Strange 'Connection closed while waiting for data.' Zinc > error (Yuriy Tymchuk) > 6. Re: Strange 'Connection closed while waiting for data.' Zinc > error (Sven Van Caekenberghe) > > > ---------- Forwarded message ---------- > From: Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 25 Dec 2017 18:03:11 +0100 > Subject: Re: [Pharo-users] Strange 'Connection closed while waiting for > data.' Zinc error > Hi, > > setting the reuse timeout to 0 or making a one shot client does not help. > But while googling I found the exact issue described on the Pharo issue > tracker: https://pharo.fogbugz.com/f/cases/18588/ > > The proposed workaround also worked for me: > ZnNetworkingUtils default socketStreamClass: SocketStream. > > Cheers, > Uko > > > On 25 Dec 2017, at 05:42, Andrew Glynn <aglynn42(a)gmail.com> wrote: > > > > The only time I've seen that behaviour is with the combination of a slow > server and a proxy such as CloudFlare where the sysadmin has set tcp_wait > to some ridiculously small number. Have you tried setting the connection > reuse timeout to 0, or setting 'beOneShot'? > > > > Zinc doesn't support the additions in HTTP/2, but I can't offhand think > of any reason that should cause that specific behaviour. I've had > sufficient problems with HTTP/2 over slow connections (I live where there > are no land lines of any kind) that I replaced the HTTP/2 code in Nginx > with code from pureftpd in order to access my server at home when I'm out. > > > > Andrew > > > > ï»¿On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" < > pharo-users-bounces(a)lists.pharo.org on behalf of yuriy.tymchuk(a)me.com> > wrote: > > > > Hi, > > > > Iâm trying to hack something with Pharo 6.1 and Phillips Hue[1] (they > have a simple REST API). When I try to do a GET request with Zinc like this: > > > > ZnClient new > > url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > > get > > > > I get a âConnectionClosed: Connection closed while waiting for dataâ > exception. The service provides a JSON response that I can get without a > problem by using a web browser or curl. Also if I try to access fewer data > (e.g. adding /1 to the url, so it gets only one resource) I donât get the > exception. > > > > What is even more strange, when I resume the exception I get the > desired response i.e. this works: > > > > [ ZnClient new > > url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > > get ] > > > > on: ConnectionClosed > > do: [ :ex | > > ex resumeUnchecked: ex defaultResumeValue ] > > > > Of course I cannot share the server that is on my local network for > resting, but maybe anyone knows it there are any known issues with Zinc, or > if there are ways for me to debug the issue further. > > > > Cheers. > > Uko > > > > [1]: https://www.developers.meethue.com > > > > > > > > > > > > > > ---------- Forwarded message ---------- > From: "JuliÃ¡n Maestri" <serpi90(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 25 Dec 2017 15:16:57 -0300 > Subject: Re: [Pharo-users] Iceberg URL regex not matching how I would > expect it to? > user@server.com:/proj/proj.git > > Isn't it: git@server.com:user/project.git ? > > On Dec 24, 2017 15:36, "Ian Ian" <icjohnsoia(a)gmail.com> wrote: > >> Hi All, >> >> I am having trouble setting up iceberg to access my repository via ssh. >> >> On the command line I assess it via: git clone user@server.com:/proj/proj.git >> and all works as expected. >> >> When adding trying to add the same repository to iceberg I get a parseUrl >> error thrown from class IceScpRemote. While debugging I see the following >> regex: >> >> matcher := '(ssh\://)?([\w\-]+@)?([\w\-.]+)(\:[\d]+)?(\:|/)/?([\w\-]+)/([\w\-]+)(\.git)?' >> asRegex. >> >> which parses username@server.com:/directory/proj.git. >> >> However fails to parse: username@server.com:/dir1/dir2/proj.git >> >> The corrected version is as follows: >> >> matcher := '(ssh\://)?([\w\-]+@)?([\w\-.]+)(\:[\d]+)?(\:|/)/?(([\w\-]+) >> /)+([\w\-]+)(\.git)?' asRegex. >> >> Questions: >> >> Is this by design? >> of the top of your head: If I use the corrected version am I going to >> run into other issues? >> >> >> NB: I am using 64 bit Pharo 6.0 Update: #60520 >> >> Thanks in advance, >> >> >> > > ---------- Forwarded message ---------- > From: Sven Van Caekenberghe <sven(a)stfx.eu> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 25 Dec 2017 20:03:27 +0100 > Subject: Re: [Pharo-users] Strange 'Connection closed while waiting for > data.' Zinc error > > > > On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Hi, > > > > setting the reuse timeout to 0 or making a one shot client does not > help. But while googling I found the exact issue described on the Pharo > issue tracker: https://pharo.fogbugz.com/f/cases/18588/ > > > > The proposed workaround also worked for me: > > ZnNetworkingUtils default socketStreamClass: SocketStream. > > You are on Windows I guess ? > > > Cheers, > > Uko > > > >> On 25 Dec 2017, at 05:42, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >> > >> The only time I've seen that behaviour is with the combination of a > slow server and a proxy such as CloudFlare where the sysadmin has set > tcp_wait to some ridiculously small number. Have you tried setting the > connection reuse timeout to 0, or setting 'beOneShot'? > >> > >> Zinc doesn't support the additions in HTTP/2, but I can't offhand think > of any reason that should cause that specific behaviour. I've had > sufficient problems with HTTP/2 over slow connections (I live where there > are no land lines of any kind) that I replaced the HTTP/2 code in Nginx > with code from pureftpd in order to access my server at home when I'm out. > >> > >> Andrew > >> > >> ï»¿On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" < > pharo-users-bounces(a)lists.pharo.org on behalf of yuriy.tymchuk(a)me.com> > wrote: > >> > >> Hi, > >> > >> Iâm trying to hack something with Pharo 6.1 and Phillips Hue[1] (they > have a simple REST API). When I try to do a GET request with Zinc like this: > >> > >> ZnClient new > >> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > >> get > >> > >> I get a âConnectionClosed: Connection closed while waiting for dataâ > exception. The service provides a JSON response that I can get without a > problem by using a web browser or curl. Also if I try to access fewer data > (e.g. adding /1 to the url, so it gets only one resource) I donât get the > exception. > >> > >> What is even more strange, when I resume the exception I get the > desired response i.e. this works: > >> > >> [ ZnClient new > >> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > >> get ] > >> > >> on: ConnectionClosed > >> do: [ :ex | > >> ex resumeUnchecked: ex defaultResumeValue ] > >> > >> Of course I cannot share the server that is on my local network for > resting, but maybe anyone knows it there are any known issues with Zinc, or > if there are ways for me to debug the issue further. > >> > >> Cheers. > >> Uko > >> > >> [1]: https://www.developers.meethue.com > >> > >> > >> > >> > > > > > > > > > > ---------- Forwarded message ---------- > From: Andrei Stebakov <lispercat(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 25 Dec 2017 20:51:51 -0500 > Subject: [Pharo-users] Breakpoints in Pharo > Can I expect that break points in Pharo work in the same way as in Visual > Works? > When I set a break point in Pharo (6.1 on Windows), it displays a red dot > with an exclamation mark and when I send this message to an object, the > debugger doesn't get invoked. > > > > ---------- Forwarded message ---------- > From: Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Tue, 26 Dec 2017 08:21:50 +0100 > Subject: Re: [Pharo-users] Strange 'Connection closed while waiting for > data.' Zinc error > Hi Sven, > > No, Iâm on Mac (OS 10.13). > > Cheers. > Uko > > > On 25 Dec 2017, at 20:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > >> On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> > >> Hi, > >> > >> setting the reuse timeout to 0 or making a one shot client does not > help. But while googling I found the exact issue described on the Pharo > issue tracker: https://pharo.fogbugz.com/f/cases/18588/ > >> > >> The proposed workaround also worked for me: > >> ZnNetworkingUtils default socketStreamClass: SocketStream. > > > > You are on Windows I guess ? > > > >> Cheers, > >> Uko > >> > >>> On 25 Dec 2017, at 05:42, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >>> > >>> The only time I've seen that behaviour is with the combination of a > slow server and a proxy such as CloudFlare where the sysadmin has set > tcp_wait to some ridiculously small number. Have you tried setting the > connection reuse timeout to 0, or setting 'beOneShot'? > >>> > >>> Zinc doesn't support the additions in HTTP/2, but I can't offhand > think of any reason that should cause that specific behaviour. I've had > sufficient problems with HTTP/2 over slow connections (I live where there > are no land lines of any kind) that I replaced the HTTP/2 code in Nginx > with code from pureftpd in order to access my server at home when I'm out. > >>> > >>> Andrew > >>> > >>> ï»¿On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" < > pharo-users-bounces(a)lists.pharo.org on behalf of yuriy.tymchuk(a)me.com> > wrote: > >>> > >>> Hi, > >>> > >>> Iâm trying to hack something with Pharo 6.1 and Phillips Hue[1] (they > have a simple REST API). When I try to do a GET request with Zinc like this: > >>> > >>> ZnClient new > >>> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > >>> get > >>> > >>> I get a âConnectionClosed: Connection closed while waiting for dataâ > exception. The service provides a JSON response that I can get without a > problem by using a web browser or curl. Also if I try to access fewer data > (e.g. adding /1 to the url, so it gets only one resource) I donât get the > exception. > >>> > >>> What is even more strange, when I resume the exception I get the > desired response i.e. this works: > >>> > >>> [ ZnClient new > >>> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > >>> get ] > >>> > >>> on: ConnectionClosed > >>> do: [ :ex | > >>> ex resumeUnchecked: ex defaultResumeValue ] > >>> > >>> Of course I cannot share the server that is on my local network for > resting, but maybe anyone knows it there are any known issues with Zinc, or > if there are ways for me to debug the issue further. > >>> > >>> Cheers. > >>> Uko > >>> > >>> [1]: https://www.developers.meethue.com > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > > > ---------- Forwarded message ---------- > From: Sven Van Caekenberghe <sven(a)stfx.eu> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Tue, 26 Dec 2017 10:14:54 +0100 > Subject: Re: [Pharo-users] Strange 'Connection closed while waiting for > data.' Zinc error > > > > On 26 Dec 2017, at 08:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Hi Sven, > > > > No, Iâm on Mac (OS 10.13). > > That is not good then, Uko, but again, there is no way to start debugging > this without a reliable test case that I can run too. > > Sven > > > Cheers. > > Uko > > > >> On 25 Dec 2017, at 20:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >> > >>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >>> > >>> Hi, > >>> > >>> setting the reuse timeout to 0 or making a one shot client does not > help. But while googling I found the exact issue described on the Pharo > issue tracker: https://pharo.fogbugz.com/f/cases/18588/ > >>> > >>> The proposed workaround also worked for me: > >>> ZnNetworkingUtils default socketStreamClass: SocketStream. > >> > >> You are on Windows I guess ? > >> > >>> Cheers, > >>> Uko > >>> > >>>> On 25 Dec 2017, at 05:42, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >>>> > >>>> The only time I've seen that behaviour is with the combination of a > slow server and a proxy such as CloudFlare where the sysadmin has set > tcp_wait to some ridiculously small number. Have you tried setting the > connection reuse timeout to 0, or setting 'beOneShot'? > >>>> > >>>> Zinc doesn't support the additions in HTTP/2, but I can't offhand > think of any reason that should cause that specific behaviour. I've had > sufficient problems with HTTP/2 over slow connections (I live where there > are no land lines of any kind) that I replaced the HTTP/2 code in Nginx > with code from pureftpd in order to access my server at home when I'm out. > >>>> > >>>> Andrew > >>>> > >>>> ï»¿On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" < > pharo-users-bounces(a)lists.pharo.org on behalf of yuriy.tymchuk(a)me.com> > wrote: > >>>> > >>>> Hi, > >>>> > >>>> Iâm trying to hack something with Pharo 6.1 and Phillips Hue[1] (they > have a simple REST API). When I try to do a GET request with Zinc like this: > >>>> > >>>> ZnClient new > >>>> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > >>>> get > >>>> > >>>> I get a âConnectionClosed: Connection closed while waiting for dataâ > exception. The service provides a JSON response that I can get without a > problem by using a web browser or curl. Also if I try to access fewer data > (e.g. adding /1 to the url, so it gets only one resource) I donât get the > exception. > >>>> > >>>> What is even more strange, when I resume the exception I get the > desired response i.e. this works: > >>>> > >>>> [ ZnClient new > >>>> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731 > df/lights/'; > >>>> get ] > >>>> > >>>> on: ConnectionClosed > >>>> do: [ :ex | > >>>> ex resumeUnchecked: ex defaultResumeValue ] > >>>> > >>>> Of course I cannot share the server that is on my local network for > resting, but maybe anyone knows it there are any known issues with Zinc, or > if there are ways for me to debug the issue further. > >>>> > >>>> Cheers. > >>>> Uko > >>>> > >>>> [1]: https://www.developers.meethue.com > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > >

Dec. 26, 2017

Re: [Pharo-users] Thanks All.

by Stephan Eggermont

Op 26-12-2017 om 14:03 schreef Ian Ian: > After some looking into it I believe Mongo Voyager is the easiest given > the current options. > > Too bad Gemstone limits usage after a given number of Gems. I have always found the Gemstone people very approachable, and open to trying out ideas. Stephan

Dec. 26, 2017

Re: [Pharo-users] Thanks All.

by Stephan Eggermont

Op 26-12-2017 om 14:03 schreef Ian Ian: > After some looking into it I believe Mongo Voyager is the easiest given > the current options. > > Too bad Gemstone limits usage after a given number of Gems. I have always found the Gemstone people very approachable, and open to trying out ideas. Stephan

Dec. 26, 2017

Re: [Pharo-users] Thanks All.

by Stephan Eggermont

Op 26-12-2017 om 14:03 schreef Ian Ian: > After some looking into it I believe Mongo Voyager is the easiest given > the current options. > > Too bad Gemstone limits usage after a given number of Gems. I have always found the Gemstone people very approachable, and open to trying out ideas. Stephan

Dec. 26, 2017

Re: [Pharo-users] Athens error

by Nicolai Hess

Running your drgeo.image on a recent linux pharo 64 bit vm gives this error message first: /home/nicolai/devel/pharo/Pharo7.0-32bit-52a28a8.sources. With pharo 7, every (bootstrapped)image needs its own sources file? 2017-12-26 11:59 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > Just make a drgeo build with latest image as of today, the problem is the > same with latest image, as long as the source file is not present. Here is > the newest built[1] > > Hilaire > > > [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 > > Le 26/12/2017 Ã 11:15, Pavel Krivanek a Ã©crit : > >> Hi Hilaire >> >> your P7 image is older and has problems with FreeType fonts >> initialization that should be fixed in the newest builds. Maybe that is >> cause of the Athens issues you are facing. Please upgrade. >> >> > -- > Dr. Geo > http://drgeo.eu > > > >

Dec. 26, 2017

Thanks All.

by Ian Ian

After some looking into it I believe Mongo Voyager is the easiest given the current options. Too bad Gemstone limits usage after a given number of Gems. Too bad ObjectDB does as well. Thanks all. :) On Dec 25, 2017 12:00 PM, <pharo-users-request(a)lists.pharo.org> wrote: > Send Pharo-users mailing list submissions to > pharo-users(a)lists.pharo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-users_ > lists.pharo.org > or, via email, send a message with subject or body 'help' to > pharo-users-request(a)lists.pharo.org > > You can reach the person managing the list at > pharo-users-owner(a)lists.pharo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-users digest..." > > Today's Topics: > > 1. Re: Object Persistence (Hilaire) > 2. Re: Object Persistence (Joachim Tuchel) > 3. Re: Object Persistence (Torsten Bergmann) > 4. Re: Object Persistence (Stephane Ducasse) > > > ---------- Forwarded message ---------- > From: Hilaire <hilaire(a)drgeo.eu> > To: pharo-users(a)lists.pharo.org > Cc: > Bcc: > Date: Mon, 25 Dec 2017 12:08:08 +0100 > Subject: Re: [Pharo-users] Object Persistence > Fuel (present in the image) is nice, but not compatible from one image > version to another one. > > Hilaire > > > Le 25/12/2017 Ã 10:43, Ian Ian a Ã©crit : > >> Hi All, >> >> Thoughts of a purely OO nature? >> >> :) >> > > -- > Dr. Geo > http://drgeo.eu > > > > > > > ---------- Forwarded message ---------- > From: Joachim Tuchel <jtuchel(a)objektfabrik.de> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 25 Dec 2017 12:54:10 +0100 > Subject: Re: [Pharo-users] Object Persistence > Wasnât there an attempt to port Magma over from Squeak? That would sound > like a nice alternative. Or Gemstone, of course. > > > Am 25.12.2017 um 10:43 schrieb Ian Ian <icjohnsoia(a)gmail.com>: > > > > Hi All, > > > > Thoughts of a purely OO nature? > > > > :) > > > > > > ---------- Forwarded message ---------- > From: Torsten Bergmann <astares(a)gmx.de> > To: pharo-users(a)lists.pharo.org > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Bcc: > Date: Mon, 25 Dec 2017 14:13:37 +0100 > Subject: Re: [Pharo-users] Object Persistence > Hi, > > with Voyage you can already use easy persistence in an OO way - with tiny > (P)UnQlite up to Mongo. > > Check https://github.com/pharo-nosql > > Or you use Gemstone. > > For a full Magma version on Pharo: > I doubt that will happen as Chris Muller was and still is more oriented > towards Squeak as > development platform. He is the author of Magma and beside the port it > would cost him > (or anyone who would do such a port) more effort to maintain another Pharo > specific version. > > But maybe a Pharo client for a Squeak based Magma server is possible - > with a Voyage wrapper. > > Bye > T. > > > Gesendet: Montag, 25. Dezember 2017 um 12:54 Uhr > > Von: "Joachim Tuchel" <jtuchel(a)objektfabrik.de> > > An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > > Betreff: Re: [Pharo-users] Object Persistence > > > > Wasnât there an attempt to port Magma over from Squeak? That would sound > like a nice alternative. Or Gemstone, of course. > > > > > Am 25.12.2017 um 10:43 schrieb Ian Ian <icjohnsoia(a)gmail.com>: > > > > > > Hi All, > > > > > > Thoughts of a purely OO nature? > > > > > > :) > > > > > > > > > > > ---------- Forwarded message ---------- > From: Stephane Ducasse <stepharo.self(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 25 Dec 2017 16:01:15 +0100 > Subject: Re: [Pharo-users] Object Persistence > the author of omnibase told me that he always wanted to port it to > Pharo. But may be someone should do it. > There is also VOSS that is open source even if GPL that could be > ported to pharo but this is an effort too. > > Stef > > On Mon, Dec 25, 2017 at 10:43 AM, Ian Ian <icjohnsoia(a)gmail.com> wrote: > > Hi All, > > > > Thoughts of a purely OO nature? > > > > :) > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > >

Dec. 26, 2017

Re: [Pharo-users] Athens error

by Hilaire

Just make a drgeo build with latest image as of today, the problem is the same with latest image, as long as the source file is not present. Here is the newest built[1] Hilaire [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 Le 26/12/2017 Ã 11:15, Pavel Krivanek a Ã©critÂ : > Hi Hilaire > > your P7 image is older and has problems with FreeType fonts > initialization that should be fixed in the newest builds. Maybe that > is cause of the Athens issues you are facing. Please upgrade. > -- Dr. Geo http://drgeo.eu

Dec. 26, 2017

Re: [Pharo-users] Athens error

by Pavel Krivanek

Hi Hilaire your P7 image is older and has problems with FreeType fonts initialization that should be fixed in the newest builds. Maybe that is cause of the Athens issues you are facing. Please upgrade. -- Pavel 2017-12-25 12:05 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > The source is really needed to get Athens functionning, otherwise there is > an error. On top of that, the source file name is confused by Pharo (it > should be mimic of the 32bits images, althought 64bits image is used, and > it should not depend on the bits number I guess). > > Here is an archive with the image[1], go in Contents/Resources/drgeo.image > and used a 64 bits VM to run the image, do not used the embedded VMs, there > are for P3. > > [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 > > Hilaire > > Le 20/12/2017 Ã 21:08, Stephane Ducasse a Ã©crit : > >> Normally the call does not need the sources (if I'm correct in the >> past it needed to generate the correct method argument or something >> like that). >> Can you provide more information? or the image somewhere? >> Because FFI should improve and we are looking for edge corner bugs. >> >> Stef >> > > -- > Dr. Geo > http://drgeo.eu > > > >

Dec. 26, 2017

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

by Sven Van Caekenberghe

> On 26 Dec 2017, at 08:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi Sven, > > No, Iâm on Mac (OS 10.13). That is not good then, Uko, but again, there is no way to start debugging this without a reliable test case that I can run too. Sven > Cheers. > Uko > >> On 25 Dec 2017, at 20:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hi, >>> >>> setting the reuse timeout to 0 or making a one shot client does not help. But while googling I found the exact issue described on the Pharo issue tracker: https://pharo.fogbugz.com/f/cases/18588/ >>> >>> The proposed workaround also worked for me: >>> ZnNetworkingUtils default socketStreamClass: SocketStream. >> >> You are on Windows I guess ? >> >>> Cheers, >>> Uko >>> >>>> On 25 Dec 2017, at 05:42, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>> >>>> The only time I've seen that behaviour is with the combination of a slow server and a proxy such as CloudFlare where the sysadmin has set tcp_wait to some ridiculously small number. Have you tried setting the connection reuse timeout to 0, or setting 'beOneShot'? >>>> >>>> Zinc doesn't support the additions in HTTP/2, but I can't offhand think of any reason that should cause that specific behaviour. I've had sufficient problems with HTTP/2 over slow connections (I live where there are no land lines of any kind) that I replaced the HTTP/2 code in Nginx with code from pureftpd in order to access my server at home when I'm out. >>>> >>>> Andrew >>>> >>>> ï»¿On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" <pharo-users-bounces(a)lists.pharo.org on behalf of yuriy.tymchuk(a)me.com> wrote: >>>> >>>> Hi, >>>> >>>> Iâm trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have a simple REST API). When I try to do a GET request with Zinc like this: >>>> >>>> ZnClient new >>>> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/'; >>>> get >>>> >>>> I get a âConnectionClosed: Connection closed while waiting for dataâ exception. The service provides a JSON response that I can get without a problem by using a web browser or curl. Also if I try to access fewer data (e.g. adding /1 to the url, so it gets only one resource) I donât get the exception. >>>> >>>> What is even more strange, when I resume the exception I get the desired response i.e. this works: >>>> >>>> [ ZnClient new >>>> url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/'; >>>> get ] >>>> >>>> on: ConnectionClosed >>>> do: [ :ex | >>>> ex resumeUnchecked: ex defaultResumeValue ] >>>> >>>> Of course I cannot share the server that is on my local network for resting, but maybe anyone knows it there are any known issues with Zinc, or if there are ways for me to debug the issue further. >>>> >>>> Cheers. >>>> Uko >>>> >>>> [1]: https://www.developers.meethue.com >>>> >>>> >>>> >>>> >>> >>> >> >> > >

Dec. 26, 2017