- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Denis Kudriashov

But it shows notification why it does not supported and what to use instead. (it was not available in old versions) Idea to move away from star convention. Calypso gives you explicit tools to add method to the package. Most simple is checkbox "extension" in the status bar of method editor. For now star convention will stay internal implementation detail of RPackage. In future it should be completely removed (you know how RPackage is ugly because of that). Only old text code formats will use star protocols. So Calypso is a step to remove this "star habit" from users. 2018-04-12 11:42 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > in calypso. > * was simple and nice. > Now if I create a protocol with a star it got eaten and no protocol > will be created. > > Stef > >

April 12, 2018

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

by Stephane Ducasse

I will not make it but I really want. Let us know where will be the videos. Stef On Thu, Apr 12, 2018 at 9:09 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 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

Why can't we use * in protocol for package extension?

by Stephane Ducasse

in calypso. * was simple and nice. Now if I create a protocol with a star it got eaten and no protocol will be created. Stef

April 12, 2018

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