Squeak-dev April 2002

squeak-dev@lists.squeakfoundation.org

195 participants
665 discussions

Problem with Socket under Linux...
by goran.hultgren＠bluefish.se 29 Apr '02

29 Apr '02

We have some interesting problems under Linux. We have just semi-verified it's a Linux - thing, Jonas here running on Win2k does not have it - at least not when doing some simple tests. We use Comanche with SocketStream and my problem is that this method: waitForDataUntil: deadline "Wait up until the given deadline for data to arrive. Return true if data arrives by the deadline, false if not." | dataArrived | [self isConnected & (dataArrived _ self primSocketReceiveDataAvailable: socketHandle) not "Connection end and final data can happen fast, so test in this order" and: [Time millisecondClockValue < deadline]] whileTrue: [ "self readSemaphore initSignals." self readSemaphore waitTimeoutMSecs: (deadline - Time millisecondClockValue)]. ^ dataArrived ...seems to busyloop when I have a connected SocketStream waiting with #nextLine. It eats up somewhere around 30-50% in the Process browser. The UI process gets the rest - which is a bit weird in itself. On Win2k it's the idle process that has about 100%, not the UI process. I just assume that has something to do with the Linux port? Anyway, after investigating a bit in the debugger we found that #waitTimeoutMSecs: just flys by the "self wait" because there is an excessive signal on the readSemaphore! Oops, seems not right. So the #whileTrue: loop above is chugging along quite a lot... And the signal gets there right after the #primSocketReceiveDataAvailable: call above (which returns false btw). Hmmph, why is that? As you can see I just threw in a hack above with initSignals (now commented out) and that sure made it do a real wait. But then it didn't wake up when data arrived!? So... what is going on here? regards, Göran

5 8

Re: Squeak UI and toolkit commentary: (was: Re: Who has no job? (was Re: O'Reilly Squeak book?))
by Martin Drautzburg 29 Apr '02

29 Apr '02

marbusse(a)t-online.de (Markus Fritsche) writes: > Am Mittwoch, 24. April 2002 16:54 schrieben Sie: > > > And my defense here is that I don't really want to attract users. > > > I want to attract *developers* > > I don't want a car for drivers, I want a car for car mechanics? > > Regards, Markus Isn't it more like a "car construction toolkit for car mechanics" ?

4 4

Re: IMAP
by goran.hultgren＠bluefish.se 29 Apr '02

29 Apr '02

"Les Tyrrell" <tyrrell(a)canis.uiuc.edu> wrote: > The VW 3.0 version of my IMAP client can be found on the following Wiki: > > http://sabine.canis.uiuc.edu:8080/EMail > > I have not tried to port it to Squeak, I suspect you will need to look at > Squeak's sockets and streams to understand the best way to make it work there. If someone want's to do this - take a look at SocketStream etc in Comanche, easier to use than plain Socket. Those classes should be included in base Squeak IMHO. regards, Göran

4 3

[ENH] SequenceCompare
by ok＠cs.otago.ac.nz 29 Apr '02

29 Apr '02

from preamble: "Change Set: SequenceCompare Date: 29 April 2002 Author: Richard A. O'Keefe Add #< #>= #> #<= #min: #max: #min:max: #between:and: to SequenceableCollection so that SequenceableCollections bhave like Magnitudes. The ordering is the lexicographic extension of the ordering of the elements. This is fully compatible with the ordering of Strings. With this ordering, s1 <= s2 if and only if s1 asArray <= s2 asArray, where s1 and s2 are Strings."!

1 0

Re: [Q] Has SharedQueue a very subtle bug?
by goran.hultgren＠bluefish.se 29 Apr '02

29 Apr '02

Scott A Crosby <crosby(a)qwes.math.cmu.edu> wrote: > On Mon, 15 Apr 2002 goran.hultgren(a)bluefish.se wrote: > > > Ok, a few conclusions: > > > > 2. Scott's addition of #critical: to SharedQueue seems useful in some > > cases. Should have proper comments to explain how it can be used. > > Actually, it may not be a good idea.... Ok, why then? You proposed it. :-) > > ...and then we come to #isEmpty and #size. > > You can't invoke #isEmpty or #size and get a reliable result unless the > lock is held. (I covered this in an earlier mail.) I would argue even more strongly (well, you already saw that below) - even using your critical: you must take into account that there can be multiple readers "queued up" that you will never be able to "beat to it". So you need to be aware of what you can use the information give by size/isEmpty for. Anyway - we are probably completely in agreement. > So the options are either this idiom: > > sq critical: [ ..... sq isEmpty ....] > sq critical: [ ..... sq size ....] > > Or this idiom > > sq ifEmpty: [ ........ ] > sq withSize: [ :size | ...... ] > > In either case, it is not permitted to do queue mutation during those > blocks. (Until/unless squeak gets reentrant locks.) Well, that would only fix half of the problem I think. You must also change the current situation where other readers can be queued up. But sure. > Personally, I am tempted for the first idiom, because you can run #isEmpty > or #size outside of the #critical:, as long as you can accept that the > answer is only advisory and not accurate for any fixed duration. (And if > they are run within the #critical:, then the answer is known valid for the > duration of the #critical: Eh... Then we need two different versions of #size/#isEmpty because if you want to run them within #critical: they must not use accessProtect and if they are run outside of #critical: they can give bogus results if they do NOT use accessProtect. At least as long as we have methods like #peek is implemented today. > > Scott A Crosby <crosby(a)qwes.math.cmu.edu> wrote: > > [SNIP] > > > And you can't get an *accurate* size outside the lock on the semaphore. > > > #peek below just means that we run a risk of an inaccurate and possibly > > > corrupt size. If #size also got #accessProtect, we'd still have this > > > inaccuracy... When you say inaccuract here I assume you are thinking of "queued up readers" right= [SNIP] > > Anyway, if we would protect #size and #isEmpty then those methods could > > not be used inside Scott's #critical: (since they would block) and they > > still would not be "safe" when used from the outside without #critical: > > because there can still be Processes queued up at the readSemaphore or > > "just released" from it and just about to get into the accessProtect > > semaphore, or already queued up at the accessProtect semaphore. > > Translated to english this means that the queue can have readers "queued > > up" so naive code like: > > > > q isEmpty not ifTrue:[q next] > > > > ...could block because it might be empty after all - the other readers > > beat us to it. In short - #size and #isEmpty should be heavily commented > > so that people don't get fooled by them. > > Exactly! > > Fixes are 1: Allow locks to be held recursively. (Probably > create a seperate Mutex class).. Then you can do > > q critical: [q isEmpty not ifTrue:[^q next] ifFalse: [^nil]] > > Where since the lock is already held by *this* thread from within > #critical: , the access to accessProtect in 'next' also succeeds. Ok, that is a larger rewrite of SharedQueue. But perhaps we should do it. > -- > Or, create a seperate method called #nextNoLock that is only to be > invoked from within #critical: and assumes that the lock has been grabbed. > > q critical: [q isEmpty not ifTrue:[^q nextNoLock]] Oooh. That would (currently) mess things up. It would mean that you could "sneak by" the reader queue (Processes sitting on the readSema AND on the accessProtect AND inbetween) and steal objects causing the 'Error in SharedQueue synchronization' in #next. But sure - we could change the logic in SharedQueue and not rely on the signal count and instead use the Semaphore as a "data available" flag as we did in SharedBufferStream. You would then have to take into account that when #next finally gets into the critical: part the queue could be empty and you would have to go back and wait again (at the end of the line). This is how SharedBufferStream works because we can not match readers against writers (since it is a stream and not a queue). > -- > > BTW, it is safe to do > > q size > HighWaterMark ifFalse: [ q nextPut: 2 ] > > as long as going a *little* over the high water mark isn't bad.. Because > if there are a max of $k$ concurrent threads, the worst case is all $k$ of > them run 'q size' and get the size equal to HighWaterMark. Then all k of > them add one more item.. So in this case, we can bound the used size at: > > HighWaterMark + k > > Which shoudn't be that severe of a problem.. I agree. > > Actaully, when I come to think of it #nextOrNil is probably pretty buggy > > too. Since it doesn't wait on the readSemaphore it just might go > > straight by one or more other readers and steal the next object from > > them. This could actually make the queue empty and then we would get a > > 'Error in SharedQueue synchronization' in #next. > > > > Perhaps we should remove #nextOrNil: altogether and rely on #peek > > instead... > > I never looked at this function, but that sounds bad. Yep, should be fixed. > > Hrmph, this class is full of fleas! :-) > > Nope.. IMHO, Its more an artifact that multithreading programming is a > bitch. :) Yes, I agree! We have been scratching our head once or twice when concocting the SharedBufferStream and friends. But now they seem solid... (famous last words) > BTW, sorry... Missed this new message on the list. No prob. > Scott regards, Göran

2 1

Vote now! (was Re: straw-man 3.2 default preferences)
by goran.hultgren＠bluefish.se 29 Apr '02

29 Apr '02

"Stephan B. Wessels" <swessels(a)one.net> wrote: > On 4/18/02 11:16 PM, "Jon Hylands" <jon(a)huv.com> wrote: > > > On Thu, 18 Apr 2002 19:37:24 -0700, Scott Wallace > > <scott.wallace(a)squeakland.org> wrote: > > > >> Would you also put these inboard scrollbars on the *right*, on > >> similar grounds of familiarity? > > > > Well, I certainly would (and do). > > > > I think you should also seriously consider setting the windows to all > > white, or at least all the same (light pastel) color. > > I'd vote for the pastel settings by default. I like the colors! "Go colors, go colors!". Don't let all these gray-stripe-Windows-users drag us down to the boring bottomless pit of white backgrounds! :-) Who knows, the next thing they may come up with is removing the mouse logo! Stop this nonsense right NOW: Make your voice heard at <a href="http://anakin.bluefish.se:8080/squeakdot">SqueakDot</a> (There is a poll up!) Vote for multiple colors! Vote now! regards, Göran

8 7

Re: How do you define "object-oriented"?
by Richard A. O'Keefe 29 Apr '02

29 Apr '02

Kevin Fisher <kgf(a)golden.net> wrote: I have a bit of a question...I'm just sitting down to learn Python right now and I'm finding it a bit too C/C++ like for my liking. This would astonish the average C/C++ programmer. People with that background tend to really _hate_ indentation-based syntax. The words 'int' and 'char' go back to Algol 68, which looked nothing like C. (I say this as a former Algol 68 enthusiast.) No, make that 'looks'; there are still a couple of Algol 68 compilers around. Python shares a useful property with Lisp and Smalltalk, which sets it off quite sharply from the Fortran/Java world. VALUES have types, not VARIABLES. What strikes me about Python is it's claim of "object orientation"--and yet, it has atomic types like 'int' and 'char' that are not objects (shades of C++ and Java). Originally, Python was not an object-oriented language at all, and was not meant to be. Eventually, object-oriented features were added to it. At long last, it was completely rearchitected to be more consistently OO throughout. This makes it a bit like Lisp, where classes were added afterwards, and built-in primitive types _weren't_ classes before but _now_ act for many purposes as though they were. Squeak implements SmallIntegers differently from other objects. Does that mean Squeak isn't object-oriented? If you can put an object in a list, you can put an integer or character. That's as true of Python as it is of Smalltalk, and in marked contrast to Java. Is it safe to say that something like Python is not truly object-oriented? Or rather--if it's not objective right down to the smallest particle, can it be called object-oriented? It is quite fair to call current versions of Python object-oriented. It is a lot closer to the ideal than Java is. It seems to me to be closer to the ideal than Perl, which also gets called 'object-oriented'. (and then there's the other question about why all new languages go out of their way to be so C-like...a personal beef of mine. :) I think it can be fairly said of Python that its designer went out of his way to make it NOT like C. For the benefit of readers who are not familiar with python, I enclose a small program that a friend wrote. I've stripped out the comments, which considerably outbulked the code. 1. import sys, string 2. rows = map(lambda x: map(string.strip, string.split(x, ",")), 3. string.split(string.strip(sys.stdin.read()), "\n")) 4. col_widths = map(max, 5. apply(map, (None,) + tuple(map(lambda r: map(len, r), 6. rows)))) 7. for row in rows: 8. for item in map(None, col_widths, row): 9. if item[1] == '-': 10. sys.stdout.write("-" * item[0] + "--") 11. elif item[1] == '+' or item[1] == '|': 12. sys.stdout.write("%s" % item[1]) 13. else: 14. sys.stdout.write(" %*s " % item[:2]) 15. sys.stdout.write("\n") Ad 1: 'import' is like Ada 'with/use', not like C 'include'. Ad 2-6: 'map', 'lambda', 'apply' come from Lisp, not C, and are quite alien to the C way of doing things. Ad 7: identation-based syntax is very unlike C. Ad 7: what 'in' means is determined by the class of the following expression; it is much closer to Smalltalk's #do: than C's 'for'. Ad 11: the word 'elif' goes back to Algol 68 and is not found in C. What do we find that is C-like? - backslash escapes in strings (idea inherited from BCPL, which used *; idea also found in Eiffel, which uses %; backslash *quotation* found in Lisp). It's handy, and there's no real point in inventing a new notation. - item[0], but zero-origin array indexing is found in Lisp and (as a run- time option) in APL. Note that the 'slicing' notation in line 14 has no equivalent in C at all, it goes back to APL, PL/I, and Algol 68. - the _ % _ formatting operator (APL also had such an infix formatting operator) and the format codes used in the left operand. - The names 'stdin' and 'stdout'. Names such as 'SYSPRINT' long predate C. All things considered, Python is better considered a "squashed" Lisp with Occam-ish syntax than having nontrivial inspiration from C.

