May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] [Ann] Some new iceberg videos

by Guillermo Polito

On Thu, May 24, 2018 at 9:51 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi Tim, > > On Wed, May 23, 2018 at 6:32 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Guille - the text reads very well, Iâll try and look at the videos later. >> > > Good! > > >> I just submitted a PR to pharo to try and get the contributions text >> pointing to the ânewer wayâ so that people donât get off track (like we did >> earlier this week). >> > > Yes I saw it :) > >> >> (Aside: Its quite nice having these docs in GitHub as does make it easier >> to propose fixes that people can review and accept/comment on). >> > > I'll paste my mail in some readme/iceberg wiki ;) > > >> >> Presumably those how to contribute docs should then also link to the >> below, so you also realise how you can help with Iceberg as well? And >> possibly those videos might also be helpful on the more generic - how to >> contribute to pharo (in general). >> >> By the way - this video - https://www.youtube.com/watc >> h?v=c0IgIT2s6Js&feature=youtu.be has a very low quality compare to the >> others. I think maybe a setting was wrong when it was uploaded? >> > > Ah that's probably my fault. The video editor I'm using has some ugly > defaults and I may have forgotten to change the export options for this > one? I'll check and replace the video. > I've uploaded a new version with better quality to https://www.youtube.com/watch?v=DBzkjwABPEI and marked the old one as deprecated, pointing to the new one (can't replace videos in youtube...). > > Thanks! > > >> >> Tim >> >> On 23 May 2018, at 17:09, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Hi all, >> >> This time (just before releasing a new version of iceberg) I wanted to >> share some videos with you. >> Feedback is welcome. >> >> !! How to contribute to Iceberg >> https://youtu.be/yGr5HvVWM0M >> >> This video shows how to contribute to iceberg. >> For this, you should update your iceberg installation and then just do a >> pull request. >> This means that you need to start by forking >> https://github.com/pharo-vcs/iceberg >> >> - Path 1: Clone and pull (easy) >> - Clone your fork >> - Checkout the latest development branch (e.g., dev-0.7) >> - Pull from pharo-vcs/iceberg >> >> This path does not always work, as this is kind of self-brain surgery. >> Iceberg is updating itself. >> If this does not work, go to path 2 >> >> - Path 2: Install from scratch (if Path 1 does not work) >> - Use the script in the README file to unload and reinstall iceberg >> - Make sure you use the latest development branch in the Metacello >> script (e.g., dev-0.7) >> - Clone your fork and checkout the development branch >> >> Once you have the correct version, you can load the tests by loading the >> development group of the baseline. >> >> >> !! Basic Branching and Merging >> https://youtu.be/c0IgIT2s6Js >> >> This video shows in a simple example how to branch, merge and checkout >> different commits. >> In this video we first create a new class with a method, then we create >> another branch and force a conflict. We resolve the conflict during merge. >> >> In the middle, bonus feature, we checked out a commit and stayed in >> Detached HEAD for a while ;) >> >> !! Loading a baseline from your repository >> https://youtu.be/brUHEOr-p_E >> >> This video shows how to load a baseline from Iceberg's UI. >> We clone an existing project, see it is "Not loaded" and use Metacello >> plugin to load the default group. >> >> Enjoy, >> Guille >> >> PS: Tomorrow I'll answer the threads about Iceberg that were going around >> here in the mailing list. I was running today. >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 24, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Some new iceberg videos

by Guillermo Polito

Hi Tim, On Wed, May 23, 2018 at 6:32 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Guille - the text reads very well, Iâll try and look at the videos later. > Good! > I just submitted a PR to pharo to try and get the contributions text > pointing to the ânewer wayâ so that people donât get off track (like we did > earlier this week). > Yes I saw it :) > > (Aside: Its quite nice having these docs in GitHub as does make it easier > to propose fixes that people can review and accept/comment on). > I'll paste my mail in some readme/iceberg wiki ;) > > Presumably those how to contribute docs should then also link to the > below, so you also realise how you can help with Iceberg as well? And > possibly those videos might also be helpful on the more generic - how to > contribute to pharo (in general). > > By the way - this video - https://www.youtube.com/ > watch?v=c0IgIT2s6Js&feature=youtu.be has a very low quality compare to > the others. I think maybe a setting was wrong when it was uploaded? > Ah that's probably my fault. The video editor I'm using has some ugly defaults and I may have forgotten to change the export options for this one? I'll check and replace the video. Thanks! > > Tim > > On 23 May 2018, at 17:09, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi all, > > This time (just before releasing a new version of iceberg) I wanted to > share some videos with you. > Feedback is welcome. > > !! How to contribute to Iceberg > https://youtu.be/yGr5HvVWM0M > > This video shows how to contribute to iceberg. > For this, you should update your iceberg installation and then just do a > pull request. > This means that you need to start by forking https://github.com/pharo-vcs/ > iceberg > > - Path 1: Clone and pull (easy) > - Clone your fork > - Checkout the latest development branch (e.g., dev-0.7) > - Pull from pharo-vcs/iceberg > > This path does not always work, as this is kind of self-brain surgery. > Iceberg is updating itself. > If this does not work, go to path 2 > > - Path 2: Install from scratch (if Path 1 does not work) > - Use the script in the README file to unload and reinstall iceberg > - Make sure you use the latest development branch in the Metacello > script (e.g., dev-0.7) > - Clone your fork and checkout the development branch > > Once you have the correct version, you can load the tests by loading the > development group of the baseline. > > > !! Basic Branching and Merging > https://youtu.be/c0IgIT2s6Js > > This video shows in a simple example how to branch, merge and checkout > different commits. > In this video we first create a new class with a method, then we create > another branch and force a conflict. We resolve the conflict during merge. > > In the middle, bonus feature, we checked out a commit and stayed in > Detached HEAD for a while ;) > > !! Loading a baseline from your repository > https://youtu.be/brUHEOr-p_E > > This video shows how to load a baseline from Iceberg's UI. > We clone an existing project, see it is "Not loaded" and use Metacello > plugin to load the default group. > > Enjoy, > Guille > > PS: Tomorrow I'll answer the threads about Iceberg that were going around > here in the mailing list. I was running today. > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 24, 2018

Re: [Pharo-users] GIFReadWriter and Animated GIFs

by Guillermo Polito

Big thanks :) If you have any question regarding the stream changes, go on On Wed, May 23, 2018 at 10:52 PM, Eric Gade <eric.gade(a)gmail.com> wrote: > Thanks, Sven. I'll switch over to Pharo 7a and continue my efforts there. > When I have something worth a damn I'll submit a PR according to the new > contribution protocol. > > On Wed, May 23, 2018 at 4:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi Eric, >> >> I can't speak about the Morph related aspects, not my area of expertise. >> >> The other aspects, about the actual read/writer, all sound reasonable. >> >> It would be very good if someone contributed to improve the quality of >> GIFReadWriter, thanks for doing this ! >> >> One remark though, I think that your changes are based off Pharo 6. That >> is a problem because GIFReadWriter underwent a couple of changes in >> relation to stream/file handling. I see some small conflicts in >> #readHeader, nothing major. >> >> I also assume the transcript printing will be removed eventually. >> >> Normally development takes place in Pharo 7 with an option to back port >> to Pharo 6.1 if it is a very important change. These kind of discussions >> also normally happen on the pharo-dev mailing list. >> >> Thanks again and please continue. >> >> Sven >> >> PS: maybe you can find a GIF test suite somewhere like there exists one >> for PNG (https://pharo.manuscript.com/f/cases/21927/Figure-out-why-P >> NGReadWriter-does-not-pass-a-full-test-suite and >> https://github.com/DraagrenKirneh/PngSuiteExplorer) >> >> > On 23 May 2018, at 21:08, Eric Gade <eric.gade(a)gmail.com> wrote: >> > >> > Hello all, >> > >> > Please excuse the length of this email. >> > >> > A week or two ago I discovered that the GIF implementation in Pharo >> (and possibly Squeak?) is incomplete. This has two side effects: >> > 1) Not all GIF data will load correctly; >> > 2) There is for now no way to display animated GIFs. >> > >> > It looks like the corresponding classes have not been updated since the >> 90s. >> > >> > But fear not! I've been working on a solution, and need the community's >> feedback and advice. >> > >> > # The Problem with GIFs # >> > One of the issues here is that GIF files can (and do) contain multiple >> images inside of them. The root header will supply things like a "screen >> size" in which these nested images should be displayed. That also means >> that each nested image does not have to have the same dimensions as the >> parent object -- in fact, most are offset somewhere inside of the "screen." >> > >> > Additionally, each nested image will contain information about how it >> should be handled when animating. This is a crucial point. In many cases >> images are just updates of a small area that should be applied to the >> previous image in the set. GIFs call this attribute the "disposal," and >> this information is contained in a packed byte. >> > >> > Both GIFReadWriter and AnimatedGIFReadWriter have intentionally >> skipped/ignored the bits/bytes that store and keep track of these things. >> GIFReadWriter on its own will only read the first Form and does not store >> information about disposal, offsets, etc. These classes are not reading all >> the information we need to display GIFs! >> > >> > # My Solution # >> > The attached changes file includes some preliminary updates to the >> GIFReadWriter class. Now when each nested image is read, it will be loaded >> into a collection called "frames" as a (new -- see attached package file) >> AnimatedImageFrame. Instances of this new class will store the disposal >> symbol, offset, and form for each nested image in the file. >> > >> > I have also created an AnimatedImageMorph which reads >> AnimatedImageFrame objects and cycles them based on the disposal re-drawing >> rules. >> > >> > # Trying This Out # >> > To try this out, first load the attached changes file and the ST file. >> > >> > You'll need a FileReference to a gif file, so when you have one execute >> the following: >> > >> > ```smalltalk >> > file := "your gif filereference here" >> > img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter >> formsFromStream: file readStream). >> > img openInWorld. >> > ``` >> > >> > # Issues # >> > Not all GIF images work. This has to do with my implementation of the >> disposal (redrawing) rules for each frame. I'm still experimenting. >> > >> > I believe AnimatedGIFReadWriter should be deprecated and all >> appropriate functionality should be put into GIFReadWriter. If you all >> agree, I will make several changes to GIFReadWriter that I think will be >> helpful / necessary. >> > >> > AnimatedImageMorph is also incomplete. I'm not sure if I should >> subclass ImageMorph for this or not. >> > >> > # Your Feedback # >> > If you disagree with any point of this architecture, please let me >> know. Also if you come across GIFs that do not animate or display properly, >> send them my way please! >> > >> > -- >> > Eric >> > <Images-Animated.st><GIFReadWriter.EricGade.cs> >> >> >> > > > -- > Eric > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 24, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by David T. Lewis

Hi Mariano, hi Thierry, I cannot follow up for a few days but I like Mariano's proposal and I think that it will work. Maybe move the child reaper process to a small OSChildWatcher class and have interested clients (OSP, OSSP, others) subscribe to update notifications. Dave > Hi Thierry. Excellent question. For OSSubprocess this is not an issue > because I look up by pid in my list of forked children... So if not found > I > do nothing... At least that's what I remember (away from my machine now). > So at worst it would be a performance problem when both loaded. > > As for osprocess I don't recall if this would be a problem but I imagine > it > won't. Maybe David can tell. > > > On Wed, May 23, 2018, 5:31 PM Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> Hi Mariano, >> >> 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck >> <marianopeck(a)gmail.com>: >> > >> > >> > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris >> <sean(a)clipperadams.com> >> > wrote: >> >> >> >> David T. Lewis wrote >> >> > FFI based solutions work at a different level of abstraction than >> >> > VM plugins, and there is a role for both. >> >> >> >> Thanks for the context, David. Now that we understand the different >> >> niches, >> >> the main problem is that they can not be loaded in the same image >> without >> >> breaking :/ >> >> >> > >> > The problem is to find a solution that works for both, Squeak and >> Pharo >> as >> > well as for OSProcess and OSSubprocess. >> > >> > I guess one possibility is to modify both, OSProcess and OSSubprocess >> > initialization of the child reaper so that they install the same >> "generic" >> > child reapear. Aside from initializating the child repear, they should >> be >> > added into an "observer list". When, when it comes the second project >> to >> get >> > loaded it which check that a child reaper is already registered..in >> which >> > case he just register itself as "observer". >> > >> > This child reaper should be generic enough (cannot be coupled to WHAT >> to do >> > when the semaphore is signaled). Using Announcements (or other >> mechanisim >> > that would work for Pharo and Squeak) we could simply "notify" the >> > registered observers and each observer would do whatever is needed >> (what >> is >> > actually now hardcoded in each child reaper) >> > >> > Maybe that works...just an idea. >> >> I think that looks like a nice design. Just one question: do we need >> to track down whether the child reaper event should be directed to >> OSProcess or to OSSubprocess? Wondering if there is an issue with one >> of them trying to close the other one's resource (but I haven't >> checked, so I may be wrong). >> >> >> >> Thierry >> >> > >> >> >> >> >> >> >> >> ----- >> >> Cheers, >> >> Sean >> >> -- >> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> >> >

May 24, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Mariano Martinez Peck

Hi Thierry. Excellent question. For OSSubprocess this is not an issue because I look up by pid in my list of forked children... So if not found I do nothing... At least that's what I remember (away from my machine now). So at worst it would be a performance problem when both loaded. As for osprocess I don't recall if this would be a problem but I imagine it won't. Maybe David can tell. On Wed, May 23, 2018, 5:31 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Mariano, > > 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris <sean(a)clipperadams.com> > > wrote: > >> > >> David T. Lewis wrote > >> > FFI based solutions work at a different level of abstraction than > >> > VM plugins, and there is a role for both. > >> > >> Thanks for the context, David. Now that we understand the different > >> niches, > >> the main problem is that they can not be loaded in the same image > without > >> breaking :/ > >> > > > > The problem is to find a solution that works for both, Squeak and Pharo > as > > well as for OSProcess and OSSubprocess. > > > > I guess one possibility is to modify both, OSProcess and OSSubprocess > > initialization of the child reaper so that they install the same > "generic" > > child reapear. Aside from initializating the child repear, they should be > > added into an "observer list". When, when it comes the second project to > get > > loaded it which check that a child reaper is already registered..in which > > case he just register itself as "observer". > > > > This child reaper should be generic enough (cannot be coupled to WHAT > to do > > when the semaphore is signaled). Using Announcements (or other mechanisim > > that would work for Pharo and Squeak) we could simply "notify" the > > registered observers and each observer would do whatever is needed (what > is > > actually now hardcoded in each child reaper) > > > > Maybe that works...just an idea. > > I think that looks like a nice design. Just one question: do we need > to track down whether the child reaper event should be directed to > OSProcess or to OSSubprocess? Wondering if there is an issue with one > of them trying to close the other one's resource (but I haven't > checked, so I may be wrong). > > > > Thierry > > > > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > >

May 23, 2018

Re: [Pharo-users] GIFReadWriter and Animated GIFs

by Eric Gade

Thanks, Sven. I'll switch over to Pharo 7a and continue my efforts there. When I have something worth a damn I'll submit a PR according to the new contribution protocol. On Wed, May 23, 2018 at 4:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Eric, > > I can't speak about the Morph related aspects, not my area of expertise. > > The other aspects, about the actual read/writer, all sound reasonable. > > It would be very good if someone contributed to improve the quality of > GIFReadWriter, thanks for doing this ! > > One remark though, I think that your changes are based off Pharo 6. That > is a problem because GIFReadWriter underwent a couple of changes in > relation to stream/file handling. I see some small conflicts in > #readHeader, nothing major. > > I also assume the transcript printing will be removed eventually. > > Normally development takes place in Pharo 7 with an option to back port to > Pharo 6.1 if it is a very important change. These kind of discussions also > normally happen on the pharo-dev mailing list. > > Thanks again and please continue. > > Sven > > PS: maybe you can find a GIF test suite somewhere like there exists one > for PNG (https://pharo.manuscript.com/f/cases/21927/Figure-out-why- > PNGReadWriter-does-not-pass-a-full-test-suite and https://github.com/ > DraagrenKirneh/PngSuiteExplorer). > > > On 23 May 2018, at 21:08, Eric Gade <eric.gade(a)gmail.com> wrote: > > > > Hello all, > > > > Please excuse the length of this email. > > > > A week or two ago I discovered that the GIF implementation in Pharo (and > possibly Squeak?) is incomplete. This has two side effects: > > 1) Not all GIF data will load correctly; > > 2) There is for now no way to display animated GIFs. > > > > It looks like the corresponding classes have not been updated since the > 90s. > > > > But fear not! I've been working on a solution, and need the community's > feedback and advice. > > > > # The Problem with GIFs # > > One of the issues here is that GIF files can (and do) contain multiple > images inside of them. The root header will supply things like a "screen > size" in which these nested images should be displayed. That also means > that each nested image does not have to have the same dimensions as the > parent object -- in fact, most are offset somewhere inside of the "screen." > > > > Additionally, each nested image will contain information about how it > should be handled when animating. This is a crucial point. In many cases > images are just updates of a small area that should be applied to the > previous image in the set. GIFs call this attribute the "disposal," and > this information is contained in a packed byte. > > > > Both GIFReadWriter and AnimatedGIFReadWriter have intentionally > skipped/ignored the bits/bytes that store and keep track of these things. > GIFReadWriter on its own will only read the first Form and does not store > information about disposal, offsets, etc. These classes are not reading all > the information we need to display GIFs! > > > > # My Solution # > > The attached changes file includes some preliminary updates to the > GIFReadWriter class. Now when each nested image is read, it will be loaded > into a collection called "frames" as a (new -- see attached package file) > AnimatedImageFrame. Instances of this new class will store the disposal > symbol, offset, and form for each nested image in the file. > > > > I have also created an AnimatedImageMorph which reads AnimatedImageFrame > objects and cycles them based on the disposal re-drawing rules. > > > > # Trying This Out # > > To try this out, first load the attached changes file and the ST file. > > > > You'll need a FileReference to a gif file, so when you have one execute > the following: > > > > ```smalltalk > > file := "your gif filereference here" > > img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter > formsFromStream: file readStream). > > img openInWorld. > > ``` > > > > # Issues # > > Not all GIF images work. This has to do with my implementation of the > disposal (redrawing) rules for each frame. I'm still experimenting. > > > > I believe AnimatedGIFReadWriter should be deprecated and all appropriate > functionality should be put into GIFReadWriter. If you all agree, I will > make several changes to GIFReadWriter that I think will be helpful / > necessary. > > > > AnimatedImageMorph is also incomplete. I'm not sure if I should subclass > ImageMorph for this or not. > > > > # Your Feedback # > > If you disagree with any point of this architecture, please let me know. > Also if you come across GIFs that do not animate or display properly, send > them my way please! > > > > -- > > Eric > > <Images-Animated.st><GIFReadWriter.EricGade.cs> > > > -- Eric

May 23, 2018

Re: [Pharo-users] GIFReadWriter and Animated GIFs

by Sven Van Caekenberghe

Hi Eric, I can't speak about the Morph related aspects, not my area of expertise. The other aspects, about the actual read/writer, all sound reasonable. It would be very good if someone contributed to improve the quality of GIFReadWriter, thanks for doing this ! One remark though, I think that your changes are based off Pharo 6. That is a problem because GIFReadWriter underwent a couple of changes in relation to stream/file handling. I see some small conflicts in #readHeader, nothing major. I also assume the transcript printing will be removed eventually. Normally development takes place in Pharo 7 with an option to back port to Pharo 6.1 if it is a very important change. These kind of discussions also normally happen on the pharo-dev mailing list. Thanks again and please continue. Sven PS: maybe you can find a GIF test suite somewhere like there exists one for PNG (https://pharo.manuscript.com/f/cases/21927/Figure-out-why-PNGReadWriter-doe… and https://github.com/DraagrenKirneh/PngSuiteExplorer) > On 23 May 2018, at 21:08, Eric Gade <eric.gade(a)gmail.com> wrote: > > Hello all, > > Please excuse the length of this email. > > A week or two ago I discovered that the GIF implementation in Pharo (and possibly Squeak?) is incomplete. This has two side effects: > 1) Not all GIF data will load correctly; > 2) There is for now no way to display animated GIFs. > > It looks like the corresponding classes have not been updated since the 90s. > > But fear not! I've been working on a solution, and need the community's feedback and advice. > > # The Problem with GIFs # > One of the issues here is that GIF files can (and do) contain multiple images inside of them. The root header will supply things like a "screen size" in which these nested images should be displayed. That also means that each nested image does not have to have the same dimensions as the parent object -- in fact, most are offset somewhere inside of the "screen." > > Additionally, each nested image will contain information about how it should be handled when animating. This is a crucial point. In many cases images are just updates of a small area that should be applied to the previous image in the set. GIFs call this attribute the "disposal," and this information is contained in a packed byte. > > Both GIFReadWriter and AnimatedGIFReadWriter have intentionally skipped/ignored the bits/bytes that store and keep track of these things. GIFReadWriter on its own will only read the first Form and does not store information about disposal, offsets, etc. These classes are not reading all the information we need to display GIFs! > > # My Solution # > The attached changes file includes some preliminary updates to the GIFReadWriter class. Now when each nested image is read, it will be loaded into a collection called "frames" as a (new -- see attached package file) AnimatedImageFrame. Instances of this new class will store the disposal symbol, offset, and form for each nested image in the file. > > I have also created an AnimatedImageMorph which reads AnimatedImageFrame objects and cycles them based on the disposal re-drawing rules. > > # Trying This Out # > To try this out, first load the attached changes file and the ST file. > > You'll need a FileReference to a gif file, so when you have one execute the following: > > ```smalltalk > file := "your gif filereference here" > img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter formsFromStream: file readStream). > img openInWorld. > ``` > > # Issues # > Not all GIF images work. This has to do with my implementation of the disposal (redrawing) rules for each frame. I'm still experimenting. > > I believe AnimatedGIFReadWriter should be deprecated and all appropriate functionality should be put into GIFReadWriter. If you all agree, I will make several changes to GIFReadWriter that I think will be helpful / necessary. > > AnimatedImageMorph is also incomplete. I'm not sure if I should subclass ImageMorph for this or not. > > # Your Feedback # > If you disagree with any point of this architecture, please let me know. Also if you come across GIFs that do not animate or display properly, send them my way please! > > -- > Eric > <Images-Animated.st><GIFReadWriter.EricGade.cs>

May 23, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Thierry Goubier

Hi Mariano, 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris <sean(a)clipperadams.com> > wrote: >> >> David T. Lewis wrote >> > FFI based solutions work at a different level of abstraction than >> > VM plugins, and there is a role for both. >> >> Thanks for the context, David. Now that we understand the different >> niches, >> the main problem is that they can not be loaded in the same image without >> breaking :/ >> > > The problem is to find a solution that works for both, Squeak and Pharo as > well as for OSProcess and OSSubprocess. > > I guess one possibility is to modify both, OSProcess and OSSubprocess > initialization of the child reaper so that they install the same "generic" > child reapear. Aside from initializating the child repear, they should be > added into an "observer list". When, when it comes the second project to get > loaded it which check that a child reaper is already registered..in which > case he just register itself as "observer". > > This child reaper should be generic enough (cannot be coupled to WHAT to do > when the semaphore is signaled). Using Announcements (or other mechanisim > that would work for Pharo and Squeak) we could simply "notify" the > registered observers and each observer would do whatever is needed (what is > actually now hardcoded in each child reaper) > > Maybe that works...just an idea. I think that looks like a nice design. Just one question: do we need to track down whether the child reaper event should be directed to OSProcess or to OSSubprocess? Wondering if there is an issue with one of them trying to close the other one's resource (but I haven't checked, so I may be wrong). Thierry > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > > > -- > Mariano > http://marianopeck.wordpress.com

May 23, 2018

GIFReadWriter and Animated GIFs

by Eric Gade

Hello all, Please excuse the length of this email. A week or two ago I discovered that the GIF implementation in Pharo (and possibly Squeak?) is incomplete. This has two side effects: 1) Not all GIF data will load correctly; 2) There is for now no way to display animated GIFs. It looks like the corresponding classes have not been updated since the 90s. But fear not! I've been working on a solution, and need the community's feedback and advice. # The Problem with GIFs # One of the issues here is that GIF files can (and do) contain multiple images inside of them. The root header will supply things like a "screen size" in which these nested images should be displayed. That also means that each nested image does not have to have the same dimensions as the parent object -- in fact, most are offset somewhere inside of the "screen." Additionally, each nested image will contain information about how it should be handled when animating. This is a crucial point. In many cases images are just updates of a small area that should be applied to the previous image in the set. GIFs call this attribute the "disposal," and this information is contained in a packed byte. Both GIFReadWriter and AnimatedGIFReadWriter have intentionally skipped/ignored the bits/bytes that store and keep track of these things. GIFReadWriter on its own will only read the first Form and does not store information about disposal, offsets, etc. These classes are not reading all the information we need to display GIFs! # My Solution # The attached changes file includes some preliminary updates to the GIFReadWriter class. Now when each nested image is read, it will be loaded into a collection called "frames" as a (new -- see attached package file) AnimatedImageFrame. Instances of this new class will store the disposal symbol, offset, and form for each nested image in the file. I have also created an AnimatedImageMorph which reads AnimatedImageFrame objects and cycles them based on the disposal re-drawing rules. # Trying This Out # To try this out, first load the attached changes file and the ST file. You'll need a FileReference to a gif file, so when you have one execute the following: ```smalltalk file := "your gif filereference here" img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter formsFromStream: file readStream). img openInWorld. ``` # Issues # Not all GIF images work. This has to do with my implementation of the disposal (redrawing) rules for each frame. I'm still experimenting. I believe AnimatedGIFReadWriter should be deprecated and all appropriate functionality should be put into GIFReadWriter. If you all agree, I will make several changes to GIFReadWriter that I think will be helpful / necessary. AnimatedImageMorph is also incomplete. I'm not sure if I should subclass ImageMorph for this or not. # Your Feedback # If you disagree with any point of this architecture, please let me know. Also if you come across GIFs that do not animate or display properly, send them my way please! -- Eric

May 23, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Mariano Martinez Peck

On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > David T. Lewis wrote > > FFI based solutions work at a different level of abstraction than > > VM plugins, and there is a role for both. > > Thanks for the context, David. Now that we understand the different niches, > the main problem is that they can not be loaded in the same image without > breaking :/ > > The problem is to find a solution that works for both, Squeak and Pharo as well as for OSProcess and OSSubprocess. I guess one possibility is to modify both, OSProcess and OSSubprocess initialization of the child reaper so that they install the same "generic" child reapear. Aside from initializating the child repear, they should be added into an "observer list". When, when it comes the second project to get loaded it which check that a child reaper is already registered..in which case he just register itself as "observer". This child reaper should be generic enough (cannot be coupled to WHAT to do when the semaphore is signaled). Using Announcements (or other mechanisim that would work for Pharo and Squeak) we could simply "notify" the registered observers and each observer would do whatever is needed (what is actually now hardcoded in each child reaper) Maybe that works...just an idea. > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Mariano http://marianopeck.wordpress.com

May 23, 2018