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

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

Re: [Pharo-dev] No Metadata in 7.0

by Guillermo Polito

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/Pharo… 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/0… 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

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Alistair Grant

Hi Henrik, On Sun, Jul 09, 2017 at 08:10:28PM +0000, Henrik Nergaard 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(?). > > Best regards, > > Henrik I think this is answered in: http://forum.world.st/Pharo-7-Method-Version-Browser-does-not-include-autho… Cheers, Alistair

July 10, 2017

Re: [Pharo-dev] Vm-dev Digest, Vol 133, Issue 13

by Max Leske

Hi Luke, > On 10 Jul 2017, at 09:38, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Hi Max, > > On 18 May 2017 at 13:32, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> >> We managed to figure out that OSProcess works when we use gcc <= 4.8 on >> Debian. We are happy to use 4.8 for now, so we're good. It would of course >> be super cool if we could use the series 6 gcc as that will soon ship with >> Debian 9 (stretch) but it's probably not trivial to just move to a new >> compiler version (as seems evident from the fact that a minor version >> change can mess up compilation). >> > > Thanks for tracking this problem down and sharing the details. I came upon > exactly the same problem with the Nix package and was able to work-around > that by also downgrading to gcc 4.8. I am sure it would have taken a long > time to work this out without the benefit of your experience. Sweet! Nice to know that others benefit from my work (or woes) :) > > Relatedly: Is there a suitable automated test that we can use to check that > our VMs are basically okay? I am pushing the switch to gcc 4.8 to resolve > this problem but I don't know whether this is causing other regressions or > what other obvious problems I have missed. I'd love a bit of test coverage > for the builds. There are tests that are being run for every commit to https://github.com/opensmalltalk/opensmalltalk-vm <https://github.com/opensmalltalk/opensmalltalk-vm>. Unfortunately, they don't explicitly include VM plugin related things. Also, the build is pretty much fixed to a specific GCC version by the build setup (depends on what Travis CI offers, for instance). I fully agree, that it would be very helpful to have a more elaborate test suite that would take into account things like architecture and available libraries. I think, that could be a nice project for an intern, or a bachelor's thesis (cc'ing pharo-dev and squeak-dev). As long as we don't have that, I'd use the GCC version from the build. You can get to that by browsing the latest build on travis and searching the log for "gcc" (currently version 4.6.3 on Ubuntu Precise). Cheers, Max

July 10, 2017

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

by Alistair Grant

Hi Tim, On Mon, Jul 10, 2017 at 07:32:12AM +0100, Tim Mackinnon wrote: > Just as a side note - a quick spot check of my other recent images (1 > 64 bit normal 6.0 and another 32 bit 6.0, are all correct) - its just > the one where I used the newer vm. I'm not aware of all the changes that have gone in to the newer VMs, but it's not the first place I'd look in trying to track this down. And I'm not familiar enough with Monticello / Metacello to make any guided suggestions, sorry. Going back to one of your earlier emails, what is the result of: self workingDirectory resolve If that confirms the problem, maybe you could use the debugger to step through and see what it is being resolved against. Cheers, Alistair > Tim > > > On 10 Jul 2017, at 06:32, Rajula Vineet <Vineet.Reddy(a)iiitb.org> > > wrote: > > > > Hey Tim, > > > > The new implementation hasn`t been merged into the pharo code base. > > This error is not related to the new implementation. Probably it is > > related to your local directories. Are you using a linux? Are you > > running from the image directory? If you don`t, the path changes and > > pharo can not find the cache directory. > > > > Rajula

July 10, 2017

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

by Tim Mackinnon

Just as a side note - a quick spot check of my other recent images (1 64 bit normal 6.0 and another 32 bit 6.0, are all correct) - its just the one where I used the newer vm. Tim > On 10 Jul 2017, at 06:32, Rajula Vineet <Vineet.Reddy(a)iiitb.org> wrote: > > Hey Tim, > > The new implementation hasn`t been merged into the pharo code base. This > error is not related to the new implementation. Probably it is related to > your local directories. Are you using a linux? Are you running from the > image directory? If you don`t, the path changes and pharo can not find the > cache directory. > > Rajula > > > > -- > View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 10, 2017