Hi All,
In spirit with what I proposed about making larger teams, Göran and I decided to merge the File and Network teams. Both packages are roughly in a state of "we could do with a revamp" and they touch in many places (URL's, Streams, etcetera) so it seems a logical thing to do.
For the time being, I'll lead the new team which I think is best labelled as "I/O team" (risking that we get the Midi and Serial code thrown in as well ;-)). The strategy of both teams was already closely aligned: first, vacuum Mantis during 3.9a, then decide on revamping the code.
I'll wait a day to see if there are very big protests ;-), and then commence with getting the infrastructure adapted. The next team report will then have more details on the "life after 3.9" plans.
Regards,
Cees
On Tue, Jan 03, 2006 at 07:47:56PM +0100, Cees De Groot wrote:
In spirit with what I proposed about making larger teams, Göran and I decided to merge the File and Network teams. Both packages are roughly in a state of "we could do with a revamp" and they touch in many places (URL's, Streams, etcetera) so it seems a logical thing to do.
+1
On 1/4/06, stéphane ducasse ducasse@iam.unibe.ch wrote:
Waiting for Flow or any other progress :)
Flow is a strong candidate for the network side, indeed. For the files side, I chatted a bit with Tim and we think that the VW model is worth copying - it is good, written by a what I heard is a brilliant Smalltalk developer ;-), and it would increase compatibility with VW.
BTW - for both issues I am very strongly considering a "burn the diskpacks" approach. Interaction with files and networking is minimal for the vast majority of code, so porting would be much, much easier than keeping two API versions in the image. We could carry the old primitives around for a couple of years and have the old stuff available on SqueakMap or something for people who insist on backwards compatibility, but I would need to hear extremely strong arguments for burdening this project with all sorts of backwards compatibility requirements...
Regards,
Cees
Hi--
Stéphane writes:
Waiting for Flow or any other progress :)
Cees responds:
Flow is a strong candidate for the network side, indeed. For the files side, I chatted a bit with Tim and we think that the VW model is worth copying - it is good, written by a what I heard is a brilliant Smalltalk developer ;-), and it would increase compatibility with VW.
For what it's worth... Flow derives from a fundamental separation of stream, name, and resource for all external resources (files, sockets, serial and parallel ports, MIDI ports, etc.). This is conceptually compatible with VisualWork's notions of filenames and file "accessors", and allows for platform-specific support. I find that the details in VisualWorks become overly complicated, but I think we could be compatible with it.
-C (author of Flow, http://netjam.org/flow )
for VW we should pay attention not to reproduce their idea to raise an exception when Stream EOF (if I remember) since I gave us a lot of trouble. I could asked roel the problem with got with that.
Stef
On 4 janv. 06, at 19:31, Cees De Groot wrote:
On 1/4/06, stéphane ducasse ducasse@iam.unibe.ch wrote:
Waiting for Flow or any other progress :)
Flow is a strong candidate for the network side, indeed. For the files side, I chatted a bit with Tim and we think that the VW model is worth copying - it is good, written by a what I heard is a brilliant Smalltalk developer ;-), and it would increase compatibility with VW.
BTW - for both issues I am very strongly considering a "burn the diskpacks" approach. Interaction with files and networking is minimal for the vast majority of code, so porting would be much, much easier than keeping two API versions in the image. We could carry the old primitives around for a couple of years and have the old stuff available on SqueakMap or something for people who insist on backwards compatibility, but I would need to hear extremely strong arguments for burdening this project with all sorts of backwards compatibility requirements...
Regards,
Cees
stéphane ducasse wrote:
for VW we should pay attention not to reproduce their idea to raise an exception when Stream EOF (if I remember) since I gave us a lot of trouble. I could asked roel the problem with got with that.
Stef
I think that the problem is that it is a Notification. Easily ignored but as soon as you put a "catch all" handler ([] on: Exception do: [:ex| ...]) around a segment which raises it you all-of-a-sudden start seeing these exceptions. I could be wrong here but I think that's the problem. I think that catching Exception is generally not a good idea though.
David
David Shaffer wrote:
I think that the problem is that it is a Notification. Easily ignored but as soon as you put a "catch all" handler ([] on: Exception do: [:ex| ...]) around a segment which raises it you all-of-a-sudden start seeing these exceptions. I could be wrong here but I think that's the problem. I think that catching Exception is generally not a good idea though.
Now it's coming back to me....the problem is when you nest I/O.
[self doSomethingWith: someStream next] on: EndOfStreamNotification do: [:ex | ]
causes problems if doSomethingWith is written as:
doSomethingWith: someObject [someOtherStream atEnd] whileFalse: [someOtherStream next]
because the "someOtherStream next" will eventually raise EndOfStreamNotification which will be caught by the outer handler. Of course in real life you get tripped up by a method you didn't write which follows a convension you didn't expect (maybe you didn't even know it used a stream!).
David
Yes this was something like that...Terrible.
I think that the problem is that it is a Notification. Easily ignored but as soon as you put a "catch all" handler ([] on: Exception do: [:ex| ...]) around a segment which raises it you all-of-a-sudden start seeing these exceptions. I could be wrong here but I think that's the problem. I think that catching Exception is generally not a good idea though.
Now it's coming back to me....the problem is when you nest I/O.
[self doSomethingWith: someStream next] on: EndOfStreamNotification do: [:ex | ]
causes problems if doSomethingWith is written as:
doSomethingWith: someObject [someOtherStream atEnd] whileFalse: [someOtherStream next]
because the "someOtherStream next" will eventually raise EndOfStreamNotification which will be caught by the outer handler. Of course in real life you get tripped up by a method you didn't write which follows a convension you didn't expect (maybe you didn't even know it used a stream!).
David
Yes this was something like that...Terrible.
Another terrible incompatibility thing that just recently hit me, is the different behaviour of #upTo: and #upToAll: in Squeak and VisualWorks. Guess what: VisualWorks sets the stream-position right before the match, Squeak after the match; making it impossible to use these methods in code that should run on both dialects.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli schrieb:
Yes this was something like that...Terrible.
Another terrible incompatibility thing that just recently hit me, is the different behaviour of #upTo: and #upToAll: in Squeak and VisualWorks. Guess what: VisualWorks sets the stream-position right before the match, Squeak after the match; making it impossible to use these methods in code that should run on both dialects.
VAST, VW and ObjectStudio sets the position after the match ...
Marten
VAST, VW and ObjectStudio sets the position after the match ...
stream := '12345' readStream. (stream upToAll: '23') -> (stream upToEnd).
VW: '1'->'2345' Squeak: '1'->'45'
Don't know about the others.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli schrieb:
VAST, VW and ObjectStudio sets the position after the match ...
stream := '12345' readStream. (stream upToAll: '23') -> (stream upToEnd).
VW: '1'->'2345' Squeak: '1'->'45'
Don't know about the others.
VA: '1' -> '45' ObjectStudio as VW ... actually this seems strange for me, because upToAll: and upTo: reacts differently. upTo: position after the match, upToAll: position before the match.
squeak-dev@lists.squeakfoundation.org
-
Cees De Groot -
Craig Latta -
David Shaffer -
David T. Lewis -
Lukas Renggli -
Marten Feldtmann -
stéphane ducasse