- Pharo-dev - lists.pharo.org

bloc next experiments
by Tudor Girba Jan. 14, 2018

Jan. 14, 2018

Hi, Happy New Year! We were asked about the roadmap of Bloc several times. It is a perfectly reasonable request given that Bloc is supposed to offer the UI infrastructure for the future of Pharo. However, I was reluctant to provide one because we do not really have a classic roadmap. When we develop Bloc and GT we think in terms of experiments and examples that we want to play with to get us to our goal. Features are a consequence of that. This approach allowed us on multiple occasions to stumble across functional possibilities that we would have not been able to think about before seeing the experiments. It also works the other way around: as we move ahead, we sometime discover modeling problems and we sometimes chase them all the way down. Having said that, we can specify the next examples and experiments that we consider for the next months. Here they are: â¢ Drag and drop that can be customized on an instance basis. In the process, revisit event management and explore making it use Announcements. Use this for the diagramming engine. â¢ Scrollbar for infinite list and the scalable element. â¢ Apply layout once. For example, this would allow us to apply a layout but still be able to drag elements in custom positions without disturbing the others. The first application is in the context of creating diagrams and visualizations. â¢ Apply layout with animation. For example, in Connector, a new example should be spawned and moved to its position through a smooth animation. This will also allow us to play with the concept of animation and MVVM. â¢ Introduce the concept of elevation. This is important for scenes in which we have overlapping elements that are not part of the composition tree. For example, in Connector, the lines connect inner elements inside the text, but they belong to the root. such as a visualization (but not only). For this to work, we need a better element traversing structure. â¢ Experiment with theming. The theming mechanism should be instance specific with per-widget defaults, and the theme values should ideally be injected in the widgets. The CSS implementation from Glenn is one direction. As developing and maintaining themes can be a nightmare in the long run, the theming mechanism to provide debugging tools. â¢ Experiment with delegating animations through the model. Typical MVVM or MVC focus on the behavior of an interaction. We want to get smooth live interfaces and the animation logic should be influence-able by the model. For example, hovering over a button, enlarges the button with extra details about the action. â¢ Basic widgets: list, input box, button, radio button, checkbox, menu, dropdown menu, toggling button, tabs, toolbar. â¢ Table and tree widgets. â¢ Pager interface (similar to the one in the current inspector) with resizable panes. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

1 0

Re: [Pharo-dev] Blame support P7
by Ben Coman Jan. 13, 2018

Jan. 13, 2018

On 13 January 2018 at 20:57, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Bcc: > Date: Sat, 13 Jan 2018 12:57:00 +0000 (UTC) > Subject: Re: [Pharo-dev] Blame support P7 >> So what would be the alternative? > > A centralized server (e.g. Cincom Public Repository, SqueakSource, SmalltalkHub, SqueakSource 3). After that, all you need is a detailed project/package/framework description. Google will index it. > > The whole "GitHub adventure" was started on the premise that it would give Pharo more visibility. >From what I remember of mail list discussions, the primary reason to move to github, which was reducing the need for a 24x7 operations team to support our code repository servers. http://forum.world.st/SmalltalkHub-bugs-hangs-tp4792551p4792598.html There was an argument that support effort would make the servers more reliable, but it seems both SqueakSource3 and Smalltalkhub were started in response to SqueakSource issues at some time. So ti still seems reasonable to make use of these 3rd party maintained VCS services. > > Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers. I was recently told "I just gave up on Smalltalk when I saw 200+ files"... It was too late. I told the poor guy it was just the way code was *stored* on GitHub but in your dev environment, everything resides in the image... Too late : I had lost him solely based on the impression that he was entering into a code management nightmare worse than a thousand C header files! Which repo was that? Was it before/after Tonel? > In the current state of things, the whole Cuis/Pharo/Squeak world is a mess. Newcomers looking for code end up having to pick between a myriad of links to SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz files, fileOuts, etc. > Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak (and/or others such as VW, VAST, Dolphin) and share a common import/export format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and would probably do a decent job) Yes, but please not XML. JSON like would be much nicer, where Tonel could be a good option. cheers -ben

1 0

ZnClient issue: ZdcPlugin Missing
by Photon Jan. 13, 2018

Jan. 13, 2018

Hello, I was just following along this book: and it told me to get some data via ZnClient like this, I tried them both with a dot inbetween and independantly like in the picture below. Does someone got an idea what`s wrong? <http://forum.world.st/file/t371759/ZnClient_issue.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

3 10

Re: [Pharo-dev] [Doodle] OpenSmalltalk VM Meeting
by Fabio Niephaus Jan. 13, 2018

Jan. 13, 2018

Hi all, This is a friendly reminder that you can still sign up for the below until tomorrow evening. Best, Fabio -- On Mon, Jan 8, 2018 at 8:46 PM Fabio Niephaus <lists(a)fniephaus.com> wrote: > Hi all, > > When ClÃ©ment and I recently talked about the next VM release, we thought > it might be good to organize a meeting and invite everyone who would be > interested. The agenda is yet to be finalized, but I think it would be > great if ClÃ©ment and/or Eliot could give an update on their work on Sista. > And I could give an overview of what still needs to be done for the release > or how we plan to sign and update the release bundles. I'm sure there is a > lot more we can talk about. > > If you would like to attend, please indicate your availability using this > Doodle link by Sunday, 14th January: > https://doodle.com/poll/cyei4ax4sd43m522. > > Looking forward to seeing you all soon. > > Best, > Fabio >

3 2

Protocol names convention
by Norbert Hartl Jan. 13, 2018

Jan. 13, 2018

Iâm not the biggest fan of method categories/protocols but I try to. What strikes me is the huge mess in names we have. Everytime I create e.g. an initialize method Iâm asking myself which is the proper name to choose initialize initializing initialization â¦. Do we have a convention for this? Right now all names starting with init are initialization-data initialize-destroy initialization-filter initialize - release initialize initialization-union initialize - event initializing initialization initalize-release initailize-release initialization widgets initalize initialize-release initialization-release Norbert

6 9

Re: [Pharo-dev] Blame support P7
by Stephane Ducasse Jan. 13, 2018

Jan. 13, 2018

I think that some people are talking without really understanding. Let me shed some light - Iceberg uses the Monticello meta model to compute models and store information in Git (files). - Now Monticello just stores the information in zip files. - In addition Pharo itself is doing the diff model and does not let git doing the diff between models. So I do not understand why Iceberg is less Smalltalk centric than Envy or Store (BTW about store I would have a lot to say about the industrial strength of the product - one db expert look at the model and he was realllllllly surprised.). - Now what Git gives us is that we can manage C, Pharo, PNG, css, .... the same way. In addition you may not like git (I do not like git personally but I really love the model) and we need to have a real decentralized source versioning control system. We are not afraid by sharing :) and collaborating. The world is using Git and we are too. The situation will improve and it will continue to improve. Now it looks like the great smalltalk community does not like when people get some traction. I cannot do much for them. Do not participate, complain and tell us that we are plain idiots and that this is our fault. Now nobody force anyone to use Pharo. We will continue and I'm confident that we will have success. Stef On Sat, Jan 13, 2018 at 2:01 PM, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Blame support P7 >>Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming >process, version control? This is a huge blunder. > > +1000 > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > >

2 1

Re: [Pharo-dev] Blame support P7
by Stephane Ducasse Jan. 13, 2018

Jan. 13, 2018

I think that some people are talking without really understanding. Let me shed some light - Iceberg uses the Monticello meta model to compute models and store information in Git (files). - Now Monticello just stores the information in zip files. - In addition Pharo itself is doing the diff model and does not let git doing the diff between models. So I do not understand why Iceberg is less Smalltalk centric than Envy or Store (BTW about store I would have a lot to say about the industrial strength of the product - one db expert look at the model and he was realllllllly surprised.). - Now what Git gives us is that we can manage C, Pharo, PNG, css, .... the same way. In addition you may not like git (I do not like git personally but I really love the model) and we need to have a real decentralized source versioning control system. We are not afraid by sharing :) and collaborating. The world is using Git and we are too. The situation will improve and it will continue to improve. Now it looks like the great smalltalk community does not like when people get some traction. I cannot do much for them. Do not participate, complain and tell us that we are plain idiots and that this is our fault. Now nobody force anyone to use Pharo. We will continue and I'm confident that we will have success. Stef On Sat, Jan 13, 2018 at 2:01 PM, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Blame support P7 >>Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming >process, version control? This is a huge blunder. > > +1000 > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > >

1 0

[Pharo 7.0-dev] Build #425: SUCCESS
by ci-pharo-ci-jenkins2＠inria.fr Jan. 12, 2018

Jan. 12, 2018

There is a new Pharo build available! The status of the build #425 was: SUCCESS. Could not extract further issue information from commit message: https://pharo.fogbugz.com/f/cases/20961/ Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #424: SUCCESS
by ci-pharo-ci-jenkins2＠inria.fr Jan. 12, 2018

Jan. 12, 2018

There is a new Pharo build available! The status of the build #424 was: SUCCESS. Could not extract further issue information from commit message: https://pharo.fogbugz.com/f/cases/20960/Move-ExecutionDisplayPlugin-from-Re… Reviewed the code and the tests Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #423: SUCCESS
by ci-pharo-ci-jenkins2＠inria.fr Jan. 12, 2018

Jan. 12, 2018

There is a new Pharo build available! The status of the build #423 was: SUCCESS. Could not extract further issue information from commit message: https://pharo.fogbugz.com/f/cases/20913/ Ok now the cascades are not introduced. Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0