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-requ...@lists.pharo.org> wrote: > Send Pharo-users mailing list submissions to > pharo-users@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-requ...@lists.pharo.org > > You can reach the person managing the list at > pharo-users-ow...@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.tymc...@me.com> > To: Any question about pharo is welcome <pharo-users@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 <aglyn...@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-boun...@lists.pharo.org on behalf of yuriy.tymc...@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" <serp...@gmail.com> > To: Any question about pharo is welcome <pharo-users@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? > u...@server.com:/proj/proj.git > > Isn't it: g...@server.com:user/project.git ? > > On Dec 24, 2017 15:36, "Ian Ian" <icjohns...@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 >> u...@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 usern...@server.com:/directory/proj.git. >> >> However fails to parse: usern...@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 <s...@stfx.eu> > To: Any question about pharo is welcome <pharo-users@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.tymc...@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 <aglyn...@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-boun...@lists.pharo.org on behalf of yuriy.tymc...@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 <lisper...@gmail.com> > To: Any question about pharo is welcome <pharo-users@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.tymc...@me.com> > To: Any question about pharo is welcome <pharo-users@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 <s...@stfx.eu> wrote: > > > > > > > >> On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymc...@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 <aglyn...@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-boun...@lists.pharo.org on behalf of yuriy.tymc...@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 <s...@stfx.eu> > To: Any question about pharo is welcome <pharo-users@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.tymc...@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 <s...@stfx.eu> wrote: > >> > >> > >> > >>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymc...@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 <aglyn...@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-boun...@lists.pharo.org on behalf of yuriy.tymc...@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@lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > >
