June 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] TestCases and forked processes in TestResource don't play well

by Denis Kudriashov

I think proper fix for this logic would be to disable test environment during startup of resources ÑÑ, 12 Ð¸ÑÐ½. 2019 Ð³. Ð² 21:11, Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Eric. > > You can override #runCaseManaged on your test case: > > MyTestCase>>runCaseManaged > self runCase > > It will disable all clever logic. > > ÑÑ, 12 Ð¸ÑÐ½. 2019 Ð³. Ð² 20:55, Erik Stel <erik.stel(a)gmail.com>: > >> Hi, >> >> I'm developing a web application using (amongst others) WebSockets. To >> prevent test methods from becoming too big and slow I created a TestCase >> with a TestResource containing my web application instance. After the >> first >> test method is run, the WebSocket is closed unexpectedly and >> automagically. >> It turns out that all forked processes are terminated when a TestCase has >> executed a test method. What would be the proper way to prevent these >> forked >> processes from terminating after a single test method? Or am I missing >> something/doing something wrong? >> >> TestExecutionEnvironment>>#checkForkedProcesses is responsible for >> terminating any (non failed) processes. It is executed after >> TestExecutionEnvironment>>#runTestCaseSafelly: [sic: this should be >> #runTestCaseSafely:]. A possible solution might be to check whether the >> Context in which a forked process was created has the #setUp method of a >> TestResource of the TestCase (you still with me ;-) in its Context chain. >> If >> that is the case, the process is probably forked for a reason. This forked >> process does have to be terminated when all TestCases have finished of >> course (when the TestResource does #tearDown). >> >> IFF the forked processes should be kept alive during the execution of all >> TestCase methods, does the suggested solution above seem logical or are >> there any (better) alternatives? >> >> Regards, >> Erik >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >>

June 12, 2019

Re: [Pharo-users] TestCases and forked processes in TestResource don't play well

by Denis Kudriashov

Hi Eric. You can override #runCaseManaged on your test case: MyTestCase>>runCaseManaged self runCase It will disable all clever logic. ÑÑ, 12 Ð¸ÑÐ½. 2019 Ð³. Ð² 20:55, Erik Stel <erik.stel(a)gmail.com>: > Hi, > > I'm developing a web application using (amongst others) WebSockets. To > prevent test methods from becoming too big and slow I created a TestCase > with a TestResource containing my web application instance. After the first > test method is run, the WebSocket is closed unexpectedly and automagically. > It turns out that all forked processes are terminated when a TestCase has > executed a test method. What would be the proper way to prevent these > forked > processes from terminating after a single test method? Or am I missing > something/doing something wrong? > > TestExecutionEnvironment>>#checkForkedProcesses is responsible for > terminating any (non failed) processes. It is executed after > TestExecutionEnvironment>>#runTestCaseSafelly: [sic: this should be > #runTestCaseSafely:]. A possible solution might be to check whether the > Context in which a forked process was created has the #setUp method of a > TestResource of the TestCase (you still with me ;-) in its Context chain. > If > that is the case, the process is probably forked for a reason. This forked > process does have to be terminated when all TestCases have finished of > course (when the TestResource does #tearDown). > > IFF the forked processes should be kept alive during the execution of all > TestCase methods, does the suggested solution above seem logical or are > there any (better) alternatives? > > Regards, > Erik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

June 12, 2019

TestCases and forked processes in TestResource don't play well

by Erik Stel

Hi, I'm developing a web application using (amongst others) WebSockets. To prevent test methods from becoming too big and slow I created a TestCase with a TestResource containing my web application instance. After the first test method is run, the WebSocket is closed unexpectedly and automagically. It turns out that all forked processes are terminated when a TestCase has executed a test method. What would be the proper way to prevent these forked processes from terminating after a single test method? Or am I missing something/doing something wrong? TestExecutionEnvironment>>#checkForkedProcesses is responsible for terminating any (non failed) processes. It is executed after TestExecutionEnvironment>>#runTestCaseSafelly: [sic: this should be #runTestCaseSafely:]. A possible solution might be to check whether the Context in which a forked process was created has the #setUp method of a TestResource of the TestCase (you still with me ;-) in its Context chain. If that is the case, the process is probably forked for a reason. This forked process does have to be terminated when all TestCases have finished of course (when the TestResource does #tearDown). IFF the forked processes should be kept alive during the execution of all TestCase methods, does the suggested solution above seem logical or are there any (better) alternatives? Regards, Erik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 12, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Stephan Eggermont

Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > On 11/06/2019 18:07, Stephan Eggermont wrote: >> Konrad Hinsen <konrad.hinsen(a)fastmail.net> >> wrote: >> : >>> . To make this >>> effective, you have to think a bit about good data management >>> strategies. Few people will want to mirror all the history of Pharo. >> Why? Fits on an SD card in a raspberry pi > > > All of http://files.pharo.org/ ? So how many GB is that? It is only a few thousand changes per release. There is no reason why that shouldnât compress well Stephan

June 12, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Konrad Hinsen

On 11/06/2019 18:07, Stephan Eggermont wrote: > Konrad Hinsen <konrad.hinsen(a)fastmail.net> > wrote: > : >> . To make this >> effective, you have to think a bit about good data management >> strategies. Few people will want to mirror all the history of Pharo. > Why? Fits on an SD card in a raspberry pi All of http://files.pharo.org/ ? So how many GB is that? Konrad.

June 12, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Stephan Eggermont

Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: : > . To make this > effective, you have to think a bit about good data management > strategies. Few people will want to mirror all the history of Pharo. Why? Fits on an SD card in a raspberry pi Stephan

June 11, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Konrad Hinsen

serge.stinckwich(a)gmail.com writes: > I would like something like that for Pharo images. Can you sync > files.pharo.org on ipfs ? That should be straightforward using nothing but the IPFS command-line client. But it's worth thinking about the goals. What are you trying to improve exactly? The main advantage that IPFS provides is the possibility to create full or partial mirrors of the data (and thus faster access), including on your personal machine. To make this effective, you have to think a bit about good data management strategies. Few people will want to mirror all the history of Pharo. So you have to make interesting subcollections available under permanent names (via IPNS). Konrad.

June 11, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Marcus Denker

> On 11 Jun 2019, at 13:34, serge.stinckwich(a)gmail.com wrote: > > I would like something like that for Pharo images. Can you sync files.pharo.org <http://files.pharo.org/> on ipfs ? > Yes, that would be the first step. We could even use this: https://blog.cloudflare.com/distributed-web-gateway/ > Sent from my iPhone > > On 11 Jun 2019, at 17:00, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> >> >>> On 6 Jun 2019, at 19:37, Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: >>> >>> >>> >>> On Thu, Jun 6, 2019 at 6:35 PM Konrad Hinsen <konrad.hinsen(a)fastmail.net <mailto:konrad.hinsen@fastmail.net>> wrote: >>> Hi everyone, >>> >>> Over the last weeks I have started to explore IPFS more seriously. >>> IPFS, the Inter-Planetary File System, is supposed to be the >>> next-generation Web: a decentralized content-addressed database. >>> >>> Since there is nothing better then Pharo for exploring databases, >>> I have started to write an IPFS interface to Pharo: >>> >>> https://github.com/khinsen/ipfs-pharo <https://github.com/khinsen/ipfs-pharo> >>> >>> It connects to a local IPFS server, so you have to have one >>> running. It's surprisingly straightforward to install and configure, >>> unless you have to fight with firewalls that block IPFS traffic. >>> >>> >>> Great work ! I think Marcus was interested to have something like that. >> >> yes! >> >> IPFS has nice properties for many thingsâ¦ e.g. one simple things to try is to distribute images via IPFSâ¦ it has all the >> propose of Bittorrent for that. Imagine your case in Africaâ¦ very nice for that already. >> >> >> Marcus

June 11, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by serge.stinckwich＠gmail.com

I would like something like that for Pharo images. Can you sync files.pharo.org on ipfs ? Sent from my iPhone > On 11 Jun 2019, at 17:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 6 Jun 2019, at 19:37, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> >> >> >> On Thu, Jun 6, 2019 at 6:35 PM Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: >>> Hi everyone, >>> >>> Over the last weeks I have started to explore IPFS more seriously. >>> IPFS, the Inter-Planetary File System, is supposed to be the >>> next-generation Web: a decentralized content-addressed database. >>> >>> Since there is nothing better then Pharo for exploring databases, >>> I have started to write an IPFS interface to Pharo: >>> >>> https://github.com/khinsen/ipfs-pharo >>> >>> It connects to a local IPFS server, so you have to have one >>> running. It's surprisingly straightforward to install and configure, >>> unless you have to fight with firewalls that block IPFS traffic. >>> >> >> Great work ! I think Marcus was interested to have something like that. > > yes! > > IPFS has nice properties for many thingsâ¦ e.g. one simple things to try is to distribute images via IPFSâ¦ it has all the > propose of Bittorrent for that. Imagine your case in Africaâ¦ very nice for that already. > > > Marcus

June 11, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Marcus Denker

> On 6 Jun 2019, at 19:37, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > > On Thu, Jun 6, 2019 at 6:35 PM Konrad Hinsen <konrad.hinsen(a)fastmail.net <mailto:konrad.hinsen@fastmail.net>> wrote: > Hi everyone, > > Over the last weeks I have started to explore IPFS more seriously. > IPFS, the Inter-Planetary File System, is supposed to be the > next-generation Web: a decentralized content-addressed database. > > Since there is nothing better then Pharo for exploring databases, > I have started to write an IPFS interface to Pharo: > > https://github.com/khinsen/ipfs-pharo <https://github.com/khinsen/ipfs-pharo> > > It connects to a local IPFS server, so you have to have one > running. It's surprisingly straightforward to install and configure, > unless you have to fight with firewalls that block IPFS traffic. > > > Great work ! I think Marcus was interested to have something like that. yes! IPFS has nice properties for many thingsâ¦ e.g. one simple things to try is to distribute images via IPFSâ¦ it has all the propose of Bittorrent for that. Imagine your case in Africaâ¦ very nice for that already. Marcus

June 11, 2019