Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

timrowledge
I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.

Running the GoogleWikiCompiler example failed! Oh noes!

Turns out that in GoogleWikiCompiler>LinkShort: the use of
address, '.html'
to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String - after all, it's a collection of characters, right?

However, Chris has changed that for MaClientServer such the String is returned as
Array with: theString
which doesn't play nice with the above.

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

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 perplexity when mixing xtreams and client server packages.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it



Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Levente Uzonyi
Hi Tim,

On Mon, 12 Aug 2019, tim Rowledge wrote:

> I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.
>
> Running the GoogleWikiCompiler example failed! Oh noes!
>
> Turns out that in GoogleWikiCompiler>LinkShort: the use of
> address, '.html'
> to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String - after all, it's a collection of characters, right?
>
> However, Chris has changed that for MaClientServer such the String is returned as
> Array with: theString
> which doesn't play nice with the above.
>
> 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 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.
>
> 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 perplexity when mixing xtreams and client server packages.
If MaClientServer implements String >> #asCollection, then that's a
mistake, which breaks #,.

I came to the conclusion that without a proper html generator,
GoogleWikiCompiler cannot create correct output.
I have attached a version of GoogleWikiCompiler (attached), which uses our
internal tool: StreamingHtmlCanvas (also attached) to generate html.
Yes, that's another dependency, but that's how things go, isn't it? :)

Also, I had to convert the address variable to a string in links actions.
I think you've done the same in your image.

Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it


StreamingHtmlCanvas-klub.33.mcz (19K) Download Attachment
GoogleWikiCompiler.1.st (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

timrowledge


> On 2019-08-12, at 5:47 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Tim,
>
[snip]
> If MaClientServer implements String >> #asCollection, then that's a mistake, which breaks #,.

Yeah, probably. I doubt Chris did it capriciously though, so he may have some good reasons.

>
> I came to the conclusion that without a proper html generator, GoogleWikiCompiler cannot create correct output.

Oh, well I have just a couple of minutes ago been generating pages that safari is perfectly happy with using

(GoogleWikiCompiler process: '= *Hello*
_italic stuff_
A link [link]
A longer link to an outside site [foo>http:\\www.foo.com/wibble]

Should be a paragraph break before this.
---
This should     be preformatted ---
* abullet
*  another one
** bullet2
# an unordered list
# a second unordered item
{{{
some code := other}}}

|| Table header row || second column||
|| 4 || 5 thing ||
') asString


> I have attached a version of GoogleWikiCompiler (attached), which uses our internal tool: StreamingHtmlCanvas (also attached) to generate html.
> Yes, that's another dependency, but that's how things go, isn't it? :)
>
> Also, I had to convert the address variable to a string in links actions. I think you've done the same in your image.

Sounds like it -
GoogleWikiDomNode a
                attributes: { 'href' -> ((address as: String), '.html') };
for example.

I'll take a look at your changes too. I do wonder how little of the Xtreams package one could load to get a working parser; it doesn't appear to use a lot so far? Adding 4Mb to my image seems a bit much. What other value does Xtreams have?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Don't document the program; program the document.



Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Chris Cunnington-4
This is a great thread. I’m glad to see Xtreams Parsing getting better Actor examples. 

On Aug 12, 2019, at 9:11 PM, tim Rowledge <[hidden email]> wrote:

What other value does Xtreams have?

It’s supposed to be an replacement for the Streams packages. All of it.
If I understand it correctly, Martin and Willow didn’t like the back and forth between read/write, so they made streams work like blocks. 
It's a little beyond my pay grade so I’ll just give  you the ESUG 2010 talk. [1]

Chris 




Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Chris Muller-3
In reply to this post by timrowledge
HI Tim,

That method was an experiment from last year that shouldn't have been part of the release package yet.  Please revert BrpExtensions-cmm.16 back to BrpExtensions-cmm.15 and it'll be gone.  It's not needed by Ma client server.

I've fixed the SqueakMap entry.  I'll have to research why I thought I wanted to do that later.

Let me know if you run into any other issues.

 - Chris

On Mon, Aug 12, 2019 at 8:11 PM tim Rowledge <[hidden email]> wrote:


> On 2019-08-12, at 5:47 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Tim,
>
[snip]
> If MaClientServer implements String >> #asCollection, then that's a mistake, which breaks #,.

Yeah, probably. I doubt Chris did it capriciously though, so he may have some good reasons.

>
> I came to the conclusion that without a proper html generator, GoogleWikiCompiler cannot create correct output.

Oh, well I have just a couple of minutes ago been generating pages that safari is perfectly happy with using

(GoogleWikiCompiler process: '= *Hello*
_italic stuff_
A link [link]
A longer link to an outside site [foo>http:\\www.foo.com/wibble]

Should be a paragraph break before this.
---
This should     be preformatted ---
* abullet
*  another one
** bullet2
# an unordered list
# a second unordered item
{{{
some code := other}}}

|| Table header row || second column||
|| 4 || 5 thing ||
') asString


> I have attached a version of GoogleWikiCompiler (attached), which uses our internal tool: StreamingHtmlCanvas (also attached) to generate html.
> Yes, that's another dependency, but that's how things go, isn't it? :)
>
> Also, I had to convert the address variable to a string in links actions. I think you've done the same in your image.

Sounds like it -
GoogleWikiDomNode a
                attributes: { 'href' -> ((address as: String), '.html') };
for example.

I'll take a look at your changes too. I do wonder how little of the Xtreams package one could load to get a working parser; it doesn't appear to use a lot so far? Adding 4Mb to my image seems a bit much. What other value does Xtreams have?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Don't document the program; program the document.





Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

timrowledge


> On 2019-08-12, at 7:00 PM, Chris Muller <[hidden email]> wrote:
>
> HI Tim,
>
> That method was an experiment from last year that shouldn't have been part of the release package yet.  Please revert BrpExtensions-cmm.16 back to BrpExtensions-cmm.15 and it'll be gone.  It's not needed by Ma client server.

Excellent news; so no clash to worry about at all. Always the easiest way to solve a problem...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Sep 19th ; talk like a pirate day - http://www.talklikeapirate.com/piratehome.html


Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Chris Muller-3
In reply to this post by Levente Uzonyi
Just for a clarification:

On Mon, 12 Aug 2019, tim Rowledge wrote:

> I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.
>
> Running the GoogleWikiCompiler example failed! Oh noes!
>
> Turns out that in GoogleWikiCompiler>LinkShort: the use of
> address, '.html'
> to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String

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:

   myObject1, myObject2, myObject3    "==> { myObject1. myObject2. myObject3 }"

It was also to allow input arguments of methods which expected collection arguments to also allow single arguments.

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.

GoogleWikiCompiler should be fixed.


- after all, it's a collection of characters, right?
>
> However, Chris has changed that for MaClientServer such the String is returned as
> Array with: theString
> which doesn't play nice with the above.
>
> 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 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.
>
> 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 perplexity when mixing xtreams and client server packages.

If MaClientServer implements String >> #asCollection, then that's a
mistake, which breaks #,.

No it doesn't.  The package also adds Collection>>#, to maintain the proper function, but Tim simply didn't mention that.

Best,
  Chris


 

I came to the conclusion that without a proper html generator,
GoogleWikiCompiler cannot create correct output.
I have attached a version of GoogleWikiCompiler (attached), which uses our
internal tool: StreamingHtmlCanvas (also attached) to generate html.
Yes, that's another dependency, but that's how things go, isn't it? :)

Also, I had to convert the address variable to a string in links actions.
I think you've done the same in your image.

Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it


Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Levente Uzonyi
On Mon, 12 Aug 2019, Chris Muller wrote:

> Just for a clarification:
>
>       On Mon, 12 Aug 2019, tim Rowledge wrote:
>
>       > I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.
>       >
>       > Running the GoogleWikiCompiler example failed! Oh noes!
>       >
>       > Turns out that in GoogleWikiCompiler>LinkShort: the use of
>       > address, '.html'
>       > to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String
>
>
> 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:
>
>    myObject1, myObject2, myObject3    "==> { myObject1. myObject2. myObject3 }"
>
> It was also to allow input arguments of methods which expected collection arguments to also allow single arguments.
>
> 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.
>
> GoogleWikiCompiler should be fixed.
So, in your opinion, should

  #($a $b $c), 'def'

give

  #($a $b $c $d $e $f)

or

  #($a $b $c 'def')

?

(GoogleWikiCompiler/Xtreams-Parsing assumes the former, that's the
behavior in trunk images, and that's what I would expect as well.)

>
>
>       - after all, it's a collection of characters, right?
>       >
>       > However, Chris has changed that for MaClientServer such the String is returned as
>       > Array with: theString
>       > which doesn't play nice with the above.
>       >
>       > 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
>       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.
>       >
>       > 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
>       perplexity when mixing xtreams and client server packages.
>
>       If MaClientServer implements String >> #asCollection, then that's a
>       mistake, which breaks #,.
>
>
> No it doesn't.  The package also adds Collection>>#, to maintain the proper function, but Tim simply didn't mention that.
YOu mean it overwrites the existing Collection >> #, changing its
behavior - aka breaking #,.

Levente

>
> Best,
>   Chris
>
>
>  
>
>       I came to the conclusion that without a proper html generator,
>       GoogleWikiCompiler cannot create correct output.
>       I have attached a version of GoogleWikiCompiler (attached), which uses our
>       internal tool: StreamingHtmlCanvas (also attached) to generate html.
>       Yes, that's another dependency, but that's how things go, isn't it? :)
>
>       Also, I had to convert the address variable to a string in links actions.
>       I think you've done the same in your image.
>
>       Levente
>
>       >
>       > tim
>       > --
>       > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>       > Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Chris Muller-4
> Just for a clarification:
>
>       On Mon, 12 Aug 2019, tim Rowledge wrote:
>
>       > I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.
>       >
>       > Running the GoogleWikiCompiler example failed! Oh noes!
>       >
>       > Turns out that in GoogleWikiCompiler>LinkShort: the use of
>       > address, '.html'
>       > to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String
>
>
> 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:
>
>    myObject1, myObject2, myObject3    "==> { myObject1. myObject2. myObject3 }"
>
> It was also to allow input arguments of methods which expected collection arguments to also allow single arguments.
>
> 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.
>
> GoogleWikiCompiler should be fixed.

So, in your opinion, should

        #($a $b $c), 'def'

give

        #($a $b $c $d $e $f)

or

        #($a $b $c 'def')

?

If one is interested in using powerful concatenation syntax, it should answer the latter.
 

(GoogleWikiCompiler/Xtreams-Parsing assumes the former, that's the
behavior in trunk images, and that's what I would expect as well.)

Why do you want to use an inefficient Array of characters instead of a String of them that would respond basically the same?

 

>
>
>       - after all, it's a collection of characters, right?
>       >
>       > However, Chris has changed that for MaClientServer such the String is returned as
>       > Array with: theString
>       > which doesn't play nice with the above.
>       >
>       > 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
>       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.
>       >
>       > 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
>       perplexity when mixing xtreams and client server packages.
>
>       If MaClientServer implements String >> #asCollection, then that's a
>       mistake, which breaks #,.
>
>
> No it doesn't.  The package also adds Collection>>#, to maintain the proper function, but Tim simply didn't mention that.

YOu mean it overwrites the existing Collection >> #, changing its
behavior - aka breaking #,.

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.

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

 - Chris

 

Levente

>
> Best,
>   Chris
>
>
>  
>
>       I came to the conclusion that without a proper html generator,
>       GoogleWikiCompiler cannot create correct output.
>       I have attached a version of GoogleWikiCompiler (attached), which uses our
>       internal tool: StreamingHtmlCanvas (also attached) to generate html.
>       Yes, that's another dependency, but that's how things go, isn't it? :)
>
>       Also, I had to convert the address variable to a string in links actions.
>       I think you've done the same in your image.
>
>       Levente
>
>       >
>       > tim
>       > --
>       > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>       > Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
>
>
>