October 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] changes file

by John M McIntosh

I note I downloaded the current pharo image/changes for pushing out on the iPhone and noticed the changes was 10.5MB, but if I condense it becomes 4.2MB which is much easier to deal with if I include it in an iPhone.app I'm wondering here if you need to push out the changes with all the method versions in it, or should it be condenced first and rely on changes from MC to show the history of how the methods evolved? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

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

by John M McIntosh

That is preserving any resource fork, and meta-data from hfs file attributes. Also so retains the hidden file that is used by the finder to format the folder view. It doesn't need to be present I believe in order for the re-zipped app to run, however I'd just keep it for now. After you replace the image/changes and other files, just rezip it all. On the mac unzipping it and the unarchive will do the right thing with the __MACOS__ files/folders On Oct 22, 2008, at 12:05 PM, Lukas Renggli wrote: >> However if you are using linux then you should be fine, the >> Squeak.app is >> just a folder with a bunch of files/folders. > > But there is a whole bunch of hidden files in these directories. I > guess these must be preserved? > > Also the ZIP archive contains a strange hidden __MACOS__ folder. > What is it for? > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

[Pharo-project] Returning something when debugging

by Damien Cassou

I've just discovered something today: when you are debugging you can always return from the current method by right-clicking on the stack frame and selecting 'return entered value'. You then get an input field where you can enter any expression and the result of that expression will be evaluated as the return value of the stack frame. -- 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] Merging one-click and pharo-dev

by Keith Hodges

Lukas Renggli wrote: >> However if you are using linux then you should be fine, the Squeak.app is >> just a folder with a bunch of files/folders. >> It would be good to have a SakeTask for generating one click images, that can be incorporated into Bob. Keith

Oct. 22, 2008

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

by Lukas Renggli

> However if you are using linux then you should be fine, the Squeak.app is > just a folder with a bunch of files/folders. But there is a whole bunch of hidden files in these directories. I guess these must be preserved? Also the ZIP archive contains a strange hidden __MACOS__ folder. What is it for? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 22, 2008

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

by Damien Cassou

On Wed, Oct 22, 2008 at 9:29 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > In general it would be nice to be able to build the one-click > programmatically. > There should be a "one-click" package-generator in the image. It should be easy in Bash, I can try. However, I don't know how it can be done in Squeak. Why do you need to do it in Squeak? -- 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 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