July 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] -> 10350
by StÃ©phane Ducasse July 2, 2009

July 2, 2009

integrated Issue 890: Mantis 6535: keyBlock and sortBlock are lost when creating a collection of the same species. Nicolas if you can check that I did not make mistakes this would be good. Stef

1 0

[Pharo-project] Inspector values do not update dynamically anymore
by Oscar Nierstrasz July 2, 2009

July 2, 2009

If I inspect a morph and focus on the bounds variable, then move the morph, the bounds do not update dynamically as they used to in Squeak. Is notification broken? - on

1 0

[Pharo-project] Pharo coding party
by Damien Cassou July 2, 2009

July 2, 2009

Damien P, StÃ©phane D and me are doing a Pharo coding party to kill some bugs. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

2 1

[Pharo-project] Fonts directory necessary in pharo-dev
by Simon Denier July 2, 2009

July 2, 2009

Hi I juste downloaded the latest pharo 10342 and I noticed that if I remove the Fonts folder, it does not look for DejaVu fonts already installed on my MacOs system. Instead I got crappy fonts. Is this a known bug? -- Simon

5 5

[Pharo-project] FasterSets
by StÃ©phane Ducasse July 2, 2009

July 2, 2009

I would really like to assess FasterSets for Pharo1.1 Begin forwarded message: > From: Ralph Boland <rpboland(a)gmail.com> > Date: June 25, 2009 8:30:13 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: about fasterTests > > 2009/6/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> we are interest to get better libraries in pharo. >> If you want to join and help making sure that your code in >> integrated in >> pharo1.1 >> please say it and may be join the pharo mailing-list. >> >> Stef >> > > Yes, I would like my code 'FasterSets' added to Pharo. > I joined the pharo mailing list. > Today I will mail you my MIT license release. > Probably will take a couple of weeks (From Calgary, Canada) to get > there. > Once I am added as a contributer I will release my code to Pharo for > verification. > In the meantime if any Squeakers try out my code and report bugs I > will fix them > before releasing to Pharo. > > Some comments: > > 1) Since FasterSets modifies low level methods in class Set and its > subclasses it > may be incompatible with packages that create subclasses of Set > and then > override low level methods. If someone could send me a list of > package add-ons > to Pharo that do this then I can download them and make any > modifications > necessary for them to run with FasterSets and make these changes > part of my > release. Note that it is no more difficult to subclass from Set > with FasterSets > than without; it is just different and only different if you do > low level things. > > 2) FasterSets uses a method 'noCompareOrGrowAdd:' which adds > an element to a set without doing compares or growing the set. > Needless to say it is a private method. > I also have a public method 'nastyAddNew:' which, like > 'noCompareOrGrowAdd:' adds an element to a set without checking > if the > element is already there but does do a grow if needed. > This is useful (i.e. faster) in situations where you KNOW the > object > you are adding to a set is not there already. > However if the object IS already there then you now have two > of them in your set; i.e. you now have a subtle bug. > I use 'nastyAddNew:' in my code but never made it a part of > FasterSets > because it is questionable whether or not such a method should be > available generally. However, if I can decide I like the > 'nastyAddNew:' > method and am willing to use it despite its risks so can others > so there > is an argument for it being added. > While my expectation is that you don't want 'nastyAddNew:' in > Pharo > I thought you should at least be aware of it. > > Regards, > > Ralph Boland

5 13

[Pharo-project] [ANN] 10345 and 10346 Arithmetic
by StÃ©phane Ducasse July 2, 2009

July 2, 2009

Hi all Here are some integrations: Fix and test http://bugs.squeak.org/view.php?id=3374 aka http://code.google.com/p/pharo/issues/detail?id=876 Thanks nicolas for your contributions to make the system better. Stef PS: making chicken steps the system better and more agile

1 0

[Pharo-project] why FileDirectory sucks
by StÃ©phane Ducasse July 2, 2009

July 2, 2009

Hi guys we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks. I have a file FileDirectory default and now I want to get two levels up. Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic. Smalltalk deserves a better library for file. What a crap this stuff. Stef

10 25

Re: [Pharo-project] [squeak-dev] Forks, forks, forks
by Igor Stasenko July 2, 2009

July 2, 2009

2009/7/2 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Thu, Jul 2, 2009 at 12:06 AM, Ralph Johnson <johnson(a)cs.uiuc.edu> wrote: >> >> The tendency to fork is a product of all Smalltalks, not just Squeak. > > as others have observed in the current spate of discussion the need to fork > can be minimised or avoided altogether by providing a small kernel image > that can load packages, and getting into the habit of writing one's > application as a set of packages and regularly building them up into an > image (nightly, weekly) starting from the kernel. > This approach also allows the VM and image representation to evolve (and > even fork!) because the kernel is amenable to transformation. Â So one can > create different forms of the kernel image with exactly the same apparent > image contents, but with object representations adapted for specific uses, > such as an extremely compact representation for embedded applications and a > simple one for performance and normal development, and one can have purely > interpreted VMs for hostile or memory-limited machines (iPhone does not > allow one to enable execution permission on mmap'ed memory) and JITs > forÂ performance and normal development. > IMO it is also easierÂ building up a kernel than carving it out of a > monolithic imageÂ to architect the necessary modularity support to allow > packages to be loaded that make major transformations such as adding a GUI > and replacing a standard i/o stack dump with an interactive debugger. > I hope that if such a beast becomes available that the community will make > the effort to port to it, which involves packaging their code, and we can > branch to our heart's content because images will be constructed not > constricting. Yes, and all Squeak forks could use such kernel as a base, except those who making own changes to VM. This is another reason for having a package-based development model. I remember we have discussed this before, but this idea & especially benefits which it could bring to us, were leaked from my mind :) P.S. can't resist CC-ing this to Pharo list. :) >> >> There is a company in town that developed a commercial product on >> VisualWorks 2.0. Â They customized it heavily. Â It is a sound >> generater, in fact the world's fastest synthesizer in which you can >> specify each waveform. Â It is used by musicians and for sound effects >> in movies. Â All the programming is done by two people. Â It provide a >> very nice UI in which you drag and drop sound objects to create your >> piece. Â When you say "play", the sound objects are converted into code >> for an array of DSPs, which execute the code to play the sounds. Â The >> process is nearly instantaneous. >> >> This company made a fork over ten years ago, and last I heard, had not >> caught up. Â They would like to run their software on Unix. Â It only >> runs on PC and Macs, and I think they have hacked the VM themselves to >> run on newer OSs. Â The binary, that is. Â But it was just too much >> trouble to convert their image, and didn't seem like it provided >> enough benefits. >> >> There are still a lot of companies running VSE applications in spite >> of the fact that it hasn't been supported for a decade. >> >> One of the great things about Smalltalk is that it is so open. Â You >> can change everything about it; the way the compiler works, the UI, >> the programming environment tools, what it means to send a message to >> an object that is not understood. Â You can change arrays, strings, >> booleans. Â Of course, if you do this then you are not longer >> compatible. Â If you hack Behavior and ClassDescription then the odds >> are that your hacks will not be compatible with other people's hacks. >> Every time a new version of the platform comes out, you'll have to go >> back and make sure none of your hacks are broken. Â Often they will be. >> >> Sometimes it is worth the pain. Â But often people just fork. Â They >> will lose all the nifty new features that come out, but it just isn't >> worth the trouble to keep up. >> >> I think the reason there is so much forking with Smalltalk is that >> application programmers don't have to depend on vendors. Â They can >> craft the environment to suit their own needs, and don't need to >> depend on someone who doesn't really understand their needs. Â There >> are disadvantages to forking, but it is easy and there are enough >> advantages that people will continue to do it. >> >> So, we need to learn to live in a world of forks. Â Seaside shows how >> it can be done. Â Squeak and VisualWorks, after all, are different >> forks from the original Xerox Smalltalk-80. >> >> -Ralph Johnson >> > > > > > -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] Squeak: A New Community Development Model
by Damien July 2, 2009

July 2, 2009

Sent to you by Damien via Google Reader: A New Community Development Model via The Squeak Oversight Board Blog by andreasraab on 7/1/09 In the board meeting today we had a nice discussion about how to move forward with a new community development model for Squeak. Here is an overview of the model and what will happen next: The goals The goal of this process is to get rid of as many hurdles as possible in the contribution process. We are trying to enable the community at large to improve Squeak, the core of the system and its supporting libraries. To do this, we are adopting processes that have been shown to work in commercial settings: The use of Monticello as the primary source code management system, free access for the developers to the main repositories, an incremental update process for both developers and users of Squeak. Repositories We will be setting up the following Monticello repositories: * http://source.squeak.org/trunk This will be the main repository for ongoing development. New code will be committed here, the repository will be world-readable and writable for the core-dev group. * http://source.squeak.org/tests This is the main repository for unit tests. It will be world-readable AND world-writable. We encourage everyone to write more tests and commit them, improve the existing tests and bring in entirely new test suites. * http://source.squeak.org/inbox This repository is intended as dropbox. Itâs usage will depend on what we make it out to be. The idea is to have it world-readable and world-writable, too. Developer access The board will manage developer access to the repositories at source.squeak.org. In the next days weâll send out a few âyou are pre-approvedâ messages to people who have proven to be active developers in the past in order to invite them to become a core developer. If you canât wait and absolutely want to be in on the action you can register yourself at http://source.squeak.org/ and send message to the board asking for access but most of the regular contributors (you know who you are) will be invited anyway. Rules of Engagement If you have used Monticello in projects with more than two developers in the past you already know the drill. If not, here are some useful guidelines: * Merge often. In particular when you pick up work and right before you intend to commit. * Exercise caution. This is a running system and breaking it needlessly is generally frowned upon. * Restrain yourself. Getting developer access doesnât mean you are free to put in every pet extension you always wanted to have without discussion. * If in doubt, ask. This is the corollary to the restrain yourself rule. Youâre not under pressure to ship a product, so you have the time to send a note saying âhey, Iâm planning to fix this old issue and it may have some side effect here or there. Anyone having a problem with that?â >>> Iâll add a Squeak-dev exception here: Any response from any non-developer can be entirely ignored in this context. * You break it, you fix it. If you change something you are generally expected to take care of the consequences, though there are some exceptions. If in doubt, ask * Do good and talk about it. When youâre done with whatever it is youâve been working on let people know about it. It can be as short as a note to Squeak-dev saying âhey, some of you might care that Iâve fixed the long standing bug with xyz. Update and enjoyâ I think that roughly covers it. Basically you will be working with a dozen (hopefully more) other developers on Squeak and weâll all have to learn how to make this work successfully. Updating We are in the process of developing an update process that can work seamlessly with Monticello. An early experiment is described here. We are evaluating alternative approaches, in particular the use of Installer since there are some shortcomings when using Monticello Configurations. Existing Work It is important to note that we will be trying very hard not to lose any work that is being done for Squeak 3.11. We will start with the package set that was used in the 3.10 release, then we will issue package updates to cover the missing delta up until 3.10.2. Following which we will reissue any changes done for 3.11 into the repositories. Things you can do from here: - Subscribe to The Squeak Oversight Board Blog using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites

1 0

July 2, 2009

> Hi, > > perhaps this is interesting for some people. We hope so. :-) > > I am glad to announce the availability, as of today, of two > Squeak-based projects that both deal with letting Squeak interface > with the surrounding world. > > > 1. PhidgetLab > > Phidgets are sensors and actuators that can be connected to a PC via > USB. So far, support for them in Squeak was not freely available - > this changes now. :-) A group of students in our group - Lysann > Kessler, Stephanie Platz, Thomas Klingbeil, Philipp Tessenow, and > Frank Schlegel - have developed PhidgetLab in fulfilment of a > coursework assignment. It provides a "low-level" Phidgets API in > Squeak, but is also integrated with Etoys. > > Behold: http://www.hpi.uni-potsdam.de/swa/projects/phidgetlab/ > > 2. NXTalk > > Over the past few years, we've made the occasional announcement of > this: it's Smalltalk on Lego Mindstorms NXT. It's a real Smalltalk VM > running on the NXT, with an image being interpreted. Now it's finally > available, including the VM source code. NXTalk is the outcome of > Martin Beck's MSc research; Martin is a former student in our group. > > Behold: http://www.hpi.uni-potsdam.de/swa/projects/nxtalk/ > > > Both projects' source code is MIT licensed. They both are based on > (L)GPLed software, though: PhidgetLab uses the Phidgets API from the > vendor, which is under the LGPL, and NXTalk uses NXOS, which is under > the GPL. > > We would be grateful for any suggestions for improvement - for both > the projects and the respective web pages alike. Experience reports > are, of course, most welcome too. Unfortunately, we cannot make the > required hardware available as easily as the software. ;-) > > > Please let us know what you think! > > > Best, > > Michael > > -- > > Robert Hirschfeld > Hasso-Plattner-Institut > hirschfeld(a)hpi.uni-potsdam.de > www.hpi.uni-potsdam.de/swa > _______________________________________________ > Etoys mailing list > Etoys(a)lists.laptop.org > http://lists.laptop.org/listinfo/etoys >

1 0