Xtreams up to date

Hope it's OK to cross-post this, I figured there might be interested people on both sides. I finished the updates of the Xtreams port to match the VW version, so everything (that is available) should work as advertised in the documentation (http://code.google.com/p/xtreams/).

Besides the implementation updates this last round of changes includes:

* repackaging to match the docs and VW better, the dialect specific parts are now (mostly) gathered in Xtreams-Support

* there is now a Gofer expression on the project page (http://www.squeaksource.com/Xtreams.html) to help people loading it, it shouldn't be hard to keep it up to date it shouldn't change very much

* the source code is now identical between the dialects as much as possible, to help keeping it up to date.

* one significant API change is that we renamed XTIncomplete to Incomplete to make code that uses Xtreams more portable. This is the only class that is very prominent in the API and hard to avoid in any sufficiently complex application, hopefully this is acceptable.

I don't anticipate any significant changes in the port for next little while. I'd like to play with Squeak FFI next to see if I can bring the cryptographic streams from Xtreams-Xtras over and then see what it would take to get Xtreams-SSH2 running on Squeak and how it would perform. If you're curious how it went on VW side, I wrote about that in a blog post here: http://www.cincomsmalltalk.com/userblogs/cst/blogView.

If you find bugs or issues, feel free to file an issue on the google project page (http://code.google.com/p/xtreams/issues/list). I'm monitoring both of these lists now as well and will try to answer any questions promptly.

Cheers!

Martin

thansk martin

Stef

On Jan 12, 2011, at 1:08 AM, [hidden email] wrote:

Hi Martin,

On 12 Jan 2011, at 01:08, [hidden email] wrote:
Thank you for all this work, this is a really interesting project, I am glad you are putting in the effort to bring this to Pharo/Squeak.

I tried the Gofer script to load Xtreams into a fresh Pharo 1.1.1 #11414. This went OK for two issues:

XTSqueakEncoder class>>initialize(name is shadowed) - more a warning I guess

XTReadStream>>detect: (NotFoundError is Undeclared) - it seems other #detect: implementors just do self error: 'Not Found', but a real exception would be better

Running all tests, I get 718 OK out of 731; 13 errors:




Most of these are with sockets. I tried to look at one of the others XTFileReadingWritingTest>>#testWriteFromCollectionAt

        | data |
        data := #[1 2 3 4 5 6 7].
        self assert: (self output write: 4 from: data at: 1) = 4.
        self assert: (self input read: 4) = (data first: 4).
        self assert: (self output write: 3 from: data at: 5) = 3.
        self assert: (self input read: 3) = (data last: 3)

The failure is at the last assertion. If I understand the code correctly, you write to a file in 2 steps (and yes the file contains the data). The input stream is created lazily, after the first write. But it seems strange to me to expect an open reading file stream to see newly written data ? Closing/reopening input works as expected. So you are also testing a particular OS feature here IMHO. Maybe this works on some OS's but it does not seem to work for me (Mac OS X, Cog VM), but other elements might be involved (caching/buffering at various levels, vm, primitives, ..).

I think all the non-socket failures have the same issue.

Sven

"Sven Van Caekenberghe"<[hidden email]> wrote:
> Thank you for all this work, this is a really interesting project, I am glad you are putting in the effort to bring this to Pharo/Squeak.

Thanks. It's Nicolas who deserves the praise. I'm just trying to help out.

The intent of the test certainly is that the data would be visible. It's the same generic test we run across all the terminals. I can't give any authoritative statement whether it should work with files everywhere or not, but I can say that it does work across Linux, Windows and OSX in VW. I think the key aspect of this tests is that it's the same process doing the reading and writing. Actually maybe it's even that it must be the same descriptor. I'll have to take a closer look to see what's going on, but it seems to pass for me with Pharo (1.1.1 or 1.2, cog or standard VM) on Linux. I can test it on Windows as well, but I don't have OSX available for this. Does anyone know if it is reasonable to expect it to work on OSX ? I'm certainly not bent on keeping the test that way, our primary goal is to test the API on all terminals. But if it is meant to work this way even on files, then we probably should keep it that way.