Hi Martin,
On 12 Jan 2011, at 01:08, [email protected] wrote:
> 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
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:
731 run, 718 passes, 0 expected failures, 0 failures, 13 errors, 0 unexpected
passes
Failures:
Errors:
XTFileReadingWritingTest>>#testReadWriteLargeAmount
XTFileReadingWritingTest>>#testWriteFromCollectionAt
XTFileReadingWritingTest>>#testWriteFromStream
XTFileReadingWritingTest>>#testWriteTransformHexToByte
XTSocketReadingWritingTest>>#testDoing
XTSocketReadingWritingTest>>#testReadCollecting
XTSocketReadingWritingTest>>#testReadInjecting
XTSocketReadingWritingTest>>#testReadWriteLargeAmount
XTSocketReadingWritingTest>>#testSeekForward
XTSocketReadingWritingTest>>#testWriteCollectingIncompatibleContentSpecies
XTSocketReadingWritingTest>>#testWriteCollection
XTSocketReadingWritingTest>>#testWriteFromCollectionAt
XTSocketReadingWritingTest>>#testWriteFromStream
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
