June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Esteban's ChangeLog week of 12 June 2017

by Norbert Hartl

You totally rock! I'm so eager to have iceberg on 64bits. It is the last block for me to move my projects into the 21st century ;) thanks, Norbert > Am 19.06.2017 um 08:00 schrieb estebanlm(a)gmail.com: > > Hello! > > This is my weekly ChangeLog, from 12 June 2017 to 18 June 2017. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=12/6/2017&to=18/6/2017 > > ChangeLog > ========= > > 15 June 2017: > ------------- > > * I finished an iteration for allowing cherry-pick into [iceberg](http://github.com/pharo-vcs/iceberg). > > Now, I just need to make it work on 64bits and we will be ready-to-go for releasing it :) > > > 13 June 2017: > ------------- > > * Still "iceberging", I fixed an annoying bug when browsing diff with parent (in all screens that have it), > who was trowing a DNU because of course, first commits do not have a parent to compare with. > > * I've been working on iceberg 0.5. It will incorporate some needed features (to make it appropriate to > work on pharo itself, and better for users). > > This was also my work last week, but I forget to announce it here ;) > > So far, I added following features: > > === Better diff handling > It was very naive because it was comparing always all present packages which does not scales on > large repositories. Now, I implemented a double dispatch that works in different scenarios: > > * commit -> commit: It relies in libgit2 to take the list of changed packages. > * commit -> branch: it takes last commit on branch on continues as commit->commit scenario > * loaded code -> commit: this is the most complicated scenario. It compares what is in image with what is in commit to take a correct diff. > > With this, now diffs are performant in all cases (bah, if you have a commit that changes > 300 packages, you will suffer anyway, but I would argue that is not a very good codign practice) > > Also with this you will finally be able to add not-dirty packages to your repo and commit them :) > > === Branch sync with disk copy > I had a discussion with author of Iceberg (Nico) on this: originally he weanted to treat loaded code in > the image as a got working-copy itself, so he was taking the information of the branch and keepong it. > > Problem with this is, if you change the repository branch (in command line or another image) and then > go back to your current image, you do not have any feedback... and that is severely confusing. > > So now I'm just taking the information from git repository. That means you can have differences between > what you loaded and your current branch, but that's, IMO, perfectly reasonable (you can always switch back or > merge or whatever you need to do) > > === Other > * Minor cleanups > * Other bugfixes > > > cheers! > Esteban

June 19, 2017

Re: [Pharo-dev] Esteban clone, Pavel clone, Clement clone, Guillermo clone....

by Alistair Grant

On Mon, Jun 19, 2017 at 08:13:10AM +0200, Stephane Ducasse wrote: > Thanks for FileSystem. I was thinking that it would be great to do > another pass on the comments. I've made significant changes to the Path class comments (of course there's still room for improvement). > I would like to start to convert the example in comment to use the new > >>> convention. > > I do not know how to push fixes using the new process. I will discuss > with marcus to know if he knows. > Once I know we will focus on the FileSystem fixes. I haven't yet submitted the patch which includes the Path class comments. I've submitted my first pull request and once I've got the process down will work my way through the others. Cheers, Alistair > Stef > > On Sun, Jun 18, 2017 at 5:10 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > On Sat, Jun 17, 2017 at 08:48:36AM +0200, Stephane Ducasse wrote: > >> Dear Pharoers > >> > >> there are many things that we would like to achieve to offer you a much better > >> system but we cannot clone ourselves. > >> > >> Please let us know if you want to participate building better tools > >> around for example Iceberg. > >> > >> Stef > > > > As there haven't been any other replies yet... > > > > I've been using Iceberg for a few months without any problems. I've > > just started trying out Esteban's suggested PR process for Pharo 7 and > > am starting to see issues. > > > > I've got some FileSystem patches which I would like to get in, but once > > they're done I will hopefully have a chance to look at Iceberg. > > > > Just FYI, the FileSystem patches are: > > > > - FileRefence>>moveTo: works across disks > > - FileReference>>/ is more intuitive, i.e. accept directory deliminators > > in the paramter, and make path canonicalisation consistent (also > > below). > > - FileReference>>= considers files equal if they point to the same file > > / directory. > > - Path canonicalisation has been tightened up (there's still some room > > for improvement). > > - isSymlink works, and all attributes from the libc stat() / lstat() > > calls are accessible (about 11 new attributes). > > > > And file attribute operations and directory enumarating are slightly > > faster than before. This is a fairly major patch, introducing a new VM > > plugin (which is why I waited for Pharo 7). > > > > And of course, thanks to everyone who has helped make Pharo what it is > > today. > > > > Cheers, > > Alistair

June 19, 2017

Re: [Pharo-dev] Extra shortcut modifier opposite to #meta

by Denis Kudriashov

