Resent, reply to all... 2010/10/9 Michael Lucas-Smith <[email protected]>: >> >> Hehe, I've got the feeling to surf on your hard work with low investment ;) >> Xtream ideas should definitly continue to attract. J'espère que la >> mayonnaise va prendre. >> Of course the best option is to share. Though I don't think Xtream was >> developped with portability as main goal, it's not sure it has so many >> external dependencies. >> Is there a tool to identify the dependency on classes outside the >> package in VW ? >> We know in advance a few concerning the system, File & Sockets, DLLCC, >> compression... >> With good package delimitation, that can be worked out. > > We divided the Xtreams packages up with this in mind. The Core should be > portable, the Terminals are not -- they must be implemented for each platform > because they're the ones that use the platform specific objects. >
I'm browsing VW right now, at first sight there are not so many uncompatibilities in core, should be solved easily Incomplete>>#raise could be added (#signal in Squeak) #copyEmpty: could be an extension #isFixedArgument not existing in Squeak (external heap notion exists though) Lack of namespace in Squeak shall force use of a prefix (XT ?). Some terminals are generic and should port easily too: BlockClosure/Buffer/Collection For File, assuming they are non blocking, we can arrange a quick hack. For transforms, the StreamEncoder does not exist in Squeak (better not use existing Multilingual, a rewrite will be cleaner). >> The problem with Squeak is that we don't have a good File library (non >> blocking). The good point with Xtream is that we don't need that many >> primitives. >> And last good point is the huge effort you made to coverage tests... >> That should ease porting. > > It's okay if not all terminals and transformation are supported on every > platform. We could create a capabilities grid for the different ports to show > what can and can't be done. > >> >> Then, there is the question of using Exception handling or not. In >> Squeak, this isn't going to be a matter of compatibility (though the >> difference might be subtle), rather a matter of efficiency. >> However, Incomplete is a corner stone of Xtream implementation if I >> understand correctly... >> Squeak is not using EndOfStream >> http://bugs.squeak.org/view.php?id=6755 and some of the efficiency >> reasons are there >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122434.html > > Even in VisualWorks Exceptions are expensive. We went to great lengths to > make sure the exception mechanism did not fire constantly. We spent several > agonizing weeks studying the effects of our implementation on garbage > generation and efficiency until we finally arrived at the design we have now. > The biggest problems were with substreaming which we eventually solved. > > Michael The simplest thing is just to port a few classes then bench... That's worth a try. Nicolas _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
