Hi, Let's take this on the Pharo mailing list. I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). And I also think your analysis is not accurate. Here is why (I apologize for the long list): 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. So, before dismissing Glamour, perhaps it would be useful to actually look into it. Cheers, Doru
On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote:
Hi Stef,
You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo.
Do you think so? I do not think that we can base our infrastructure on something that only one person understand and can modify. You will tell that this is the same for Morphic but this is not true.
Stef
-- www.tudorgirba.com "Beauty is where we see it."
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. Stef On Dec 31, 2011, at 5:13 PM, Tudor Girba wrote:
Hi,
Let's take this on the Pharo mailing list.
I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte).
And I also think your analysis is not accurate. Here is why (I apologize for the long list):
1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more.
2. It is quite well tested. This part can be improved, but the core has some 80% coverage.
3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult.
4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes.
5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too.
6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes.
7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too.
I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now.
So, before dismissing Glamour, perhaps it would be useful to actually look into it.
Cheers, Doru
On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote:
Hi Stef,
You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo.
Do you think so? I do not think that we can base our infrastructure on something that only one person understand and can modify. You will tell that this is the same for Morphic but this is not true.
Stef
-- www.tudorgirba.com
"Beauty is where we see it."
On 31 December 2011 23:33, Stéphane Ducasse <stephane.ducasse@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
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@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.
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. :)
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
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."
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
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."
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.
Nice argument for your students reading this thread: http://memegenerator.net/instance/12779750.
But, what do you mean by slow? How did you benchmark it?
No, but if you look at the code you will see many extra steps: 1. It tests if a registry is there: Why would that be necessary in an object-oriented implementation? 2. It tests if the registry is empty: Why would that be necessary in an object-oriented implementation? 3. It enters a critical section of a monitor: This is rarely useful and the slowest kind of concurrency control available in Pharo (a Mutex would be enough for what it is used for, and instantiate multiple semaphores and queues), and btw the lazy initialization of the monitor is the prime example of a race condition. 4. It creates a copy of the collection of all the subscriptions: This is rarely useful and wouldn't be necessary if an immutable data structure was used. 5. It iterates over all announcements, it doesn't even try to group announcements of the same kind. 6. It wraps each announcement delivery into a curtailed block. It does that even for those that are never actually announced. 7. It then tests each announcement if it matches, again it doesn't even try to group the announcements of the same kind. Aside, the match test was changed so that it doesn't allow instance-based announcements anymore, breaking some of my code. 8. It then wraps the actual notification into an exception handler. Again, this is rarely useful and should probably rather be something pluggable. 9. It then culls the announcement and announcer into the block. Not sure why the announcer is useful, after all the block was registered with the announcer at some point. So all these 9 steps are not really necessary (or even wanted) in most case. I doubt that any of them makes the code faster. I am glad that the code works for you even if all of this new functionality is untested. And good luck with the race condition :-)
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.
Do you really believe that stripping away unwanted material works? No other open source project in the whole world does it like that, everybody builds distributions on top of a smaller core: Linux, GCC, Gnome, FireFox, ... Even in the supermarket, you typically don't get a vegetable hamper if you just want a some potatoes. Lukas -- Lukas Renggli www.lukas-renggli.ch
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.
Nice argument for your students reading this thread: http://memegenerator.net/instance/12779750.
Why other should be stupid axiomatically?
But, what do you mean by slow? How did you benchmark it?
No, but if you look at the code you will see many extra steps:
1. It tests if a registry is there: Why would that be necessary in an object-oriented implementation?
2. It tests if the registry is empty: Why would that be necessary in an object-oriented implementation?
3. It enters a critical section of a monitor: This is rarely useful and the slowest kind of concurrency control available in Pharo (a Mutex would be enough for what it is used for, and instantiate multiple semaphores and queues), and btw the lazy initialization of the monitor is the prime example of a race condition.
4. It creates a copy of the collection of all the subscriptions: This is rarely useful and wouldn't be necessary if an immutable data structure was used.
5. It iterates over all announcements, it doesn't even try to group announcements of the same kind.
6. It wraps each announcement delivery into a curtailed block. It does that even for those that are never actually announced.
7. It then tests each announcement if it matches, again it doesn't even try to group the announcements of the same kind. Aside, the match test was changed so that it doesn't allow instance-based announcements anymore, breaking some of my code.
8. It then wraps the actual notification into an exception handler. Again, this is rarely useful and should probably rather be something pluggable.
9. It then culls the announcement and announcer into the block. Not sure why the announcer is useful, after all the block was registered with the announcer at some point.
So all these 9 steps are not really necessary (or even wanted) in most case. I doubt that any of them makes the code faster. I am glad that the code works for you even if all of this new functionality is untested. And good luck with the race condition :-)
Why did you discuss that with igor and henrik? I mean ***discuss*** not taking the working hypotheses that they are idiot writing dull codeâ¦
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.
We do not want to strip an image in the long but if to make sure that we can make progress we have to add stuff to the image we will. I added RB because we were thinking that I could have time to work on RPackage that we could load Nautilus but I got trapped by new duties. Still see my other mails. Stef
On 02 Jan 2012, at 10:53, Stéphane Ducasse wrote:
We do not want to strip an image in the long but if to make sure that we can make progress we have to add stuff to the image we will. I added RB because we were thinking that I could have time to work on RPackage that we could load Nautilus but I got trapped by new duties. Still see my other mails.
You guys have the same argument again and again. Stef, to me it looks like you have conflicting goals with Pharo. You want to make everything better, and all at the same time. My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time. Happy new year Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On Jan 2, 2012, at 11:11 AM, Stefan Marr wrote:
On 02 Jan 2012, at 10:53, Stéphane Ducasse wrote:
We do not want to strip an image in the long but if to make sure that we can make progress we have to add stuff to the image we will. I added RB because we were thinking that I could have time to work on RPackage that we could load Nautilus but I got trapped by new duties. Still see my other mails.
You guys have the same argument again and again.
Stef, to me it looks like you have conflicting goals with Pharo. You want to make everything better, and all at the same time.
My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time.
this is what we are doing :) Because there are parts we refrained ourselves to even look at them :) Stef
On 02 Jan 2012, at 11:30, Stéphane Ducasse wrote:
My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time.
this is what we are doing :) Because there are parts we refrained ourselves to even look at them :)
No, you are not focusing at all. You do everything and you want everything. You want a full blown Pharo distribution with great dev tools to enable businesses. You want bootstrapping. You want better event handling. You want a vector canvas. You want better infrastructure like the Ring. You want RPackage. You want remote debugging. You want ... I guess if I would dig through the discussions I could make up a list with at least 20 items. That is not what I would call focused. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On Jan 2, 2012, at 11:47 AM, Stefan Marr wrote:
On 02 Jan 2012, at 11:30, Stéphane Ducasse wrote:
My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time.
this is what we are doing :) Because there are parts we refrained ourselves to even look at them :)
No, you are not focusing at all. You do everything and you want everything.
You want a full blown Pharo distribution with great dev tools to enable businesses. You want bootstrapping. You want better event handling. You want a vector canvas. You want better infrastructure like the Ring. You want RPackage. You want remote debugging. You want ...
Stefan wanting and doing are two different things. Wanting let us plan. Now you can believe that we do not plan. You can also check what we are committing in the changes and see that this is not always what we want.
I guess if I would dig through the discussions I could make up a list with at least 20 items.
That is not what I would call focused.
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Lukas please read this mail until the end before replying :) I want a tool suite that can work on another environment being it remote. I want to be able to refactor the code of the compiler that it is another image from this one. We need to be able to act on other cores. It does not look totally a stupid requirement. for RB this is simple :) If we cannot discuss and build something with you and that you stand on your position without taking time to see that we need to have it fully parametrized so that we could ideally refactor remote code, then what is left for us to do? Ok we take responsibilities for the changes we do. This is not the best solution for us but if we are forced then we do it. Even if adapting configurationOf can take my energy. Since we are a bit stupid we will do mistakes and may be you will be right but does it matter? Because at the end this is what we can do that count. The correct approach would have been to really try to see that the original design of RB is not immutable, it can be changed, it was not done for remote or other system refactoring. I saw that you fixed some of the problems I reported like directly accessing Smalltalk globals where it should not. Now instead of too often shooting at us negatively you would simply try to understand that: - moving implies breaking - the state of the system is still spaghetti code (how come that we should deprecate a method that generate accessor implemented on scrollbar!!!). - testing is important but on time (for example 1.3 was release as RC during at least 3 months and you complained because you tried it after 1.3 was out). - you can be sardonic if this helps you but I do not see the added value on the long term.
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 :-(
You cannot say that. This is insultant for the time and effort igor and henrik spent on it. Why do you think that announcement should stay a system that anybody can write in 2 hours, not dealing with weak registry? Now a gift for you. When you write impersonal mails this is easier to piss on people (Even if I decided that such little flood of nasty thoughts will not reach me). Avoid impersonal mails, put the human in the center of the loop. When you want to say "stef you are idiot because" just write it. Do the same say "Igor is a fucking idiot because he bloated Announcement" or "Henrik writes muddy and untested code". (writing this one made me laugh when I remember that igor and henrik stayed until 10 in the evening writing tests and improving announcement).
Moreover, every generic framework included with the core will sooner or later introduce dependencies from random core packages.
Why do you say random. Of course people make mistakes and are not perfect. But we will fix it. Lukas do you want to be our andreas? Because to me this is what you are doing. Been smart and aggressive for the sake of it. You can do it if you have to pass by this stage but you could act in a much more friendly way and gain positive feeling in addition. You could be the pharo heros and have fun with us killing dragons - because this is what we did last thursday with the fucking event loop with igor.
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.
You see I read and spent time to answer your kind of mail. Because you are still my friend and because I had a lot of fun with you and I'm sure that you could have fun with us. Now tell us how you want to interact with us. Think about it because this is the new year resolution. What I would like is - I have no problem to remove RB from the image. But I need to be able to change it. for RPackage (you know the bad code I'm writing because the system is so well done). I need to change it also because I want to be able to plug into another image and refactor it remotely. I hope nick will start for real on that. - So if you want to communicate in a humane way with us. No problem, we can and we are happy to have fun with you. Now I do not want to get your frustration on my shoulders. I'm doing Pharo to build a better world and you know it. Stef
please read this mail until the end before replying :)
Done.
Moreover, every generic framework included with the core will sooner or later introduce dependencies from random core packages.
Why do you say random. Of course people make mistakes and are not perfect. But we will fix it.
I am saying "random" because people (including me) will start to use whatever the auto-completion is offering. And we all know that the proposals of the auto-completion are rather random at times. You can see that in Pharo, Seaside, Pier, Magritte, ... over time packages tend to blend. Whatever you add now, you cannot easily remove tomorrow.
You see I read and spent time to answer your kind of mail. Because you are still my friend and because I had a lot of fun with you and I'm sure that you could have fun with us.
Thank you. Now this makes me wonder how I should behave if I am not allowed to say why I think that Pharo is on the wrong track? You want me to shut up and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Jan 2, 2012, at 11:08 AM, Lukas Renggli wrote:
please read this mail until the end before replying :)
Done.
Moreover, every generic framework included with the core will sooner or later introduce dependencies from random core packages.
Why do you say random. Of course people make mistakes and are not perfect. But we will fix it.
I am saying "random" because people (including me) will start to use whatever the auto-completion is offering. And we all know that the proposals of the auto-completion are rather random at times. You can see that in Pharo, Seaside, Pier, Magritte, ... over time packages tend to blend. Whatever you add now, you cannot easily remove tomorrow.
I know. This is why I worked on bootstrap during holidays and cleaning event.
You see I read and spent time to answer your kind of mail. Because you are still my friend and because I had a lot of fun with you and I'm sure that you could have fun with us.
Thank you.
Now this makes me wonder how I should behave if I am not allowed to say why I think that Pharo is on the wrong track?
say it! we are not against this kind of feedback. You know well that I hate politically correctness. But think positive. For example for Announcement: - raise the issue - motivate the point - send code I'm 100% sure that igor will value your code and criticisms. We are all for improving but not for bad words and the system will get better. We are not autists and we value feedback even when it is negative. We listen what you are saying believe me.
You want me to shut up no just use other words. Yesterday I was in a library reading books on positive communication and I'm sure that we can all improve, me the first :).
and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out.
Not totally true :). I could merge the code each time you publish a new version but this is tedious. So how do we collaborate? :). First I will update the RB version. You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :). But I would not do that for RB. We can unload RB from 1.4 without problem but I would like to have a - calm - non conflictual - reasonable - with clear argument (because I checked the BrowserEnvironment new location and I imagine that plugin an environment instead is not something that is done in 15 min) roadmap so that WE (YOU and US) can build a roadmap together. I do not think it is much. I'm even ready to be calm :)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out.
Not totally true :). I could merge the code each time you publish a new version but this is tedious. So how do we collaborate? :). First I will update the RB version.
I looked at the ConfigurationOfRefactoringEngine today, and I could not figure out how to update it: - There is now a package Refactoring-Pharo-Platform that should be loaded together with Refactoring-Core. - There seems to be some code moved between the packages in Pharo 1.4, so I don't see how the head can be merged with that code. - There are parts for GemStone and Squeak in the configuration, that I don't know how to deal with.
You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :).
Zinc is something else. Zinc is a clean replacement for HTTPSocket. It is backward compatible by providing the old and ugly HTTPSocket interface. The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development. As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project? This leads me to the question: Did anybody ever sketch an architecture of where Pharo should be heading to? I created a simplified one based on my own understanding of the current proposals: http://bit.ly/vpnAf1 (Google Docs). I think Pharo should concentrate only one the blue squares, eventually only on the dark-blue one. Everything else should be a distribution on top. Kernel developers might want/need to use a distribution on top of the kernel themselves. Although it has been argued in the past that this doesn't work, I don't see a reason why not. In any other open source project (i.e. a Linux kernel hacker might as well use Emacs or Gnome, even if they are not part of the kernel) people work like this, why not in Pharo too? Lukas -- Lukas Renggli www.lukas-renggli.ch
On Jan 2, 2012, at 2:18 PM, Lukas Renggli wrote:
and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out.
Not totally true :). I could merge the code each time you publish a new version but this is tedious. So how do we collaborate? :). First I will update the RB version.
I looked at the ConfigurationOfRefactoringEngine today, and I could not figure out how to update it:
I will look at it once we beat the event crashing bug because I hate it. BTW something I would like is - we have a core - when working on coreA, we load all the system in another core - from this other core we hack with rb and other tools the coreA - we publish changes to coreA - without having to touch core and we produce coreA without interference Because I loaded RB in Core because we crawl in mud all the time and I do everything by hand. Now the problem is that also we cannot scope the changes.
- There is now a package Refactoring-Pharo-Platform that should be loaded together with Refactoring-Core.
- There seems to be some code moved between the packages in Pharo 1.4, so I don't see how the head can be merged with that code.
Strange it should not.
- There are parts for GemStone and Squeak in the configuration, that I don't know how to deal with.
Me too :)
You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :).
Zinc is something else. Zinc is a clean replacement for HTTPSocket. It is backward compatible by providing the old and ugly HTTPSocket interface.
The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development.
Now see above this is not research. I cannot publish anything on that.
As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project?
Lukas we want only one compiler but we should be able to edit its code. RIght now marcus has the old compiler as a fallback and this is annoying. We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also object environment (nil trueâ¦.) so that we can bootstrap it with itself.
This leads me to the question: Did anybody ever sketch an architecture of where Pharo should be heading to? I created a simplified one based on my own understanding of the current proposals: http://bit.ly/vpnAf1 (Google Docs).
We should because we know where we want to go.
I think Pharo should concentrate only one the blue squares, eventually only on the dark-blue one. Everything else should be a distribution on top. Kernel developers might want/need to use a distribution on top of the kernel themselves. Although it has been argued in the past that this doesn't work, I don't see a reason why not. In any other open source project (i.e. a Linux kernel hacker might as well use Emacs or Gnome, even if they are not part of the kernel) people work like this, why not in Pharo too?
Probably.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development.
Now see above this is not research. I cannot publish anything on that.
Ok, then be it a separate open-source project that Pharo does not need to depend on.
As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project?
Lukas we want only one compiler but we should be able to edit its code. RIght now marcus has the old compiler as a fallback and this is annoying. We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also object environment (nil trueâ¦.) so that we can bootstrap it with itself.
I don't understand what you write, but I guess it boils down to having namespaces that allows one to load and use different variations of the same code at once. This would also solve my problem with the refactoring engine: Pharo could depend on one version, I could use another one. Seems to me quite a central kind of functionality to make progress. Again to make the analogy with Linux: This seems to be the virtual machines that allow one to easy test and run other kernels aside. Lukas -- Lukas Renggli www.lukas-renggli.ch
As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project?
Lukas we want only one compiler but we should be able to edit its code. RIght now marcus has the old compiler as a fallback and this is annoying. We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also object environment (nil trueâ¦.) so that we can bootstrap it with itself.
I don't understand what you write, but I guess it boils down to having namespaces that allows one to load and use different variations of the same code at once.
Not only but nearly. we should even be able to say from which class literal true is and potentially have two different ones.
This would also solve my problem with the refactoring engine: Pharo could depend on one version, I could use another one.
Yes this is what we want for pharo and this is why we are cleaning everything too . but for that it means that all the tools chain should be parametrized by environment. Compiler, senders, implementors, test and refactoring is one of them. Remote is just one case. And since Nick needs it, this is a way to get momentum.
Seems to me quite a central kind of functionality to make progress.
We are working on it regularly. SystemNavigation was fixed, then we get some problems with TestRunner. Because we should be able to run tests defined in another one. So this poses the question of late bound classes. So before getting there we should be able to experiment. And for that we need to have a parametrized environment.
Again to make the analogy with Linux: This seems to be the virtual machines that allow one to easy test and run other kernels aside.
Yes this is the vision. We think about that since a couple of year with marcus. The bootstrap is also part of the story.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Hi, Stepping into this conversation :) ...and just to point one thing: IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. I think Pharo needs to be Kernel+Development Tools. Now, real objective is to make dev tools modules that you can load/unload, so you can have Kernel+Morphic Tools, Kernel+Glamoroust, Kernel+OB, etc. So, questions arise: 1) How do we achieve the objective of being real modular? 2) Which "dev tools" will be "blessed" (and maintained in the long way) by Pharo? I think right now we are trying to solve (1), so it has sense to want the simplest dev tools possible (That's how I interpret Stef requirements of not-on-top-of-yet-another-package)... But that will work for some time, once we have a modular kernel, Pharo needs powerful tools. It will be Glamouroust? I really don't know... I like it, but what I would like is to discuss what Glamour needs to be the tool we need, because other way, we will end with yet-another-tool-builder, and yet-another-discussion about which one adopt. What needs to be done in glamour to reach our goals? well... that's another discussion (and I'm agree, right now It can't be integrated as Pharo main distribution, but it could once Glamoroust is ready)... but this is my list: 1) drag&drop support 2) better menu handling/building (is too unflexible, now) well... I can keep talking about glamoroust tools, but non-sense right now :) best, Esteban El 02/01/2012, a las 10:37a.m., Stéphane Ducasse escribió:
On Jan 2, 2012, at 2:18 PM, Lukas Renggli wrote:
and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out.
Not totally true :). I could merge the code each time you publish a new version but this is tedious. So how do we collaborate? :). First I will update the RB version.
I looked at the ConfigurationOfRefactoringEngine today, and I could not figure out how to update it:
I will look at it once we beat the event crashing bug because I hate it. BTW something I would like is
- we have a core - when working on coreA, we load all the system in another core - from this other core we hack with rb and other tools the coreA - we publish changes to coreA - without having to touch core and we produce coreA without interference
Because I loaded RB in Core because we crawl in mud all the time and I do everything by hand. Now the problem is that also we cannot scope the changes.
- There is now a package Refactoring-Pharo-Platform that should be loaded together with Refactoring-Core.
- There seems to be some code moved between the packages in Pharo 1.4, so I don't see how the head can be merged with that code.
Strange it should not.
- There are parts for GemStone and Squeak in the configuration, that I don't know how to deal with.
Me too :)
You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :).
Zinc is something else. Zinc is a clean replacement for HTTPSocket. It is backward compatible by providing the old and ugly HTTPSocket interface.
The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development.
Now see above this is not research. I cannot publish anything on that.
As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project?
Lukas we want only one compiler but we should be able to edit its code. RIght now marcus has the old compiler as a fallback and this is annoying. We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also object environment (nil trueâ¦.) so that we can bootstrap it with itself.
This leads me to the question: Did anybody ever sketch an architecture of where Pharo should be heading to? I created a simplified one based on my own understanding of the current proposals: http://bit.ly/vpnAf1 (Google Docs).
We should because we know where we want to go.
I think Pharo should concentrate only one the blue squares, eventually only on the dark-blue one. Everything else should be a distribution on top. Kernel developers might want/need to use a distribution on top of the kernel themselves. Although it has been argued in the past that this doesn't work, I don't see a reason why not. In any other open source project (i.e. a Linux kernel hacker might as well use Emacs or Gnome, even if they are not part of the kernel) people work like this, why not in Pharo too?
Probably.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I foresee Pharo as multithreaded OS, like HP's dropped WebOS. All based on one interpreter. Why not? Guido Stepken Am 02.01.2012 um 17:41 schrieb Lukas Renggli <renggli@gmail.com>:
IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions.
Esteban, why not? Can you give one technical reason why what Linux does cannot work for Pharo?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Hi Lukas, is not that *it can't* is that, as a development platform, Pharo needs to provide kernel+tools, not just kernel. Anyway, I was not arguing against having a small kernel, I was arguing against pharo "just doing" the kernel. Linux itself can't be distributed just as a kernel, it is distributed with a full set of different tools: GNU/Linux, Ubuntu Linux, etc. (btw... this is one of the arguments Stallman allways says about Linux: it was possible because there was already a lot of tools) And, in that case, just as Linux, we can't just do the kernel, we need to provide development tools... otherwise, people wont use it. I myself wont use it for my commercial applications if I do not have something like OmniBrowser to develop. What I'm saying: Pharo is not the Kernel, is the Kernel + Tools (we are not just linux... we are linux+eclipse, if you want) What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it) ...and I'm also saying that, at this stage (while we are achieving the "modularization phase") , it is ok that Tools are reduced to it's minimum... of course if I can load other dev tools, like ob or glamour). But we as Pharo community need to ensure there are a powerful set of tools that makes ppl happy. Cheers, Esteban El 02/01/2012, a las 1:41p.m., Lukas Renggli escribió:
IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions.
Esteban, why not? Can you give one technical reason why what Linux does cannot work for Pharo?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
is not that *it can't* is that, as a development platform, Pharo needs to provide kernel+tools, not just kernel. Anyway, I was not arguing against having a small kernel, I was arguing against pharo "just doing" the kernel. Linux itself can't be distributed just as a kernel, it is distributed with a full set of different tools: GNU/Linux, Ubuntu Linux, etc. (btw... this is one of the arguments Stallman allways says about Linux: it was possible because there was already a lot of tools) And, in that case, just as Linux, we can't just do the kernel, we need to provide development tools... otherwise, people wont use it. I myself wont use it for my commercial applications if I do not have something like OmniBrowser to develop.
I totally agree, the Pharo Kernel alone is not very useful for an end-user. However, with the emerging Pharo architecture you can hardly build a different distribution. To use the Linux analogy: You are trying to convince GNU/Linux to rebuild their system on top of a full-fledged Ubuntu distribution.
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it)
This coupling is exactly what is happening. How do you propose to build your kernel+other distribution? Lukas -- Lukas Renggli www.lukas-renggli.ch
On 2 January 2012 18:44, Lukas Renggli <renggli@gmail.com> wrote:
is not that *it can't* is that, as a development platform, Pharo needs to provide kernel+tools, not just kernel. Anyway, I was not arguing against having a small kernel, I was arguing against pharo "just doing" the kernel. Linux itself can't be distributed just as a kernel, it is distributed with a full set of different tools: GNU/Linux, Ubuntu Linux, etc. (btw... this is one of the arguments Stallman allways says about Linux: it was possible because there was already a lot of tools) And, in that case, just as Linux, we can't just do the kernel, we need to provide development tools... otherwise, people wont use it. I myself wont use it for my commercial applications if I do not have something like OmniBrowser to develop.
I totally agree, the Pharo Kernel alone is not very useful for an end-user. However, with the emerging Pharo architecture you can hardly build a different distribution.
To use the Linux analogy: You are trying to convince GNU/Linux to rebuild their system on top of a full-fledged Ubuntu distribution.
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it)
This coupling is exactly what is happening. How do you propose to build your kernel+other distribution?
What coupling you are talking about? Can you give an example? Instead we striving to decouple components of the system and improve infrastructure. If you speaking about announcements, so here the vision: - there are tons of different event driving mechanisms in image and we want to leave only one, replacing all of them with announcements. Will this couple tools to announcements? Of course. Will this add unnecessary coupling between layers? No. Because announcements is inherently serving for decoupling event source(s) from event consumers. -- Best regards, Igor Stasenko.
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it)
This coupling is exactly what is happening. How do you propose to build your kernel+other distribution?
What coupling you are talking about? Can you give an example? Instead we striving to decouple components of the system and improve infrastructure. If you speaking about announcements, so here the vision: Â - there are tons of different event driving mechanisms in image and we want to leave only one, replacing all of them with announcements. Will this couple tools to announcements? Of course. Will this add unnecessary coupling between layers? No. Because announcements is inherently serving for decoupling event source(s) from event consumers.
THis is not about announcements. I am talking about adding new UI, FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such addition will increase the coupling in Pharo because the core and external clients will start to slowly adapt these frameworks. This adaptation increases the coupling (to this particular framework) and means that it will be increasingly hard to unload or replace them in the future. Or shorter: What you add today, you cannot easily remove again tomorrow. Lukas -- Lukas Renggli www.lukas-renggli.ch
On 3 January 2012 14:35, Lukas Renggli <renggli@gmail.com> wrote:
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it)
This coupling is exactly what is happening. How do you propose to build your kernel+other distribution?
What coupling you are talking about? Can you give an example? Instead we striving to decouple components of the system and improve infrastructure. If you speaking about announcements, so here the vision: Â - there are tons of different event driving mechanisms in image and we want to leave only one, replacing all of them with announcements. Will this couple tools to announcements? Of course. Will this add unnecessary coupling between layers? No. Because announcements is inherently serving for decoupling event source(s) from event consumers.
THis is not about announcements. I am talking about adding new UI, FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such addition will increase the coupling in Pharo because the core and external clients will start to slowly adapt these frameworks. This adaptation increases the coupling (to this particular framework) and means that it will be increasingly hard to unload or replace them in the future.
Or shorter: What you add today, you cannot easily remove again tomorrow.
i don't understand your concerns here. if we replacing old compiler with a new one, should external clients adapt new compiler? sure they should. but they will only benefit from that. so i don't see what are problem here? and about unloading.. do you think it will be worse than in existing system? or you suspect that we're not caring about that in new frameworks design? again, i don't really understand what is your concerns grounded on. should we stop improving system because any change have a potential risk of breaking someone's code?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko.
Igor Stasenko wrote:
On 3 January 2012 14:35, Lukas Renggli <renggli@gmail.com> wrote:
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it)
This coupling is exactly what is happening. How do you propose to build your kernel+other distribution?
What coupling you are talking about? Can you give an example? Instead we striving to decouple components of the system and improve infrastructure. If you speaking about announcements, so here the vision: - there are tons of different event driving mechanisms in image and we want to leave only one, replacing all of them with announcements. Will this couple tools to announcements? Of course. Will this add unnecessary coupling between layers? No. Because announcements is inherently serving for decoupling event source(s) from event consumers.
THis is not about announcements. I am talking about adding new UI, FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such addition will increase the coupling in Pharo because the core and external clients will start to slowly adapt these frameworks. This adaptation increases the coupling (to this particular framework) and means that it will be increasingly hard to unload or replace them in the future.
Or shorter: What you add today, you cannot easily remove again tomorrow.
i don't understand your concerns here. if we replacing old compiler with a new one, should external clients adapt new compiler? sure they should. but they will only benefit from that. so i don't see what are problem here?
and about unloading.. do you think it will be worse than in existing system? or you suspect that we're not caring about that in new frameworks design? again, i don't really understand what is your concerns grounded on. should we stop improving system because any change have a potential risk of breaking someone's code?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I am reminded of an article "Things You Should Never Do" [1] by one of my favourite authors. This is not to discourage the clean out and re-architecture of Pharo which is overall a good thing, but just to consider the downside and risk as a counter-point. Certainly Pharo is more evolving than starting from scratch... And then I got sucked into reading another (perhaps offtopic) article "Painless Functional Specifications" [2] that some may find interesting [1] http://www.joelonsoftware.com/articles/fog0000000069.html [2] http://www.joelonsoftware.com/articles/fog0000000036.html
On 3 January 2012 15:21, Ben Coman <btc@openinworld.com> wrote:
I am reminded of an article "Things You Should Never Do" [1] by one of my favourite authors. Â This is not to discourage the clean out and re-architecture of Pharo which is overall a good thing, but just to consider the downside and risk as a counter-point. Certainly Pharo is more evolving than starting from scratch... And then I got sucked into reading another (perhaps offtopic) article "Painless Functional Specifications" [2] that some may find interesting
[1] http://www.joelonsoftware.com/articles/fog0000000069.html [2] http://www.joelonsoftware.com/articles/fog0000000036.html
yes, a new is not necessary better than old. And if you ask me, i never throw away stuff, just because it is 'old'. if its in good condition and still can be used, why we should throw it away? To my experience, all code we thrown away in Pharo (where i participated) were because it is no longer used or was replaced with better , cleaner, simpler , more robust implementation. -- Best regards, Igor Stasenko.
On 03.01.2012 15:44, Igor Stasenko wrote: > On 3 January 2012 15:21, Ben Coman<btc@openinworld.com> wrote: >> I am reminded of an article "Things You Should Never Do" [1] by one of my >> favourite authors. This is not to discourage the clean out and >> re-architecture of Pharo which is overall a good thing, but just to consider >> the downside and risk as a counter-point. Certainly Pharo is more evolving >> than starting from scratch... >> And then I got sucked into reading another (perhaps offtopic) article >> "Painless Functional Specifications" [2] that some may find interesting >> >> [1] http://www.joelonsoftware.com/articles/fog0000000069.html >> [2] http://www.joelonsoftware.com/articles/fog0000000036.html >> >> > yes, a new is not necessary better than old. In the case of - Announcements vs Events, - FileSystem vs. FileDirectory&Friends - Opal vs. current Compiler I would say there's a strong case for considering the new alternative "better". > And if you ask me, i never throw away stuff, just because it is 'old'. > if its in good condition and still can be used, > why we should throw it away? > Why should be throw the old ones away you ask? We shouldn't. We should, however: a) Migrate code in core to use new systems. b) Repackage old systems to be unloadable/reloadable for external projects who still rely on them. c) Remove them from core, leaving one choice by default for building code using such systems, reducing confusion. d) Introduce namespaces, so folks who don't like the versions of those systems existing in core capable of loading alternate versions without a massive renaming effort. As for the question, what belongs in a Core image? Well, I for one would like compiler/decompiler in there. I'd also like an easily modifiable/understandable one. Haven't really read the current one, nor Opal enough to have an educated opinion on which is "better" in those regards, but others seem to. If that Compiler requires an AST, yes, it should be in Core. I'd also like the ability to write a sources file, but decoupled from the presence of a Compiler in a way which make me able to unload it if I don't need it. (say, for a minimal image) Doing so in a clean way sort of requires an event-system, my choice for that would be Announcements. It also requires interacting with the file system. So I'd like a system doing that in Core as well. A graphical framework? Sure. Tools written in the GUI to modify/inspect the system from within the image? Absolutely. Refactoring? While I like it, I don't think it's important enough to necessarily include in a "Core" image. (Full image? Absolutely) Syntax highlighting? Same as refactoring. As for dealing with systems also existing as external packages, in addition to d) above, I 100% agree with Nortbert's mail. I don't see why one could not work out solutions for synching with external repositories in addition to the Pharo-specific one, and/or introduce extensions used in Pharo as just that, extensions. Cheers, Henry IOW; A bit late perhaps, but I don't think the merge of Full and Core was a good thing, and would rather if the image builder took care of such tasks... As long as the packages are "pure" in the sense they contain no overrides, there is no reason one could not work on/commit fixes to the Core parts of the system from a "Full" image if one felt the tools/functionality included in Full are worth it.
This is the story where we can all have fun. :) http://www.dailymotion.com/video/xl28zi_monster-hunter-4-3ds-trailer-nintend... kind of cliffhanger :) http://www.dailymotion.com/video/x338j_monster-hunter-1_videogames But to kill that dragons better be more than one :) Stef (my sons loved totally to play together on this game).
Lukas if you want you can improve the OB tutorial that we wrote and that was for PBE2 book. Now publishing an obsolete chapter is useless and I do not have the knowledge to change it. So if you want just ask us. Do not modify the one on git because the current version is on svn but we can add you on our server in less than a minute. Stef On Jan 1, 2012, at 11:07 PM, Lukas Renggli wrote:
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.
Hi Stef, We are in the new year now, so the arguments can begin :). On 31 Dec 2011, at 23:33, Stéphane Ducasse wrote:
I looked at it and
First, these seem to be a totally different set of arguments :). That is good.
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.
and the scripting aspects Veronica showed me that she does not use long scripts.
I do not understand. You do not have to use long scripts unless you want them. If you look in the current code of most browsers, you will see that most methods are pretty small. So, this is not really an argument, either.
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.
Now if people want to load glamour perfect. Now I do not have any spare cycles to maintain it. My plate is full.
I do not understand. You do not have to maintain it. It is already maintained.
For now I would like to have a good way to build and reuse Morphic widgets not to create another layer on top.
Sure. Go ahead. This is most welcome. 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. Doru
Stef
On Dec 31, 2011, at 5:13 PM, Tudor Girba wrote:
Hi,
Let's take this on the Pharo mailing list.
I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte).
And I also think your analysis is not accurate. Here is why (I apologize for the long list):
1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more.
2. It is quite well tested. This part can be improved, but the core has some 80% coverage.
3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult.
4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes.
5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too.
6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes.
7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too.
I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now.
So, before dismissing Glamour, perhaps it would be useful to actually look into it.
Cheers, Doru
On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote:
Hi Stef,
You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo.
Do you think so? I do not think that we can base our infrastructure on something that only one person understand and can modify. You will tell that this is the same for Morphic but this is not true.
Stef
-- www.tudorgirba.com
"Beauty is where we see it."
-- www.tudorgirba.com "Every thing should have the right to be different."
On Jan 1, 2012, at 1:24 AM, Tudor Girba wrote:
Hi Stef,
We are in the new year now, so the arguments can begin :).
Sure ;)
First, these seem to be a totally different set of arguments :). That is good.
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.
and the scripting aspects Veronica showed me that she does not use long scripts.
I do not understand. You do not have to use long scripts unless you want them. If you look in the current code of most browsers, you will see that most methods are pretty small. So, this is not really an argument, either.
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.
Now if people want to load glamour perfect. Now I do not have any spare cycles to maintain it. My plate is full.
I do not understand. You do not have to maintain it. It is already maintained.
Well, when we integrate something we have to take care. You know oops we changed this wonderful method that nobody use except you :). And suddenly Pharo is bad because it changes :). So it means more code to look atâ¦
For now I would like to have a good way to build and reuse Morphic widgets not to create another layer on top.
Sure. Go ahead. This is most welcome.
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. Stef
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?"
except that it changes the perception of blocks arguments and usage.
I do not understand.
you see the not this argument because the first should be xzk
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?
what is not clear to me is: when I code oo I get messages and each method is a potential hook for extension when I code component (because GL is that a component model) the ports are the extension points. How such extension points works in presence of subclassing. Then how the methods (because GL is coding in OO) which are the de facto hooks interact with the ports one.
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 :).
You know that I always say that. I even ask veronica to participate to the glamour chapter because I want more. But this is on another level. and I still have my doubts about glamour :) I think that building models and code that does not rely on glamour is the best way to make sure that it can work in both world.
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?
Yes
Cheers, Doru
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
participants (9)
-
Ben Coman -
Esteban Lorenzano -
Guido Stepken -
Henrik Sperre Johansen -
Igor Stasenko -
Lukas Renggli -
Stefan Marr -
Stéphane Ducasse -
Tudor Girba