- Pharo-users - lists.pharo.org

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

by Konrad Hinsen

Stephan Eggermont <stephan(a)stack.nl> writes: >> 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 Did anybody try? In IPFS, files are cut into blocks of roughly 256 KB. Blocks shared between multiple files are stored only once. So if changes in Pharo images from one version to the next happen mainly in one or two specific places (such as beginning and end), they would be stored efficiently on IPFS without any effort. But again, the best way to know is to try it out. Konrad.

June 13, 2019

Re: [Pharo-users] Modeling HABTM

by sergio ruiz

Oh! i am trying to do everything in pharo/seaside.. i am not using a database at all.. i am working on getting this set up in gemstones, but i am still really confused in that area.. > On Jun 12, 2019, at 10:35 PM, Jeff Gray <jeff(a)rogerthedog.com> wrote: > > diagram, you may not need a class to model play. As it is just a repository > for a set of links I might just have a method on an Episode class that calls > the sql to return a collection of Tracks and vice versa. ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

June 13, 2019

Re: [Pharo-users] Modeling HABTM

by Jeff Gray

This may not be a very object thing to say but if you have a relational database with tables for episode, track and play like in Christopher's diagram, you may not need a class to model play. As it is just a repository for a set of links I might just have a method on an Episode class that calls the sql to return a collection of Tracks and vice versa. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 13, 2019

Re: [Pharo-users] How to render video frames?

by Aliaksei Syrel

Hi Rafael, Assuming you have your OpenCV camera frame object named image in BGR format (default for OpenCV) Here is how you can render it at high fps in Bloc (override *BlElement>>#* drawOnSpartaCanvas: aCanvas in a subclass) surface := aSpartaCanvas bitmap fromBGR: image imageData extent: image width @ image height stride: image widthStep. aSpartaCanvas fill paint: surface; path: surface bounds; draw Cheers, Alex On Wed, 12 Jun 2019 at 22:39, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > Hello, > > I'm experimenting with an integration between OpenCV and Pharo based on > uFFI. My native C library opens a video camera and captures frames for > detecting certain points (aka blobs) of interest for my use case. The data > for these frames are available to Pharo as uchar* inside a C struct. > > My issues came when I tried to render the video camera frames inside > Pharo. The C examples I developed for testing the shared library show > frames around 50-60 fps. However, the best I have got in Pharo is around > 15-20 fps. > > My first try consisted of writing an specific ImageReadWriter for the > OpenCV image format, so I can build a Form for each frame and render it > with Morphic. This way I can render the video camera in GTInspector, but at > a terrible 5-10 fps. > > The second try was to use Bloc to render the Forms. I though the Moz2D > backend will provider better performance. Indeed, I got around 15-20 fps, > but it is still insufficient for playing video smoothly. > > My current try consist of using BlExternalForm to avoid all the frame data > processing inside Pharo, but I'm finding problems to render this kind of > "shallow" Forms using Bloc. > > I've also find some old mails (2017) about ClÃ©ment Bera working in games > based on Cairo + SDL. Should I explore this approach for video rendering? > > In summary, I don't know what is the recommended approach (if any) to show > a sequence of video frames with decent bit-rate. > > Thank you! >

June 12, 2019

How to render video frames?

by Rafael Luque

Hello, I'm experimenting with an integration between OpenCV and Pharo based on uFFI. My native C library opens a video camera and captures frames for detecting certain points (aka blobs) of interest for my use case. The data for these frames are available to Pharo as uchar* inside a C struct. My issues came when I tried to render the video camera frames inside Pharo. The C examples I developed for testing the shared library show frames around 50-60 fps. However, the best I have got in Pharo is around 15-20 fps. My first try consisted of writing an specific ImageReadWriter for the OpenCV image format, so I can build a Form for each frame and render it with Morphic. This way I can render the video camera in GTInspector, but at a terrible 5-10 fps. The second try was to use Bloc to render the Forms. I though the Moz2D backend will provider better performance. Indeed, I got around 15-20 fps, but it is still insufficient for playing video smoothly. My current try consist of using BlExternalForm to avoid all the frame data processing inside Pharo, but I'm finding problems to render this kind of "shallow" Forms using Bloc. I've also find some old mails (2017) about ClÃ©ment Bera working in games based on Cairo + SDL. Should I explore this approach for video rendering? In summary, I don't know what is the recommended approach (if any) to show a sequence of video frames with decent bit-rate. Thank you!

June 12, 2019

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