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

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

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

by Ben Coman

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. 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. cheers -ben > > When you branch in Pharo, a command line git status does show that change > - so some things clearly are being mirrored, just not code (Which Iâm guess > happens briefly when you click commit?). > > Iâm curious now to understand the tradeoffs. > > Tim > > p.s. it is very nice for small private projects, to use a git client on > your phone - edit a method or two on the train, commit your changes and > then see your CI build the results and deploy a new website by the time you > get offâ¦ yes its not the rich smalltalk environment for bigger changes - > but tiny stuff, its quite nice to fallback on the traditional way. > > >

May 23, 2018

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

by Sean P. DeNigris

Esteban A. Maringolo wrote > there is no way to "save" the package other than committing its changes to > the repo. In the past, I sorely missed a feature like this. When Iceberg (or I!) was confused about the state of the local repo/changes/whatever, I wished I had a way to write to disk and then verify that it did "the right thing" and manually fix with "normal" git tools if needed. Maybe Iceberg has improved enough to make this unneededâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 22, 2018

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

by Sean P. DeNigris

Tim Mackinnon wrote > Although possibly calling it âCommitâ¦â might make it more obvious that you > have a chance to review changes and change your mind +1. This minor change would IMHO make things much more obvious, especially to people unfamiliar with gitâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 22, 2018

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

by Tim Mackinnon

Actually I missed that one - thanks. Would have been a useful one to show everyone when we went through the commit process - itâs very good. Sent from my iPhone Sent from my iPhone > On 22 May 2018, at 17:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Partial answer, but you saw this, right ? > > https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary > >> On 22 May 2018, at 17: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? >> >> When you branch in Pharo, a command line git status does show that change - so some things clearly are being mirrored, just not code (Which Iâm guess happens briefly when you click commit?). >> >> Iâm curious now to understand the tradeoffs. >> >> Tim >> >> p.s. it is very nice for small private projects, to use a git client on your phone - edit a method or two on the train, commit your changes and then see your CI build the results and deploy a new website by the time you get offâ¦ yes its not the rich smalltalk environment for bigger changes - but tiny stuff, its quite nice to fallback on the traditional way. > >

May 22, 2018

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

by Tim Mackinnon

The community has invested a lot in a new way of working - Iâve seen the pain, but I think itâs both inspiring , a difficult journey but ultimately well worth it. We need to finish this first leg though, but Iâm still very proud to be a smalltalker ... Sent from my iPhone > On 22 May 2018, at 16:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Tim, > > Thanks for the detailed/constructive feedback. I am sure it will be helpful. > > Sven > >> On 22 May 2018, at 17:15, 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. >> >> 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). >> >> 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). >> >> 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). 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?). >> >> 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). >> >> 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. >> >> >> Tim >> >> >> Sent from my iPhone > >

May 22, 2018