<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>