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

[Yuriy Tymchuk]

Hi Sven,

No, I’m on Mac (OS 10.13).

Cheers.
Uko

> On 25 Dec 2017, at 20:03, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk  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  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" 
>>>  
>>> 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
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

[Pharo-users] Breakpoints in Pharo

[Andrei Stebakov]

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.

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

[Sven Van Caekenberghe]

> On 25 Dec 2017, at 18:03, Yuriy Tymchuk  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  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" 
>>  
>> 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
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Iceberg URL regex not matching how I would expect it to?

[Julián Maestri]

u...@server.com:/proj/proj.git

Isn't it: g...@server.com:user/project.git ?

On Dec 24, 2017 15:36, "Ian Ian"  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,
>
>
>

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

[Yuriy Tymchuk]

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

Re: [Pharo-users] Object Persistence

[Stephane Ducasse]

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  wrote:
> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)

Re: [Pharo-users] Object Persistence

[Torsten Bergmann]

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" 
> An: "Any question about pharo is welcome" 
> 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 :
> > 
> > Hi All,
> > 
> > Thoughts of a purely OO nature?
> > 
> > :)
> 
> 
>

Re: [Pharo-users] Object Persistence

[Joachim Tuchel]

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 :
> 
> Hi All,
> 
> Thoughts of a purely OO nature?
> 
> :)

Re: [Pharo-users] Object Persistence

[Hilaire]

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

Re: [Pharo-users] Athens error

[Hilaire]

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

Re: [Pharo-users] Object Persistence

[Richard Sargent]

GemStone/S, of course!

On Dec 25, 2017 01:44, "Ian Ian"  wrote:

> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)
>

[Pharo-users] Object Persistence

[Ian Ian]

Hi All,

Thoughts of a purely OO nature?

:)