On Mon, Jul 3, 2017 at 2:00 PM, <estebanlm@gmail.com> wrote:
Hello!
This is my weekly ChangeLog, from 26 June 2017 to 2 July 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=26/6/2017&to=2/7/2017
ChangeLog =========
29 June 2017: -------------
* ... and I spent some time figuring out why windows users have a persistent error about access files.
We should always remember the windows path limitations (256) :)
Now, the workaround for this is to execute this in command line:
---- git config --system core.longpaths true ----
but of course, this is just a workaround because people using Iceberg could not hava installed a command line git client. I will need to check in the future this :(
Nice pickup. I notice this command creates the file /etc/gitconfig like this... [core] longpaths = true and instead using --local update $ cp .git/config /tmp/oldconfig $ git config --local core.longpaths true $ diff .git/config /tmp/oldconfig 6d5 < longpaths = true Sorry I don't have time to test further, but if --local has the same positive effect per repo as --global, could Pharo modify the config text file directly?
* I spent some time trying to get [Iceberg version dev-0.5]( https://github.com/pharo-vcs/iceberg/tree/dev-0.5) to load properly (yesterday's script is not working).
The reason is that +Metacello+ fails to upgrade packages from a baseline. And there is no way (at least that I found) to force the upload.
So this is the updated script to test dev-0.5:
1. Download latest vm and image.
---- wget -O- get.pharo.org/64/70+vmLatest | bash wget -O- get.pharo.org/64/70+vmTLatest | bash # for linux systems ----
2. Execute this on your image
---- #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGit') do: [ :each | each asPackage removeFromSystem ].
Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:dev-0.5'; load. ----
This should actually remove old iceberg version then install new one.
28 June 2017: -------------
* Ok, I get the VM to compile correctly with the new libgit2 version, and now +latest vm+ comes with +libgit 0.25.1+ for both 32 and 64 bits versions.
I also made some minor fixes to +iceberg dev-0.5+ and it should be ready to test and release. This version incorporates some important changes that will allow us to work with it to make changes to Pharo itself (and that will be noticed on big projects):
* it has cherry-pick. * it speeds up sincronization by introducing more precise comparisons instead making a "full scan"
sincronization = something naughty you do at regular intervals ?? %^)
* it keeps in sync branch on disk and branch on iceberg (before it was keeping them separately and it was very confusing)
To test it, you can execute:
---- wget -O- get.files.org/64/70+vmLatest | bash wget -O- get.files.org/64/70+vmTLatest | bash # on linux systems ----
then you will need to load version +dev-0.5+ :
---- Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:dev-0.5'; load. "And you will need to execute this... I will need to update the baseline with this, now that I think :)" LGitExternalStructure allSubclassesDo: #compileFields. ----
* I finished ensuring [iceberg](https://github.com/ pharo-vcs/iceberg/tree/dev-0.5) will work on 64 bits.
Now, I needed to make some fixes for UFFI, which I put in [case: 20198](https://pharo.fogbugz.com/f/cases/20198) (it is imperative to include this to be able to backport 0.5 into Pharo 6.0). Also, I will need to promote a new VM as stable.
I'm not sure I want to backport this into Pharo 6. I know I promised but complications are... more than benefits, I think: You will need a new VM. People will not know that and they will download a P6 image with the older VM and this will cause problems.
Maybe is better to move all this to P7?
cheers! Esteban