- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] integrating FileDialog into Pharo 7

by Pavel Krivanek

We should work on integration of it. Firstly please move tests to a separate package. Cheers, -- Pavel 2017-07-10 12:34 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > some people expressed interest in integrating File Dialog > https://github.com/peteruhnak/file-dialog into Pharo as the default file > dialog. > > Is it something people are interested in, or is the current solution > sufficient for them? > > Peter > >

July 10, 2017

integrating FileDialog into Pharo 7

by Peter Uhnak

Hi, some people expressed interest in integrating File Dialog https://github.com/peteruhnak/file-dialog into Pharo as the default file dialog. Is it something people are interested in, or is the current solution sufficient for them? Peter

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Pavel Krivanek

We can get the information using the GitHub API... like https://api.github.com/repos/pharo-project/pharo/commits/development?pathsr… -- Pavel 2017-07-10 11:32 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-10 11:22 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > >> On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote: >> > >> > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> > >> > However the real question is if we need them in the form we had >> them until >> > now because they are flattened as soon as a new changes file >> (release) is >> > created and it stores only information about the last person who >> touched >> > the method, not about the author nor wider history. >> > >> > For me, YES! >> > >> > I always take this data as a hint to track down bugs. Especially in >> > this community were different people do bug fixes or introduce >> > something new /change something, it is really helpfull and valueable >> > to track this changes by the method history. (not only *who* did the >> > change, but also, in what context, what else had changed. And I think >> > it is much easier to do this from within the image instead of looking >> > at the git diff). >> >> Are the two really mutually exclusive? Given the move to Iceberg >> wouldn't it make sense to extend Iceberg to be able to analyse the git >> history from within the image? >> > > > No, they are not mutually exclusive, it is just that you can not see the > history now. > Maybe iceberg will solve this, but for now you can not see the history > (and as a windows user, I can not even use iceberg). > > > >> >> >> > That hte history is already lost when we created a new changes/sources >> > for release is something that always disturbed me. And I hoped there >> > would be some way to reload the "real" history with all intermediate >> > changes. >> >> Cheers, >> Alistair >> >> >> >

July 10, 2017

Re: [Pharo-dev] latest 70 and vm

by Pavel Krivanek

So 64-bit version is now working too -- Pavel 2017-07-10 10:51 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Now we can get the latest Pharo 7 (32-bit only) by zero-conf: > > http://get.pharo.org/70+vm > http://get.pharo.org/70 > etc. > > Be sure that you have a virtual machine suitable for Pharo 7 (it contains > newer libgit2 version). > Pharo 7 is distributed in three files: image, changes and sources file > that is unique for every bootstrapped version, so if you use the zero-conf > scripts (e.g. on a CI), keep this in mind. > > Cheers, > > -- Pavel > > 2017-07-09 16:15 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Hi, >> >> I added upload of 32-bit version to CI so the link for the download of >> the version 7 starts to return proper result (for minimal image not). >> >> The link is http://files.pharo.org/image/70/latest.zip >> >> We still cannot use zero-conf because the script cannot process the new >> sources. >> >> -- Pavel >> >> 2017-07-09 14:12 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> In fact I cannot access it. So when esteban is back and fix the web >>> site we should not forget to update this. >>> >>> On Sun, Jul 9, 2017 at 2:04 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>> > Tx pavel I will update the website. >>> > >>> > >>> > On Sat, Jul 8, 2017 at 10:06 PM, Pavel Krivanek >>> > <pavel.krivanek(a)gmail.com> wrote: >>> >> the VM for Pharo 7 is available by zero-conf scripts >>> >> (http://get.pharo.org/vm70) or from files.pharo.org >>> >> (http://files.pharo.org/get-files/70/) >>> >> >>> >> We are currently not uploading Pharo 7 images to files.pharo.org. >>> They can >>> >> can be found here (32-bits): >>> >> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ >>> >> >>> >> -- Pavel >>> >> >>> >> >>> >> 2017-07-08 21:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com >>> >: >>> >>> >>> >>> Hi >>> >>> >>> >>> I realized that I forgot where I could find the latest 70 and vm. >>> >>> So I could not update the web site >>> >>> >>> >>> Stef >>> >>> >>> >> >>> >>> >> >

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Nicolai Hess

2017-07-10 11:22 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote: > > > > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > > However the real question is if we need them in the form we had them > until > > now because they are flattened as soon as a new changes file > (release) is > > created and it stores only information about the last person who > touched > > the method, not about the author nor wider history. > > > > For me, YES! > > > > I always take this data as a hint to track down bugs. Especially in > > this community were different people do bug fixes or introduce > > something new /change something, it is really helpfull and valueable > > to track this changes by the method history. (not only *who* did the > > change, but also, in what context, what else had changed. And I think > > it is much easier to do this from within the image instead of looking > > at the git diff). > > Are the two really mutually exclusive? Given the move to Iceberg > wouldn't it make sense to extend Iceberg to be able to analyse the git > history from within the image? > No, they are not mutually exclusive, it is just that you can not see the history now. Maybe iceberg will solve this, but for now you can not see the history (and as a windows user, I can not even use iceberg). > > > > That hte history is already lost when we created a new changes/sources > > for release is something that always disturbed me. And I hoped there > > would be some way to reload the "real" history with all intermediate > > changes. > > Cheers, > Alistair > > >

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Alistair Grant

On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote: > > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > However the real question is if we need them in the form we had them until > now because they are flattened as soon as a new changes file (release) is > created and it stores only information about the last person who touched > the method, not about the author nor wider history. > > For me, YES! > > I always take this data as a hint to track down bugs. Especially in > this community were different people do bug fixes or introduce > something new /change something, it is really helpfull and valueable > to track this changes by the method history. (not only *who* did the > change, but also, in what context, what else had changed. And I think > it is much easier to do this from within the image instead of looking > at the git diff). Are the two really mutually exclusive? Given the move to Iceberg wouldn't it make sense to extend Iceberg to be able to analyse the git history from within the image? > That hte history is already lost when we created a new changes/sources > for release is something that always disturbed me. And I hoped there > would be some way to reload the "real" history with all intermediate > changes. Cheers, Alistair

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Nicolai Hess

2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > However the real question is if we need them in the form we had them until > now because they are flattened as soon as a new changes file (release) is > created and it stores only information about the last person who touched > the method, not about the author nor wider history. > For me, YES! I always take this data as a hint to track down bugs. Especially in this community were different people do bug fixes or introduce something new /change something, it is really helpfull and valueable to track this changes by the method history. (not only *who* did the change, but also, in what context, what else had changed. And I think it is much easier to do this from within the image instead of looking at the git diff). That hte history is already lost when we created a new changes/sources for release is something that always disturbed me. And I hoped there would be some way to reload the "real" history with all intermediate changes. > > > > > > 2017-07-10 10:15 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> >> >> On Sun, Jul 9, 2017 at 10:10 PM, Henrik Nergaard <draagren(a)outlook.com> >> wrote: >> >>> Hi, >>> >>> I had a look at the Pharo 7.0 today and see metadata for methods (Author >>> and timestamp) has been removed*, what is the reason for this? >>> >>> Having the ability to find methods created around the same time and/or >>> by author is quite useful when fixing bugs in the core libraries. >>> >>> There is also quite a lot of history that is lost as well with this >>> change (I am always impressed when I stumble upon methods over 15-20 years >>> old!). >>> >>> >>> >>> Could this be reverted, please? >>> >>> [*] all methods have a stamp, but it is the same for all with only a >>> timestamp from the bootstrap(?). >>> >>> >> Hi Henrik, >> >> I'm sorry about that, it's probably a side effect of the bootstrap. We >> may have to track down the cause, so if you can help, it's most welcome :). >> For that I can explain you the process as it is today: >> >> 1st) We previously exported all code from Pharo to FileTree >> (Metadataless I think). This step is not done anymore. >> 2nd) We bootstrap from the packages on FileTree by first compiling >> methods without metadata. >> >> 3rd) We export all bootstrap packages from filetree to MCZ >> >> https://github.com/pharo-project/pharo/blob/development/ >> bootstrap/src/Pharo30Bootstrap.package/PBBootstrap.class/ >> instance/exportAllPackagesIntoMcz.st >> >> 4th) Once the first image is ready (without source code nor meta-data) >> we install monticello and we reload all mcz files >> This regenerates the source code and should load all metadata in >> mczs >> >> https://github.com/pharo-project/pharo/blob/development/ >> bootstrap/scripts/02-monticello-bootstrap/02-bootstrapMonticello.st >> >> So either it is that the metadata is lost in Filetree because it is >> metadataless, or it is lost in the intermediate conversion to mcz, or in >> the loading. >> >> Guille >> >> >>> >>> >>> Best regards, >>> >>> Henrik >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> 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 <+33%206%2052%2070%2066%2013> >> > >

July 10, 2017

Re: [Pharo-dev] latest 70 and vm

by Pavel Krivanek

Now we can get the latest Pharo 7 (32-bit only) by zero-conf: http://get.pharo.org/70+vm http://get.pharo.org/70 etc. Be sure that you have a virtual machine suitable for Pharo 7 (it contains newer libgit2 version). Pharo 7 is distributed in three files: image, changes and sources file that is unique for every bootstrapped version, so if you use the zero-conf scripts (e.g. on a CI), keep this in mind. Cheers, -- Pavel 2017-07-09 16:15 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > I added upload of 32-bit version to CI so the link for the download of the > version 7 starts to return proper result (for minimal image not). > > The link is http://files.pharo.org/image/70/latest.zip > > We still cannot use zero-conf because the script cannot process the new > sources. > > -- Pavel > > 2017-07-09 14:12 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> In fact I cannot access it. So when esteban is back and fix the web >> site we should not forget to update this. >> >> On Sun, Jul 9, 2017 at 2:04 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> > Tx pavel I will update the website. >> > >> > >> > On Sat, Jul 8, 2017 at 10:06 PM, Pavel Krivanek >> > <pavel.krivanek(a)gmail.com> wrote: >> >> the VM for Pharo 7 is available by zero-conf scripts >> >> (http://get.pharo.org/vm70) or from files.pharo.org >> >> (http://files.pharo.org/get-files/70/) >> >> >> >> We are currently not uploading Pharo 7 images to files.pharo.org. >> They can >> >> can be found here (32-bits): >> >> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ >> >> >> >> -- Pavel >> >> >> >> >> >> 2017-07-08 21:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> >> >>> Hi >> >>> >> >>> I realized that I forgot where I could find the latest 70 and vm. >> >>> So I could not update the web site >> >>> >> >>> Stef >> >>> >> >> >> >> >

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Pavel Krivanek

