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

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

by Sean P. DeNigris

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 :/ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018

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

by Sean P. DeNigris

Mariano Martinez Peck wrote > From what I understand/remember/believe, the main reasons for > building OSSubprocess were: Thanks, Mariano!! Very informative :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018

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

by Mariano Martinez Peck

Hi guys, First, I would like to say that David was always very helpful, positive and we have discussed and worked together a lot for this. When I was sponsored to build OSSubprocess I already got the "we would like this have this", so maybe some additional opinion from the ESUG board may help clarify. From what I understand/remember/believe, the main reasons for building OSSubprocess were: 1) *FFI-based tool*. Low the barrier of having to modify the VM to make a fix. Despite all our efforts, we still have way more people able to deal with FFI than with the VM. Even more if the VM is now shared under a common project, in which is not always easy to plug Pharo-specific stuff. 2) *Cleaner/nicer API*. You may or may not agree with this and that's perfect (we all have different opinions). When I was using OSProcess I always thought the API was not as I would like to, so my goal was to provide a API closer to my wishes. Again, not necessary better. 3) *Smaller functionality than OSProcess*: OSProcess is huge...it allows you to fork squeak images, fork() + exec*() whatever you want, runs on Windows, etc. We wanted something smaller...just enough to be able to fork processes. That is... to capture the most common/easy process forking.. But if you really need something very advance, you may still go to bare metals and use OSProcess approach (fork + exec). 4) *Added infrastructure*. We wanted the project to be on Git, with a very detailed documentation, very high test coverage, and CI integration. ----- So...that is about the reasons... as to why it breaks when OSProcess is loaded to, it's because for OSSubprocess I took the wonderful idea from OSProcess of the child reaper. This is a process that runs on the Smalltalk side and handles exception (via semaphore) when the child has died. This is (currently) only possible thanks to OSProcess primitive. That means OSSubprocess still needs (one or very little) OSProcess primitives down in the VM. When you load either of the projects, they launch the child reaper process, register the semaphore etc etc. So the problem is when you loaded one and you then try to load the second one, the initialization of the second one you plug its own semaphore etc etc and so the previous gets broken as it doesn't have a working child reaper process. If someone has a better idea on how to solve this, then please speak up. Cheers, On Wed, May 23, 2018 at 11:12 AM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Guillermo Polito wrote > > I try not to depend on projects using OSProcess in that case. > > That is not exactly a robust solution! What is the only project providing > the functionality you need depends on OSP?! > > > Guillermo Polito wrote > > I understand that the incompatibilities bother, but putting all the fault > > in OSSubprocess and not in OSProcess seems not fair :) > > Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some > of its functionality just recently, so I'd say it's fair indeed! > > > Guillermo Polito wrote > > Maybe both should be modified to be compatible? > > Maybe. I don't really understand the source of the incompatibility well > enough. > > > Guillermo Polito wrote > > I found OSProcess API particularly bad. It's never clear to me whether to > > use OSProcess, PipeableSomething or CommandWhatever (I don't even > remember > > the names of the things that **do work** and I have to look them every > > time). > > The things you're describing are not accidental complexity, but the fact > that OSP (and its companion CommandShell) actually have a far wider feature > set than just simple commands. CommandShell makes many shell-like things > possible in-image, but one doesn't have to use or even know anything about > all that to do simple things. That said, every time I did into CS and see > all the things that are possible I am amazed. > > > Guillermo Polito wrote > > Most people only want to do > > output := OSProcess executeCommand: 'ls'. > > Blocking. Recovering stdout. And that's all. > > (PipeableOSProcess command: 'ls') output > > That doesn't seem horribly complex to do in OSP ;) > > > Guillermo Polito wrote > > Well from a technical point of view, if you want to choose from one or > > another today I'd sayâ¦ > > Ah, interesting and informative. Thank you. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Mariano http://marianopeck.wordpress.com

May 23, 2018

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

by Tim Mackinnon

Guille - the text reads very well, Iâll try and look at the videos later. 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). (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). 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 <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? 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 <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 <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 <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 <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.

May 23, 2018

[Ann] Some new iceberg videos

by Guillermo Polito

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.

May 23, 2018

Re: [Pharo-users] On UDP broadcast

by N. Bouraqadi

Note that the package includes tests that show that the broadcast working :-) Thanx CÃ©drick for the CC. Noury > On 21 May 2018, at 21:17, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Noury did. He sent that on the other thread : > > Â« Just want to point that I did some work late 2017 on UDP sockets including multicast and broadcast. > The package named 'NetworkExtras' is part of the ReusableBricks repo of my team. > http://smalltalkhub.com/#!/~CAR/ReusableBricks <http://smalltalkhub.com/#!/~CAR/ReusableBricks> > It has some dependencies on other packages. Â» > > It may help. I cc Noury. > > Cheers, > > CÃ©drick > > Le 21 mai 2018 Ã 20:00, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> a Ã©crit : > >> >> >>> On 21 May 2018, at 19:37, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >>> >>> Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote:. >>>> >>>> I can't get the broadcast sending via nc to work (like your terminal >>>> example). The -b nc option on macOS is not related to broadcasting. >>> >>> Whoâs allowed to broadcast? >> >> Yes, I vaguely remember that Unix permissions are involved, I just don't know how this works exactly. >> >>> Stephan >>> >>> >> >>

May 23, 2018

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

by David T. Lewis

On Wed, May 23, 2018 at 07:11:29AM -0700, Sean P. DeNigris wrote: > Guillermo Polito wrote > > I try not to depend on projects using OSProcess in that case. > > That is not exactly a robust solution! What is the only project providing > the functionality you need depends on OSP?! > > > Guillermo Polito wrote > > I understand that the incompatibilities bother, but putting all the fault > > in OSSubprocess and not in OSProcess seems not fair :) > > Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some > of its functionality just recently, so I'd say it's fair indeed! > Actually, OSProcess was born in 1999 :-) First announcement: http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/016553.html And this appears to be where I first starting thinking about the problem: http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-January/025236.… http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-May/023712.html Kudos to Mariano for working closely with me as he developed the FFI based functionality in OSSP, he did a really good job of working out issues wherever possible. FFI based solutions work at a different level of abstraction than VM plugins, and there is a role for both. Dave

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

Hi Henry, > [...] it might be possible to try to do this with FFI only? If I understand you correctly, I could use FFI to call an external lib to perform the actual computation according to the rounding mode, right? In this case I'd be worry about the performance impact of many FFI calls. > For the same reason, I hope you intend roundByMethodXWhile: to be a > mandatory API, forgetting to set the mode back when done (or, never > getting > there due to errors, etc) is an area best left unexplored ;) I used roundByMethodXWhile: aBlock just to convey the idea that an API could work "local" and ensures resetting the rounding mode afterwards. =) Best, Steffen

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

I'll cross-post there later. Thanks for the suggestion! The application I have in mind is approximation algorithms for systems of linear equations or linear programs. Approximation algorithms, such as the power method, typically run until convergence of the solution vector is reached. However, determining convergence is usually done by computing the difference (epsilon) between the last two solutions and comparing it to some threshold. This may work in some cases but not in general, as the intermediate epsilon does not tell the distance to the actual solution. Interval iteration tackles this problem by approaching the solution from above and below. The difference between the upper and lower solution bounds determines the quality of the solution. However, if we use imprecise arithmetic (floats, doubles) it is important to round down/up in computing the lower/upper bounds. Best, Steffen Am .05.2018, 12:50 Uhr, schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Wed, May 23, 2018 at 11:47 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> *bump* >> >> I guess there no way to do this now. But maybe a VM guy can give me how >> difficult it might be to extend the VM accordingly. >> >> > âYes you should followup this question to the VM mailing-list. > Can you open an issue here: > https://github.com/PolyMathOrg/PolyMath/issues > so we don't forget about it ?â > > âDo you have specific needs behind this ?â

May 23, 2018

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

by Sean P. DeNigris

Guillermo Polito wrote > I try not to depend on projects using OSProcess in that case. That is not exactly a robust solution! What is the only project providing the functionality you need depends on OSP?! Guillermo Polito wrote > I understand that the incompatibilities bother, but putting all the fault > in OSSubprocess and not in OSProcess seems not fair :) Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some of its functionality just recently, so I'd say it's fair indeed! Guillermo Polito wrote > Maybe both should be modified to be compatible? Maybe. I don't really understand the source of the incompatibility well enough. Guillermo Polito wrote > I found OSProcess API particularly bad. It's never clear to me whether to > use OSProcess, PipeableSomething or CommandWhatever (I don't even remember > the names of the things that **do work** and I have to look them every > time). The things you're describing are not accidental complexity, but the fact that OSP (and its companion CommandShell) actually have a far wider feature set than just simple commands. CommandShell makes many shell-like things possible in-image, but one doesn't have to use or even know anything about all that to do simple things. That said, every time I did into CS and see all the things that are possible I am amazed. Guillermo Polito wrote > Most people only want to do > output := OSProcess executeCommand: 'ls'. > Blocking. Recovering stdout. And that's all. (PipeableOSProcess command: 'ls') output That doesn't seem horribly complex to do in OSP ;) Guillermo Polito wrote > Well from a technical point of view, if you want to choose from one or > another today I'd sayâ¦ Ah, interesting and informative. Thank you. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Henrik Sperre Johansen

fesetround()/fegetround() are part of C99, and amazingly, also present in the Windows CRT, it might be possible to try to do this with FFI only? IIRC the numerical model is supposed to act identical across platforms; whether it would actually affect anything depends on how the VM achieves that; I assume it's done by explicitly setting fp state to be identical (including rounding mode), rather than using some library which avoids x87/sse ops entirely, but I haven't actually looked. For the same reason, I hope you intend roundByMethodXWhile: to be a mandatory API, forgetting to set the mode back when done (or, never getting there due to errors, etc) is an area best left unexplored ;) Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

by Thierry Goubier

2018-05-23 15:28 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > > On Wed, May 23, 2018 at 6:42 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On 22 May 2018 at 23:23, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi - when trying out the new Iceberg with a bunch of developers and >>> explaining the challenges of integrating git and files into a smalltalk >>> realm of the image - there was a lot of interest in how this works. >>> >>> When you clone - you obviously see a series of files (in Tonel - nice) >>> that are then brought into your image. If you edit a file like Readme.md >>> (using a markdown editor) you will notice that git status will show you that >>> this file has changed. However if you then edit some methods - and then look >>> in the file system - git status doesnât show these? This in retrospect >>> possibly feels weird - or does it? Iâm not sure anymore - and was wondering >>> if there was a specific reason behind not mirroring code changes back to the >>> file system as they happen? >> >> >> I guess the conceptual model they have might be of Pharo as a text editor >> directly changing the files. >> Its interesting to consider how that would operate. Changes are >> immediately reflected in Epcia files, >> and used to be immediately written to ".changes" file, so it seems >> possible. > > > This is indeed valuable when things go wrong. At a point, I was considering using git as the changes file (every method save and compile in Pharo -> a commit in git) Didn't try to see if git would handle the load. >> More interesting is what to do if the text file is edited outside Pharo. >> If Pharo could observe this and then recompile the new file, >> we might suddenly have a workable "external editor" workflow, >> lack of which is a common complaint by some. > > > I don't believe that it should be Pharo's concern to waste effort on > supporting external editors -- it is throwing so much value of Pharo. > > That being said, until git conflicts can be resolved inside Pharo, it is > necessary to be able to edit the files by hand. The ability to run the > hand-resolved code without committing it (to verify it still works/compiles) > seems like a worthwhile feature. Good point. >> However if you then edit some methods - and then look in the file system - >> git status doesnât show these? This in retrospect possibly feels weird - or >> does it? > > > With Iceberg you have two separate working copies. It is not weird from git > perspective, however it is a rather unique setup -- even seasoned git users > might say... "You can do that? :-o" :) (And yes, it adds some extra cost, > but nothing is perfect.) I considered eliminating one of the working copy when in Pharo, by cloning repositories in RAW mode (without working tree). What you wrote (the git fast-import layer) allows you to do that. But, to be able to pull, you need to be able to be able to do a merge (and resolve conflicts)... in Pharo memory. Thierry > Peter

May 23, 2018

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

by Peter UhnÃ¡k

On Wed, May 23, 2018 at 6:42 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 22 May 2018 at 23:23, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - when trying out the new Iceberg with a bunch of developers and >> explaining the challenges of integrating git and files into a smalltalk >> realm of the image - there was a lot of interest in how this works. >> >> When you clone - you obviously see a series of files (in Tonel - nice) >> that are then brought into your image. If you edit a file like Readme.md >> (using a markdown editor) you will notice that git status will show you >> that this file has changed. However if you then edit some methods - and >> then look in the file system - git status doesnât show these? This in >> retrospect possibly feels weird - or does it? Iâm not sure anymore - and >> was wondering if there was a specific reason behind not mirroring code >> changes back to the file system as they happen? >> > > I guess the conceptual model they have might be of Pharo as a text editor > directly changing the files. > Its interesting to consider how that would operate. Changes are > immediately reflected in Epcia files, > and used to be immediately written to ".changes" file, so it seems > possible. > This is indeed valuable when things go wrong. > More interesting is what to do if the text file is edited outside Pharo. > If Pharo could observe this and then recompile the new file, > we might suddenly have a workable "external editor" workflow, > lack of which is a common complaint by some. > I don't believe that it should be Pharo's concern to waste effort on supporting external editors -- it is throwing so much value of Pharo. That being said, until git conflicts can be resolved inside Pharo, it is necessary to be able to edit the files by hand. The ability to run the hand-resolved code without committing it (to verify it still works/compiles) seems like a worthwhile feature. However if you then edit some methods - and then look in the file system - > git status doesnât show these? This in retrospect possibly feels weird - or > does it? > With Iceberg you have two separate working copies. It is not weird from git perspective, however it is a rather unique setup -- even seasoned git users might say... "You can do that? :-o" :) (And yes, it adds some extra cost, but nothing is perfect.) Peter

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Serge Stinckwich

On Wed, May 23, 2018 at 11:47 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > *bump* > > I guess there no way to do this now. But maybe a VM guy can give me how > difficult it might be to extend the VM accordingly. > > âYes you should followup this question to the VM mailing-list. Can you open an issue here: https://github.com/PolyMathOrg/PolyMath/issues so we don't forget about it ?â âDo you have specific needs behind this ?â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

*bump* I guess there no way to do this now. But maybe a VM guy can give me how difficult it might be to extend the VM accordingly. Best, Steffen Am .01.2018, 12:27 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: > Hi, > > is there any way to set the rounding mode for IEEE floating point > operations? Maybe something like > >> Double roundToMinusInfWhile: [... code goes here ...]Double >> roundToZeroWhile: [... more code here ...] > > If not, is it possible to add this behavior, e.g., via a custom > primitive? > > Best, Steffen

May 23, 2018