Squeak-dev February 2005

squeak-dev@lists.squeakfoundation.org

191 participants
430 discussions

[ANN][ENH] "ChangeSet and PackageInfo integration" package published on SqueakMap.
by Ned Konz 26 Feb '05

26 Feb '05

I've just published a package that I've been using for some time that integrates ChangeSets with PackageInfo instances. It requires PackageInfo-Extras v8 to be loaded first. What it does: - Lets you move change sets and their contents between packages, filter message lists by package, find methods with out-of-order versioning, package extension methods, etc. - Adds resettable filtering to message lists. It can be downloaded from SqueakMap, or from either of: http://map1.squeakfoundation.org/sm/accountbyid/092daeeb-7a37-427f-8afb-66b… http://bike-nomad.com/squeak/PackagesVsCS-nk.20.mcz The two attached images show: * the new MessageList filter menu (filters are now resettable); you can say "browse methods" from the ChangeSorter and get a filterable list of methods that you can then operate on. * The shifted ChangeSorter menu, showing new package-related operations. -- Ned Konz http://bike-nomad.com/squeak/

2 2

Re: [Squeak-e] Modules etcetera on squeak-dev
by Mark Miller 26 Feb '05

26 Feb '05

[Sorry about the wide distribution of this message. Please direct replies to an appropriately narrower audience -- probably modules(a)lists.squeakfoundation.org .] Cees de Groot wrote: > I'm not sure how many subscribe here that do not subscribe or actively > follow squeak-dev, but a team is forming to work towards a short-term > 'modules' thingy for Squeak. I lurk, sort-of, but the volume of traffic is overwhelming, so I don't even read it as it goes by. Below, you mention a separate list for discussion of modules -- modules(a)lists.squeakfoundation.org. I suggest that the discussion of modules should indeed move there, if you want the attention of people too busy to read squeak-dev. Is the intention of this thread to fix the main problem preventing the creation of a Squeak-E -- a capability secure variant of Squeak? By "main problem", I mean the pervasive use of widely shared (effectively global) namespaces and state. If so, perhaps Squeak-E is the right forum, and perhaps we don't need yet another new list? > Dan Ingalls leads the team, and he wants > to implement The Simplest Thing With The Largest Impact - which means > that he is looking at stuff like E, Vats so that modules could have > security implications (implications in the positive sense). The E Vat concept and the E module concept are mostly orthogonal. Vats Each Vat runs a singly threaded event loop -- a Vat is an island of synchrony in a sea of asynchrony. Vats form an address-space-like disjoint partitioning of objects, where the live references that may cross between vats may only be "eventual references" -- references that may only carry eventually-sent messages, so that Vats can only be asynchronously coupled to each other. Inter-Vat references are also the only kind that may spontaneously break. Breakage can be caused by network failure, crash, or killing a Vat -- the Vat is thereby the unit of partial failure and resource eviction. With these two properties, the Vat is also the largest sensible unit of identity-preserving separable persistence, and therefore of migration. Smalltalk's orthogonal persistence system is great, and I look forward to having it underneath E-on-Squeak. However, this doesn't solve the separable persistence / migration problem. Both Smalltalk and E handle the separable persistence problem by serialization. This is where we should look for a bridge between the E Vat concept and the E module concept. At http://www.erights.org/data/serial/jhu-paper/index.html , I give a sketch of a user-level serialization system for E, where this serialization system is 1) able to provide per-Vat or finer persistence, and 2) where this serialization system is based on "un-evaluation", i.e., where the serialized form of an object graph is an expression, and unserializing is just evaluating this expression. Eval & Modules The current E module system is provided as a primitive part of E, but should instead be built up from eval, and hopefully will be in future implementations of E. See p8 of http://www.erights.org/talks/asian03/paradigm-revised.pdf for a precise statement of the security properties that eval must satisfy. (That document uses the term "loader" for the eval function.) We thereby unify loading and unserialization -- they are both simple uses of expression evaluation. (Oz & Oz-E unify unserialization and module loading in essentially this way as well.) I don't like the current E module system, and I have various thoughts about how to change it. However, they all have in common 1) that they are built, without cheating, on an eval with the security properties explained in the above document, and 2) that module import may lead to shared identity, but not shared state. What does this mean? Suppose A and B both import name "C" from loader L. In the current E module system, the text of C is as-if evaluated afresh each time, and so and identities or state created by C is created separately for each of its clients, A and B. A and B cannot come to have a communications channel to each other merely by having shared access to the loader L, and by having asked L to import the same module name, "C". The problem with this approach is that any identities exported by C are not shared by A and B, preventing them from comparing such identities in order to talk to each other about C-stuff. For example, "x isKindOf: C" may be pointlessly picky. I think, instead, each loader should load a given module name exactly once, where the resulting module values are required to be DeepFrozen (transitively immutable). This still gives us multiple instantiation of created identities, by virtue of creating multiple first class loaders. But it separates the relatively-safe sharing of identities from the relatively dangerous sharing of state. In the approximation that the source of loaded modules is itself immutable (in E-on-Java, if the classpath and its contents are immutable), then each loader can be considered immutable. By enabling two entities to share access to loader L, we enable them to share imported identities, but not thereby to interact with each other. In the Smalltalk context, where development happens primarily within a single persistent system image, rather than by loading module files from a file system, all these issues may look quite different. I don't yet have any clear idea how to think about these differences. (The BitC language has adopted the safety portion of this rule corresponding to use of a single shared loader. See section 6.1 of http://www.coyotos.org/docs/bitc-spec/bitc-spec.html .) > Anyway, there's a mailing list > (modules-subscribe(a)discuss.squeakfoundation.org) and a Swiki page to > discuss this all (http://minnow.cc.gatech.edu/squeak/5608) so if you > think you've got something to add from the E perspective, this is > probably The Chance. What's the relationship between http://lists.squeakfoundation.org/listinfo and http://discuss.squeakfoundation.org/ ? I see the first lists Squeak-e but not modules, while the latter lists modules but not Squeak-e. When I click on the "Modules" link on http://discuss.squeakfoundation.org/ , I get a > Internal Server Error > > The server encountered an internal error or misconfiguration and was unable to > complete your request. > > Please contact the server administrator, webmaster@localhost and inform them > of the time the error occurred, and anything you might have done that may have > caused the error. > > More information about this error may be available in the server error log. > Apache/2.0.52 (Debian GNU/Linux) DAV/2 SVN/1.1.3 Server at > discuss.squeakfoundation.org Port 80 Everyone, please remember to respond to a narrower audience. Thanks. -- Text by me above is hereby placed in the public domain Cheers, --MarkM

2 2

Help with multiByteFileStream
by stéphane ducasse 26 Feb '05

26 Feb '05

Hi I'm porting my env to 3.8 and I have the following problem (which worked like a charm in 3.7). The loadImage: method normally load a form store in a file. loadImage: aString "Load an image from a file and install it as new graphics" | stream res | stream := FileStream readOnlyFileNamed: aString, '.frm'. res := Compiler new evaluate: stream in: nil to: nil notifying: nil ifFail: [nil]. res isNil ifTrue: [PopUpMenu inform: 'Problem with the file ', aString, '.frm'] ifFalse: [(res isKindOf: Form) ifTrue: [self image: res]] the file is of this form: (Form extent: 70@78 depth: 16 fromArray: #( 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0....... 0 0) offset: 0@0) Apparently now the res := Compiler new evaluate: stream in: nil to: nil notifying: nil ifFail: [nil]. returns nil when the stream is a MultiByteFileStream So what is the best way to obtain an stream working the old way? Stef

1 1

[ANN][ENH] Yet more Refactoring Browser improvements
by Ned Konz 26 Feb '05

26 Feb '05

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.3829.mcd You will have to load Refactory-md.3.8.12 first. 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. -- Ned Konz http://bike-nomad.com/squeak/

1 1

[ANN] Seaside article by Pavel Krivanek (in Czech)
by Jan B. Krejčí 26 Feb '05

26 Feb '05

Hi all, Pavel Krivanek has published first volume of his article serie dedicated to Seaside at http://www.root.cz Unfortunately it's in Czech :) Good work, Pavel! You serve to us as an example of less talking, more working. (Damn, how do you get so much free time? I'll probably have to ask your employer ;) ) -- .:jbk:. Jan B. Krejci

4 3

Re: Modules
by Avi Bryant 26 Feb '05

26 Feb '05

On Thu, 24 Feb 2005 12:05:17 -0800, Dan Ingalls <Dan(a)squeakland.org> wrote: > Greetings Florin, Goran, Cees, Steven, Brian, David, and Craig, Ned, Colin! > ... and anyone else who is interested but hasn't yet said so. I've been away from squeak-dev for a week (and my, what a week of traffic to catch up on), but - count me in. I liked what Craig said about designer/implementor/user: I too, would *love* to just be a user, but I recognize that my needs as a user may not be met without doing some design, and I've long been used to the fact that design is useless unless you commit to implementing it :). As to what I'd like to see in such a system, Colin's already talked about our plans for the next major iteration of Monticello; obviously, I'd hope that our work there will somehow play a role in the module work - even if (or perhaps ideally if) that role is "modules isn't going to address versioning, that's Monticello's job". That is, in fact, another key aspect of what I think is important in going forward: the word "module" can describe solutions to so many different kinds of problems, and I think it's critical that we are clear from the start about which problems we are trying to solve, and not conflate the solutions to too many of them into one mechanism. The flip side of that is that we not solve the same problem multiple times: versioning and partitioning may be separate problems, but a versioning mechanism should build on the partitioning mechanism used by the rest of the image, not invent its own (as Store effectively does in VW). Forgive me if I'm saying things that are obvious or have already been said in the maze of threads that have popped up recently; I *think* I've seen most of the relevant postings but it's hard to be sure when not reading them as they come in... Avi

1 0

[BUG]Array(Object)>>error:
by Markus Fritsche 26 Feb '05

26 Feb '05

typing cmd+6, done "link to method" 26 February 2005 4:48:30 pm VM: Win32 - a SmalltalkImage Image: Squeak3.8gamma [latest update: #6548] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Dokumente und Einstellungen\mfritsche\Eigene Dateien\Squeak\050203 Trusted Dir C:\Dokumente und Einstellungen\mfritsche\Eigene Dateien\Squeak\050203\mfritsche Untrusted Dir C:\My Squeak\mfritsche Array(Object)>>error: Receiver: #() Arguments and temporary variables: aString: 'this collection is empty' Receiver's instance variables: #() Array(Collection)>>errorEmptyCollection Receiver: #() Arguments and temporary variables: Receiver's instance variables: #() Array(SequenceableCollection)>>first Receiver: #() Arguments and temporary variables: Receiver's instance variables: #() TextLink>>analyze: Receiver: a TextLink Arguments and temporary variables: aString: 'SqOLAPCube>>#dimensionAdd:' list: #() Receiver's instance variables: classAndMethod: nil --- The full stack --- Array(Object)>>error: Array(Collection)>>errorEmptyCollection Array(SequenceableCollection)>>first TextLink>>analyze: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TextMorphEditor(ParagraphEditor)>>changeEmphasis: TextMorphEditor>>changeEmphasis: TextMorphEditor(ParagraphEditor)>>dispatchOnCharacter:with: TextMorphEditor>>dispatchOnCharacter:with: TextMorphEditor(ParagraphEditor)>>readKeyboard TextMorphEditor>>readKeyboard [] in TextMorphForEditView(TextMorph)>>keyStroke: {[editor readKeyboard]} TextMorphForEditView(TextMorph)>>handleInteraction:fromEvent: TextMorphForEditView>>handleInteraction:fromEvent: TextMorphForEditView(TextMorph)>>keyStroke: TextMorphForEditView>>keyStroke: TextMorphForEditView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForEditView(Morph)>>handleEvent: TextMorphForEditView(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. capturingGesture := capturingGest...]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]} -- http://reauktion.de/archer/

2 3

[SHOUT] How to stop having shout active on a particular instance of editor
by stéphane ducasse 26 Feb '05

26 Feb '05

hi andy I would like to know if this is possible not to have shout running on a particular instance of editor Stef

1 1

Stefs roadmap for 3.9, time to get it nailed down
by goran.krampe＠bluefish.se 26 Feb '05

26 Feb '05

Hi all! So, the report 1 is out and we now want to discuss and finalize Stefs (and crew) roadmap for Squeak 3.9 according to the postings a while back from Stephane and crew. I include below those two postings verbatim. The only thing in the report that affects this is that we want the ToolBuilder package into 3.9. Let's take a look at this yet again and come to a concluded roadmap within say a week or so. I am now going to take weekend and will probably not be very active until monday. But this todo is on me: http://anakin.bluefish.se/castaways/1 ...and I will make sure to vaccum clean this thread and gather the discussion into a proposal during next week. So if you make your voice heard it will definitely have an effect. Just try to keep the postings clear and showing what you support and not - otherwise it will be hard to turn it into some sort of result. So, let's all take a good look here and discuss these bits. Then we will post a concrete proposal based on all that (trying to reflect the general concensus) and take some last feedback and then we decide it. regards, Göran PS. Perhaps our "take" on this roadmap would have been interesting but frankly - we don't have time for that now. Remember, we aren't going to push stuff down your throats - let's discuss it alltogether, just like we always do and take it from there. ------------- Hi all, <WARNING> Please before replying to this email ask yourself what you did recently for squeak besides sending emails! And as you will see there are a lot of places where you can contribute. </WARNING> So after a long discussion with the crew here (nathanael, alex, marcus and adrian will agree) we decided not to fork and this will cost us energy and time. But we think that this is worth. We plan to do the following: we will focus on building 3.9 and take our time and your feedback to do it. We think that april/mai would be a good release date so that we have the time to test and work in pace. (Note also that this will be my last contribution to the community (from today perspective since I do not know where I will living in 5 months from now). So we want to have a really cool 3.9.) BUT BUT BUT we will only focus on what we are good at and we NEED the help of other people to work on the other areas: UI, Morph (PLM), Etoy, Note that the list after is not fixed since we do not want to push something that will not be ready. For example, we will pay an extreme attention that the traits are fully integrated. Nathanael is planning to help and also would like to for example make sure that he can refactor the collection hierarchy before releasing traits. We are LOOKING for a lead harvester, and ETOY harvester and a Multimedia one. 3.9 Full - new multimedia app (Ogg reader?) - YAXO (p) a real one on SqueakSource :) (yes this is a subliminal message :)) - Wonderland back in shape (you see mark there are room) / 3DBalloon - and anything that is valuable for full - GENIE (yes ned we want that) - Connectors (yes yes we want that too) -> ned would it be possible to get access to one your recent Genie image? - but people will have to provide package in MC format (or at least a good sar) 3.9 Basic (the stuff for the developer: not the mini image! ) - Diego look - eCompletion or another package (p) - keybinding cool package (may this one should go in basic as package (p) because the current way of binding key is system wide and not really good) - shout (p) - SqueakMap II (yes we want it) - rbengine (p) this is absolutely not intrusive (ok there are some duplicated functionality but we need it and if a brave soul wants to optimize it will be really possible for now we should not be that warry since the package is self-contained and we are not enough, so we should be productive and then after one guy will fix that if necessary). So simply a package that can be removed but that is needed to code. - services - new preferences pane - traits - new compiler framework (note that according to Scott this should not have an impact on etoy) But again we need a Etoy expert to help. - refactoring of systemDictionary as proposed to get it done once right. Again read again what we wrote and comment. (I think that having SmallltalkImage and SystemDictionary does not make sense to have both) - OB (p?) + browseUnit new version (integrated version). The idea of having OB here is that we want to enable the creation of new tools and deprecate slowly the use of the old browser (which could be packaged but keep alive in case we only want to have one single but gigantic class). - MC in the base image (we all would like to have a mini image and a cool script but for now not having MC in the base image is getting in our way to maintain packages and to also produce a much smaller mini-image, to also learn what we cannot do with MC and ask kindly to MC developers if they can fix the problems we see). Except if of course someone come up with a better idea and code to support that. We would like to avoid to abandon the idea of having packages in basic since we would like to push further the packages curving process. - We would like also to have a much better support for packages: Package as real entities with support for - resources - meta information - comments - substituing package info (alex is willing to work on that). We also like the idea of TestServer, so feel free to write tests! May be markus G could be the guy responsible to push them into the stream. Markus? Romain? Note that for the packages marked as (p) of course we will ask if the package creator is willing to help and feel the pression of having his cool package in Basic. One requirement could be that the code is managed with MC and SqueakSource so that in case of emergency we can get our hands on it :) We ask for feedback, help, testing, ideas.... BUT MORE IMPORTANT: This community needs to structure itself. We would like to be able to pay someone to work half-time on harvesting and improving the system. So we are looking for solutions. Would you be ready to pay for a cool Squeak release? Do not reply to this question now, just look at yourself in the mirror and let us hope that something happen. Stef, alex, marcs, adrian and nathanael (writing style of Stef ;))) PS: marcus got totally burnt by the harvesting process and the lack of communication so now he should reenergize himself. So don't expect anything from him, because he is learning to say no :))) From: ducasse(a)iam.unibe.ch Subject: A roadmap for 3.9 Date: 9 décembre 2004 13:38:44 GMT+01:00 To: squeak-dev(a)lists.squeakfoundation.org Reply-To: squeak-dev(a)lists.squeakfoundation.org hi all I have been discussing with marcus/alex and also thinking about that after my remarks on andreas remarks related to changes, interfaces/ cleaning vs changes. So to avoid get frustration from all the parts and to state clearly what is our plan for 3.9 we would like you to read the following and let us know. Depending on the reactions, we (the guys from berne) may decide to produce our own stream, because we must work too ;). But we understand that other people cannot deal with a system changing. But in that case we should draw the consequences. Our part that we will work on for 3.9 is to get the system improved from a developers point of view. We think that having a good foundation is important for everybody. The overall idea is to slowly improve one aspect of Squeak: The idea to have a System to build the next System with. This has lots of consquences, one is that you want the system to be in a shape that e.g., students that are not yet complete Squeak experts can start to do experiments with it on a quite deep level, e.g., change the compiler or add a feature to the Browser. Another aspect is to have a System for research. The Traits project has been hugely successful, but it has shown that Squeak does have real problems if you use it for stuff like that. If Squeak is supposed to be the system of choice for research like this, we need to fix those problems, we need to make sure that the lessons learned from those projects get fed back into the system. (One example is the change-notification that was added to 3.7, it is a direct result of the Traits project) All this does not mean that 3.9 will only be about that stuff: We surely want to see e.g. the work of Diego beeing included, also any changes that other people would need are welcome. For our perspective here what we would like to have: we put in (p) the code that will be in external packages, which likely will be "full". - services - new preferences pane - OB (p?) + browseUnit new version - MC in the base image - rbengine (p) - shout (p) - SqueakMap II (yes we want it) - eCompletion or another package - keybinding - traits - new compiler framework of anthony adapted by marcus to produce not full block. Note that for Etoy the old compiler will still be in the image so from that point of view it should not have an impact. - refactoring of systemDictionary. (see below this point) We are sure that we forgot something but this is what we have on top of my head. Now for systemDictionary here is the situation and here is where we would like to be after 3.9 In the past we created SmalltalkImage out of SystemDictionary in the hope to have SystemDictionary be a nice and simple namespace class. Lot of stuff has been put in coherent places (SystemNavigation, SpaceTally, Changeset....) But this will not work since people get used to add stuff there and Smalltalk is a cool name. So the new proposal is the following one and is partly implemented. Note however that it will require from us a lot of work so if you are against it please say it and we will only do it for us. from a user point of view we want to have: only one class: SmalltalkImage/SystDict for all the image related services (VM pluggins, ....) but the namespace behavior will be delegated to Namespace. All the previous code referencing Smalltalk will work but with deprecation for the namespace interface. From the language programmer point of view: there will be a namespace that can be used for experimentation this class will replace the environment class of dan that is now obsolete We plan to proceed that way: - create a class namespace with a new interface (done) - delegate from systemDictionary to this new class (done but not published) - deprecate all the namespace method of systemDictionary (but we likely want to keep them for some time) - fix all the in image senders of Smalltalk as a namespace to use the new class (using self environment for example). (partly done over the previous years) - merge back SmalltalkImage into SystemDictionary: the idea here is to not have SystemDict as a subclass of Dictionary - have Smalltalk pointing to an instance of this new entity, so that everybody is happy. Stef and Marcus

17 80

[FIX] TextLinkValidateFix-nk
by ned＠squeakland.org 26 Feb '05

26 Feb '05

from preamble: "Change Set: TextLinkValidateFix-nk Date: 26 February 2005 Author: Ned Konz Provides a little more bulletproofing (though still no help) on the Cmd-6 link creation operations. "!

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
43
Older →

Jump to page: