Squeak-dev March 2003

squeak-dev@lists.squeakfoundation.org

202 participants
818 discussions

Re: Ideas, Experiences required for changes managements
by Daniel Vainsencher 31 Mar '03

31 Mar '03

DVS is also capable of handling class extensions. It doesn't raise an exception on overriding/changing stuff, which would be a a good addition, making it easier to have policies about that. What do I mean policy? a package should almost never override anything. Having code in your package that overrides code in your prerequisites can cause unexpected behavior for users that want to use/modify stuff other than your package (meaning - everybody but yourself ;-). Daniel "John W. Sarkela" <sarkela(a)sbcglobal.net> wrote: > The deeper issue is that Class structure is typically an organization > scheme that is orthogonal to a functional/utilitarian scheme. > > From a usage/loading point of view, one wishes to manage source > code based on the function points that it introduces into the system, > rather than *all* of the class structure of *all* of the affected > classes. > > For example, a well defined framework will commonly extend > the behavior of base classes like Object or Collection. > Thus, for the purposes of managing functional chunks of > code, one almost certainly needs to store and access code > based upon a functional capability point of view, rather than > a runtime hierarchical structure point of view. > > It was for these reasons that SWT used build scripts to load > functional elements of the image and used the ginsu module > mechanism to handle modules that could contain "loose methods" > that extended the behavior of existing classes. It further > ensured that each definitional element of code was uniquely > defined in the image. This is required to avoid problems of > one module "stepping on" definitions from previously loaded > modules. > > Cheers, > > :-}> John Sarkela > > On Monday, March 31, 2003, at 07:26 AM, jennyw wrote: > > > On Mon, Mar 31, 2003 at 09:30:49AM +0100, goran.hultgren(a)bluefish.se > > wrote: > >> Yep. Well, Squeak doesn't "play" that well with filebased source > >> management tools. > >> In Squeak we now have DVS which essentially is a "smart" > >> file-in/file-out mechanism which makes it at least practical to use > >> CVS > >> or any other filebased source management tool - but it is still not a > >> perfect fit and will probably never be. > > > > This isn't so much a suggestion as a potentially dumb question, but ... > > > > If there was an option to filed-out in a directory structure instead of > > a single file, such as: > > > > category/classname/classdef > > category/classname/methodcategory/method1 > > category/classname/methodcategory/method2 > > etc. > > > > And filed-in in the same manner, wouldn't source control systems be > > able > > to handle that better? I know this probably wouldn't work well in CVS > > (since it doesn't support renames), but with Subversion (successor to > > CVS), BitKeeper, or a number of more recent CMS systems, it might work > > better. Or not? > > > > Jen > >

3 2

[BUG] browse MessageTally with balloonHelpInMessageLists
by Martin Drautzburg 31 Mar '03

31 Mar '03

Start/browse MessageTally from the debug entry in the world menu has a problem when balloonHelpForMessageLists is enabled in Preferences. Select the menu entry Start/browse MessageTally and move the mouse to the top of the screan to pop up the Time Profile. When the mouse moves over the second line of the Time Profile (an empty line) it throws up the debugger saying "this collection is empty".

1 0

[Q] a couple of questions related to look enhancements
by diegogomezdeck＠consultar.com 31 Mar '03

31 Mar '03

Hi guys... I plan to continue with the look enhancements work. See the current state at: http://minnow.cc.gatech.edu/squeak/3142 I have a couple of questions: - Which is the feeling of the community about the new set of changes? - Do you consider these changes an [ENH] to the base image or an external package? - Do you prefer one package with all the changes (right now: menus, scrollbars and system window's icons) or several different packages? There are a set of design-decisions to take base on the answers to these questions. TIA, Diego Gomez Deck

8 11

Re: Ideas, Experiences required for changes managements
by Daniel Vainsencher 31 Mar '03

31 Mar '03

Hmm, if the default action is to proceed, this would be completely compatible with the way things work today, while allowing new UIs to customize the response (ask the user, roll back, do it anyway, check a preference...) Daniel "John W. Sarkela" <sarkela(a)sbcglobal.net> wrote: > Exactly the point. Perhaps DVS could in the future signal a > Notification upon redefinition. That way redefinitions could > be easily loaded (with notifications of redefinitions that are > typically ignored) but that allows a more careful loader policy > to intercept the notification, preferably prior to changing the > state of the image. > > I suppose my point is that the flavor of Exception that should > drive the policy is more like a Notification than an Error. > > John > > On Monday, March 31, 2003, at 09:52 AM, Daniel Vainsencher wrote: > > > DVS is also capable of handling class extensions. > > > > It doesn't raise an exception on overriding/changing stuff, which would > > be a a good addition, making it easier to have policies about that. > > > > What do I mean policy? a package should almost never override anything. > > Having code in your package that overrides code in your prerequisites > > can cause unexpected behavior for users that want to use/modify stuff > > other than your package (meaning - everybody but yourself ;-). > > > > Daniel > > > > "John W. Sarkela" <sarkela(a)sbcglobal.net> wrote: > >> The deeper issue is that Class structure is typically an organization > >> scheme that is orthogonal to a functional/utilitarian scheme. > >> > >> From a usage/loading point of view, one wishes to manage source > >> code based on the function points that it introduces into the system, > >> rather than *all* of the class structure of *all* of the affected > >> classes. > >> > >> For example, a well defined framework will commonly extend > >> the behavior of base classes like Object or Collection. > >> Thus, for the purposes of managing functional chunks of > >> code, one almost certainly needs to store and access code > >> based upon a functional capability point of view, rather than > >> a runtime hierarchical structure point of view. > >> > >> It was for these reasons that SWT used build scripts to load > >> functional elements of the image and used the ginsu module > >> mechanism to handle modules that could contain "loose methods" > >> that extended the behavior of existing classes. It further > >> ensured that each definitional element of code was uniquely > >> defined in the image. This is required to avoid problems of > >> one module "stepping on" definitions from previously loaded > >> modules. > >> > >> Cheers, > >> > >> :-}> John Sarkela > >> > >> On Monday, March 31, 2003, at 07:26 AM, jennyw wrote: > >> > >>> On Mon, Mar 31, 2003 at 09:30:49AM +0100, goran.hultgren(a)bluefish.se > >>> wrote: > >>>> Yep. Well, Squeak doesn't "play" that well with filebased source > >>>> management tools. > >>>> In Squeak we now have DVS which essentially is a "smart" > >>>> file-in/file-out mechanism which makes it at least practical to use > >>>> CVS > >>>> or any other filebased source management tool - but it is still not > >>>> a > >>>> perfect fit and will probably never be. > >>> > >>> This isn't so much a suggestion as a potentially dumb question, but > >>> ... > >>> > >>> If there was an option to filed-out in a directory structure instead > >>> of > >>> a single file, such as: > >>> > >>> category/classname/classdef > >>> category/classname/methodcategory/method1 > >>> category/classname/methodcategory/method2 > >>> etc. > >>> > >>> And filed-in in the same manner, wouldn't source control systems be > >>> able > >>> to handle that better? I know this probably wouldn't work well in > >>> CVS > >>> (since it doesn't support renames), but with Subversion (successor to > >>> CVS), BitKeeper, or a number of more recent CMS systems, it might > >>> work > >>> better. Or not? > >>> > >>> Jen > >>> > >

1 0

Building from source on RH 8.0...
by Jim.Gettys＠hp.com 31 Mar '03

31 Mar '03

Since the RPM's wouldn't install, I decided to try the fun of building from source. The resulting squeak won't run using the default GCC on rh8 (the first distribution that moved to gcc 3.2), but fail in a very obscure fashion (very obscure to someone like me new to squeak). Compiling with the 2.96 version also available on RH 8 does work, though it was obscure figuring out how to get it invoked in the right places. It would save large amounts of frustration to have some release notes noting both the install --nodeps of the RPM's and the compiler dependency. I suspect gcc 3.2 has a bug someplace that squeak tickles; not clear if it is worth more work as RH 9 is in the middle of hitting the streats, but release noting this stuff would be a big help to reduce friction of newbies to squeak. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys(a)hp.com

3 2

Re: Harvesting was: [Q] a couple of questions related to look enhancements
by Martin Wirblat 31 Mar '03

31 Mar '03

Hi Daniel, I knew you would enthusiastically disagree with 'murmuring of loadscripts' :) > A. Writing a load script is trivial. The script itself is trivial, but as I said you need to test it, meaning you have to run it AND test the resulting image. This is testing a release! If you have more than one loadscript it is something which is MORE work than testing a monolithic image release today. Have in mind here how many bugs, problems or not quite beautiful things are in the single image of today. There are not only packages depending on other packages, there are packages excluding each other, and this not only in a syntactically detectable way ( name clashes, class and method redefinitions ) but as I fear in many more subtle ways. E.g. programs produce data with data structures on disk, communicate with protocols, have semantics of their inst and class vars or have implications regarding the UI. You will not find such incompatibilities in an automated way. Something on top of assembled image A may not work on top of assembled image B or may hamper something in B, even if the dependency system gives green lights. These two points led me to the conclusion that it is best to keep the number of packages for the official releases as small as possible and the packages as big as possible. Of course it is a question of sensitiveness to find the optimal balance, but I really think that something like Diego's font-enhancement for the pref-panel is more a fix of something ugly - it should not be a package for loadscripts. This leads to Debian: Most modules of Debian are full blown applications or at least tools or libraries, they don't have minor tweaks and fixes which you can combine together to your personal system. The finer the granulation of modules, the more interface vs function there is, the bigger is the chance of problems. Debians module granulation is huge compared to the small SM-packages which I think about. > Just to make this factually crystal clear - the harvesters don't > harvest from SM. Exactly because not everyone puts his code on the right avenue this is a problem. regards Martin

1 0

[BUG] [FIX] DropFilesEvent-fix-dgd
by diegogomezdeck＠consultar.com 31 Mar '03

31 Mar '03

from preamble: Change Set: DropFilesEvent-fix-dgd Date: 31 March 2003 Author: Diego Gomez Deck <DiegoGomezDeck(a)ConsultAr.com> BUG: An error occurrs when a drag event is processes and the world has not a real color (example: an InfiniteForm). The method try to get the negated color and it fails. FIX: an #asColor message is send to "owner color"

1 0

SmaCC gui enhancements
by Alain Plantec 31 Mar '03

31 Mar '03

Hello all, here are some little SmaCC enhancements. remarks are wellcome alain plantec

2 1

Re: Harvesting was: [Q] a couple of questions related to look enhancements
by Daniel Vainsencher 31 Mar '03

31 Mar '03

Hi Martin. Martin Wirblat <sql.mawi(a)t-link.de> wrote: > Every good basic enhancement like these should eventually go into the > base image. Axiom I - for every changeset E someone considers an ENH, there exists someone else that considers it as more cruft. I agree Diego's stuff is very good looking, and might someday even end up as an alternative default look, or part of it, but A. Its not quite as clear cut as you think (see above). B. Since SM exists, there is no harm in letting ENH's mature there before inserting them into the image, where their maintainance becomes much heavier (since changes for it needs to be harvested). And lots of benefits... For example, while I view the keyboard control of hierarchial lists as very cool, and very useful (it makes using the explorer a completely different experience), I'm glad it's in SM now, and should get more use before we integrate it into the image. We need to do everything we can to make maintainance of the image go faster, including excluding as many things as possible from being in the image, exactly in order to make it's evolution faster. > To have thousands of > people sifting through SM and searching the 100 packages they need to > make Squeak what it could be is a colossal waste of resources. That is true. If you have good ideas for how to improve the UI/model/functionality, send them in, Goran listens very well. Ideas amounting to "the Harvesters should do something about this" are not very useful. > For those who are now inclined to murmur 'loadscript': To write and > test this loadscript is hard work. It is essentially the same work as > to integrate things directly into the base. To have a complete and > universal base is much more valuable than to have 1000 parts which > have to be assembled first. Ooooh - now here I gladly and enthusiastically disagree - we simply have a better solution. Point by point - A. Writing a load script is trivial. I've sent a generic one to the list a while ago. Using the SM API, it's a couple of lines of code. See the code SM uses to load SMLoader, for example. That's a load script. B. While *integrating* the load script with the released image is exactly the same kind of work as Harvesters would need to do, it has two major differences - 1. Anyone can do it, and his work will be just as well as effective as a Harvesters, since once on SM, anyone can use it. 2. The fact that you do it doesn't force other people to accept this package, so concensus is not required. C. Writing a load script is a way for you to create and distribute your own view of what the image should be like. If a lot of people come to agree, it paves the way to making the packages better, and if appropriate, part of the image. So in regard to your last sentence, 1000 parts aren't just an alternative to a whole, they're also the right way to get there. > The Squeak of the future should be made up of few big modules, and not > of a mess of fixes and enhancements. If you mean it shouldn't be that every user has to assemble his fixes and enhancements - I agree. If you mean things should be preloaded in the image, I beg to differ. Debian is IMO (and that of many people who've tried it), the easiest Linux distro to use and maintain, exactly because it is made of modular parts. > On SqueakMap are already some packages which fall into this category. > The harvesters do have to harvest on SqueakMap too! Just to make this factually crystal clear - the harvesters don't harvest from SM. Anyone is welcome to post [FIX]/[ENH] message that refer to SM packages. If you want us to treat this seriously, use QA tags. Daniel

2 1

Post-doctorate research position
by Serge Stinckwich 31 Mar '03

31 Mar '03

Hi all, i'm seeking a post-doctorate candidate to work in a french funded research project about modular robotics. The project is called MAAM (Molecule = Atom or Atom + Molecule) and the goal is to make atomic robots that have self-organizing facilities to aggregate. Look at the english presentation of the project available on my web page for more details: http://www.iutc3.unicaen.fr/serge/19 The candidate must possess a CS Phd degree and a good knowledge of the Smalltalk language. The salary is about 2150 euros/month for 18 months. I must send the proposition before the 23th april, 2003. Please get in touch with me if you are interessed. -- Serge Stinckwich -< ) multiagent.com Université de Caen>CNRS UMR 6072>GREYC>MAD /~\ squeak.org http://www.iutc3.unicaen.fr/serge/ (/ | zope.org Smalltalkers do: [:it | All with: Class, (And love: it)] _|_/ debian.org

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
82
Older →

Jump to page: