Squeak-dev March 2003

squeak-dev@lists.squeakfoundation.org

202 participants
818 discussions

UUIDGenerator problems (was: SUnit Test Failure on fresh image - Win32)
by Hannes Hirzel 01 Mar '03

01 Mar '03

There seem to be two candidates / suggestions for fixes for the UUIDGenerator problem http://swiki.gsug.org:8080/sqfixes/2961.html 7-Jan-03 John M McIntosh <johnmci(a)smalltalkconsulting.com> http://swiki.gsug.org:8080/sqfixes/2984.html Mon, 3 Feb 2003 julian(a)beta4.com -- HJH

1 0

Re: C++ exception handling for Smalltalkers
by David Simmons 01 Mar '03

01 Mar '03

"Bill Schwab" <bills(a)anest4.anest.ufl.edu> wrote in message news:b3ofs4$1n9ehh$1@ID-58434.news.dfncis.de... > Blair, > > This is slightly off-topic, but not really given that just about any > Smalltalk needs the occaisional boost from a more staticically-typed > language, and because I have C++ questions that (I suspect) only other > Smalltalkers will understand. I recently did some C++ programming that > reminded me of my lack of knowledge about/confidence in C++ exception > handling. > > You won't like it<g>, but I've been using MinGW lately, falling back on VC++ > for things that cause trouble otherwise. However, most if not all of my > coding experience with C++ excpetions has been with MFC macros. The C++ > books on my shelf at home describe try/catch, but Google searches quickly > turn up different implementations and question the thread safety of at least > some of them. Is C++ exception handling in chaos, or are the posters > confused? Do you recommend any particular implementation or know of good > reading on the subject? > > Apparently one has the choice to pass exception arguments as pointers vs. > references, and there _must_ be issues with memory management. Any > recommendations on the best way to proceed? [See what I mean about having > to ask these questions of Smalltalkers? :)] > > What does one do for an analog to #ensure:? #ifCurtailed:? Hi Bill, I regularly use c++ exceptions [and Window SEH and .NET mechanisms] in addition to those within Smalltalk/S#. Standard c++ does not provide for the notion of "resumable" exceptions, VC++ using the underlying Microsoft SEH (structured exception handle) platform model does provide this support. The S# language implementation (Smalltalk design) is layered on the SEH model (with some optimizations), which means you can catch any exception (Smalltalk or otherwise) and manage it. [sorry for the little S# commentary, but it was worth noting]. In standard c++, once the exception "hander" has been invoked for a particular "guard" expression, all intervening method frames (from the point of the exception on up the stack to the guarded-method frame) have effectively been unwound already [see temporal-issues questions regarding c++ standard at the end].. In c++ (as you know) the full expression form is: try { } catch("guard filter expression => var-type + optionally a var") { "handler code" } In VC++ we can use the extended forms: __try { } __except(ExceptionFilter(GetExceptionInformation())) { } __finally { } The extended form in vc++ allows us to provide a function for the "guard-filter". That filter serves two purposes. First it allows us to algorithmically take action regarding the "Signal/Warning/Exception" before the frames between the faulting method and the guard have been unwound, and it allows us to tell the exception mechanism what to do once our filter is finished. I.e., resume-execution, continue-looking-for-a-suitable-handler, stop-and-call-my-handler. Which means that (resumable) Smalltalk style exception handling is actually implemented in the vc++/SEH style "guard-filter" itself, whereas c++ handling is implemented in the "handler" block of SEH behavior. The second thing we notice about the extended form is that we have a "finally" clause which is used to declare code we want to have executed whenever the "try" block finishes "OR" is prematurely terminated due to an exception fault unwinding it. So, to distinguish between a "curtailed" and a "non-curtailed" Smalltalk style exception unwind we would have to add a little to the sequence. bool wasCurtailed = true; __try { ... our try body here ... wasCurtailed = false; } __except(ExceptionFilter(GetExceptionInformation())) { } __finally { if(wasCurtailed) ... else ... } I should also add that all versions of XP and later provide for dynamic SEH exception filters (first chance filters) which can be registered on a thread and will come ahead of normally stack-discipline exception guards. This latter capability is very useful for many operations where you need to handle/hide extrinsically triggered exceptions which c++ model code cannot deal with. I should also point out that c++ only traps c++ exceptions, whereas the VC++ extended form allows capturing of signals, warnings, exceptions etc which includes interrupts (including INT3/DebugBreak), faults, and the like. Microsoft's .NET CLR (common language runtime) mechanisms are fairly similar to the SEH model except (for non-specific reasons) the guard-filter does not support "resume-execution" semantics. >From .NET IL we have: .try <il_start_range> to <il_end_range> filter <il_filter_label> handler <il_start_range> to <il_end_range> // catch "<type> handler ..." are optional here finally handler <il_start_range> to <il_end_range> fault handler <il_start_range> to <il_end_range>. Generally coded as: .try { ... } filter { ... endfilter } "handler" { ... } finally { ... } fault { ... } This effectively corresponds to S# equivalents of the form: try [ ] "we can have multiple catch clauses and discrete handlers here" catch("filter-expression including closures etc") [ "handler is executed during the filter" "if recoded in .NET/VC++ handler body is no-op" ] finally [ ] fault "or ifCurtailed" [ ]. Where the keyword variable <thisSignal> can be referenced where needed, or a variable to hold <thisSignal> can be declared as a parameter to a handler block. The (typically less-efficient/more-cumbersome-nesting) classic resumable ANSI Smalltalk exceptions subset of the above would look like: [ [ [ ...place actual try body here... ] on: exceptionFilter do: [:signal| ...exception handler body... ]. ] ifCurtailed: [:signal| ...curtailed/fault handler body... ] ] ensure: [:signal| ...finally handler body... ]. As to the question of "pointer" versus "new-inst" form with exceptions, you do need to be careful. It really helps to understand the temporal semantics in question for c++ [which, as I now realize in writing this -- see below -- I am not so sure about]. Which is that the given exception-handler is logically invoked "after" all the intervening frames have been unwound. In practice they will probably not have been unwound yet (come to think about it, I'm sure the c++ spec must say something about this timing). What that means is that it is probably safe to use an "auto/stack" allocated exception in a throw since the stack has not actually been unwound when the guard is invoked. But if stack unwind semantics (maybe specified in C++ standard) result in the destructor being called on the (auto/stack) allocated exception before you get it, then you are getting an exception structure whose memory still exists but which has already had its destructor invoked. I.e., generally the destructors in an exception do nothing so this is a non-issue. I could go look at the c++ spec/tome for clarification, but I will leave this to someone with a bit more time for such digging. Cheers, -- Dave S. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ S# for the AOS & .NET Platforms David.Simmons(a)SmallScript.com http://www.smallscript.org > > Have a good one, > > Bill > > -- > Wilhelm K. Schwab, Ph.D. > bills(a)anest4.anest.ufl.edu > > >

1 0

SUnit Test Failure on fresh Image - Win32
by Chad Nantais 01 Mar '03

01 Mar '03

I've installed a clean copy of the VM and image for Windows. The image is version 3.2-4956. When I do 'TestRunner runTests', I get 1 failed test: TestUUIDPrimatives>>testCreationNodeBased I want to use SUnit to do some testing and don't want this failure to happen but I am a Squeak novice and don't know how to fix the problem. Any help is appreciated. Chad Nantais

3 2

Re: SUnit Test Failure on fresh Image - Win32
by Hannes Hirzel 01 Mar '03

01 Mar '03

"Chad Nantais" <chad(a)whistler.com> wrote: >ŸI'veŸinstalled a clean copy of the VM and image for Windows.Ÿ The image is version 3.2-4956.Ÿ >When I do 'TestRunner runTests', I get 1 failed test: ŸŸŸ > TestUUIDPrimatives>>testCreationNodeBased Ÿ >I want to use SUnit to do some testingŸand don't want this failure to happen but I am a Squeak novice and don't know how to fix the problem.Ÿ > Any help is appreciated. ŸChad Nantais Thank you for pointing us at this issue! The same test still fails in a fresh Squeak 3.4gammaOne image. 171 run, 170 passed, 1 failed, 0 errors And the SUnit version included there is still 3.0 although there is an updated version (3.1) on SqueakMaop (updated by Diego Gomez Deck and Francisco Garau; original port by Joseph Pelrine, Stephane Ducasse and Ned Konz and I think). That version conforms better with the SUnit implementations for other Smalltalk dialects. To the Guides: How do you want to handle this? -- Hannes ------------------ The test which fails testCreationRandom | uuid | (UUID new asString last: 12) = (UUID new asString last: 12) ifTrue: [^self]. 1000 timesRepeat: [uuid _ UUID new. self should: [((uuid at: 7) bitAnd: 16rF0) = 16r40]. self should: [((uuid at: 9) bitAnd: 16rC0) = 16r80]]

3 2

Re: Multi-Lingual Squeak, Cathedrals, Bazaars and Fallen Cities.
by Hannes Hirzel 01 Mar '03

01 Mar '03

Daniel, I vote for putting Eddies proposal on a prominent place on the squeak foundation swiki and declare it as a long term goal (6..12..18 months). I have as well added some comments below. -- Hannes Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > Hi Eddie. > > I understand your concerns, and in the final analysis, probably agree > multilanguage support is something that should be in the core. However, > we're not at a point where there's anything to do about MLSQ in the > core. > > The reason for that is that currently, Yoshiki's work is experimental. Yoshiki.Ohshima(a)acm.org writes >The latest version Nihongo3 and Nihongo4 Squeak are considered to be >"stable" versions and have been used in many places. (Nihongo = "Japanese language" in Japanese") HH: I do not think you can say their work is more experimental than other parts of Squeak; in fact you guides are considering shipping a broken image right now, with an error that almost every Smalltalk in the last twenty years hadn't - the ability to compile itself. Proposed reason: A newbie will not notice! (Sic!) (Side remark: It have accepted the fact that 3.4 will contain a severe bug and I'm advocating now for having a 3.5 for the end of the this month). In fact hundreds of Japanese Squeakers have been using Nihongo for a few years now without us latin-bound script users noticing! What do you think all these kids on the great photos are working with? http://homepage.mac.com/younos/PhotoAlbum3.html http://homepage.mac.com/younos/PhotoAlbum4.html You can download the image they are working with from http://squeak.hoops.ne.jp/squeak/SqueakNihongo4.zip > Since no one understands it (AFAIK) but him and Abe-san, nobody else can > maintain it. No, you have to read the excellent design documentation. The docu is really extraordinary - if all of the documents would be like that .... Yoshiki.Ohshima(a)acm.org sent in 4 mails regarding this topic three days ago The most important one is http://aspn.activestate.com/ASPN/Mail/Message/squeak/1550187 > Until someone goes in and breaks it up into pieces we can > integrate, it'll remain a separate project. Since Yoshiki has stated he > will not have time to do this in the next few months, I called for > anyone interested in helping make this happen to step forward. AFAIK, so > far, no good. Edmund is just proposes to declare to have international script support as a long term goal for Squeak. And you Daniel, with a email address ending with .il - Woudn't it be a great thing to have for example the support of Hebrew script within Squeak? Looking for champions | implementers comes later. BTW Edmund is a PhD student in Computer science I think, has worked as a cs magazine journalist, reads and writes some Japanese and has been a professional software tester. Why not delegate the coordination of such an effort to him? Asking him does not cost more than a few emails? He could be the "product manager" of internationalization. I know that Tedd Blanchard would probably be interested as well in this thing. > This means that the integration of Yoshiki's work, right now, will have > to wait until he has the time to do it, or someone else shows up with a > serious itch. It is not the question of integrating the work of Oshima-san and Abe-san right now - I agree that the structure of the "Squeak development organization" can not cope with this at the moment. But this can change in a few months if properly coordinated. I second Eddie in his plea to add having international script support in the core as a long term goal (6..12..18 months). > Daniel > > Edmund Ronald <eronald(a)cmapx.polytechnique.fr> wrote: > > I plead for Multilingual Squeak (call it MLSQ) to become the responsiblity > > of the core Squeak maintainers. Here's why: > > > > 1. MLSQ is important for all of us in non US locales. We would wish all > > Squeak to be locale-agnostic: Any program should run in any locale. > > > > 2. For MLSQ to be transparent, it should therefore not require the > > programmer to understand any Unicode or other charset or encoding > > esoterica. MLSQ character processing should ideally isolate the programmer > > completely from the specificities of any multi-byte encoding. > > > > 3. Clearly, MLSQ needs to be designed carefully by specialists familiar > > with multi-byte issues. Reliability from the start is important. Therefore > > a cathedral-like initial design approach, with good documentation by the > > likes of Oshima-san and Abe-san makes sense, rather than letting > > mods accrete as it seems has happened with morphic. > > > > 4. However, a Multilingual separate distribution (like Nihongo Squeak), or > > a loadable add-on, DO NOT MAKE SENSE. Such a separate package will > > inevitably get out of sync with the current beta, get out of sync with > > newer add-ons, unnoticed bugs will lie dormant, and people will be too > > busy to rewrite their US-centric software to ensure compatibility with > > MLSQ, retroactively, when foreign users demand it. > > > > 5. If MLSQ is part of the core of every new distribution, any > > incompatibilities of MLSQ with standard tools will become immediately > > apparent. Furthermore, foreign users will immediately notice any issues > > with any new version in their own locales, at the alpha beta and gamma > > stages of each distribution and help nip them in the bud. As all software > > runs in any locale from the start, writers of add-ons will have bugs in > > multi-nationalization communicated to them by foreign beta-testers, > > allowing hackers to fumigate their add-on *before* it reaches maturity. > > > > Which is why, again, I plead for internationalisation to be considered a > > core feature, to be intended from the start to be handed over to the core > > maintainers. > > > > Edmund

2 1

Re: Multi-Lingual Squeak, Cathedrals, Bazaars and Fallen Cities.
by Hannes Hirzel 01 Mar '03

01 Mar '03

Frank Sergeant <frank(a)canyon-medical.com> wrote: > Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > > > HH: I do not think you can say their work is more experimental than > > other parts of > > Squeak; in fact you guides are considering shipping a broken image right > > now, with > > an error that almost every Smalltalk in the last twenty years hadn't - > > the ability > > to compile itself. Proposed reason: A newbie will not notice! (Sic!) > > I was under the impression that this minor lack (I'm reluctant to call > it a bug ;)) has been present in Squeak for a very long time. The bug is not present in the release 3.2 which is still *the* download people are told to get when visiting www.squeak.org. See my test report http://aspn.activestate.com/ASPN/Mail/Message/squeak/1549922 If it is minor or not depends on what you intend Squeak to use for. > Am I wrong? In other words, it is not a simple case of a recent change set > having broken this. Thus, why the rush on fixing it? It was broken some time ago. But in general that is not an argument for shipping something broken. However people are now finalizing these days release 3.4 which will contain the bug and I accept that. The bug fix will be rolled in version 3.5 with a planned release date for end of this month. http://swiki.squeakfoundation.org/squeakfoundation/79 [snip] > And on a somewhat different topic: > > > Edmund is just proposes to declare to have international script support > > as a long term goal for Squeak. > > Long term, with plenty of thought, might not be so bad. Great that you agree! > Without knowing > anything about the subject, I'll just offer that one of my hopes for > Squeak is a very small core with simply everything possible as an > add-on. That way, those who do not want the kitchen sink are not stuck > with it. Well we international non-Anglo-Saxon / non-Spanish users do not consider proper language support "kitchen sink". -- Hannes

1 0

Re: Multi-Lingual Squeak, Cathedrals, Bazaars and Fallen Cities.
by Frank Sergeant 01 Mar '03

01 Mar '03

Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > HH: I do not think you can say their work is more experimental than > other parts of > Squeak; in fact you guides are considering shipping a broken image right > now, with > an error that almost every Smalltalk in the last twenty years hadn't - > the ability > to compile itself. Proposed reason: A newbie will not notice! (Sic!) I was under the impression that this minor lack (I'm reluctant to call it a bug ;)) has been present in Squeak for a very long time. Am I wrong? In other words, it is not a simple case of a recent change set having broken this. Thus, why the rush on fixing it? The people who need it fixed already know how to fix it, and most people do not need it fixed. So, let's not think of it as "shipping a broken image" but rather think of it as "shipping a much improved image whose great benefits we do not wish to delay further". > (Side remark: It have accepted the fact that 3.4 will contain a severe > bug (And which previous version of Squeak didn't have a severe bug (or many)?) And on a somewhat different topic: > Edmund is just proposes to declare to have international script support > as a long term goal for Squeak. Long term, with plenty of thought, might not be so bad. Without knowing anything about the subject, I'll just offer that one of my hopes for Squeak is a very small core with simply everything possible as an add-on. That way, those who do not want the kitchen sink are not stuck with it. -- Frank

1 0

[Traits] questions/comments
by German Morales 01 Mar '03

01 Mar '03

Hi everybody, specially traits people at Bern, I'm reading the very interesting Traits papers, and although I haven't finished reading, I can't resist to ask some questions and give some comments: -I see how the conflict resolution is applied for provided methods, but not for required methods. The same aliases mechanism is applied? -I don't completely like the Substraction mechanism (TDrawing - {#hash}). It seems to me that it leads to the same problem described in "Fragile hierarchies". For example, in the example of Circle composed with TCircle and TDrawing - {#hash, #= and #~=}, if later TEquality adds a new method #?=, Circle will have a conflict. Perhaps instead of: Circle = TCircle + (TDrawing - {#hash, #= and #~=}) I would prefer: Circle = TCircle + (TDrawing - TEquality) ??? -a final small comment: I like what I'm reading. That's all for the time being. I'll try to finish reading the papers. I mean, if you want to answer "that is explained later in the other paper!!!", feel free to do it ;-) Regards, German Morales

3 4

ESUG Donation to Squeak, ev.
by Stephane Ducasse 01 Mar '03

01 Mar '03

Hi all, I just want to let you know that ESUG will donate 2000 Euros to Squeak ev. (a non profit organization to promote Squeak and Smalltalk http://www.squeak.de/) to continue its work on the promotion of Squeak and Smalltalk. Note that this action as any other (the free books http://www.esug.org/sponsoring/promotionProgram.html) organized by ESUG is only possible with money, so if you know a sponsor, or you want to donate to ESUG contact us. A simple way to sponsor ESUG is to attend the conference. As you see we are making concrete actions with our money. Stef Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

1 0

An Improved Harvesting Process (was: Re: release prioritization)
by Hannes Hirzel 01 Mar '03

01 Mar '03

Doug Way <dway(a)riskmetrics.com> wrote: > > Daniel Vainsencher wrote: > > > > ... > > [Status - everyone should know where each release stands. Could be > > solved with a bug/issue DB] > > You're right. We need such a tool, but - we need more urgently a fix > > tracking tool, to make sure we don't lose work that people submit - > > fixes are higher priority than bugs, because people become more upset > > when you lose their changesets than when you ignore their bugs. > > > > We're planning to make such a tool, but we haven't made much progress in > > that, either. We could really use some help from the community with > > either of them. > > I put together a swiki page awhile ago (which I just updated a bit) with some > initial thoughts on how such a tool might work: > > http://swiki.squeakfoundation.org/squeakfoundation/86 > > Feel free to add comments at the end of the page. I'm planning to start > working on this as soon as 3.4 is released, but if anyone else is interested > in helping out with this, that would be great. > > - Doug Way I have posted the following comment on An Improved Harvesting Infrastructure http://swiki.squeakfoundation.org/squeakfoundation/86 [Hannes Hirzel, 1-March-03]: I do not think that the UI is the main problem. Even doing some manual editing work on a swiki table is not really a time consuming thing. The main problem is the process of assessing the quality of the fixes. And this is directly linked to the availability of SUnit tests for them. As a concrete next step I would suggest approaching the problem from three directions !! Harvesting process Tentative description of actions for Enhancing the bug and fix reviewing process ! Use case for harvester champion The gsug archive contains the fixes http://swiki.gsug.org:8080/SQFIXES/ # Write a little script that loads all the [Fix] tagged changeSets from the gsug archive into CodeBrowsers of a harvester champions flagship image. # run automated queries on the codebrowser to find out which class categories are affected. # generate sublists of groups of fixes - Smalltalk code that will load the fixes for other harvesters. ! Use case for general harvesters # Run one of the sublists to load a bunch of code browsers with fixes # Have a quick assessment on the importance of the fixes. # Do a table entry in a swiki table describing the fix and assigning it a status. # Ask the authors and others to supply test cases. # Collect the tests, run them. # Update the swiki table regarding the status of the fix # Feed the fix into the update stream !! Get more people involved in the reviewing and testing process. Assign areas of expertise / responsibility to harvester champions. Why not have 25 harvesters with 5 harvester champions? Newbies are welcome as well - they know how to press the 'run all tests button'. !! Get more applications / packages removed from the core Get more applications / packages removed from the core from the core so that the number of fixes diminihes. Actively seek stewards for the various packages. Question: Where is the link to the current harvesting infrastructure? ------- Please ask questions if you think something is written in a style not easy to understand or is just plain wrong. At the moment I think it is the best to update the swiki page and send a copy to this list as this is a very important matter. It actually deals with the way the Squeak community communicates regarding bugs, fixing them, assessing the quality of the fixes and finally including them. I think that involvement of more people is needed. Doing this fixing process can't be the duty of just 5 volunteers! -- Hannes Hirzel

1 0

Jump to page: