Squeak-dev September 1998

squeak-dev@lists.squeakfoundation.org

108 participants
197 discussions

Problem on Solaris
by Thierry Thelliez 02 Sep '98

02 Sep '98

Sorry if this is not directly a question related to Squeak (it is probably more a Sun Solaris issue), but I am stuck attempting to run Squeak on a Sun. I get the following error message: ld.so.1: ./SqueakVM-2.1-sparc-solaris-2.5.1: fatal: libXext.so.0: can't open file: errno=2 Killed It seems like a proble with the X library. Any suggestions on how to solve that ? (This workstation runs Netscape 4.06 with no problem). Thanks for your help. Thierry

2 1

Re: Scientific Computing
by Les Tyrrell 01 Sep '98

01 Sep '98

Leandro wrote... > Performance is only an issue in some branches of Mathematics, like > algorithmic, complexity or numerical analysis. Mainly I was alluding to extremely high-end applications, such as fluid dynamics, where one is going to have lots of other problems in dealing with arcane supercomputer architectures and massive storage requirements, etc... But day to day engineering stuff, things you would actually use during initial design work ( and not advanced analysis ) are often well within the computational abilities of something like Smalltalk. My recollection is that most of my undergraduate FORTRAN programs ran in just a few minutes... I'm sure that Smalltalk could handle that with todays computers ( I was an undergraduate a long time ago...). In fact, I gambled my Master's thesis on that and was rewarded with the insight that the ability to interact with a problem was as valuable as the ability to implement it's solution. I found Smalltalk ( V/286, actually, on a 486/DX33 ) to be a very good match to my problem, developing an algorithm for 2D unstructured mesh generation. ( I needed the mesh for the flow solver, one thing led to another, etc ... ). > We are not interested in doing long > calculations, we are using Squeak to think and understand mathematical > concepts. In much of my undergraduate engineering work, we were primarily doing one-off programs meant to hone our skills in developing numerical software to meet our own needs. These were the end products of having first learned the mathematical, physical, and engineering principles ( probably in separate coursework ) rather than an integrated learning experience in which one literally builds upon previous work. I'm very glad to hear of your work in this area- I know there are a lot of Statics and Dynamics engineering students out there who would benefit enormously from having a highly interactive "textbook", rather than those pages of cut-and-dried vectors calculus formulas that I had ( too much abstraction is not a good thing early in the learning process - pages of equations quickly become nothing but pages of equations, with all physical meaning lost somewhere in the dazed confusion of too many courses ). > The important point is that Squeak and Morphic fit exactly in our work. > (BTW, I'm just beginning to write my manuscripts and classroom notes in > BookMorphs, and I am discovering the beauty and power of having mathematical > objects living around the same pages where the definitions and theorems > they illustrate are written. It's exciting.) I should think so! I'd love to see these! les

1 0

Re: Polymorphism without protocol dilution
by Randal Schwartz 01 Sep '98

01 Sep '98

>>>>> "Mike" == Mike Klein <mike(a)twinsun.com> writes: >> At 12:04 PM 8/30/98, Marcus Denker wrote: >> >From the Camel Book ("Programming Perl", by Larry Wall, Tom Christiansen & >> >Randal L. Schwartz) p.2. Mike> [ironic quote about readability and perl] Mike> (ironic because I think most perl looks like line noise) Yes, but it's "checksummed line noise with a mission in life!" (from my book "Learning Perl" :) -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: <merlyn(a)stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn(a)teleport.com) Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A> Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

1 0

Re: Scientific Computing
by Leandro Caniglia 01 Sep '98

01 Sep '98

>I know that there are folks out there doing Math in Squeak- I'd be >interested in seeing how they approach this, and hearing whether they >feel if this is an issue or not. Performance is only an issue in some branches of Mathematics, like algorithmic, complexity or numerical analysis. We are not interested in doing long calculations, we are using Squeak to think and understand mathematical concepts. Of course, we compute some calculations, but they are simple; as simple as the examples that a mathematician tries when she is considering some interesting question. In mathematics, a simple example may enclose ideas that are hard to understand. On the other hand, a hard computation may be trivial. I'm not saying that we are not interested in finding the way to do long calculations easier or faster (i.e., to develop better algorithms), I'm only saying that we are not interested in doing long computations. To face the problems found in specialties like complexity and numerical analysis, you still must understand concepts, not perform long calculations. The important point is that Squeak and Morphic fit exactly in our work. (BTW, I'm just beginning to write my manuscripts and classroom notes in BookMorphs, and I am discovering the beauty and power of having mathematical objects living around the same pages where the definitions and theorems they illustrate are written. It's exciting.) Saludos, Leandro

1 0

Re: Base image
by Gerardo Richarte (CORE-SDI) 01 Sep '98

01 Sep '98

On Tue, 1 Sep 1998, Doug Way wrote: > Still, after playing around with Squeak for a few months, there are some > things I'd like to see moved to the base image. Something I'd like to see WeakArrays and swAPIs moved to the base image, mostly becouse they need VM recompilation. I think that sqAPIs portability should be checked befor moving it into the base image. I've been working on it myself, but I found some problems I c ouldn't deal with beacouse I needed more time than what I had... too sad... Base Bye! Richie++

3 3

Re: Scientific Computing
by Kyle Pierce on SNI 01 Sep '98

01 Sep '98

Here's my take on how to do serious number crunching tasks within a Squeak environment -- whether it be celestial mechanics, matrix math, or statistical computing. I should point out that I am a C++ developer by day, a Schemer (until recently) and Squeaker (wannabe) by night. I already have written a (commercial) C++ library for celestial mechanics, and have previously developed a Scheme-like environment (in C++) for writing apps that call this library. Now I'm thinking about making the existing C++ code a part of a dedicated Squeak VM, with specialized primitives that take care of all the serious number crunching in C++. Not too different from Siren, in terms of concept and architecture. (Too bad I can't make a living doing that sort of thing :-) Kyle Pierce P.S. Thanks to STP for the new Siren, which I hope to play with soon -----Original Message----- From: Les Tyrrell <tyrrell(a)canis.uiuc.edu> To: squeak(a)cs.uiuc.edu <squeak(a)cs.uiuc.edu> Date: Tuesday, September 01, 1998 12:57 PM Subject: Re: Scientific Computing > >Short answer: Smalltalk, which Squeak is based upon, is not intended >for the sorts of serious number crunching commonly found in engineering >applications. These are typically large, monolithic, batch-style >processing applications where the emphasis is on getting numerical >results to be post-processed for later review after the computation >is over, whereas Smalltalk is well suited for highly interactive exploration >of abstract models. > >HOWEVER. > >Squeak is open, a bit of a new situation in the Smalltalk world. >VM's can be changed. Provision for this is explicitly included >in the Squeak system. One can easily imagine installing FloatArrays >like objects, much as we currently have with CharacterArrays, or for >that matter FloatMatrices. > >I believe you would be able to get rather good numerical performance >for vector-style computation for many routine engineering applications. >I would not expect to be able to have good performance for high-end stuff >such as Direct Numerical Simulation of the Navier-Stokes equation over >arbitrarily shaped complex three dimensional bodies, but then if you >are trying to do that sort of thing you have bigger worries anyway. > >A bigger issue in my opinion is the extent to which the OO model fits >the way engineers typically think of numerical problems... mathematics >has a highly imperative, operational point of view, much more process >( or procedural ) oriented than object-oriented. My impression is that >straightforward implementations of numerical algorithms are easier in >a non-OO language ( ie, a "kinder, gentler" variant of FORTRAN ) and >that the problems we have using things such as FORTRAN are more due to >its ancient, archaic roots than the fact that it is a procedural >language. > >I know that there are folks out there doing Math in Squeak- I'd be >interested in seeing how they approach this, and hearing whether they >feel if this is an issue or not. For myself, one of my first Smalltalk >projects was an attempt to build an unstructured Euler flow solver >so I am not at all opposed to this sort of thing. Actually, I felt >that the interactive side of things had been neglected for far too >long in engineering computations. Perhaps now I would be able to see >the problem more easily from an OO perspective, but then it was hard >to ignore the procedural character of the algorithms I was trying to >implement ( actaully, I did implement, but I didn't have the computational >power to run and debug them ). > > >les > > > > >

1 0

Re: Scientific Computing
by Les Tyrrell 01 Sep '98

01 Sep '98

Short answer: Smalltalk, which Squeak is based upon, is not intended for the sorts of serious number crunching commonly found in engineering applications. These are typically large, monolithic, batch-style processing applications where the emphasis is on getting numerical results to be post-processed for later review after the computation is over, whereas Smalltalk is well suited for highly interactive exploration of abstract models. HOWEVER. Squeak is open, a bit of a new situation in the Smalltalk world. VM's can be changed. Provision for this is explicitly included in the Squeak system. One can easily imagine installing FloatArrays like objects, much as we currently have with CharacterArrays, or for that matter FloatMatrices. I believe you would be able to get rather good numerical performance for vector-style computation for many routine engineering applications. I would not expect to be able to have good performance for high-end stuff such as Direct Numerical Simulation of the Navier-Stokes equation over arbitrarily shaped complex three dimensional bodies, but then if you are trying to do that sort of thing you have bigger worries anyway. A bigger issue in my opinion is the extent to which the OO model fits the way engineers typically think of numerical problems... mathematics has a highly imperative, operational point of view, much more process ( or procedural ) oriented than object-oriented. My impression is that straightforward implementations of numerical algorithms are easier in a non-OO language ( ie, a "kinder, gentler" variant of FORTRAN ) and that the problems we have using things such as FORTRAN are more due to its ancient, archaic roots than the fact that it is a procedural language. I know that there are folks out there doing Math in Squeak- I'd be interested in seeing how they approach this, and hearing whether they feel if this is an issue or not. For myself, one of my first Smalltalk projects was an attempt to build an unstructured Euler flow solver so I am not at all opposed to this sort of thing. Actually, I felt that the interactive side of things had been neglected for far too long in engineering computations. Perhaps now I would be able to see the problem more easily from an OO perspective, but then it was hard to ignore the procedural character of the algorithms I was trying to implement ( actaully, I did implement, but I didn't have the computational power to run and debug them ). les

1 0

Re: Polymorphism without protocol dilution
by m3rabb＠stono.com 01 Sep '98

01 Sep '98

On 8/29/98 at 4:37 PM, alank(a)wdi.disney.com (Alan Kay) wrote: > Unfortunately, we forgot that languages are also for communication -- > for being read, not just for being written -- and what we quickly wound up > with was a Tower of Babel -- as least as far as people who were trying to > learn from our code were concerned. For Smalltalk-76 we decided that the > language should be always be readable, and that the extensibility that was > really needed was in expressing meanings. At 12:04 PM 8/30/98, Marcus Denker wrote: >From the Camel Book ("Programming Perl", by Larry Wall, Tom Christiansen & >Randal L. Schwartz) p.2. > >"Languages were first invented by humans, for the benefit of humans. In >the annals of computer science, this fact has occasionally forgotten. >Since Perl was designed (loosely speaking) by an occasional linguist, it >was designed to work smoothly in the same ways that natural language works >smoothly. Naturally, there are many aspects to this, since natural language >works well at many levels simultaneously. We could enumerate many of these >linguistic principles here, but the most important principle of laguage >design is simply that easy things should be easy, and hard things should be >possible. That may seem obvious, but many computer languages fail at one or >the other." >-- >p. xi At 12:16 PM 8/31/98, Mike Klein wrote: [munch many good points] Once a method name is used in an important protocol it is gone. It is shame that so many names have been misused, and so many methods are misnamed. That is why I am so obsessed with creating good names before they get locked in stone for posterity. It reminds me very much of the misuse of the electro-magnetic spectrum. It is a finite space that cannot be taken for granted. I know that from time to time there is discussion of sub-namespaces. However if I am correct, this discussion is surrounding the class name space, not the method name space. In some sense, even more than in spoken languages, we need to use messaging words with precision. > >Object >> fullyEvaluated > >fullyEvaluated > | result lastResult | > result := self. > [(lastResult := result) respondsTo: #value] whileTrue: [ > result := lastResult value. > result = lastResult ifTrue: [^result]]. > ^result > >This is sort of like Mathematica's evaluation loop (without the Hold[]) > [0->[3]] fullyEvaluated => 3 > >-- Mike Klein Considering this, like Mayor Quimby, I want to flip-flop. I now like #evaluated better than #asEvaluated. It seems that every instance of an 'as' method suggests some kind of copy is created. I don't necessarily intend a copy, just an evaluated version of the object. Ahhhh Mathematica! Yet another way cool product from good ol' UI. --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

2 1

Scientific Computing
by Laurence Rozier 01 Sep '98

01 Sep '98

A recent Techweb story(http://www.techweb.com/wire/story/TWB19980831S0001 - see excerpt below) focuses on the shortcomings of Java in scientific computing. I'm a systems engineer and not deeply familar with the effeciencies of Squeak's floating point, array and complex number operations. There have been some threads on floating point math here, but how does the Squeak VM compare to Java in this regard? Thanks, Laurence Excerpt from the article: Java isn't cutting it in scientific computing, a group of prominent engineers said. The engineers have banded together to form the Java Grande Forum in a bid to get Sun Microsystems to correct what they say are serious deficiencies in the programming language. Specifically, they said Java falls short in its handling of floating-point calculations, arrays, and complex numbers. Such lapses could affect engineering applications ranging from computer simulation to signal-processing. "From the standpoint of doing scientific computing in Java, these are big issues," said Jack Dongarra, a computer-science professor at the University of Tennessee. "They need to get resolved before things progress too far." "This is not just for supercomputing," said Geoffrey Fox, founder of the Java Grande Forum. "It's critical for the regular engineer. It affects Java in classic, sequential applications engineers do on the desktop." advocating a study of the scaling of the Java virtual machine to large applications.

1 0

Re: Base image
by stp＠limbo.create.ucsb.edu 01 Sep '98

01 Sep '98

Being that Squeak is freely distributable, I think it would be great if more of us posted our working images and file-ins to the ftp archives. This is why I distribute the "STP12" file-in library. If more of us did this, it would less and less important what was in the base image. 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/

2 1

Jump to page: