Squeak-dev December 1998

squeak-dev@lists.squeakfoundation.org

125 participants
236 discussions

Re: problem with sockets
by Asymptotically Approaching Harmony 22 Dec '98

22 Dec '98

"Michael S. Klein" <mklein(a)alumni.caltech.edu> writes: > Now don't get me wrong... I think Squeak's approach to pretending that > the supporting machine is vanilla is admirable, but i think that a more > unified approach to handling differences when they arise is warranted. > Perhaps pluggable primitives can be used to map a "common subset" semantics > to native calls in image code, rather than VM code. Of course, one still > needs to define a reasonable common subset, and I think that, for networking, > TCP/IP and Berkeley sockets are the way to go. Is anyone using squeak for > non-TCP/IP networking? AppleTalk? > > -- Mike Berkeley sockets are eminently possible on the Mac through a compatibility library known as GUSI.<I may be mis-spelling that, it's been a while since I attempted Mac development and bounced off because I chose a stupid upgrade path and thus the Mac is flaky as all get out :)> I'm not sure if this would introduce any siginficant additional overhead, though. -Chris ____________________________________________________________________ |Chris Patti|ICQ#16333120|feoh(a)cosmic.com|Home #:(617)625-3194|JAPH| |"I have opposable thumbs, and I can buy a rifle. I don't need to | | run from anything." -Todd Finney |

1 0

Re: The cadence of Software Engineering.
by David van Coevorden 22 Dec '98

22 Dec '98

Bill, Could you give me a reference to Dan Ingalls note about the Squeak 2.3 timeline. I´m very interested in this discussion. BTW, what did you mean by conventional software engineering? Does conventional include object-oriented development in languages "less elegant", such as C++? Regards, David >Date: Sat, 19 Dec 1998 15:56:46 -0500 (EST) >From: Bill Cattey <wdc(a)MIT.EDU> >To: squeak(a)cs.uiuc.edu >Subject: The cadence of Software Engineering. >Reply-To: squeak(a)cs.uiuc.edu > >Although I have been aware of Smalltalk for a very long time, (I >mentioned it in my Undergraduate Thesis in 1983) I've not been at all >serious in my study of it until I learned about Squeak this past >October. For the past 15 years, I'd been doing what I'll call >'conventional' software engineering -- taking on multi-month and multi >year projets to get something done. > >Reading Dan Ingalls note about the Squeak 2.3 timeline, I suddenly found >myself in a universe with a VERY different sense of how long things take >to do. As I've chatted with Squeakers over the past couple months, I >understood that my sense of what to do when and how long it took was >different, but it seems that it's much more different than I imagined. > >Let's take a moment to savor how Squeak is changing how we think about >what is possible. > >-wdc > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

re: problem with sockets
by Craig Latta 21 Dec '98

21 Dec '98

Hi-- Perhaps I wasn't clear... I have implemented a complete (Berkeley interface) sockets framework for Squeak. I have written all the Smalltalk-level code and all the VM code, too. I've been using it on Windows 95, Mac and (secret hardware) systems. It will work on any system which has a Berkeley-interface sockets C library, which is all of them. Yes, it even works on the Mac. I think I'll stop working on lower-level things temporarily, and just release the sockets stuff (even though it needs closures and exceptions to work properly). On the order of hours. thanks, -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org latta(a)interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

re: problem with sockets
by johnm＠wdi.disney.com 21 Dec '98

21 Dec '98

Folks, I'm the guy responsible for the current Squeak socket API, and I completely agree: it should definitely be based on the Berkeley listen() and accept() semantics. There's no other way to handle back-to-back connection requests. Historical note: The problem is that MacTCP doesn't support a connection queuing model like Berkeley sockets. I had hoped to emulate this queuing mechanism in Smalltalk where it would be easy to debug and change. And that worked--almost! HTTP clients that produce rapid bursts of back-to-back requests hit this design in its Achilles heel--the tiny time window right after a connection is estabilished during which there is no socket waiting for the next connection. I'm willing to fix it. What would help me is pointers to open-source implementations of Berkeley sockets for the Mac using either MacTCP or OpenTransport. The code needs to work under Mac OS 7.x as well as 8.x and on both the PPC and 68K. I think Craig Latta mentioned a Berkeley-socket C library that might work, if the source is available. Of course, the code must be free of legal entanglements that would prevent us from distributing its source code with the Squeak release. If you'd like to help, please send me email with pointers to code that might be useful. Or, if you are a good Mac hacker and would like to lend a hand to the effort (mostly ust answering questions), let me know. Note that all other platforms have Berkeley socket API's, so once we have a solution on the Mac, it will be easy to port everywhere. Thanks! -- John P.S. I won't have time to work on this until mid-January at the earliest.

1 0

Sidenote: OSKit 0.96 released over the weekend.
by Les Tyrrell 21 Dec '98

21 Dec '98

The Flux OSKit has finally been released in a new version, 0.96. This may be of interest to people wanting to port Squeak to bare hardware, or interested in building OS's involving Squeak. http://www.cs.utah.edu/projects/flux/oskit/ Previous version was 0.60, which formerly was available several years ago but was then pulled from the web site. For the last few years no version of the OSKit was available except through people who had already gotten it. Perhaps the new release is a good sign that whatever issues needed to be resolved have finally been resolved. happy holidays! les

1 0

Re: Unidentified subject!
by John (Zhijiang) Han 20 Dec '98

20 Dec '98

On Sat, 19 Dec 1998, Craig Latta wrote: > The sockets implementation I've done (which I mentioned here > recently) uses the Berkeley interface. 'Guess I should hurry up and > finish closures so I can finish porting exceptions so I can finish > porting sockets. Well, the problem is, would this be available on all platforms? If not, then we will end up with a new dialect of Smalltalk, which IMHO is not a good news for this group. Cheers, * http://www.ews.uiuc.edu/~zhan1 John (Zhijiang) * zhan1 at uiuc dot edu -- (^_^) Jesus Loves You

1 0

Re: problem with sockets
by Richard L. Peskin 20 Dec '98

20 Dec '98

At 11:17 PM -0500 12/19/98, Pennell's wrote: >I have a couple of weeks between jobs and would be willing to work on cleaning >this up for Unix and Windows if anybody is interested. I could use a Unix fix for the BeOS port. --dick peskin ================================= R. L. Peskin, Rutgers Univ. ; <peskin(a)caip.rutgers.edu>; <http://www.caip.rutgers.edu/~peskin> VT Phone (802) 824-4558 NJ Phone (732) 445-4208 "The corporate culture is concerned less with Occam's razor than his aftershave lotion."

1 0

RE: The cadence of Software Engineering.
by Alejandro F. Reimondo 20 Dec '98

20 Dec '98

Smalltalk is not a language. Smalltalk is a place. It may take one hour or +ten years to know what a "place" means. This topic is the most difficult thing to communicate in the computing community, because people thinks in terms of a language to talk to the computer. Smalltalk is not a language. Smalltalk is a place. It may take one hour or +ten years to know what a "place" means. This topic is the most difficult thing to communicate in the computing community, because people think in terms of a language to talk to the computer.(1) Smalltalk makes real a new perception of computer, been a place where things are sub-created by a men. (2) What can be better than Smalltalk? If Smalltalk is a place with things (an environment with objects)... then a better Smalltalk is a Smalltalk with better objects... :-) The great work to be done is in the creation of better objects and ways to evolve our environment in a more "natural" way (w/ evolution & selection). The dilution/missing of the machine & the language is very important to the humman-object relation. The better operating system is the OS that does not exist. (3) The better database is the database that does not exist. What about the better language ? Holiday greetings to all. Ale. (1) the conventional paradigm treats the computer like another human, and the programmer talk to it! In an Object Environment the machine is a place where things are living. (2) sub-creation understood as the activity of creation been done by humans; as the Creator, but in their imagination. J.R.Tolkien (3) please read "not exist" as "is transparent" to human. ---------- De: Bill Cattey[SMTP:wdc@MIT.EDU] Enviado: Sábado 19 de Diciembre de 1998 12:56 Para: squeak(a)cs.uiuc.edu Asunto: The cadence of Software Engineering. Although I have been aware of Smalltalk for a very long time, (I mentioned it in my Undergraduate Thesis in 1983) I've not been at all serious in my study of it until I learned about Squeak this past October. For the past 15 years, I'd been doing what I'll call 'conventional' software engineering -- taking on multi-month and multi year projets to get something done. Reading Dan Ingalls note about the Squeak 2.3 timeline, I suddenly found myself in a universe with a VERY different sense of how long things take to do. As I've chatted with Squeakers over the past couple months, I understood that my sense of what to do when and how long it took was different, but it seems that it's much more different than I imagined. Let's take a moment to savor how Squeak is changing how we think about what is possible. -wdc

1 0

Re: problem with sockets
by Jeffrey Chapman 19 Dec '98

19 Dec '98

>> It's true, Squeak is broken in this respect. I don't know why they did >> not implement the much more common and reliable Berkeley Socket >> semantics with listen() and accept(), >> where the underlying OS does the connection queue stuff. Implementing >> these semantics on top of a weird socket interface such as that of the >> Mac should be mucht easier than the implementing a reliable server on >> top of a conceptually broken API... For quite a while now, the Mac is using STREAMS. Same thing as Solaris, if I'm not mistaken... the old MacTCP API is still in place for compatibility's sake. I haven't investigated, but is Squeak using that older API? OpenStep-based MacOS flavors, FWIW, will have Berkeley Sockets and a STREAMS compatibility layer. I've seen various servers ported from Unix that implement listen()/accept() on MacOS. Maybe something similar could be done in Squeak?

1 0

Re: problem with sockets
by Michael S. Klein 19 Dec '98

19 Dec '98

> > Is this true? Is there a workaround, or is Squeak just broken? > > It's true, Squeak is broken in this respect. I don't know why they did > not implement the much more common and reliable Berkeley Socket > semantics with listen() and accept(), > where the underlying OS does the connection queue stuff. Implementing > these semantics on top of a weird socket interface such as that of the > Mac should be mucht easier than the implementing a reliable server on > top of a conceptually broken API... I experienced the same problems working on an internet video game in squeak. I think that part of the problem is cultural. Squeak wants to pretend that there is such a thing as vanilla hardware (and in this case, vanilla networking), but the reality of the situation is that keyboards *are* different, mice don't all have the same number of buttons, and networking apis are not all the same. Clearly, Macintosh is Squeak's native platform. Now don't get me wrong... I think Squeak's approach to pretending that the supporting machine is vanilla is admirable, but i think that a more unified approach to handling differences when they arise is warranted. Perhaps pluggable primitives can be used to map a "common subset" semantics to native calls in image code, rather than VM code. Of course, one still needs to define a reasonable common subset, and I think that, for networking, TCP/IP and Berkeley sockets are the way to go. Is anyone using squeak for non-TCP/IP networking? AppleTalk? -- Mike

1 0

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

Jump to page: