<br><br><div class="gmail_quote">On Wed, Dec 2, 2009 at 10:49 AM, Colin Putney <span dir="ltr"><<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 2-Dec-09, at 8:26 AM, Nicolas Cellier wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Xtream is not functional yet, it is just a three evenings shot.<br>
</blockquote>
<br></div>
At the rate you're going, you'll have caught up to the functionality in Filesystem in no time. ;-)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Especially pipelines are quite tricky with a forked process... I got<br>
to rest a bit and think.<br>
This kind of implementation natively has good parallelism properties,<br>
unfortunately this won't exploit multi-core/processors any time soon<br>
in Smalltalk...<br>
</blockquote>
<br></div>
I'm guessing you mean running each stage of the stream in a separate Smalltalk Process, using the Pipes and Filters pattern?<br>
Stephen Pair did some neat stuff with that a few years ago. It's indeed tricky. I wonder if it's worth it in this case, though, exactly because Smalltalk doesn't exploit multiprocessors. Flow of control inside a stream might be complicated without parallelism, but it's probably easier to debug.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A few month ago, I implemented a simple Wrapper-like scheme, but was<br>
not satisfied with end of stream handling. Both EndOfStream exception<br>
capture and atEnd tests are expensive when processing elements 1 by 1.<br>
Maybe I'll have to turn to such a more simple scheme though.<br>
</blockquote>
<br></div>
I don't understand the issue with EndOfStream exceptions. Throwing and catching an exception is expensive, yes, but that should happen only once, right? Unless you're setting up exception handler inside a loop, the expense of a single exception shouldn't be a problem.</blockquote>
<div><br></div><div>Exception search and delivery is, uh, /expensive/. The cost of propagating an EndOfStream exception to its defaultAction and returning nil is huge compared to simply answering an end-of-stream value. So unless one really wants exception handling one should strive to avoid raising EndOfStream exceptions at end of stream.</div>
<div><br></div><div>I think in VisualWorks we noticed the extreme expense in the ChangeList scanner where one is creating lots of streams on strings corresponding to each chunk. The end-of-stream exceptions on all these streams when doing something like scanning a changes file would add up to a significant percentage of the entire parse time. So believe me, it does add up.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Definitely, we should exchange code/ideas.<br>
</blockquote>
<br></div>
Agreed. We may find that doing parallel development with lots of cross-pollination is the best way to explore the design space.<br><font color="#888888">
<br>
Colin<br>
<br>
</font></blockquote></div><br>