Squeak-dev May 1998

squeak-dev@lists.squeakfoundation.org

82 participants
182 discussions

Updates for today
by Dan Ingalls 29 May '98

29 May '98

069WindowRelabel-di.cs Install basic (via morph menu) facility for relabelling SystemWindows 070ProjectTweaks-di.cs Defines 'go back' in morphic world menu (you'll have to make new ones) to mean return to the project from which you came (whether parent or not). If you want to get back to the parent, use the 'jump to...' command and choose the parent item. 071FourEdits-di.cs Four handy edit commands... Ctl-U Convert linefeeds to carriage returns in selection - useful for some FTP sites Ctl-X Force selection to lowercase Ctl-Y Force selection to uppercase Ctl-Z Capitalize all words in selection 072MiscFixes-wod-27May.cs ChangeSet fileOut -- use 'asFileName' rather than 'truncateTo: 27'. Allows preserving longer change set names on systems that support it. FileList fileAllIn -- open the file using 'readOnlyFileNamed:' rather than 'oldFileNamed:'. Allows the filing-in of read-only files. FileList updateFileList -- set the fileName to nil. Allows the file list menu to revert to the 'noFileSelectedMenu:'. Debugger selection -- two fixes unearthed from an old change set. Class comments -- ability to fileIn the form written by a changeList 073FixesForIan-di.cs Two fixes requested by Ian Piumarta: Provide a context menu for the Transcript and Workspaces in Morphic. Make reframing of ProjectViews work right. Plus a couple of others... Enables the volume menu in FileLists in morphic. Makes primitive string display (as in 'abc' displayAt: 0@0) be black on white. [It had been black on transparent and all black in 16 bits. Very hard to read the primitive debugger then!] 074FileList-resort.st Causes the directory contents to re-sort as well as the file list if you don't have any file selected.

1 0

Re: Pluggability
by Sabine van Loon 28 May '98

28 May '98

Tom you wrote: [snip] > This sounds similar to the stuff Digitalk did when they revised their It is. Visual Smalltalk Enterprise is the successor to Smalltalk/V. > Smalltalk system for Dos/Windoze. My biggest problem with that was that > their documentation and browser capabilities weren't upgraded along with > the change, and I found it very difficult to make the change from the > early ST/V-dos methods, similar to current Squeak, to the new scheme. It is hard in the sense that it forces you to think differently about objects. Objects are not pulled for information anymore but can push information too (via events). It really makes objects much easier to use. There is no need for fixed protocols anymore and it easy to plug into existing applications/objects. I think a lot of people still associate events with a user interface but that is not the case with the VSE event approach. Each object can trigger an event, i.e. business objects, data objects, GUI objects etc. A nice example is the event #dataAvailable which is triggered by a database object when the results of a query are available. In response to that a window could be opened. In fact, the whole event mechanism makes for a loose coupling of objects and reflects much more the real world (i.e. events lead to responses in the real world, events may affect multiple objects at once and they allow asynchronous messaging). > I hasten > to add that I was working full time in C/C++, and trying to port my stuff Done that for 5 years too. Was even busy writing a Dutch book on C++ in that time until I realized that it was bad to teach other people C++. > from ST/V-mac to the second version of it in my spare time -- and my brain > exhausts after a while -- playing a game becomes more attractive that > trying to climb back on that learning curve... Sounds familair. Most of the time the problems are processed in the background while playing games. > Hmmm... I have the glimmer of a project idea -- an ApplicationBrowser that > lets one browse the responses to various #changed: messages in an > application... Does such a browser already exist? I recall adding (in > ST/Vdos) the ability to click on a window and open an inspector on the > associated TopPane/View - which provides access to the Model, etc. > That's a start.... A list pane in VSE works like that. When a list pane is first shown (and the list was not set yet), it triggers an event named #needsContents. If no one responds to it, the list pane shows an empty list. Whenever an item is selected in the list pane an event #changed: is triggered. When an item is double clicked the event #doubleClicked: with the item as argument is triggered. When the list pane needs the string for an item it triggers the event #needsStringFor: with the item as argument. So, lets put a Date and a Time instance into an array called theList and suppose we have a list pane called theListPane. Then we can code the following: theListPane when: #needsContents send: #setList: to: theListPane with: theList; when: #changed: send: #select: to: someModel; when: #doubleClicked: send: #inspect: to: someModel; when: #needsStringFor: send: #niceStringFor: to: someModel. In this case someModel provides 3 methods: select:, inspect: and niceStringFor: which could have been implemented like this: Model>>inspect: anObject anObject inspect. Model>>select: anObject selection := anObject Model>>niceStringFor: anObject anObject isDate ifTrue: [ ^anObject year asString , anObject month asString, anObject day asString ]. ^anObject asString I think Squeak Fabrik is a graphical way of specifying event->message relationships between objects. Dolphin Smalltalk does the same in a method called createSchematicWiring, i.e. create the wiring between objects. It really is much more like hardware where a chip generates a signal on a certain pin. The chip doesn't know/care if something is attached to that pin. It just knows WHEN to generate the signal. The effect is defined by the clients. Hope this helps a bit. I think this approach comes closer to Alan's Dynabook vision. I mean we are still left with sequential processing although the original idea was not like that at all (the real world isn't sequential or is it just that fast that we don't notice it is sequential? ;-) Groetjes, Reinier.

1 0

Re: Pluggability
by Sabine van Loon 28 May '98

28 May '98

Tom you wrote: [snip] > Before alot more pluggable this and thats are made, > I was wondering if it is worthwhile to consider changing the idiom, to instead > pass in a block to evaluate as the standard way of doing pluggability? I am not a fan of using the #symbol approach for pluggability. A block would be better but is still limited. Although I am biased (because I am using it) I think VSE event approach is much better. In this approach each class defines the events its instances can generate and let the client of such an instance determine what to do when it happens. Suppose you have a Order class which defines the following events: #newOrderLine: (generated when a new order line is added to the order, the parameter is the order line), #delivered (generated when the status is changed to delivered). A client can then register interest in these events like this: someOrder when: #newOrderLine: send: #updateTotal to: someWindow. someOrder when: #delivered send: #add: to: deliveredOrders with: someOrder. someOrder when: #delivered send: #message: to: MessageBox with: 'Order delivered'. As you see, the messages #when:send:to: and #when:send:to:with: are used to register the interest. In this case the parameter of #newOrderLine: is passed as the first parameter of #updateTotal:. This is builtin-in functionality. Furthermore, you can have multiple event handlers for an event (2x #delivered) You could argue that this is a variant to the #symbol mechanism but it is more powerful than that. I am even planning on extending the compiler to recognize 'event' as a keyword (like super) for triggering an event. There's no real need for that of course but it keeps me from typing 'self triggerEvent" #delivered'). BTW Somebody already made a change set for working like this. > There are pluses and minuses to doing this, here is my list (with some > schizophrenic comments about my own list) > > Blocks to evaluate are a good thing > ----------------------------------- > > -There may be no need to make a method to handle the pluggablity > action, you can do what you need right in the block. It's a plus that you don't have to make a method. > > -(For pluggable actions that need to be fast) it is easier to > imagine tuning up methods that have real 'static' sends in the > pluggable block, rather than some scheme that makes 'perform' > run fast. > > Objection: most pluggable things don't need to > be fast. > Yeah but: the pluggable action inside of things > like sliders and drag 'n drop would > benefit from being fast. I hope the 'event' keyword implementation is faster than an ordinary send. [snip] > -It would be easy and 'thin' to provide an interface that accepted > the #symbol kind of pluggablity, by simply sticking the > symbol in a block to evaluate and passing that to the block > argument interface. True. [snip] > -(This is a pretty opaque argument). Using a block is a better > match of the moment in time when you know something to the > moment in time you want to use what you know. That is, > 'performing' something is a good match, when you don't know > at the calling point what you want until just the instant before you > do the perform; the passed in block matches the fact that > you know what you want to do at the time that you write the > method which calls for the opening of the pluggable action. > > Objection: What did you just say? True ;-)) > > Blocks to evaluate are a bad thing > ---------------------------------- > > -Anonymous chunks of code are scary and hard to debug. Very true. > > -The blocks will be hard to track down and revise, in the > event they need to be changed; it is better to insist that > they be in named methods Agree. Cheers, Reinier.

2 1

Pluggability
by Tom Morgan 28 May '98

28 May '98

I was rummaging around in the Morphic stuff, and it is plain that there is going to be lots more pluggability in the interfaces. The current Smalltalk idiom for such things is to specify a #symbol to perform the plugged in action. Before alot more pluggable this and thats are made, I was wondering if it is worthwhile to consider changing the idiom, to instead pass in a block to evaluate as the standard way of doing pluggability? There are pluses and minuses to doing this, here is my list (with some schizophrenic comments about my own list) Blocks to evaluate are a good thing ----------------------------------- -There may be no need to make a method to handle the pluggablity action, you can do what you need right in the block. -(For pluggable actions that need to be fast) it is easier to imagine tuning up methods that have real 'static' sends in the pluggable block, rather than some scheme that makes 'perform' run fast. Objection: most pluggable things don't need to be fast. Yeah but: the pluggable action inside of things like sliders and drag 'n drop would benefit from being fast. -It would easier to capture other data to pass into the pluggable block. The slider is an example, where the pluggable #symbol can be provided with a user defined argument array, in addition to the standard slider supplied argument. -It would be easy and 'thin' to provide an interface that accepted the #symbol kind of pluggablity, by simply sticking the symbol in a block to evaluate and passing that to the block argument interface. -This would be familiar to the Java crowd. (Don't throw rotten fruit at me, please) -(This is a pretty opaque argument). Using a block is a better match of the moment in time when you know something to the moment in time you want to use what you know. That is, 'performing' something is a good match, when you don't know at the calling point what you want until just the instant before you do the perform; the passed in block matches the fact that you know what you want to do at the time that you write the method which calls for the opening of the pluggable action. Objection: What did you just say? Blocks to evaluate are a bad thing ---------------------------------- -Anonymous chunks of code are scary and hard to debug. -The blocks will be hard to track down and revise, in the event they need to be changed; it is better to insist that they be in named methods Comments? -- +---Tom Morgan ------------------------------ (tmorgan(a)acm.org) -----+ I Brooklyn Union Phone: 1 718 403 2427 I I 1 MetroTech Center Fax: 1 718 488 1752 I +---Brooklyn, New York 11201 USA ------------------------------------+

4 3

Re: Squeak 2.0 trouble? (on Mac)
by nishis＠urban.ne.jp 28 May '98

28 May '98

I've tried re-download more 3 times and get collect source, changes, image, VM. Thank to Mr. Raab for the advice. Well, I've ported some AOKI goodies for VisualWorks to Squeak (sorry, only 1.31 supported now). (including Bit Field, Encyclopedia, Histogram, HTML Report Writer, Lisp, Source Code Saver etc) Now I'd like to update them for 2.0. regards At 01:16 05/27/1998 +0900, NISHIHARA Satoshi wrote: >After downloading, plain vanilla setting, >my browser missed first character of some methods of >some classes... ------------------------------------------- 西原聡士 (NISHIHARA Satoshi) e-mail: nishis(a)urban.ne.jp : tcc00164(a)niftyserve.or.jp URL: http://www.urban.ne.jp/home/nishis/ -------------------------------------------

1 0

Squeak Team Plans...
by Dan Ingalls 28 May '98

28 May '98

I thought it would be useful for you to know some of our near- and far-term plans. Beginning around June 4, we're going to hunker down and focus on some of our internal work. For probably a month, then, you can expect fewer updates and fewer messages from us. I haven't really figured this one out, though. We might keep putting out updates, but batched up in large groups. I just have to figure a scheme that doesn't take up a lot of our time. Until that time, though, we will continue to clean up and publish updates for the 2.0 release. Here is a rough outline of where this activity will center over the next week: Improve the convenience and effectiveness of removing parts of Squeak. Hopefully this will culminate in a simple 'majorShrink' that will produce an up-to-date image for WinCE and palm-top machines Our goal of the past has been full development in a 1MB image, and a usble subset that runs (with VM and free sapce) in a 1MB partition. Rework the mouseOver logic in Morphic to reduce overhead, and eliminate quirks like multiple active scrollbars. Release a couple of goodies that didn't make it into the release Morphic support for translucency (Michael Stevens), and Show-invisible-characters mode (Reinier van Loon) Make it easier to import fonts, images, and active morphs from remote archives via the fileList. - Dan

3 3

Quick CAM QV-300 conversion to JPEG
by Alejandro F. Reimondo 28 May '98

28 May '98

I've implemented CASIO's QV-300 file format reader and conversor to JPEG for Squeak an Visual Smalltalk. You can download it from http://www.sugarWeb.com/Miniatures/downloads.html Ale. He implementado la lectura de archivos de la camara digital de casio y su conversion a formato JPEG; para Squeak y Visual Smalltalk. Pueden bajarselo de la pagina de miniaturas SUGAR en http://www.sugarWeb.com/Miniatures/miniatures.htm Ale.

1 0

RE: Squeak 2.0 mirrored at CREATE
by stp＠limbo.create.ucsb.edu 28 May '98

28 May '98

>> Thanks 10**6 to Dan, Ted, John, Scott, Alan, et al! > [Kevin] I guess in order to be anally and Squeakly correct :) > it should be: > Thanks 10 raisedTo: 6 to Dan, ... Yup--I guess my FORTRAN heritage is showing... stp _ Stephen Travis Pope _ Center for Research in Electronic Art Technology (CREATE) _ Dept. of Music, Univ. of California, Santa Barbara (UCSB) _ stp(a)create.ucsb.edu, http://www.create.ucsb.edu/~stp/

1 0

RE: Squeak API support
by Alejandro F. Reimondo 27 May '98

27 May '98

>Hi Ale, Hi! >I am using your sqAPI2.0.exe file, and when I run your test examples, > some of them crash the VM, giving me a crash dump as below. Me too! :^( But it work ok during debug ! (I am using Microsoft Developer Studio for C++ version 4.0) mmmm I love Smalltalk. And hate C and compilers and compilation modes. Can any squeaker help us? Are there any special consideration to compile the VM under Win32 platform? Ale. This example runs just fine: KernelDLL current beep: 500 for: 3000 While this one: KernelDLL current sleep: 5000 crashes the VM. Any suggestions as to what I have done wrong? Mike --------------------------------------------------------------------- Wed May 27 11:38:38 1998 Current byte code: 224 Primitive index: 242 Stack dump follows: 20548116 UndefinedObject>DoIt 20532528 Compiler>evaluate:in:to:notifying:ifFail: 20533072 ParagraphEditor>evaluateSelection 20532996 ParagraphEditor>doIt 20532452 StringHolder>perform:orSendTo: 20532340 FileList>perform:orSendTo: 20531204 PluggableTextController>yellowButtonActivity 20531128 ParagraphEditor>processYellowButton 20531052 ParagraphEditor>processMouseButtons 20530956 ParagraphEditor>controlActivity 20529648 Controller>controlLoop 20529572 Controller>startUp 20529484 Controller>controlToNextLevel 20529408 Controller>controlActivity 20529332 MouseMenuController>controlActivity 20529256 StandardSystemController>controlActivity 20528980 Controller>controlLoop 20527784 Controller>startUp 20527528 [] in ControlManager>activeController: 20527604 [] in BlockContext>newProcess

1 0

Itsy Pocket Computing Project
by Tim Olson 27 May '98

27 May '98

Hey, folks, wonder if someone can get Squeak running on this: http://www.research.digital.com/wrl/itsy/ Looks like its goals of open hardware/software for handheld systems might mesh nicely with Squeak directions. -- tim

5 5

← Newer
1
2
3
4
5
6
7
...
19
Older →

Jump to page: