April 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Why String do not implement #displayString?

by Stephane Ducasse

Thanks denis! No problem syrel I was also dead tired :) On Thu, Apr 12, 2018 at 10:19 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Ok. I opened the issue 21689 > > 2018-04-11 22:06 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> The point is a list of strings should be displayed as >> >> a >> b >> c >> >> and not >> >> 'a' >> 'b' >> 'c' >> >> It shows that often people confuse asString and printString BTW. >> >> On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> > ? >> > >> > >> > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> > wrote: >> >> Hi, >> >> >> >> I am sorry for interrupting this conversation... but >> >> >> >> | s | >> >> s := 'Hello, ''Funny'' World'. >> >> s displayString = s "false" and not true! >> >> >> >> Cheers, >> >> Alex >> >> >> >> On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> >> >> wrote: >> >>> >> >>> Yes I think that >> >>> >> >>> | s | >> >>> s := 'Hello, ''Funny'' World'. >> >>> s displayString = s. "true" >> >>> s printString = s. "false" >> >>> >> >>> is ok and widgets should use displayString. >> >>> >> >>> Stef >> >>> >> >>> >> >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >> >>> <emaringolo(a)gmail.com> wrote: >> >>> > Isn't #displayString implemented in terms of #displayOn: the same >> >>> > way >> >>> > #printString is implemented in terms of "printOn:"? >> >>> > >> >>> > And in the case of String #displayString should return the receiver >> >>> > (it >> >>> > is, self), so the following should be true. >> >>> > >> >>> > | s | >> >>> > s := 'Hello, ''Funny'' World'. >> >>> > s displayString = s. "true" >> >>> > s printString = s. "false" >> >>> > >> >>> > Regards, >> >>> > >> >>> > >> >>> > On 10/04/2018 12:21, Denis Kudriashov wrote: >> >>> >> Hi. >> >>> >> >> >>> >> According to the comment of #displayString it should be used as >> >>> >> default >> >>> >> textual representation of objects in the UI: >> >>> >> >> >>> >> "While printString is about to give a detailled information >> >>> >> about >> >>> >> an >> >>> >> object, displayString is a message that should return a short >> >>> >> string-based representation to be used by list and related UI >> >>> >> frameworks. By default, simply return printString." >> >>> >> "asString should not be implemented in Object, and kept for >> >>> >> conversion between strings, symbols, text and characters." >> >>> >> >> >>> >> But String itself does not respect this message: >> >>> >> >> >>> >> 'some string' displayString " ==> '''someString''' " >> >>> >> >> >>> >> >> >>> >> Is it bug? Or is there any reason for this? >> >>> >> >> >>> >> Best regards, >> >>> >> Denis >> >>> > >> >>> > -- >> >>> > Esteban A. Maringolo >> >>> > >> >>> >> >> >> >

April 12, 2018

Re: [Pharo-dev] [Newsletter] Content Needed

by Stephane Ducasse

You can mention Chrysal: a library to manage configuration http://github.com/Ducasse/Chrysal Stef On Thu, Apr 12, 2018 at 9:28 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The Pharo Monthly Newsletter is working quite well. > https://newsletter.pharo.org > > We now reached a level where it is not just 3 things, but much much more.. > of course this comes with a downside: > - Sometimes topics that would be worth a small article are just posted as a > one-liners > - I forget / overlook things for sure (so much happening!) > > If you want your (or some other project or topic) to be in the newsletter â> > send me a mail, in the best of all cases > with a fully written text that you want to have posted. > > This includes: > - new libraries and projects > - dates > - high level description of existing projects > - videos > - Blog posts > - books > - lectures > - Success Stories of all kinds (nice to present your Company!) > - Research (e.g. published papers or project descriptions) > - Expanded versions of news posted as one-liners before > - â¦. > > There is a explicit jobs section, too. > > Marcus

April 12, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Alistair Grant

Hi Sven, On Thu, Apr 12, 2018 at 09:23:21AM +0200, Sven Van Caekenberghe wrote: > > > > On 12 Apr 2018, at 08:33, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > ... > > > > In your example you've carefully exited by some other means than > > signalling end-of-file (Ctrl-D). > > > > I don't think we can reasonably say "if you write code with Zinc > > streams, ensure that none of your users ever press Ctrl-D, they must > > always type 'quit' (or whatever)". > > I left that open as an exercise for the reader - I knew you would try that ;-) Glad that I didn't disappoint. :-) > The code was originally written for network streams and there it > catches ConnectionClosed which is the network stream equivalent of EOF > (more or less). > > I think we need something like an EndOfStream exception which should > be thrown in that case, instead of returning nil. > > Returning nil from ZnCharacterReadStream or ZnCharacterEncoder when > the stream is EOF is wrong IMHO. The stream being EOF is an > exceptional situation (even though it is relatively common) and there > is always #atEnd that works well in 99% of the cases. > > AFAIK that is also the design decision taking by Xtreams (where I > believe the Incomplete exception replaces #atEnd). OK, this brings us full-circle. Earlier in the thread we wrote: On Tue, Apr 10, 2018 at 11:54:39PM +0200, Sven Van Caekenberghe wrote: > Alistair, > > I am replying in-between, please don't take my remarks as being > negative, I just like to straighten things out as clear as possible. > > > On 10 Apr 2018, at 22:14, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > At this point I think there are three options: > > > > 1. Modify Zinc to check the return value of #next instead of using #atEnd. > > > > This is what all existing character / byte oriented streams in Squeak > > and Pharo do. At that point the Zinc streams can be used on all file > > / stdio input and output. > > I agree that such code exists in many places, but there is lots of > stream reading that does not check for nils. > > > 2. Modify all streams to signal EOF in some other way, i.e. a sentinel > > or notification / exception. > > > > This is what we were discussing below. But it is a decent chunk of > > work with significant impact on the existing code base. > > Agreed. This would be a future extension. I agree that raising an exception is a nicer solution (although for anyone who disagrees I'll also admit that there is a subjective element to that assessment). But the existing behaviour of returning nil on EOF has been around for a long time and works reasonably well, and as we agreed here, changing that behaviour will have a significant impact on the existing code base. None of this excludes Zinc streams adopting exceptions at any time in the future. So I'm going to respectfully disagree and say that I think to raise a MNU instead of returning nil is wrong, and that changing the Zinc streams isn't such a big deal. Cheers, Alistair

April 12, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Denis Kudriashov

Ok. I opened the issue 21689 <https://pharo.fogbugz.com/f/cases/21689/displayString-for-String-should-ret…> 2018-04-11 22:06 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > The point is a list of strings should be displayed as > > a > b > c > > and not > > 'a' > 'b' > 'c' > > It shows that often people confuse asString and printString BTW. > > On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > ? > > > > > > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> Hi, > >> > >> I am sorry for interrupting this conversation... but > >> > >> | s | > >> s := 'Hello, ''Funny'' World'. > >> s displayString = s "false" and not true! > >> > >> Cheers, > >> Alex > >> > >> On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>> > >>> Yes I think that > >>> > >>> | s | > >>> s := 'Hello, ''Funny'' World'. > >>> s displayString = s. "true" > >>> s printString = s. "false" > >>> > >>> is ok and widgets should use displayString. > >>> > >>> Stef > >>> > >>> > >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo > >>> <emaringolo(a)gmail.com> wrote: > >>> > Isn't #displayString implemented in terms of #displayOn: the same way > >>> > #printString is implemented in terms of "printOn:"? > >>> > > >>> > And in the case of String #displayString should return the receiver > (it > >>> > is, self), so the following should be true. > >>> > > >>> > | s | > >>> > s := 'Hello, ''Funny'' World'. > >>> > s displayString = s. "true" > >>> > s printString = s. "false" > >>> > > >>> > Regards, > >>> > > >>> > > >>> > On 10/04/2018 12:21, Denis Kudriashov wrote: > >>> >> Hi. > >>> >> > >>> >> According to the comment of #displayString it should be used as > default > >>> >> textual representation of objects in the UI: > >>> >> > >>> >> "While printString is about to give a detailled information > about > >>> >> an > >>> >> object, displayString is a message that should return a short > >>> >> string-based representation to be used by list and related UI > >>> >> frameworks. By default, simply return printString." > >>> >> "asString should not be implemented in Object, and kept for > >>> >> conversion between strings, symbols, text and characters." > >>> >> > >>> >> But String itself does not respect this message: > >>> >> > >>> >> 'some string' displayString " ==> '''someString''' " > >>> >> > >>> >> > >>> >> Is it bug? Or is there any reason for this? > >>> >> > >>> >> Best regards, > >>> >> Denis > >>> > > >>> > -- > >>> > Esteban A. Maringolo > >>> > > >>> > >> > >

April 12, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Sven Van Caekenberghe

> On 12 Apr 2018, at 03:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Sven, > > On Wed, Apr 11, 2018 at 1:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 11 Apr 2018, at 21:44, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > I did not know about the NeoConsole. Nice because I wanted to build a > > little REPL for my minilanguage implementation. > > You are of course welcome to look at it. > But it is Pharo specific. > I use it to be able to hook/look into running headless server images. > For this it is super handy. > > Cool usage! Could you tell me whether you type Smalltalk expressions into this to examine your running server? The answer will be used in a related discussion on a mailing list not too distant from this one ;-) Yes of course, that it the whole purpose, to type in expressions and to manipulate objects in a running image. I recently added options to look at code and change/add methods. All very primitive, but when in trouble, it works well. > > Stef > > > > On Wed, Apr 11, 2018 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Alistair, > >> > >>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> I will send you some code later on. > >> > >> Today I arranged for my NeoConsole code (that normally works over a network connection) to work over stdio. Although I am not yet happy with every aspect of the implementation, it does work (using unaltered Zn streams and code). The foll > >> > >> $ cat /etc/issue > >> Ubuntu 16.04.4 LTS > >> $ mkdir pharo7 > >> $ cd pharo7/ > >> $ curl get.pharo.org/70+vm | bash > >> % Total % Received % Xferd Average Speed Time Time Time Current > >> Dload Upload Total Spent Left Speed > >> 100 3036 100 3036 0 0 36799 0 --:--:-- --:--:-- --:--:-- 37024 > >> Downloading the latest 70 Image: > >> http://files.pharo.org/get-files/70/pharo.zip > >> Pharo.image > >> Downloading the latest pharoVM: > >> http://files.pharo.org/get-files/70/pharo-linux-stable.zip > >> pharo-vm/pharo > >> Creating starter scripts pharo and pharo-ui > >> On a 64-bit system? You must enable and install the 32-bit libraries > >> Please see http://pharo.org/gnu-linux-installation for detailed instructions > >> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo ConfigurationOfNeoConsole --install=bleedingEdge > >> 'Installing ConfigurationOfNeoConsole bleedingEdge' > >> > >> Loading 1-baseline of ConfigurationOfNeoConsole... > >> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo > >> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- cache > >> ...finished 1-baseline > >> $ ./pharo Pharo.image eval NeoConsoleStdio run > >> Neo Console Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 Bit) > >> pharo> 1+2 > >> > >> 3 > >> pharo> 42 factorial > >> > >> 1405006117752879898543142606244511569936384000000000 > >> pharo> Stdio stdin > >> > >> StdioStream: #stdin > >> pharo> == > >> self: StdioStream: #stdin > >> class: StdioStream > >> file: a File > >> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1] > >> forWrite: false > >> peekBuffer: nil > >> pharo> show StdioStream>>#atEnd > >> StdioStream>>#atEnd > >> atEnd > >> > >> ^ file atEnd > >> pharo> get process.list > >> Morphic UI Process > >> Delay Scheduling Process > >> Low Space Watcher > >> Input Event Fetcher Process > >> Idle Process > >> WeakArray Finalization Process > >> CommandLine handler process > >> pharo> quit > >> Bye! > >> a NeoConsoleStdio > >> > >> I know there are many approaches to a REPL, I don't claim mine is best, it is just the one that I have been using for years. > >> > >> In the above, I do not depend on EOF - just to be clear. The point being that there is no immediate fundamental problem. > >> > >> But there is something wrong with what is returned by Stdio stdin > >> > >> Sven > >> > >> > >> > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot

April 12, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Sven Van Caekenberghe

> On 12 Apr 2018, at 04:07, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 12 April 2018 at 04:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 11 Apr 2018, at 21:44, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > I did not know about the NeoConsole. Nice because I wanted to build a > > little REPL for my minilanguage implementation. > > You are of course welcome to look at it. > But it is Pharo specific. > I use it to be able to hook/look into running headless server images. > For this it is super handy. > > A description of how to set that up would make a nice blog post. It is part of, and partially documented in https://github.com/svenvc/pharo-server-tools But maybe I'll write something about it, yes. > cheers -ben

April 12, 2018

[Newsletter] Content Needed

by Marcus Denker

Hi, The Pharo Monthly Newsletter is working quite well. https://newsletter.pharo.org <https://newsletter.pharo.org/> We now reached a level where it is not just 3 things, but much much more.. of course this comes with a downside: - Sometimes topics that would be worth a small article are just posted as a one-liners - I forget / overlook things for sure (so much happening!) If you want your (or some other project or topic) to be in the newsletter â> send me a mail, in the best of all cases with a fully written text that you want to have posted. This includes: - new libraries and projects - dates - high level description of existing projects - videos - Blog posts - books - lectures - Success Stories of all kinds (nice to present your Company!) - Research (e.g. published papers or project descriptions) - Expanded versions of news posted as one-liners before - â¦. There is a explicit jobs section, too. Marcus

April 12, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Sven Van Caekenberghe

> On 12 Apr 2018, at 08:33, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On 11 April 2018 at 20:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Alistair, >> >>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> I will send you some code later on. >> >> Today I arranged for my NeoConsole code (that normally works over a network connection) to work over stdio. Although I am not yet happy with every aspect of the implementation, it does work (using unaltered Zn streams and code). The foll >> >> $ cat /etc/issue >> Ubuntu 16.04.4 LTS >> $ mkdir pharo7 >> $ cd pharo7/ >> $ curl get.pharo.org/70+vm | bash >> % Total % Received % Xferd Average Speed Time Time Time Current >> Dload Upload Total Spent Left Speed >> 100 3036 100 3036 0 0 36799 0 --:--:-- --:--:-- --:--:-- 37024 >> Downloading the latest 70 Image: >> http://files.pharo.org/get-files/70/pharo.zip >> Pharo.image >> Downloading the latest pharoVM: >> http://files.pharo.org/get-files/70/pharo-linux-stable.zip >> pharo-vm/pharo >> Creating starter scripts pharo and pharo-ui >> On a 64-bit system? You must enable and install the 32-bit libraries >> Please see http://pharo.org/gnu-linux-installation for detailed instructions >> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo ConfigurationOfNeoConsole --install=bleedingEdge >> 'Installing ConfigurationOfNeoConsole bleedingEdge' >> >> Loading 1-baseline of ConfigurationOfNeoConsole... >> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo >> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- cache >> ...finished 1-baseline >> $ ./pharo Pharo.image eval NeoConsoleStdio run >> Neo Console Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 Bit) >> pharo> 1+2 >> >> 3 >> pharo> 42 factorial >> >> 1405006117752879898543142606244511569936384000000000 >> pharo> Stdio stdin >> >> StdioStream: #stdin >> pharo> == >> self: StdioStream: #stdin >> class: StdioStream >> file: a File >> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1] >> forWrite: false >> peekBuffer: nil >> pharo> show StdioStream>>#atEnd >> StdioStream>>#atEnd >> atEnd >> >> ^ file atEnd >> pharo> get process.list >> Morphic UI Process >> Delay Scheduling Process >> Low Space Watcher >> Input Event Fetcher Process >> Idle Process >> WeakArray Finalization Process >> CommandLine handler process >> pharo> quit >> Bye! >> a NeoConsoleStdio >> >> I know there are many approaches to a REPL, I don't claim mine is best, it is just the one that I have been using for years. >> >> In the above, I do not depend on EOF - just to be clear. The point being that there is no immediate fundamental problem. > > > Cool. I've wanted to try NeoConsole for a while (I've got a Raspberry > Pi monitoring temperatures and wanted to use it to work on the Pi) but > hadn't made the time. > > But... :-) > > > $ vm/pharo Pharo7.0-64bit-d2734dc.image eval NeoConsoleStdio run > Neo Console Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a > (64 Bit) > pharo> 4+3 > > 7 > pharo> [Ctrl-D] > MessageNotUnderstood: receiver of "<" is nil > UndefinedObject(Object)>>doesNotUnderstand: #< > ZnUTF8Encoder>>nextCodePointFromStream: > ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream: > ZnCharacterReadStream>>nextElement > ZnCharacterReadStream(ZnEncodedReadStream)>>next > [ :out | > | eol char | > eol := false. > [ eol ] > whileFalse: [ char := readStream next. > (char isNil or: [ char == lf ]) > ifTrue: [ eol := true ] > ifFalse: [ char == cr > ifTrue: [ eol := true. > readStream peekFor: lf ] > ifFalse: [ out nextPut: char ] ] ] ] in ZnFastLineReader>>nextLine in > Block: [ :out | ... > ZnFastLineReader>>streamContents: > ZnFastLineReader>>nextLine > [ lineReader nextLine trimBoth ] in NeoConsoleStdio>>readInputFrom: in > Block: [ lineReader nextLine trimBoth ] > BlockClosure>>on:do: > NeoConsoleStdio>>readInputFrom: > NeoConsoleStdio>>executeRequestResponseLoop > NeoConsoleStdio>>run > NeoConsoleStdio class>>run > UndefinedObject>>DoIt > > > In your example you've carefully exited by some other means than > signalling end-of-file (Ctrl-D). > > I don't think we can reasonably say "if you write code with Zinc > streams, ensure that none of your users ever press Ctrl-D, they must > always type 'quit' (or whatever)". I left that open as an exercise for the reader - I knew you would try that ;-) The code was originally written for network streams and there it catches ConnectionClosed which is the network stream equivalent of EOF (more or less). I think we need something like an EndOfStream exception which should be thrown in that case, instead of returning nil. Returning nil from ZnCharacterReadStream or ZnCharacterEncoder when the stream is EOF is wrong IMHO. The stream being EOF is an exceptional situation (even though it is relatively common) and there is always #atEnd that works well in 99% of the cases. AFAIK that is also the design decision taking by Xtreams (where I believe the Incomplete exception replaces #atEnd). >> But there is something wrong with what is returned by Stdio stdin > > Right, that's the bug I was addressing stdio.cs. I've got a note to > open an issue and submit a PR. > > Cheers, > Alistair

April 12, 2018

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

by Marcus Denker

This is today 5:00 PM - 7:00 PM (UTC+02:00) There is a calendar entry to download at: https://association.pharo.org/event-2797068 > On 10 Apr 2018, at 16:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > There next TechTalk will be April 12: GIT with Iceberg > > https://association.pharo.org/event-2797068 > > > A regular chat about Pharo. Happens on Discord. > > The Tech talks are open to both members and non-members! > > Topic: GIT with Iceberg. Demo of improved UI > > We will send an information to all subscribers some hours before the talk starts. > >

April 12, 2018

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

by Thierry Goubier

2018-04-12 7:51 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On 12 April 2018 at 12:39, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: >> >> Le 12/04/2018 Ã 03:54, Ben Coman a Ã©crit : >>> >>> >>> I was thinking that a smalltalk-implemented merge algorithm would only be >>> used for the Smalltal/Tonel code, >>> not for any other files. And maybe, when a merge is invoked from >>> Iceberg, the callback to the merge-driver >>> might present conflicts in a GUI to be resolved, but I guess such would >>> require a threaded-VM. >> >> >> Two things then. >> >> - What happens if the C developer does a merge in a multi-language project >> containing tonel files? >> >> - What is the difference with setting and provides a merge driver in Git, >> which has the ability to work even without libcgit? > > > I don't quite understand the question. By "setting" do you mean in > .gitattributes? Yes. > The same merge-algorithm could be invoked in two ways. > > The first would be "externally" from the shell, > booting an Image to invoke the merge-algorithm > with the files-to-process as arguments. This wouldn't need libgit. > Conflicts could left marked in text files similar to exiting merge, > or the running Image could present them in a GUI to resolve. > A tool is required either way. > I guess one of the existing options does this already? Yes. The GitFileTree-MergeDriver works like that. It is a headless image, now buildt out of the Pharo6 minimal image, and it is called by git for specific file types. What is missing is the GUI part, like a git merge-tool like meld can do. > But I had imagined a problem(?) in an already running Image, with Iceberg > doing a merge through libgit > being able to invoke the merge driver in the already running Image. > Now you've made me think it through more, I see some holes. > Perhaps its okay to have two Images running by using the "external" way > anyway; Yes: in that case the merge driver is called in another process anyway. Also, you want to reduce the overhead (make the pharo-based merge driver as fast as possible to start, because git will start it for each file to merge). The nice thing with that setup is that the common ancestor search is done by git. > or the merge done purely "internally" before touching git, and just present > the resultant "index" to libgit; That one has the issue of having to deal with non-smalltalk files (i.e. write a generic merge tool). If you restrict yourself to smalltalk merges, then that can be fine (i.e. you merge with Monticello, and the resulting package is stored as a merge in the git store). But you reverse who is the master... in the later, smalltalk is the master, and git store smalltalk results; in the merge driver, git is the master, and smalltalk does what git requires. But someone can still come from the outside of the repo and do a merge on the command line; which is also fine. > and my idea is not needed as a third way. > Now I find I don't know the depths of the Pharo / libgit interface enough to > speculate further here. Yes, it seems that there are multiple ways to interface with it. Thierry > cheers -ben

April 12, 2018