Re: [Pharo-project] Omnibrowser in 1.4
On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
No, it is complex and it is getting bigger with every release.
Do you think the Pharo we have is good enough to have a future?
No, there is a lot to be improved. I think the future of Pharo is what can be built on top, not what can be integrated and forced upon everybody.
So? Maybe we should just stop and do something else. Marcus -- Marcus Denker -- http://marcusdenker.de
On Aug 29, 2011, at 8:55 PM, Marcus Denker wrote:
On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
No, it is complex and it is getting bigger with every release.
The size of the image is Monticello Meta Data and ScriptLoader. Just doing deleting the Monticello History, remove ScriptLoader and do a Smalltalk cleanUp: true, and we are at 9.2MB Image size with tests. This is not that bad. Marcus -- Marcus Denker -- http://marcusdenker.de
Hi, On 29 Aug 2011, at 21:03, Marcus Denker wrote:
On Aug 29, 2011, at 8:55 PM, Marcus Denker wrote:
On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
No, it is complex and it is getting bigger with every release.
The size of the image is Monticello Meta Data and ScriptLoader.
Just doing deleting the Monticello History, remove ScriptLoader and do a Smalltalk cleanUp: true, and we are at 9.2MB Image size with tests.
This is not that bad.
I really do not understand where this feeling of bloating comes from. Perhaps it is from the fact that for a transitional period, we will have a couple of systems in parallel. But, this is necessary to move things forward and to have a smooth transition: - The Announcements will replace SystemNotifier which is a hack - The RPackage will replace PackageInfo which is a hack - To remove PackageInfo and friends, we need to get the tools to work with RPackage - I did not have enough time to take a closer look at Ring, but from what I understood it does not add much code but it should provide a nice layer for unifying several abstractions that were used for tools - The old browser is a hack, so Nautilus should be a minimal implementation of a new browser that works with the RPackage. Now, I am not sure if Nautilus did manage to be minimal, but it would be a good goal and in the end it will result in a reduced code base. - Shout can probably be debated, but for the little code that is added, it is not - RB should be in the image because it is essential for people that want to code (and the developers that maintain the image do want that) I find these to be the right decisions. Having Core + Dev did not make sense because people that maintain Core, did not have the tools. Unifying the two with minimal overhead (and it is minimal in my view) is the right way to go. Besides, stressing the creation of a PharoMini will make sure things are modular. Cheers, Doru
Marcus
-- Marcus Denker -- http://marcusdenker.de
-- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
I really do not understand where this feeling of bloating comes from. Perhaps it is from the fact that for a transitional period, we will have a couple of systems in parallel. But, this is necessary to move things forward and to have a smooth transition: - The Announcements will replace SystemNotifier which is a hack - The RPackage will replace PackageInfo which is a hack - To remove PackageInfo and friends, we need to get the tools to work with RPackage - I did not have enough time to take a closer look at Ring, but from what I understood it does not add much code but it should provide a nice layer for unifying several abstractions that were used for tools - The old browser is a hack, so Nautilus should be a minimal implementation of a new browser that works with the RPackage. Now, I am not sure if Nautilus did manage to be minimal, but it would be a good goal and in the end it will result in a reduced code base. - Shout can probably be debated, but for the little code that is added, it is not - RB should be in the image because it is essential for people that want to code (and the developers that maintain the image do want that)
I find these to be the right decisions. Having Core + Dev did not make sense because people that maintain Core, did not have the tools. Unifying the two with minimal overhead (and it is minimal in my view) is the right way to go.
Besides, stressing the creation of a PharoMini will make sure things are modular.
Thanks This is why we were working on a bootstrap, not just for fun. And yes our goal is to have a nice layered system with decent abstraction and not spaghetti code. For me stable means that we can build something without having to reimplement everything because everything is so brittle that each time we change something simple all the system shake. Stef
Is the current system simple and minimal?
No, it is complex and it is getting bigger with every release.
Do you think the Pharo we have is good enough to have a future?
No, there is a lot to be improved. I think the future of Pharo is what can be built on top, not what can be integrated and forced upon everybody.
So? Maybe we should just stop and do something else.
No and yes. No, don't stop: The cleanup process in Squeak 3.9, Pharo 1.0 and Pharo 1.1 was awesome. The system got smaller and more stable with every release. Yes, do something else. Be your own customer. Where is the next Reflectivity? Lukas -- Lukas Renggli www.lukas-renggli.ch
Is the current system simple and minimal?
No, it is complex and it is getting bigger with every release.
Do you think the Pharo we have is good enough to have a future?
No, there is a lot to be improved. I think the future of Pharo is what can be built on top, not what can be integrated and forced upon everybody.
So? Maybe we should just stop and do something else.
No and yes.
No, don't stop: The cleanup process in Squeak 3.9, Pharo 1.0 and Pharo 1.1 was awesome. The system got smaller and more stable with every release.
Yes, do something else. Be your own customer. Where is the next Reflectivity?
Do you think that we are not using Pharo? We are. And we got burned. When is the last time I was using a decent browser? I do not know. Why because I cannot wati 30 min that the tools get loaded in the integration image. Since I burn images like hell one every two minutes. So why did we start more than one year ago to work on a fast binary serializer? I let you guess. But the road is still long. Now just let me tell you that the state of the code definition was so awful (I mean really really really awful) that we burnt hours with johan brichau (far from an idiot), veronica and ben. Benjamin lost days because of this fucking state of the system to build a simple messageListbrowser. Why because a class comment is a method definition with the selector starting with C because the abstraction were wrong or inexistant, not class definition... So may be you do not like Ring and this is ok. Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. With the current state of the system this was simply impossible. I want to be able to browse senders in the past and compare them with the current version. Because we use prehistorical tools even if we could have something like torch to help us. I cannot see anymore SystemChangeNotifier (even if this was far better than without) PackageInfo, PackageOrganizer with lazy identification of packages so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there. I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. One AST. For example, did you check the size of Zinc, much larger than the previous crap. So? What conclusion should we draw? Fuel will have probably more classes than IS, DataStream, SmartRefStream but more tests.... And pluggable. So once we will achieved that then it will be ok. And again again again our goal is to have a modular system. At ESUG I was discussing with goran and other to see how we could have pluggable traits in the kernel (so that we can have a kernel without them). Now lukas it would be good that we all spend less time reading and writing these mails. Stef
On 29/08/2011 21:41, Stéphane Ducasse wrote:
So may be you do not like Ring and this is ok. Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. With the current state of the system this was simply impossible.
I want to be able to browse senders in the past and compare them with the current version. Because we use prehistorical tools even if we could have something like torch to help us.
I cannot see anymore SystemChangeNotifier (even if this was far better than without) PackageInfo, PackageOrganizer with lazy identification of packages so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there.
I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. One AST.
If I may make a metaphor, it sounds like rebuilding a house from the foundations on up while you're living in it. Things are bound to get unpleasant while it's happening, but it's still worth it in the end. :)
On 30 August 2011 02:58, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 29/08/2011 21:41, Stéphane Ducasse wrote:
So may be you do not like Ring and this is ok. Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. With the current state of the system this was simply impossible.
I want to be able to browse senders in the past and compare them with the current version. Because we use prehistorical tools even if we could have something like torch to help us.
I cannot see anymore SystemChangeNotifier (even if this was far better than without) PackageInfo, PackageOrganizer with lazy identification of packages so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there.
I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. One AST.
If I may make a metaphor, it sounds like rebuilding a house from the foundations on up while you're living in it. Things are bound to get unpleasant while it's happening, but it's still worth it in the end. :)
Yes.. I agree with Stef. Compatibility (including backward's one) is good to have when it worth it. But keeping compatibility with crap (okay, okay lets call it poorly designed software)? Why? Of course we can focus our energy somewhere else.. But then i think it will be not making Pharo, but more making things on top of it. Still there's a lot to do in Pharo. Maybe for Lukas it is unclear.. i'm not sure. But we are agree in one thing: we want to fix stuff even if its not broken , because the way it works is against laws of logic, software engineering, common sense etc.. And i can remind everyone: nobody forcing people to use latest stuff. I know that commercial applications are at least 1 year behind the current version. That's the way it works and not only for Pharo, but for most other software in the world. And there is nothing bad with it. Personally, if i would be involved in commercial project, i would just pick one version of image and stick with it to the death. Because often there's much more to care about inside a project itself (development, support etc), and you usually having deadlines.. so trying to cope up with latest and greates stuff at the same rate as it appears would be just silly and waste of energy. -- Best regards, Igor Stasenko AKA sig.
On Tue, 30 Aug 2011, Igor Stasenko wrote:
On 30 August 2011 02:58, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 29/08/2011 21:41, Stéphane Ducasse wrote:
So may be you do not like Ring and this is ok. Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. With the current state of the system this was simply impossible.
I want to be able to browse senders in the past and compare them with the current version. Because we use prehistorical tools even if we could have something like torch to help us.
I cannot see anymore SystemChangeNotifier (even if this was far better than without) PackageInfo, PackageOrganizer with lazy identification of packages so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there.
I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. One AST.
If I may make a metaphor, it sounds like rebuilding a house from the foundations on up while you're living in it. Things are bound to get unpleasant while it's happening, but it's still worth it in the end. :)
Yes..
I agree with Stef. Compatibility (including backward's one) is good to have when it worth it.
But keeping compatibility with crap (okay, okay lets call it poorly designed software)?
IMHO it doesn't matter if it's crap or not. What you should consider is: - how widely is the API used? - how easy is it to implement a (partially) backwards compatible API?
Why?
Of course we can focus our energy somewhere else.. But then i think it will be not making Pharo, but more making things on top of it. Still there's a lot to do in Pharo. Maybe for Lukas it is unclear.. i'm not sure. But we are agree in one thing: we want to fix stuff even if its not broken , because the way it works is against laws of logic, software engineering, common sense etc..
And i can remind everyone: nobody forcing people to use latest stuff. I know that commercial applications are at least 1 year behind the current version. That's the way it works and not only for Pharo, but for most other software in the world. And there is nothing bad with it.
Personally, if i would be involved in commercial project, i would just pick one version of image and stick with it to the death.
Unless you need the new features of the newer images. Levente
Because often there's much more to care about inside a project itself (development, support etc), and you usually having deadlines.. so trying to cope up with latest and greates stuff at the same rate as it appears would be just silly and waste of energy.
-- Best regards, Igor Stasenko AKA sig.
Levente Uzonyi-2 wrote:
IMHO it doesn't matter if it's crap or not. What you should consider is: - how widely is the API used?
While this is practical and a great way to prioritize, I ultimately want a system that is clean and beautiful down as close to the metal as possible. In the past, when I've dug deeper (Morphic, VM, etc.), I got smacked by ugly, hard to understand code and broken processes. Usually, just to figure out what the heck is going on I have to spend time refactoring and cleaning before I can do my work. And at ESUG, I got the same feedback. For instance, when Morphic came up, I realized that we all end up reimplementing from the ground up (custom text morph, layout hacks) because it's so brittle. I talked to people all over the world waiting with great ideas, because they were bitten by the ugliness in the depths of the code. Once the necessary pain is done, I think many will step up and produce amazing things, but not if the cleaning and restructuring stops. For me to be confident and productive, I need to know that wherever I go, even if it's not very often, I will be at home and empowered to bend the system to my ends. For me, the releases are like OS releases with a super-human pace, which I enjoy and appreciate. That having been said, I have projects still using 1.2, and spend a lot of time keeping outside projects up to date as I upgrade. If that's the price for the system we all dream of, so be it. Levente Uzonyi-2 wrote:
- how easy is it to implement a (partially) backwards compatible API?
In some cases, but how about file handling? "FileDirectory extensionFor: aDirectoryEntryFile name" vs. "anFSReference extension" Someone please cryogenically freeze me until the former is eradicated from the image. It hurts and offends me. My 2c, Sean -- View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3778260.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Aug 30, 2011, at 1:58 AM, Douglas Brebner wrote:
On 29/08/2011 21:41, Stéphane Ducasse wrote:
So may be you do not like Ring and this is ok. Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. With the current state of the system this was simply impossible.
I want to be able to browse senders in the past and compare them with the current version. Because we use prehistorical tools even if we could have something like torch to help us.
I cannot see anymore SystemChangeNotifier (even if this was far better than without) PackageInfo, PackageOrganizer with lazy identification of packages so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there.
I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. One AST.
If I may make a metaphor, it sounds like rebuilding a house from the foundations on up while you're living in it. Things are bound to get unpleasant while it's happening, but it's still worth it in the end. :)
:) Doing that for real here with three kids :) Stef
participants (8)
-
Douglas Brebner -
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
Marcus Denker -
Sean P. DeNigris -
Stéphane Ducasse -
Tudor Girba