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

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Stephane Ducasse

Thanks!!!! On Tue, Apr 10, 2018 at 11:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 5 Apr 2018, at 09:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey(a)inria.fr> > wrote: > > Nice addition! > I should say that names are not really intention revealing. > What about haltIfTestExecutionEnvironment and > haltIfDefaultExecutionEnvironment ? > > To long and too implementation centered. > > I would even shorten it to haltIfTest and haltIfNotTest. > > > https://github.com/pharo-project/pharo/pull/1187/files > > I simplified them further and added test (will be in the next build) > > Marcus

April 11, 2018

Re: [Pharo-dev] Did magritte change? Magritte-Morph-SeasnDeNigris.95 is not found

by Stephane Ducasse

My roadmap is the following: - release Pillar 70 alpha (we made really nice progress) - work and release the tinyblog book - then work on magritte I will ping you when I arrive at this point. On Mon, Apr 9, 2018 at 3:33 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com > wrote: > > > On Mon, Apr 9, 2018 at 2:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Stephane Ducasse-3 wrote >> > I will create one >> >> There is https://github.com/magritte-metamodel/magritte which I forked >> from. >> I wonder if we can make that canonical. It would be easy for me to sync my >> changes back and from the README, it appears that most other Smalltalk >> load >> Magritte from elsewhere. Regarding Sqeak, there are the mcz repos, and >> IFAICT Squeak has not shown much interest in git, so we're probably safe >> there. Either way, please coordinate with me because the StHub repo is >> waaaay behind my forkâ¦ >> >> > > âYes I guess, this is better to reuse existing org on github. > Sean or me can invite people. > > âRegards,â > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ >

April 11, 2018

What about removing forks in Monticello browser

by Stephane Ducasse

Hi I have the impression that the forks around the monticello browser are introducing more mess than they solve. Would not be good to remove such behavior? Stef

April 11, 2018

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

by Sven Van Caekenberghe

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

April 11, 2018

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

by Thierry Goubier

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-ret… > <https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-ret…> > > 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_ap… 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. In most (all?) my professionnal 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@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 11, 2018

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

by Nicolas Cellier

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

April 11, 2018

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

by Sven Van Caekenberghe

Hmm, but why does the following work then ? $ ./pharo --headless Pharo.image eval '(FileStream stdin next: 3)' 123 '123' The binary case is an error though, for sure. And Zn character decoding works on binary streams, while the buffering streams read in blocks. And it always comes back to 'stdin is handled specially', is that so in C, generally speaking ? I am still digging though. I will send you some code later on. > On 11 Apr 2018, at 19:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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 >

April 11, 2018

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

by Alistair Grant

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

April 11, 2018

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

by Sven Van Caekenberghe

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. > On 11 Apr 2018, at 18:26, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On 11 April 2018 at 17:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> I think we have to reset this whole discussion. >> >> FileStream stdin >> >> and >> >> Stdio stdin >> >> are completely different ! >> >> We'll have to check that first, before talking about the issues raised in this thread. > > Are you sure you're comparing (roughly) equal things? > > I would compare: > > FileStream stdin > > (very roughly) to: > > ZnCharacterReadStream on: > (ZnBufferedReadStream on: > Stdio stdin). > > Actually it is still not a fair comparison because MultiByteFileStream > attempts to be writable as well. If you could notionally do: > > FileStream stdin > readOnly; > binary; > unbuffered; > yourself. > > you could compare FileStream and Stdio :-) > > One important similarity: At the bottom they both use the same set of > primitives to communicate with the OS stdio streams (FilePlugin). > > HTH, > Alistair > > > >> And BTW these terminal streams are a real pain to test ;-)

April 11, 2018

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

by Alistair Grant

Hi Sven, On 11 April 2018 at 17:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think we have to reset this whole discussion. > > FileStream stdin > > and > > Stdio stdin > > are completely different ! > > We'll have to check that first, before talking about the issues raised in this thread. Are you sure you're comparing (roughly) equal things? I would compare: FileStream stdin (very roughly) to: ZnCharacterReadStream on: (ZnBufferedReadStream on: Stdio stdin). Actually it is still not a fair comparison because MultiByteFileStream attempts to be writable as well. If you could notionally do: FileStream stdin readOnly; binary; unbuffered; yourself. you could compare FileStream and Stdio :-) One important similarity: At the bottom they both use the same set of primitives to communicate with the OS stdio streams (FilePlugin). HTH, Alistair > And BTW these terminal streams are a real pain to test ;-)

April 11, 2018