Re: [Pharo-users] Spec Adapter Advice

[Ben Coman]

Hi Dennis,

On Fri, Apr 28, 2017 at 7:09 AM, Rob Rothwell 
wrote:

> Hi Peter,
>
> Thank you very much for that overview!
>
> It looks like even just creating a window with no other widgets is sort of
> "hard-wired" to Morphic through ComposableModel>>defaultWindowModelClass,
> so maybe just overriding that and trying to create a Cocoa window model and
> adapter is the place to start.
>
> I need to find a good starting point because you can't poke at the
> existing code too much since even the debugger is built with Spec!
>

Would your remote IDE [1] be suitable to help Rob to hack around Spec
without blowing up his IDE?
But I think its only available on Pharo 6?

[1]
http://forum.world.st/Ann-PharmIDE-Pharo-remote-IDE-to-develop-farm-of-Pharo-images-remotely-td4930602.html


cheers -ben



>
> It's pretty exciting, though, because it feels like all the right pieces
> are there and a lot of this could mostly be "just work" once I get going.
>
> Thanks again,
>
> Rob
>
> On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak  wrote:
>
>> Hi Rob,
>>
>> I guess the best resource at the moment is to just look at existing
>> adapters.
>>
>> But here are some thoughts to get you started:
>>
>> (Spec) ComposableModel has as its widget (Spec) Adapter
>> Adapter has as its widget the actual visual component, which currently
>> means Morphic.
>>
>>
>> The simplest example: LabelModel
>>
>> 1. model to adapter
>>
>> LabelModel is adapted by MorphicLabelAdapter:
>>
>> you can see on the class side in method `defaultSpec`.
>> There is only `LabelAdapter` there because there is some extra mapping
>> for some classes, but you can specify directly the class of the Adapter, so
>> the following would work just as well:
>>
>> LabelModel class>>defaultSpec
>> 
>>
>> ^ #(MorphicLabelAdapter
>> adapt: #(model))
>>
>>
>> LabelModel -> LabelAdapter direct event propagation (pushing changes)
>>
>> in Model world you can call changed:with: to execute code on the Adapter,
>> e.g.
>>
>> self changed: #emphasis: with: {emphasis}
>>
>> which in turn will call the #emphasis: method on the LabelAdapter.
>>
>> LabelModel -> LabelAdapter events (pulling changes)
>>
>> preferred alternative is to do the opposite; properties of models are
>> often held in ValueHolders, which can be observed on ValueChange, so the
>> Adapter can register to event change and react on itself;
>>
>> you can see this best in MorphicTabAdapter (but you will see that
>> TabAdapter looks a bit different from the rest, because I was experimenting
>> with cleaning up Adapters...)
>>
>> 2. adapter to morphic
>>
>> Every adapter implements #buildWidget method that returns a Morphic
>> Object.
>> Typically the adapter registers itself as the model of the adapter (so
>> adapter's model is Spec, and Morphic's model is the adapter). This depends
>> a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
>> there's no buildWidget, and it is in #buildWidgetWith:).
>>
>> It is all kinds of messy, but if you have other widgets then it will be a
>> good test how well Spec can handle it... or rather we'll see how it can be
>> improved...
>>
>> Peter
>>
>>
>>
>> On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
>> > Hello,
>> >
>> > I have recently been lucky enough to get the Cocoa portion of Mars
>> working
>> > on Pharo 5.0.  While there are some issues, it has a wonderful set of
>> > examples that allowed me create new Cocoa classes and delegate methods
>> and
>> > see a straightforward path to learning how to use Coco widgets from
>> Pharo.
>> >
>> > I'd like to do that by creating appropriate Spec adapters, but
>> > unfortunately the new Spec booklet wasn't designed for that!
>> >
>> > Can anyone give me any insight into creating (and using) a new Spec
>> > adapter?  Maybe just some high level steps to help me orient my
>> > investigation into how Spec works?
>> >
>> > Thank you,
>> >
>> > Rob
>>
>>
>

Re: [Pharo-users] Spec Adapter Advice

[Rob Rothwell]

Hi Peter,

Thank you very much for that overview!

It looks like even just creating a window with no other widgets is sort of
"hard-wired" to Morphic through ComposableModel>>defaultWindowModelClass,
so maybe just overriding that and trying to create a Cocoa window model and
adapter is the place to start.

I need to find a good starting point because you can't poke at the existing
code too much since even the debugger is built with Spec!

It's pretty exciting, though, because it feels like all the right pieces
are there and a lot of this could mostly be "just work" once I get going.

Thanks again,

Rob

On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak  wrote:

> Hi Rob,
>
> I guess the best resource at the moment is to just look at existing
> adapters.
>
> But here are some thoughts to get you started:
>
> (Spec) ComposableModel has as its widget (Spec) Adapter
> Adapter has as its widget the actual visual component, which currently
> means Morphic.
>
>
> The simplest example: LabelModel
>
> 1. model to adapter
>
> LabelModel is adapted by MorphicLabelAdapter:
>
> you can see on the class side in method `defaultSpec`.
> There is only `LabelAdapter` there because there is some extra mapping for
> some classes, but you can specify directly the class of the Adapter, so the
> following would work just as well:
>
> LabelModel class>>defaultSpec
> 
>
> ^ #(MorphicLabelAdapter
> adapt: #(model))
>
>
> LabelModel -> LabelAdapter direct event propagation (pushing changes)
>
> in Model world you can call changed:with: to execute code on the Adapter,
> e.g.
>
> self changed: #emphasis: with: {emphasis}
>
> which in turn will call the #emphasis: method on the LabelAdapter.
>
> LabelModel -> LabelAdapter events (pulling changes)
>
> preferred alternative is to do the opposite; properties of models are
> often held in ValueHolders, which can be observed on ValueChange, so the
> Adapter can register to event change and react on itself;
>
> you can see this best in MorphicTabAdapter (but you will see that
> TabAdapter looks a bit different from the rest, because I was experimenting
> with cleaning up Adapters...)
>
> 2. adapter to morphic
>
> Every adapter implements #buildWidget method that returns a Morphic Object.
> Typically the adapter registers itself as the model of the adapter (so
> adapter's model is Spec, and Morphic's model is the adapter). This depends
> a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> there's no buildWidget, and it is in #buildWidgetWith:).
>
> It is all kinds of messy, but if you have other widgets then it will be a
> good test how well Spec can handle it... or rather we'll see how it can be
> improved...
>
> Peter
>
>
>
> On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > Hello,
> >
> > I have recently been lucky enough to get the Cocoa portion of Mars
> working
> > on Pharo 5.0.  While there are some issues, it has a wonderful set of
> > examples that allowed me create new Cocoa classes and delegate methods
> and
> > see a straightforward path to learning how to use Coco widgets from
> Pharo.
> >
> > I'd like to do that by creating appropriate Spec adapters, but
> > unfortunately the new Spec booklet wasn't designed for that!
> >
> > Can anyone give me any insight into creating (and using) a new Spec
> > adapter?  Maybe just some high level steps to help me orient my
> > investigation into how Spec works?
> >
> > Thank you,
> >
> > Rob
>
>

Re: [Pharo-users] Spec Adapter Advice

[Peter Uhnak]

Hi Rob,

I guess the best resource at the moment is to just look at existing adapters.

But here are some thoughts to get you started:

(Spec) ComposableModel has as its widget (Spec) Adapter
Adapter has as its widget the actual visual component, which currently means 
Morphic.


The simplest example: LabelModel

1. model to adapter

LabelModel is adapted by MorphicLabelAdapter:

you can see on the class side in method `defaultSpec`.
There is only `LabelAdapter` there because there is some extra mapping for some 
classes, but you can specify directly the class of the Adapter, so the 
following would work just as well:

LabelModel class>>defaultSpec


^ #(MorphicLabelAdapter
adapt: #(model))


LabelModel -> LabelAdapter direct event propagation (pushing changes)

in Model world you can call changed:with: to execute code on the Adapter, e.g.

self changed: #emphasis: with: {emphasis}

which in turn will call the #emphasis: method on the LabelAdapter.

LabelModel -> LabelAdapter events (pulling changes)

preferred alternative is to do the opposite; properties of models are often 
held in ValueHolders, which can be observed on ValueChange, so the Adapter can 
register to event change and react on itself;

you can see this best in MorphicTabAdapter (but you will see that TabAdapter 
looks a bit different from the rest, because I was experimenting with cleaning 
up Adapters...)

2. adapter to morphic

Every adapter implements #buildWidget method that returns a Morphic Object.
Typically the adapter registers itself as the model of the adapter (so 
adapter's model is Spec, and Morphic's model is the adapter). This depends a 
lot on the API of morphic. (in TabAdapter I'm overriding adapt: so there's no 
buildWidget, and it is in #buildWidgetWith:).

It is all kinds of messy, but if you have other widgets then it will be a good 
test how well Spec can handle it... or rather we'll see how it can be 
improved...

Peter



On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> Hello,
> 
> I have recently been lucky enough to get the Cocoa portion of Mars working
> on Pharo 5.0.  While there are some issues, it has a wonderful set of
> examples that allowed me create new Cocoa classes and delegate methods and
> see a straightforward path to learning how to use Coco widgets from Pharo.
> 
> I'd like to do that by creating appropriate Spec adapters, but
> unfortunately the new Spec booklet wasn't designed for that!
> 
> Can anyone give me any insight into creating (and using) a new Spec
> adapter?  Maybe just some high level steps to help me orient my
> investigation into how Spec works?
> 
> Thank you,
> 
> Rob

[Pharo-users] Spec Adapter Advice

[Rob Rothwell]

Hello,

I have recently been lucky enough to get the Cocoa portion of Mars working
on Pharo 5.0.  While there are some issues, it has a wonderful set of
examples that allowed me create new Cocoa classes and delegate methods and
see a straightforward path to learning how to use Coco widgets from Pharo.

I'd like to do that by creating appropriate Spec adapters, but
unfortunately the new Spec booklet wasn't designed for that!

Can anyone give me any insight into creating (and using) a new Spec
adapter?  Maybe just some high level steps to help me orient my
investigation into how Spec works?

Thank you,

Rob

Re: [Pharo-users] [Ann] Pharo Sprint App to improve coordination during Pharo Sprints

[Juraj Kubelka]

Hi,

Marcus and I have updated the contribute page: 
http://pharo.org/contribute-events  
And I have just released Pharo Sprint App version 0.2.0: 
http://bit.ly/PharoSprintApp  (Discord sprint 
channel includes the link)
To run it, you need Pharo 6.0 VM

Thanks everyone for the early feedback. I was able to include some of them to 
the release.

Have a fun. I will join you at 9:00 UTC-4 time.
Juraj

> On Apr 27, 2017, at 11:03, Luc Fabresse  wrote:
> 
> Nice Juraj! ;-)

Thanks Luc :-)

> 
> #Luc
> 
> 2017-04-24 20:51 GMT+02:00 K K Subbu  >:
> On Monday 24 April 2017 08:00 PM, Juraj Kubelka wrote:
> 
> Please, can you send me a screenshot? Or submit the screenshot
> here https://github.com/JurajKubelka/PharoSprint/issues/new 
> 
> 
> Done. I think the error appears because when a login fails, the message 
> causes a horiz scroll bar to be added to the panel pushing the fields beyond 
> the top edge. I stumbled on this error because I tried using my fogbugz id 
> whereas the login field needs the registered email id for login.
> 
> Regards .. Subbu
> 
> 

Re: [Pharo-users] MOOC offline download

[Peter Uhnak]

Everything is also on github so you can clone it locally 
https://github.com/SquareBracketAssociates/PharoMooc

On Thu, Apr 27, 2017 at 11:50:22PM +0800, Ben Coman wrote:
> I was just chatting with someone with limited Internet who was looking to
> odownload the mooc files [1] for use offline.  Does such exist?
> 
> [1]  http://files.pharo.org/mooc
> 
> cheers -ben

[Pharo-users] IMPORTANT: iceberg home changed

[Esteban Lorenzano]

As part of our work for release, I changed the home of Iceberg into his own 
place:  https://github.com/pharo-vcs/iceberg

So, now to install you will need: 

Metacello new
  baseline: 'Iceberg';
  repository: 'github://pharo-vcs/iceberg:dev-0.4';
  load.

I also uploaded a Configuration to the *catalog>http://catalog.pharo.org*, so 
you can load while 
doing the transition.

Re: [Pharo-users] Sending byte array in a JSON format

[Sven Van Caekenberghe]

> On 27 Apr 2017, at 14:57, Juraj Kubelka  wrote:
> 
> Hi,
> 
> That’s great! Thank you a lot for the information :-)

Well, it is Peter who came up with the alternative request. All credit to him.

> Juraj
> 
>> On Apr 27, 2017, at 09:52, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 26 Apr 2017, at 17:21, Peter Uhnak  wrote:
>>> 
>>> Maybe the content is not properly stored in the JSON on github' side? But 
>>> you can use base64 in `accept:` to make it work.
>>> 
>>> json := STONJSON fromString: (ZnClient new
>>>url: 'https://api.github.com/gists/5503544';
>>>accept: 'application/vnd.github.v3.base64+json';
>>>get).
>>> b64 := ((json at: 'files') at: 'thumbnail.png') at: 'content'.
>>> PNGReadWriter formFromStream: (Base64MimeConverter mimeDecodeToBytes: 
>>> content readStream).
>> 
>> Ah, great that you found a way to force the server to send the data in a 
>> more sensible way !
>> 
>> Using the latest code from Zn & NeoJSON, combining with another recent 
>> thread (accessing nested dictionaries), this could be written as:
>> 
>> json := NeoJSONObject fromString: (ZnClient new
>>  url: 'https://api.github.com/gists/5503544';
>>  accept: 'application/vnd.github.v3.base64+json';
>>  get).
>> b64 := json atPath: #('files' 'thumbnail.png' 'content').
>> PNGReadWriter formFromStream: (ZnBase64Encoder new decode: b64) readStream.
>> 
>> Sven
>> 
>>> Peter
>>> 
>>> 
>>> On Wed, Apr 26, 2017 at 04:50:04PM +0200, Sven Van Caekenberghe wrote:
 I am puzzled by how they actually encoded the PNG as a String, I tried a 
 couple of alternatives but I could not get binary data out of it so that 
 it parsed successfully as PNG.
 
 If I would have to encode binary data in JSON I would use Base64 encoding 
 (but alternatives exist).
 
> On 24 Apr 2017, at 20:36, Juraj Kubelka  wrote:
> 
> Hi,
> 
> I was playing with GitHub Gist API and I have queried the following Gist: 
> https://gist.github.com/mbostock/5503544
> I was interested how the PNG image is returned: 
> https://gist.github.com/mbostock/5503544#file-thumbnail-png 
> 
> I can obtain the whole Gist executing:
> 
> STONJSON fromString: 
>   (ZnClient new
>   url: 'https://api.github.com/gists/5503544';
>   accept: 'application/vnd.github.v3+json';
>   get).
> 
> I can get PNG contents executing:
> 
> pngData := (ZnEasy get:
>   STONJSON fromString: 
>   (ZnClient new
>   url: 'https://api.github.com/gists/5503544';
>   accept: 'application/vnd.github.v3+json';
>   get)) at: 'files') at: 'thumbnail.png') at: 'raw_url')) 
> contents.
> PNGReadWriter formFromStream: rawPng readStream.
> 
> But the PNG image is part of the Gist query and can be retrieved by:
> 
> pngContent := STONJSON fromString: 
>   (ZnClient new
>   url: 'https://api.github.com/gists/5503544';
>   accept: 'application/vnd.github.v3+json';
>   get)) at: 'files') at: 'thumbnail.png') at: 'content').
> 
> "As pngContent is a WideString, I cannot use:"
> PNGReadWriter formFromStream: pngContent readStream.
> 
> How can I read the PNG image from the pngContent? Any idea? 
> And the reverse question: How can I send the PNG bytes using JSON format? 
> 
> Thanks!
> Juraj
> 
 
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Sending byte array in a JSON format

[Sven Van Caekenberghe]

> On 26 Apr 2017, at 17:25, Peter Uhnak  wrote:
> 
> It is also possible that ZnEasy is doing some encoding transformations that 
> breaks it; after all, you are retrieving binary data as text data, so 
> encoding should be applied on it.

JSON is text, using a specific encoding indeed. Since the JSON comes in and is 
parsed OK, it is safe to assume the textual decoding went fine.

The problem is that the server sends binary data in a string without us knowing 
how it encoded them. That is why the base64 approach is better. 

> Peter
> 
> On Wed, Apr 26, 2017 at 04:50:04PM +0200, Sven Van Caekenberghe wrote:
>> I am puzzled by how they actually encoded the PNG as a String, I tried a 
>> couple of alternatives but I could not get binary data out of it so that it 
>> parsed successfully as PNG.
>> 
>> If I would have to encode binary data in JSON I would use Base64 encoding 
>> (but alternatives exist).
>> 
>>> On 24 Apr 2017, at 20:36, Juraj Kubelka  wrote:
>>> 
>>> Hi,
>>> 
>>> I was playing with GitHub Gist API and I have queried the following Gist: 
>>> https://gist.github.com/mbostock/5503544
>>> I was interested how the PNG image is returned: 
>>> https://gist.github.com/mbostock/5503544#file-thumbnail-png 
>>> 
>>> I can obtain the whole Gist executing:
>>> 
>>> STONJSON fromString: 
>>> (ZnClient new
>>> url: 'https://api.github.com/gists/5503544';
>>> accept: 'application/vnd.github.v3+json';
>>> get).
>>> 
>>> I can get PNG contents executing:
>>> 
>>> pngData := (ZnEasy get:
>>> STONJSON fromString: 
>>> (ZnClient new
>>> url: 'https://api.github.com/gists/5503544';
>>> accept: 'application/vnd.github.v3+json';
>>> get)) at: 'files') at: 'thumbnail.png') at: 'raw_url')) 
>>> contents.
>>> PNGReadWriter formFromStream: rawPng readStream.
>>> 
>>> But the PNG image is part of the Gist query and can be retrieved by:
>>> 
>>> pngContent := STONJSON fromString: 
>>> (ZnClient new
>>> url: 'https://api.github.com/gists/5503544';
>>> accept: 'application/vnd.github.v3+json';
>>> get)) at: 'files') at: 'thumbnail.png') at: 'content').
>>> 
>>> "As pngContent is a WideString, I cannot use:"
>>> PNGReadWriter formFromStream: pngContent readStream.
>>> 
>>> How can I read the PNG image from the pngContent? Any idea? 
>>> And the reverse question: How can I send the PNG bytes using JSON format? 
>>> 
>>> Thanks!
>>> Juraj
>>> 
>> 
>> 
> 

Re: [Pharo-users] Sending byte array in a JSON format

[Juraj Kubelka]

Hi,

That’s great! Thank you a lot for the information :-)

Juraj

> On Apr 27, 2017, at 09:52, Sven Van Caekenberghe  wrote:
> 
> 
>> On 26 Apr 2017, at 17:21, Peter Uhnak  wrote:
>> 
>> Maybe the content is not properly stored in the JSON on github' side? But 
>> you can use base64 in `accept:` to make it work.
>> 
>> json := STONJSON fromString: (ZnClient new
>> url: 'https://api.github.com/gists/5503544';
>> accept: 'application/vnd.github.v3.base64+json';
>> get).
>> b64 := ((json at: 'files') at: 'thumbnail.png') at: 'content'.
>> PNGReadWriter formFromStream: (Base64MimeConverter mimeDecodeToBytes: 
>> content readStream).
> 
> Ah, great that you found a way to force the server to send the data in a more 
> sensible way !
> 
> Using the latest code from Zn & NeoJSON, combining with another recent thread 
> (accessing nested dictionaries), this could be written as:
> 
> json := NeoJSONObject fromString: (ZnClient new
>   url: 'https://api.github.com/gists/5503544';
>   accept: 'application/vnd.github.v3.base64+json';
>   get).
> b64 := json atPath: #('files' 'thumbnail.png' 'content').
> PNGReadWriter formFromStream: (ZnBase64Encoder new decode: b64) readStream.
> 
> Sven
> 
>> Peter
>> 
>> 
>> On Wed, Apr 26, 2017 at 04:50:04PM +0200, Sven Van Caekenberghe wrote:
>>> I am puzzled by how they actually encoded the PNG as a String, I tried a 
>>> couple of alternatives but I could not get binary data out of it so that it 
>>> parsed successfully as PNG.
>>> 
>>> If I would have to encode binary data in JSON I would use Base64 encoding 
>>> (but alternatives exist).
>>> 
 On 24 Apr 2017, at 20:36, Juraj Kubelka  wrote:
 
 Hi,
 
 I was playing with GitHub Gist API and I have queried the following Gist: 
 https://gist.github.com/mbostock/5503544
 I was interested how the PNG image is returned: 
 https://gist.github.com/mbostock/5503544#file-thumbnail-png 
 
 I can obtain the whole Gist executing:
 
 STONJSON fromString: 
(ZnClient new
url: 'https://api.github.com/gists/5503544';
accept: 'application/vnd.github.v3+json';
get).
 
 I can get PNG contents executing:
 
 pngData := (ZnEasy get:
STONJSON fromString: 
(ZnClient new
url: 'https://api.github.com/gists/5503544';
accept: 'application/vnd.github.v3+json';
get)) at: 'files') at: 'thumbnail.png') at: 'raw_url')) 
 contents.
 PNGReadWriter formFromStream: rawPng readStream.
 
 But the PNG image is part of the Gist query and can be retrieved by:
 
 pngContent := STONJSON fromString: 
(ZnClient new
url: 'https://api.github.com/gists/5503544';
accept: 'application/vnd.github.v3+json';
get)) at: 'files') at: 'thumbnail.png') at: 'content').
 
 "As pngContent is a WideString, I cannot use:"
 PNGReadWriter formFromStream: pngContent readStream.
 
 How can I read the PNG image from the pngContent? Any idea? 
 And the reverse question: How can I send the PNG bytes using JSON format? 
 
 Thanks!
 Juraj
 
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-users] Sending byte array in a JSON format

[Sven Van Caekenberghe]

> On 26 Apr 2017, at 17:21, Peter Uhnak  wrote:
> 
> Maybe the content is not properly stored in the JSON on github' side? But you 
> can use base64 in `accept:` to make it work.
> 
> json := STONJSON fromString: (ZnClient new
>  url: 'https://api.github.com/gists/5503544';
>  accept: 'application/vnd.github.v3.base64+json';
>  get).
> b64 := ((json at: 'files') at: 'thumbnail.png') at: 'content'.
> PNGReadWriter formFromStream: (Base64MimeConverter mimeDecodeToBytes: content 
> readStream).

Ah, great that you found a way to force the server to send the data in a more 
sensible way !

Using the latest code from Zn & NeoJSON, combining with another recent thread 
(accessing nested dictionaries), this could be written as:

json := NeoJSONObject fromString: (ZnClient new
url: 'https://api.github.com/gists/5503544';
accept: 'application/vnd.github.v3.base64+json';
get).
b64 := json atPath: #('files' 'thumbnail.png' 'content').
PNGReadWriter formFromStream: (ZnBase64Encoder new decode: b64) readStream.

Sven

> Peter
> 
> 
> On Wed, Apr 26, 2017 at 04:50:04PM +0200, Sven Van Caekenberghe wrote:
>> I am puzzled by how they actually encoded the PNG as a String, I tried a 
>> couple of alternatives but I could not get binary data out of it so that it 
>> parsed successfully as PNG.
>> 
>> If I would have to encode binary data in JSON I would use Base64 encoding 
>> (but alternatives exist).
>> 
>>> On 24 Apr 2017, at 20:36, Juraj Kubelka  wrote:
>>> 
>>> Hi,
>>> 
>>> I was playing with GitHub Gist API and I have queried the following Gist: 
>>> https://gist.github.com/mbostock/5503544
>>> I was interested how the PNG image is returned: 
>>> https://gist.github.com/mbostock/5503544#file-thumbnail-png 
>>> 
>>> I can obtain the whole Gist executing:
>>> 
>>> STONJSON fromString: 
>>> (ZnClient new
>>> url: 'https://api.github.com/gists/5503544';
>>> accept: 'application/vnd.github.v3+json';
>>> get).
>>> 
>>> I can get PNG contents executing:
>>> 
>>> pngData := (ZnEasy get:
>>> STONJSON fromString: 
>>> (ZnClient new
>>> url: 'https://api.github.com/gists/5503544';
>>> accept: 'application/vnd.github.v3+json';
>>> get)) at: 'files') at: 'thumbnail.png') at: 'raw_url')) 
>>> contents.
>>> PNGReadWriter formFromStream: rawPng readStream.
>>> 
>>> But the PNG image is part of the Gist query and can be retrieved by:
>>> 
>>> pngContent := STONJSON fromString: 
>>> (ZnClient new
>>> url: 'https://api.github.com/gists/5503544';
>>> accept: 'application/vnd.github.v3+json';
>>> get)) at: 'files') at: 'thumbnail.png') at: 'content').
>>> 
>>> "As pngContent is a WideString, I cannot use:"
>>> PNGReadWriter formFromStream: pngContent readStream.
>>> 
>>> How can I read the PNG image from the pngContent? Any idea? 
>>> And the reverse question: How can I send the PNG bytes using JSON format? 
>>> 
>>> Thanks!
>>> Juraj
>>> 
>> 
>> 
>