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

Re: [Pharo-dev] Pharo Launcher on Windows > Failing

by Vincent.Blondeau＠lamresearch.com

Hi Phil, I can help you to fix this issue. Can you tell me the list of the files in the folder that is designed by the error? And in the parent folder, there should be a zip file with the same name, can you check if Pharo.exe is here and if the file list is the same? It will be nice if you can serialize the stack and send it to me / post it in a new github issue: https://github.com/pharo-project/pharo-launcher/issues . Thanks, Vincent From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of phil(a)highoctane.be Sent: Thursday, April 12, 2018 7:58 To: Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Pharo Launcher on Windows > Failing I wanted to try Pharo Laucher before the tech talk But I get this when asking for an image [cid:image002.png@01D3D236.9CDB6FD0] I do not even know what is going on and I am an "experienced user". The impression this gives to a newcomer is utterly disastrous. We are really on a bad path on this. I'd like to get through this with some Launcher expert and fix this for good. Phil

April 12, 2018

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

by Alistair Grant

On 11 April 2018 at 20:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > But there is something wrong with what is returned by Stdio stdin > I've opened https://pharo.fogbugz.com/f/cases/21692/StdioStream-incorrectly-delegates-a… PR in progress. Cheers, Alistair

April 12, 2018

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

by Alistair Grant

On 12 April 2018 at 10:48, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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. Sorry Sven, this sounds like I'm suggesting that your planning to leave the MNU in there, which would be rather rude of me, but isn't what I meant at all. But I do think Zinc streams should handle #next returning nil before #atEnd answers true. Cheers, Alistair

April 12, 2018

Pharo Launcher on Windows > Failing

by phil＠highoctane.be

I wanted to try Pharo Laucher before the tech talk But I get this when asking for an image I do not even know what is going on and I am an "experienced user". The impression this gives to a newcomer is utterly disastrous. We are really on a bad path on this. I'd like to get through this with some Launcher expert and fix this for good. Phil

April 12, 2018

TechTalk on Iceberg will start in 30min (link inside)

by Esteban Lorenzano

here: https://www.youtube.com/estebanlorenzano/live <https://www.youtube.com/estebanlorenzano/live> see you there, Esteban

April 12, 2018

[Pharo 7.0-dev] Build #762: 21684-Integrate-Iceberg-0.7.1

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #762 was: SUCCESS. The Pull Request #1188 was integrated: "21684-Integrate-Iceberg-0.7.1" Pull request url: https://github.com/pharo-project/pharo/pull/1188 Issue Url: https://pharo.fogbugz.com/f/cases/21684 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 12, 2018

[Pharo 7.0-dev] Build #761: 21684-Integrate-Iceberg-0.7.1

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #761 was: FAILURE. The Pull Request #1188 was integrated: "21684-Integrate-Iceberg-0.7.1" Pull request url: https://github.com/pharo-project/pharo/pull/1188 Issue Url: https://pharo.fogbugz.com/f/cases/21684 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 12, 2018

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

by Denis Kudriashov

2018-04-12 12:49 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > I do not see why we should remove star protocols. Think about future module system which you already started to work with others. I don't think you plan to support string convention there. I just want RIGHT simple things: aMethod package: aPackage. or aPackage addMethod: aMethod. Instead of aMethod protocol: '*', aPackage name Which is the only way to create extension in current system. > It will break many things. > As soon as package management will do this part in the right way we will just need to fix code exporters and importers. But fixing package system is not easy task. Extension protocols and packages are bound implicitly using events. > Why can't we focus on important next steps. > I would say it is required step to achieve module system. > > On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > 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] Why can't we use * in protocol for package extension?

by Stephane Ducasse

Ok let us move away. Now I would like to know all the old ways and clean them. Stef On Thu, Apr 12, 2018 at 1:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-04-12 12:31 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> >>> 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. >> >> >> What is the correct way to generate such methods then? >> I use Something compile: 'method' classified: '*OtherPackage' ... but if >> the star convention is removed? > > > It should be simple package parameter like: > > Something compile: 'method' inPackage: #'OtherPackage' asPackage > > >> >> >> Thanks, >> Peter > >

April 12, 2018

Re: [Pharo-dev] How to remove the extra protocol in Calypso

by Stephane Ducasse

Hi guys I went to discuss with denis. And we will have some settings. And also better names for some menus. And also some fixes because some behavior was confusing and I got confused. Stef On Thu, Apr 12, 2018 at 12:54 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I want that the tools let me to get focused on my task. > And now I cannot disable. > > I do not want to live in a place with neon ads all over the place, I > want a calm place where I can pick > the tools I need when I need them and that they are not impose on me. > > BTW I will not adapt the mooc so students will use Pharo 50. Why > because I'm fedup to be the idiot > in this community upgrading books, slides and videos. > > Yes you can think that "oh we we cannot invent new stuff then we > should better stop" > - first I would like to see the people that think that to write more > than a page on doc. > - second paying attention to not impose new stuff for the shake on it > would be better > > Stef > > On Thu, Apr 12, 2018 at 12:50 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I want to remove >> critiques >> overridden >> overrides >> >> THEY GET IN MY WAY. >> Sorry to have to shout but I have the impression that I'm not heard. >> >> Ideally we could have a menu item to show extras things. RIght now >> each time I browse my class I stop >> because I have to interpret these new infroamtion and I'm not >> interested in them. >> >> Stef >> >> >> On Thu, Apr 12, 2018 at 12:46 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> Hi >>> >>> There are too much information by default I'm overhelmed. >>> I would like to remove the following protocols >>> >>> critiques

April 12, 2018