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

Re: [Pharo-project] glamour and pharo

by Tudor Girba

Hi, On 1 Jan 2012, at 23:56, Lukas Renggli wrote: >> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). > > The size is the least problem. > > More annoying is that the code quickly gets out of sync and > non-changes are added to the history. Both of these problems are > already visible today. > > Additionally, over time people will change/add/remove features that > get integrated without proper review. I just had a look at the > announcement framework in Pharo 1.4 today, it is unbelievable how a > tiny framework could degrade to a bloated, untested and dead slow pile > of mud in just a few years :-( I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. But, what do you mean by slow? How did you benchmark it? > Moreover, every generic framework included with the core will sooner > or later introduce dependencies from random core packages. This only > makes it harder to have a modular system. And people that want to use > another refactoring engine (or another version thereof) are excluded, > because existing code depends on the included version. Again look at > where the announcements are used and how people work around to use > their own implementation. There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. >> p.s. I am happy that the competition pushes OB to get trees and resizable panes :) > > OB does not intend to compete with Glamour. OB only aims at a tiny > subset of what Glamour tries to solve. This was intended to be a joke. It deserved at least a "Happy New Year" :). Doru > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Tudor Girba

Hi Stef, On 1 Jan 2012, at 09:14, StÃ©phane Ducasse wrote: > > On Jan 1, 2012, at 1:24 AM, Tudor Girba wrote: >> >>> I do not like the magic of the block and arguments >> >> There really is little magic. In fact, it is about the same as the magic of Morphic calling selectors with arguments. > > except that it changes the perception of blocks arguments and usage. I do not understand. >>> Still I do not see how we extend browsers. We discussed that during the PhD meal at bern with lukas >>> and I'm still not convinced. >> >> I am not sure what you are referring to. > > How I can create a subclass and customize. Subclass of what? Perhaps we should just set a case study and I try to show something. But first, I would need to understand what the concern is. Could you help me with it? >> Please understand that this debate started because you said it's sad that Alex would choose to work on top of Glamour for the Metacello browser. I simply would like to understand why you think it's so. To me, there does not seem to be a strong argument. > > Because if alex can build a model and a little UI for basic image and wrap it with a better UI for glamouroust then > we all win. Now if there is no UI for basic then the people like me that are always coding in alpha and working a lot > with metacello will get zero benefit. > > I think that the plan is the following: > - make the best IDE you can and that the people use it like hell > - make sure that you force pharo to always load it > - for the moment we are focusing on cleaning below. Now the challenge is that we need tools too. Sounds ok :). It's much better than the "sad" remark :). But, I thought the whole idea of one Pharo image was to get some decent tools in there for the benefit of the infrastructural work as well. Am I wrong? Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). The size is the least problem. More annoying is that the code quickly gets out of sync and non-changes are added to the history. Both of these problems are already visible today. Additionally, over time people will change/add/remove features that get integrated without proper review. I just had a look at the announcement framework in Pharo 1.4 today, it is unbelievable how a tiny framework could degrade to a bloated, untested and dead slow pile of mud in just a few years :-( Moreover, every generic framework included with the core will sooner or later introduce dependencies from random core packages. This only makes it harder to have a modular system. And people that want to use another refactoring engine (or another version thereof) are excluded, because existing code depends on the included version. Again look at where the announcements are used and how people work around to use their own implementation. > p.s. I am happy that the competition pushes OB to get trees and resizable panes :) OB does not intend to compete with Glamour. OB only aims at a tiny subset of what Glamour tries to solve. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Tudor Girba

Hi Lukas, Please read my mails :). I was talking about Pharo distribution which in your language means Pharo Dev. I never argued for Pharo Core. And I also said that the whole misunderstanding stems from the position of the current Pharo image. To me, the current image is a convenience for the core development team. It is not Pharo Core. It is the Pharo Distribution. The minimal core is still desired, but it was not practical to get there with rudimentary tools. And I am unhappy that the present tools are just not good enough and there does not seem to be any progress in this area. To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). So, I think we have to clarify what it is intended with the current image and how we should organize to get both the minimal core (or maybe it's the kernel) and a distribution with cool dev tools. Cheers, Doru p.s. I am happy that the competition pushes OB to get trees and resizable panes :) On 1 Jan 2012, at 23:07, Lukas Renggli wrote: >> But, most people will load exactly the same thing: one set of development tools that should do the basic work nicely. This was the point of the Pharo distribution. And it shipped with OB and it was great. > > OB was never part of PharoCore, it was part of a distribution > (PharoDev) that originally Damien and then other people built on top > of PharoCore. For some reasons (not understandable to me) it was > decided not to have this "official" distribution anymore, but people > continued to build and use different distributions (see Moose, > Seaside, ...). > >> Only OB is rather limited, and apparently, it will not be supported anymore :). So, from this point of view, a browsing infrastructure is relevant for the Pharo distribution. > > OB is supported in Pharo 1.3. In fact, Colin and I have spent a lot of > time during the past months improving OB: laying the ground work for > multi-selection/trees, redesigned the rendering platforms (tool > builder, polymorph, web, ...; drag & drop, resizable panes), , etc. > >> Now, to me it seems that there is a problem with what different people understand by Pharo. And I think it would be good to clarify how we should get to the core image so that Lukas can get peace of mind :) > > This proposal is as ridiculous as if like Linux would suddenly decide > to include KDE or Gnome in the kernel. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

> But, most people will load exactly the same thing: one set of development tools that should do the basic work nicely. This was the point of the Pharo distribution. And it shipped with OB and it was great. OB was never part of PharoCore, it was part of a distribution (PharoDev) that originally Damien and then other people built on top of PharoCore. For some reasons (not understandable to me) it was decided not to have this "official" distribution anymore, but people continued to build and use different distributions (see Moose, Seaside, ...). > Only OB is rather limited, and apparently, it will not be supported anymore :). So, from this point of view, a browsing infrastructure is relevant for the Pharo distribution. OB is supported in Pharo 1.3. In fact, Colin and I have spent a lot of time during the past months improving OB: laying the ground work for multi-selection/trees, redesigned the rendering platforms (tool builder, polymorph, web, ...; drag & drop, resizable panes), , etc. > Now, to me it seems that there is a problem with what different people understand by Pharo. And I think it would be good to clarify how we should get to the core image so that Lukas can get peace of mind :) This proposal is as ridiculous as if like Linux would suddenly decide to include KDE or Gnome in the kernel. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

> Hi, > > I agree that people should load what they want on top of a nice little core. > > But, most people will load exactly the same thing: one set of development tools that should do the basic work nicely. This was the point of the Pharo distribution. And it shipped with OB and it was great. Only OB is rather limited, and apparently, it will not be supported anymore :). So, from this point of view, a browsing infrastructure is relevant for the Pharo distribution. > > Now, to me it seems that there is a problem with what different people understand by Pharo. And I think it would be good to clarify how we should get to the core image so that Lukas can get peace of mind :) :) > Cheers, > Doru > > p.s. And I told you that Glamour is small, not big :) I know. So we will see. Continue to push Glamour because we need tester of the changes we are doing - like the massive cleaning of the VM events handling. :)

Jan. 1, 2012

Re: [Pharo-project] Image input sensors blocked

by StÃ©phane Ducasse

> Hi guys, > > There is opportunity for someone of you to finally catch this bug! My > image is blocked again, but Aida is still working and my backdoor too :) > So, I can run any code on image. 'Sensor startUp' didn't help, what can > yet try? Last action was OSProcess related, can this be a problem, some > sempahore related stuff? Can you tell us which version you use? We faced a strange behavior related with event processing last week with igor. May be tomorrow we will investigate what is happening. But this is not related to OSProcess since we do not use it nor load it. For us, we could plug a completely new way to generate events, everything worked well HandMorph was using our new events, but a pop up would freeze to death the system. Stef > > Even better, contact me privately to get access to this image via web > and debug it by yourself. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Tudor Girba

Hi, I agree that people should load what they want on top of a nice little core. But, most people will load exactly the same thing: one set of development tools that should do the basic work nicely. This was the point of the Pharo distribution. And it shipped with OB and it was great. Only OB is rather limited, and apparently, it will not be supported anymore :). So, from this point of view, a browsing infrastructure is relevant for the Pharo distribution. Now, to me it seems that there is a problem with what different people understand by Pharo. And I think it would be good to clarify how we should get to the core image so that Lukas can get peace of mind :) Cheers, Doru p.s. And I told you that Glamour is small, not big :) On 31 Dec 2011, at 23:39, Lukas Renggli wrote: > On 31 December 2011 23:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I looked at it and >> I do not like the magic of the block and arguments >> and the scripting aspects >> Veronica showed me that she does not use long scripts. >> Still I do not see how we extend browsers. We discussed that during the PhD meal at bern with lukas >> and I'm still not convinced. >> >> Now if people want to load glamour perfect. Now I do not have any spare cycles >> to maintain it. My plate is full. For now I would like to have a good way to build and reuse Morphic widgets not to >> create another layer on top. > > +1000 > > Pharo should concentrate on the infrastructure, so that load what they > want: Glamour, OmniBrowser, ...; Seaside, Iliad, ...; or whatever the > next big thing is. > > Happy new year, > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com Things happen when they happen, not when you talk about them happening.

Jan. 1, 2012

[Pharo-project] Image input sensors blocked

by Janko MivÅ¡ek

Hi guys, There is opportunity for someone of you to finally catch this bug! My image is blocked again, but Aida is still working and my backdoor too :) So, I can run any code on image. 'Sensor startUp' didn't help, what can yet try? Last action was OSProcess related, can this be a problem, some sempahore related stuff? Even better, contact me privately to get access to this image via web and debug it by yourself. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Stephan Eggermont

There are a number of separate problems here, I think. Mixing them up makes the situation a bit complex. I'll try separating them here. At what abstraction level should the basic tools be build. From my point of view, Glamour provides the right level. It is very easy to build browsers and it is easy to keep them maintainable. When the underlying stack is going to be replaced it makes sense to have an abstraction layer that is is easy to implement on both the old and the new stack. The alternatives (Morphic, PolyMorph, OmniBrowser, ToolBuilder) are much less accessible. OmniBrowser looks much more comprehensive, but I don't feel qualified to comment on its usability as abstraction layer. I have taken a look at creating a google issue browser with Glamour (before ssl support) and think the committer workflow should be able to be improved with a few specialized Glamour browsers. But my opinion does not matter so much. That decision should be taken by the people maintaining the core of Pharo. Does Glamour provide enough functionality to build a whole tool chain? The focus of Glamour is on navigation in a single window, the language for updating and editing is limited. Drag-and-drop support is missing. Should the programming style of Glamour be the style to build basic tools in Pharo? Would it be better to use something more similar to the Seaside canvas style? The behavior change based on the number of block parameters is very powerful but imho also confusing. On the other hand I'm pretty sure HelpBrowser initWindow is worse than the equivalent Glamour code would be. At the moment the modularization of Pharo is not yet good enough. It is not easy enough to (de)compose images, so the maintainers need to have in the core image code to create user interfaces (web-based :) or direct). When we can create very small images and work with them using remote tools, this need will disappear. Committing to a tool chain build on top of Glamour would mean either back porting Glamour to earlier versions of Squeak/Pharo, so the new tools can replace the old ones everywhere, or breaking old tools and having to maintain them all ourselves. That is, if current maintainers agree with that. Happy new year, Stephan

Jan. 1, 2012