The metadata are lost because of the metadata-less FileTree format. In FileTree the method metadata are not stored in the method file but in a class specific file. All methods metadata in one file. If you use FileTree with metadata, it causes a lot of needless changes and conflicts. So we have no methods metadata because the repository does not contain them. However the real question is if we need them in the form we had them until now because they are flattened as soon as a new changes file (release) is created and it stores only information about the last person who touched the method, not about the author nor wider history. What we need to do is to export older versions to the Pharo Git repository and take method history information from the VCS. Do not try to duplicate VCS behavior with the changes file because the purpose of changes file is different. Cheers, -- Pavel 2017-07-10 10:15 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Sun, Jul 9, 2017 at 10:10 PM, Henrik Nergaard <draagren(a)outlook.com> > wrote: > >> Hi, >> >> I had a look at the Pharo 7.0 today and see metadata for methods (Author >> and timestamp) has been removed*, what is the reason for this? >> >> Having the ability to find methods created around the same time and/or by >> author is quite useful when fixing bugs in the core libraries. >> >> There is also quite a lot of history that is lost as well with this >> change (I am always impressed when I stumble upon methods over 15-20 years >> old!). >> >> >> >> Could this be reverted, please? >> >> [*] all methods have a stamp, but it is the same for all with only a >> timestamp from the bootstrap(?). >> >> > Hi Henrik, > > I'm sorry about that, it's probably a side effect of the bootstrap. We may > have to track down the cause, so if you can help, it's most welcome :). For > that I can explain you the process as it is today: > > 1st) We previously exported all code from Pharo to FileTree (Metadataless > I think). This step is not done anymore. > 2nd) We bootstrap from the packages on FileTree by first compiling > methods without metadata. > > 3rd) We export all bootstrap packages from filetree to MCZ > > https://github.com/pharo-project/pharo/blob/development/bootstrap/src/ > Pharo30Bootstrap.package/PBBootstrap.class/instance/ > exportAllPackagesIntoMcz.st > > 4th) Once the first image is ready (without source code nor meta-data) we > install monticello and we reload all mcz files > This regenerates the source code and should load all metadata in > mczs > > https://github.com/pharo-project/pharo/blob/development/bootstrap/scripts/ > 02-monticello-bootstrap/02-bootstrapMonticello.st > > So either it is that the metadata is lost in Filetree because it is > metadataless, or it is lost in the intermediate conversion to mcz, or in > the loading. > > Guille > > >> >> >> Best regards, >> >> Henrik >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > 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 <+33%206%2052%2070%2066%2013> >

July 10, 2017

Re: [Pharo-dev] The new implementation of current working directory

by Alistair Grant

Hi Rajula, On Sun, Jul 09, 2017 at 10:38:42PM -0700, Rajula Vineet wrote: > Hi Alistair, > > ------------------------------------------------------------------------------- > > From: Alistair Grant [via Smalltalk] <ml+[hidden email]> > Sent: Monday, July 3, 2017 7:29 PM > To: Rajula Vineet Reddy(IMT2014045) > Subject: Re: The new implementation of current working directory > > Hi Rajula, > > On Thu, Jun 29, 2017 at 05:42:02AM -0700, Rajula Vineet wrote: > > > Hi all, > > > > As I have already been posting about my GSoC work and updates on my blog > > <https://vineetreddy.wordpress.com> and on the mailing list > > <<a href="http://forum.world.st/template/NamlServlet.jtp?macro= > search_page&node=1294792&query=gsoc+Rajula+&days=0" > target="_top" rel="nofollow" id="LPlnk372500" previewremoved="true">http:// > forum.world.st/template/NamlServlet.jtp?macro=search_page&node=1294792& > query=gsoc+Rajula+&days=0> > > . In this post, I would like to go in depth of my work on 'the working > > directory' so that I can get valuable feedback and suggestions from > > everyone. This discussion was started on an github PR > > <https://github.com/pharo-project/pharo/pull/96> which was conflicting > my > > PR. > > > It looks like my concerns were unfounded, but many thanks for taking the > trouble to follow up on this. > > > Not a problem. Indeed thanks for making me do it. I got to learn something new > and improved my knowledge on this issue. > > It would good if you could keep a similar caching strategy to the one I > introduced as the performance gains can be significant (as suggested by > Cyril's comment). > > > Yeah. Sure. I have used the same caching strategy and made changes to my pull > request. > > Thanks again, > Alistair > > Thank you, > Rajula Great! I'm looking forward to updating my scripts to use this instead of my current hack. Thanks again, Alistair

July 10, 2017