- Pharo-users - lists.pharo.org

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

by Serge Stinckwich

What is really strange is when I print the following lines, I obtain 2048: current := LibC uniqueInstance fegetround. LibC uniqueInstance fesetround: 2048. LibC uniqueInstance fegetround. and 0 when I remove the first line : LibC uniqueInstance fesetround: 2048. LibC uniqueInstance fegetround. On Thu, May 24, 2018 at 10:37 AM Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > > > On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> I actually made progress: It works like a charm! Basically, I >> implemented >> the same code as you. Testing is straightforward (using the constant >> values from libc): >> >> current := LibC fegetround. >> LibC fesetround: FE_DOWNWARDS. >> v1 := 1.0/10.0. >> LibC feesetround: FE_UPWARDS. >> v2 := 1.0/10.0. >> LibC feesetround: current. >> v1 < v2. "true" >> >> > âbut apparently nothing happens when you do : >> > LibC uniqueInstance fesetround: 1024. >> > LibC uniqueInstance fegetround. >> > always return 0.â >> >> This is expected, since the fesetround function returns 0 only if the >> set >> operation was successful. >> >> > âI was talking about fgetround function. > â Can you check the value returns by your fegetround function ?â > > Constants values are not dependent of the platform ?â > > âCan you commit yr code to Pharo 7.0 or if there is no interest for this > to PolyMath ?â > âThank you.â > -- > 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/ > -- 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 24, 2018

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

by Guillermo Polito

Aaand, I've updated https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo On Thu, May 24, 2018 at 11:34 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies) > https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging > > On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi, >> >> I'll take some minutes to provide an answer as detailed as possible to >> all questions in this mail, and to the ones in the mails before. >> But first, since I know most people only read the first lines of mails >> :P, if you find any concrete iceberg issues, please report them in >> >> https://github.com/pharo-vcs/iceberg/issues >> >> Now, answers inline. >> >> On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> Hi - last night we managed to explore the new contribution process as >>> well as the new iceberg ui at the U.K. Smalltalk meetup last night. >>> >> >> Cool! >> >> >>> >>> Not many had seen it before so it was a good test run. >>> >>> As an initial comment - we need to invest a small amount of time to get >>> the right docs in places you expect them as not doing so undoes a lot of >>> good work - the Pharo main site that points to old contribution docs (and >>> doesnât reference the new ones) must be updated ASAP to keep energy high >>> (we almost lost a few folks last night by going down the wrong path - >>> fortunately Cyril piped up on Discord for me - phew). >>> >> >> I know. This is indeed important. I'm trying to get time to make videos, >> paste as much info in the wiki. Now, it would be good to know what was >> exactly your "wrong path". The more concrete you are, the easier is to fix >> it :). >> I see Pharo contribution page (http://pharo.org/contribute-propose-fix) >> points to https://github.com/pharo-project/pharo/wiki/Contribute-a- >> fix-to-Pharo which is outdated. I'll fix it ASAP. >> >> >>> >>> Armed with the right steps it was straightforward - much easier than the >>> older slices mechanism (that I never was comfortable with) - so HUGE thanks >>> for that everyone! >>> >>> As we worked through it, the more git seasoned folks were confused why >>> git status in a terminal wasnât really showing the same info as iceberg >>> (Iâll put this in a separate thread to discuss, as itâs an interesting >>> thought which Iâm sure has lively discussion). >>> >> >> Well, this is the discussion in the other thread. If you have read the >> glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) >> you will notice that iceberg presents you with two working copies: >> - the image working copy >> - the disk working copy >> >> The disk working copy is what most people know when they use git. The >> directory where you have your repository, with the files you're modifying. >> >> The image working copy represent what is loaded in Pharo. It's important >> to differentiate them because if I send you an image (or you download it >> from somewhere) you have code loaded on it. This working copy allows us to >> track how and where you loaded that code from. That is useful if later on >> you want to contribute to that project in some way. >> >> Then there are other questions: >> >> !! Why do we still have a disk working copy? >> >> Well, this is not really necessary for iceberg to work. Iceberg could >> just write source code directly on git's BLOB, as Thierry mentioned in the >> other thread. >> The reason for this working copy to be there is just to try to be less >> alien. >> Having the disk working copy allows people to still have a way to: >> - edit non-smalltalk files from the command like >> - use the non command line as a last ressource if something goes wrong >> with your Pharo image >> - use external tools to manage the repository (sourcetree, git kraken, >> whatever you're confortable with) >> >> The idea is that Iceberg will try to keep your disk working copy in sync >> with your repository HEAD. >> It will take care of transparently synchronizing your disk working copy >> when: >> - you commit >> - you change branches >> - you pull/push/merge >> >> !! Why don't we dump code into the disk as we write it? >> >> The main reason behind it is that the image is not causally connected to >> the directory in disk, as Ben implied. >> There is not a 1 to 1 correspondence between what you could ever have in >> disk and your running image. >> As Ben mentionned, for this to happen: >> - changing the source code in disk should get automatically loaded into >> Pharo >> - changing the source code in Pharo should get automatically written in >> disk >> >> The thing is that this is much more difficult than it sounds: >> - What happens if you do not want to save your image, you forgot to save >> it or it crashes? Suddenly you will have an image that is not in sync with >> your repository. Would you load all changes into your image as soon as you >> reopen it? Atomically? >> - What happens if you share your repository between several images? >> - Or if suddenly you change your branch from the command line to >> something completely different? >> >> Several of these usecases don't even make sense. So we preferred to >> choose the path of "make it explicit". >> Of course, we could do better, we are open to discuss any improvements. >> Just take into account that Iceberg did not come from an egg :) we have >> thought about many possible scenarios and discussed with a lot of people >> before. >> >> !! How does merge work? >> >> First, just for the record, merge works. We even >> - detect fast forward merge avoiding the creation of extra merge commits >> - proposing a single UI to resolve all conflicts of a project at once >> and not one per package >> >> Now, as Thierry suggested in the other thread, Iceberg's merge happen in >> memory. The reason behind this is that using Git's default merge mechanism >> would insert the >>>> <<<< markers in the conflicting files. This would >> break our parsers and all our tools. >> Instead, we ask git for the list of conflicting files, and we build a >> diff tree in memory, that we later augment with information such as >> conflicts. >> >> There are some issues we have seen when merging external files, but as >> soon as the two merged commits are not merging external files, but we hope >> we will fix them soon. >> >> Missing feature: right now we can only choose between incoming or loaded >> version during a merge. It would be nice to be able to edit a method's >> code, picking part of the incoming code and part of the current code. >> >> Missing feature 2: right now we resolve all conflicts in memory and >> commit them at once. We know some people would like to, instead, not do the >> merge automatically, so they can test it before committing. This should not >> be tooo difficult to do but it was down in the priority list :). >> >> !! Exporting without commiting? >> >> There is no UI support for this, but it is doable from the backend, >> though not correctly exposed right now. >> >> You can right-click on the repository -> Extras -> Inspect >> >> repository index updateDiskWorkingCopy: repository workingCopy >> workingCopyDiff. >> >> >>> Anyway - the new UI does take some getting used to (personally I liked >>> the compactness of the original Iceberg and its tabs), but when you >>> understand what the different windows show you - I think it makes sense >>> (and hopefully is more stable). >> >> >> Well, the UI rewriting has several ideas behind. I'll put whichever ones >> come to my mind in here, I hope Esteban will correct me if I'm wrong: >> >> - Moving from Glamour to Spec. This is a purely technical decision. >> AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT >> team, and it has some rough corners that made the old UI difficult to deal >> with sometimes. From an investment of time standpoint, we decided to put >> effort in Spec instead... >> - Simplify the UI. We needed it to be less overwhelming and sometimes >> more direct. That's the why of the toolbar on the top, and the more (but >> smaller and simpler) windows. >> >> Regarding the design, Esteban followed some UI guidelines for the design >> taken from I don't where. But at the end we are engineers, not UI >> designers, so we make ugly UIs by default :P. >> Any improvement or concrete suggestion on this direction is welcome :). >> >> >>> We all missed having an obvious Diff mechanism - we later spotted that >>> Commit does show this (Although possibly calling it âCommitâ¦â might make it >>> more obvious that you have a chance to review changes and change your mind) >>> - but knowing the size of your change and reviewing them without any danger >>> of committing something is a useful feature (but maybe a 2.0 enhancement >>> request?). >>> >> >> Yes, I want that also. I miss >> - a Diff/See Changes button. >> - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" >> instead of just "XXX to YYY" >> >> Could you open an issue? >> >> >>> >>> One small tweak (which I would PR if I knew how to - would be to swap >>> the status and branch columns in the Repository window to make the status >>> clearer (the status gets lost as it sqashed against the normally much >>> longer branch name). Its a simple change to #initializeRepositoryList but >>> I guess Iceberg is in a different repository (and not in the instructions >>> for contirbutions). >>> >> >> Could you open an issue? >> >> >>> >>> We also noticed that if you try to use the âCreate Pull Requestâ menu >>> item, you canât if you have 2FA enabled on Github (the recommended setting) >>> as I guess that ssh protocol doesnât allow this with an ssh key? So I we >>> should update the instructions to suggest either using the web ui - or - >>> creating an app specific login (that doesnât use 2fa). - Iâll look at how >>> to add that tweak and send a PR. >>> >> >> Ouki :) >> >> Thanks! >> >> >>> >>> >>> Tim >>> >>> >>> Sent from my iPhone >>> >> >> >> >> -- >> >> >> >> 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 > -- 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] Set Rounding mode for IEEE floating point operations

by Serge Stinckwich

On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I actually made progress: It works like a charm! Basically, I implemented > the same code as you. Testing is straightforward (using the constant > values from libc): > > current := LibC fegetround. > LibC fesetround: FE_DOWNWARDS. > v1 := 1.0/10.0. > LibC feesetround: FE_UPWARDS. > v2 := 1.0/10.0. > LibC feesetround: current. > v1 < v2. "true" > > > âbut apparently nothing happens when you do : > > LibC uniqueInstance fesetround: 1024. > > LibC uniqueInstance fegetround. > > always return 0.â > > This is expected, since the fesetround function returns 0 only if the set > operation was successful. > > âI was talking about fgetround function. â Can you check the value returns by your fegetround function ?â Constants values are not dependent of the platform ?â âCan you commit yr code to Pharo 7.0 or if there is no interest for this to PolyMath ?â âThank you.â -- 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 24, 2018

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

by Guillermo Polito

https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies) https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi, > > I'll take some minutes to provide an answer as detailed as possible to all > questions in this mail, and to the ones in the mails before. > But first, since I know most people only read the first lines of mails :P, > if you find any concrete iceberg issues, please report them in > > https://github.com/pharo-vcs/iceberg/issues > > Now, answers inline. > > On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - last night we managed to explore the new contribution process as >> well as the new iceberg ui at the U.K. Smalltalk meetup last night. >> > > Cool! > > >> >> Not many had seen it before so it was a good test run. >> >> As an initial comment - we need to invest a small amount of time to get >> the right docs in places you expect them as not doing so undoes a lot of >> good work - the Pharo main site that points to old contribution docs (and >> doesnât reference the new ones) must be updated ASAP to keep energy high >> (we almost lost a few folks last night by going down the wrong path - >> fortunately Cyril piped up on Discord for me - phew). >> > > I know. This is indeed important. I'm trying to get time to make videos, > paste as much info in the wiki. Now, it would be good to know what was > exactly your "wrong path". The more concrete you are, the easier is to fix > it :). > I see Pharo contribution page (http://pharo.org/contribute-propose-fix) > points to https://github.com/pharo-project/pharo/wiki/Contribute- > a-fix-to-Pharo which is outdated. I'll fix it ASAP. > > >> >> Armed with the right steps it was straightforward - much easier than the >> older slices mechanism (that I never was comfortable with) - so HUGE thanks >> for that everyone! >> >> As we worked through it, the more git seasoned folks were confused why >> git status in a terminal wasnât really showing the same info as iceberg >> (Iâll put this in a separate thread to discuss, as itâs an interesting >> thought which Iâm sure has lively discussion). >> > > Well, this is the discussion in the other thread. If you have read the > glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) > you will notice that iceberg presents you with two working copies: > - the image working copy > - the disk working copy > > The disk working copy is what most people know when they use git. The > directory where you have your repository, with the files you're modifying. > > The image working copy represent what is loaded in Pharo. It's important > to differentiate them because if I send you an image (or you download it > from somewhere) you have code loaded on it. This working copy allows us to > track how and where you loaded that code from. That is useful if later on > you want to contribute to that project in some way. > > Then there are other questions: > > !! Why do we still have a disk working copy? > > Well, this is not really necessary for iceberg to work. Iceberg could just > write source code directly on git's BLOB, as Thierry mentioned in the other > thread. > The reason for this working copy to be there is just to try to be less > alien. > Having the disk working copy allows people to still have a way to: > - edit non-smalltalk files from the command like > - use the non command line as a last ressource if something goes wrong > with your Pharo image > - use external tools to manage the repository (sourcetree, git kraken, > whatever you're confortable with) > > The idea is that Iceberg will try to keep your disk working copy in sync > with your repository HEAD. > It will take care of transparently synchronizing your disk working copy > when: > - you commit > - you change branches > - you pull/push/merge > > !! Why don't we dump code into the disk as we write it? > > The main reason behind it is that the image is not causally connected to > the directory in disk, as Ben implied. > There is not a 1 to 1 correspondence between what you could ever have in > disk and your running image. > As Ben mentionned, for this to happen: > - changing the source code in disk should get automatically loaded into > Pharo > - changing the source code in Pharo should get automatically written in > disk > > The thing is that this is much more difficult than it sounds: > - What happens if you do not want to save your image, you forgot to save > it or it crashes? Suddenly you will have an image that is not in sync with > your repository. Would you load all changes into your image as soon as you > reopen it? Atomically? > - What happens if you share your repository between several images? > - Or if suddenly you change your branch from the command line to > something completely different? > > Several of these usecases don't even make sense. So we preferred to choose > the path of "make it explicit". > Of course, we could do better, we are open to discuss any improvements. > Just take into account that Iceberg did not come from an egg :) we have > thought about many possible scenarios and discussed with a lot of people > before. > > !! How does merge work? > > First, just for the record, merge works. We even > - detect fast forward merge avoiding the creation of extra merge commits > - proposing a single UI to resolve all conflicts of a project at once and > not one per package > > Now, as Thierry suggested in the other thread, Iceberg's merge happen in > memory. The reason behind this is that using Git's default merge mechanism > would insert the >>>> <<<< markers in the conflicting files. This would > break our parsers and all our tools. > Instead, we ask git for the list of conflicting files, and we build a diff > tree in memory, that we later augment with information such as conflicts. > > There are some issues we have seen when merging external files, but as > soon as the two merged commits are not merging external files, but we hope > we will fix them soon. > > Missing feature: right now we can only choose between incoming or loaded > version during a merge. It would be nice to be able to edit a method's > code, picking part of the incoming code and part of the current code. > > Missing feature 2: right now we resolve all conflicts in memory and commit > them at once. We know some people would like to, instead, not do the merge > automatically, so they can test it before committing. This should not be > tooo difficult to do but it was down in the priority list :). > > !! Exporting without commiting? > > There is no UI support for this, but it is doable from the backend, though > not correctly exposed right now. > > You can right-click on the repository -> Extras -> Inspect > > repository index updateDiskWorkingCopy: repository workingCopy > workingCopyDiff. > > >> Anyway - the new UI does take some getting used to (personally I liked >> the compactness of the original Iceberg and its tabs), but when you >> understand what the different windows show you - I think it makes sense >> (and hopefully is more stable). > > > Well, the UI rewriting has several ideas behind. I'll put whichever ones > come to my mind in here, I hope Esteban will correct me if I'm wrong: > > - Moving from Glamour to Spec. This is a purely technical decision. > AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT > team, and it has some rough corners that made the old UI difficult to deal > with sometimes. From an investment of time standpoint, we decided to put > effort in Spec instead... > - Simplify the UI. We needed it to be less overwhelming and sometimes > more direct. That's the why of the toolbar on the top, and the more (but > smaller and simpler) windows. > > Regarding the design, Esteban followed some UI guidelines for the design > taken from I don't where. But at the end we are engineers, not UI > designers, so we make ugly UIs by default :P. > Any improvement or concrete suggestion on this direction is welcome :). > > >> We all missed having an obvious Diff mechanism - we later spotted that >> Commit does show this (Although possibly calling it âCommitâ¦â might make it >> more obvious that you have a chance to review changes and change your mind) >> - but knowing the size of your change and reviewing them without any danger >> of committing something is a useful feature (but maybe a 2.0 enhancement >> request?). >> > > Yes, I want that also. I miss > - a Diff/See Changes button. > - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" > instead of just "XXX to YYY" > > Could you open an issue? > > >> >> One small tweak (which I would PR if I knew how to - would be to swap >> the status and branch columns in the Repository window to make the status >> clearer (the status gets lost as it sqashed against the normally much >> longer branch name). Its a simple change to #initializeRepositoryList but >> I guess Iceberg is in a different repository (and not in the instructions >> for contirbutions). >> > > Could you open an issue? > > >> >> We also noticed that if you try to use the âCreate Pull Requestâ menu >> item, you canât if you have 2FA enabled on Github (the recommended setting) >> as I guess that ssh protocol doesnât allow this with an ssh key? So I we >> should update the instructions to suggest either using the web ui - or - >> creating an app specific login (that doesnât use 2fa). - Iâll look at how >> to add that tweak and send a PR. >> > > Ouki :) > > Thanks! > > >> >> >> Tim >> >> >> Sent from my iPhone >> > > > > -- > > > > 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] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

I actually made progress: It works like a charm! Basically, I implemented the same code as you. Testing is straightforward (using the constant values from libc): current := LibC fegetround. LibC fesetround: FE_DOWNWARDS. v1 := 1.0/10.0. LibC feesetround: FE_UPWARDS. v2 := 1.0/10.0. LibC feesetround: current. v1 < v2. "true" > âbut apparently nothing happens when you do : > LibC uniqueInstance fesetround: 1024. > LibC uniqueInstance fegetround. > always return 0.â This is expected, since the fesetround function returns 0 only if the set operation was successful. Thanks again for your support! Best, Steffen

May 24, 2018

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

by Guillermo Polito

Hi, I'll take some minutes to provide an answer as detailed as possible to all questions in this mail, and to the ones in the mails before. But first, since I know most people only read the first lines of mails :P, if you find any concrete iceberg issues, please report them in https://github.com/pharo-vcs/iceberg/issues Now, answers inline. On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - last night we managed to explore the new contribution process as well > as the new iceberg ui at the U.K. Smalltalk meetup last night. > Cool! > > Not many had seen it before so it was a good test run. > > As an initial comment - we need to invest a small amount of time to get > the right docs in places you expect them as not doing so undoes a lot of > good work - the Pharo main site that points to old contribution docs (and > doesnât reference the new ones) must be updated ASAP to keep energy high > (we almost lost a few folks last night by going down the wrong path - > fortunately Cyril piped up on Discord for me - phew). > I know. This is indeed important. I'm trying to get time to make videos, paste as much info in the wiki. Now, it would be good to know what was exactly your "wrong path". The more concrete you are, the easier is to fix it :). I see Pharo contribution page (http://pharo.org/contribute-propose-fix) points to https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo which is outdated. I'll fix it ASAP. > > Armed with the right steps it was straightforward - much easier than the > older slices mechanism (that I never was comfortable with) - so HUGE thanks > for that everyone! > > As we worked through it, the more git seasoned folks were confused why git > status in a terminal wasnât really showing the same info as iceberg (Iâll > put this in a separate thread to discuss, as itâs an interesting thought > which Iâm sure has lively discussion). > Well, this is the discussion in the other thread. If you have read the glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) you will notice that iceberg presents you with two working copies: - the image working copy - the disk working copy The disk working copy is what most people know when they use git. The directory where you have your repository, with the files you're modifying. The image working copy represent what is loaded in Pharo. It's important to differentiate them because if I send you an image (or you download it from somewhere) you have code loaded on it. This working copy allows us to track how and where you loaded that code from. That is useful if later on you want to contribute to that project in some way. Then there are other questions: !! Why do we still have a disk working copy? Well, this is not really necessary for iceberg to work. Iceberg could just write source code directly on git's BLOB, as Thierry mentioned in the other thread. The reason for this working copy to be there is just to try to be less alien. Having the disk working copy allows people to still have a way to: - edit non-smalltalk files from the command like - use the non command line as a last ressource if something goes wrong with your Pharo image - use external tools to manage the repository (sourcetree, git kraken, whatever you're confortable with) The idea is that Iceberg will try to keep your disk working copy in sync with your repository HEAD. It will take care of transparently synchronizing your disk working copy when: - you commit - you change branches - you pull/push/merge !! Why don't we dump code into the disk as we write it? The main reason behind it is that the image is not causally connected to the directory in disk, as Ben implied. There is not a 1 to 1 correspondence between what you could ever have in disk and your running image. As Ben mentionned, for this to happen: - changing the source code in disk should get automatically loaded into Pharo - changing the source code in Pharo should get automatically written in disk The thing is that this is much more difficult than it sounds: - What happens if you do not want to save your image, you forgot to save it or it crashes? Suddenly you will have an image that is not in sync with your repository. Would you load all changes into your image as soon as you reopen it? Atomically? - What happens if you share your repository between several images? - Or if suddenly you change your branch from the command line to something completely different? Several of these usecases don't even make sense. So we preferred to choose the path of "make it explicit". Of course, we could do better, we are open to discuss any improvements. Just take into account that Iceberg did not come from an egg :) we have thought about many possible scenarios and discussed with a lot of people before. !! How does merge work? First, just for the record, merge works. We even - detect fast forward merge avoiding the creation of extra merge commits - proposing a single UI to resolve all conflicts of a project at once and not one per package Now, as Thierry suggested in the other thread, Iceberg's merge happen in memory. The reason behind this is that using Git's default merge mechanism would insert the >>>> <<<< markers in the conflicting files. This would break our parsers and all our tools. Instead, we ask git for the list of conflicting files, and we build a diff tree in memory, that we later augment with information such as conflicts. There are some issues we have seen when merging external files, but as soon as the two merged commits are not merging external files, but we hope we will fix them soon. Missing feature: right now we can only choose between incoming or loaded version during a merge. It would be nice to be able to edit a method's code, picking part of the incoming code and part of the current code. Missing feature 2: right now we resolve all conflicts in memory and commit them at once. We know some people would like to, instead, not do the merge automatically, so they can test it before committing. This should not be tooo difficult to do but it was down in the priority list :). !! Exporting without commiting? There is no UI support for this, but it is doable from the backend, though not correctly exposed right now. You can right-click on the repository -> Extras -> Inspect repository index updateDiskWorkingCopy: repository workingCopy workingCopyDiff. > Anyway - the new UI does take some getting used to (personally I liked the > compactness of the original Iceberg and its tabs), but when you understand > what the different windows show you - I think it makes sense (and hopefully > is more stable). Well, the UI rewriting has several ideas behind. I'll put whichever ones come to my mind in here, I hope Esteban will correct me if I'm wrong: - Moving from Glamour to Spec. This is a purely technical decision. AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT team, and it has some rough corners that made the old UI difficult to deal with sometimes. From an investment of time standpoint, we decided to put effort in Spec instead... - Simplify the UI. We needed it to be less overwhelming and sometimes more direct. That's the why of the toolbar on the top, and the more (but smaller and simpler) windows. Regarding the design, Esteban followed some UI guidelines for the design taken from I don't where. But at the end we are engineers, not UI designers, so we make ugly UIs by default :P. Any improvement or concrete suggestion on this direction is welcome :). > We all missed having an obvious Diff mechanism - we later spotted that > Commit does show this (Although possibly calling it âCommitâ¦â might make it > more obvious that you have a chance to review changes and change your mind) > - but knowing the size of your change and reviewing them without any danger > of committing something is a useful feature (but maybe a 2.0 enhancement > request?). > Yes, I want that also. I miss - a Diff/See Changes button. - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" instead of just "XXX to YYY" Could you open an issue? > > One small tweak (which I would PR if I knew how to - would be to swap the > status and branch columns in the Repository window to make the status > clearer (the status gets lost as it sqashed against the normally much > longer branch name). Its a simple change to #initializeRepositoryList but > I guess Iceberg is in a different repository (and not in the instructions > for contirbutions). > Could you open an issue? > > We also noticed that if you try to use the âCreate Pull Requestâ menu > item, you canât if you have 2FA enabled on Github (the recommended setting) > as I guess that ssh protocol doesnât allow this with an ssh key? So I we > should update the instructions to suggest either using the web ui - or - > creating an app specific login (that doesnât use 2fa). - Iâll look at how > to add that tweak and send a PR. > Ouki :) Thanks! > > > Tim > > > Sent from my iPhone > -- 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] Set Rounding mode for IEEE floating point operations

by Serge Stinckwich

On Wed, May 23, 2018 at 3:39 PM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > 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. =) > > âThis quite easy to implement : LibC>>fegetround ^ self ffiCall: #(int fegetround(void))â âLibC>>â fesetround: round ^ self ffiCall: #(void fesetround(int round)) âbut apparently nothing happens when you do : LibC uniqueInstance fesetround: 1024. LibC uniqueInstance fegetround. always return 0.â -- 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 24, 2018

Re: [Pharo-users] On UDP broadcast

by Hilaire

I took a look of course. Thanks. At my basic level of knowledge, I found the articles on the Pharo books and the basic Tests on Socket very helpful. Hilaire Le 23/05/2018 Ã 17:42, N. Bouraqadi a Ã©critÂ : > 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 >> <mailto:cdrick65@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/#%21/%7ECAR/ReusableBricks> >> It has some dependencies on other packages. Â» >> >> It may help. I cc Noury. -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] On UDP broadcast

by Hilaire

Hi Henrik, Le 22/05/2018 Ã 10:57, Henrik Sperre Johansen a Ã©critÂ : > With UDP, there is no connection concept, so I'd reckon > waitForConnectionFor: is what gives you a TimeOut error... The #waitForConnectionFor: message seems not to be the issue. I was doing something apparently stupid: I started first the broadcast from the shell, then the listener in Pharo. Funnily I was doing it the other way when using nc to listen. Any way I will still discard #waitForConnectionFor: > Delete that, only use waitForDataFor: n , put it in a loop (so it won't stop > listening until it receives a request), and you should be fine. ok > Doesn't quite look like neither server nor client yet, the workflow should > be something like: > 1) server (you) starts, listening to port you're using and waitsForData: in > an infinite loop. > 2) client (student) starts, sends request to broadcast address/port, then > waitsForData: on the socket it created. > 3) broadcast server reads request, generates reply, and sends it to the > originIP/port of the request > 4) client receives reply, handles it, and closes socket. If I understand correctly what you suggest, student workstations initiate the broadcast to manifest interest to access My scenario initial idea was a bit more like: 1) server, teacher workstation, continuously broadcast its IP to a specific port. 2) student workstation, when they want to access teacher shares, listen to this port to get the teacher workstation IP 3) once student workstation got the ip, it stops listen for broadcast, and it connects to the to the teacher workstation http server to access the shares. Your scenario does not need a continuously broadcast... > PS. Why use nc when you already have a working broadcast client in pharo?;) Oh, just to play with one variable at a time.Â But seems I introduced a human factor. Thanks Hilaire -- Dr. Geo http://drgeo.eu

May 24, 2018

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

by Sven Van Caekenberghe

Thanks! > On 24 May 2018, at 10:34, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > AAAnd, I've uploaded some of this things to Iceberg's documentation. > > How to contribute to Iceberg: https://github.com/pharo-vcs/iceberg/wiki/Contributing-to-Iceberg > Metacello support: https://github.com/pharo-vcs/iceberg/wiki/Metacello-Support > Branching and merging: https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging > > On Thu, May 24, 2018 at 10:06 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > 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/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. > > 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 > > Web: 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 > > Web: 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

May 24, 2018