- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FileSystem file attributes and #isSymlink patch

by Max Leske

Nice work Alistair! On 24 July 2017 at 10:10:09, Alistair Grant (akgrant0710(a)gmail.com) wrote: Hi All, I'm nearly ready to submit a patch that started with the goal of being able to retrieve the device id and fixing FileReference>>isSymlink and also follows Esteban's suggestion of splitting out file existence and other attributes (which provides a performace gain). See the summary below for a description of the changes. The patch involves adding a new VM plugin, FileAttriubutesPlugin. To minimise the chance of any problems along the way I'd like to submit the patch in three steps: 1. Add the VM plugin (FileAttributesPlugin) 2. Add the code the image that allows testing of the code and plugin, but doesn't do any integration with existing functionality. This will allow the plugin to be tested by a few volunteers (hopefully). 3. Add the patches that make the switch over to the new implementation. Can someone point me to how to submit a new VM plugin? The code is contained in a subclass of InterpreterPlugin. I've been using this as my production environment for about 2 months now on a linux 32 bit VM. Running the full test suite results in the same set of test failing before and after applying the patch. I've also ran file related tests on linux 64 bit (run the Test Runner, select all packages with "file" as part of the name and run all the available tests) and the full test suite on Windows 32 bit. The summary is: 1. #isSymlink now works properly on Linux (and it should also work on MacOS and BSD). 2. The list of file attributes available from FileReference now is: #accessTime (new) #changeTime (new) #creationTime #deviceId (new) #exists #gid (new) #inode (new) #isBlock (new) #isCharacter (new) #isDirectory #isExecutable (new) #isFIFO (new) #isFile #isReadable #isRegular (new) #isSocket (new) #isSymlink (works) #isWritable #modificationTime #numberOfHardLinks (new) #permissions #size #targetFile (new) #uid (new) 3. FileReference>>exists is faster than before (well, at least on my linux laptop). This is useful as it is called quite often. 4. It is possible to retrieve symbolic link attributes, e.g. all the attributes listed above plus the target path. Given how similar MacOS and BSD are to linux, I assume that this will all work without problem on those platforms (but it obviously needs to be tested). As implied above, the changes are all backward compatible (except the broken #isSymlink), although a couple deserve mention: 1. Obviously #isSymlink now answers correctly (previously it would only answer correctly for a broken link). 2. Requesting any of the attributes listed above (except #isSymlink) will return the value of the target path. If the FileReference is to a broken symbolic link, it will return the attributes of the symbolic link (keeping existing behaviour). 3. The attributes of a symbolic link can be retrieved using FileReference>>symlinkAttributes. Overall, performance is slightly better than before. Code that needs to access multiple attributes and is written to take advantage of the new behaviour will see significant performance improvements. If you've got this far and forgotten the original question :-) Can someone point me to how to submit a new VM plugin? Thanks, Alistair

July 24, 2017

Re: [Pharo-dev] New Launcher not working (Windows)

by Christophe Demarey

Hi Jan, Iâm currently updating the Pharo Launcher so that it can determine the right VM to use to launch an image and download it if not available on disk. It is almost finished but not yet ready! On Windows, there was indeed a bug in the executable name to find. It is now fixed on the latest build but I do not think the Launcher will work because the vm for 60 is buggy. OSProcess (used by the launcher) cannot work wit this VM. Iâm waiting the publication of Pharo 6.1 with its VM (with OSProcess bug fixed) to publish and announce the new Launcher version. If you do not want to wait, you can replace the pharo 6.0 vm shipped with the Launcher with a Pharo 70 vm. It will work. Regards, Christophe Le 24 juil. 2017 Ã 00:28, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> a Ã©crit : > > Hello > > It seems I am not able to open an image via new Launcher for Windows. > I have downloaded new build of Pharo Launcher for Windows from > https://ci.inria.fr/pharo/job/Launcher-Win/ ( pharo_installer-0.2.13.exe ) > and it starts ok, downloads image ok, but I am unable to open it, although > opening images works fine in older launcher ( pharo_installer-0.2.11.exe > from 28. 2. 2017). > > First time I tried opening the image (double clicking on it in the list), > loading bar "Determining Image version" showed up and remained frozen like > that without any progress shown in the bar. I gave it 10 minutes, but no > change, still stuck like that. UI was not responding, so I terminated it via > alt+. > > Second time I tried opening the image via the Launcher, that "Determining" > bar was there only for a second and then it was replaced by "Fetching VM to > run Pharo 60 images" which seemed to be really fetching something, but after > another second or two, it got stuck in the middle of the process and got an > error "KeyNotFound: key '60' not found in Dictionary". > > Well, it seemed like I got further, so third time is a charm. This time, > instead of previous error, I got "FileExists: File > @C:\Users\User\Documents\Pharo\vms\60.zip", which is quite understandable > since previous process did not successfully cleaned up after itself. > > I tried it repeatedly, tried it with both old (already existing) and new > images (downloaded in new Launcher) and I tried removing whole Pharo folder > in Documents, but every time I get stuck with one of those problems above. > > There is a PharoDebug.log with logs of interrput and errors mentioned above: > PharoDebug.log <http://forum.world.st/file/n4956495/PharoDebug.log> > > Note that I can open those images just fine by opening them directly from > Windows file explorer or via old Launcher, just not in the new Launcher. > > Windows 10 Pro v1703 64bit. > > Thank you > Jan > > > > > -- > View this message in context: http://forum.world.st/New-Launcher-not-working-Windows-tp4956495.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 24, 2017

FileSystem file attributes and #isSymlink patch

by Alistair Grant

Hi All, I'm nearly ready to submit a patch that started with the goal of being able to retrieve the device id and fixing FileReference>>isSymlink and also follows Esteban's suggestion of splitting out file existence and other attributes (which provides a performace gain). See the summary below for a description of the changes. The patch involves adding a new VM plugin, FileAttriubutesPlugin. To minimise the chance of any problems along the way I'd like to submit the patch in three steps: 1. Add the VM plugin (FileAttributesPlugin) 2. Add the code the image that allows testing of the code and plugin, but doesn't do any integration with existing functionality. This will allow the plugin to be tested by a few volunteers (hopefully). 3. Add the patches that make the switch over to the new implementation. Can someone point me to how to submit a new VM plugin? The code is contained in a subclass of InterpreterPlugin. I've been using this as my production environment for about 2 months now on a linux 32 bit VM. Running the full test suite results in the same set of test failing before and after applying the patch. I've also ran file related tests on linux 64 bit (run the Test Runner, select all packages with "file" as part of the name and run all the available tests) and the full test suite on Windows 32 bit. The summary is: 1. #isSymlink now works properly on Linux (and it should also work on MacOS and BSD). 2. The list of file attributes available from FileReference now is: #accessTime (new) #changeTime (new) #creationTime #deviceId (new) #exists #gid (new) #inode (new) #isBlock (new) #isCharacter (new) #isDirectory #isExecutable (new) #isFIFO (new) #isFile #isReadable #isRegular (new) #isSocket (new) #isSymlink (works) #isWritable #modificationTime #numberOfHardLinks (new) #permissions #size #targetFile (new) #uid (new) 3. FileReference>>exists is faster than before (well, at least on my linux laptop). This is useful as it is called quite often. 4. It is possible to retrieve symbolic link attributes, e.g. all the attributes listed above plus the target path. Given how similar MacOS and BSD are to linux, I assume that this will all work without problem on those platforms (but it obviously needs to be tested). As implied above, the changes are all backward compatible (except the broken #isSymlink), although a couple deserve mention: 1. Obviously #isSymlink now answers correctly (previously it would only answer correctly for a broken link). 2. Requesting any of the attributes listed above (except #isSymlink) will return the value of the target path. If the FileReference is to a broken symbolic link, it will return the attributes of the symbolic link (keeping existing behaviour). 3. The attributes of a symbolic link can be retrieved using FileReference>>symlinkAttributes. Overall, performance is slightly better than before. Code that needs to access multiple attributes and is written to take advantage of the new behaviour will see significant performance improvements. If you've got this far and forgotten the original question :-) Can someone point me to how to submit a new VM plugin? Thanks, Alistair

July 24, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> What is the system you use? >>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work on >>> Windows... >>> >>> -- Pavel >>> >> >> windows 10 32 bit >> > > and on another windows 10 64 bit system > > on both, it crashes on working with libgit/iceberg > Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ? Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ? > > >> >> >>> >>> 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>> >>>> >>>> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>>> >>>>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>> >>>>>> And if I only want to contribute by reviewing a fix. Do I have to go >>>>>> the git-path ? >>>>>> Or is there a way to just start up an image and load and review the >>>>>> change? >>>>>> >>>>>> >>>>>> right now, you can review by going to github and seeing. >>>>>> I will add a âPR toolâ to view/load PRs into an image, but thatâs not >>>>>> ready. If someone wants to take a hit on itâ¦ the idea is to extend the >>>>>> github plugin with it :) >>>>>> >>>>>> cheers! >>>>>> Esteban >>>>>> >>>>> >>>>> Anyone got this working on windows (32) ? >>>>> I followed this guide, enabled the ssh key setting for iceberg. >>>>> But I still got the error : >>>>> >>>>> Image: Pharo7.0SNAPSHOT [Latest update: #0] >>>>> >>>>> LGitReturnCodeEnum>>handleLGitReturnCode >>>>> Receiver: a LGitReturnCodeEnum(#git_error [-1]) >>>>> Arguments and temporary variables: >>>>> handler: LGit_GIT_ERROR >>>>> Receiver's instance variables: >>>>> value: -1 >>>>> >>>>> >>>>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo: >>>>> Receiver: a LGitRepository (<not initialized>) >>>>> Arguments and temporary variables: >>>>> callBlock: [ self >>>>> clone: self >>>>> url: aString >>>>> local_path: aFileReference pathSt...etc... >>>>> Receiver's instance variables: >>>>> handle: @ 16r00000000 >>>>> repositoryPath: File @ pharo-core >>>>> isOpen: nil >>>>> workingDirectory: nil >>>>> >>>>> >>>>> LGitRepository>>clone:options:to: >>>>> Receiver: a LGitRepository (<not initialized>) >>>>> Arguments and temporary variables: >>>>> aString: 'git@github.com:pharo-project/pharo.git' >>>>> cloneOptions: a LGitCloneOptions () >>>>> aFileReference: File @ pharo-core >>>>> Receiver's instance variables: >>>>> handle: @ 16r00000000 >>>>> repositoryPath: File @ pharo-core >>>>> isOpen: nil >>>>> workingDirectory: nil >>>>> >>>>> >>>>> And finally after some more tries, the vm crashed >>>>> (crash.dmp attached). >>>>> >>>>> If this only happens on windows, what else would be an option to start >>>>> with contributing for pharo 7 ? >>>>> >>>> >>>> maybe I am doing something wrong ? I thought this should work now with >>>> the latest vm (and libgit)? >>>> It is still crashing for me. >>>> >>>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class >>>> failed >>>> [0mExternalAddress class(Object)>>primitiveFailed: >>>> ExternalAddress class(Object)>>primitiveFailed >>>> ExternalAddress class>>allocate: >>>> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >>>> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >>>> LGitRemoteCallbacks class>>defaults >>>> LGitRemoteCallbacks class>>withProvider: >>>> LGitCloneOptions class>>withCredentialsProvider: >>>> [ | repo cloneOptions | >>>> repo := LGitRepository on: self location. >>>> cloneOptions := LGitCloneOptions >>>> withCredentialsProvider: IceCredentialsProvider default. >>>> repo clone: url options: cloneOptions. >>>> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >>>> (LGitRemote of: repo named: 'origin') >>>> lookup; >>>> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >>>> in Block: [ | repo cloneOptions |... >>>> [ self checkInitialized. >>>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class >>>> failed >>>> [0mExternalAddress class(Object)>>primitiveFailed: >>>> ExternalAddress class(Object)>>primitiveFailed >>>> ExternalAddress class>>allocate: >>>> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >>>> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >>>> LGitRemoteCallbacks class>>defaults >>>> LGitRemoteCallbacks class>>withProvider: >>>> LGitCloneOptions class>>withCredentialsProvider: >>>> [ | repo cloneOptions | >>>> repo := LGitRepository on: self location. >>>> cloneOptions := LGitCloneOptions >>>> withCredentialsProvider: IceCredentialsProvider default. >>>> repo clone: url options: cloneOptions. >>>> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >>>> (LGitRemote of: repo named: 'origin') >>>> lookup; >>>> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >>>> in Block: [ | repo cloneOptions |... >>>> [ self checkInitialized. >>>> aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self >>>> checkInitialized.... >>>> [ activeProcess psValueAt: index put: anObject. >>>> aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: >>>> in Block: [ activeProcess psValueAt: index put: anObject.... >>>> BlockClosure>>ensure: >>>> LGitActionSequence(DynamicVariable)>>value:during: >>>> LGitActionSequence class(DynamicVariable class)>>value:during: >>>> LGitGlobal class>>runSequence: >>>> IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >>>> IceRepositoryCreator>>createRepository >>>> UndefinedObject>>DoIt >>>> >>>> VM windows 32 bit: >>>> CoInterpreter VMMaker.oscog-eem.2252 uuid: >>>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >>>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 >>>> VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >>>> $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >>>>>> pavel.krivanek(a)gmail.com>: >>>>>> >>>>>> >>>>>> >>>>>> 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Just to be clear, in Pharo 7, if I want to get some code integrated: >>>>>>> - I *have to* use the pull request process described by Pavel >>>>>>> OR >>>>>>> - I *can* use the pull request process, but I can also use the old >>>>>>> slice monticello process >>>>>>> ? >>>>>>> >>>>>>> What is the answer to the first question now, and what will be the >>>>>>> answer of this question in 6 months from now ? >>>>>>> >>>>>> >>>>>> You should use the pull request process. >>>>>> >>>>>> It is possible to create a standard slice BUT it must be done from >>>>>> Pharo 6 and then sent into Pharo60Inbox. And then you need to wait until >>>>>> somebody converts this slice to pull request. That means that it will be >>>>>> harder and harder to contribute this way because the code-base is moving. >>>>>> >>>>>> No slice will be integrated into Pharo 7 with the old process >>>>>> directly. >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < >>>>>>>> juraj.kubelka(a)icloud.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> >>>>>>>>> escribiÃ³: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>>>>>>> pavel.krivanek(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>>>>>>> serge.stinckwich(a)gmail.com>: >>>>>>>>>> >>>>>>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>>>>>> serge.stinckwich(a)gmail.com>: >>>>>>>>>>> >> >>>>>>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>>>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>>>>>>>> >> > Hi, >>>>>>>>>>> >> > >>>>>>>>>>> >> > this mail describes how to start to send pull requests to >>>>>>>>>>> Pharo 7 Github >>>>>>>>>>> >> > repository from Pharo 7. >>>>>>>>>>> >> >>>>>>>>>>> >> Thank you for the great explanation Pavel. >>>>>>>>>>> >> >>>>>>>>>>> >> > Preparations >>>>>>>>>>> >> > ===================== >>>>>>>>>>> >> > >>>>>>>>>>> >> > - you need to have a Github account and set SSH keys. See >>>>>>>>>>> >> > https://help.github.com/articl >>>>>>>>>>> es/connecting-to-github-with-ssh/ >>>>>>>>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>>>>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" >>>>>>>>>>> button and >>>>>>>>>>> >> > follow >>>>>>>>>>> >> > the instructions >>>>>>>>>>> >> >>>>>>>>>>> >> [ ... ] >>>>>>>>>>> >> >>>>>>>>>>> >> > Issue processing >>>>>>>>>>> >> > ===================== >>>>>>>>>>> >> > >>>>>>>>>>> >> > - create new case on FogBugz to get the issue number >>>>>>>>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>>>>>>>> repository do: >>>>>>>>>>> >> > Pharo >>>>>>>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID >>>>>>>>>>> and it will >>>>>>>>>>> >> > fill >>>>>>>>>>> >> > the full branch name for you >>>>>>>>>>> >> > - create your changes (you can do it before the creation of >>>>>>>>>>> the branch >>>>>>>>>>> >> > too) >>>>>>>>>>> >> > - commit and push your changes in Iceberg, this way you >>>>>>>>>>> will commit your >>>>>>>>>>> >> > branch to your fork repository. Remember that the Iceberg >>>>>>>>>>> commit window >>>>>>>>>>> >> > has >>>>>>>>>>> >> > two buttons, one for local commit, the second for commit >>>>>>>>>>> with immediate >>>>>>>>>>> >> > push. They can be very long because they contain the full >>>>>>>>>>> branch (issue) >>>>>>>>>>> >> > name >>>>>>>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: >>>>>>>>>>> Pharo - Create >>>>>>>>>>> >> > pull >>>>>>>>>>> >> > request, fill your >>>>>>>>>>> >> > - fill your Github credentials >>>>>>>>>>> >> > - leave the PR title, comment is not required, check the >>>>>>>>>>> pull request >>>>>>>>>>> >> > head >>>>>>>>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>>>>>>>> Create the >>>>>>>>>>> >> > pull >>>>>>>>>>> >> > requests >>>>>>>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, >>>>>>>>>>> check your pull >>>>>>>>>>> >> > requests and put URL of it into the issue record on FogBugz >>>>>>>>>>> (as a >>>>>>>>>>> >> > comment). >>>>>>>>>>> >> > Resolve the issue as Fix review needed >>>>>>>>>>> >> >>>>>>>>>>> >> It means, there is no PR without a corresponding FogBugz >>>>>>>>>>> issue ? >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Yes, at least for code changes we would like to keep this >>>>>>>>>>> relation. If it is >>>>>>>>>>> > a really trivial change in readme or something like that, we >>>>>>>>>>> can accept no >>>>>>>>>>> > related issue record. >>>>>>>>>>> > Please prefer to comment the issues instead of PRs directly to >>>>>>>>>>> have all >>>>>>>>>>> > information at one place. >>>>>>>>>>> >>>>>>>>>>> Thank you Pavel for the explanation. >>>>>>>>>>> >>>>>>>>>>> Maybe in the future, it will make sense to put everything in the >>>>>>>>>>> PR >>>>>>>>>>> and use github issues. >>>>>>>>>>> You will use CI travis builds for all PR ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For now we will use FogBugz because it has a lot of nice features >>>>>>>>>> and good API. Maybe we will switch it in future but now we should not >>>>>>>>>> change too many things at once :-) >>>>>>>>>> For several reasons we now prefer to use own infrastructure for >>>>>>>>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>>>>>>>> can be changed in future. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> It would be interesting to see how this might fit in with our >>>>>>>>> workflow... >>>>>>>>> https://blog.fogcreek.com/fogbugz-github-integration/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What is the benefit of the integration? I do not understand it >>>>>>>>> from the given link. >>>>>>>>> >>>>>>>>> >>>>>>>> When you submit a PR on github, Fogbugz is automatically updated >>>>>>>> with a link to the PR. >>>>>>>> Presumably this makes it easier for people reviewing cases in >>>>>>>> Fogbugz to identify the slice to test. >>>>>>>> This is a better link... >>>>>>>> https://blog.fogcreek.com/improved-github-integration-automa >>>>>>>> tically-create-bug-events-with-commits/ >>>>>>>> >>>>>>>> cheers -ben >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

July 24, 2017

Esteban's ChangeLog week of 17 July 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 17 July 2017 to 23 July 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=17/7/2017&to=23/7/2017 ChangeLog ========= 20 July 2017: ------------- * I'm fixing the Pharo7 build process to finally get to the point where we can use easily the Iceberg-based process. We have two remaining problems: . Since we use plain filetree on the bootstrap process, we do not have version information of packages. . Also because of that (and because Iceberg uses metadataless format), we do not have correct timestamps. So, today (last two days, in fact), I fixed point 1, by adding a Pharo +hidden+ repository to iceberg and setting the package ancestors with correct version info. This way, all comparissons are fine :) Process is kind of complex to explain here, but basically we replace the +cypress.1+ info with a correct version with a commit reference. 19 July 2017: ------------- * I released [Iceberg v0.5.3](https://github.com/pharo-vcs/iceberg/releases/tag/v0.5.3) I needed this because the load/merge/pull times for large projects were innaceptable, mainly because after doing the pull into the local workingcopy, it was scanning all packages to see what changed and load them. This naive approach was ok for most of the projects, but those with many packages (like Pharo itself) were taking ages to perform a merge. Now we do it as the sync: we figure out packages that changed between your installed version and the upcoming version and we merge just that. Also, I fixed some other important issues: * +#isAncestorOf:+ was scanning all commits. Again, this worked for small projects. Big ones (as Pharo) were not scaling. * I created "system repository" concept. This is because Pharo7 will be dispatched with a Pharo repository but no local checkout. Then you will see an invalid project in iceberg window. This is not good because most of the times users will not care about it, but it will be annoying :) Now, if you are a Pharo developer, you can add to your startup actions this script: ---- Iceberg showSystemRepositories: true. IceRepository registry detect: [ :each | each name = 'pharo' ] ifFound: [ :each | each location: '/path/to/your/location/of/pharo-project/pharo' asFileReference ]. ---- with this, you will have always access to your Pharo repository. 17 July 2017: ------------- * I just cameback from a week off. I released a patch version of [Iceberg (0.5.2)](https://github.com/pharo-vcs/iceberg/tree/v0.5.2) mostly to fix an override problem, but incorporating some other contributions. cheers! Esteban

July 24, 2017

Re: [Pharo-dev] Epicea applying multiple changes

by Tim Mackinnon

In retrospect, this is the problem I also had - But I put it down to the UI being a bit confusing about what you were loading. I will give some constructive feedback on the UI as like others, I think the underlying idea is very good. Tim Sent from my iPhone > On 23 Jul 2017, at 22:10, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > > Hello > > Might it be related to a problem I described over here? > http://forum.world.st/Epicea-feedback-td4952661.html > > In short, I think that when I select multiple changes, epicea applies them > in wrong order, so, if for example a single method is changed two times, > Epicea first creates newer content and then replaces it by older content. It > seems to be solvable by filtering just latest changes, but I am not sure > whether it might not have other unwanted consequences. > > Jan > > > tinchodias wrote >> I'll check the bug, it's important. >> >> However, Tim and others, I'm interested in your experience with the UI. If >> you want to send me more details... >> >> Maybe I can remark: Epicea has work and feedback accumulated during my >> phd. >> Now that phd finished and Epicea comes with Pharo 6.0, the project is open >> to much more developers to collaborate with their work and feedback. So >> you >> are welcome. The project belongs to the community now even though I'm >> still >> responsible to maintain it, of course. >> >> Cheers, MartÃn >> >> On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov < > >> dionisiydk@ > >> > >> wrote: >> >>> It is issue 20223 >>> <https://pharo.fogbugz.com/f/cases/20223/Epicea-applying-collection-of-same-method-changes-uses-wrong-order> >>> >>> 2017-07-19 9:41 GMT+02:00 Tudor Girba < > >> tudor@ > >> >: >>> >>>> Hi, >>>> >>>> I experienced the same issues. It seems somehow related that when we >>>> have >>>> multiple changes to the same method, not all changes are applied and we >>>> do >>>> not get back the latest version. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Jul 18, 2017, at 10:48 AM, Andrei Chis < > >> chisvasileandrei@ > >> > >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Is there some known bug in Epicea when applying multiple changes at >>>> once in Pharo 6? >>>>> >>>>> I had a few crashes lately and each time when recovering the changes >>>> by >>>> selecting multiple changes at once some changes are skipped. If I apply >>>> manually each change it works. >>>>> >>>>> Cheers, >>>>> Andrei >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Things happen when they happen, >>>> not when you talk about them happening." >>>> >>>> >>>> >>> > > > > > > -- > View this message in context: http://forum.world.st/Epicea-applying-multiple-changes-tp4955502p4956482.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 23, 2017

New Launcher not working (Windows)

by Jan BlizniÄenko

Hello It seems I am not able to open an image via new Launcher for Windows. I have downloaded new build of Pharo Launcher for Windows from https://ci.inria.fr/pharo/job/Launcher-Win/ ( pharo_installer-0.2.13.exe ) and it starts ok, downloads image ok, but I am unable to open it, although opening images works fine in older launcher ( pharo_installer-0.2.11.exe from 28. 2. 2017). First time I tried opening the image (double clicking on it in the list), loading bar "Determining Image version" showed up and remained frozen like that without any progress shown in the bar. I gave it 10 minutes, but no change, still stuck like that. UI was not responding, so I terminated it via alt+. Second time I tried opening the image via the Launcher, that "Determining" bar was there only for a second and then it was replaced by "Fetching VM to run Pharo 60 images" which seemed to be really fetching something, but after another second or two, it got stuck in the middle of the process and got an error "KeyNotFound: key '60' not found in Dictionary". Well, it seemed like I got further, so third time is a charm. This time, instead of previous error, I got "FileExists: File @C:\Users\User\Documents\Pharo\vms\60.zip", which is quite understandable since previous process did not successfully cleaned up after itself. I tried it repeatedly, tried it with both old (already existing) and new images (downloaded in new Launcher) and I tried removing whole Pharo folder in Documents, but every time I get stuck with one of those problems above. There is a PharoDebug.log with logs of interrput and errors mentioned above: PharoDebug.log <http://forum.world.st/file/n4956495/PharoDebug.log> Note that I can open those images just fine by opening them directly from Windows file explorer or via old Launcher, just not in the new Launcher. Windows 10 Pro v1703 64bit. Thank you Jan -- View this message in context: http://forum.world.st/New-Launcher-not-working-Windows-tp4956495.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 23, 2017

Re: [Pharo-dev] Epicea feedback

by Jan BlizniÄenko

Thank you for that, since I did not managed to register those at the time. Jan tinchodias wrote > Thanks I still didn't invest time to fix them but I registered both in > fogbugz as: > > https://pharo.fogbugz.com/f/cases/20223/Epicea-check-usability-bug-to-apply… > https://pharo.fogbugz.com/f/cases/20225/Epicea-would-be-nice-is-to-have-som… > > cheers, > Martin > > On Sat, Jul 1, 2017 at 5:24 AM, Stephane Ducasse < > stepharo.self@ > > > wrote: > >> Thanks martin for your excellent support. >> What would be nice is to have some menus on the sessions items >> because often I try to click on them so see what I can do with them. >> >> Stef >> >> On Tue, Jun 27, 2017 at 4:17 PM, Martin Dias < > tinchodias@ > > wrote: >> > Hello Jan, thanks for your feedback. I will have a look asap. Feel free >> to >> > report it in fogbugz. >> > >> > MartÃn >> > >> > On Tue, Jun 27, 2017 at 8:26 AM, Jan BlizniÄenko < > bliznjan@.cvut > > >> > wrote: >> >> >> >> Hello >> >> >> >> I'd like to thank you for creating the Epicea. It is way more >> >> user-friendly >> >> and dependable than previous change-handling tool. Browsing, applying >> and >> >> reverting changes is way easier. >> >> >> >> Just one note: >> >> It is not exactly clear from first look how to properly reapply >> changes >> >> after an image has been closed without saving. If I select all changes >> I >> >> want to apply without using any filter, those changes are reapplied in >> >> wrong >> >> order (if I changed a method two times, first the new version is >> applied >> >> and >> >> then the old one). As far as I understood, I have to use filter to >> show >> >> only >> >> latest changes, but I think it could be clearer in the UI that I need >> to >> >> do >> >> so (or something completely different?) for applying changes. >> >> >> >> Thank you >> >> Jan >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> http://forum.world.st/Epicea-feedback-tp4952661.html >> >> Sent from the Pharo Smalltalk Developers mailing list archive at >> >> Nabble.com. >> >> >> > >> >> -- View this message in context: http://forum.world.st/Epicea-feedback-tp4952661p4956491.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-07-23 22:38 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com>: >> >>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> > >>> > Hm, I tried to create the build environment used for the >>> > windows vm build from opensmalltalk. >>> > >>> > I setup a cygwin environment with the same install commands as from >>> > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >>> appveyor.yml >>> > >>> > My problems, first it is missing make and wget, I can add make and >>> wget to the install command line for cygwin, but I am >>> > curious why it is working on the build server ? >>> > >>> > Anyway, after I got this working, the build stops and building the >>> pkg-config package. >>> > The log says it can not find a gcc, I know that the build process with >>> cygwin uses >>> > i686-w64-mingw32-gcc >>> > or >>> > x86_64-w64-mingw32-gcc >>> > >>> > But I don't understand where is the missing step to tell the configure >>> scripts to use the >>> > >>> > i686-w64-mingw32-gcc command instead of "gcc", >>> > >>> > again, this seems to work on the appveyor build but not locally on my >>> machine. >>> > >>> > Any idea what I had missed? >>> > >>> >>> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in >>> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and >>> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the >>> line: >>> >>> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >>> >>> to >>> >>> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bi >>> n:/usr/bin:/bin" >>> >>> And finally >>> >>> source /etc/profile >>> >>> Cheers, >>> >> >> I always had problems using mingw in the past. I got a working mingw >> environment some years ago, and a newer mingw version >> did not work well (some changes on the debug and exception format). >> But now, the build process for pharo did change. (The build instructions >> on github/pharo-vm are old and do not work anymore. >> >> And I hoped to get a more automatic and more reliable build process by >> using the same commands used by the build server for >> the opensmalltalk pharo vm sources. >> >> And I thought the compiler used to build the latest pharo-vm for windows >> is from cygwin ? >> >> >> > Hi Nicolai, > more exactly we cross compile from a cygwin environment for a mingw target. > The main reason for switching to cygwin are: > - this is required for the 64 bit vm > - the other flavours on opensmallalk (squeak/newspeak) were also built > with cygwin, so it's more simple to maintain a single way of doing things > > Cygwin is required for the 64bits vm because of directx. > Indeed cygwin still provides support for the legacy directx version used > by the VM, while recent mingw does not. > Until we port to a newer API, mingw thus depends on the MS directx include > and library files that we redistribute for 32 bits only (and we should not > without permission, I plan to remove these files). That does not work at > all for 64 bits. > > The 64bits VM does not work either with gcc and requires clang currently. > installing clang in mingw is tedious, while it's a prebuilt package in > cygwin. > > You now know why we use cygwin, not how, maybe it does not terribly helps, > but it's important in order to avoid regression, or to be aware of what > need to be done before changing the building environment again... > Could you detail what you tried exactly? > Setup cygwin: CYG_MIRROR=http://cygwin.mirror.constant.com CYG_ROOT='c:\cygwin' CYG_SETUP=setup-x86.exe MINGW_ARCH=i686 $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l "$CYG_ROOT"/var/cache/setup -P mingw64-$MINGW_ARCH-gcc-core,mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers,mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang,libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget (taken from the appveyor.xml, I needed to add make and wget, don't know why, from the appveyor log I see that make and wget is installed, even without this option...) Run the build (from an "empty" environment, that is, no other msys or mingw in the path environment variable) set FLAVOR=pharo.cog.spur set ARCH=win32x86 set MINGW_ARCH=i686 set CYG_ROOT=c:\cygwin set TRAVIS_OS_NAME=windows set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%; git config --system core.autocrlf input git clone -q --depth=5 --branch=Cog https://github.com/OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm SET APPVEYOR_BUILD_FOLDER=c:\projects\vm git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16 %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0</dev/null;exec ./.travis_build.sh" > > Nicolas > > >>> HernÃ¡n >>> >>> > >>> > nicolai >>> > >>> > >>> > >>> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >> >>> >> >>> >> >>> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < >>> philippe.back(a)gmail.com>: >>> >>> >>> >>> I made my own build here. >>> >>> Not up to date with latest stuff but should work for the build >>> process. >>> >>> >>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>> >>> >>> >>> It uses my forked repo and provided you set your own bintray env >>> vars for API keys will publish there. >>> >>> >>> >>> Check all of the output of env vars and where/which in the appveyor >>> console to see what gets used when when it comes to compilers and so on as >>> there were various compiler versions involved at one point. >>> >>> >>> >>> Third party cache part is also worth checking. >>> >>> >>> >>> Still not able to build on my local box at the moment due to some >>> tools discrepancies happening. >>> >>> >>> >>> My build artifacts are embarking too much at this point but allow >>> you ro get the release, debug, and assert vms for windows. This helps when >>> debugging as backtraces and so on are much more meaningful and one can use >>> gdb more effectively to understand what is going on. >>> >>> >>> >>> Just keep the dlls and exes and you'll be fine. >>> >> >>> >> >>> >> Ah good, thank you. >>> >> >>> >> >>> >>> >>> >>> >>> >>> HTH >>> >>> >>> >>> Phil >>> >>> >>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a >>> Ã©crit : >>> >>>> >>> >>>> >>> >>>> >>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>>>>>> >>> >>>>>>>> Hi Nicolai, >>> >>>>>>>> >>> >>>>>>>> If you look at appveyor.yml configuration on >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, >>> you will see that the pharo brand is not yet in the matrix. >>> >>>>>>>> >>> >>>>>>>> It's because builds are based on cygwin, but as I understood, >>> some library used by some plugin required by pharo refuse to compile with >>> cygwin. They appear to work with mingw32. >>> >>>>>>>> Cygwin provides headers for legacy directx, some distribution >>> of mingw32 did in the past, but it does not seem the case anymore. >>> >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They >>> are not redistributable and can't be found anymore on the net (too old). We >>> cannot seriously base the builds on something so fragile (both technically >>> and legally) in the long term. >>> >>>>>>>> >>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't >>> have anything available as a 64bits Microsoft SDK... So pharo has to fix >>> that too. >>> >>>>>>>> >>> >>>>>>>> In the interim, you should look at >>> https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and >>> follow the scripts there. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Ok, thank you. >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in >>> Nantes, and I almost succeeded in compiling all the dependencies with >>> cygwin. >>> >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>> forget a few other niceties that some not so well informed programmers >>> committed with the faith that it would make their life "easier". It >>> certainly does not make mine simpler... >>> >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: >>> it seems that the workaround of Igor does not work anymore. >>> >>>>>> ssize_t, WTF??? >>> >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >>> I'll publish the branch to see how far appveyor goes. >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> So I solved the ssize_t problem by removing the hack from Igor >>> which is not necessary anymore... >>> >>>>> But got another problem soon after while building the tests... >>> >>>>> There are trailing lines generated at end of >>> tests/cairo-test-constructors.c that make the compilation fail: >>> >>>>> >>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opens >>> malltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 >>> -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration >>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o >>> cairo_test_suite-cairo-test-constructors.o `test -f >>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>> >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>> donnÃ©es n'a pas de type ni de classe de stockage >>> >>>>> oning (); >>> >>>>> ^ >>> >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to >>> âintâ in declaration of âoningâ [-Wimplicit-int] >>> >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>> donnÃ©es n'a pas de type ni de classe de stockage >>> >>>>> _register_ft_show_glyphs_table (); >>> >>>>> ^ >>> >>>>> >>> >>>>> And the file looks like it has obviously been overwritten, but not >>> truncated !!! >>> >>>>> >>> >>>>> ... >>> >>>>> extern void _register_multi_page (void); >>> >>>>> extern void _register_fallback_resolution (void); >>> >>>>> >>> >>>>> void >>> >>>>> _cairo_test_runner_register_tests (void) >>> >>>>> { >>> >>>>> _register_a1_bug (); >>> >>>>> _register_a1_clip_paint (); >>> >>>>> ... >>> >>>>> _register_multi_page (); >>> >>>>> _register_fallback_resolution (); >>> >>>>> } >>> >>>>> oning (); >>> >>>>> _register_ft_show_glyphs_table (); >>> >>>>> _register_ft_text_vertical_layout_type1 (); >>> >>>>> _register_ft_text_vertical_layout_type3 (); >>> >>>>> _register_ft_text_antialias_none (); >>> >>>>> _register_ps_eps (); >>> >>>>> _register_ps_features (); >>> >>>>> _register_ps_surface_source (); >>> >>>>> _register_svg_surface (); >>> >>>>> _register_svg_clip (); >>> >>>>> _register_svg_surface_source (); >>> >>>>> _register_multi_page (); >>> >>>>> _register_fallback_resolution (); >>> >>>>> } >>> >>>>> >>> >>>>> This file is generated by a shell script >>> test/make-cairo-test-constructors.sh >>> >>>>> I can't find any reference of the bug, and upgrade to version >>> 1.14.8 does not solve the issue. >>> >>>>> So it will wait until tomorrow... >>> >>>> >>> >>>> >>> >>>> >>> >>>> I got the build for windows with mingw nearly working. (it can not >>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>> is different in the mingw distrubtion). >>> >>>> >>> >>>> I still have the problem, that there seems to be a preprocessing >>> step , that should put the vm-version (and source timestamp) in the >>> sqSCCSVersion.h >>> >>>> I got this working by running .travis_build.sh (with the options >>> for arch/flavor/platform) But how is this done normally when you build a vm >>> locally? >>> >>>> And how is this done for the pharo-vm we currently use? >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Nicolas >>> >>>>> >>> >>>>>>>> >>> >>>>>>>> I hope that Esteban will find time to resolve all these >>> problems and have pharo brand back on opensmalltalk-vm. I guess that any >>> form of help is welcome. >>> >>>>>>>> >>> >>>>>>>> Nicolas >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>>>>>>> >>> >>>>>>>>> I still have problems building a vm on windows. >>> >>>>>>>>> can you give me some hints how to start ? >>> >>>>>>>>> I cloned the recent pharo-vm project, >>> >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>> >>>>>>>>> run >>> >>>>>>>>> mvm >>> >>>>>>>>> >>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>> found, I had to adjust the include path for finding directx header, missing >>> variable replacement for git-versions). >>> >>>>>>>>> So I may miss some important steps. >>> >>>>>>>>> Is there a repository where I can clone the mingw environment >>> used to build the win32-pharo-vm, the environment used on the build-server ? >>> >>>>>>>>> >>> >>>>>>>>> Thanks >>> >>>>>>>>> Nicolai >>> >>>>>>>>> >>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >>> >: >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >>> >: >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < >>> estebanlm(a)gmail.com>: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess < >>> nicolaihess(a)gmail.com> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera < >>> bera.clement(a)gmail.com>: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Hi, >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> I believe they're built from >>> https://github.com/OpenSmalltalk/vm using travis and appveyor. On the >>> gitbhub readme there are relevant links. All built artifacts are also kept >>> on bintray for history. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Thank you! >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> no, they arenât :) >>> >>>>>>>>>>>> instead, they are built here: >>> https://github.com/pharo-project/pharo-vm >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> (README still not updated) >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>> anymore (something wrong with generating the generator.image, I'll now >>> reset my local pharo-vm build directory and see if it works afterwards). >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> see attached the stderr log : >>> >>>>>>>>>> >>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>> dVMMaker.st' >>> >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>> >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>> >>>>>>>>>> BaseSoundSystem class>>initialize >>> >>>>>>>>>> MCMethodDefinition>>postloadOver: >>> >>>>>>>>>> >>> >>>>>>>>>> .... >>> >>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>> master ? >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Esteban >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>> nicolaihess(a)gmail.com> wrote: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>> >>>>>>>>>>>>>> I don't see them on the build server, only the >>> buildresults at >>> >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last >>> year only. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> nicolai >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>> >>> >> >>> > >>> >>> >> >

July 23, 2017

Re: [Pharo-dev] Epicea applying multiple changes

by Jan BlizniÄenko

Hello Might it be related to a problem I described over here? http://forum.world.st/Epicea-feedback-td4952661.html In short, I think that when I select multiple changes, epicea applies them in wrong order, so, if for example a single method is changed two times, Epicea first creates newer content and then replaces it by older content. It seems to be solvable by filtering just latest changes, but I am not sure whether it might not have other unwanted consequences. Jan tinchodias wrote > I'll check the bug, it's important. > > However, Tim and others, I'm interested in your experience with the UI. If > you want to send me more details... > > Maybe I can remark: Epicea has work and feedback accumulated during my > phd. > Now that phd finished and Epicea comes with Pharo 6.0, the project is open > to much more developers to collaborate with their work and feedback. So > you > are welcome. The project belongs to the community now even though I'm > still > responsible to maintain it, of course. > > Cheers, MartÃn > > On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov < > dionisiydk@ > > > wrote: > >> It is issue 20223 >> <https://pharo.fogbugz.com/f/cases/20223/Epicea-applying-collection-of-same-method-changes-uses-wrong-order> >> >> 2017-07-19 9:41 GMT+02:00 Tudor Girba < > tudor@ > >: >> >>> Hi, >>> >>> I experienced the same issues. It seems somehow related that when we >>> have >>> multiple changes to the same method, not all changes are applied and we >>> do >>> not get back the latest version. >>> >>> Cheers, >>> Doru >>> >>> >>> > On Jul 18, 2017, at 10:48 AM, Andrei Chis < > chisvasileandrei@ > > >>> wrote: >>> > >>> > Hi, >>> > >>> > Is there some known bug in Epicea when applying multiple changes at >>> once in Pharo 6? >>> > >>> > I had a few crashes lately and each time when recovering the changes >>> by >>> selecting multiple changes at once some changes are skipped. If I apply >>> manually each change it works. >>> > >>> > Cheers, >>> > Andrei >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Things happen when they happen, >>> not when you talk about them happening." >>> >>> >>> >> -- View this message in context: http://forum.world.st/Epicea-applying-multiple-changes-tp4955502p4956482.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 23, 2017