August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>>> 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

Aug. 29, 2011

[Pharo-project] Pharo Future was: Re: Omnibrowser in 1.4

by Marcus Denker

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

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Sean P. DeNigris

Sean P. DeNigris wrote: > > p.s. guys, please start another thread. Many people may find this > interesting and it has nothing to do with the OP. > Or not. -- View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3777074.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Marcus Denker

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

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>>>>> No more for me. >>>> >>>> Introducing more code into Pharo that depends on more parts of Pharo >>>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it >>>> easier to maintain and change Pharo. Or did I misunderstand something >>>> about cohesion and coupling? :-) >>> >>> With that philosophy, we can just declare Pharo as finished and do something >>> else. >>> My point of view is that I invent new abstractions *and than use them* on and >>> for the system itself. >> >> 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? > > 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. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Sean P. DeNigris

Sean P. DeNigris wrote: > > Does anyone have OB working in 1.4? > Until we get things sorted out, I got OmniBrowser to load with only one small change, tested a change method name refactoring, and 1361 out of 1365 tests pass. 1. ConfigurationOfOmniBrowser project bleedingEdge load: 'Dev'. 2. File in http://forum.world.st/file/n3776989/OBPaneScroller-initializeScrollbar.st OBPaneScroller-initializeScrollbar.st Sean p.s. guys, please start another thread. Many people may find this interesting and it has nothing to do with the OP. -- View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3776989.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Marcus Denker

On Aug 29, 2011, at 7:54 PM, Lukas Renggli wrote: >>>> No more for me. >>> >>> Introducing more code into Pharo that depends on more parts of Pharo >>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it >>> easier to maintain and change Pharo. Or did I misunderstand something >>> about cohesion and coupling? :-) >> >> With that philosophy, we can just declare Pharo as finished and do something >> else. >> My point of view is that I invent new abstractions *and than use them* on and >> for the system itself. > > 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? > Is the current system simple and minimal? Do you think the Pharo we have is good enough to have a future? Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 29, 2011

Re: [Pharo-project] Pharo 1.4

by StÃ©phane Ducasse

On Aug 29, 2011, at 7:19 PM, Alexandre Bergel wrote: > RoelTyper is probably what should be interfaced with the automatic completion. it is. Stef > Other approaches are expensive. > > Alexandre > > > > On 28 Aug 2011, at 19:04, Frank Shearar wrote: > >> On 28 August 2011 21:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Damien Cassou wrote: >>>> >>>> >>> >>> Cool! That would make a big difference. Where are they/what are they called? >> >> I know of Roel Wuyts' RoelTyper >> (http://decomp.ulb.ac.be/roelwuyts/smalltalk/roeltyper/) and Lex >> Spoon's Chuck (http://www.lexspoon.org/ti/) Matt Might has also >> written about k-CFA (Control Flow Analysis) for inferring types in a >> dynamic language (Scheme, in particular) - >> http://matt.might.net/articles/implementation-of-kcfa-and-0cfa/ - >> which we might be able to apply to Smalltalk. >> >> frank >> >>> Sean >>> >>> -- >>> View this message in context: http://forum.world.st/Pharo-1-4-tp3759684p3774973.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>>> No more for me. >> >> Introducing more code into Pharo that depends on more parts of Pharo >> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it >> easier to maintain and change Pharo. Or did I misunderstand something >> about cohesion and coupling? :-) > > With that philosophy, we can just declare Pharo as finished and do something > else. > My point of view is that I invent new abstractions *and than use them* on and > for the system itself. 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? Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote: >>> 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, ...? >> >> Have a "basic" browser so that we can get rid of StringHolder. > > You could push down all the code of StringHolder into the subclass(es) > and remove the empty class. This can be done with RB with a few > clicks. I want to remove all the code of the hierarchy >> No more for me. > > Introducing more code into Pharo that depends on more parts of Pharo > (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it > easier to maintain and change Pharo. Or did I misunderstand something > about cohesion and coupling? :-) Why do you say that Ring = replacement for MethodComment, MethodReference, PseudoClass, PseudoMethod, ..... Pragma is compiler stuff Shout should be pluggable Announcement = replacement for SystemChangeNotifier RPackage = replacement for PackageInfo So I do not see the problem of coupling. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 29, 2011