- Pharo-dev - lists.pharo.org

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

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

by Alistair Grant

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)". > > 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] Changed #atEnd primitive - #atEnd vs #next returning nil

by K K Subbu

On Wednesday 11 April 2018 10:38 PM, Alistair Grant wrote: > StandardFileStream>>readInto:startingAt:count: assumes that > primitiveFileRead will always attempt to read count bytes, but it > actually only attempts to read 1. StandardFileStream>>#basicNext uses position < readLimit ifFalse: and does not check if the primRead returns < 0. Instead it should call whileFalse: and check if primRead returns <= 0 to check for EOF or error. #primRead:... returns an error if the primitive fails and the file is closed. It should instead check for EOF or error and then return -1, otherwise it should return 0 (Data not ready?). Raise an error only if the underlying primitive fails for non-EOF cases. Regards .. Subbu

April 12, 2018

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

by Alistair Grant

On 11 April 2018 at 19:42, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2018-04-11 19:08 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> Hi Sven, >> >> On 11 April 2018 at 18:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > Something is off (and/or I am getting crazy, probably both). >> > >> > $ ./pharo --headless Pharo.image eval '(FileStream stdin binary; next: >> > 3)' >> > 123 >> > #[49] >> > >> > ?? >> > >> > This should return #[49 50 51] AFAIK. >> >> I haven't checked properly, but I can take a guess at this... >> >> The file read primitive in FilePlugin tries to read from stdin 1 >> character at a time (presumably to get around the line buffering that >> is done, but I haven't gone through the history. At one time I think >> it modified the terminal settings, but that code is #if'd out). For >> all other streams it attempts to read the requested number of >> characters. >> >> StandardFileStream>>readInto:startingAt:count: assumes that >> primitiveFileRead will always attempt to read count bytes, but it >> actually only attempts to read 1. >> >> Cheers, >> Alistair >> > > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/150 Thanks! I'd already looked at this routine and found it strangely constructed. Having some background discussion will help a lot. Cheers, Alistair

April 12, 2018

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

by Ben Coman

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? 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? 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; or the merge done purely "internally" before touching git, and just present the resultant "index" to libgit; 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. cheers -ben

April 12, 2018

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

by Thierry Goubier

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 developper 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? Thierry > > cheers -ben > > > ...

April 12, 2018

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

by Ben Coman

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. cheers -ben

April 12, 2018

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

by Ben Coman

On 12 April 2018 at 01:47, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Ben, > > Le 11/04/2018 Ã 16:37, Ben Coman a Ã©crit : > >> >> >> On 11 April 2018 at 05:05, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> Hi, >> >> Iâve been wondering how to better fix the problem of having windows >> and linux/macOS people contributing and the fact that files are >> written in their native system format (crlf windows, lf for the rest >> of the world). >> >> >> >> I digged a bit and I found a couple a link that helped me (after >> trying to understand the doc): >> https://stackoverflow.com/questions/170961/whats-the-best- >> crlf-carriage-return-line-feed-handling-strategy-with-git >> <https://stackoverflow.com/questions/170961/whats-the-best- >> crlf-carriage-return-line-feed-handling-strategy-with-git> >> >> and it seems adding a .gitattributes file with this content: >> >> # Auto detect text files and perform LF normalization >> *text=auto >> >> >> I see a few posts around that recommend reading >> http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ >> which about the above line says... "This is certainly better than >> requiring everyone to be on the same global setting for core.autocrlf, but >> it means that you really trust Git to do binary detection properly. In my >> opinion it is better to explicitly specify your text files that you want >> normalized." >> >> and https://tinyurl.com/ya9xsprx says "We had a repo with * text=auto, >> and Git guessed wrong for an image file that it was a text file, causing it >> to corrupt it as it replaced CR + LF bytes with LF bytes in the object >> database." >> >> I'm unsure. Without it the system is subject to different users' >> different global settings >> and I'd guess that may be a more frequent problem than Git guessing >> wrong. The latter >> can be fixed by a user adding an extra .gitattributes entry explicitly >> specifying the file was binary, >> whereas the former seems to introduce a confounding factor. >> So probably a good line to have. >> >> *.sttext merge=union eol=lf >> >> could fix the problem? >> can someone confirm this? >> >> >> "eol=lf" looks appropriate... >> https://www.scivision.co/git-line-endings-windows-cygwin-wsl/ >> >> Most editors on Windows transparently handle LF line endings. >> https://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support >> >> >> " merge=union" I am not familiar with, but I read at... >> https://git-scm.com/docs/gitattributes >> "union = Run 3-way file level merge for text files, but take lines from >> both versions, instead of leaving conflict markers. >> This tends to leave the added lines in the resulting file in random** >> order and the user should verify the result. >> Do not use this if you do not understand the implications." >> >> What are the implications of lines being merged in a random order? >> >> >> btw, has doing a callback from libgitto a custom merge driver in Pharo >> been considered? >> https://libgit2.github.com/libgit2/#HEAD/group/callback/git_ >> merge_driver_apply_fn >> > > There is a merge driver for parts of the filetree format implemented with > Pharo, it could be done on a more general basis if the Tonel format exhibit > more conflicts than usual. > > But (and this is a big "but"), mixed Pharo / other things repositories > with very large files to merge could make things very hard on a > smalltalk-implemented merge algorithm. > 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. cheers -ben > In most (all?) my professional work, this is the case. I have among my > projects a mix FPGA design (verilog + vhdl) + C (drivers, runtime) + > Smalltalk, and the smalltalk part is small. > > btw2, I found (https://githubengineering.com/move-fast/) interesting... >> saying... "Despite being a C library, libgit2 contains many powerful >> abstractions to accomplish complex tasks that Git simply cannot do. One of >> these features are indexes that exist solely in memory and allow work-tree >> related operations to be performed without an actual working directory. >> [...] With the in-memory index, libgit2 is capable of merging two trees in >> a repository without having to check out any of their files on disk." >> > > Yes, I considered that for GitFileTree. The current version uses > fast-import and archive (resp. to write and read) and in truth could work > on a bare repository, without working tree. > > Oh, by the way: it also solves the #lf issue, because you do everything > the unix way, even on windows: GitFileTree now never touches a file of the > host system. > > Thierry > > > >> >> On 11 April 2018 at 05:55, Esteban Lorenzano<estebanlm(a)gmail.com <mailto: >> estebanlm(a)gmail.com>>wrote: >> >> or a .iceberg file? >> >> Esteban >> >> ps: yep, we need itâ¦ we will have it, why not start now? >> >> >> Do you mean Iceberg would clone a repo, and from its included .iceberg >> file >> a matching .gitattributes file would be created? >> That seems like double handling. >> Why not have the user edit the .gitattributes file directly from >> Iceberg? >> Iceberg might provide some appropriate templates. >> >> >> cheers -ben >> >> > >

April 12, 2018