Squeak-dev August 2000

squeak-dev@lists.squeakfoundation.org

130 participants
418 discussions

Re: sinful bug
by Lex Spoon 03 Aug '00

03 Aug '00

Luciano Notarfrancesco <lnotarfrancesco(a)yahoo.com> wrote: > > x sin = x for all x >= 16r7FFFFFFFFFFFFDFC > > Why? > Man, for large integers, this should really work! Cascading problems in my attempts to solve it: Number>>sin should do mod (2*Pi) before converting to a float mod (\\) on large integers shouldn't convert the receiver to a float! What a mess. I give up. Try to operate on smaller numbers, Luciano :) -Lex

1 0

Re: [ENH] Alternative EventSensor
by Lex Spoon 03 Aug '00

03 Aug '00

John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > PS I'm not sure I understand why the clock for sockets on Unix is different > than the one from X? > The X display terminal might well be on a different computer than the one Squeak is running on. The X events will be timestamped with the clock on the server. In fact, if you double click fast enough, one can both imagine the two events arriving right next to each other, and the two events getting into separate packets on a busy network and thus seeming to be quite far apart. So it's nice to use X's timestamp if it's possible. -Lex

1 0

RE: [ENH] Alternative EventSensor
by Lex Spoon 03 Aug '00

03 Aug '00

"Raab, Andreas" <Andreas.Raab(a)disney.com> wrote: > Lex wrote: > > Hmm, I just put these two ideas together. On Unix, the timestamps > > for X events are going to be based on a completely separate clock > > from the ones for sockets. > > Whatever the time stamps are they should be based on what is reported by > #millisecondClockValue so that the ST side can actually figure out how old > an event is. There is no much use for a time stamp if you don't know the > clock it's based upon. > Well, there is *some* use. If you want to check for double clicks (bleck), then you only need for the timestamps on mouse events to be consistent, and you don't need them to be consistent with the timestamps on, say, socket events. I'm wondering how general purpose we really need to be. One of the cool things about Squeak is that it has very few tie-ins to the underlying OS. So how many event sources are we expecting?! Do we really need timestamps on socket events?! And why has no one suggested putting sound-player events in the queue? Those are (potentially) asynchronous. Input events certainly make sense. Also, timestamping input events makes sense. But do we really need a Squeak-wide abstraction for events in general? And does it have to be more than a handy semaphore-signalling mechanism? -Lex

1 0

Re: [BUG] Symbol>>hash
by Mark van Gulik 03 Aug '00

03 Aug '00

> On Wed, 02 Aug 2000 14:46:51 -0700 Andres Valloud <avalloud(a)exobox.com> wrote: ... > And this is with a hash that takes longer to calculate, but it sure helps > in the end. > > Cheers, > Bob > ---- a faster hash ----- > biggerHash > > self size <= 2 ifTrue: [^self hash]. > ^self inject: self size into: [ :sum :each | (sum + sum + each asciiValue) > bitAnd: 16rFFFFFF] Note that since this left shifts (sum+sum) and masks the running total, only the last 24 characters contribute to the hash (and the 24th-last character only contributes one bit, etc). I prefer a slightly slower mechanism that gives *really* good distribution... Treat each string as a polynomial in M, where each position p in the string is the character value times M^p. Evaluate that polynomial with M=1664525, modulo 2^28 (this should be half the maximum integer so this hash value can be easily combined with others without risk of overflow via + or -. This constant is taken from Knuth -- it's a multiplicative generator of order 2^30 in the group (*,Z[2^32]). To avoid overflow into large integers, each multiplication can be broken down into a couple of smaller ones: -------------------------- !Integer methodsFor: 'hashing helper'! timesMultiplier "Compute (self * 1664525) mod 2^28. We use radix 16384 to do the multiplication because 16384=2^14 and 16384^2 = 2^28. Using hex, 1664525 = 16r0019660D = 16r0065*16384 + 16r260D." | low hi res | low := self bitAnd: 16383. hi := self bitShift: -14. res := ((16r260D * low) + (((16r260D * hi) + (16r0065 * low) bitAnd: 16383) * 16384)) bitAnd: 16r0FFFFFFF. "[res = (1664525 * self bitAnd: 2**28-1)] assert." ^res! -------------------------- And the string hashing method is: -------------------------- !String methodsFor: 'better hashing'! goodHash | hash | hash := 0. self size to: 1 by: -1 do: [:i | hash := (hash + (self at: i) asInteger) timesMultiplier]. ^hash! -------------------------- I tried these methods under VisualWorks 3.0NC on a 233MHz PowerBook, and executing "Time millisecondsToRun: [1000000 timesRepeat: ['hello' goodHash]]" gave me 6233ms, which is 6.2 microseconds to hash 'hello' once. In case anyone's interested, the fact that I use a good multiplicative random generator as the "variable" of the polynomial is so that each character position has a weight independent of all other character positions. It also just so happens to support my rope implementation in interesting ways. For example, (all equations are modulo 2**28)... hash('hellothere') = hash('hello') + (hash('there') * M^5) hash('hellop') = hash('hello') + ($p * M^6). hash('hellotherz') = hash('hellothere') + (($z - $e) * M^10). etc. This allows me to maintain cached hash values as strings are concatenated, modified, etc. P.S., When I did a distribution check using a large dictionary of words, there were *no* duplicated hash values (I forget the size of the list, but I remember doing the math). This was just slightly *better* than the birthday paradox predicted for completely *random* numbers (it expected somewhere between one and two collisions, I believe).

1 0

Re: [Q] Does anyone have a radix searchtrieSmalltalkimplementation?
by Rob Withers 03 Aug '00

03 Aug '00

Mark Guzdial wrote: > > > > >Sure! I'm not sure where the Prolog/V stuff is...do you have an url, > >Mark? > > Code and docs at http://www.cc.gatech.edu/projects/squeakers/25.html Thanks, Mark. I'll dig into it. Perhaps there will be something about unification. I've never heard of that term before. Rob

2 2

Re: [Q][Unix][Sockets] Looking for explainations of 3 semaphores and error states.
by Lex Spoon 03 Aug '00

03 Aug '00

John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > >> You have thread (A) that reads data from a socket, and thread (B) that > >> writes data to the same socket. Thread (A) waits on read with Sempahore X > >> then thread (B) happens to wait on write on Semaphore X. > >> > > > > Two gripes about this scenario. First, why would you have a threading > > situation like this in practice? Second, why stop with a reader and a > > writer--suppose two threads are both writing data to the same socket > > (probably a UDP socket)? Or, what if one thread is watching for normal > > closes, and another is watching for errors? > > May I remind you the question is one or more semaphores? The example doesn't > have to elegant, just something to show one semaphore is insufficient. In > math or physics I only need one counter example to disprove a theory. I > think I've give an example to show one semaphore is a problem. Since the > objective is to have millions of people use Squeak I'm sure someone will > think my solution is elegant. > One counterexample would be enough, but it has to be one I agree with! I argued that your example isn't something we actually need to support, and I furthermore proposed a way to solve it anyway without using more semaphores. So to convince me, you need to either refute those two arguments or find another counterexample. Also, I had thought my UDP example was a straightforward extension of the problem and solution you've been describing. Isn't a major goal to support multithreaded access to a single socket? I wonder why one would stop at 3 threads, once they've decided that 1 isn't enough. Regarding performance, I have a standing question against whether the 3-semaphores interface would really better performance than simply tuning the image and VM. As far as I can reconstruct the reasoning, the idea is that you won't waste time trying to write when it's reading that has become available, and vice versa. Is that about right? Well, consider that trying to write and failing can be made an extremely fast operation. Futhermore, I'd guess that most applications tend to know which operation they are waiting for at any given time. In fact, many services will naturally refuse to read any new data until they have finished spooling out their response to the last query. For such applications, which I'd tentatively guess are the majority, it is possible to guess the appropriate operation every time. Theory aside, I eagerly await more performance data. Although, I hereby whine that people shouldn't performance tune before they have at least measured a problem! Anyway, it will be interesting to see. I betchya a 1-semaphore VM can saturate a 100MBit network, if a 3-semaphore VM can, but, we shall see. Overall, I still think the original VM interface was fine. Of course, even if everyone agreed, we'd faced with a cost analysis of switching the Mac port from 3 semaphores -> 1, versus switching all the other ports from 1->3. Note, though, around 10-20 man-hours have already been put into updating the Unix port, and it probably isn't finished yet. -Lex

2 1

[BUG][FIX] FileContentsBrowser has incorrect label
by Doug Way 03 Aug '00

03 Aug '00

Here's a trivial fix to correct the label on the FileContentsBrowser, which has been bugging me for awhile. The FileContentsBrowser is the very useful brown window which comes up when you select "browse code" on a file in the FileList window. Currently the label on the FileContentsBrowser window reads "Package Browser", but there is already a different PackageBrowser, the yellow 5-paned variant of the regular Browser. (Will the real Package Browser please stand up!) This changeset changes the label to "File Contents Browser". While I was at it I also changed the PackageBrowser title from "Squeak Package Browser" to just "Package Browser". ("Squeak" seems redundant.) (There's still some code in FileContentsBrowser which uses the term "package" internally, but I left that alone for now. Avoiding confusion in the interface is the important thing. Probably a few people still like to use the term "package" to refer to something like a changeset, but it seems that the term "package" in Squeak usually refers to the first half of a class category, for better or worse.) - Doug Way dway(a)mat.net, @riskmetrics.com RiskMetrics Group, Ann Arbor, MI http://www.riskmetrics.com

1 0

RE: Learning B3D (newbie)
by Raab, Andreas 02 Aug '00

02 Aug '00

Jesse, Translucency is currently not supported at all. The reason for this is mainly that the rasterizer is based on some very experimental design (for which the entire graphics community would probably kill me - "what??? you can't seriously do THAT" ;-) The design makes it pretty fast and quite small (no z-buffer required) but has, in it's current state, the disadvantage that it simply can't deal with translucency correctly. I know how to change this but these changes require a fundamental rewrite of core parts in the engine and for now I just don't have no time to do it. - Andreas > -----Original Message----- > From: Jesse Welton [mailto:jwelton@pacific.mps.ohio-state.edu] > Sent: Wednesday, August 02, 2000 9:55 AM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: Re: Learning B3D (newbie) > > > I also had a couple of questions about the B3D engine. In my > experimenting, I've been putting a B3DSceneObject with a B3DSimpleMesh > into a B3DSceneMorph. I eventually figured out how to use the > texCoords to texturize the model, and color the whole thing with a > B3DMaterial with an appropriate emission color. What's stumping me, > though, is how B3D works with translucency. I'd really like to be > able to use translucent 3D objects, and B3DMaterial and > B3DMaterialColor support some kind of alpha channel, but it doesn't do > anything for my models. So, two questions: Can I do what I want? > (And even if I can't) Where should I look to start understanding > translucency and lighting? > > -Jesse >

1 0

Re: Newbie technical/cultural question
by Roel Wuyts 02 Aug '00

02 Aug '00

> 1c) TGen > There is a port of a independant Lexer/Parser-Generator framework to > Squeak > called TGen. > Search for the reference on: > http://minnow.cc.gatech.edu/squeak > (currently down) > > > 1d) Programming Lab of the University of Brussels > A researcher of the programming lab of the University of > Brussels seems also to be working this area. > Search for "Vrije Universiteit Brussel" in the mailing list archive and > check what he is doing. He also maintains a Swiki-Web (I dont' have the > URL at hand) hmm, I guess I am that researcher (together with some other people at our lab) :) We have declarative languages running over Smalltalk code, so we needed parsers for these languages. For (what used to be) my language, I used the ParserGenerator. The reason is that this is a tool from another Smalltalk Environment (VisualWorks) in which I originally developed my stuff. I ported it to Squeak, but I am still waiting for an answer of the legal department whether I can release the port to the Squeak community or not (the departure of Cincom's VisualWorks responsible for Europe did not speed up this process...). The second option (which we are investigating now) is to use TGen. It seems to have some benefits over the ParserGenerator, but we are still investigating it. > 2) Little Languages > >>The second part of my question is "What's the ST way of dealing with >>little languages. Do you just build editors/inspectors instead?" > > I don't understand the question exactly. A utterance in a "little language" > in this context is a sequence of characters. The lexer/parser builds a tree > of objects. > With the inspectors you can look at any node of the tree and ask > the object to do something. Very convenient when developing. I was wondering about the question too. First of all, I do not know what you mean by 'little language'. Do you mean that it is not very different of Smalltalk's synta ? Do you mean it is something *very* simple ? Second, 'Do you just build editors/inspectors instead', I was wondering: 'instead of what' ? -- Roel Wuyts Programming Technology Lab rwuyts(a)vub.ac.be Vrije Universiteit Brussel http://prog.vub.ac.be/~rwuyts Webmaster of European Smalltalk User Group: www.esug.org

4 3

RE: Learning B3D (newbie)
by Tim Rowledge 02 Aug '00

02 Aug '00

In message <F539F53ECAF5D111B73D00805F65BAE6854FBF@WDIGL003> you wrote: > It's imperative that you send #finish at the end (the renderer won't even > start before it's getting the #finish message so you won't be able to see > anything ;-) What? You have to send #finish before it will start? :-) -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: AG: Add Gibberish

2 1

Jump to page: