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

pharo 6.1 iceberg problem with latest windows (32bit) VM
by Sanjay Minni Jan. 15, 2018

Jan. 15, 2018

Using Pharo 6.1 with the latest windows 32 bit VM, i get the following message when trying to use world->tools->iceberg "This version of iceberg required libgit2 0.25.1, you have 0.23.0, pls update your PharoVM" regards Sanjay ----- --- Regards, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 1

Pharo Lecture at Tunis next week
by Stephane Ducasse Jan. 15, 2018

Jan. 15, 2018

Hi guys just to tell you that next week I will give a lecture at ENIS at tunis. 3 full days of Pharo and advanced design. Stef

4 3

Spec dynamic layout without dynamic widgets
by HernÃ¡n Morales Durand Jan. 15, 2018

Jan. 15, 2018

Hi guys, A comment from building Spec layouts for widgets (Pharo 6 but maybe applicable to Pharo >= 7): I have built a Spec widget which could have two layouts: #buttonsOnTopSpec and #buttonsOnBottomSpec : SpcLabeledActionsList new openWithSpec: #buttonsOnTopSpec; yourself. SpcLabeledActionsList new openWithSpec: #buttonsOnBottomSpec; yourself. Now if you would have to set such list as a widget in #initializeWidgets, the building process follows its path to #private_buildWithSpec which hardcodes the spec layout to the #defaultSpecSelector (the one containing <spec: #default> pragma). The problem subclassing from DynamicComposableModel / Presenter is that is trying to solve two problems at once: 1) Dynamic adding/removing widgets 2) Dynamic configuration of layout In this case I just need the 2), and I would have to remove inst. vars and accessors in ~20 classes because the dynamic widgets dictionary now stores all widgets, or interject a weirdo between ComposableModel/Presenter and DynamicComposableModel/Presenter. What would you do? Cheers, HernÃ¡n

2 2

a summary of the "blame" thread
by Dale Henrichs Jan. 14, 2018

Jan. 14, 2018

The recent "blame" thread seems to have touched on a sore point for some folks and the discussion has devolved into a melee of clashingÂ (s)words -- which in general is pretty counter-productive. I read through each of the messages in the thread and tried to pick out the concrete questions/issues that were brought up. I ignored the many meta arguments that went on and I may have missed some subthreads of importance, but I was surprised at the number of issues that were raised in the course of two days:): the lost author/timestampsÂ subthread the exchange code between dialects subthread the what is collaboration subthread the git is not smalltalk subthread the central server vs distributed server subthread the git support is important to new business subthread the iceberg has bugs, therefore it is wrong to use git subthread the Monticello is perfect so it isn't necessary to use git subthread the it works for me there it will work for everyone subthread the multi-platform support subthread the we at y think git is cool, but disagree with the approach taken by z subthread Each of these points/issues/arguments for the most part is important, some not so important and some already addressed, but amazingly the vast majority of the topic never got a reply as some of these threads were buried in a message that also contained meta arguments. In re-reading the list it is clear to me that my personal bias crept into the short summary, but frankly when I reread those messages I wasn't able to summarize the actual point, because it was not necessarily clear what the real point was --- not enough detail --- I included it with my funky interpretation because it is probably worth discussing at some level, but the discussion deserves more substance. I seems to me that each of the dialects in play: Cuis, Pharo, Squeak, and GemStone has consistent answers to each of the subthreads, but perhaps it is the cross-platform nature of of the issues that is at the core of the arguments ... Pharo has taken the bull by the horns and committed to using git/github for the Pharo kernel source code and thereby committed to making it easy to use git (and presumably other disk-based SCMs ... eventually) from within the Pharo7.0 image ... the decision has been made and the conversion pains are being felt (which is not unexpected). Clearly this move by Pharo does have an (eventual?/varying) impact on the other Smalltalk dialects. For GemStone we are moving pretty much in the same direction as Pharo is moving and for many of the same reasons ... I have been grumpy about the unilateral move to Tonel, but We are expecting to introduce git/package/Metacello support in the base in the next release of GemStone (just a simple matter or resources:). We are using Tonel and git in our internal product development process in a limited way. Besides the obvious reasons, Metacello support is there so that our customers who are not using GsDevKit can have the option of loading/contributing to open source Smalltalk projects hosted on github. We do not plan to support .mcz files in the kernel. We will most likely base our kernelÂ git tools support on bash command line git (a feature that has been in tODE for about 5 years). Our server product is not supported on Windows, so we can get away with that.. Windows clients are supported, but not Windows servers. With regards to central vs. distributed server, we lean towards distributed servers. We have a number of customers whose production systems are behind firewalls that make it very difficult if not impossible for the Smalltalk developers to access network-based Monticello web-sites let alone CVS-style centralized servers. So making it possible for those developers to use local git clones "transparently" is a seen as a real advantage ... Finally our open source GsDevKit project has a Pharo compatibility layer, so being able to share source code with Pharo is a priority and Metacello is a key component in that support. Monticello .mcz files will continue supported in GsDevKit as long as the critical projects for customers continue to be hosted inÂ Monticello .mcz repositories ... eventually I expect .mcz support to become an optional component in GsDevKit, but I won't put a date on it since I do expect to support Monticello for some definition of forever:) Dale

1 0

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