- Pharo-dev - lists.pharo.org

git, packages, and package dependencies (also migration from sthub to git)

by Peter Uhnak

Hi, after many-o-hours spent on my git-migration tool ( https://github.com/peteruhnak/git-migration ), I've concluded that the migration cannot be properly done for packages. In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore: * a specific version of package A mandates specific versions of every other package in the project * it is not possible to do a 1:1 migration from mcz to git and keep this flexibility Both ways (mcz and git) have advantages and disadvantages of their own, however as far as I could tell, they are incompatible; so mcz flexibility and some information (history) will be lost during migration. The only solution I see is to either separate every package to a separate git project to keep the flexibility or use git subtree/git module... which are both complications... As a git commit specifies the code in the entire project, even across packages, then I wonder what is the point of expressing package dependencies _within_ the project (whether in BaselineOf or Cargo). Peter

July 1, 2017

Re: [Pharo-dev] [Pharo-users] Custom Glamour browser for Dr. Geo scripting

by Nicolai Hess

2017-06-30 9:55 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > I extended the browser definition with: > > browser transmit > from: #scripts; > from: #categories; > to: #methods; > when: [ :a :b | a isMeta not ]; > andShow: [:a | self methodsIn: a ]. > browser transmit > from: #scripts; > from: #categories; > to: #methods; > when: [ :a | a isMeta ]; > andShow: [:a | self classMethodsIn: a ]. > > > However it does not work as #when: message always receive a class, so > the wrong methods a re list in the method pane. > > I enclosed a Fileout of the browser. It works independently of DrGeo. > When one select class methods, still the instance methods are displayed > in right most pane. > > Any tips? > I don't have a solution. I just want to make more clear what the problem is. See attached screenshot. The question is, is it possible to make the population of the "methods" list dependent of the focused "Instance Methods"/"Class Methods" pane ? I tried to wire a "#focus" port, but I don't think the "categories"-pane exports any port that could be used to distinguish between the selected tabs. > > Thanks > > Hilaire > > > Le 29/06/2017 Ã 14:59, Hilaire a Ã©crit : > > but something is missing to get the listed method right depending on the > > category is instance or class side. I don't how to do it. > > -- > Dr. Geo > http://drgeo.eu > >

July 1, 2017

Re: [Pharo-dev] Epicea feedback

by Stephane Ducasse

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(a)gmail.com> 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(a)fit.cvut.cz> > 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. >> >

July 1, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Esteban A. Maringolo

2017-06-30 8:28 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> Am 30.06.2017 um 12:03 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> recently I started to read a book on machine learning and they >> manipulate dictionary of dictionary. (So I started my own >> implementation and I will switch to DataFrame). >> > having an abstract notation for a structure (or dictionary of dictionary) is something really useful. I work a lot with JSON and the creation in pharo is done the same way but you have to call asDictionary all the time which is annoying. This can be rethought and would make things less ugly if we had a good way. If it is close to S-expressions the better. I don't what black magic requires, but having a syntax compatible with JSON would be a HUGE boost. Maybe because of where the keys are located on my keyboard layout, but the #-> selector, although I understand its semantics, it's cumbersome to type. I'd love a more compact representation. If the compiler could be modified to accept $: as a message selector, then we could map it to return an Association as #-> currently does. I can't foresee the implications of such change. > What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. One of the stregths of the JSON format is it doesn't matter in which order the data arrives, otherwise you'd use a Array, because you already know the indices of the data you're looking for. Regards! -- Esteban.

June 30, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Stephane Ducasse

> But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. >> >> STON fromString: 'Point[10,20]' >> > Same goes for JSON. > >> We were brainstorming with marcus and we could have a first nice extension: >> >> { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>>>> 10@20 >> >> Now in addition I think that there is a value in having an object >> literal syntax. >> >> I pasted the old mail of igor on object literals because I like the >> idea since it does not add any change in the parser. >> Do you remember what were the problem raised by this solution (beside >> the fact that it had too many # and the order was like in ston not >> explicit). >> >> I would love to have another pass on the idea of Igor. > > What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. >As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. > > my 2 cents, > > Norbert > >> >> Stef >> >> >> >> >> ---------- Forwarded message ---------- >> From: Igor Stasenko <siguctua(a)gmail.com> >> Date: Fri, Oct 19, 2012 at 1:09 PM >> Subject: [Pharo-project] Yet another Notation format: Object literals >> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >> >> >> Hi, >> as i promised before, here the simple smalltalk-based literal format. >> It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to >> have separate parser (a normal smalltalk parser used for that). >> >> The idea is quite simple: >> you can tell any object to represent itself as an 'object literal' , >> for example: >> >> (1@3) asObjectLiteral >> --> #(#Point 1 3) >> >> { 1@2. 3@4. true. false . nil } asObjectLiteral >> >> -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) >> >> (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral >> -> >> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') >> >> Next thing, you can 'pretty-print' it (kinda): >> >> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral >> >> '#(#Dictionary >> 1 >> (#Array 1 2 3) >> ''foo'' ''bar'')' >> >> >> and sure thing, you can do reverse conversion: >> >> '#(#Dictionary >> 1 >> (#Array 1 2 3) >> ''foo'' ''bar'')' parseAsObjectLiteral >> >> a Dictionary('foo'->'bar' 1->#(1 2 3) ) >> >> Initially, i thought that it could be generic (by implementing default >> Object>>#asObjectLiteral), >> but then after discussing it with others, we decided to leave >> >> Object>>#asObjectLiteral to be a subclass responsibility. >> So, potentially the format allows to represent any object(s) as >> literals, except from circular referencing objects, of course. >> >> The implementation is fairly simple, as you may guess and contains no >> new classes, but just extension methods here and there. >> >> Take it with grain and salt, since it is just a small proof of >> concept. (And if doing it for real it may need some changes etc). >> Since i am far from areas right now, where it can be used, i don't >> want to pursue it further or advocate if this is the right way to do >> things. >> Neither i having a public repository for this project.. >> >> So, if there anyone who willing to pick it up and pursue the idea >> further, please feel free to do so and make a public repository for >> project. >

June 30, 2017

Re: [Pharo-dev] Reviewing of the pull requests

by Pavel Krivanek

2017-06-30 17:58 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Fri, Jun 30, 2017 at 4:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, >> >> the reviewing of the pull requests is currently not as easy as we would >> like to have. For simple changes it should be enough to go to the pull >> requests list (https://github.com/pharo-project/pharo/pulls) and review >> the changes from the GitHub web interface. In case that the PR passes tests >> and bootstrapping, it should be fine. >> >> However if you want to play with an image that contains the PR code, your >> options are more complicated. The basic and the most clean one is to >> bootstrap from the repository with the PR applied on it. But it takes A LOT >> of time (over 20 mins). You can use this script that you will run inside >> the clone. >> >> set -e >> >> export PR=122 >> export BRANCH=development >> >> export PHARO_VERSION=60 >> export BOOTSTRAP_ARCH=32 >> >> git fetch origin $BRANCH >> git fetch origin refs/pull/$PR/head >> git checkout -b pullrequest FETCH_HEAD >> git merge --no-edit origin/$BRANCH >> #git diff origin/$BRANCH..pullrequest > pullrequest.diff >> >> wget -O - get.pharo.org/${PHARO_VERSION}+vm >> <http://get.pharo.org/$%7BPHARO_VERSION%7D+vm> | bash >> >> ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ >> prepare_image.st --save --quit >> ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ >> bootstrap.st --ARCH=${BOOTSTRAP_ARCH} --quit >> bash ./bootstrap/scripts/build.sh >> >> The other option is to take existing Pharo 7 image, have >> pharo-project/pharo clone next to it in a folder named 'pharo-core' and >> then create a new branch with the merged pull request. Currently it cannot >> be done from Iceberg directly so you need to use Git. You can use this >> script: >> >> set -e >> >> PR=119 >> COMMIT=2225314a7404c9e00fe71e70d41fc59d4ba78e2d >> > > where does this commit hash come from? > > as described, SystemVersion current commitHash > >> cd pharo-core >> >> git fetch origin refs/pull/$PR/head >> git checkout -b pr$PR-local FETCH_HEAD >> git checkout $COMMIT >> git checkout -b pr$PR-merged >> git merge --no-edit pr$PR-local >> #git diff $COMMIT...pr$PR-merged > pr$PR.diff >> > > Sorry I haven't the time to test this, but maybe it would do the same...?? > git fetch origin refs/pull/$PR/merge:pr$PR-merged > #git diff $COMMIT...pr$merged > > https://coderwall.com/p/z5rkga/github-checkout-a-pull-request-as-a-branch > > cheers -ben > ok, I'll try. thanks -- Pavel > > >> Set the pull request name to the variable PR and the image commmit hash >> to the variable named COMMIT. It can be obtained by "SystemVersion current >> commitHash". As the result you are in a merged branch created for this pull >> requests (e.g. pr122-merged) and you need to reload all packages. It can be >> done from Iceberg where you will need to confirm several dialogs, or by >> this script: >> >> repo := MCFileTreeRepository new >> directory: './pharo-core/src' asFileReference; >> yourself. >> >> versions := OrderedCollection new. >> repo allFileNames do: [ :packageName | >> | wc | >> wc := MCWorkingCopy allManagers detect: [ :each | each packageName = >> (packageName withoutSuffix: '.package') ] ifNone: [nil]. >> wc ifNotNil: [ >> [(repo loadVersionFromFileNamed: packageName) load] on: >> MCMergeOrLoadWarning do: [:w | w resume ] ]] displayingProgress: [:e | e ]. >> >> The other option is to let display the classical Monticello merging >> window. For that you can use this script: >> >> repo := MCFileTreeRepository new >> directory: './pharo-core/src' asFileReference; >> yourself. >> >> versions := OrderedCollection new. >> repo allFileNames do: [ :packageName | >> | wc | >> wc := MCWorkingCopy allManagers detect: [ :each | each packageName = >> (packageName withoutSuffix: '.package') ] ifNone: [nil]. >> wc ifNotNil: [ >> versions add: (repo loadVersionFromFileNamed: packageName) ]] >> displayingProgress: [:e | e ]. >> >> merger := MCVersionMerger new. >> versions do: [:each | merger addVersion: each ]. >> merger mergeWithNameLike: 'merged'. >> >> merger gatherChanges. >> >> (merger instVarNamed: #records) do: [ :each | each mergePatch operations >> do: [:operation | operation chooseRemote.]]. >> >> (merger instVarNamed: #merger) operations do: #chooseRemote. >> >> merger resolveConflicts. >> >> However I have seen cases where for example the PR deleted some class and >> the MC merging tool was not able to see this change. So be careful with >> this approach. We need to look at that. >> >> Do not look on this mail as something final. It's only a hint for brave >> sprinters. To find a good workflow how properly review our PR should be one >> of our priorities. >> >> Cheers, >> -- Pavel >> > >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Stephane Ducasse

Thanks! This is cool I'm learning how to PR too :). Stef On Fri, Jun 30, 2017 at 4:55 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The PR is updated > > -- Pavel > > 2017-06-30 16:44 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> Attached is the changeset as discussed in my last email. >> >> Just to be clear, this is just for reference, I'm happy to redo the PR >> if it will save you and/or Pavel some time. >> >> Cheers, >> Alistair >> >> >> On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > Hi Stef, >> > >> > Good pickup. >> > >> > I also can't load >> > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. >> > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I >> > have no idea what that is (I don't remember ever creating it, and I >> > don't have a copy on my machine anywhere, or in any of my backups). >> > >> > Fortunately I do have a changeset of the patch. I'll send it through >> > as an attachment after I've sent this email in case it causes the >> > response to be blocked. >> > >> > Do you or Pavel have a preference on how to get the PR fixed? I'm >> > happy to generate a new PR if you or Pavel can close the existing one >> > (#126). >> > >> > Thanks, >> > Alistair >> > >> > >> > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> >> Hi alistair >> >> >> >> I'm starting to review code that is in the PR pipeline. >> >> https://github.com/pharo-project/pharo/pull/126 >> >> >> >> I noticed that you wrote in the slice >> >> >> >> Changes since last slice: >> >> >> >> - Change Path>>fullName to just print the path >> >> - Fix absolute path strings >> >> - Bug fix Path class>>from:delimiter: >> >> - Add unit tests >> >> >> >> But I only see in the PR three methods. >> >> Can you check because I have the impression that we are losing code >> >> somewhere? >> >> >> >> BTW I could not see the contents of the AlistairGrant.1 package >> >> I tried on several images 70 and 60 latest >> >> >> >> Stef >> >> > >

June 30, 2017

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

by Ben Coman

On Fri, Jun 30, 2017 at 4:12 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > > On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> Rajula, thanks for your write-up. >> >> As the person who pushed Rajula to send his email I feel I should >> respond. >> >> While I'm in favour of Rajula's proposed changes, scripting in >> particular will be much easier, I think we need to make the change >> generally known as it will not always be obvious, e.g. at the moment I >> can rely on: >> >> '../init/mystartup.st' asFileReference fileIn >> >> to always work with the current definition since my init directory is >> always next to the image directory. After Rajula's changes I >> will need to do something like: >> >> (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn >> > > That's not true. It depends from where the image is launched. If you're > running from the command line, > > $ pharo Pharo.image eval " 'someFile' asFileReference fullName " > > will be a file relative to the path of the image, if you open the image > from where it is located (ie, working directory = image directory). > > This is yes different when you're > 1) deploying the image in one directory, but you're using it from another > one > $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' > asFileReference fullName " > > But then, why working directory should be image directory and not VM > directory? > I feel the analogy is that the VM is like WinWord.exe and the Image is like a document. The working directory would never be where WinWord.exe is located. Its where the document was opened from. cheers -ben > Just historical reasons? > That's a buggy convention. And people who know what a working > directory is will perceive it as even buggier. > > 2) starting the process from a graphical environment (ie, double click > in an executable app) > In that case, the OS usually sets as working directory the current > user home directory, or the user "desktop" directory. > > In any case, > - we should have a good default, I think that following the principle of > least surprise we should use as working directory what the OS means by > working directory. > > - Applications in general should be explicit with their file management. > Each OS has different locations to store different things (data, settings, > libraries, executables)... FileLocator helps by reducing the noise between > different OSs, but we should use it! > > >> Cheers, >> Alistair >> >> > > > -- > > > > 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> >

June 30, 2017

Re: [Pharo-dev] Reviewing of the pull requests

by Ben Coman

On Fri, Jun 30, 2017 at 4:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > the reviewing of the pull requests is currently not as easy as we would > like to have. For simple changes it should be enough to go to the pull > requests list (https://github.com/pharo-project/pharo/pulls) and review > the changes from the GitHub web interface. In case that the PR passes tests > and bootstrapping, it should be fine. > > However if you want to play with an image that contains the PR code, your > options are more complicated. The basic and the most clean one is to > bootstrap from the repository with the PR applied on it. But it takes A LOT > of time (over 20 mins). You can use this script that you will run inside > the clone. > > set -e > > export PR=122 > export BRANCH=development > > export PHARO_VERSION=60 > export BOOTSTRAP_ARCH=32 > > git fetch origin $BRANCH > git fetch origin refs/pull/$PR/head > git checkout -b pullrequest FETCH_HEAD > git merge --no-edit origin/$BRANCH > #git diff origin/$BRANCH..pullrequest > pullrequest.diff > > wget -O - get.pharo.org/${PHARO_VERSION}+vm > <http://get.pharo.org/$%7BPHARO_VERSION%7D+vm> | bash > > ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/prepare_ > image.st --save --quit > ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ > bootstrap.st --ARCH=${BOOTSTRAP_ARCH} --quit > bash ./bootstrap/scripts/build.sh > > The other option is to take existing Pharo 7 image, have > pharo-project/pharo clone next to it in a folder named 'pharo-core' and > then create a new branch with the merged pull request. Currently it cannot > be done from Iceberg directly so you need to use Git. You can use this > script: > > set -e > > PR=119 > COMMIT=2225314a7404c9e00fe71e70d41fc59d4ba78e2d > where does this commit hash come from? > > cd pharo-core > > git fetch origin refs/pull/$PR/head > git checkout -b pr$PR-local FETCH_HEAD > git checkout $COMMIT > git checkout -b pr$PR-merged > git merge --no-edit pr$PR-local > #git diff $COMMIT...pr$PR-merged > pr$PR.diff > Sorry I haven't the time to test this, but maybe it would do the same...?? git fetch origin refs/pull/$PR/merge:pr$PR-merged #git diff $COMMIT...pr$merged https://coderwall.com/p/z5rkga/github-checkout-a-pull-request-as-a-branch cheers -ben > Set the pull request name to the variable PR and the image commmit hash to > the variable named COMMIT. It can be obtained by "SystemVersion current > commitHash". As the result you are in a merged branch created for this pull > requests (e.g. pr122-merged) and you need to reload all packages. It can be > done from Iceberg where you will need to confirm several dialogs, or by > this script: > > repo := MCFileTreeRepository new > directory: './pharo-core/src' asFileReference; > yourself. > > versions := OrderedCollection new. > repo allFileNames do: [ :packageName | > | wc | > wc := MCWorkingCopy allManagers detect: [ :each | each packageName = > (packageName withoutSuffix: '.package') ] ifNone: [nil]. > wc ifNotNil: [ > [(repo loadVersionFromFileNamed: packageName) load] on: > MCMergeOrLoadWarning do: [:w | w resume ] ]] displayingProgress: [:e | e ]. > > The other option is to let display the classical Monticello merging > window. For that you can use this script: > > repo := MCFileTreeRepository new > directory: './pharo-core/src' asFileReference; > yourself. > > versions := OrderedCollection new. > repo allFileNames do: [ :packageName | > | wc | > wc := MCWorkingCopy allManagers detect: [ :each | each packageName = > (packageName withoutSuffix: '.package') ] ifNone: [nil]. > wc ifNotNil: [ > versions add: (repo loadVersionFromFileNamed: packageName) ]] > displayingProgress: [:e | e ]. > > merger := MCVersionMerger new. > versions do: [:each | merger addVersion: each ]. > merger mergeWithNameLike: 'merged'. > > merger gatherChanges. > > (merger instVarNamed: #records) do: [ :each | each mergePatch operations > do: [:operation | operation chooseRemote.]]. > > (merger instVarNamed: #merger) operations do: #chooseRemote. > > merger resolveConflicts. > > However I have seen cases where for example the PR deleted some class and > the MC merging tool was not able to see this change. So be careful with > this approach. We need to look at that. > > Do not look on this mail as something final. It's only a hint for brave > sprinters. To find a good workflow how properly review our PR should be one > of our priorities. > > Cheers, > -- Pavel >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Alistair Grant

On Fri, Jun 30, 2017 at 04:55:29PM +0200, Pavel Krivanek wrote: > The PR is updated > > -- Pavel Thanks, Pavel! > 2017-06-30 16:44 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Attached is the changeset as discussed in my last email. > > Just to be clear, this is just for reference, I'm happy to redo the PR > if it will save you and/or Pavel some time. > > Cheers, > Alistair > > > On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > Good pickup. > > > > I also can't load > > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. > > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I > > have no idea what that is (I don't remember ever creating it, and I > > don't have a copy on my machine anywhere, or in any of my backups). > > > > Fortunately I do have a changeset of the patch. I'll send it through > > as an attachment after I've sent this email in case it causes the > > response to be blocked. > > > > Do you or Pavel have a preference on how to get the PR fixed? I'm > > happy to generate a new PR if you or Pavel can close the existing one > > (#126). > > > > Thanks, > > Alistair > > > > > > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi alistair > >> > >> I'm starting to review code that is in the PR pipeline. > >> https://github.com/pharo-project/pharo/pull/126 > >> > >> I noticed that you wrote in the slice > >> > >> Changes since last slice: > >> > >> - Change Path>>fullName to just print the path > >> - Fix absolute path strings > >> - Bug fix Path class>>from:delimiter: > >> - Add unit tests > >> > >> But I only see in the PR three methods. > >> Can you check because I have the impression that we are losing code > somewhere? > >> > >> BTW I could not see the contents of the AlistairGrant.1 package > >> I tried on several images 70 and 60 latest > >> > >> Stef > >> > >

June 30, 2017