Squeak-dev January 2000

squeak-dev@lists.squeakfoundation.org

131 participants
468 discussions

Re: Type Safety (was Re: fun and empowerment)
by Stephan Rudlof 31 Jan '00

31 Jan '00

Vassili, that's great! I just wanted to write a reply to Lex assert suggestion to say that it would be nice if assert on/off would be considered at compile time and not only at run time. But I thought I had to check the other mails first and now: Thank you! Stephan Vassili Bykov wrote: > > > From: Lex Spoon [mailto:lex@cc.gatech.edu] > > [...] > > For internal checks like you describe, it would be cool if Squeak had a > > global assert: function: > > Here is a "deluxe" version of #assert. It inlines (or omits) assertion code > and recompiles all methods that have inlined assertions once the inline > setting changes. It is similar to the #assert: I wrote for VW a few years > ago, except this time I though making #assert look like a message sent to a > block is a better thing. > > It does not use Preferences as you suggested in your post, just use > "MessageNode inlineAsserts: <aBoolean>". I guess I could have modified > #noteThatFlag:justChangedTo: in Preferences class to give UI access to it > but I hate overriding existing methods in change sets. There is little > choice with MessageNode class>>initialize, of course. > > --Vassili > > ------------------------------------------------------------------------ > Name: Assert.1.cs > Assert.1.cs Type: unspecified type (application/octet-stream) > Encoding: quoted-printable -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: Class comments within .change files are anonymous doits
by Lex Spoon 31 Jan '00

31 Jan '00

One easy way to fix this would be to use ANSI SIF as the standard interchange format, instead of traditional fileouts. SIF makes everything quite explicit. Someone has posted SIF code to this list before; I don't recall the details. Lex Les Tyrrell <tyrrell(a)canis.uiuc.edu> wrote: > > I've been parsing .change and .source files for all publicly available > versions of Squeak, and have noticed something that I think ought to > be corrected for the next release. If possible, I'll try to come > up with a fix before then. It may be very simple, but I've noticed > a few simple changes to the format of these files that have made > it more difficult to handle them, and I'd like to avoid introducing > any other problems. > > Since version 1.30 Class comments have been getting stored in the > change files as though they were doits. To an image, this is not > a problem. But if you are trying to extract information from these > change logs, as I am doing, then you are going to have a bit of trouble > identifying which of those doits are supposed to be class comments, > and if they are class comments, it is possible that there is no > information ( or outdated information ) identifying which class the > comment belongs to. Prior to 1.30, the class comments were stored > in the same format as we find in file-outs, and are easily identified. > > There are a few things I can do to filter some of the comments out- > but what should be an easy task can now only be done with manual > intervention and educated guessing. I would also wonder how it would > be possible to recover the comment after an image crash. > > This problem does not affect the V1 and V2.sources files. > > -les

2 1

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

31 Jan '00

My problem with static type checking is that the types in most languages are not first class. Do not confuse "type checking" with "most languages". Common Lisp has run time type checking, plus optional static type checking, with first-class values that represent types. Type signature information that could potentially be useful to a programmer is thrown away by the compiler. Does Java reflection provide what you want? I also do not like inputting code that doesn't *DO* anything. Types in Ada, Haskell, Clean, and Mercury amongst others are used for overloading. This goes all the way back to Fortran, where types let you write X+1.0 as well as I+1, as opposed to say BCPL, where you had to write X #+ 1.0 to distinguish floating point add (#+) from integer add (+). Ada &c allow user-defined overloading. Writing X: Foo; does do something for you, because it means you can write Bar(X); Ugh(X); instead of Foo_Bar(X); Foo_Ugh(X); What's more, the presence of types in a langauge doesn't mean that you have to write any more code. Take the Haskell function f x = x + 1 The compiler infers the type f : Num a => a -> a all by itself. Static type-checking is not good for rapid prototyping of applications. The Haskell experience is otherwise. The main issue for rapid prototyping is "how much code do you have to design, code, and test", NOT how much of it is type declarations. What's in the library is perhaps the most important thing. Does any sane programmer use Perl or Java because they are good *languages*? Of course not. You use Perl because of the CPAN; you use Java because of its library. Suppose typeful language A requires 20% more lines on average than typefree language B, but language A has 60% of what you need already there in its library and language B only has 30%. Then it's less work to do it in language A. Even (perhaps especially) in rapid prototyping, you had better write useful comments, and they will far out-bulk any type declarations you need in a modern typeful design. Of course, Squeak does well on both measures, except that I don't _know_ what's in the library. It would be very nice to have full documentation.

1 0

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

31 Jan '00

From: Mark Guzdial <guzdial(a)cc.gatech.edu> So, I've taken to asking students (in oral exams, office hours, and the like) what evidence they have that "safe types" buys them anything? ... But this is actually more than me being "pedagogues who look on their profession as an opportunity for pederastic abuse" :-) I'm seriously interested: Does anyone know of any empirical evidence for the value of types? Or is it a myth that we invented to rationalize the typing needed to improve the compiler's performance? Much depends on the programming language. Types don't really buy you much in Pascal, for example. But in Ada they do, thanks to (compile-time) overloading. When I define a generic procedure or package in Ada, I can not only state the type parameters, but what operations they must support. This is in marked distinction to C++: just because the C++ compiler accepts a template class or template function does not mean that there are _any_ legal instantiations of it. In Clean, the type system lets me state uniqueness as well, so I can have efficient I/O and constant-time array update in a pure lazy functional language. There's also the usual Haskell-style type- class stuff (inheritance without objects). Type inference systems such as those in Haskell and Clean let you - document (some of) your intentions - have type-dependent operations - check your code for consistency (not correctness) - find many errors *without* testing without requiring heavyweight type declarations. It is perfectly true that many type errors would be caught by runtime checking, but only *if* the code in question happens to be tested. It's all a matter of how much is checked, when it is checked, and how much it coes to have the checking done. Do NOT take the type systems of Pascal and C++ as models of what a type system can do for you!

1 0

Type Safety (was Re: fun and empowerment)
by Mark Guzdial 30 Jan '00

30 Jan '00

>In the one and only case in my experience in which I advocated using >Smalltalk for a significant project, the "technical" folks on the >project voted the idea down in favor of Java, which they believed to >have advantages in performance, type safety, and market acceptance. >Draw what conclusions you like from this, but don't a priori assume >that "management" is the source of all difficulties. So, I've taken to asking students (in oral exams, office hours, and the like) what evidence they have that "safe types" buys them anything? "The types help the compiler catch errors in the program," they respond. I ask them if the types really do. Do the warnings really point to errors, or just type problems? Are they errors that you would have found easily and quickly without the types? Then there's the cost of types. Casting, declaring types, and fixing code to address warnings takes a good bit of time. Is the cost worth the benefit? But this is actually more than me being "pedagogues who look on their profession as an opportunity for pederastic abuse" :-) I'm seriously interested: Does anyone know of any empirical evidence for the value of types? Or is it a myth that we invented to rationalize the typing needed to improve the compiler's performance? 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

4 4

Re: Type Safety (was Re: fun and empowerment)
by demiourgos＠smalltalk.org 30 Jan '00

30 Jan '00

On Sat, 29 January 2000, Randal L. Schwartz wrote: [snip] > I had a student in my Object Oriented Perl course yesterday tell me > that his employer won't let him use *any* "object oriented" languages, > because they build embedded systems that have to be FAA certified, and > FAA will only certify if you've done a complete call-flow analysis. > > So instead, he has to do all his work in C (!!!!). Gack. Like that's > any better? [snip] I thought FAA was into Ada95? C surely seems like a huge step backwards. --jtg ______________________________________________________ Jan Theodore Galkowski www.smalltalk.org/ http://www.scguild.com/usr/1707I.html demiourgos(a)smalltalk.org www.marssociety.org/ ********************************************** PGP Key Fingerprint: 2757 F86D AA51 677D 38D7 964B 9A8D 7852 A494 3790 ********************************************** Get my Public Key from my home page at: http://home.stny.rr.com/algebraist/ ********************************************** ______________________________________________ Get free e-mail at http://www.britannica.com

1 0

[GOODIE] Re: autoRise (was Re: woohoo! ...)
by Robert Withers 30 Jan '00

30 Jan '00

Torge Husfeldt wrote: > > Hi Robert, > ----- Original Message ----- > From: Robert Withers <withers(a)vnet.net> > To: <squeak(a)cs.uiuc.edu> > Sent: Sunday, January 30, 2000 9:38 AM > Subject: Re: autoRise (was Re: woohoo! It's my first squeak/morphic alpha > code!) > > > Robert Withers wrote: > > > > > > I'm glad you like it. I can't take any credit for the idea; it comes > > > from Linux/XFree86. Let me say that I think the list is the best place > > > for this exchange because someone may take your additions and add their > > > own. I'm not worried about ownership issues; it's all of ours. So > > > it's not less than polite, but rather asynchronous pair programming. > > > > > > Your fixes make a lot of sense. Thanks! I was wondering how to bring > > > this to all Morphic windows, but I'm not familiar enough with the > > > Classes yet. I especially like your #autoRiseOnMouseEntry and your > > > placement of the Register dictionary as a class var in WindowRaiser (we > > > could call it a Necromancer if you wish! :) ). I don't know what I was > > > thinking, putting it in the Smalltalk dictionary. Just hacking, you > > > know? > > > > > > Could you post your changeset, please? I want to build on it. I'd > > > like to figure out how to install a start/stop menu item in the World > > > popup (or preferences). I believe this would require removing the event > > > registrations from the windows that are active > > > (#cancelAutoRiseOnMouseEntry) and setting a class side flag in > > > WindowRaiser to not install the events for new windows. Finally, have > > > #autoRiseOnMouseEntry and #cancelAutoRiseOnMouseEntry defer ot class > > > methods on the WindowRaiser for installation/deinstallation of the > > > events. I also found that I like a 50 millisecond delay or none at > > > all. It's more immediate. > > > > > > > Here's an update. I incorporated most of Stan's recommendations and > > extended a few others so that you can turn it on and off. It defaults > > to off. See the class comment of WindowRaiser, which is now in > > Morphic-Support, for instructions on turning this on and off. I changed > > the delay, and my previous change to 400 milliseconds. It isn't as > > immediate as I would like but it is more forgiving than 50! > > > > I would love to put this into the Preferences, but, first, I wasn't sure > No need to hesitate here! Adding an entry to Preferences that defaults to > false is very easy and polite and IMO the widely agreed way to do it. > Look at the #doesNotUnderstand: in Preferences and you'll see. > You just ask: > Preferences autoRiseWindows > and it answers false. To enable autoRising it suffices to send: > Preferences enable: autoRiseWindows > > how, and second, it's prolly best to let it ripen a bit and see if y'all > > find it useful. I sure do! > On the contrary I think that using the Preferences for this can even help > the overall acceptance of your goodie. (don't forget to include [GOODIE] > in the subject line next time you post it with .cs). Ok, I had to change Preferences class>>noteThatFlag:justChangedTo:, so that I could (de)install all of the event registrations for existing windows. This brings to two the core classes I have modified (Morphic>>openInWorld:) It defaults to disabled. You should go into the preferences window and click on the false next to autoRaiseWindows. Now you can save you're fingers for better things. It is quite a productivity boost. ;-) Thanks again Stan and Torge! Rob > > > > Enjoy! (thanks again Stan!) > > Rob > > > > > > > > -- > > Regards, > Torge. -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one! 'From Squeak2.7 of 5 January 2000 [latest update: #1762] on 30 January 2000 at 12:54:49 pm'! "Change Set: WindowRaiserTool Date: 30 January 2000 Author: Robert Withers Beta: Ok folks. We are into the Preferences now. On load the WindowRaiser installs a preference which defaults to disabled. You have to enable it in help...preferences... Special thanks goes to Stan Heckman, and Torge Husfeldt. Special Warning: This changeset modifies Morph>>#openInWorld: aWorld, which is a core Morphic method. It also modifies Preferences class>>noteThatFlag:justChangedTo:"! Object subclass: #WindowRaiser instanceVariableNames: 'view isRaising ' classVariableNames: 'EventRegister ' poolDictionaries: '' category: 'Morphic-Support'! !Morph methodsFor: 'event handling' stamp: 'rww 1/30/2000 02:14'! autoRiseOnMouseEntry WindowRaiser installOnMorph: self. ! ! !Morph methodsFor: 'event handling' stamp: 'rww 1/30/2000 02:18'! cancelAutoRiseOnMouseEntry WindowRaiser deinstallOnMorph: self. ! ! !Preferences class methodsFor: 'preferences dictionary' stamp: 'rww 1/30/2000 12:39'! noteThatFlag: prefSymbol justChangedTo: aBoolean "Provides a hook so that a user's toggling of a preference might precipitate some immediate action" | keep | prefSymbol == #useGlobalFlaps ifTrue: [aBoolean ifFalse: "Turning off use of flaps" [keep _ self confirm: 'Do you want to preserve the existing global flaps for future use?'. Utilities globalFlapTabsIfAny do: [:aFlapTab | Utilities removeFlapTab: aFlapTab keepInList: keep. aFlapTab isInWorld ifTrue: [self error: 'Flap problem']]. keep ifFalse: [Utilities clobberFlapTabList]] ifTrue: "Turning on use of flaps" [Smalltalk isMorphic ifTrue: [self currentWorld addGlobalFlaps]]]. prefSymbol == #roundedWindowCorners ifTrue: [World ifNotNil: [World fullRepaintNeeded]]. prefSymbol == #optionalButtons ifTrue: [Utilities replacePartSatisfying: [:el | (el isKindOf: MorphThumbnail) and: [(el morphRepresented isKindOf: SystemWindow) and: [el morphRepresented model isKindOf: FileList]]] inGlobalFlapSatisfying: [:f1 | f1 wording = 'Tools'] with: FileList openAsMorph applyModelExtent]. (prefSymbol == #optionalButtons or: [prefSymbol == #useAnnotationPanes]) ifTrue: [Utilities replaceBrowserInToolsFlap]. (prefSymbol == #smartUpdating) ifTrue: [SystemWindow allSubInstancesDo: [:aWindow | aWindow amendSteppingStatus]]. (prefSymbol == #autoRaiseWindows) ifTrue: ['blah2' print. aBoolean ifTrue: [WindowRaiser startAutoRise] ifFalse: [WindowRaiser stopAutoRise]]! ! !SystemWindow methodsFor: 'open/close' stamp: 'rww 1/30/2000 02:29'! openInWorld: aWorld "This msg and its callees result in the window being activeOnlyOnTop" self autoRiseOnMouseEntry. self bounds: (RealEstateAgent initialFrameFor: self). aWorld addMorph: self. self activate. aWorld startSteppingSubmorphsOf: self! ! !WindowRaiser commentStamp: 'rww 1/30/2000 03:19' prior: 0! To turn on window raising: WindowRaiser startAutoRise. To turn window raising off again: WindowRaiser stopAutoRise.! !WindowRaiser methodsFor: 'accessing' stamp: 'rww 1/30/2000 02:41'! isRaising "Answer the receiver's instance variable isRaising." ^isRaising! ! !WindowRaiser methodsFor: 'accessing' stamp: 'rww 1/30/2000 02:41'! isRaising: aBoolean "Set the receiver's instance variable isRaising to aBoolean." isRaising := aBoolean! ! !WindowRaiser methodsFor: 'accessing' stamp: 'rww 1/28/2000 01:33'! view "Answer the receiver's instance variable view." ^view! ! !WindowRaiser methodsFor: 'accessing' stamp: 'rww 1/28/2000 01:33'! view: anObject "Set the receiver's instance variable view to anObject." view := anObject! ! !WindowRaiser methodsFor: 'action' stamp: 'rww 1/30/2000 02:39'! raiseInMilliseconds: millisecondTime self isRaising: true. [(Delay forMilliseconds: millisecondTime) wait. self isRaising ifTrue: [self raiseView]] fork.! ! !WindowRaiser methodsFor: 'action' stamp: 'rww 1/28/2000 01:41'! raiseView self view activate ! ! !WindowRaiser methodsFor: 'action' stamp: 'rww 1/30/2000 02:39'! stop self isRaising: false.! ! !WindowRaiser methodsFor: 'initialize' stamp: 'rww 1/30/2000 02:40'! initializeOn: aView self view: aView. self isRaising: false.! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/30/2000 02:24'! deinstallOnMorph: aMorph |raiser| raiser := self eventRegister removeKey: aMorph ifAbsent: [nil]. raiser ifNotNil: [raiser stop]. aMorph on: #mouseEnter send: nil to: nil. aMorph on: #mouseLeave send: nil to: nil. ! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/30/2000 02:10'! eventRegister ^EventRegister. ! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/30/2000 10:48'! initialize EventRegister := Dictionary new. Preferences disable: #autoRaiseWindows.! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/30/2000 12:40'! installOnMorph: aMorph (Preferences autoRaiseWindows) ifTrue: [ aMorph on: #mouseEnter send: #value to: [self eventRegister at: aMorph put: ((WindowRaiser newOn: aMorph) raiseInMilliseconds: 400)]. aMorph on: #mouseLeave send: #value to: [(self eventRegister removeKey: aMorph ifAbsent: [^ self]) stop]].! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/28/2000 01:32'! newOn: aView ^super new initializeOn: aView ! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/30/2000 10:44'! startAutoRise SystemWindow allSubInstancesDo: [:aWindow | aWindow autoRiseOnMouseEntry]. ! ! !WindowRaiser class methodsFor: 'as yet unclassified' stamp: 'rww 1/30/2000 10:44'! stopAutoRise SystemWindow allSubInstancesDo: [:aWindow | aWindow cancelAutoRiseOnMouseEntry]. ! ! WindowRaiser removeSelector: #timer:! WindowRaiser removeSelector: #waitFor:! WindowRaiser removeSelector: #timer! WindowRaiser initialize! WindowRaiser class removeSelector: #IsActive!

1 0

Re: Continuations; was RE: Multiple Returns, was Re: Common Lisp style macros in Smalltalk?
by demiourgos＠smalltalk.org 30 Jan '00

30 Jan '00

On Thu, 27 January 2000, "Vassili Bykov" wrote: Excellent summary Vassili! Sorry I missed it before. --jtg > > > From: Jarvis, Robert P. (Contingent) [mailto:Jarvisb@timken.com] > > > > OK, I'll exhibit my ignorance :-). What are continuations, and what are > > they useful for? Same questions for coroutines. > > Continuations is a big topic. They are pretty mind-bending, so no > explanation can replace actual use of them. I am attaching my continuations > (still work in 2.7) for playing with. > > Continuations is an abstraction for non-local control transfer used (among > some other languages) in Scheme as the foundation for all the other > non-local control tricks. Things like non-timeslicing multitasking, > exceptions, catch/throw can all be implemented using continuations. > > First of all, to get matters straight, what one could implement using > continuations could be implemented by "regular" Smalltalk means or is > already available, as objects and blocks, exceptions and processes. Within > Smalltalk, using those would of course be a better solution. This is what I > meant saying that continuations are far out of Smalltalk thinking. I still > find it neat that they can be implemented in Squeak at the image level. > (You can almost, but not quite, do that in VW--or maybe YOU can). > > Here is what continuations are. Suppose we have a piece of code that reads > "quux := aFoo bar". While the #bar message send is in progress, we can say > that the piece of code "quux := ..." expects the value returned by "aFoo > bar" to substitute it in place of the ellipsis. We can express this > expectation as a block "[:a | quux := a]". We can imagine that once "aFoo > bar" completes, the execution continues by invoking that block, with the > result returned from the #bar message as the argument. This one-argument > block is called the continuation of the message send--because it describes > how execution continues after the message send returns. > > As far as most languages are concerned, continuations are only a theoretical > concept. Scheme, on the other hand, makes them first class. It provides a > function call-with-current-continuation, often also available as call/cc, > expecting a one-argument function. It then calls that function passing the > continuation of the (call/cc ...) as the argument. The continuation behaves > as a one-argument function; calling it has an effect of returning from the > (call/cc ...) form. If you feel OK about reading some Scheme, here is a > stupid but simple example > > (define (foo n) > (call/cc > (lambda (cont) > (if (zero? n) (cont 'zero)) > 'non-zero))) > > Here, the continuation is used for non-local exit. A similar thing in > Smalltalk, shown on c.l.s a couple of times by Eliot Miranda and myself > would be > > Block{Context,Closure,whatever}>>valueWithExit > ^self value: [:result | ^result] > > MyClass>>foo: n > | temp | > temp := > [:exit | > n = 0 ifTrue: [exit value: #zero]. > #non-zero] valueWithExit > > (without the #valueWithExit thing, you could not have #zero assigned to > "temp", ^ would just leave the method). > > The funky part is, you can hold onto a continuation object and call it > multiple times, thus causing one function call return multiple times along > the same call chain. For example, in Scheme after you evaluate > > (begin > (call/cc > (lambda (cont) > (set! print-again cont))) > (display "Hello again")) > > you could many times evaluate > > (print-again 'bogus) > > and each time it would print "Hello again", because control "escapes" into > the continuation and returns along its sender chain--that is the call/cc > will return (with 'bogus as the value which is ignored) and will then move > on to the next form. > > See a test method at the class side of Continuation class in the attached > change set. In this implementation, Block methods > #valueWithCurrentContinuation and #valueWithCC are the analogs of > call-with-current-continuation and call/cc. > > Alan (Knight) already mentioned that you can mimic this stuff by explicitly > passing blocks around. This is true by definition--continuations behave > *almost* like functions of one argument (incidentally, allowing them to have > may arguments yields a language with multiple return values). What all the > fuss is about then? Theoretically, execution of any program can be viewed > in terms of continuations. In languages with first class continuations > (Scheme or Squeak with the attached file-in), you can "lift" a contunuation > as a "real" object off a syntactically "normal" program. In a language > without first-class continuations, but with closures, you can manually chop > and slice your program into continuations expressed as blocks. > > How about this summary of how continuations are different from a bunch of > blocks passed all over: > > Continuations allow to introduce non-standard evaluation rules > in code that uses standard syntax. > > It is getting late, so I'll wrap up here. (I am not sure anyone will read > this far anyway. :-) Just a few interesting points before the end. > > A continuation may look just like a function of one argument (a one-argument > block in the Smalltalk version), but the catch is it has weird call > semantics. In the "print-again" example, evaluating > > (begin > (print-again) > (display "and goodbye")) > > will never print "goodbye" because calling a continuation, speaking in > technical terms, replaces the call stack so (print-again) will never return > to the caller. You can see the gory details in the code. > > Why does call/cc have the confusing form of accepting a function that will > receive the actual continuation? Could we just have something like get/cc, > a no-argument function that returns its own continuation? get/cc is less > general. It can be implemented using call/cc, in a very cool way: > > (define (get/cc) > (call/cc call/cc)) > > (proving that it works is an exercise to the reader). There are a couple of > pragmatic considerations as well. > > Finally, people have been known to insist that the correct implementation of > call/cc is: > > (define (call/cc foo) > (display "cc: Segmentation fault. Core dumped.")) > > A good book discussing all that is Lisp in Small Pieces by Christian > Queinnec. > > Cheers, > > --Vassili ______________________________________________________ Jan Theodore Galkowski www.smalltalk.org/ http://www.scguild.com/usr/1707I.html demiourgos(a)smalltalk.org www.marssociety.org/ ********************************************** PGP Key Fingerprint: 2757 F86D AA51 677D 38D7 964B 9A8D 7852 A494 3790 ********************************************** Get my Public Key from my home page at: http://home.stny.rr.com/algebraist/ ********************************************** ______________________________________________ Get free e-mail at http://www.britannica.com

1 0

Re: Computer Modern Fonts for Squeak/Mach I
by Bob Arning 30 Jan '00

30 Jan '00

On Sun, 30 Jan 2000 04:05:10 -0500 "Andrew C. Greenberg" <werdna(a)gate.net> wrote: >A number of people have asked me to put together Squeakable versions >of the Donald Knuth's Computer Modern Fonts. Attached please find a >changeset that loads up FontSet's for cmr (roman), cmtt (typewriter) >and cmss (sans-serif), all in 8, 10, 12, 18 and 24 point fonts. The >changeset installs them for immediate use, using cntl-K (to change >font style), and then the command-1 through -5 keys (to adjust font >size) Andrew, A slight glitch here - missing class definitions for Cmr and Cmss. Easily fixed by replicating the definition of Cmtt. Cheers, Bob

2 1

RE: [ANN] distribution of Squeak programs
by David Pennell 30 Jan '00

30 Jan '00

[snip] > Worked fine for me, too (on Linux). There's no "ini" file needed on Linux, > so it just up and runs. There were a number of previous posts > about putting > the image into the same file with the VM. If this could also be done, > nobody would even know that their "hanoi" program was Squeak. I suspect > also that as image segments come into use, the distributed "executable" > could become quite small, and would appear to be a program with > no separate > image file. > Lex has shown us a way to distribute closed squeak programs without doing all the hard work (yet) to build a combined image/VM. This approach has the wonderful advantage of working right now. I think this is enough to actually build some shrink-wrap apps and try them out with non-squeak audiences. As image segments mature, we can incorporate them into the process. -david

1 0

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

Jump to page: