Squeak-dev June 2000

squeak-dev@lists.squeakfoundation.org

134 participants
686 discussions

[CANNOT] Do Modules ( was Re: Ship it with Squeak )
by Les Tyrrell 29 Jun '00

29 Jun '00

Stefan, I've enjoyed your posts on this subject and have mostly held off on commenting. Well, all good things must come to an end and all that, so here's my view on a few issues that I feel are strongly related to each other. Though my views are strong, I suspect that we are probably more closely aligned than the following text would suggest. Take care! - les Stefan Matthias Aust wrote: > > Paul, > > Some comments on your text heavily influenced by the other answers I read. > >* Doing odds and ends related to stability and testing > > Unit tests for the base image would be nice. Yes. However as most parts > of the core system are used in the development tools and are very much > interconnected, the whole system is its own big unit test already and this > point has a lower priority. In your world, that may be the case- but some would like to have a better understanding of the reliability of the tools that they use. I happen to think that overall Smalltalk ( and of course Squeak ) usually is pretty good- but I don't have the ability to say that I KNOW that. Squeak in particular is tough to consider as a strong system simply due to the high rate of change it is going through right now. How would you certify that it is a strong system at any given point? Systems in flux, even Smalltalk systems, are much more likely to have more errors in them than systems which are not being changed on a continuous basis. On the other hand, if that system is constructed from independently testable sub-components, you stand a much better chance of being able to keep the error count down as the system evolves. True, we do have some benefit along those lines- classes are a big boon for that. But I think more is needed at a "system of classes" level that is below the "entire image" level. > >* Namespaces > > Would be nice, but not really needed if you want to create shrink-wrap > applications as you've then total control over your image. It's more > important to have name spaces if you want to create frameworks or other > modules that should work in other people's images. You do not have total control over your image if you cannot tell what belongs there and what can be safely removed without having to personally expend arbitrarily large and unpredictable amounts of effort in doing so. > >* Image buildable from scratch > > Why? While this would be very interesting from a theoretically point of > view, I don't need this for application deployment. Which is more likely to work- a system constructed from independently testable and certifiable sub-modules with known interfaces, or a big ball of mud that was tested and certified but then subjected to a stripping phase where you don't know what all was removed, or for that matter, left behind? It's not an academic problem- it's a real-world issue of being able to state that your system meets a certain level of confidence. Systems which are stripped after testing are NOT certifiable to any level of confidence, as they are no longer the system that was tested. Nor can you map the reliability of an unstripped system onto a stripped system- they are not the same. You are then hoping that your testing on the stripped system will be sufficient to accomplish the same level of confidence that testing on individual components as well as being able to test the fully integrated system would have achieved- that is, you are trying to achieve the same level of confidence without the benefit of component-level unit tests. Also, is it more likely that a stripping process will spontaneously fix errors or create them ? > >* Producing a small footprint image with all "clutter" removed > > Actually, this is more a psychologic thing, I started to realise. If > there're no really rigid space considerations, it really doesn't matter > whether the image is 2 MB or 5 MB. As always, it depends. > > And creating such an image isn't that difficult. One could refactor the > current image within 2-3 days to easily reach 1.5 MB for > Core+MVC+development tools. Again, I know how to do this. But you didn't when you started- and it apparently took you several days to figure this out, a time that many would not find acceptable. It makes no difference whether there are "supposed" to be methods to take care of this for you- in your case, apparently they didn't work and before you could get on with the job you had in mind ( packaging the image ) you had to first fix the tools that did the packaging. Those fixes in turn could also be prone to errors, you know- so now you have a stripper of unknown ability chomping through your code. Well, if you read my comments above you know where I'd go with THAT situation. Besides, if I could construct a packaged application from scratch in 2-3 hours with a known level of confidence, why would I want to spend 2-3 days stripping an image to package an application which I'm pretty certain would not have the same level of reliability? > The only problem is, we first have to shoot the person who had the idea to > use the class SoundBuffer from all 1000+ classes of Squeak (instead of some > core class) in the image segment code to determine endianness. Just as an > example to demonstrate what happens if you don't think in modules and don't > obey the module interfaces. This is symptomatic of a philosophical problem- either you feel that it's ok to build big balls of highly coupled mud, or you don't. If you don't, then you will want the tools you use to have properties that Squeak's tools do not have at this time. However, IMO it is possible to provide those capabilities without undermining the things that we love about Smalltalk. > Then, after the blood dried up, we can refactor and clean up the image > without much problems. Using what? How are you going to decouple the hundreds ( actually, isn't it thousands now? ) of classes already in existence ? What strategy are you going to use- your small steps are going to be competing with the Great Giant Leaps of the change stream? Dubious, I think- in fact, I suspect that it would be highly unlikely. For one thing, who outside of SqueakCentral feels that they have the confidence to undertake such a task while development continues at the current pace ? My own feeling is that everything you do will be obsoleted immediately. -------- So, to summarize- the situation as I see it is that there actually is a need for tools that would support "A Different Way of Doing Smalltalk Development". That doesn't mean that I think Squeak ( or Smalltalk in general ) is incapable of being used as a serious development tool- in fact, I haven't used anything else for years now. It just means that I've seen opportunities to make an already strong system into a very strong system, one that can completely silence any criticisms of being untrustworthy or otherwise unsuited for "serious" applications. It's not the criticisms that bother me so much- it's the fact that often I have only vague generalizations to offer in defense, and I'm pretty tired of that. So Paul McCullough, if you are reading this, I'm interested. Caveat: I have some idea of the issues involved, and they are not trivial. Luckily, I did not know that at first! - les

2 1

Re: [CANTOO] [CANNOT] [CANTOO] [CANNOT] Re: Ship it with Squeak
by Stephan Rudlof 29 Jun '00

29 Jun '00

Bert Freudenberg wrote: > > On Thu, 29 Jun 2000, Bruce ONeel wrote: > > > For completness sake we also need the [CANTOO] tag as well, with > > the obvious results above ... > > > > ;-) > > > > Bob Arning <arning(a)charm.net> wrote: > > > > > I think it's time for a new message tag. If everyone who asserted > > > that "Squeak cannot ..." would add the tag "[CANNOT]" to their message > > > subject, we could have fun tallying up the hits and misses. ;-) > > Hmm, one problem here - this matches the sqfixes archive procmail regex > so the [CANNOT] messages will appear in the archive: > > ^Subject: \[.*(FIX|ENH|ADD|ANN|GOOD|HACK).*\] > > Any idea on improving this reg ex? It must, for example, match > "[BUG][FIX]" but not "Re: [FIX]". > > -- Bert - I don't understand the joke here. - If there is no joke: Don't you already have the searched reg ex? Greetings, Stephan -- 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: Socket>>sendData: and slow networks
by John M McIntosh 29 Jun '00

29 Jun '00

on 6/28/00 2:44 PM, Bob Arning at arning(a)charm.net wrote: > I ran into a problem recently where a large chunk of data was being sent > through a Squeak socket over a dial-up line at 9600 baud. Socket>>sendData: > requests the VM to send as much as possible and waits up to 20 seconds for the > send to complete. Since the new Mac VM seems willing to send up to 64K each > pass, this means that unless the network is transmitting at 3200 BYTES per > second, a large request will timeout. Clearly 9600 baud won't do that. > > I was able to get it running fine by increasing the timeout value and dropping > the max data sent each pass Hi Bob, it's more complicated at the lower level in the Mac open transport code. You see I copy and hand off the data to the send data call which happens to buffer 64K (I think) of data within the transport layer. If you look at the socket options you can see what the socket buffer sizes are on the macintosh, these of course are adjustable in the 2.8 Mac VM. This means at the point when I get notification that a flow restriction exists, which remember could be coming from the other side if you are overrunning the peer (doubtful). Then we could have WAY more than 64K of data in flight. The flow restriction is lifted when either congestion in the lower layers of OT are cleared, or the other side starts accepting more data. When this happens we consider the send done, but data still lurks lower down, but now we can accept more data to send. However as you point out this might cause a timeout failure since now you are waiting on 64k+ of data to be transmitted. >, but that's not pretty. It means that real > timeouts, when they happen, will be longer and fast networks may not be as > fully utilized since more calls are made to send the same data. It also leaves > open the question of how slow a network can be before it stops working again. I'm not sure I follow this. If you set a 300 second timeout and it occurs then is the other side dead or just congested? How do you tell? Perhaps there isn't a good answer here. > > It would be nice if there were some way of asking if packets are being sent in > a timely fashion - whatever that means for a given network connection. This is hard since you don't know when the packet actually arrives at the other side in TCP/IP, unless the other side helps. In the Mac VM the objective is to accept data from Smalltalk code as fast as possible and buffer it to the transport layer which runs async, this would skew numbers if you are attempting to look at flow rates, since it will accept the first 64k really really fast. > > Any ideas? > > Cheers, > Bob > PS I've been writing some notes on the OT code you can find it here http://www.smalltalkconsulting.com/html/OTNotes1.html -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================

1 0

USB Support
by David N. Smith (IBM) 29 Jun '00

29 Jun '00

Hi: Is anyone looking at, or thinking about, or know of any USB support for Squeak? It's getting harder and harder to get serial support on newer machines. USB seems to be the replacement. Palm's (which are of interest to us) are going USB. Thanks, Dave _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.

2 1

[CANTOO] [CANNOT] [CANTOO] [CANNOT] Re: Ship it with Squeak
by Bruce ONeel 29 Jun '00

29 Jun '00

For completness sake we also need the [CANTOO] tag as well, with the obvious results above ... ;-) Bob Arning <arning(a)charm.net> wrote: > On Wed, 28 Jun 2000 15:47:19 -0700 Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > >> >Hmm. This isn't quite true. You can use muliple fonts, colors, styles, > >> >etc. right now in a Workspace (or even a code pane). Or you could use > >> >Scamper for static display (which would let you reuse html). > >> > >> Hmm. This isn't quite true either. Can you really show multiple fonts in > >> multiple sizes in one workspace? I think, all lines need the same size and > >> one one font is possible. > >I'm staring at a workspace with four different font, in three different > >colours all on one line. I am getting very slee..... > > I think it's time for a new message tag. If everyone who asserted that "Squeak cannot ..." would add the tag "[CANNOT]" to their message subject, we could have fun tallying up the hits and misses. ;-) > > Cheers, > Bob

1 0

Re: SqC goes from Hollywood (to ECOOP--will EuroSqueakers join up?)
by Stephane Ducasse 29 Jun '00

29 Jun '00

Sorry I found it :) > Resent-date: Mon, 17 Apr 2000 17:55:34 +0000 > Date: Mon, 17 Apr 2000 19:54:20 +0200 > Resent-from: squeak(a)cs.uiuc.edu > From: Henrik Gedenryd <Henrik.Gedenryd(a)lucs.lu.se> > Subject: SqC goes from Hollywood (to ECOOP--will EuroSqueakers join up?) > Resent-sender: squeak-request(a)cs.uiuc.edu > To: Squeak list <squeak(a)cs.uiuc.edu> > Resent-cc: recipient list not shown: ; > Resent-message-id: <eIseTC.A.9YE.WA1-4(a)jerry.cs.uiuc.edu> > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > X-Loop: squeak(a)cs.uiuc.edu > User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) > X-Mailing-List: <squeak(a)cs.uiuc.edu> archive/latest/18438 > > Apparently SqC are too bashful to say this themselves, but they are all > coming to ECOOP in Nice this June (Alan speaks at the banquet). A great > reason for Euro-Squeakers to join up, and perhaps we can have a BOF-style > session there (BYO demo). > > Note that Nice is a vacation resort, which means that cheaper charter > flights are likely to be available. > > And yes, it very much looks like I will be there, fwiw. > > Henrik > > Stephane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.

1 0

Open Jit for Squeak??
by Stephane Ducasse 29 Jun '00

29 Jun '00

Hi I was reading the proceedings of Ecoop and the work on openJIT looks really interesting. I'm not an expert in that but I was thinking that the approach could interest the Squeak community. http://www.openjit.org/ Stef Stephane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.

1 0

[ENH] More Scamper Buttons & code cleanup
by Norton, Chris 29 Jun '00

29 Jun '00

Hi Folks. >From the change set... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This change set incorporates and extends Karl Ramberg's Scamper button row enhancement. Enhancement: I've added a History button to Karl's button row. Code Cleanup: I have also spent some time cleaning up the Scamper's window creation code. The code is the same; no functionality has been lost, but Scamper's openAsMorph method has been substantially refactored. I'm hoping my changes make the code easier to maintain, reuse and read. I also wrapped some file stuff in an ensure block. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I used it for a while (an hour or so), so I think it'll work for you. I've only tried it out on Squeak 2.8, though. Cheers, ---==> Chris PS> Scamper needs some work! I don't know how much time I'll be able to spend on it, but it would be good if somebody would start a Scamper feature request list somewhere. I'm sure that some of you will be interested in helping to clean up this cool tool. :-) I'll start the list with: 1. The back/forward behavior is screwy. I noticed a couple of times that the indexes got messed up. I don't have time to look into this tonight, though (it's 10:15p and I've GOT to get some dinner!). 2. If you browse a page like www.nasa.gov, or www.cnn.com, a lot of the text is pressed up against the left wall of Scamper. This is not what I see when I use Netscape or M$'s browser. 3. It would be nice if either the cursor, or the URL in a page would indicate that you've clicked it. 4. It would be nice if Scamper had some form of caching of page contents. When I browse the Swiki, it has to reload the menu widgets for each page. This is very wasteful. <<ScamperButtonRow3.1.cs.gz>>

1 0

[ENH] local vs. UTC time
by lex spoon 29 Jun '00

29 Jun '00

Here are a pair of changesets that let Squeak discern local vs. UTC time. It adds one primitive, which returns both the local time and UTC in parallel. Squeak-level code can then interpret this information as needed. The first changeset defines the primitive and a plugin that implements it. It should be fairly portable, but I've only tried it on Linux. The second changeset updates the Time class to use the new plugin when its present, and it updates Celeste to make date stamps with it. How does this look to people? It seems to allow the following basic time functions, with a minimum of fuss: 1. Return a UTC time precise to the second. This is useful when Squeak's are talking to each other from different places in the world. It's also precisely what's needed for building a proper HTTP cache. 2. Return a local time precise to the second. This is useful for clock and calender displays. 3. Return a local time plus a delta from UTC. This is what email is happiest with. Is anything critical missing? What else would people like to be able to do with time? If this looks good, let's put it in the main system. -Lex

1 0

Re: Ship it with Squeak
by Bob Arning 29 Jun '00

29 Jun '00

On Wed, 28 Jun 2000 15:47:19 -0700 Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: >> >Hmm. This isn't quite true. You can use muliple fonts, colors, styles, >> >etc. right now in a Workspace (or even a code pane). Or you could use >> >Scamper for static display (which would let you reuse html). >> >> Hmm. This isn't quite true either. Can you really show multiple fonts in >> multiple sizes in one workspace? I think, all lines need the same size and >> one one font is possible. >I'm staring at a workspace with four different font, in three different >colours all on one line. I am getting very slee..... I think it's time for a new message tag. If everyone who asserted that "Squeak cannot ..." would add the tag "[CANNOT]" to their message subject, we could have fun tallying up the hits and misses. ;-) Cheers, Bob

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
69
Older →

Jump to page: