- Pharo-dev - lists.pharo.org

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

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

by Tim Mackinnon

Ok - that should rule out those changes, however it may be a sign of things to come (or maybe not - its just the discussions here made me think of what Iâm seeing). I am running the image from the command line on OSX Sierra, using 64 bit. If I run System reporter it nicely shows the problem where I have run from a directory "Pharo-6.0-64-7vmâ using .pharo-ui Pharo.image, However look at the first Monticello repository - its referencing another one of my directories - an older image that I havenât used a for a few weeks. Iâm pretty sure this current image was a fresh one downloaded with zeroconf as I was following Estebans instructions to use the 7 vm with a pharo6 image, and I had to do it a particular way as I quizzed him on it just a few days ago. I guess I will go and try it with a new image and see if I get the same results - but Iâm wondering if there is a latent problem in here somehow? Image ----- /Users/macta/Dev/Smalltalk/Pharo/Pharo-6.0-64-7vm/Pharo.image Pharo6.0 Latest update: #60506 Unnamed Monticello Repositories ----------------------- /Users/macta/Dev/Smalltalk/Pharo/Pharo-6-60495-c/pharo-local/package-cache http://smalltalkhub.com/mc/Pharo/Athens/main/ http://smalltalkhub.com/mc/PharoExtras/CatalogBrowser/main/ http://smalltalkhub.com/mc/PharoExtras/Tool-DependencyAnalyser/main/ http://smalltalkhub.com/mc/MartinDias/Epicea/main/ http://smalltalkhub.com/mc/estebanlm/FastTable/main/ http://smalltalkhub.com/mc/YuriyTymchuk/ScrapYard/main/ http://smalltalkhub.com/mc/Pharo/Fuel/main/ http://smalltalkhub.com/mc/Moose/GToolkit/main/ http://smalltalkhub.com/mc/Moose/Glamour/main/ http://smalltalkhub.com/mc/Pharo/OSWindow/main/ http://smalltalkhub.com/mc/NicolaiHess/Playground/main/ http://smalltalkhub.com/mc/StephaneDucasse/AutomaticMethodCategorizer/main/ http://smalltalkhub.com/mc/Pharo/SessionManager/main/ http://smalltalkhub.com/mc/dalsat/ShoreLine-Reporter/main/ http://ss3.gemstone.com/ss/STON http://smalltalkhub.com/mc/Pharo/TxText/main/ http://smalltalkhub.com/mc/Pharo/FFI-NB/main/ http://smalltalkhub.com/mc/PharoExtras/Versionner/main/ http://smalltalkhub.com/mc/PharoExtras/BitmapCharacterSet/main/ http://smalltalkhub.com/mc/PharoExtras/XMLParser/main/ http://smalltalkhub.com/mc/Pharo/XMLWriter/main/ http://mc.stfx.eu/ZincHTTPComponents http://smalltalkhub.com/mc/Pharo/Pharo60/main http://smalltalkhub.com/mc/Pharo/Pharo60Inbox/main github://pharo-vcs/iceberg:master github://pharo-vcs/libgit2-pharo-bindings:v0.25.1 https://github.com/svenvc/NeoJSON/tree/master/repository https://github.com/svenvc/NeoJSON https://github.com/svenvc/NeoJSON/tree http://mc.stfx.eu/Neo github://svenvc/NeoJSON:master/repository filetree:///Users/macta/Dev/Smalltalk/Pharo/Pharo-6.0-64-7vm/pharo-local/iceberg/macta/PharoLambda Virtual Machine --------------- /Users/macta/Dev/Smalltalk/Pharo/Pharo-6.0-64-7vm/pharo-vm/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 VM: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sat Jul 1 16:38:23 2017 -0700 $ Plugins: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Mac OS X built on Jul 1 2017 23:57:21 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString VM: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sat Jul 1 16:38:23 2017 -0700 $ Plugins: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 > 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

Esteban's ChangeLog week of 3 July 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 3 July 2017 to 9 July 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=3/7/2017&to=9/7/2017 ChangeLog ========= 6 July 2017: ------------ * Tuesday I spend the full day trying to get the windows VM to compile on my environment, and I failed completely because I don't know why, +pkgconfig+ is crashing. I need to doit to review some problems of the VM on windows, but well, I decided to jump to better places for the moment, and then I've been working on a Pull Request tool, which first version is now released on [Iceberg 0.5.1](https://github.com/pharo-vcs/iceberg/tree/v0.5.1) . You can check details on this [mail](http://forum.world.st/ANN-Iceberg-0-5-1-with-Pull-Request-review-tool-td4953751.html). 3 July 2017: ------------ * I made default vm for linux (for P7) the default VM. I also updated [zeroconf](http://get.pharo.org) to add a new type of download for linux: the explicit iTimer heartbeat download. So, for P7, if you download the default stable VMâ¦ it will be a threaded VM. Take that into account :) * And now I also release [Iceberg 0.5](https://github.com/pharo-vcs/iceberg/releases/tag/0.5) :) == Major changes this release: * works on 64bits * adds cherry-pick == Other * important revision of the sync process. Now is a lot smarter and relies much more on libgit2. Not perfect, but we are getting there :) * branch-in-image is in sync with branch-in-local (the other way was a mess) * other bugfixes * I released a new stable VM for [Pharo 7.0](http://files.pharo.org/get-files/70). This is to catch up with latest fixes made by Eliot but mostly to update libgit2 library (and include it in mac64 distribution). cheers! Esteban

July 10, 2017

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

by Rajula Vineet

Hi Alistair, ________________________________ From: Alistair Grant [via Smalltalk] <ml+s1294792n4953299h23(a)n4.nabble.com> 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 > <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> > . 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 > Firstly, I would like to go through the current implementation of the > working directory. With this implementation, when you use the > defaultWorkingDirectory method, the directory in which the running image is > present in, is returned. This is not a completely good working because when > you run the image from a different directory like './pharo ../Pharo.image' > the working directory is the one in which your image resides. But that isn`t > your actual working directory. Due to this, > > 1. Pharo cannot be installed as a normal application in a read-only > environment. > 2. Pharo wrongly reads and writes files relative to the 'working directory'. > 3. It also makes scripting difficult. > > In the FogBugz issue here > <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there > is an example which explains the problem. > > Let say the Pharo VM and Image are in the directory "~/Pharo", > and I wrote a script in "~/Documents/Pharo-scripts" called > "perfect-numbers.st" > > I have 2 possibilities: > > cd ~/Pharo && pharo Pharo.image st > ~/Documents/Pharo-scripts/perfect-numbers.st // works > > or > > cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st > perfect-numbers.st // doesn't work... > > It doesn't work because when pharo wants to load the file, > it tries to locate it with: FileSystem disk workingDirectory !!! > which is NOT the current working directory." > > I hope you get the problem. > > So for the new implementation <https://github.com/rajula96reddy/pharo-cli> [https://avatars1.githubusercontent.com/u/9512824?v=3&s=400]<https://github.com/rajula96reddy/pharo-cli> rajula96reddy/pharo-cli<https://github.com/rajula96reddy/pharo-cli> github.com pharo-cli - Enhancements to pharo command line interface > with the help of Guille I researched about $PWD and getcwd() for a while and > wrote a new implementation. This is how it goes > 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and > 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI > 2. And a new method currentWorkingDirectoryPath and > currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the > above method and gets the working directory. > 3. To integrate this, I have patched the DiskStore method > 'defaultWorkingDirectory' to use the new methods in OSPlatform. > > I have checked all the sendors of the 'defaultWorkingDirectory' for any > issue. And I also wrote some unit tests. So, the new implementation is > working fine. With this, now I am able to get the right working directory. > The example mentioned above works perfectly. > > But, there may be a few cases where it can break interoperability between > Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' > directory and its methods should also be patched subsequently. In fact, > these problems can be tackled by running image from its own directory itself > (which is obvious ;) ) or by using the method imageDirectory in FileLocator > class explicitly when necessary. But overall a good thing is this is will > ensure the system will behave as in other languages. > > I have completed this implementation and submitted a PR > <https://github.com/pharo-project/pharo/pull/92> to github. But because of [https://avatars1.githubusercontent.com/u/9512824?v=3&s=400]<https://github.com/pharo-project/pharo/pull/92> 05723-Default-Working-Directory by rajula96reddy Â· Pull Request #92 Â· pharo-project/pharo<https://github.com/pharo-project/pharo/pull/92> github.com This is a new pull request, the last one had unnecessary commits. > some dependency issue, it has not yet been merged. With the help of my > mentor, I am working on the problem. > > Thanks for reading all this. Please give your feedback and comments on this > new implementation. Your suggestions help me in learning more about the > project and also about the organization. > > Thanks, > Rajula > > > > -- > View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… Pharo Smalltalk Developers - The new implementation of current working directory<http://forum.world.st/The-new-implementation-of-current-working-directory-t…> forum.world.st The new implementation of current working directory. Hi all, As I have already been posting about my GSoC work and updates on my blog and on the mailing list . In this post, I would like to go in... > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > ________________________________ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/The-new-implementation-of-current-working-directory-t… Pharo Smalltalk Developers - The new implementation of current working directory<http://forum.world.st/The-new-implementation-of-current-working-directory-t…> forum.world.st The new implementation of current working directory. Hi all, As I have already been posting about my GSoC work and updates on my blog and on the mailing list . In this post, I would like to go in... To unsubscribe from The new implementation of current working directory, click here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> -- 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

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

by Rajula Vineet

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

No Metadata in 7.0

by Henrik Nergaard

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

July 9, 2017