Omnibrowser in 1.4
Locked
123
123
 
|
On Aug 29, 2011, at 11:13 PM, Hernán Morales Durand wrote: > Hi Stef, > > I just want to know if OB will be supported in Pharo >= 1.4 even if > you don't maintain it, because I've spent energy and time learning the > framework, and I have written one developer guide for OB and I have > planned at least 5 more browsers. I did that too sadly. Alex and me wrote a complete chapter for Pharo by example 2. Now I do not invest in system that cannot handle multiple selection and trees. So good luck. For me trees are the basic minimum. Stef |
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> 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. |
|
|
In reply to this post by Lukas Renggli
On Aug 29, 2011, at 10:56 PM, Jorge Ressia wrote: > Hi guys, > > I am completely for inventing something new. > > However, I do not think this is the right model for doing so. > In a sense we are getting static, we put some tools in the image and > expect people to use them. > I think that this is going to be contra productive. > I believe that a much better model would be a dynamic one in which > people can load the tools that make them more productive. > Moreover, this model will force us, developers, to better target our > tools. Make clear which are their objectives, showing their benefits, > improve their design for understandability and extension and thus > getting feedback and interested people. At the end better tools will > emerge. > In a word, better products, with a "natural selection" process. > So we than just make "Pharo" an unusable download and expect the users to evaluate and pick their favorite browser from 3 to-be-loaded ones? Do you think this is realistic? -- Marcus Denker -- http://marcusdenker.de |
|
|
In reply to this post by Douglas Brebner
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 > |
|
|
In reply to this post by Lukas Renggli
On Aug 29, 2011, at 10:56 PM, Sven Van Caekenberghe wrote: > Lukas, > > On 29 Aug 2011, at 19:53, Lukas Renggli wrote: > >> I disagree; I would like a small and stable Pharo in which crazy ideas >> can be realized. For that I don't need fancy abstractions, but a >> minimal, simple and absolutely stable system in which I can load and >> do whatever I want. Maybe this is just me? > > I guess it all depends on your point of view. I can imagine that for you a clean minimal core is important as you build your own universe. But for most regular users, more stuff is needed. In practice, the core/dev difference was not optimal for all the reasons given before. I really feel crippled in a core image. And I don't like having to do long builds myself. > > I switched to 1.3, but I am using your one-click image because I need Seaside and there is no client build in Pharo any more. (Thx, BTW ;-) > -- Marcus Denker -- http://marcusdenker.de |
|
|
In reply to this post by Marcus Denker-4
>
>> Hi guys, >> >> I am completely for inventing something new. >> >> However, I do not think this is the right model for doing so. >> In a sense we are getting static, we put some tools in the image and >> expect people to use them. >> I think that this is going to be contra productive. >> I believe that a much better model would be a dynamic one in which >> people can load the tools that make them more productive. >> Moreover, this model will force us, developers, to better target our >> tools. Make clear which are their objectives, showing their benefits, >> improve their design for understandability and extension and thus >> getting feedback and interested people. At the end better tools will >> emerge. >> In a word, better products, with a "natural selection" process. >> > > So we than just make "Pharo" an unusable download and expect the > users to evaluate and pick their favorite browser from 3 to-be-loaded ones? > Do you think this is realistic? and not use one yourself or work day long with bad one..... common let us put our energy in something else. > > > > > -- > Marcus Denker -- http://marcusdenker.de > > |
|
|
In reply to this post by Igor Stasenko
On Aug 29, 2011, at 10:38 PM, Lukas Renggli wrote: >>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. >> >> No, i wouldn't say so. >> >> Most fixes and improvements are still about cleaning things out and fixing bugs. >> But not about new features. > > Yes, you are right. In fact Pharo 1.4 is roughly 1 MB smaller than Pharo 1.3. > 1.4 is smaller only(!) because we unloaded ScriptLoader13. And every MC commit makes the image bigger, as does every update. > Zinc is an excellent example, because it is fully backward compatible. > I don't see that with RPackage, SystemAnnouncements, Ring, Shout > (before Alan fixed it), with the proposed RB changes, ... > I do not want my live to be defined by being backward compatibe to what we have. Life is short. I mean that seriously: Should it be my life's goal to make a backward compatible system? I spend quite some time thinking about what to do with my future. Go to industry, have a real salary, and play with etoys the evening? Stay in research and write lots of papers with lots of greek letters that nobody reads? Or it there a third way possible? Maybe? But the idea of building a Smaltalk system whose only goal is to be compatbile to Squeak-minus-eToys I never even thought about ;-) >> > > Right, but you can easily force people not to follow. I don't > understand why all the people that still use Pharo 1.0 or 1.1 don't > speak up? > Are there a lot of 1.0 and 1.1 users left? They don't submit bug reports, for sure. Marcus -- Marcus Denker -- http://marcusdenker.de |
Re: Omnibrowser in 1.4
|
|
In reply to this post by Lukas Renggli
On 29.08.2011 14:32, Lukas Renggli wrote:
> On 29 August 2011 13:54, Alexandre Bergel <[hidden email]> wrote: >> Since there is ob, I personally use Nautilus. It provides interesting functionalities >> such as grouping packages and the hierarchies view (such as in vw). Importing >> things are missing however, including refactorings. > > Personally I wonder what the goal of Nautilus is? > > Nautilus looks to me like yet another Smalltalk-80 browser that works > exactly the same as all previous Smalltalk browsers in the last 32 > years (including OB). IMHO fixed lists, a text field and ugly buttons > do not cut it anymore. Did any Smalltalker ever work with XCode, > Eclipse, VisualStudio, ...? They are all inferior! Everybody body who has never used them or has used them at most for 5 seconds by clicking through the menus can confirm this. Because that was the state 15 years ago. Never mind that nobody actually uses RB because it's that bad. As long as nobody admits this our tools are prefect. Cheers Philippe |
|
|
In reply to this post by Igor Stasenko
On Tue, 30 Aug 2011, Igor Stasenko wrote:
> On 30 August 2011 02:58, Douglas Brebner <[hidden email]> 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)? - 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. 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. > > |
|
Administrator
|
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. 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
Cheers,
Sean |
|
|
In reply to this post by Stéphane Ducasse
2011/8/29 Stéphane Ducasse <[hidden email]>:
> > On Aug 29, 2011, at 11:13 PM, Hernán Morales Durand wrote: > >> Hi Stef, >> >> I just want to know if OB will be supported in Pharo >= 1.4 even if >> you don't maintain it, because I've spent energy and time learning the >> framework, and I have written one developer guide for OB and I have >> planned at least 5 more browsers. > > I did that too sadly. Alex and me wrote a complete chapter for Pharo by example 2. > Now I do not invest in system that cannot handle multiple selection and trees. > So good luck. For me trees are the basic minimum. > > Thanks. I read all your OB chapters/papers and they are very good. I will continue using OB, nothing against Nautilus or Glamour, except that as you already know I'm out of time for learning new ST frameworks and tools. I agree, trees are a must. Now, for OB supporters/maintainers (only Lukas?): - Is that hard to add trees to the column panes without rewriting everything? -- I replaced the "code pane" with an Explorer and ImageMorph in the MagmaBrowser, the code is in SqS for almost 2 years, see http://www.youtube.com/watch?v=VxUaOFRHFPk it is not the same as handling column interactions but it's a start. There is also a feature to paginate very large lists that nobody cared to mention or even steal. -- IIRC O2 could manage trees at some point right? - The same for multiple selections (I've implemented in the old Squeak classic system browser), is the problem understanding OB or is too difficult to modify or both? - Anyone willing to collaborate or review the OB article I wrote can contact me anytime. Hernán |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |