Squeak-dev October 1999

squeak-dev@lists.squeakfoundation.org

141 participants
396 discussions

Polymorphism and language
by Adam Bridge 02 Aug '00

02 Aug '00

I wonder if we're not asking the wrong question here. Language, it seems to me, is for expression. If we design a language (as opposed to allowing it to evolve) then we should have a goal for that language. What's the goal here? Although polymorphism is certainly an interesting capability shouldn't we be looking at the kinds of tasks we wish to perform? Would we demand an artist work in tempra when water color is what expresses the mood best? Personally I like the idea of small languages that do some things very very well. They are easy to learn because their concepts are clear. If languages can agree on ways to intermingle so I can write my image manipulation in one language and my text in another and my GUI in yet another -- and have them work together intimately and EASILY -- then I think we have a software system which is about expression first and language second. I'd love to easily, trivially, combine Smalltalk, Perl, Fortran, Obj-C and be able to easily explore other languages in this same context: it becomes easy to grow. Adam Bridge

2 1

unsubscribe
by Alek 09 Jun '00

09 Jun '00

2 1

Re: Byte order and ByteArray conversions
by Lex Spoon 04 Nov '99

04 Nov '99

If you know the endian-ness you want, you can use nextNumber:put: and nextLittleEndianNumber:put: to write out integers in big endian or little endian. So that would probably be the inverse of the methods you were looking for. You can read them back with nextNumber: and nextLittleEndianNumber:. But why would knowing the machine's ordering matter, unless you are doing primitives? Maybe if you post a higher-level view of what you are trying to do, someone will have a more helpful response. I tend to like the fact that I don't have to think about endianness :) Lex "David T. Lewis" <lewis(a)mail.msen.com> wrote: > > I'm sure I'm missing something obvious, but I'd like to be able to convert > integers to and from byte arrays in native machine byte ordering, without > resorting to a new primitive. > > 1) Does Squeak know the byte order convention of the hardware it's running > on? I can't find any method to query for this. > > 2) Class ByteArray knows how to convert itself into integers, given that > you can tell it the answer to question 1. Is there any existing method > for converting an integer into a four byte array? > > Thanks.

11 12

Byte order and ByteArray conversions
by David T. Lewis 02 Nov '99

02 Nov '99

I'm sure I'm missing something obvious, but I'd like to be able to convert integers to and from byte arrays in native machine byte ordering, without resorting to a new primitive. 1) Does Squeak know the byte order convention of the hardware it's running on? I can't find any method to query for this. 2) Class ByteArray knows how to convert itself into integers, given that you can tell it the answer to question 1. Is there any existing method for converting an integer into a four byte array? Thanks.

2 2

[Q] Project: Better performance for LargeIntegers
by Stephan Rudlof 01 Nov '99

01 Nov '99

Dear Squeakers, I have changed my mind a little bit after studying some Squeak sources. Now I plan to implement LargeInteger primitives (20-39) _without_ changing the representation of LargeIntegers by extending the Interpreter arithmetic primitives using the CCodeGenerator. This avoids some problems dealing with different platforms. In a later step changing the representation to bigger 'digits' (16,32,.. bits?) _could_ be interesting. What do you think? Stephan P.S.: Is [Q] the right string to get attention from Squeak Central? > -----Original Message----- > From: Stephan Rudlof [mailto:stephan.rudlof@ipk.fhg.de] > Sent: Dienstag, 26. Oktober 1999 11:24 > To: squeak > Subject: RE: Better integer performance possible? > > > Dan, Michael and others, > > > There are three reasons LargeInts are slower: > > > > It is all written in ST (no primitive support) > > The inner loops runs byte by byte > > [FYI, they were written when Squeak had 12-bit smallInts > > -- can you guess out why?] > > Squeak does not have a JIT -- yet. > > > > If I'd have the freedom to change the representation of LargeInts I would > like to implement this stuff as primitives in C. > > > We would happily invite a replacement LargeInt package into > > Squeak if it were at least as simple and understandable (I cannot > > imagine this not being the case!!), and if it did not add a > > significant overhead to the VM. > > And change some Smalltalk methods to call the new primitives. > > Timeline: Because I'm a new squeaker - but familiar with VW > Smalltalk - and > haven't change implementations of a VM - but implemented user > primitives for > VW Smalltalk - I'm planning quiet some time to become familiar with it. I > could start in the mid of November - then I will have holidays - > and I think > I could finish around christmas. > > What do you think? > > Greetings, > > Stephan Rudlof > > sr (stephan.rudlof(a)ipk.fhg.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 > > > -----Original Message----- > > From: Dan Ingalls [mailto:Dan.Ingalls@disney.com] > > Sent: Montag, 25. Oktober 1999 22:32 > > To: squeak(a)cs.uiuc.edu > > Subject: Re: Better integer performance possible? > > > > > > Stephan Rudlof <stephan.rudlof(a)ipk.fhg.de> wrote... > > > > >The integer performance of Squeak is poor compared with other > Smalltalks, > > >especially for big ints (~ factor 500) and not so much for > small ones (~ > > >factor 3). > > > > > >What's the reason? Does anybody know if improvements are possible? > > > > There are three reasons LargeInts are slower: > > > > It is all written in ST (no primitive support) > > The inner loops runs byte by byte > > [FYI, they were written when Squeak had 12-bit smallInts > > -- can you guess out why?] > > Squeak does not have a JIT -- yet. > > > > There is one reason SmallInts are slower: > > > > Squeak does not have a JIT -- yet. > > Also, in the factorial example, it may matter that > > Squeak allocates real objects for all contextx > > > > Ask Ian about Jitter -- he has been having fun with it recently. > > When he's done, I think the SmallInt comparison will be much > > better. LargeInts will be similarly better, but not like the > > Dolphin numbers. I personally have not ever found LargeInt speed > > to be a concern in any useful code. > > > > We would happily invite a replacement LargeInt package into > > Squeak if it were at least as simple and understandable (I cannot > > imagine this not being the case!!), and if it did not add a > > significant overhead to the VM. > > > > - Dan > > > > PS: I know Squeak's bytecode speed got better on Windows in a > > recent VM, so 2.6 may be somewhat faster than 2.5. > > > > >WinNT Dolphin Smalltalk Version 2.1 Patch Level 2: > > > > > >Time millisecondsToRun: [2000 factorial]. "big ints" > > > 76 75 76 > > >Time millisecondsToRun: [1000 timesRepeat: [12 factorial]]. > "small ints" > > > 11 11 10 > > > > > >WinNT Squeak 2.5: > > >Time millisecondsToRun: [2000 factorial]. "big ints" > > > 34520 34520 35080 > > >Time millisecondsToRun: [1000 timesRepeat: [12 factorial]]. > "small ints" > > > 30 30 30 > > > > > >Stephan > > > > > > > > > > > >

5 11

[Q, BUG?] perform:orSendTo problem?
by Jason McVay 01 Nov '99

01 Nov '99

hello again all-- i asked about this last week and only heard from one person (thanks Torsten). however, i would like to hear from some others on this on if this is a bug or not. from what i understand of the #perform: selector orSendTo: otherTarget method in both Object and Model, the receiever is supposed to be asked first if it can handle the selector; if not, then the selector is passed off to otherTarget. the comments in both classes says this is supposed to happen, but the implementation in both classes seems not to ask the receiever anything; instead, it just sends the selector onto otherTarget. other classes such as PluggableText, StringHolder, and TranscriptStream override this method to what looks to be the proper implementation. why is the message implemented like this in Object and Model? what am i missing? thanks for your consideration and replies, jason

2 1

Re: Where's the source?
by JArchibald＠aol.com 01 Nov '99

01 Nov '99

Hello Ross, I hope I'm not going to tell you something you might already know about Squeak. Squeak, as do all Smalltalk variants (to a greater or lessor extent), provides all source for the entire application environment. First though you have to get within the environment to work. The home page 'squeak.org' will lead you to appropriate download information. Download a package for your platform which includes four files (VM, Image, Changes, Source). Run it. From the 'desktop' select open>>Browser. At that point you are looking at all the source (for the entire system, as well as the Smalltalk to C converter for creating the VM=virtual machine). The mailing list archives are broken (thus the Forbidden message); we have not been able to determine why at this point. Version 2.6 is the current version. But the download archives (=> Squeak.org) provide all versions for download. Usually facilities which have been previously available (such as mentioned for 2.4c, a very recent version), have been updated, or often will be updated if you request so from the submitter. Hope this helps, Jerry Archibald systemObjectivesIncorporated => 10/30/99 9:40:13 PM EDT, RossBoylan(a)stanfordalumni.org => << I'd like to get the source for the VM for the current squeak (2.6). At the moment I'm on Windows NT. I've looked around the download site and the squeak.org site, and I can't find it. I did see an indication that the Unix source was available, but I'd like something I can rebuild if I want to. I might want to link in some C++ code. I don't know if I need the VM source to do that, but I'd like to have it in any event. By the way, I tried going to the discussion archives from the main site, and I got a permission error. Also, I noticed that some items have particular versions of squeak attached. For example, on of the persistence frameworks says it's for 2.4c. Are these likely to work if I try them with 2.6? >>

2 1

"The Smalltalk-76 Programming System: Design and Implementation" paper now online....
by Dwight Hughes 01 Nov '99

01 Nov '99

I just put Dan Ingall's classic paper "The Smalltalk-76 Programming System: Design and Implementation" from the Fifth Annual ACM Symposium on Principles of Programming Languages, January 1978, online at my site: http://users.ipa.net/~dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.h… My thanks go to Dan and ACM for giving me their permission to publish this -- but especially to Dan since he even went to the trouble to send me scanned images of this paper to work from since I didn't have a copy of it available. Enjoy. -- Dwight

2 3

Re: Anybody know bytecodes/sec for the G4 processors?
by Bruce ONeel 31 Oct '99

31 Oct '99

Jan Bottorff <janb(a)pmatrix.com> wrote: > I was fiddling with my presentation on interpreters for OOPSLA and was > wondering if anybody had run "Integer tinyBenchmarks" on an Apple G4 > system. There was a discussion a while back suggesting the PPC 750 (I > assume this is a G4?) might have great interpreter performance. > > - Jan Hi, No, no G4 to try this on. A 750 is a G3 though. I don't know what number is assigned to a G4... cheers bruce

1 0

Anybody know bytecodes/sec for the G4 processors?
by Jan Bottorff 30 Oct '99

30 Oct '99

I was fiddling with my presentation on interpreters for OOPSLA and was wondering if anybody had run "Integer tinyBenchmarks" on an Apple G4 system. There was a discussion a while back suggesting the PPC 750 (I assume this is a G4?) might have great interpreter performance. - Jan

1 0

Jump to page: