Squeak-dev October 2007

squeak-dev@lists.squeakfoundation.org

151 participants
195 discussions

Re: [OT] An artifact of possible interest...
by Brad Fuller 05 Oct '07

05 Oct '07

This is great, Dan. Thanks for placing the Squeak reference and the links in the intro. I messed around with the Live Kernel on Firefox 2.0.0.7. ran rather slow on my 1.8MHz computer. And, it seemed objects (like Asteroids and the morphic dialog demo) were tucked underneath - it seemed that the World was too small to show all the objects. When I maximized the browser to full, I saw the additional stock charts down below. I can't wait to dig into it to see what I can do with it and especially see what others more skilled than I can do. With all the morphic experience here, some neat apps might appear quickly. thanks for the hard work! brad > Folks - > > As many of you know, I and a couple of friends at Sun have been > playing around with JavaScript, and we've finally figured out out how > to have fun with a browser. > > You can find out all about it at... > > http://research.sun.com/projects/lively/ > > ...and if you have a very recent build of Safari (preferably Webkit > nightly builds) or FireFox (preferably latest Gran Paradiso build), > then you can probably have fun with it too! > > It's not at all polished, but it should look strangely familiar ;-) > > Enjoy > - Dan

1 0

Re: [OT] An artifact of possible interest...
by Brad Fuller 05 Oct '07

05 Oct '07

1 0

My namespace proposal described in Yet Another Try
by Göran Krampe 05 Oct '07

05 Oct '07

Hi folks! I just typed this in, longish but hopefully enlightening, forgive me for any typos etc. regards, Göran ------------ I agree, syntax is not really important. And we have already discussed it AT LENGHT at earlier occasions. To all of you out there that think this is the *first* Namespace-discussion on Squeak-dev - you have no idea... :) Compile time binding vs late binding: Currently we have compile time binding of class names, I think moving away from that as the "default" is too much of a change. And at the times we want to do late binding we can already use obvious Smalltalk code (in both our proposals): MyNamespace at: #Array Let me try to explain a bit about my proposed solution (and yes, it is on SqueakMap and *works* almost completely, updated for 3.9 IIRC): I have written about it on numerous occasions and every time it feels like a lot of people either misunderstand it, don't think it *is* a namespace solution at all, don't even try to understand it or all of the above. :) I am not sure why, but I think it has at least *partially* to do with people being so fixated on how "other languages do it" that they can't even begin to consider an alternative approach. If you read this, please try to open up your mind and consider that there ARE other ways to do it. :) Ok, (rubbing head to come up with the ultimate pedagogical approach), let's begin with a few "Intentions" with this proposal: - Simple. I mean, dead simple. :) - Backwards compatible. Tools should work etc etc. - Not disrupt the "feel" of Smalltalk. Read more below. Now... Michael is IMHO implementing a rather "regular" namespace solution, as so many others have done or tried doing over the years. That may be fine - and from what I know he is doing it as part of a larger project so he probably have good reasons for its design. My proposal is solely aimed at being a lightweight-just-enough-solution only aimed at Squeak and its community and not rooted in any other project. In other words - there is NO other use of my code and effort than getting it eventually accepted in Squeak - otherwise it is totally wasted. ;) Let's look at "Simple" first. In my proposal I am proposing that we "go with the flow" and evolve what we already have. What *do* we have then? We have a shared global space (SystemDictionary) and other spaces created by various participants in our community (prefixes). Examples are WA for Seaside, SM for SqueakMap and so on. Let's consider that for a second - we actually *already have* a Namespace solution in place which works! Prefixes. I can hear people thinking "Is he on crack or what, that's not namespaces..." - but I challenge you: Why not? Just because lots of people over the years have for various reasons decided to make namespaces==package (or some other concept) does not mean that a Namespace IS a package or any other source code or deployment entity. A Namespace is "just a space of names" - a Dictionary simply. Please agree with me on that. :) A named space that is a cooperatively maintained set of unique names. If we agree on this then the scope of problems we are trying to solve is made much smaller and comprehensible: - Allowing duplicate names in an image. - Being able to write short names and read short names. - Being able to manipulate namespaces like remapping or moving names between them etc. It does not deal with deployment units, method overrides, source code management etc etc! Now, let's look at the prefixes used today then: - It is not hierarchical! It is simple "a bunch of named buckets". But that is exactly what was needed! So saying that namespaces MUST be hierarchical is ignoring the fact that what we have today actually works. - Binding is compile time, just as with globals. Hey, WAComponent is of course also a global, since the solution today is just plain prefixing. I am proposing: - Allow "::" (or hey, any other nice separator that we can agree on - it is NOT that important) in global names. This is a very small change and we have done it (Andreas and I) and it works. - Implement class Namespace and let it act just like a Dictionary and let us create one instance "per prefix" automatically. This is the reification part of my proposal so that: Fruit::Orange == (Smalltalk at: #Fruit) at: #Orange Fruit::Orange == Fruit at: #Orange Fruit class == Namespace Thus our namespaces are globals and we can easily do nice dynamic lookup using "Fruit at: #Orange" if we like. We can also easily check for Namespaces being there with "Smalltalk at: #Fruit ifAbsent: []" and we can manipulate our namespaces and classes within them etc. IMHO the obvious Smalltalk way - I presume Michael's solution in this respect is similar. BUT... Andreas advised me *strongly* to let my Namespace instances delegate to Smalltalk (the SystemDictionary) because otherwise tons of code will break. So my Namespace instances behave like Dictionary but actually don't hold anything at all! The class is *still held in Smalltalk* just like before: (Smalltalk at: #Fruit::Orange) == Fruit::Orange At this point people may be confused but it all boils down to this usage pattern: - If you want to have a class Apple in your own namespace "Fruit", just name it "Fruit::Apple"! It is that simple. - If you want to move it, just rename it! The Namespace instances I describe are automatically created and maintained. - If you want to use it, just type "Fruit::Apple" (because hey, that is the name of the class!) but of course, you don't want to type all that so fine, just type "Apple" and it will automatically work! Different things will happen then: - If there is no other Apple in your image it will just work. Apple. No prefix needed. This covers 98% I guess. - If there are multiple Apple, Squeak will ask you which one you mean (nice popup menu) and autoexpand it in place! - If there are multiple Apple BUT one of them is in your LOCAL namespace (=the namespace of the class you are editing) then it will work just fine with the short form, the local Apple is chosen instead of the others. This covers perhaps 70% of those last 2%. :) Let me repeat that: If you consider what I wrote above you will only write (and read) fully qualified names (Fruits::Apple) if and only if there are multiple Apples in your image (and I bet there aren't - 98% (?) of all classes have most likely unique short names!) AND the method you are editing is in a class in a namespace that does NOT have one of them (it is not local). Please let this sink in. This means we have NO IMPORTS and we still don't need to write or read qualified names! How is this done? Let's compare to Java. In java we avoid typing long names by typing the paths once at the top of the file - the imports. Then we can use short names in the rest of the file. This is classic. Anyone who knows Eclipse and the alt-shift-o key combo knows that you ever hardly edit the imports section because Eclipse *will do it for you* if you press that key combo! So in Eclipse/Java you can emulate my proposal by pressing alt-shift-o every minute (perhaps add a background process that does it? :)) and only type short names! Yep, same effect. The only difference is that instead of encoding the qualified names by splitting out the tedious long paths into an imports section - in my proposal we simple *don't*! We use qualified long names ALL THE TIME in the source. You can do that in java too - but it would look like hell and be awful to type. The trick is to let the source use fully qualified names at ALL TIMES and just hook into the source code pane rendering code and the source code editing code and make sure the tools "render" short names and accept short names when being typed. Aha! So the trick is in the tools. The actual source code is JUST LIKE BEFORE. And that is why my proposal is so darn backwards compatible. And the simplicity of this is very powerful. Every class reference is fully qualified. If you add ten Apples in your image the old references will still refer perfectly to the Apple they intended (Stephane's use case), but suddenly they will *render* fully qualified since you otherwise would not know which one they refer to. And if you remove 9 Apples the references still around will suddenly render *short* again. Another example, if you move a class from one namespace to another - that is equal to a class rename operation - and Squeak already handles renames rather gracefully - by offering all methods it is referenced to that you can change them. Or using RB it can fix the references for you - I haven't tested this but I bet this works PERFECTLY FINE with my proposal! I hope my ramblings here have shown that my proposal is indeed VERY SIMPLE, has NO IMPORTS, still avoids typing and reading of long names, still are REAL namespaces (you can make an Apple and so can I) and is very backwards compatible (hey, even old fileout formats should work just fine and Monticello and all our other tools). But what did I mean with "Smalltalk feel"? I meant that in Smalltalk we don't have "modes". We can type a snippet of code anywhere and just run it - the only thing that is context sensitive is "self" so to speak. But if we start messing with java-ish conventional namespaces with imports we suddenly have lost that "loving feeling" - we will have lots of "modes". The snippet will bind and behave very differently based on where I run it. Which class? What imports does it have? What does OrderedCollection actually bind to? And how does a Workspace work? And what imports does the debugger have and the inspectors and all other text panes? Please consider this. regards, Göran

14 42

stack overflow using #inline anchor
by Chris Muller 04 Oct '07

04 Oct '07

I am making my own TextMorph (subclass) in which I want to be able to drag any Morph embedded directly into the text. TextMorph already supports this via #anchorMorph:at:type:. I am interested in providing an enriched #inline embedding. What I've done in MyTextMorph is express interest in mouse-over dragging by overriding #mouseEnterDragging: and #mouseLeaveDragging: which #startTrackingDropZones and #stopTrackingDropZones, respectively. Tracking drop zones is nothing more than stepping real fast to show a "marker" morph by calling the above mentioned method: ... self anchorMorph: spacer at: hand position type: #inline It works great! Except.. *sometimes*, when being rough with it, shaking a big morph around in the text it gets into an infinite recursion (sans stack overflow error), which I've pasted at the end of this message. There is a guard in CompositionScanner>>#placeEmbeddedObject: anchoredMorph | descent | "Workaround: The following should really use #textAnchorType" anchoredMorph relativeTextAnchorPosition ifNotNil:[^true]. which piqued my interest because of the comment, and another in TextAnchor>>#emphasizeScanner: aScanner self anchoredMorph ifNil: [ ^ self ]. aScanner placeEmbeddedObject: self anchoredMorph. which is interesting because of the fact it is related to its #anchoredMorph. Unfortunately, an infiinite recursion is a bad show-stopper, I need advice to help find an appropriate guard to prevent the recursion. Any help is much appreciated. - Chris From: chris To: squeak-dev(a)lists.squeakfoundation.org Subject: [BUG]IdentityDictionary(Dictionary)>>at:ifAbsent: here insert explanation of what you were doing, suspect changes you've made and so forth. 4 October 2007 12:41:17 am VM: Win32 - a SmalltalkImage Image: Squeak3.9 [latest update: #7067] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true IdentityDictionary(Dictionary)>>at:ifAbsent: Receiver: an IdentityDictionary() Arguments and temporary variables: key: #relativeTextAnchorPosition aBlock: [] in MorphExtension>>valueOfProperty:ifAbsent: {[^ aBlock value]} assoc: nil Receiver's instance variables: tally: 0 array: #(nil nil nil nil nil) MorphExtension>>valueOfProperty:ifAbsent: Receiver: a MorphExtension (602) Arguments and temporary variables: aSymbol: #relativeTextAnchorPosition aBlock: [] in MorphExtension>>valueOfProperty: {[]} Receiver's instance variables: locked: false visible: true sticky: false balloonText: nil balloonTextSelector: nil externalName: nil isPartsDonor: false actorState: nil player: nil eventHandler: nil otherProperties: nil MorphExtension>>valueOfProperty: Receiver: a MorphExtension (602) Arguments and temporary variables: aSymbol: #relativeTextAnchorPosition Receiver's instance variables: locked: false visible: true sticky: false balloonText: nil balloonTextSelector: nil externalName: nil isPartsDonor: false actorState: nil player: nil eventHandler: nil otherProperties: nil RectangleMorph(Morph)>>valueOfProperty: Receiver: a RectangleMorph(749) Arguments and temporary variables: aSymbol: #relativeTextAnchorPosition Receiver's instance variables: bounds: 0@0 corner: 94@142 owner: nil submorphs: #() fullBounds: 0@0 corner: 94@142 color: Color transparent extension: a MorphExtension (602) borderWidth: 1 borderColor: Color green --- The full stack --- IdentityDictionary(Dictionary)>>at:ifAbsent: MorphExtension>>valueOfProperty:ifAbsent: MorphExtension>>valueOfProperty: RectangleMorph(Morph)>>valueOfProperty: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - RectangleMorph(Morph)>>relativeTextAnchorPosition CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} Array(SequenceableCollection)>>do: CompositionScanner(CharacterScanner)>>setFont CompositionScanner>>setFont CompositionScanner(CharacterScanner)>>placeEmbeddedObject: CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} Array(SequenceableCollection)>>do: CompositionScanner(CharacterScanner)>>setFont CompositionScanner>>setFont CompositionScanner(CharacterScanner)>>placeEmbeddedObject: CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} Array(SequenceableCollection)>>do: CompositionScanner(CharacterScanner)>>setFont CompositionScanner>>setFont CompositionScanner(CharacterScanner)>>placeEmbeddedObject: CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} Array(SequenceableCollection)>>do: CompositionScanner(CharacterScanner)>>setFont CompositionScanner>>setFont CompositionScanner(CharacterScanner)>>placeEmbeddedObject: CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} Array(SequenceableCollection)>>do: CompositionScanner(CharacterScanner)>>setFont CompositionScanner>>setFont CompositionScanner(CharacterScanner)>>placeEmbeddedObject: CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} Array(SequenceableCollection)>>do: CompositionScanner(CharacterScanner)>>setFont CompositionScanner>>setFont CompositionScanner(CharacterScanner)>>placeEmbeddedObject: CompositionScanner>>placeEmbeddedObject: TextAnchor>>emphasizeScanner: [] in CompositionScanner(CharacterScanner)>>setFont {[:att | att emphasizeScanner: self]} ...etc...

1 0

Squeaksource (in)stability
by Andreas Raab 04 Oct '07

04 Oct '07

Hi - Our local Squeaksource installation has recently taken a turn to the worse, probably because we hit some magic number of packages or versions or so. While in the past we needed to restart SS about 2-3 times a week, it has recently gone up to needing a restart twice a day (we get emails whenever that happens so I'm not just imagining this). Help! This is completely unusable. If I hadn't added my little patch that recovers the versions involved in the lock up there would be open mutiny here by now. How can you run a Squeaksource installation with a *bit* of stability? Thanks, - Andreas

9 19

ifNotNil: perceived strangeness ;)
by Brian Brown 04 Oct '07

04 Oct '07

Looking at ProtoObject>>ifNotNil: ifNotNilBlock "Evaluate the block, unless I'm == nil (q.v.)" ^ ifNotNilBlock valueWithPossibleArgs: {self}ifNotNil: ... which is invoked if the receiver is not nil, I would expect the following to work: 5 ifNotNil: [:e | e] to return 5, but what I get is: argument of ifNotNil: must be a 0-argument block However, if first store the block in a temp: ab := [:e | e] 5 ifNotNil: ab. returns 5 I don't understand what the difference is between these; could some kind soul enlighten me as what is happening? Cheers, Brian

8 7

Is there a message profiler in Squeak?
by Robert Withers 04 Oct '07

04 Oct '07

I am looking for a class that displays the call tree of an executed block of code. thanks, Rob

7 15

Re: Is there a message profiler in Squeak?
by Rob Withers 04 Oct '07

04 Oct '07

I know nothing about code simulation. I really need to run the InterpreterSimulator and learn, considering the vm changes I want to make for my research. I didn't know semaphores trip it up. Is there no way to repair that? This would explain the call to NetNameResolver>>#addressForName: returning garbage. Rob ----- Original Message ---- From: Bert Freudenberg <bert(a)freudenbergs.de> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Sent: Wednesday, October 3, 2007 1:14:09 PM Subject: Re: Is there a message profiler in Squeak? #tallySends: simulates the code rather than running it. It will trip over the same things that can't be simulated as the debugger's "step" button. I guess code using semaphore like the network code won't work. - Bert - On Oct 3, 2007, at 20:15 , Robert Withers wrote: > This is reproducible and not limited to the vm I specified. I also > ran this with vm: 'Squeak 3.8.12beta4U.app' and it crashed. Also, > it crashes almost immediately, unlike what I said earlier. Also, > there are several problems. The crash is described below. I am > also getting code simulation errors using MessageTally tallySends: > [...]. I think this sets up the crash. > > I dug into the code and this is what I found. This code crashes > the vm: > > Socket new connectTo: 1 port: 80. > > I call #connectTo:port: with an argument of 1 due to interference > by the MessageTally. When I run the code below I crash: > > | addr s | > Socket initializeNetwork. > MessageTally tallySends: [ > addr := NetNameResolver addressForName: 'www.google.org'. > (s := SafeSocket new) connectTo: addr port: 80. > s waitForConnectionFor: Socket standardTimeout ifTimedOut: []. > ]. > > and when I run this code the result is 1. > | addr s | > Socket initializeNetwork. > MessageTally tallySends: [ > addr := NetNameResolver addressForName: 'www.google.org'. > ]. > addr > > I hope this helps, > Rob > > On Oct 3, 2007, at 10:16 AM, Robert Withers wrote: > >> Sure. I am running on a Mac with vm: 'Squeak 3.8.18beta1U.app'. >> I am running an image started from Squeak3.10alpha.7081.image or >> so. I am not sure of the exact update number since I don't have >> that root image around anymore. I have loaded everything >> specified for SSH (2 bug fixes, telnet, Crypto, SSL, SSH). I then >> ran this code, with appropriate values inserted for user and host: >> >> MessageTally tallySends: [SSH runBy: user to: host port: 22]. >> >> It ran for a bit then crashed. >> >> Rob >> >> On Oct 3, 2007, at 9:59 AM, Travis Kay wrote: >> >>> Can you share what you executed that crashed your image? >>> Which image and vm versions? >>> >>> Travis >>> >>> Robert Withers wrote: >>>> As promising as this was, it killed my image. I don't know >>>> why. Luckily, all changes are saved! I love Smalltalk! >>>> >>>> Rob >>>> >>>> On Oct 3, 2007, at 3:02 AM, Bert Freudenberg wrote: >>>> >>>>> On Oct 3, 2007, at 3:19 , Lukas Renggli wrote: >>>>> >>>>>>> I am looking for a class that displays the call tree of an >>>>>>> executed >>>>>>> block of code. >>>>>> >>>>>> MessageTally spyOn: [ 1000 factorial ] >>>>> >>>>> That is only a sampling time profiler. A call tree you get by >>>>> doing >>>>> >>>>> MessageTally tallySends: [42.0 printString] >>>>> >>>>> - Bert -

3 2

DeltaStreams and MC2
by Damien Cassou 03 Oct '07

03 Oct '07

Hi, Giovanni asked me to contact the DeltaStreams team. I just wanted to inform you that I wrote some documentation about MC2: http://wiki.squeak.org/squeak/5624. MC2 is able to manage ChangeSets as well as PackageInfo. So, I'm unsure if DeltaStreams are really useful. I also published some notes on the Summer of Squeak blog. Ask me questions if you want. -- Damien Cassou

7 12

The Sophie team needs some folks to test unicode input on the macintosh, plus resolving unicode issues on other platforms
by John M McIntosh 03 Oct '07

03 Oct '07

The Sophie team needs to understand how Sophie works with full unicode input support on the Macintosh (Kanji input for example). Both for textual entry/editing, and file/folder name usage for importing and linking to data files. If someone is interested in helping, please contact me. You would need to use a developer build from http:// dev.sophieproject.org/downloads/builds/ to ensure you have the latest work on URI UTF8 normalization and http character set resolving. We believe unicode text entry is broken on WIndows, wasn't there someone working on this? If so can you email us about progress, and or the fixes required to build a Windows VM that fully supports the entry of unicode data. We know unicode text entry is broken on Unix, again if anyone has fixes we'll review them for Sophie. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

Jump to page: