Squeak-dev April 2001

squeak-dev@lists.squeakfoundation.org

165 participants
614 discussions

Dumb question about headless & Nebraska
by Kevin Fisher 02 Apr '01

02 Apr '01

Hi: This is probably a dumb question but...is it possible to set up a headless Squeak that runs a Nebraska server? I was thinking about running a headless Swiki server and being able to use Nebraska to administer it would be kinda cool. :)

1 0

Object, or Attribut, or something else...
by GeneCox 02 Apr '01

02 Apr '01

Hi, Smalltalkers Almost everything in SmallTalk is interesting, but not its classes tree;-) To my opinion, some kind of clarifying still needs to be make. Since I use English as a foreign language I just try my best to explain as follows: Being a Chinese, and with a good knowledge of Eastern Philosiphy, I don't see anything of a real heirarchy in Smalltalk( or any OO children languages). Sorry, I haven't read a lot, before I say this, of documents here and there on the net. I cannot afford to do that in China. Different levels of classifying or grouping have nothing to do with heirarchy at all. And keep this clear will help SmallTalk a lot as a pure class-based language. The puzzle came out of some kind of mistaking objects but not their attributes to be the main target when the class-tree was invented. For instance, say I am a man, middle aged, tall, used to be a proffessor and now work for some ABCD company as Mananger of Marketing Department or something, then I could be grouped into these classes: Man MidAged Tall people People who have changed job Company employees which class should I belonging to? I simply be someone who posess, or be composition of all these attributes. The root of the Smalltalk Classes Tree should be Atrribute, not Object. Say, I learned math in college, Mr Octave be the Proffessor who taught me, and I learned some music from Miss Doremi, adding to a lot of other things from other people. Here somebody will see something of inheriting occur. But one will not be son of their teachers simply because he has learned("inherited") something from them and objects in a Smalltalk class tree never have such teacher-student relationship. It is far more clear to look at things this way, that anObject is made up of someAttributes( relations with others), and atrributes can be grouped if they are common ones shared among some objects. (When talking about a piece of attribute particularly, it is correct to say anObject belongs to some group, but only in that aspect). And these groups can still be grouped, to an imaginaryAtrributeRoot, which represents atrributes common among all objects. Some thing else will emerge from this kind of clarifying. For Atrribute should at once be divided into(fall into) two groups as knowledge and behavior. And the knowledge part of anObject's atrribute shows itself up when it gives some information to other objects or gains some from others, while the behavior part can be "seen" when the object does something to cause other objects or itself to change. Giving/gaining information, of course, is a kind of behavior. All what a SmallTalk object needs is just, and at least, these two part of attributes. Because they are not a real phisicaly object at all! The knowledge part is less noticed, and thrown into some class/instance or class instance variables in a term of "data". Think it over. If it has been correct to emphases the behavior part of anObject's attributes in that all its knowledge will be invisible unless it does something(perhaps influences others), then why not take a step forward to throw away those C/I or C.I. variables? Just let object learn something, tell something, and manage its knowledge or memory. Take a look at these: Bonny keep: Number new as: #age. "this will get things run.(maybe, #keep:for: --you know my English is not good ENOUGH)" Bonny age: 10. "the system will generate set/get method automatically" Bonny prop: #age ifTrue:[ Bonny age printOn: blackboard ]. Bonny age: Bonny age + 1. Bonny forget: #age. "forgetting something like a real Bonny. All relative methods frozen." Bonny age. => some inform for Exception occur. The system will manage those hiden things better than programmers, for instance, people only need to care about what the target object should know and what it will do, and decide accordinly which group should be the most efficient to reside it in, and some kind of type check can be available at once though it's free to use or not use( I use newInstance instead of new to emphasize the group-individual relationship of atrribute classifying): initialize "I will prepare my memory for everything, and the set/get pair of methods will be ready." self keep: Number newInstance as: #age; "the programmer want this be checked later." keep: nil as: #hobby; "not checked when using #hobby: something message later." keep: Fruit newInstance as: #favour; "not Vegetables..." keep: JavaBean UglyFace as: #afraid. "...Java?! Maybe a joke." and system will generate some methods include "querying" ones as #component and #knowledge: Bonny component. "componet attributes, all more easy to understand, capabilities." => #(#knowledge -> #( #age -> #aNumber #hobby -> #nil #favour -> #aFruit #afraidOf -> #'a JavaBean UglyFace' #and -> #someOthers) #behavior -> #( #age #age: #hobby #hobby: #favour #favour #afraid #afraid: #sleep #run #eat #sing #etc )) Bonny knowledge. => #(#age #hobby #favour #afraid) "not knowledge-gaining/showing actions, though looks alike" If you like change, then include #behavior in place of existing similar one to report all its unique behaviors as to its "working class". At least the OO manner will be enforced, and Smalltalk objects made up of atrributes( capability in knowledge and behavior) will be able to change themselves all the time, just like their model real objects( for you can always ask it to keep: something as/for: #aSelector, then make use of that!). Because changes only occur within the knowledge part, it is not the same as some dynamatic object. For the amount of attributes shared among objects will be much less than the number of different "object classes" what we have now, it will make the liborary much smaller. For many of the classes existing are in fact instances of the attribute-composition. With time much more things could change if this Attribute centered tech would be accept by Smalltalkers. No more discussion on those composition mannered instance creation is needed here. An additional #canActAs: aPresident method or something would make Bonny act like a President whenever the Court would comfirm that. Yet this is not multi-heirarchy or multi-inherits, but multi-grouping at different level for different situations or aspects and Bonny's knowledge and behavior will change. Also, this will give the system a chance to mask the Smalltalk programms, one may call it some kind of a Language Wraper, when it's in need. For example, Smalltalkers will easily use any libs available no matter which language they are originally stemed from as long as Squeak will mask the codes to run on their Virtual Machines, for instance, say Java VMs. When you browse the IBM homepage searching for NetRexx and then find that this <500k sized little thing generates(calls JDK to do the job) some good code to make advantege of Java and JavaBeans, you may want to have a try. Tea or coffee, that's not the question. Only important thing is that some Smalltalk water, will, make it. Thank all of those who invented Smalltalk and have ever contributed to it! Otherwise many people would have lived in darkness :-) Good luck! GeneCox genecox(a)21cn.com (This letter was originally for discussion on another topic.) >On Thursday 29 March 2001 14:37, Karl Wilson wrote: >> why doesn't it say something like: >> >> ProtoObject class subclass #Object class >> >> instanceVariableNames: '' > >When you do "ProtoObject subclass: #Object ..." this method takes care >of all these little details automatically. > >> and why can't you spawn a class side heirarchy? >> >> Behavior >> ClassDescription >> Class >> ProtoObject class >> Object class > >Ooops - I had said you would reach "Behavior class" but that was wrong. >Since the system created all these metaclasses behind your back and >doesn't even bother to give them proper names, showing them like this >would probably cause more confusion. It is easy to patch the tools to >do this, but I don't think it is a good idea. > >> I am sure this will all make sense after awhile. Thanks again. > >Others have given a lot of great pointers to more information about >this than most people want to know. I prefer the alternative adopted by >the Self dialect of Smalltalk - simply design this complication out of >the language! http://www.sun.com/research/self/ > >-- Jecel

3 2

Re: [BUG][FIX][VM][UNIX] Socket assumes connection in Linux
by Bert Freudenberg 02 Apr '01

02 Apr '01

On Sat, 31 Mar 2001, Patrik Nordebo wrote: > On Sat, Mar 31, 2001 at 04:52:46PM +0200, Stephan Rudlof wrote: > > could you post this patch marked (prefix of subject) as > > [BUG][FIX][VM][UNIX] > > again? > > Right ho. Patrick, You should've omitted the "Re:" prefix of the subject - replies wont normally get included into the http://swiki.gsug.org/sqfixes archive. I manually added your message, though. -- Bert

1 0

Relative URLs (again)
by Bert Freudenberg 02 Apr '01

02 Apr '01

On Fri Mar 16, 2001, I wrote: > Btw, it's always okay to specify the protocol, even in a relative URL > like this: "file:foo/bar". Actually, I was wrong. RFC 2396 says If the scheme component is defined, indicating that the reference starts with a scheme name, then the reference is interpreted as an absolute URI and we are done. Otherwise, the reference URI's scheme is inherited from the base URI's scheme component. Due to a loophole in prior specifications [RFC1630], some parsers allow the scheme name to be present in a relative URI if it is the same as the base URI scheme. Unfortunately, this can conflict with the correct parsing of non-hierarchical URI. For backwards compatibility, an implementation may work around such references by removing the scheme if it matches that of the base URI and the scheme is known to always use the <hier_part> syntax. The parser can then continue with the steps below for the remainder of the reference components. Validating parsers should mark such a misformed relative reference as an error. So "file:foo/bar" is invalid, as is even "http:/somedir/somefile". Netscape 4 and other browsers tolerate this, while Mozilla nowadays does not. I was about to file a bug report but found this: http://bugzilla.mozilla.org/show_bug.cgi?id=22251 The "bug" gets reported quite often, as there are a number of web sites using such wrong adresses - but the Mozilla developers decided to not un-fix the browser but let the page authors fix their pages. -- Bert

1 0

Re: Odd highlighting of Class names in Browser in 2.9alpha
by Bob Arning 02 Apr '01

02 Apr '01

Andrew, There was a problem with this at one time, but I thought it had been fixed. The difference in behavior behavior has to do with the fact that the list with the classes is inside an AlignmentMorph so as to better accomodate the buttons beneath it. This led to a wrinkle in how colors of panes were set when you changed teh color of the window. A fwe questions: What is you Squeak display depth? Is your 2.9 image fully updated? Have you changed the color of the browsers in which highlighting looks odd? Cheers, Bob On Fri, 30 Mar 2001 19:07:38 -0800 "Andrew P. Black" <black(a)cse.ogi.edu> wrote: >I have noticed some off behavior in 2.9 alpha, which I don't see in >either 2.8 or 3.0. So perhaps no one is interesting in tracking this >down, but I'm puzzled because I can't explain it. > >In some (but not all) of my System Browsers, the highlighting of the >currently selected class is weird. That is, instead of being a >smooth band of dark color, it is an ugly stipple pattern. > >I can't see why this should be. The System Browser contains four >PluggableListMorphs, all executing the same drawOn: method, which >seems to do highlighting by using 'color darker'. Why does the >PluggableListMorph with the class list look different from the others? > >Is this a bug or a feature? Am I the only person who sees this?

2 1

Squeak written in Scheme
by J Scott Jaderholm 02 Apr '01

02 Apr '01

Good day Squeakers, soon to be Schweakers, We're having a party in #squeak on irc.openprojects.net to celebrate the release of Schweak, a new version of Squeak completely rewritten in Scheme. We have VMs for Linux/UNIX and Windows, but unfortunately we've yet to build a VM for MacOS, so any help with this would be greatly appreciated. We'd like to invite all to drop by and party with us. The url is in the topic and we'd love any feedback! Actually we were done yesterday but didn't want to release it on April 1st, you know, people might think it was a joke. Sincerely, jsj

1 0

[ENH] Better TrueType fonts
by Ned Konz 02 Apr '01

02 Apr '01

It's not yet done. But it does work, sort of, for black text. See the attached .gif file for a sample of what this can do (the top, black sample) versus what it should look like (the bottom, magenta sample). Perhaps someone could make it work in color (needs a proper colormap between the 8-bit greyscale source form and the destination). Also, how would you keep the italic characters from getting cut off at the upper right of their bounding boxes (and still have decent looking kerning)? from preamble: "Change Set: TTFInstallFix-nk Date: 1 April 2001 Author: Ned Konz This allows specification of form depth when converting TrueType fonts to StrikeFonts. This will work to get TrueType fonts displayed fairly well, but only in black, so far. Other problems include character forms cut off at edge of bounding boxes (noticeable with italic fonts). TTFontReader installTTF: '/usr/share/fonts/truetype/verdana.ttf' asTextStyle: #Verdana sizes: #(24 60) depth: 8 "!

1 0

Re: morphic related question...
by Ned Konz 02 Apr '01

02 Apr '01

On Sunday 01 April 2001 18:28, Raymond Tiefenthal wrote: > I try to explain my question: > Given, I have 2 simple morphs from class Morph, which where created non > programatically, > by dragging out of a parts bin, for example. How can I refer to them and > how can 1 refer to > the other? I could open an inspector on the morph to assign it to a global > var (like A_self), > then I would open an inpector on the other morph (like A addMorphBack: > self). You can tell a Workspace "start accepting dropped Morphs for reference". When you drop a Morph on a Workspace with this enabled, the Morph will be added to the bindings of the Workspace, and its name will be added to the text of the Workspace. If you do this with both of your Morphs, you can then work with them in a Workspace. There is also the scripting support. > Another way could be using the internal names, but I think that would > involve more typing. > I'm interested in a way to do it by morphic's rules and philosophy. > Another example: I want a MenuMorph, which shall set it's item's target's > to any other morph. MenuItemMorphs have a control menu item called set target. I don't know how it works, though. I've never been able to get it to work for me. > I would have to create a subclass with special > behaviour. I don't understand. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

RE: benchmarks
by Richard A. O'Keefe 02 Apr '01

02 Apr '01

> From: G.J.Tielemans(a)dinkel.utwente.nl > Performance is one thing, but isn't Java loosing it's > platform independancy > now Microsoft goes it's own way after SUN's victory (?) in court? Peter Crowther <Peter.Crowther(a)melandra.com> pointed out that Sun's Java CM runs under Windows 2k. I should also point out that IBM are pushing the Java wagon pretty hard, including such things as - distributing a free Java compiler (Jikes, lots of ugly C++) - having their own Java for Windows (IBM Visual Age for Java) - plugging Java in their DeveloperWorks stuff - giving away free 2-CD "developerWorks toolbox for e-business" kits to anyone who asks (I have a set) with VA Java and a ton of stuff in Java. - providing free Java goodies on their developerWorks web site Microsoft burned IBM's fingers over OS/2; I don't think IBM will forget that in a hurry. (Come to think of it, I'm *sure* they haven't forgotten: they're also pushing Linux...)

1 0

RE: How can I get FormSetFonts (from TrueType fonts) to display anti-aliased?
by Raab, Andreas 01 Apr '01

01 Apr '01

Ned, Have a look at the following two methods: BitBlt>>installStrikeFont:foregroundColor:backgroundColor: BitBlt>>displayString:on:from:to:at:kern: That's where most of the magic happens. You might experiment with the first method for installing an appropriate alpha map and blending rules. I would also recommend to take out the primitive code (from the second method) because I'm uncertain if there are some optimizations down deep which might interfere with your experiments. Cheers, - Andreas > -----Original Message----- > From: Ned Konz [mailto:ned@bike-nomad.com] > Sent: Sunday, April 01, 2001 1:12 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: How can I get FormSetFonts (from TrueType fonts) to display > anti-aliased? > > > I've been trying to get TrueType fonts to display > anti-aliased. I've gotten > them as far as reading in good-looking Forms. > > I've gotten the TrueType fonts to read in well using the > attached change set. > > The attached FSFonts.gif is a 2X magnified picture of two > samples of the same > font (Verdana Bold Italic 42). The top (better-looking) > sample was made > directly from the glyphs Form in the FormSetFont using this > from a Workspace: > > The attached FSFont1x.gif is a 1X version of the better > looking sample, > showing that it can look pretty good in practice. > > SketchMorph withForm: (FormSetFont allInstances first glyphs > contentsOfArea: > (1810@0 extent: 100@53)) ) openInHand > > The bottom sample is a TextMorph that uses the same font. > > It appears that the problem lies with the drawing of the > characters of the > FormSetFont by the TextMorph (actually (I think) the NewParagraph). > > Although the FormSetFont has an 8-bit (or deeper) Form with > grey-scale > antialiasing, it seems to be drawn 1-bit deep. > > What I'd like is for the grey edges in the FormSetFont glyphs > form to be > rendered as alpha blending when drawn, so the FormSetFonts > could be used to > make good-looking headlines, etc. I suspect that this could > be done by using > a correct color map and BitBlt mode, but I'm not sure where to do it. > > Can anyone point me in the right direction? I started looking > at how the > fonts were drawn, but I quickly ran into my lack of knowledge > about BitBlt > modes and the DisplayScanner. > > Rather than spend too much more time on this, if anyone has a > suggestion or > quick fix, it would be appreciated! > > We're really close to having TrueType fonts work pretty well > in Squeak! > > -- > Ned Konz > currently: Stanwood, WA > email: ned(a)bike-nomad.com > homepage: http://bike-nomad.com >

1 0

Jump to page: