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

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

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

by Eliot Miranda

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 ;-) > > > 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 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. > 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 >> >> >> >

April 11, 2018

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

by Stephane Ducasse

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 11, 2018