Squeak-dev February 2000

squeak-dev@lists.squeakfoundation.org

163 participants
655 discussions

Re: Generating source code from Morphs [was: RE: More Widgets for Squ eak....]
by Chris Reuter 02 Feb '00

02 Feb '00

On Tue, Feb 01, 2000 at 12:49:17PM -0500, Norton, Chris wrote: > Hi Lex & Company. > > On February 01, 2000, Lex Spoon [lex(a)cc.gatech.edu] wrote: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Sort of. Morphic is nice in that you can drag things around and embed them > in each other. Using this facility plus inspectors, you can create an > arbitrary window this way. It pretty much has the feel of a GUI builder, > except there is no way to generate code to recreate the thing." > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > You know, I have often wished that this mechanism were more robust, as it is > much easier to drag-n-drop widgets together than it is to wire them up the > old fashioned way. Perhaps the top level morph should have a standard > selector that can generate a method definition that can later be used to > rebuild the whole thing programmatically. Thus you could hook morphs > together, embed them into a SystemWindow or playfield and then ask the > SystemWindow to generate code that can reproduce the whole mess... I > suppose the first thing to do is to implement Morph>>asSourceCode. Or > something like it. I've written something along those lines already. I've got a collection of about 10 morphs that support a common protocol to create source code that recreates the layout. They're also fully pluggable and provide a simple API so that you can use them without having to understand their internals. I'm in the process of cleaning up the code right now. I was planning on releasing it in a couple of weeks, but if anyone's interested in playing with what I have now, send me email. --Chris

1 0

Re: Type Safety (was Re: fun and empowerment)
by Richard A. O'Keefe 02 Feb '00

02 Feb '00

That's not a Squeak problem except that your sources or changes file is munged - probably because you're on a Mac and UnStuffIt/StuffIt Expander did you the "favor" of converting line endings, thus disrupting the offsets into the file Squeak uses to fetch the source of methods. This is the MFAQ for new Squeak users, and a frequent topic on this list. Please don't cosider it a weakness of the language - any language's source files can be damaged. Of course it isn't a weakness of the Smalltalk language, but it *is* a weakness of the Squeak implementation that things can go this wrong with a key file without the system noticing. In previous messages I reported some timing tests I did which showed that checksumming key files need not be a performance problem; least of all is this so during installation! If the standard installation process on a Mac (download the file, click on what you get and let it unpack itself) doesn't work, what _should_ I do to get a working current Squeak?

2 1

Re: Perl open source contest
by Lex Spoon 02 Feb '00

02 Feb '00

"Michael Chean" <Michael_Chean(a)email.msn.com> wrote: > I received this message from the Bruce Eckels mail list Is this sort of > thing done for Small talk, or any language as long as its open source? > > The Department of Energy has awarded a grant of US $860,000 > to spend over the next two years on development of > easier-to-use software engineering tools for computational > scientists and engineers. All of the work will be Open > Source, in Python, and have a strong emphasis on design, > testing, and documentation. For details, see: > http://www.software-carpentry.com FWIW, Python is basically Smalltalk without the GUI. Garbage collections, first-class class objects, and no static typing to get in the way. I'm not sure whether it has any anonymous function objects akin to Smalltalk blocks. It also has a library comparable to Perl's. In fact, there's no real need for Perl nowadays, except that people are ignorant of Python. It's a pretty good open-source programming system. In fact, if anyone is thinking about what kind of documentation Squeak might be able to use, looking at the python web site would be a good idea. They seem to really have a lot of good, well-organized stuff out there. www.python.org. Just in case anyone has extra time for that sort of thing :) So anyway, I wonder what they do with all that grant money? Perhaps they're going to spend all that grant money developping a GUI :| I wonder what cool stuff Guido van Rossum might have been able to do, if he had had an open-source Smalltalk to work with instead of doing Python as a new language from scratch.... Lex

2 1

Re: Standard Squeak Font Encodings
by Richard A. O'Keefe 02 Feb '00

02 Feb '00

At any rate, some decisions should be made as to a Squeak standard repertoire and encoding, so that new fonts can be used seamlessly and without compromising existing code (or identifying where changes might need to be made). Where shall we put the "replaced" glyphs? Shouldn't we place a Euro symbol in all of our fonts? The obvious thing to do with the Euro is what Latin-0 does; junk the "generic currency" symbol and put the Euro in its place. That's 16rDB in the MacRoman character set, if I'm reading it correctly.

1 0

Re: Generating source code from Morphs
by Duane Maxwell 02 Feb '00

02 Feb '00

>Take a look at how OpenDoc did its thing. THere's a more efficient OOP >container available called "IronDoc," done by the guy who was maintaining >the Bento container for Apple when OpenDoc was still going. > >It should be possible to use the OD strategy to handle the saving of both >Squeak morphics and non-Squeak compound documents, via IronDoc. Unfortunately, the developer of IronDoc (Dave McCusker) stopped working on it for a while, over a year, and has only recently popped back up. His latest thing is an alternative language called "Mithril" with multiple syntaxes, but the project's pretty embroyonic. I would suspect that IronDoc isn't stable enough for anything but idle curiousity - McCusker himself labels it "vaporware". See: http://www.best.com/~mccusker/irondoc/irondoc.htm It also has a rather amusing approach to web navigation. -- Duane =================================================== Duane Maxwell dmaxwell (at) entrypoint.com CTO http://www.entrypoint.com EntryPoint, Inc. (858)348-3040 FAX(858)348-3100 Information contained herein is my personal opinion and not necessarily that of EntryPoint. ===================================================

1 0

Squeak regions (Was Re: Irregularly shaped main window
by Lawson English 02 Feb '00

02 Feb '00

On Tue, Feb 1, 2000 10:34 AM, Lex Spoon <lex(a)cc.gatech.edu> wrote: >It's doable on Unix as well. So the big three are covered. We just >need a primitive to specify where the shape bitmap is. > >Lex Has anyone looked at implementing the QuickDraw region algorithm in Squeak? The patent has *certainly* run out since it has been more than 15 years since the Mac was introduced. I'm willing to bet that QD regions are STILL the most efficient and fastest way to describe an irregular region, and it would likely speed up Squeak graphics by a good bit to use the algorithm as a primitive, which is no longer covered by any patent, AFAIK. ------------------------------------------------------------------------- Lawson English. Squeak, snore, etc. Check out <http://www.squeak.org> -------------------------------------------------------------------------

2 1

"explain" in code panes now broken in 2.8a
by merlyn＠stonehenge.com 02 Feb '00

02 Feb '00

No matter what I try to 'explain' in a code pane, I get a debugger walkback. I don't know how far back they were still working, but something has certainly gone awry. I also think "explain" should be on a key, as long as you're fiddling to make it work. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

1 0

Re: Type Safety (was Re: fun and empowerment)
by Richard A. O'Keefe 02 Feb '00

02 Feb '00

On Sat, Jan 29, 2000 at 02:21:04PM -0500, David N. Smith IBM" wrote: restrictions. For example, if a processor has 32-bit registers and a the compiler implements a 16-bit short type, the compiler has to make sure that the results of short arithmetic are truncated down to 16 bits after each arithmetic operation. False, and false for two reasons. First, the C standards (K&R 1, C89, C99) all specify that short-than-int operands are widened to int; this means that on a machine that has 32-bit registers and no 16-bit multiply, divide, or compare, any sane compiler writer will rule that int=32 bits and do the arithmetic in the 32-bit registers as 32-bit numbers. Similarly, on a 64-bit machine, your 16-bit numbers will be added, subtracted, multiplied, and so on as SIXTY-FOUR BIT numbers. Suppose for example that 'short' is 16 bits and 'int' is 32 bits, and that the C system reports signed integer overflow by raising an exception (which the standards very carefully allow, and which some C systems in fact d0), then short x = 1000, y = 1001, d = 10; short c = (x/d)*(y*10) > x*y; *must* be computed correctly; not only is it not the case that the compiler must truncate, but it must NOT truncate! Second, suppose a C compiler writer were sufficiently loopy to impose int=16 bits on a 32-bit machine. The "as if" rule applies. The ISO standards make it clear that a C system doesn't have to do literally what you see, only something that gives the same answers. So on a machine where there are addition and subtraction instructions that don't trap on overflow, any amount of arithmetic involving +, -, ~, &, |, and << can be done without adding truncation instructions. They would only be needed before *, /, %, >>, and comparisons. If C didn't have types--just had register-sized variables that you could treat however you wanted--the code generated would be more efficient, at least on a mediocre compiler. C *does* have register-size variables. They're called 'unsigned int'. Types are a big win in C because they help the compiler catch stupid but fatal errors (e.g. "foo = NULL;" vs. "*foo=NULL;"). Er, C compilers are notorious for NOT catching that particular problem. The usual definition for NULL is a plain 0 (0 cast to void* was supposed to be legal, but there were dodgy details like (char*)0 being a "null pointer constant" but (char*)(void*)0 NOT being a null pointer constant, so it was much simpler all round to use the normal definition), so char a; char *p = NULL; p = &a; *p = NULL; is correctly allowed by most C compilers. I don't think strong typing should be evaluated in a vacuum. Neither do I, but on any reasonable interpretation of the term "strong typing", C hasn't got it and never has had. To see the merits of strong typing, look at Ada, or Eiffel, or Haskell, or Clean, or Mercury. For a good example of a safe but truly typeless language, try Tcl. In Tcl, everything is a string. This is flexible but the language doesn't "know" the type of anything and so rarely is able to do any of those automatic type-specific things most other languages do (e.g. automatically formatting output in a "correct" manner). This hasn't been true since the release of Tcl 8.0, which was some time ago know. These days, the Tcl system knows perfectly well whether something is a number or a list or whatever; things happen to be strings at the same time. This wasn't done to catch errors, but for the sake of the compiler that was also released in Tcl 8.0. The proof of this can be seen in how strongly-typed languages try to implement this sort of behaviour. (Templates, anyone?) For "strongly-typed languages" read "SOME strongly-typed languages". C++ templates are fairly extreme; Eiffel and Ada do it better. Then there's Haskell, Clean, and Mercury, which use "type classes".

1 0

Re: More Widgets for Squeak....
by JArchibald＠aol.com 02 Feb '00

02 Feb '00

=> 2/1/00 1:31:05 PM EST, harmonra(a)webname.com => << At 05:35 PM 1/31/00 -0500, Dino <deanmao(a)cc.gatech.edu> wrote: >I think MVC is pretty much dead. Everyone uses morphic >[snip] I use MVC exclusively, and Squeak would be reduced in suitability for my use if it were dropped. >> I also have been using MVC exclusively. I am interested in Smalltalk programming. If MVC were dropped, Squeak loses much of its interest for me. I consider Morphic as an interesting new experiment in user interfaces (and several other things, I would guess), but though it is programmed in Smalltalk, I don't see it necessarily as "the" user interface for a future version of Smalltalk. Saying MVC is "pretty much dead" is not a correct assessment of the situation: "a lot of work is going into Morphic -- it is an active topic of research". Though MVC is not an active topic of research, it IS a fairly convenient facility for putting together in a simple and straight-forward manner many experiments using Smalltalk as a language and environment. IMHO, Jerry Archibald

2 1

Re: Process'ing
by Tim Olson 01 Feb '00

01 Feb '00

John Clonts wrote: >I'm expecting the following code to print on the Transcript until i >change the inspected Valueholder to hold false. But nothing at all >shows on the transcript. > >| f | >f := ValueHolder new contents: true. f inspect. >[ [ f contents ] whileTrue: > [ Transcript show: 'working' ;cr ] ] > forkAt: Processor userBackgroundPriority. > > >Can someone explain, or give a snippet that "works"? ( The equivalent >does in VW) > >This doesn't have something to do with the discussion about >BlockContexts' temporaries "real vs squeak" I hope? I saw your query in comp.lang.smalltalk before I saw this, so I responded there. Here's a recap, for those non usenet readers: ---- This code works fine if run in the Morphic environment -- I assume you are trying to run it in the MVC environment. The problem there is that performing the "f inspect" causes an inspector to open, which terminates the current thread of control in the MVC environment (i.e. everything after the "f inspect" in the thread of control is never executed). To see this in gory detail, opening the inspector causes the following method to run: Inspector >> openOn: anObject withEvalPane: withEval withLabel: label valueViewClass: valueViewClass which ends with topView controller open where topView is a StandardSystemView. This causes the controller (a StandardSystemController) to run: open "Create an area on the screen in which the receiver's scheduled view can be displayed. Make it the active view." view resizeInitially. status _ #open. ScheduledControllers scheduleActive: self This causes the ControlManager to run: scheduleActive: aController "Make aController be scheduled as the active controller. Presumably the active scheduling process asked to schedule this controller and that a new process associated this controller takes control. So this is the last act of the active scheduling process." <primitive: 19> "Simulation guard" self scheduleActiveNoTerminate: aController. Processor terminateActive Try running your code in the Morphic environment (do Open... Morphic Project from the root menu and enter the project). ---- -- tim

1 0

Jump to page: