Squeak-dev October 2001

squeak-dev@lists.squeakfoundation.org

191 participants
600 discussions

Help with sound
by Daniel Joyce 02 Oct '01

02 Oct '01

The Midi works great. But none of the sound playing demos work. The wave editor, etc. Is sound that bad on Unix? NB, normal window/open/close sound effects and others work fine too. Where is that code handled? Perhaps I can look there? Or is it just that all the sampled sound demos are broken? -Daniel

4 3

Re: Celeste improvements!
by Fleeberz＠aol.com 02 Oct '01

02 Oct '01

In a message dated 2001-10-01 11:19:46 AM, lex(a)cc.gatech.edu writes: >It would be nice to have a filter that chooses a particular thread. I >think this would help with your goal. Unfortunately, thread information >can't be stored in the current index file format, at least not easily. Well, some sort of hack perhaps? celesteThreadBloat.cs? >I guess one of the existing lines of the file could be extended with >more info, as a hack.... Exactly! Or perhaps the file could be left just the way it is, and a parallel file added, maybe using SkipLists... >Also, a general "OR" filter would be nice -- right now all you get is an >implicit "AND" of all active filters. Really, an etoys-like interface >to the filter list would be very nice.... Sure. >Note, if you are willing to hand-mark messages, you can file messages >into a "non-chitchat" category as you read them. (If you aren't-willing >to hand-mark them, I don't see how you are going to distinguish such a >property.) Yes! I was thinking only of hand-marking messages, as I doubt it would be easy to tell chitchat and spam from useful messages (unless of course you filter anything from Fleeberz into /dev/null ;-) --Flee

2 1

adding a server to "publsh it" list
by John Voiklis 02 Oct '01

02 Oct '01

How does one add one's own server to the list of project servers...ie how does a person set up his own super swiki? Thank you, John

1 0

Re: Why we should remove {} from Squeak
by danielv＠netvision.net.il 02 Oct '01

02 Oct '01

Well, by definition, they're trying accentuate some considerations (by ignoring them pointedly), even though it's possible that all involved including the original proposer are already aware of them. In doing this, they mute other considerations, specifically, whatever the proposer cares about. So they're a long way of saying "what you care about, I'm ignoring", which is argumentative and not fun. By another measure, they very often don't include any new ideas or interesting presentation, which is a waste of bits. This thread, specifically, includes lots of *counter examples* to this rule, but it still generally holds. Of course, this is somewhat a matter of personal taste, they have their legitimate uses (to point out unconsidered likely repercussions - "If you convince those language design fanatics at SqC of this idea, they'll do it, and #@ will be the next to go, and then...!" ;-), I've used them too sometimes, usual disclaimers, etc. Does this help? Daniel Vainsencher "Richard A. O'Keefe" <ok(a)atlas.otago.ac.nz> wrote: > You want a syntactic analogue? Here's one: Smalltalk could get by > without blocks. [snip ]> Can anyone else tell me what is wrong with a polite reductio ad absurdum > argument?

1 0

Re: Getting accents into Squeak
by Richard A. O'Keefe 02 Oct '01

02 Oct '01

John Hinsley <jhinsley(a)telinco.co.uk> wrote: apropos keyboard chucks up lots of man pages which *may* be relevant -- on Linux anyway. Under Solaris, the vast majority of them deal with 'curses'. However, loadkeys/dumpkeys/keytables tell me that Solaris/Sun-4 keyboard offers _three_ ways to get accented letters: - compose key - Alt Graph key; you can say what each key does on its own, or with the shift key, or with the Alt Graph key, but you cannot say what it does with shift AND Alt Graph. It would be OK for things like inverted question mark and exclamation mark, fractions, currency symbols, mu, &c, but not so good for letters. - dead keys (called "floating accent" keys): acute, cedilla, circumflex, grave, tilde, umlaut. It's possible to combine Alt Graph and "dead key", e-acute could for example by <AltGraph + '> e. For someone who needs a lot of accented letters, it might be acceptable to swipe some of the function keys and use them as accent dead keys. The documentation does NOT make clear whether the X Window System pays any attention to these keytables. Xkeycaps is a _great_ tool.

1 0

Re: Caveats
by Bob Arning 02 Oct '01

02 Oct '01

On Mon, 1 Oct 2001 19:15:03 -0500 Daniel Joyce <daniel.a.joyce(a)att.net> wrote: > Hard coded extents, or improper clipping cause all sorts of text/buttons/etc >to appear outside the bounds of their containing morphs. FWIW clipping of submorphs is not a general property of Morphic in Squeak. A few morphs (transformation morphs, e.g.) do clip their submorphs, but most simply don't and I think that is intentional and desirable. Cheers, Bob

3 2

Re: Why we should remove {} from Squeak
by Richard A. O'Keefe 02 Oct '01

02 Oct '01

ducasse stephane <ducasse(a)iam.unibe.ch> writes: > so it obviously CAN be eliminated. That doesn't mean it should be. > #@ can be eliminated too: aNumber @ anotherNumber is equivalent to > Point x: aNumber y: anotherNumber. That doesn't mean #@ should be > eliminated. There is a big different @ is a message not a parsed construct with specific rules!!!!! As a Squeak *user* I couldn't care less. The analogy holds good: (feature X *could* be eliminated) does NOT entail (feature X *should* be eliminated). You want a syntactic analogue? Here's one: Smalltalk could get by without blocks. BlockReplacement Where there is now a block ... [:a1 ... :an| stuff ] ... referring to method variables v1 ... vk, write |t| t _ BlockReplacement for: thisContext in: self selector: #c:m1:...mk: and add a method c: homeContext m1: a1 ... mk: ak stuff replacing by vi homeContext at: #vi vi := e homeContext at: #vi put: e ^e homeContext return: e There's no shortage of details to be worked out, but the thing _could_ be done. This might even be a reasonable implementation strategy. That does not mean the feature SHOULD be eliminated. > The practical questions are > - would eliminating this feature save more code in the parser and elsewhere > than it would cost in all the code using it (remember, not all such code > is known to SqC or anyone else) I could remove it! This is a fact of no interest or value to anyone else. The fact that someone who doesn't LIKE the feature would not be harmed by deleting it should neither surprise nor inform anyone. > - is ideological purity worth the loss of clarity? Sure else Smalltalk would be like Java In a word: rubbish. Smalltalk *HAS* this feature and is not like Java. (Hint: 'int' is not a class in Java. Hint: look at control structures.) > - would it be feasible to make {} support a module? > > At 8:49 +0200 9/30/01, ducasse stephane wrote: >> #() is necessary because it is compiled statically and cannot >> not be simulated by other construct. >> Storing #() in Stack frame is not really good >> but this is an implementation aspect. > > This is false. Any use of # can be eliminated by adding a class variable > and a class method using lazy initialisation. For example, > #( abc 'abc' 4 3.4 $r ) This is not my point. I was just saying that storing #() in stake frame can lead to strange error. The points that were explicitly made were "#() is necessary" and "#() ... cannot be simulated by other construct." As I have shown, neither is true. I'm really sorry to see the level of the discussion Can anyone else tell me what is wrong with a polite reductio ad absurdum argument?

1 0

Caveats
by Daniel Joyce 02 Oct '01

02 Oct '01

I will say the biggest caveats I still have is the 'dirtiness' of morphic. Hard coded extents, or improper clipping cause all sorts of text/buttons/etc to appear outside the bounds of their containing morphs. It's ugly in some places. Is there anyone working on cleaning this up? Also, has the Morphic rewrite started? Morphic still handles some translations/rotations inconsistently. If there is any work being done on rewriting morphic transforms, I'd be intrested in helping. Daniel

4 3

RE: Why we should remove {} from Squeak
by danielv＠netvision.net.il 02 Oct '01

02 Oct '01

How about this - self premadeFlowFormula forParameters: ... #premadeFlowFormula is an accessor to a cached object representing a mathematical expression. The browser tool recognizes the "premade" prefix, which is a convention for such things. So it looks for and finds a method called flowFormulaDefinition, which returns an XML description (in this case, probably MathML) of the formula. It is this method that would be used for the lazy initialization of the formula object. Having found the conventional matching "Definition" method, having recognized it as standard XML, it checks the schema for the data, and starts looking for the appropriate object to represent it directly in the method. This could be an inline editor, or an icon that brings one up. If this object is used in more than one place (other accessors to the sender), the browser gives some indication of the further implication changing it might have. Of course, this works for math, SVG graphics, icons, whatever. No syntax changes, your code can be published anywhere and be completely readable by standard tools, but you get most of the advantages of Jecel's powerful "just put the objects in the code" usage metaphor. The convention can serve eToys just as easily as textual browsing tools. Of course, the browser should provide convinient tools for embedding the things in the first place, automating the creation of the accessor, lazy initalization (if caching is wanted) and so forth. Daniel "Stephen Pair" <spair(a)advantive.com> wrote: > Andreas Raab wrote: > > > Having operators is useful too, I would like to have operators too > > > because I prefer to type > > > 2 + 3 * 6 than 2 + (3 * 6) > > > and because this is MATH and MATH are right! > > > > > > I hope you see my point. > > > > If your point is that we should not have appropriate operator > > precedences, then I don't see it. I find absolutely nothing > > wrong with them. There are plenty of language (Prolog, for > > example) dealing with operator precedence pretty well and at > > the same time not restricting people to use only built-in > > operators. So actually I agree - I want operator precedences too! ;-) > > I think we should be careful on this slippery slope...as you point out, > there is a delicate balance between simplicity and purity. Many > languages have been ruined by adding constructs that were meant to make > things more convenient but sacrificed consistency. I think this was > Stephane's point actually. These constructs usually make a language > more convenient for those with a lot of experience in the language, but > much more difficult for people new to the language. If you need proof > of this, just look at the recent thread titled "Storing and Retrieving > Points." > > I'm not arguing against using mathematical precedence, just that the > idea be carefully considered. Also, there are many mathematical > expressions that cannot be rendered in plain text. Why not augment > Squeak with the complete language of mathematics instead? Let's allow a > mathematical expression to be constructed using a full graphical > representation and then be dropped into a method. > > - Stephen

1 0

Re: Skip List in #4308
by danielv＠netvision.net.il 02 Oct '01

02 Oct '01

Well, I really cannot say who said what, or who I'm answering to, but - In Celeste, this could make recovery after image crashes faster. With SortedCollections re-adding the n logged actions done before the crash takes n^2 time, with SkipLists, presumably, n*log(n). Or we could tweak Celeste to not update this list during recovery, and resort it once later. Still nicer to just have nice behaving data structures... Anyone know what this thing eats in memory usage? Daniel Karl Ramberg <karl.ramberg(a)chello.se> wrote: > On Tue, 25 Sep 2001, Andreas Raab wrote: > > > Folks, > > > > I noticed them coming into Squeak a while ago and always since I wanted to > > ask this question: What the heck are they good for?! ;-) I don't see them > Basically, Skiplists (and/or balanced tree implementations of > SortedCollection) should be used anywhere where you have a lot of > inserts/removals from a sorted collection, and profiling shows that that > is a problem. > > Scott

3 3

Jump to page: