Squeak-dev June 2000

squeak-dev@lists.squeakfoundation.org

134 participants
686 discussions

Re: [QUESTION]Morph allSubInstances size =>19196 !!
by Stefan Matthias Aust 28 Jun '00

28 Jun '00

At 22:19 27.06.00 +0200, Karl Ramberg wrote: >On my daily use image I evaluated > >Morph allSubInstances size > >and got 25000 about after a _long_ time. >Then I did the same test in a clean 2.9a image and got 3600 about. >Then I backed up my daily use image and deleted all projects >and got the result 19196. >My questions are: > >1 why are there so may instances of Morph still around when there are no >projects etc. I'd guess that you keep a lot of stuff around in morphic's trashcan. Every time you click on the (X) halo, that morph is stored in the trashcan. Quite annoying if you ask me as it also happens if you don't work with flaps and so don't be aware of that trashcan at all. Fortunately, you can switch off this behavior in the preferences. There's also an utilty method (one of these one-billion methods in that class) for emptying the trashcan. bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf

1 0

Compiled primitives for Squeak 2.8?
by Mark Guzdial 28 Jun '00

28 Jun '00

I was out of town during the 2.8 release, so please excuse if this was explained earlier. Where do I find 2.8 compiled primitives? I downloaded Squeak2.8-2345 for the Mac to get the final version, but it doesn't include any primitives. Do I just reuse the ones from 2.7 and 2.8a, or is there a collection of them somewhere? Thanks! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

2 3

ANSI draft in PDF format?
by Lex Spoon 28 Jun '00

28 Jun '00

Does anyone have a copy of the ANSI draft in PDF format? My copy is on the other end of the continent on a computer that's turned off :( Someone should post the PDF somewhere, and I'll try and find a place for it if I can. The so-called RTF version seems to only be usable from Microsoft Word, because the file has undocumented extensions in it. -Lex

2 1

Re: [GOODIE] SpaceWar
by John-Reed Maffeo 28 Jun '00

28 Jun '00

I found a copy of the article here: http://www.wheels.org/spacewar/stone/rolling_stone.html enjoy -M-

2 1

Re: Canvas is-an Encoder?
by Lex Spoon 28 Jun '00

28 Jun '00

You don't need a general mechanism to do the negotiation you talk about. For example, you can just have *>>drawMorph: and Morph>>drawOn*:. (in fact, these methods are already present for the case of canvases). The suggestion seems to be that you might reuse a certain kind of object-graph traversal for different algorithms. But, there's not just *one* kind of traversal that all algorithms can use. There isn't a way to do writeObject: that will work for all algorithms. So, what exactly is being abstracted here? I guess I still don't see. Can you point me to this paper? The name "encoder" is probably part of my problem. Encoders are normally "reversible functions", but canvases aren't reversible, and "function" isn't specific at all. -Lex 320089961391-0001(a)t-online.de (Marcel Weiher) wrote: > > From: "Lex Spoon" <lex(a)cc.gatech.edu> > > > > > Why is Canvas a subclass of NullEncoder and FlattenEncoder, lately? It > > seems to be something added to make the Postscript support work, > but the > > solution seems kinda strang--Encoding and drawing really seem like > > separate issues to me. For example, should the same class implement > > drawCircle: and initWithTarget:? fillRectangle: and writeObject: ? > > Ahem, yes, it should, but the isa relationship could still be > removed as things are right now. > > The ping-pong double-dispatch mechanism that the encoders make > available is actually very useful for a display situation, so useful > that a less generic version of the same mechanism has been > independently added to Canvas. Of course, IMNSHO it would be much > cooler to just reuse the encoder's version, because that's why I put > it there! > > On the history of the mechanism, Dan's paper describing this > mechanism (early 80ies, I think) actually used graphical 'ports' as > its running example, IIRC. > > When you think about the display process more closely, it starts to > make a lot of sense, because how to display an object is something > that actually has to be "negotiated" between a specific display and a > specific object, and it is also an encoding task. Descriptions of > graphical objects are encoded into commands to drive a display, > wether these commands happen to be direct calls to routines, encoded > commands to display accelerators. > > The "negotiation" phase also makes a lot of sense because often > times an optimization that is vital for one type of display yields to > unacceptable output for a different type. Encoding all this behind > an opaque interface is possible, but letting display and/or object > adapt is a much more squeaky solution. What's more, specialized > algorithms/capabilities/hardware can be taken advantage of between > specific objects and specific displays (always taking "display" to > mean some sort of graphical output device or format). > > The generic #writeObject: interface makes it possible to reuse code > in a wide variety of different circumstances. For example, > Canvas/Morph currently have specific code to render the submorhs, > traversing the collection. This code is redundant because > 'flattening' object hierarchies is what the FlattenEncoder does, > except that it does it for all sorts of different applications, not > just a canvas. It can do this for all these different circumstances > because #writeObject: will automatically do the right thing for the > subobjects and the actual encoder. It's not a big thing, but these > 'flattening' patterns occur all over the image, whereas this one > implementation would actually suffice. > > > With multiple inheritance, it would seem reasonalbe to have > > PostScriptCanvas be a subclass of both Canvas and Encoder. But as > > things are, making Canvas a subclass of Encoder just for Postscript's > > sake seems strange. Why not just have an 'encoder' instance > variable in > > PostscriptCanvas? > > It's not really just for Postscript's sake, although at present it > looks that way because the functionality that is provided is not > used, but rather duplicated. Call me biased, but it makes more sense > to me to remove the duplication... > > Marcel

1 0

Re: Ship it with Squeak
by douglas＠winetech.com 28 Jun '00

28 Jun '00

Pauls missive has inspired me to put down some thoughts that have been percolating for a while: I have been watching this Squeak list for about 6 months, and was hoping to see real evidence that we could consider Squeak for our next generation product (see winetech.com). We currently have software written in a combination of Visual Basic, C++, and the Microsoft Jet Engine for the Access database. Squeak initially looked promising as a platform for the future, but I am gradually and sadly reaching the conclusion that it is may never be usable for software like ours. Here are the issues: 1. No current orientation toward application deployment at Squeak Central. 2. No stable GUI that provides critical tools for manipulating large slabs of data (particularly Grids that show multiple records and Rich Text boxes that display and edit text while using multiple fonts and colors). Although I realize that many on this mailing list regard these as old-fashioned and boring, they are still necessary for many purposes. We would like to use Squeak's wonderful capabilities in addition to these tools, but we cannot start development without them. 3. No database ( We currently have about 50,000 records across two databases, taking up about 100 megabytes). We need fast access from a variety of different indexes. 4. Not even an obvious ability to store 100 megabytes on BTrieve-like files. 5. Poor documentation. While it looks like Squeak has tremendous pluses (Innovative, open source, great functionality, machine independence) , these seem to primarily benefit teaching and research, and not actual application developers like ourselves. I admire Paul's effort to develop a deployable Squeak application, and would consider any success he has as great evidence that we may be able to use Squeak also. Sincerely Douglas Flower Douglas(a)winetech.com ========================== (From Paul Fernhout) At 06:15 PM 6/25/00 -0400, you wrote: >All- > >I am trying to determine the extent to which it is feasible to >create and maintain an application deployment kit for Squeak, and how >much others would be willing to cooperate in doing so. > >While we're not committing to anything yet, here is a note to sound out >interest. > >At the moment we (my wife and I) are seriously considering making >version 2.0 of our PlantStudio (Botanical Illustration Software that >produces 3D models of plants) product in Squeak so we can also have Mac >and Linux versions. I personally would do the bulk of the conversion >work from Delphi. The effort might possibly start in a couple of months. >We would expect that project to take four months or so. > >However, I think Squeak as it is needs several changes before it can be >used to deploy a "commercial" application to an internet audience (in >this case, of graphic professionals). I'm trying to decide if these can >be fixed with a reasonable amount of effort that still lets me finish >the application in four months. > >To me, the most important changes to do for deployment are: >* Making Squeak event driven at the VM level to eliminate those >occasional weird mouse drags >* Creating a "lockable" GUI w/ common data entry widgets >* Producing a small footprint image with all "clutter" removed >* Doing odds and ends related to stability and testing >* Having reliable VMs for Linux (which?), Windows (NT, 2000, 95, 98), >and Mac (PPC, Which OS Revs?) >* Developing an install process for all platforms (might be platform >specific; maybe could live with ZIP file install) >* Replacing the fonts (to meet license obligations) > >Things I want but could live without: >* Single EXE >* Namespaces >* Image buildable from scratch >* Consistent exception handling >* GUI builder >* One-click deployment building > >Things I don't need for my application (but others might want, or I >might want in the future): >* Printing >* Sound >* Reliable sockets >* HTML viewing >* Reentrancy >* Better development tools and version control > >I haven't done much with 2.8 so it may be improving in these areas. It >certainly sounds like pluggable primitives have come a long way. > >I think Squeak would need significant work to get it into shape for >shipping "shrink-wrap" quality applications. I would like to do this >without forking Squeak, but I don't know if this is possible. I think it >would require maintaining a seperate line of development for a while. > >This isn't specifically a dig at SqueakC (well maybe a little :-) , but >I think supporting a version of Squeak intended for shipping (ANSI) >Smalltalk apps in a boring but predictable GUI is a fairly different >activity and set of priorities than supporting a version for >experimenting (Pink vs. Blue planes). SqueakC may want a Pink (Blue?) >version or not, but it is clear (to me) that that a version of Squeak to >support applications is not where their priority is right now. I don't >fault them for this. But I do see a void which has remained since the >first OOPSLA '97 Squeak BOF where half the people in the room wanted an >experimental version and half wanted a stable version. The reality as I >see it is that the half wanting a stable version of Squeak for apps or >utilities mostly don't stick with Squeak. (Obviously there are some >noteable exceptions.) But the reality (for me) is that even when a >client doesn't care if I use Squeak for a simple utility, I know Python >or C++ or Java gives them what they want faster. I'd like to change that >situation. > >My last posts about this issue to the Squeak list were in February 2000 >(just before the NASDAQ meltdown) when I proposed a Squeak/Pro of >"SqueakHat". Several people wrote to me saying they or their company >had considered something similar or might consider participating in this >somehow. Some offered the possibility of funding; some offered to work >for pay or as partners. I decided not to pursue that proposal at the >time in part because of a concern of tearing either the community or my >relationship to it apart. The Squeak list is a precious resource and >things can often get ugly when money changes hands. > >So here is something I am thinking about (but not yet committing to) >which I hope will fit well with the Squeak community and open source >philosophy: >* Putting up a forked version of Squeak which is specifically for >deploying utilities and applications for the PC, Linux, and Mac. >This might be done on SourceForge. >* Coordinating the minimal changes (mostly removals!) required to make >this a stable deployment platform from a "make it reliable for the end >user" point of view. >* Possibly jettisoning much of Morphic and maybe also MVC and having a >hybrid GUI framework perhaps with parts of both useful for typical >commercial GUI type tasks (text box, combo box, button, image, etc.). >This GUI might have a "game-like" look. This is probably the most >controversial part, and I could reconsider this if another approach >using Morphic somehow was less work and looked nice and was stable for >an application. I like what Morphic wants to be; I just think the first >try needs to be refactored or redone for simplicity and stability in an >application. This GUI part is the highest risk part of the effort (after >ensuring reliable VMs on multiple platforms). >* Putting all this under the Squeak license (or similar compatible open >source licenses for add-ons determined by their contributor). >* I as a tool-kit user would build on top of this deployment kit for >applications for sale. > >The question to the list is: >* Am I out of my mind to think of using Squeak at this point to make a >GUI-based application for sale? >* Am I wildly underestimating the work involved? >* What am I forgetting? >* Is it likely this fork would just get ignored even if I maintained it >in the face of continual evolution along a main line? >* If this is a good idea, what sort of cooperative framework makes sense >to maintain a deployable version of Squeak for multiple platforms? >* Would people on this list be upset if this effort used this mailing >list for coordination, posting of fixes, etc. given that they would >pertain to an essentially forked version? >* Would others contribute substantially to this deployment platform -- >since its needs might differ from the mainline of Squeak development? > >The last is most important to me because I don't have the current Mac or >Linux set-up to support these platforms without a big investment in >time and new software and equipment. Maintaining the image and codebase >on one system is easy; testing VMs on multiple platforms and >configurations is hard. It is not clear to me that the current VMs would >be appropriate for deployment. At the very least changes to make them >even driven would be needed. > >Let me be clear: >* We're not asking for help developing the application, and the >application would itself most likely not be open source, and that >creates a bit of a conflict between where the deployment kit stops and >our application begins (e.g. is our 3D turtle part of the kit?) >* We have no funds to pay anyone for their contributions or their time. >* We have no interest in selling Smalltalk development tools or the >deployment kit. >* We might release other applications on top of this framework -- like >our two other products, and perhaps later something related to an email >client, news reader, web client, and knowledgebase. >* By coordinating such an effort, we might gain a commercial advantage >over others in publicity, which would be valuable in gaining consulting >contracts helping others transition their applications to Squeak. This >has the potential to create conflicts (hopefully friendly rivalries). >* We probably won't make any money from this unless PlantStudio ships >and people like it enough to register it (i.e. "tip" us), or consulting >comes along related to helping others deploy apps with the Squeak >toolkit. > >Does this sound like the beginnings of an approach that would produce a >stable version of Squeak for commercial apps and utilities, with no >money changing hands, and without posing a big threat to the beautiful >thing that is the Squeak community? > >I'd also appreciate frank and informed commentary on why what I propose >won't work (for technical, effort, or social reasons) if that is your >belief. Alternate suggestions or pointers to work in progress >(especially on a VM with events) would be appreciated. Replies to the >list would generally be preferred so all may comment on them. > >-Paul Fernhout >Kurtz-Fernhout Software >========================================================= >Developers of custom software and educational simulations >Creators of the Garden with Insight(TM) garden simulator >http://www.kurtz-fernhout.com

5 4

[GOODIE] ProjectView accepts dropped morphs
by Bolot Kerimbaev 28 Jun '00

28 Jun '00

My scenario: I'm doing development and testing in one project, but want another to be the UI playground (without browser, close to what end-user would see). When I'm done with testing a morph, I want to move it to the playground project. This change set makes it easier (vs. paste buffer). Change Set: ProjViewDnD Date: 28 June 2000 Author: Bolot Kerimbaev Support for drag-n-dropping morphs into a morphic project link. To enable, inspect a project view morph and do-it: self enableDrop: true Now, dropping a morph will remove it from the current world and put it into the link target.

1 0

Re: External Events/DSO Open Source Offering
by Michael Rueger 28 Jun '00

28 Jun '00

Stephan Rudlof wrote: > > > > http://ifsl.mb.uni-magdeburg.de/~michael/ > > sr@Klaus:~/Squeak/Import > ping ifsl.mb.uni-magdeburg.de > ping: unknown host: ifsl.mb.uni-magdeburg.de > > Could you check the link please? Just clicked on it and it's fine (from behind the firewall at Disney). Something wrong with your name server? Non-authoritative answer: Name: ifsl120.MB.Uni-Magdeburg.DE Address: 141.44.153.120 Aliases: ifsl.mb.uni-magdeburg.de Michael

2 1

Re: External Events/DSO Open Source Offering
by Paul McDonough 28 Jun '00

28 Jun '00

Who us? No way mon, if we tried to bring down the net, you wouldn't be readin' about it here, know what I mean? Ahem. No seriously, most of that is experiment-in-progress images, different vms, etc., at least I think it is. The trouble is, that project's been sitting around for a while, and we never seem to have time to get it sorted out and packaged and posted - so at the very least, we figured we could grab the whole danged mess and slap it up on an ftp site in case there's one poor soul out there on some remote, wintry island, who is both keen enough on external events and (more importantly) bored enough to dig through it and find the nuggets and ... well, there ya go. In coming days/weeks we will be updating the site, weeding out what doesn't need to be there, and sorting the rest into something easily navigable. So if you don't particularly want it Right This Minute, you might as well wait - it'll get smaller. Really sorry for the inconvenience, folks. Workin' on it. Things have been pretty busy round here lately. Paul McDonough CEO (acting) The Fourth Estate, Inc. paulm(a)4thEstate.com www.4thEstate.com ---------- >From: Tim Rowledge <tim(a)sumeru.stanford.edu> >To: squeak(a)cs.uiuc.edu >Subject: Re: External Events/DSO Open Source Offering >Date: Tue, Jun 27, 2000, 9:37 PM > > Hah! It's an experiment in bringing the net to its knees! Caught you! > > tim > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Strange OpCodes: CRN: Compare to Random Number >

3 3

RE: [Q] Class definition
by Eric Arseneau 28 Jun '00

28 Jun '00

If you look at the method ClassBuilder>>#name:inEnvironment:subclassOf:type:instanceVariableNames:clas sVariableNames:poolDictionaries:category:unsafe: The first line or so calls instVars _ Scanner new scanFieldNames: instVarString. You could change this line to extract the type info and store it somewhere else, and extract the names of the inst vars and keep those for the class builder. If you call Scanner new scanFieldNames: with the argument you passed in the expression below, you can debug what happens. You could also use a syntax already supported by Smalltalk's like Visual Works instanceVariables: 'i <Integer> j <Integer> c <Character>' And replace the same code above and pullout the type info. The plus side for this is that you can use it for method headers as well: print: stream <WriteStream> indent: indent <Integer> I don't remember whether the Squeak parser handles this directly, but I do know that the old ST-80 parser had a flag in the parser to indicate whether it should parse type information or not. Just don't remember what version. > Hi! > > Is there a good reason why class definitions are not handled as source > code? > > It is not possible to put comments there and not possible to change the > layout of things. This is not an idle question as I intend to try out > some ideas that needs type information to be stored with the instance > variables. > > The following for example will be parsed and useful with normal ST-80 > syntax, at the same time it can be read as having types associated with > the variables. I will present a version of this later this year > as an alternative > to the present Slang. > > Object subclass: #X > instanceVariableNames: > #(":int" i j > ":char" c) > classVariableNames: '' > poolDictionaries: '' > category: '' > > The compiler (or whoever) changes it to > > Object subclass: #X > instanceVariableNames: 'i j c ' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Perhaps a new field could be added to ClassDescription for the > source code? > That would also make it easier to document the variables, write a short > comment when it is introduced. > > Adding a field to all classes and metaclasses, is that very difficult? > > /Mats > >

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
69
Older →

Jump to page: