- Pharo-dev - lists.pharo.org

Re: [Pharo-project] OldSocket removal

by Damien Cassou

On Wed, Oct 22, 2008 at 6:43 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > On Tue, Oct 21, 2008 at 4:17 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: >> While playing with the OldSocket class>>clientServerTestUDP method I >> found out that a call to Socket>>discardReceivedData is blocking and >> this is not what happened with OldSocket>>discardReceivedData. An >> extra test for available data is missing. > > I have a very small fix and test for the error mentioned above. > Is it OK to upload new versions of Network and NetworkTests to PharoInbox ? Yes, please. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 22, 2008

Re: [Pharo-project] OldSocket removal

by Dan Corneanu

On Tue, Oct 21, 2008 at 4:17 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > While playing with the OldSocket class>>clientServerTestUDP method I > found out that a call to Socket>>discardReceivedData is blocking and > this is not what happened with OldSocket>>discardReceivedData. An > extra test for available data is missing. I have a very small fix and test for the error mentioned above. Is it OK to upload new versions of Network and NetworkTests to PharoInbox ?

Oct. 22, 2008

Re: [Pharo-project] Merging one-click and pharo-dev

by John M McIntosh

Actually resource forks have deprecated into non-existence in Squeak. ' The real problem is retaining the execution bit on the executables, if your file system doesn't respect that then you end up with a binary which won't execute on unix (aka mac) machines. However if you are using linux then you should be fine, the Squeak.app is just a folder with a bunch of files/folders. On Oct 22, 2008, at 12:33 AM, Lukas Renggli wrote: >>> Then, you can embed the latest one into a One-Click that >>> you generate (it seems I can't generate them myself because I don't >>> use MacOS, but I'm not sure). >> >> Don't know if you need macos, could be. (never tried it on linux). >> In general it would be nice to be able to build the one-click >> programmatically. > > If you want it working on a mac you need to make it on OS X, otherwise > the resource forks are missing. Maybe there are some unix tools that > could compensate that? > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Lukas Renggli

>> "Icons that show different concepts (and calling >> super and overriding a method are entirely different concepts, as well >> as putting a breakpoint or deprecating a method) and that hide each >> other are evil." > > Absolutely agree, hence that design. And in any case calling super is a > stupid indicator, especially when you know that it doesn't check that the > super call is a) to the same method or b) on every call path. The indicator > actually means 'might call some method declared in a superclass', which of > course you can easily do by calling a method that isn't overridden in the > declaring class, so what the hell use is that? Thank you for expressing it that clearly ;-) > OB is a good prototype, although IMO I disagree. I exclusively use OB in productive development on a daily bases for over 2 years now. > b) shouldn't include any action abstraction because that's best > handled in a completely different and system-wide fashion; I disagree. OB provides this system-wide abstraction. It is the fault of the other tools that don't use these abstractions. For example, I've written a process browser, debugger, inspector and several other tools in OB and they all benefit from the commands that already exist and that other people write as extensions (e.g. open a hierarchy browser from within the debugger). I agree that the abstraction is not optimal in all cases (e.g. text commands, applicability tests, ...), but it is definitely better than anything else I've seen so far. > different and system-wide fashion; c) is too messily tied to Morphic, with a > number of hacks; and relatedly, d) shouldn't extend existing Morphic > controls (such as lists) because they come with too much baggage (i.e. being > all things to all people). Earlier versions of OB were entirely separated from Morphic. Unfortunately it was tied to morphic over time as more and more people joined the development. I guess this happend due to laziness and lack of documentation and knowledge. Along the same lines: Every line of the model and view used to be tested with in-depth SUnit-Tests. Unfortunately that is not the case anymore either. People add features without writing tests. This is what happens, when an appealing and widely adapted projects entirely lacks a form of leadership. At some point there was an AJAX based web view and a XUL interface. I think somebody even made GTK view. Earlier versions of OB run in GemStone, with the view running in Squeak Morphic. There is an ongoing port for GST. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by David Roethlisberger

Hi Antony, > The screenshot I posted was OB, and I have arbitrary space. I very much like what I see in this screenshot. ;) Any possibility to see how you do this browser? > You just > need to address a particular OB flaw - the use of Text as the > abstraction (?!) for an annotated presentation item that is subsequently > rendered into a list. Could you elaborate on that? I don't quite get this. How is the fact that we use text (or string) to represent labels of items to be rendered in lists related to the space usage in these lists due to icons? This annotated text is just one representation of the item, the icon is another one (kind of). So how could help us another abstraction here? although to fix OB cleanly results in significant > breaking change, because while OB is a great prototype, like many things > in Squeak, the prototype wasn't respected as such as has been used quite > extensively. IMHO. Very true. David

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 22/10/2008, at 11:37 PM, David Roethlisberger wrote: > But in the columns of OB we don't have enough space to also add > meaningful decorations to icons. The screenshot I posted was OB, and I have arbitrary space. You just need to address a particular OB flaw - the use of Text as the abstraction (?!) for an annotated presentation item that is subsequently rendered into a list. A better abstraction should be preserved from node -> filters -> list, and manifested (relative to the UI domain) only in the list renderer. I've found that to be a worthwhile OB improvement (one of many), although to fix OB cleanly results in significant breaking change, because while OB is a great prototype, like many things in Squeak, the prototype wasn't respected as such as has been used quite extensively. IMHO. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by David Roethlisberger

> For icons: why not reuse some of the Eclipse icons. As far as I know they are free to use > and some developers might be familiar with them [1]. The problem discussed in this thread is kind of independent of the set of icons we use. Even with perfect icons the problem Lukas mentioned exists. The idea of the preference settings for icons is more to enable/disable the denotation of certain kind of facts (super send, sub-impl., whatever) by icons, not what concrete icon to use for what fact. This should really be fixed I think, otherwise it gets too complex. Or if people really want to use their own icons, they can always go and change those we provide. anyway, I don't particularly like the Eclipse icon set. It's nice for Eclipse, but it doesn't fit well to Squeak/Pharo IMO. I think that we should just have a very small amount of meaningful icons that are well done so that developers get used to them quickly. Most icons of Eclipse I really can't interpret, we don't want that to happen in Pharo. I will meet a designer tomorrow who might draw some cool icons for those facts we already have icons integrated, and that should do it. I think. > Would also be good to work with small overlays/decorators as Eclipse does [2]. In general yes. But in the columns of OB we don't have enough space to also add meaningful decorations to icons. Cheers, David

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by David Roethlisberger

> Wouldn't be enough for deprecated methods to just use a strikethrough > font style? Perfect. David

Oct. 22, 2008

[Pharo-project] OB annotation icons

by Torsten Bergmann

>use a strikethrough font style? +1 For icons: why not reuse some of the Eclipse icons. As far as I know they are free to use and some developers might be familiar with them [1]. Would also be good to work with small overlays/decorators as Eclipse does [2]. Bye Torsten [1] http://www.nur-scheuer.de/archives/243-Eclipse-Icons.html [2] http://www.eclipse.org/articles/Article-Decorators/decorators.html -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Lukas Renggli

On Wed, Oct 22, 2008 at 1:34 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > Wouldn't be enough for deprecated methods to just use a strikethrough > font style? +1 Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 22, 2008