Squeak-dev February 2005

squeak-dev@lists.squeakfoundation.org

191 participants
430 discussions

XML Parser
by Daria Spescha 04 Mar '05

04 Mar '05

Hi! I'm using the Soap Stuff to call webservices and this uses the XMLDOMParser to parse the response. This works well normally. But as soon as there is a carriage return () somewhere in the response, the result returned by call invoke contained an error message: SAXParseException: XML expected. The parser doesn't seem to able to handle carriage returns although  is XML 1.0 compliant. What is wrong? Where would I have to change this? Thanks! Daria

4 4

Re: Modules
by Florin Mateoc 04 Mar '05

04 Mar '05

Hi, Dan, I would love to be part of your team. And I am interested in working on all the (not for long) future technologies. About modules and packages and other related code organization structures: I think I should start by mentioning the extent and limitations of what I consider my relevant (to this subject) experience: I have had extensive, as well as low-level experience with Envy, I have also built additional organizational structures and workflow tools on top of it, I have ported code from Envy to Store and I have worked with Store. I have also worked with several Java IDEs and SCMs. I have also worked on a creating a minimal VW image, an experiment similar to Craig's Spoon. And now, my view of the world, in (not so) short: What I like about VW parcels/packages: they encapsulate in a robust (from a loading perspective) form an independent piece of functionality. Very Smalltakish in the sense that they allow partial loading: if it contains methods of a class that is missing, no problem, the parcel holds unto the uninstalled methods, and when/if the missing class is loaded, it installs the methods. This could be extended even to missing superclasses, which would make them practically load-order independent. They also have the notion of (stackable) overrides, so if in your package you change a method from a different package, you can easily browse both the override and the overriden code, but most importantly you can safely unload your package and things are restored properly. One thing that you don't have with load-order independece is dependency information. Your parcel/package may load but you have no clue if it will run. Of course, one could manually check Undeclared, look for unimplemented but sent selectors, etc, but I think we could offer more tools support for dependecy management. Envy does not allow out-of order loads, and the applications' (Envy's packages) prerequisites information is enforced only for superclass-subclasses and class-extensions relationships (it does not allow you to subclass or extend in an application where to the original class is not visible (through an explicit dependency declaration)). IMHO dependency information is useful, but it should not stop your code-writing workflow, nor should it stop you from loading partially. A potential solution (for also having dependency information) would be to compute (as extensively as reasonably possible) and store the dependecies at freezing/versioning time. Since this is a best effort solution, I don't think this should require that packages that you are dependent on to be also frozen/versioned. Dependency information could be stored as "version x" if the dependency is a version, or "version x+" if it's been modified since the last time it was versioned (as x). The base image is obviously versioned as well. It is perhaps obvious by now that I consider versioning an important feature of any organizational structure. A version is a shareable, immutable snapshot, at a finer granularity than the whole image. For VW the granularity is the package, for Envy it is the class. If one ignores the explicit and named aspects of versioning, Envy's versioning granularity is actually at the method level. Each Envy method "edition" is an immutable, timestamped snapshot of the method. They are created automatically at each "accept", which is what makes them impractical for remote servers. This is the main argument in Store for their much coarser granularity (less chat), but I think this is the wrong approach: latency can be addressed for example with background processing, and frequency can be decreased by making method versioning a separate, explicit user action. I think that in general, the finer granularity the better. If one recognizes that not every accept deserves a method version (obviously one could not have tested a method at accept time) and each change is logged locally anyway, we can grant methods their own, named versions, which may be explicitely pushed to the respository, and which can later come very handy when browsing the history. All methods have to be versioned when the class (extension) is versioned, and this can be made automatically, just like classes have to be versioned when the package is versioned. In addition, the versions of methods that belong to a class version can be marked as special when browsing the method version history, just like class versions that belong to a package version can be marked specially. Sorry for the perhaps too low-level details, I just wanted to write things down. And Dan did ask us what we wanted to see in such a system :) Now, method versions are not interesting just for themselves. A different kind of code organization is a patch, or a unit of work which happens after the packaging structure has been defined, and is perhaps cross-cutting through many different packages. This is a changeset in a non-packaged, non-versioned, and limited-collaboration universe. In a versioned, packaged world, the changesets themselves should be versioned entities, and be composed of versioned sub-entities. It is especially for changesets that method-level versioning comes in handy, because here the finer, method-level granularity is needed. If you are forced to create new (entire) class versions for inclusion in a versioned patch, this not only adds noise, but it creates a much higher incidence of merging conflicts. As far as namespaces go, the problem to be solved seems much easier, and I think everybody agrees that a heavy-weight solution like in VW is inappropriate. I profoundly disliked in VW the fact that they namespaced the base image in a lot of small, meaningless namespaces (although there was no name conflict to be solved), just as a display of what could be done with them. I disliked the fact that namespaces were made into as first-class objects as classes, to my mind without the same conceptual justification. I also profoundly disliked that they now had both namespaces (for the rest of us) and namescopes (for the compiler) as two very similar (and with very similar responsibilities) class hierachies, but yet distinct. I think that the name lookup rules for the compiler should be the same as the ones for our code, and I think that the base image should contain no namespace other than Smalltalk. There is indeed potential for name conflicts when independently developed packages are put together in the same image. But if we are only trying to solve this issue, and we don't mix it with categorizations (which should be done by packges), I would think that a simple rule like "all external applications' classes and packages should live in their own (only one) external namespace" should be sufficient. This could easily happen automatically, with a prompt for an image-wide development namespace at the first class creation (like the initials prompt for the changeset). Each corporation would have their own namespace and they would do all of their development in it. And a few priviledged among us like Dan (and maintainers of what is accepted as part of the base) would always just type "Smalltalk", and that would be it :) About image construction versus image stripping, I think we should be able to do both. The image is a very powerful instrument for development and I want to keep using it. By using it I will necessarily dirty it, but I don't care as long as it is still a work in progress. When I think I am done, I want to be able to extract the application from the image, and I want tools to help me with that. Once extracted, applications can be used to build clean images. Please note that, while packages help with keeping things organized, they are not a solution for code rot, and a long-lived application will be touched by many hands, not all of them informed or competent or careful. There will always be a case for stripping. There is a case and a market for application extraction in Java, which does not have images at all, so stripping is not so much about the image itself. Building from scratch is useful, but it only eliminates unpackaged things, it does not deal with packaged dead code Cheers, Florin

10 29

UI design by committee
by Lex Spoon 03 Mar '05

03 Mar '05

I don't know if this has been posted before, but Matthew Thomas has posted a seering review of open-source UI designs which hits close to home for us. http://mpt.phrasewise.com/2002/04/13 What can we do to avoid the fate of Mozilla's UI? Do we need a UI tsar to avoid disaster? Or, is there a way to make entire UI's be swappable in and out, so that people can make up UI's in a decentralized way and thus let the market work it out? Here's a bit of flamage copied from the article: "As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it's much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing." This sounds exactly like us! Go read the whole thing; it's short and interesting. -Lex

13 25

Are bugs in older releases fixed in newer releases still bugs?
by Ken Causey 02 Mar '05

02 Mar '05

I'm among the group that is trying to work on improving the harvesting process. One of the issues that occur to me is how to handle an issue that is no longer an issue in the latest greatest update but is a problem in the last update of a released version. In other words let's say bug X is verifiable in a fully updated 3.7 image but has been fixed in an update for 3.9. Is this issue 'fixed'? Or does it need to be fixed in 3.7 to be truly fixed? I realize that to some extent it depends on the issue. But then who decides what needs fixing in a released version and what doesn't? Also at what point to a release become so old that no bug in that release is worth worrying about? Ken

3 2

[UPDATES] 3 more
by Michael Rueger 02 Mar '05

02 Mar '05

Hi all, just so you guys don't get bored ;-) Thanks for everybody pitching in! Michael ----------- "Change Set: filePathMethodRename Date: 24 February 2005 Author: Yoshiki Ohshima Rename systemPath to vmPath." "Change Set: FontSetFixes-di Date: 24 January 2005 Author: Dan Ingalls Recent changes to support extended character sets have made it no longer possible to fileOut code with arbitrary string literals and read them back in again without corruption. The fileOut / fileIn capability of FontSet depended on this ability and is consequently broken in release 3.8. This changeSet changes that mechanism to use MIME64 encoded literals which still work in the latest releases. It includes a method that will accept the new encodings, and it puts a useful comment in the method most likely to break if an attempt is made to read in one of the now-unreadable fileOuts. This code has been tested in 3.8, and it should work in old Squeaks back to when MIME encoding was introduced. It therefore not only fixes 3.8 in this regard, but it can be filed into old Squeaks to make them FontSet-compatible with 3.8 when fixed. " "Change Set: CategorizerFix Date: 25 February 2005 Author: Hans-Martin Mosner Fixes a bug with reading class organizations containing nil, true or false as message selectors. The cause of the bug: Recent Squeak versions changed parsing of literal vectors such that nil, true and false are not stored as Symbols but as the respective objects."

2 1

Where do I go for support for the Mantis database?
by Ken Causey 01 Mar '05

01 Mar '05

I had a question regarding the Mantis database so I first tried sending it to the email address listed at the bottom of every page in the system. No go, no such address available. So now I'm trying to remember who is managing the server. Andreas, Michael? Ken

3 3

SystemChangeNotification and Packages
by Alexandre Bergel 01 Mar '05

01 Mar '05

Hello! I was wondering what is the impact of adding packages on the system change notification mechanism. I added some events for creating a new package, renaming one, deleting move, moving one method from one packate to another, ... What about adding a new repository to a package? What about saving a package? Should events be triggered or not for such actions? This question rised to me since I dispay within a browser informations like the list of repository assigned to a package (cf picture attached to this email). I need to refresh the browser whenever new information are added. And for that, triggering events would resolve this issue... Comments are welcomed! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.iam.unibe.ch/~bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

[ANN] PackageInfo-Extras v10 available on SqueakMap and SqueakSource
by Ned Konz 01 Mar '05

01 Mar '05

I've just posted a new version of PackageInfo-Extras that merges the older version of this package with my PackagesVsCS and Göran's ChangeSetRefactoring. It adds a number of package-related operations to the ChangeSorter menus, and also adds filterable MessageLists. This requires PackageInfo-Base v18. It can be downloaded from your SqueakMap loader, or from either of: http://kilana.unibe.ch:8888/PackageInfoExtras/PackageInfo-Extras-nk.10.mcz http://bike-nomad.com/squeak/PackageInfo-Extras-nk.9.mcz Enjoy, -- Ned Konz http://bike-nomad.com/squeak/

2 1

the meaning of it all
by Olivier Vasseur 01 Mar '05

01 Mar '05

I was thinking of the meaning of life, the universe and everything, when suddenly� er , well, not really. I was actually working on the French translation for Squeak. Most of it has been done for some time, but there were some 300 phrases left to translate. I did most of it, but I can�t grasp the meaning of a handful of phrases. The language editor has been useful to trace phrases in methods and find out what they were about ( � peaks � is the name of a sound, � measure lines � belongs to the vocabulary of musical notation, and so on). But for some phrases I�m still stuck. I like playing around with Squeak, but I�m not a professional programmer, not even a good amateur (I�m a translator, actually) so I guess some of my questions will seem quite naive. I need to know what the following phrases refer to before translating them (I give the class and method when I have them): * Many many thanks to Yoshiki for the language editor, but� some phrases from the editor interface are not translated (they do not appear in the list of phrases to translate): � there are no methods with the string �,� there are no match for � * what does � Flex � refers to ? * what is � add pin �? :FunctionComponent addCustomMenuItems:hand : * what is � vertical pan � ? anything to do with vertical cooking ? :) (GradientFillMorph addCustomMenuItems:hand: ) * � passing color � and � blocking colour� (ScreeningMorph addCustomMenuItems:hand: ) * � end clip here � what is a �clip� in this context? (MoviePlayerMorph invokeBookMenu) * � get sound from lib � ( EnvelopeEditorMorph addCustomMenuItems:hand: ) Does �lib� stand for 'library' (and if it does, what is this sound library)? * � World scale and clip ��seems to be a menu, but I can�t find where it is and what it does. * � start keyboard navigation with this thread � (InternalThreadNavigationMorph moreCommands ) What is a � thread � in this context ? * � die � I just have this single world in the language editor with no references� Any idea about what it can mean in Squeak ? * same problem with � diffuse � and � ton � And finally, a few remarks on the castaways : - Verne�s balloon DID eventually crash � so maybe we should forget the metaphor after all. - the castaways discover that the island is secretly ruled by Captain Nemo� Does this mean there�s a secret Squeak ruler ? :) -people who quote a French author cannot be completely wicked. - the whole thing is quite exciting, since I�ve never been able to understand so many messages in the list� usually, 2 posts out of 3 are too technical for me :) vive Squeak ! __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/

3 2

[ANN] A newer set of Refactory changes (v3832)
by Ned Konz 28 Feb '05

28 Feb '05

If you haven't run the Refactoring Browser recently, you really should try this version! It fixes all of the things that used to bug me about the RB: missing menu items, odd browsers, no RB support for the Hierarchy browser, no integration with packages, no Rewrite Tool, etc.. Check out the various new menus; also look at the window menus (for instance, you can do a "browse implementors" and then run the rewrite or finder tool on those messages). I have put another Monticello diff file (against the current SqueakMap version of Refactory, which is Refactory-md.3.8.12) on my site at: http://bike-nomad.com/squeak/Refactory-nk.3832.mcd You will have to load Monticello and Refactory-md.3.8.12 first. Or, you can load the whole package at once (Monticello is still recommended) from: http://bike-nomad.com/squeak/Refactory-nk.3832.mcz Since 3830: Fixed problem with switching from comment view. Changed to environment browsers from messagelists almost everywhere. Changed LintDialog to allow passing an environment; added the ability to run Lint from various browsers (i.e. you can run lint on all the senders of a particular message, etc.) Added more package support. Use Env browsers for implementors/senders from code pane keystrokes Since 3827: Made instVar/classVar searches look in subclasses as well. Added annotation pane and optional buttons pane to Environment browsers. Added preference for HierarchyBrowser to be a subclass of RefactoringBrowser Removed useless buttons from VariableEnvironmentBrowser Fixed coloring of Environment browsers to be the same as the browser color Since 3823: added support for opening finder/rewrite tool on environment browsers added hierarchy find/rewrite. made environment browsers use RB menus Allowed changing class selection from Finder and Rewrite tools. Added to flaps registry. Refactored LintDialog to re-use category/class selector as component made ChooserMorph work right for multiple selections improved help text made lint results always display proper selection made environment browsers display class definition if no method selections added support for defining and displaying rationale for Lint rules. The 3823 announcement: The big news here is the addition of the RewriteTool, which is like a pressure washer for code janitors. It is like the FinderTool in that it lets you search for parse tree (rather than text) patterns in your code. But it also lets you specify a replacement pattern. When you say "Replace" it puts up a FileContentsBrowser from which you can view the proposed changes and load selected methods, classes, or the entire set of changes. I have also added the beginnings of a color formatter for the RB, but haven't finished all the colors yet. You can now use the RB formatter for pretty-printing tasks throughout the system. I have also improved its printing of various things, including array literals. Changes from Refactory-md.3.8.12 to Refactory-nk.3823 - added RewriteTool (like FinderTool but you can do search/replace with it) - added lint rule for override of superclass method without calling it. - added lint rule for sending of 'new initialize' and friends - added lint rule for sending a deprecated method to a known global - improved pretty printing (especially for literal arrays, etc.) - added preference for using RB to pretty-print globally - added RB-based color pretty-printing for use in browsers - deprecation fixes: fixed 'super new initialize', 'self beep', etc. - made sure that metaclasses were searched too by lint tool! - misc. bug fixes - changed lint rule for missing super sends to look for #subclassResponsibility in superclass - fixed opening of editor in some cases - sorted class names in RB environment browsers I am presenting it this way so people can get a chance to use it for a bit. Enjoy, -- Ned Konz http://bike-nomad.com/squeak/

1 0

Jump to page: