- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Package for manage USB - RS232

by Sven Van Caekenberghe

You should #close the port when you are done, else it remains in use, I would guess. Also, why do you #close before you start, seems strange to me ? On 17 Feb 2014, at 12:05, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: > Ciao, > > >> Hi, >> >> I'm also interested by an answer to that question. So far, what I have as status is: you need a plugin to handle communications with the serial port (either for direct RS232 or USB-to-Serial) and compiling the serial port plugin with the Pharo VM makes it unstable. > > I dont know " compiling " plugin area. ( i work with Windows 7 ) > >> The solution we used was: to compile the serial plugin for the squeak VM and work in Squeak (4.3) instead of Pharo. > > Can you explain more detail about it? > > > My test is : > > > I download the Pharo 2.0 #20628 and i use the SerialPort class. > > The first time i do the code: > > | srl | > > srl := SerialPort new. > srl close. > > srl openPort: 'COM1'. > > srl nextPutAll: #[ 27 66 2 2 ] . > > The RS232 device work fine. > > After the first time, when submit the same code the system answer: > > Error: Cannot open 'COM1' > > A this time i need to restart the Pharo environment. > > > Any considerations, suggestions ? > > > Thanks, > > Dario > > >> >> Thierry >> >> Le 16/02/2014 16:28, Dario Trussardi a Ã©crit : >>> Hi, >>> >>> >>> i work with: Pharo1.Latest update: #14445 ( or with: Pharo2.0 Latest update: #20628 ). >>> >>> >>> I'm interested to manage communications with USB or RS232 device. >>> >>> >>> I can find package which support this protocol? >>> >>> Thank for any considerations ? >>> >>> Dario >>> >>> >>> >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >

Feb. 17, 2014

Re: [Pharo-dev] Package for manage USB - RS232

by Dario Trussardi

Ciao, > Hi, > > I'm also interested by an answer to that question. So far, what I have as status is: you need a plugin to handle communications with the serial port (either for direct RS232 or USB-to-Serial) and compiling the serial port plugin with the Pharo VM makes it unstable. I dont know " compiling " plugin area. ( i work with Windows 7 ) > The solution we used was: to compile the serial plugin for the squeak VM and work in Squeak (4.3) instead of Pharo. Can you explain more detail about it? My test is : I download the Pharo 2.0 #20628 and i use the SerialPort class. The first time i do the code: | srl | srl := SerialPort new. srl close. srl openPort: 'COM1'. srl nextPutAll: #[ 27 66 2 2 ] . The RS232 device work fine. After the first time, when submit the same code the system answer: Error: Cannot open 'COM1' A this time i need to restart the Pharo environment. Any considerations, suggestions ? Thanks, Dario > > Thierry > > Le 16/02/2014 16:28, Dario Trussardi a Ã©crit : >> Hi, >> >> >> i work with: Pharo1.Latest update: #14445 ( or with: Pharo2.0 Latest update: #20628 ). >> >> >> I'm interested to manage communications with USB or RS232 device. >> >> >> I can find package which support this protocol? >> >> Thank for any considerations ? >> >> Dario >> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Feb. 17, 2014

Re: [Pharo-dev] Connection closed while waiting for data in bootstrapped image

by Guillermo Polito

On Mon, Feb 17, 2014 at 11:22 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > > On 17 Feb 2014, at 11:18, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > ExternalSemaphores table may be not well initialized? I can help having > a look this afternoon :) > > Spoken like someone who has seen a fair bit of the low level parts ! > Suffered in the hard way you mean? :^) > > Yes, indeed, that could be it: data comes in on the socket but semaphore > is not signalled and/or the image never knows about it and hence thinks no > data came in. > > Good luck. > > > On Mon, Feb 17, 2014 at 11:11 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi Pavel, > > > > I just tried on a machine of mine. > > > > I changed testNetwork.st to > > > > Transcript show: (ZnClient new logToTranscript; get: ' > http://zn.stfx.eu/zn/numbers.txt'); cr. > > > > That way you get a bit more progress info. As I suspected the request is > written and the failure is while reading the response. I tried connecting > to a local Zinc server which confirmed this as well: the request comes in > on the server and it writes the response. > > > > This is the output now: > > > > root@stfx:~# ./pharo PharoKernel.image testNetwork.st > > > > 2014-02-17 10:00:59 463573 I Wrote a ZnRequest(GET /random) > > 2014-02-17 10:00:59 463573 D Sent headers > > > > User-Agent: Zinc HTTP Components 1.0 > > > > Accept: */* > > > > Host: localhost:1701 > > > > > > > =============================================================================== > > Notice: Errors in script loaded from /root/testNetwork.st > > > =============================================================================== > > Errors in script loaded from /root/testNetwork.st > > ==== Startup Error: ConnectionClosed: Connection closed while waiting > for data. > > Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection > closed whil...etc... > > Socket>>waitForDataFor:ifClosed:ifTimedOut: > > Socket>>waitForDataFor: > > Socket>>receiveDataSignallingTimeout:into:startingAt: > > SocketStream>>receiveData > > SocketStream>>next > > ZnLineReader>>processNext > > ZnLineReader>>nextLine > > ZnStatusLine>>readFrom: > > ZnStatusLine class>>readFrom: > > ZnResponse>>readHeaderFrom: > > ZnResponse(ZnMessage)>>readFrom: > > ZnResponse class(ZnMessage class)>>readFrom: > > ZnClient>>executeRequestResponse > > ZnClient>>getConnectionAndExecute in Block: [ self > executeRequestResponse ] > > BlockClosure>>ensure: > > ZnClient>>getConnectionAndExecute > > ZnClient>>executeWithRedirectsRemaining: > > ZnClient>>executeWithRetriesRemaining: in Block: [ self > executeWithRedirectsRemaining: self maxNumb...etc... > > BlockClosure>>on:do: > > ZnClient>>executeWithRetriesRemaining: > > ZnClient>>executeWithTimeout in Block: [ self > executeWithRetriesRemaining: self numberOfR...etc... > > BlockClosure>>on:do: > > ZnClient>>executeWithTimeout in Block: [ ... > > ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > > ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: > > > > You are using regular socket streams, which is good. For now I can't > think of a reasons why the reading would fail, if I think of something, I > will let you know. > > > > It is pretty hard to debug this way ;-) > > > > Sven > > > > On 17 Feb 2014, at 10:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > > (NetNameResolver addressForName: 'www.esug.org') returns good value... > > > > > > -- Pavel > > > > > > > > > 2014-02-17 9:32 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > Hi, > > > > > > thank you for the tip. It seems that it is not directly Zinc related. > But if you want something to play with, do: > > > > > > - load the bootstrapped image: > > > > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > > > > > ./pharo PharoKernel.image fix.st > > > ./pharo PharoKernel.image loadNetwork.st > > > ./pharo PharoKernel.image testNetwork.st > > > > > > The CI slaves revolt now so I cannot make it more comfortable :-) > > > > > > Cheers, > > > -- Pavel > > > > > > > > > > > > > > > 2014-02-16 22:58 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > > > Hi Pavel, > > > > > > On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > > > > Hi Sven, > > > > > > > > we can successfully load network packages to the bootstrapped image > but when we try to test it using: > > > > > > > > ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. > > > > > > > > we get "ConnectionClosed: Connection closed while waiting for data" > error after few seconds. Do you have some idea, what may be wrong? Probably > something is not initialized well but I have no clue what. > > > > > > > > Cheers, > > > > -- Pavel > > > > > > Hard to say. I would guess that you are already on the point of > waiting for a server response, so you already successfully initialised > networking, resolved DNS, opened a TCP socket and wrote the request over > it. On the other hand, one of those steps might not have been done right, > since you get no response. > > > > > > Any chance of a stack trace ? Or an image ? But that would be a > headless one I guess ;-) > > > > > > Sven > > > > > > > > > > > > > > > > > > > > > > > >

Feb. 17, 2014

Mapping key Ctrl+M and Ctrl+Enter

by Nicolai Hess

Someone knows(remembers) why Ctrl+Enter is mapped to keyvalue 13 I would expect Ctrl+M to be mapped at this value. Ctrl+l -> keyValue 12 Ctrl+Enter -> keyValue 13 Ctrl+n -> keyValue 14 I miss Ctrl+M -> keyValue ???? (see Fogbugz issue 12103 <https://pharo.fogbugz.com/default.asp?12103> shortcuts for tools) (I vagualy remember this is related to the VM and there was a reason for doing so, but don't know it anymore) regards nicolai

Feb. 17, 2014

Re: [Pharo-dev] CMS status

by Norbert Hartl

Am 17.02.2014 um 11:17 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Phil, > > On 17 Feb 2014, at 10:13, phil(a)highoctane.be wrote: > >> 2- Process vs on-request >> >> PHP-based solutions mostly have the request->apache->mod_php->scripts->db and back roundtrip. When there is no client, there is no CPU, no nothing used. This allows to pile on users in a shared hosting as there is usually not that much traffic. >> >> With the current Pharo+Seaside combo for example, we do have an always running pharo process taking away CPU cycles. That's not too good for shared hosting and platforms like EC2 where we pay based on that. >> >> >> As my thinking goes, I find interesting to have a FastCGI interface for pure Pharo (until we possibly have a mod_pharo) so that pharo becomes a first class scripting option for simple web applications. With the new command line and environment access, that's not that hard to do. > > FastCGI is a long running process as well, right ? > > It would not be unthinkable to boot a new image when needed and shut it down when it is idle for some time. It takes less then half a second: > > root@stfx:~# time ./pharo Pharo.image printVersion > [version] 3.0 #30203 > > real 0m0.379s > user 0m0.148s > sys 0m0.028s > > Lots of intelligent things could be done, I am just not sure we should compete in this space as I doubt there is any money to be made. > There can always be done a lot. But letâs face it. Amazon is offering different sizes of machines that are charged differently. The smallest one is quite a pain when it comes to latency. Sometimes you will experience half a second or more as latency for a running image. And starting an image on those machines will take a lot longer. What we are talking about are really small projects. If you do the cost calculation then you might see that amazon is not a good fit for these types of applications. The business of amazon works this way because the cloud buzz makes you believe it is cheap but in most situations it is not. S3 being one of the exceptions. Small projects only consume memory and machine/cpu time but not much cycles. So how clever can your approach be if try to make it fit into a business that calculates its cost based on time and memory? :) Norbert

Feb. 17, 2014

Re: [Pharo-dev] Connection closed while waiting for data in bootstrapped image

by Sven Van Caekenberghe

On 17 Feb 2014, at 11:18, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > ExternalSemaphores table may be not well initialized? I can help having a look this afternoon :) Spoken like someone who has seen a fair bit of the low level parts ! Yes, indeed, that could be it: data comes in on the socket but semaphore is not signalled and/or the image never knows about it and hence thinks no data came in. Good luck. > On Mon, Feb 17, 2014 at 11:11 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Pavel, > > I just tried on a machine of mine. > > I changed testNetwork.st to > > Transcript show: (ZnClient new logToTranscript; get: 'http://zn.stfx.eu/zn/numbers.txt'); cr. > > That way you get a bit more progress info. As I suspected the request is written and the failure is while reading the response. I tried connecting to a local Zinc server which confirmed this as well: the request comes in on the server and it writes the response. > > This is the output now: > > root@stfx:~# ./pharo PharoKernel.image testNetwork.st > > 2014-02-17 10:00:59 463573 I Wrote a ZnRequest(GET /random) > 2014-02-17 10:00:59 463573 D Sent headers > > User-Agent: Zinc HTTP Components 1.0 > > Accept: */* > > Host: localhost:1701 > > > =============================================================================== > Notice: Errors in script loaded from /root/testNetwork.st > =============================================================================== > Errors in script loaded from /root/testNetwork.st > ==== Startup Error: ConnectionClosed: Connection closed while waiting for data. > Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection closed whil...etc... > Socket>>waitForDataFor:ifClosed:ifTimedOut: > Socket>>waitForDataFor: > Socket>>receiveDataSignallingTimeout:into:startingAt: > SocketStream>>receiveData > SocketStream>>next > ZnLineReader>>processNext > ZnLineReader>>nextLine > ZnStatusLine>>readFrom: > ZnStatusLine class>>readFrom: > ZnResponse>>readHeaderFrom: > ZnResponse(ZnMessage)>>readFrom: > ZnResponse class(ZnMessage class)>>readFrom: > ZnClient>>executeRequestResponse > ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] > BlockClosure>>ensure: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > ZnClient>>executeWithTimeout in Block: [ ... > ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: > > You are using regular socket streams, which is good. For now I can't think of a reasons why the reading would fail, if I think of something, I will let you know. > > It is pretty hard to debug this way ;-) > > Sven > > On 17 Feb 2014, at 10:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > (NetNameResolver addressForName: 'www.esug.org') returns good value... > > > > -- Pavel > > > > > > 2014-02-17 9:32 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > Hi, > > > > thank you for the tip. It seems that it is not directly Zinc related. But if you want something to play with, do: > > > > - load the bootstrapped image: > > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > > > ./pharo PharoKernel.image fix.st > > ./pharo PharoKernel.image loadNetwork.st > > ./pharo PharoKernel.image testNetwork.st > > > > The CI slaves revolt now so I cannot make it more comfortable :-) > > > > Cheers, > > -- Pavel > > > > > > > > > > 2014-02-16 22:58 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Hi Pavel, > > > > On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > > Hi Sven, > > > > > > we can successfully load network packages to the bootstrapped image but when we try to test it using: > > > > > > ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. > > > > > > we get "ConnectionClosed: Connection closed while waiting for data" error after few seconds. Do you have some idea, what may be wrong? Probably something is not initialized well but I have no clue what. > > > > > > Cheers, > > > -- Pavel > > > > Hard to say. I would guess that you are already on the point of waiting for a server response, so you already successfully initialised networking, resolved DNS, opened a TCP socket and wrote the request over it. On the other hand, one of those steps might not have been done right, since you get no response. > > > > Any chance of a stack trace ? Or an image ? But that would be a headless one I guess ;-) > > > > Sven > > > > > > > > > > > > >

Feb. 17, 2014

Re: [Pharo-dev] Connection closed while waiting for data in bootstrapped image

by Guillermo Polito

ExternalSemaphores table may be not well initialized? I can help having a look this afternoon :) On Mon, Feb 17, 2014 at 11:11 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Hi Pavel, > > I just tried on a machine of mine. > > I changed testNetwork.st to > > Transcript show: (ZnClient new logToTranscript; get: ' > http://zn.stfx.eu/zn/numbers.txt'); cr. > > That way you get a bit more progress info. As I suspected the request is > written and the failure is while reading the response. I tried connecting > to a local Zinc server which confirmed this as well: the request comes in > on the server and it writes the response. > > This is the output now: > > root@stfx:~# ./pharo PharoKernel.image testNetwork.st > > 2014-02-17 10:00:59 463573 I Wrote a ZnRequest(GET /random) > 2014-02-17 10:00:59 463573 D Sent headers > > User-Agent: Zinc HTTP Components 1.0 > > Accept: */* > > Host: localhost:1701 > > > > =============================================================================== > Notice: Errors in script loaded from /root/testNetwork.st > > =============================================================================== > Errors in script loaded from /root/testNetwork.st > ==== Startup Error: ConnectionClosed: Connection closed while waiting for > data. > Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection > closed whil...etc... > Socket>>waitForDataFor:ifClosed:ifTimedOut: > Socket>>waitForDataFor: > Socket>>receiveDataSignallingTimeout:into:startingAt: > SocketStream>>receiveData > SocketStream>>next > ZnLineReader>>processNext > ZnLineReader>>nextLine > ZnStatusLine>>readFrom: > ZnStatusLine class>>readFrom: > ZnResponse>>readHeaderFrom: > ZnResponse(ZnMessage)>>readFrom: > ZnResponse class(ZnMessage class)>>readFrom: > ZnClient>>executeRequestResponse > ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] > BlockClosure>>ensure: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > ZnClient>>executeWithRetriesRemaining: in Block: [ self > executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: > self numberOfR...etc... > BlockClosure>>on:do: > ZnClient>>executeWithTimeout in Block: [ ... > ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: > > You are using regular socket streams, which is good. For now I can't think > of a reasons why the reading would fail, if I think of something, I will > let you know. > > It is pretty hard to debug this way ;-) > > Sven > > On 17 Feb 2014, at 10:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > (NetNameResolver addressForName: 'www.esug.org') returns good value... > > > > -- Pavel > > > > > > 2014-02-17 9:32 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > Hi, > > > > thank you for the tip. It seems that it is not directly Zinc related. > But if you want something to play with, do: > > > > - load the bootstrapped image: > > > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > > > ./pharo PharoKernel.image fix.st > > ./pharo PharoKernel.image loadNetwork.st > > ./pharo PharoKernel.image testNetwork.st > > > > The CI slaves revolt now so I cannot make it more comfortable :-) > > > > Cheers, > > -- Pavel > > > > > > > > > > 2014-02-16 22:58 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Hi Pavel, > > > > On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > > Hi Sven, > > > > > > we can successfully load network packages to the bootstrapped image > but when we try to test it using: > > > > > > ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. > > > > > > we get "ConnectionClosed: Connection closed while waiting for data" > error after few seconds. Do you have some idea, what may be wrong? Probably > something is not initialized well but I have no clue what. > > > > > > Cheers, > > > -- Pavel > > > > Hard to say. I would guess that you are already on the point of waiting > for a server response, so you already successfully initialised networking, > resolved DNS, opened a TCP socket and wrote the request over it. On the > other hand, one of those steps might not have been done right, since you > get no response. > > > > Any chance of a stack trace ? Or an image ? But that would be a headless > one I guess ;-) > > > > Sven > > > > > > > > > > > > >

Feb. 17, 2014

Re: [Pharo-dev] CMS status

by Sven Van Caekenberghe

Phil, On 17 Feb 2014, at 10:13, phil(a)highoctane.be wrote: > 2- Process vs on-request > > PHP-based solutions mostly have the request->apache->mod_php->scripts->db and back roundtrip. When there is no client, there is no CPU, no nothing used. This allows to pile on users in a shared hosting as there is usually not that much traffic. > > With the current Pharo+Seaside combo for example, we do have an always running pharo process taking away CPU cycles. That's not too good for shared hosting and platforms like EC2 where we pay based on that. > > > As my thinking goes, I find interesting to have a FastCGI interface for pure Pharo (until we possibly have a mod_pharo) so that pharo becomes a first class scripting option for simple web applications. With the new command line and environment access, that's not that hard to do. FastCGI is a long running process as well, right ? It would not be unthinkable to boot a new image when needed and shut it down when it is idle for some time. It takes less then half a second: root@stfx:~# time ./pharo Pharo.image printVersion [version] 3.0 #30203 real 0m0.379s user 0m0.148s sys 0m0.028s Lots of intelligent things could be done, I am just not sure we should compete in this space as I doubt there is any money to be made. Sven

Feb. 17, 2014

Re: [Pharo-dev] Connection closed while waiting for data in bootstrapped image

by Sven Van Caekenberghe

Hi Pavel, I just tried on a machine of mine. I changed testNetwork.st to Transcript show: (ZnClient new logToTranscript; get: 'http://zn.stfx.eu/zn/numbers.txt'); cr. That way you get a bit more progress info. As I suspected the request is written and the failure is while reading the response. I tried connecting to a local Zinc server which confirmed this as well: the request comes in on the server and it writes the response. This is the output now: root@stfx:~# ./pharo PharoKernel.image testNetwork.st 2014-02-17 10:00:59 463573 I Wrote a ZnRequest(GET /random) 2014-02-17 10:00:59 463573 D Sent headers User-Agent: Zinc HTTP Components 1.0 Accept: */* Host: localhost:1701 =============================================================================== Notice: Errors in script loaded from /root/testNetwork.st =============================================================================== Errors in script loaded from /root/testNetwork.st ==== Startup Error: ConnectionClosed: Connection closed while waiting for data. Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection closed whil...etc... Socket>>waitForDataFor:ifClosed:ifTimedOut: Socket>>waitForDataFor: Socket>>receiveDataSignallingTimeout:into:startingAt: SocketStream>>receiveData SocketStream>>next ZnLineReader>>processNext ZnLineReader>>nextLine ZnStatusLine>>readFrom: ZnStatusLine class>>readFrom: ZnResponse>>readHeaderFrom: ZnResponse(ZnMessage)>>readFrom: ZnResponse class(ZnMessage class)>>readFrom: ZnClient>>executeRequestResponse ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] BlockClosure>>ensure: ZnClient>>getConnectionAndExecute ZnClient>>executeWithRedirectsRemaining: ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... BlockClosure>>on:do: ZnClient>>executeWithTimeout in Block: [ ... ZnClient>>withTimeoutDo: in Block: [ ^ block value ] ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: You are using regular socket streams, which is good. For now I can't think of a reasons why the reading would fail, if I think of something, I will let you know. It is pretty hard to debug this way ;-) Sven On 17 Feb 2014, at 10:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > (NetNameResolver addressForName: 'www.esug.org') returns good value... > > -- Pavel > > > 2014-02-17 9:32 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > thank you for the tip. It seems that it is not directly Zinc related. But if you want something to play with, do: > > - load the bootstrapped image: > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > ./pharo PharoKernel.image fix.st > ./pharo PharoKernel.image loadNetwork.st > ./pharo PharoKernel.image testNetwork.st > > The CI slaves revolt now so I cannot make it more comfortable :-) > > Cheers, > -- Pavel > > > > > 2014-02-16 22:58 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi Pavel, > > On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Hi Sven, > > > > we can successfully load network packages to the bootstrapped image but when we try to test it using: > > > > ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. > > > > we get "ConnectionClosed: Connection closed while waiting for data" error after few seconds. Do you have some idea, what may be wrong? Probably something is not initialized well but I have no clue what. > > > > Cheers, > > -- Pavel > > Hard to say. I would guess that you are already on the point of waiting for a server response, so you already successfully initialised networking, resolved DNS, opened a TCP socket and wrote the request over it. On the other hand, one of those steps might not have been done right, since you get no response. > > Any chance of a stack trace ? Or an image ? But that would be a headless one I guess ;-) > > Sven > > > > >

Feb. 17, 2014

Re: [Pharo-dev] CMS status

by Norbert Hartl

Am 17.02.2014 um 10:13 schrieb phil(a)highoctane.be: > With the current Pharo+Seaside combo for example, we do have an always running pharo process taking away CPU cycles. That's not too good for shared hosting and platforms like EC2 where we pay based on that. > Amazons ec2 is paid based on running machine hours not on cpu cycles. Norbert

Feb. 17, 2014