2017-06-18 23:54 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > I really would like the ability to ctrl-tab (or whatever meta-tab or even > meta-some other key) reliably between windows - its frustrating that it > only works sometimes via alt-tab. There has been a lot of great work on > keyboard shortcuts, which I really appreciate - it would be awesome to > finish the job and even add a few more. > > Does this thread help with this if it was implemented? > No because I am talking about extra platform independent shortcut modifier. And for your case tab+meta is supposed to work. But by some reason it could not work all the time. It can be related to image side or also to vm side. As soon as we will move to sdl-driven window vm issues will gone

June 19, 2017

Re: [Pharo-dev] Extra shortcut modifier opposite to #meta

by Esteban Lorenzano

Hi Tim, > On 18 Jun 2017, at 23:54, Tim Mackinnon <tim(a)testit.works> wrote: > > I really would like the ability to ctrl-tab (or whatever meta-tab or even meta-some other key) reliably between windows - its frustrating that it only works sometimes via alt-tab. There has been a lot of great work on keyboard shortcuts, which I really appreciate - it would be awesome to finish the job and even add a few more. > > Does this thread help with this if it was implemented? one of the objectives we want to Pharo7 is to improve usability (in windows in particular, but also in general). maybe that means is finally the time to review the full key-binding support in Pharoâ¦ something that, as you said, started some years ago but we never got the time to finish (do it right is a lot of work, heh). Esteban > > Tim > >> On 16 Jun 2017, at 14:22, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2017-06-14 17:09 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >> But meta does also present problems in linux, doesn't it? I mean, meta in linux and windows means Ctrl. That means that overriding meta+arrows will break the Ctrl+arrows text navigation. What am I missing? >> >> I don't think that alternativeMeta means something useful. And I believe in this topic that there are no magic solutions. Spotter should define for each platform shortcuts that do not override text navigation, >> >> alternativeMeta will provide reusable solution for such cases. >

June 19, 2017

Re: [Pharo-dev] Esteban clone, Pavel clone, Clement clone, Guillermo clone....

by Stephane Ducasse

Thanks for FileSystem. I was thinking that it would be great to do another pass on the comments. I would like to start to convert the example in comment to use the new >>> convention. I do not know how to push fixes using the new process. I will discuss with marcus to know if he knows. Once I know we will focus on the FileSystem fixes. Stef On Sun, Jun 18, 2017 at 5:10 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Sat, Jun 17, 2017 at 08:48:36AM +0200, Stephane Ducasse wrote: >> Dear Pharoers >> >> there are many things that we would like to achieve to offer you a much better >> system but we cannot clone ourselves. >> >> Please let us know if you want to participate building better tools >> around for example Iceberg. >> >> Stef > > As there haven't been any other replies yet... > > I've been using Iceberg for a few months without any problems. I've > just started trying out Esteban's suggested PR process for Pharo 7 and > am starting to see issues. > > I've got some FileSystem patches which I would like to get in, but once > they're done I will hopefully have a chance to look at Iceberg. > > Just FYI, the FileSystem patches are: > > - FileRefence>>moveTo: works across disks > - FileReference>>/ is more intuitive, i.e. accept directory deliminators > in the paramter, and make path canonicalisation consistent (also > below). > - FileReference>>= considers files equal if they point to the same file > / directory. > - Path canonicalisation has been tightened up (there's still some room > for improvement). > - isSymlink works, and all attributes from the libc stat() / lstat() > calls are accessible (about 11 new attributes). > > And file attribute operations and directory enumarating are slightly > faster than before. This is a fairly major patch, introducing a new VM > plugin (which is why I waited for Pharo 7). > > And of course, thanks to everyone who has helped make Pharo what it is > today. > > Cheers, > Alistair >

June 19, 2017

Esteban's ChangeLog week of 12 June 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 12 June 2017 to 18 June 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=12/6/2017&to=18/6/2017 ChangeLog ========= 15 June 2017: ------------- * I finished an iteration for allowing cherry-pick into [iceberg](http://github.com/pharo-vcs/iceberg). Now, I just need to make it work on 64bits and we will be ready-to-go for releasing it :) 13 June 2017: ------------- * Still "iceberging", I fixed an annoying bug when browsing diff with parent (in all screens that have it), who was trowing a DNU because of course, first commits do not have a parent to compare with. * I've been working on iceberg 0.5. It will incorporate some needed features (to make it appropriate to work on pharo itself, and better for users). This was also my work last week, but I forget to announce it here ;) So far, I added following features: === Better diff handling It was very naive because it was comparing always all present packages which does not scales on large repositories. Now, I implemented a double dispatch that works in different scenarios: * commit -> commit: It relies in libgit2 to take the list of changed packages. * commit -> branch: it takes last commit on branch on continues as commit->commit scenario * loaded code -> commit: this is the most complicated scenario. It compares what is in image with what is in commit to take a correct diff. With this, now diffs are performant in all cases (bah, if you have a commit that changes 300 packages, you will suffer anyway, but I would argue that is not a very good codign practice) Also with this you will finally be able to add not-dirty packages to your repo and commit them :) === Branch sync with disk copy I had a discussion with author of Iceberg (Nico) on this: originally he weanted to treat loaded code in the image as a got working-copy itself, so he was taking the information of the branch and keepong it. Problem with this is, if you change the repository branch (in command line or another image) and then go back to your current image, you do not have any feedback... and that is severely confusing. So now I'm just taking the information from git repository. That means you can have differences between what you loaded and your current branch, but that's, IMO, perfectly reasonable (you can always switch back or merge or whatever you need to do) === Other * Minor cleanups * Other bugfixes cheers! Esteban

June 19, 2017

GT questions

by Torsten Bergmann

Hi, do we have an example on Glamorous Toolkit on 1. how to have a splitter between a pane (for instance to change size for left and right pane on a #dashboard) 2. how to have vertical tabs in a #tabulator 3. on how to use D&D from GT from a list or tree to the world? Thanks T.

June 19, 2017

Re: [Pharo-dev] Extra shortcut modifier opposite to #meta

by Tim Mackinnon

I really would like the ability to ctrl-tab (or whatever meta-tab or even meta-some other key) reliably between windows - its frustrating that it only works sometimes via alt-tab. There has been a lot of great work on keyboard shortcuts, which I really appreciate - it would be awesome to finish the job and even add a few more. Does this thread help with this if it was implemented? Tim > On 16 Jun 2017, at 14:22, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-06-14 17:09 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > But meta does also present problems in linux, doesn't it? I mean, meta in linux and windows means Ctrl. That means that overriding meta+arrows will break the Ctrl+arrows text navigation. What am I missing? > > I don't think that alternativeMeta means something useful. And I believe in this topic that there are no magic solutions. Spotter should define for each platform shortcuts that do not override text navigation, > > alternativeMeta will provide reusable solution for such cases.

June 18, 2017

Re: [Pharo-dev] Esteban clone, Pavel clone, Clement clone, Guillermo clone....

by Alistair Grant

Hi Stef, On Sat, Jun 17, 2017 at 08:48:36AM +0200, Stephane Ducasse wrote: > Dear Pharoers > > there are many things that we would like to achieve to offer you a much better > system but we cannot clone ourselves. > > Please let us know if you want to participate building better tools > around for example Iceberg. > > Stef As there haven't been any other replies yet... I've been using Iceberg for a few months without any problems. I've just started trying out Esteban's suggested PR process for Pharo 7 and am starting to see issues. I've got some FileSystem patches which I would like to get in, but once they're done I will hopefully have a chance to look at Iceberg. Just FYI, the FileSystem patches are: - FileRefence>>moveTo: works across disks - FileReference>>/ is more intuitive, i.e. accept directory deliminators in the paramter, and make path canonicalisation consistent (also below). - FileReference>>= considers files equal if they point to the same file / directory. - Path canonicalisation has been tightened up (there's still some room for improvement). - isSymlink works, and all attributes from the libc stat() / lstat() calls are accessible (about 11 new attributes). And file attribute operations and directory enumarating are slightly faster than before. This is a fairly major patch, introducing a new VM plugin (which is why I waited for Pharo 7). And of course, thanks to everyone who has helped make Pharo what it is today. Cheers, Alistair

June 18, 2017

Re: [Pharo-dev] Doing a pull request

by Esteban Lorenzano

yes please :) > On 18 Jun 2017, at 15:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > HI juraj > > yes it would really cool. > > Stef > > On Sun, Jun 18, 2017 at 1:11 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >> >>> El 16-06-2017, a las 19:27, Esteban Lorenzano <estebanlm(a)gmail.com> escribiÃ³: >>> >>> >>>> On 16 Jun 2017, at 16:50, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >>>> >>>> On Thursday 15 June 2017 08:14 PM, Esteban Lorenzano wrote: >>>>> 2. work on fix/change >>>>> 3. commit/push to your repo >>>>> 4. do a Pull Request once finished. >>>> >>>> Esteban, >>>> >>>> Step 2 requires an issue to be created in Fogbugz. It would be nice to do this within Pharo itself. >>> >>> it would be, yes. >>> I have even played with the idea of having a âreport bugâ button on debugger for years nowâ¦ >> >> Hi, I am currently playing with something like this :-) Well, I am reporting it to a Discord channel because someone may want to report and share troubles that are not related only with Pharo core, e.g., Roassal or other external projects. But we can have two buttons for sure. >> >> I will share it once it is ready for public review. >> >> Juraj >> >>> >>> but then, someone has to program it :) >>> >>> Esteban >>> >>>> >>>> When creating an issue FB requires every detail to be filled in. Most issues arise while testing or debugging, so it would be easy to get most of the details from a debug session or test failure and then file an issue. >>>> >>>> Regards .. Subbu >>>> >>>> >>> >>> >> >> >

June 18, 2017