<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Just for a clarification:<br>
><br>
> On Mon, 12 Aug 2019, tim Rowledge wrote:<br>
><br>
> > I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.<br>
> ><br>
> > Running the GoogleWikiCompiler example failed! Oh noes!<br>
> ><br>
> > Turns out that in GoogleWikiCompiler>LinkShort: the use of<br>
> > address, '.html'<br>
> > to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String<br>
> <br>
> <br>
> That's a bug in that code. Brent Pinkney originally implemented #asCollection to be a pointer collection (e.g., not bytes), to support concatenation syntax, as in:<br>
> <br>
> myObject1, myObject2, myObject3 "==> { myObject1. myObject2. myObject3 }"<br>
> <br>
> It was also to allow input arguments of methods which expected collection arguments to also allow single arguments.<br>
> <br>
> The history is, it was proposed for Squeak, but someone objected, but to at least _allow_ people to load and use it optionally, Collection>>#asCollection and two senders in core code were needed.<br>
> <br>
> GoogleWikiCompiler should be fixed.<br>
<br>
So, in your opinion, should<br>
<br>
#($a $b $c), 'def'<br>
<br>
give<br>
<br>
#($a $b $c $d $e $f)<br>
<br>
or<br>
<br>
#($a $b $c 'def')<br>
<br>
?<br></blockquote><div><br></div><div><div>If one is interested in using powerful concatenation syntax, it should answer the latter.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(GoogleWikiCompiler/Xtreams-Parsing assumes the former, that's the <br>
behavior in trunk images, and that's what I would expect as well.)<br></blockquote><div><br></div><div><div>Why do you want to use an inefficient Array of characters instead of a String of them that would respond basically the same?</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
><br>
> - after all, it's a collection of characters, right?<br>
> ><br>
> > However, Chris has changed that for MaClientServer such the String is returned as<br>
> > Array with: theString<br>
> > which doesn't play nice with the above.<br>
> ><br>
> > I'm not entirely sure I like either approach really; #($a $b $c) , 'foo' doesn't seem like such a great thing to do, especially if you can't guarantee what the actual state of the 'address' object is (that's a<br>
> bigger issue around the parser behaviour) BUT 'foo' asCollection -> #( 'foo') doesn't seem quite nice either. I could sort of appreciate 'foo' asCollection -> #($f $o $o) I suppose.<br>
> ><br>
> > The immediate solution within the context of the swiki parsing is to carefully make sure the address is actually a string, so no major issue for me today, but this does indicate a potentially problematic<br>
> perplexity when mixing xtreams and client server packages.<br>
><br>
> If MaClientServer implements String >> #asCollection, then that's a<br>
> mistake, which breaks #,.<br>
> <br>
> <br>
> No it doesn't. The package also adds Collection>>#, to maintain the proper function, but Tim simply didn't mention that.<br>
<br>
YOu mean it overwrites the existing Collection >> #, changing its <br>
behavior - aka breaking #,.<br></blockquote><div><br></div><div>Sorry, I mis-spoke -- Collection>>#, is from Brents original concatenation-syntax, but it's also the one we moved into trunk -- not overridden. But, nor is String>>#, broken, since String overrides #, too.</div><div><br></div><div>Tim ran into a situation I never expected anyone would do or want to do -- use a Pointer collection to refer to a series of bytes. It seems unnecessarily inefficient...</div><div><br></div><div> - Chris</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Levente<br>
<br>
> <br>
> Best,<br>
> Chris<br>
> <br>
> <br>
> <br>
><br>
> I came to the conclusion that without a proper html generator,<br>
> GoogleWikiCompiler cannot create correct output.<br>
> I have attached a version of GoogleWikiCompiler (attached), which uses our<br>
> internal tool: StreamingHtmlCanvas (also attached) to generate html.<br>
> Yes, that's another dependency, but that's how things go, isn't it? :)<br>
><br>
> Also, I had to convert the address variable to a string in links actions.<br>
> I think you've done the same in your image.<br>
><br>
> Levente<br>
><br>
> ><br>
> > tim<br>
> > --<br>
> > tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
> > Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it<br>
> <br>
> <br>
></blockquote></div></div>