1 0

Re: PLEASE use MIME Atttachments! (was: Re: [FIX] Comments for Set...)
by Richard A. O'Keefe 29 Apr '02

29 Apr '02

Bert Freudenberg <bert(a)isg.cs.uni-magdeburg.de> wrote: I thought you were on Solaris and these are installed on our solaris machines. I do run Squeak on a Solaris 2.8 box. As far as I can discover, no part of the Metamail package is installed on that box. Chinese and Japanese versions of Netscape, yes (although I'm the only user and can read neither). Russian, Arabic, Chinese, Japanese, and Korean fonts, yes. (I know perhaps 10 words of Russian.) Apache, yes. Video conferencing yes (a camera, no). Smart Card software, yes (smart card reader, no). Metamail, no. (According to pkginfo.) "I have X on my Y machine" does not imply "everyone with a Y machine has X". The key point, of course, is that neither the Macintosh nor the Solaris box is my mail machine. My mail machine is an Alpha, which I access through ssh2. ftp://thumper.bellcore.com:/pub/nsb/mm2.7.tar.Z ftp://thumper.bellcore.com:/pub/nsb/README Thank you. There is an important lesson here for everyone concerned with the process of sending contributions: The machine people use for E-mail is NOT always one of the machines they use Squeak on.

1 0

Re: PLEASE use MIME Atttachments! (was: Re: [FIX] Comments for Set...)
by Richard A. O'Keefe 29 Apr '02

29 Apr '02

I wrote: (Hmm. I suppose I could - make my change sets on machine X. - ftp them to machine Y. - send myself a message on machine Y with the change set as an attachment. - read my own message and save it to a file. - ftp the file to machine Z. - send the message from machine Z. trying this... b****r, machine X froze, reboot machine X... 3/4 hour later, *curse*! mail sent from Y to myself on Y never arrived (and I _do_ have 'set metoo' in my .mailrc). ) Followup: The mail I sent to myself from machine Y eventually _did_ arrive. Guess what I found? The fancy GUI mail user agent on machine Y uses *uuencode* for attachments! Sometimes I think I should have been a 'cellist.

1 0

Re: Squeak UI and toolkit commentary: (was: Re: Who has no job? (was Re: O\'Reilly Squeak book?))
by Martin Drautzburg 29 Apr '02

29 Apr '02

Göran Hultgren <goran.hultgren(a)bluefish.se> writes: > I admit that I haven\'t seen how Squeak works without guidance, though I have my > suspicions. If you have guidance at hand then it\'s another story. Like the eToy > sessions with kids - the kids have guidance and it seems to work very well then. After a couple of weeks of playing with squeak I began to wonder if it is really all worth while, since I hadn't accomplished much. But I made two interesting obeservations: (1) After about a month or so my inner monologue started to come up with smalltalkish solutions for all sorts of programming problems. I believe this will continue. It is the beginning of starting to think in smalltalk. (2) I realized that the things I am playing with at the moment could be called "widged programming". This is something I never dreamed of doing in neither C nor perl. Yes you cannot use squeak without guidance and obviously it takes more than a month (at least for me). It took longer than that to master the unix shell. No reason to worry so far. Having Yoda sitting nearby would of course be a big boost, but people on the list are very helpful. BTW: I bought Kent Beck's pattern book in German. The transation is very bad. It is a pleasure to read the Smalltalk code compared to the German text :-).

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
67
Older →

Jump to page: