Squeak-dev February 1998

squeak-dev@lists.squeakfoundation.org

110 participants
320 discussions

RE: Interfaces
by Alejandro F. Reimondo 04 Feb '98

04 Feb '98

Matthijs van Kempen wrote: AR> Do you know the time you invert in interfaces (defining, mantaining) ? MvK>NO AR> Are they usefull for you?... or for your compiler. :-| AR> Are they for people or only for the compiler (or the component technology)? MvK>Not direcly, but they are not that different from the categories we already have. Interfaces consume much more time than categories, because they have more information. Categories are "objects" that help humans, they are not used by object message sending mechanism. They only help in seen the messages (by category). MvK>I agree that objects can be more powerful, but I think a class hierarchy alone could not offer the ease of use needed for rapidly building apps. Yes, it do. I have written apps rapidly during last 10 years. How much rapidly can be with interfaces? Most of the time "the bugs" in Smalltalk does not occur in protocol mismatch (provably because you live with the objects all the time), and when it occurs, is because your objects are evolving/mutating, and it is a great thing in an environment, if it can be immediate (at the speed of thinking). MvK>I'm thinking more along the lines of Morphs encapsulated with all the code they need. Make them distributable and you have something magnificent. MvK>You could even transfrom a Bookmorph into a real compound document that could travel over the net. MvK>Say something?! Very interesting. Affect them with dynamic interfaces, but not to all objects of our world. :-) If interfaces are normal objects, objects can negotiate dynamically the way to talk! and what they need to work properly. (container support: plugIn interface) ifTrue: [ container meet: plugIn ]. Cheers, Ale. Alejandro F. Reimondo Feel free to visit Smalltalk User Group of Argentina (SUGAR) at http://www.sugarWeb.com

1 0

RE: Interfaces
by Matthijs van Kempen 04 Feb '98

04 Feb '98

> Experiment with all you want to. But it must be an object. > > Interfaces can be interesting if they can be defined/refined dynamically. > Consider the diferences between development in a language and in an environment. If you use only a language (not an evolutive environment) you MUST have a mechanism to detect potential errors during > Java and C++ must have interfaces because they have types, are static (no real meta-programming during runtime), and programmers are pasive most of the time (no interaction with real objects). > In evolutive systems (like Smalltalk) interfaces can be a waste of time. :-) > > Do you know the time you invert in interfaces (defining, mantaining) ? NO > Are they usefull for you?... or for your compiler. :-| > Are they for people or only for the compiler (or the component technology)? Not direcly, but they are not that different from the categories we already have. > I think, that interfaces can be interesting if they are "normal" objects and have all the properties of anObject (dynamic, meta-programable, changeable during runtime, etc.). > All the things that are not present in Java nor COM. :-) > > Components are not the same as objects. > The diference is not the size, the information hiddin, etc... > The diference is that components are most of the time static pluggable parts. > When created they MUST: > 1.- conforms its interface (to be pluggable). > 2.- do it's work (components are task oriented entities) > in this order. And they are created to do a piece of work. That's what I like about components. They harbor all they things they are used for, including the GUI, in one thing. > But objects... > Objects are more natural things. They are imperfect, they evolve, mutates. > Objects are things that has been born to change. > When created they MUST: > 1.- provide a medium to learn. > 2.- be. (and all that it means) > 3.- live. (do all the work it want to in the current medium) > 4.- evolve. > > Interfaces are a power mechanism to components. Exactly. I agree that objects can be more powerful, but I think a class hierarchy alone could not offer the ease of use needed for rapidly building apps. I'm thinking more along the lines of Morphs encapsulated with all the code they need. Make them distributable and you have something magnificent. You could even transfrom a Bookmorph into a real compound document that could travel over the net. Say something?! Matthijs van Kempen

1 0

Re: Float>>raisedTo and Float>>ln
by Tim Olson 04 Feb '98

04 Feb '98

>"Hamish \(DP\) Harvey" <dh4180(a)bristol.ac.uk> wrote: >>> Any comments would be of interest. Is there any reason not to do this? >>> Does it reduce portability? Is there another way to define raisedTo: such >>> and ln such that they either work or throw and error, rather then >>> surreptitiously returning garbage? Bruce Cohen replied: >Well, from the narrow point of view of making the existing design work, >this is reasonable. But I would argue that NaN is not garbage, but a >portable way to show numeric errors, since its part of the IEEE Floating >Point standard, which ought to be available on all platforms. I know, >it's not available (or properly implemented) everywhere, but it seems to >me that if we're trying interested in making it easier to use Squeak for >a wide range of applications, including those that do heavy-duty numeric >computation, that we ought to upgrade the design to meet the standard, >which wasn't complete when Smalltalk-80 was designed. I ran into the problems that Hamish did as well, awhile back. It turns out that not only NaN's, but Inf's and denormalized numbers have problems in Squeak, as well. My solution was to extend Squeak to handle these special values, so that any of these values returned from a primitive would be propagated and handled correctly within Squeak. I don't think that these fixes affect systems that don't implement IEEE-754 (any out there, now?) See enclosed change-set for details. -- tim Attachment converted: Cog:Float Fixes.cs (TEXT/R*ch) (0000B47C)

1 0

Re: Double-clickable app proposal
by Ian Piumarta 03 Feb '98

03 Feb '98

> Though I don't know all the details, I'm pretty sure that Python creates > double-clickable apps in just this way. I remember a command in Python > called "freeze" that would "pickle" (serialize) the state of a set of > Python objects and concatenate it on the end of an executable (or maybe > just prepare it to be compiled into an executable -- I'm fuzzy on the > details) to create a standalone application file. Might this be related to the gnu "undump" (I think that's what it's called, but it's all part of my ancient history ;) facility? This is used, for example, to bootstrap Emacs. Emacs starts life as an "empty" (glorified) lisp interpreter into which a whole bunch of lisp is loaded to define the basic editing functionality. The bootstrap then calls "undump" which writes something (almost but not quite entirely un)like a "core" file -- except that this "core" file has the rather interesting property that it can be rerun like a regular program, and it continues execution from an arbitrary function (specified at dump time). Can you say "snapshot for Unix binaries"? ;) The only problem with adapting this for use with Squeak (in Unix) would be restoring the X display state, but I'm not sure that it would be too difficult. The net effect would be that the entire running process (VM plus the entire state of the object memory) is saved as a binary image than can be started "in one" like a monolithic application (with no separate image file -- although issuing a snapshot from the UI would still create a regular snapshot from such a restarted "frozen" process). I've used precisely this technique in the (distant) past in lisp systems, for making executable "snapshots" that include the lisp VM and an initialised heap all in the same binary file, and it works rather well. Note that I'm *not* advocating this approach for Squeak -- it's far more adapted to the kinds of system (like Emacs and similar lispy things) that bootstrap themselves by loading a significant amount of low-level code just in order to get into a usable/useful state (because this would be an unacceptable overhead if it were necessary each time the program started). I think that simply saving an "interpreter name" in the start of the image (as "#!SqueakVM", for example) is a *far* better approach. (I won't [and indeed couldn't] try to speak for any other architecture on this topic.) Ian

1 0

Re: Converting from Sequential to Sampled Sounds?
by Boris G. Chr. Shingarov 03 Feb '98

03 Feb '98

Mark, > Is there a path from Sequential to Sampled Sounds? Do you mean interpreting MIDI into u-law wavesamples? If this is what you mean, I think Squeak is the ideal tool. One basic algorithm is implemented in TiMidity (the C source can be found at http://www.clinet.fi/~toivonen/timidity/ ); however I remember some discussion about wavelets in Squeak so we can do much more powerful things in Squeak that TiMidity does (not sure if not already). Boris

1 0

RE: Interfaces
by Alejandro F. Reimondo 03 Feb '98

03 Feb '98

Experiment with all you want to. But it must be an object. Interfaces can be interesting if they can be defined/refined dynamically. Consider the diferences between development in a language and in an environment. If you use only a language (not an evolutive environment) you MUST have a mechanism to detect potential errors during compilation. Java and C++ must have interfaces because they have types, are static (no real meta-programming during runtime), and programmers are pasive most of the time (no interaction with real objects). In evolutive systems (like Smalltalk) interfaces can be a waste of time. :-) Do you know the time you invert in interfaces (defining, mantaining) ? Are they usefull for you?... or for your compiler. :-| Are they for people or only for the compiler (or the component technology)? I think, that interfaces can be interesting if they are "normal" objects and have all the properties of anObject (dynamic, meta-programable, changeable during runtime, etc.). All the things that are not present in Java nor COM. :-) Components are not the same as objects. The diference is not the size, the information hiddin, etc... The diference is that components are most of the time static pluggable parts. When created they MUST: 1.- conforms its interface (to be pluggable). 2.- do it's work (components are task oriented entities) in this order. And they are created to do a piece of work. But objects... Objects are more natural things. They are imperfect, they evolve, mutates. Objects are things that has been born to change. When created they MUST: 1.- provide a medium to learn. 2.- be. (and all that it means) 3.- live. (do all the work it want to in the current medium) 4.- evolve. Interfaces are a power mechanism to components. Component tecnology is technology of the '80, modula, ada, C++, Java (Component technology = Object Oriented Technology). They need interfaces to plug components. The technology for the year 2000+, is Object Technology and is funded primary in change and evolution. Object Oriented Technology ~~ Object Technology Think in the word "oriented", what it means? I think that ObjectOrientedTechnology = Component Technology with an "O" If you use OOT then you will need interfaces. If you use Smalltalk to write "OOT programs", you will need interfaces. But if you use Smalltalk to build "Object systems" provably you will not be interested in specify how an object talk. Ale. ---------- Desde: Matthijs van Kempen Enviado el: Martes 3 de Febrero de 1998 21:24 Para: squeak(a)cs.uiuc.edu Asunto: Interfaces Hi Folks, How does the notion of interfaces sound? Interfaces are used in Java and in COM objects. They expose a set of properties (getters/setters) and methods. One component or object can have mutliple interfaces. Interfaces can inheri from each other. Say something?! Matthijs van Kempen

1 0

Re: #\\ with negative arguments and receivers
by Tim Olson 03 Feb '98

03 Feb '98

Leando wrote: >IMO, the method SmallInteger>>\\ is not working properly with negative >arguments and receivers. For instance, when evaluating -1 \\ -2 one >obtains -3 instead of -1 (or 1). Note that this behavior contradicts both >the mathematical definition and the current implementation of Number>>\\. Yes; this was one of the numeric primitive bugs in the VM that I noted awhile back, but it looks like the fix for it somehow slipped through the cracks. Here's the changeset for the fix again. Note that the VM will have to be recompiled to fix this. -- tim Attachment converted: Cog:Numeric Primitive Fixes.cs (TEXT/R*ch) (0000B200)

9 11

Re: Difference between views, viewports, forms, canvases and windows
by Tim Olson 03 Feb '98

03 Feb '98

>The difference between views, viewports, forms, canvases, and windows is not >too clear in my mind and the Squeak online documentation does not make it >clearer. Could someone please enlighten me on the matter? > >Would you use a view, a viewport, a form, a canvas, or a window, if you >simply >wanted to draw a shape in a window (separate from the Workspace) using a Pen? Definition Summary: --- MVC architecture --- Form: basic display medium View: structured picture that can contain other views part of "Model, View, Control" (MVC) architecture. viewport: not a basic object; it is the rectangle of a subview in the superview's coordinate system. window: not a basic object; it is the rectangle of a view in its coordinate system. --- Morphic Architecture --- Canvas: part of the new Morphic display architecture; FormCanvas is used as the background on which to draw Morphs. Morphic is a newer display architecture which will slowly replace the older MVC architecture in Squeak. In the MVC display architecture, the basic display medium is a Form, which can be used as a source or destination for displaying on other Forms using a BitBlt object. The DisplayScreen "Display" is a kind of form, so you can draw directly on it like you can any other form: | pen | pen := Pen newOnForm: Display. pen defaultNib: 4. 1 to: 50 do: [:i | pen go: i*4. pen turn: 89]. will draw a black spiral in the center of the Display. Note that since you are drawing directly to the display, it draws over any existing views ("windows"), and will be erased as views are moved over it. You can draw the spiral on another form to "retain it", then draw that form on the Display: | form pen | form := Form extent: 300@300 depth: Display depth. form fillColor: Color green. pen := Pen newOnForm: form. pen defaultNib: 4. 1 to: 50 do: [:i | pen go: i*4. pen turn: 89]. form display. form displayAt: Display center - form center. Here the pen draws on the form, which in turn is then drawn on the Display at two locations. However, this is still drawing directly to the display, so it again draws over existing views and will be erased as views are moved over it. To put the form in its own "window" (view) that interacts correctly with the other system views, you need to use the View classes. a View is a structured picture which can contain subviews, and is part of the "Model, View, Control" (MVC) architecture. Here we will put our form in a FormView (which knows how to display forms, and can edit them as well), and add the FormView as a subview of a ColorSystemView (which adds the standard title bar, close and grow boxes, and other standard window controls): | form pen view topView | form := Form extent: 300@300 depth: Display depth. form fillColor: Color green. pen := Pen newOnForm: form. pen defaultNib: 4. 1 to: 50 do: [:i | pen go: i*4. pen turn: 89]. view := FormView new. view model: form. view borderWidth: 2. topView := ColorSystemView new. topView model: form. "to set the correct window size" topView addSubView: view. topView controller open. Now the picture can be moved, resized, edited, etc. -- tim

1 0

Converting from Sequential to Sampled Sounds?
by guzdial＠cc.gatech.edu 03 Feb '98

03 Feb '98

Is there a path from Sequential to Sampled Sounds? I imagine that it's doable but hard (go from a specification of a sound sequence to simulating the sampling of that playing) -- I'm polling to see if anyone has already done it. I'm interested in producing a u-law (Web-playable) sound from a specification of a tune. Thanks! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

1 0

Re: Double-clickable app proposal
by guzdial＠cc.gatech.edu 03 Feb '98

03 Feb '98

>I just don't see this as something that can be portable. Don't get me >wrong. I really like applications with an easy launching technique >that don't leave files splattered all over the place. I just see more >headaches than are saved. All of a sudden, we need to use intimate >knowledge of platform specific binary formats. This runs at top speed >away from portability. Is this a win? Couldn't this be done instead >with some script mechanism avoiding the proprietary specifics? Though I don't know all the details, I'm pretty sure that Python creates double-clickable apps in just this way. I remember a command in Python called "freeze" that would "pickle" (serialize) the state of a set of Python objects and concatenate it on the end of an executable (or maybe just prepare it to be compiled into an executable -- I'm fuzzy on the details) to create a standalone application file. A 10 minute search in the Python docs at http://www.python.org didn't turn up the details, though. Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

1 0

Jump to page: