https://github.com/RMODINRIA-Blockchain
Inria = 200 teams 4000 researchers :)
On Sun, Dec 10, 2017 at 9:12 AM, Ben Coman wrote:
>
>
> On 10 December 2017 at 15:27, Stephane Ducasse
> wrote:
>>
>> Tx for your report :)
>>
>> https://wordpress.com/post/pharoweekly.wordpress.com/2347
>>
>> Did you
>
>
> > > On 13 Dec 2017, at 05:37, Ben Coman wrote:
> > >
> > > Hi Sven (et al),
> > >
> > > On 10 December 2017 at 11:45, Ben Coman wrote:
> > >
> > > 3. Finally parse into real objects the nested level holding the data
> you really want...
> > >
> > > Object subclass: #Market
> > > insta
> On 13 Dec 2017, at 07:49, Ben Coman wrote:
>
>
>
> On 13 December 2017 at 14:40, Sven Van Caekenberghe wrote:
> Yeah, that is the main problem with JSON. It cannot capture that variability
> in its own spec. Sure, there are tons of extensions on top of JSON to address
> these aspects, bu
On 13 December 2017 at 14:40, Sven Van Caekenberghe wrote:
> Yeah, that is the main problem with JSON. It cannot capture that
> variability in its own spec. Sure, there are tons of extensions on top of
> JSON to address these aspects, but NeoJSON only deals with the raw spec.
> And any server can
Yeah, that is the main problem with JSON. It cannot capture that variability in
its own spec. Sure, there are tons of extensions on top of JSON to address
these aspects, but NeoJSON only deals with the raw spec. And any server can use
its own version.
Simple answer is indeed: getmarkets and get
Hi Sven (et al),
On 10 December 2017 at 11:45, Ben Coman wrote:
>
> 3. Finally parse into real objects the nested level holding the data you
> really want...
>
> Object subclass: #Market
> instanceVariableNames: 'MarketCurrency BaseCurrency MarketCurrencyLong
> BaseCurrencyLong MinTradeSize Mark
> On 10 Dec 2017, at 04:45, Ben Coman wrote:
>
>
> On 5 December 2017 at 20:44, Sven Van Caekenberghe wrote:
>
> > On 5 Dec 2017, at 13:33, Ben Coman wrote:
>
> > @sven, I started reading Enterprise Pharo a couple of hours ago.
> > I don't quite get your section references. I presume you
>
On 10 December 2017 at 15:27, Stephane Ducasse
wrote:
> Tx for your report :)
>
> https://wordpress.com/post/pharoweekly.wordpress.com/2347
>
> Did you look at SmartShackles? on our inria github repo. Because
> Santiago is extracting information from blockchains.
>
>
I would hesitate to call wher
Tx for your report :)
https://wordpress.com/post/pharoweekly.wordpress.com/2347
Did you look at SmartShackles? on our inria github repo. Because
Santiago is extracting information from blockchains.
On Sun, Dec 10, 2017 at 4:45 AM, Ben Coman wrote:
>
> On 5 December 2017 at 20:44, Sven Van Caeke
On 5 December 2017 at 20:44, Sven Van Caekenberghe wrote:
>
>
> > On 5 Dec 2017, at 13:33, Ben Coman wrote:
>
> > @sven, I started reading Enterprise Pharo a couple of hours ago.
> > I don't quite get your section references. I presume you
> > don't mean "chapter 11 Persisting Objects with Voyage
Thanks Paul. It'll be good to review some concrete implementations,
and nice to see what services other other people find useful.
I got a momentary urge the create a Pharo Distribution or catalog entry
called
something like "SamplRest" with a GUI to explore available REST data
sources.
Marketing an
Hi Ben,
I've made a few REST Clients
http://smalltalkhub.com/#!/~pdebruic/Stripe
http://smalltalkhub.com/#!/~pdebruic/Tropo
http://smalltalkhub.com/#!/~pdebruic/SegmentIO
And the elasticsearch one but its been advanced mostly lately by Sho Yoshida
(https://github.com/newapplesho) here
https://g
On 5 December 2017 at 20:44, Sven Van Caekenberghe wrote:
>
>
>> On 5 Dec 2017, at 13:33, Ben Coman wrote:
>>
>> @esteban, thx, I'll take a look at mastodon.
>>
>> @peter, I remember playing with the Google API when Richard published
>> that. thx for the reminder.
>>
>> @sven, I started reading
> On 5 Dec 2017, at 13:33, Ben Coman wrote:
>
> @esteban, thx, I'll take a look at mastodon.
>
> @peter, I remember playing with the Google API when Richard published
> that. thx for the reminder.
>
> @sven, I started reading Enterprise Pharo a couple of hours ago.
> I don't quite get your s
There is also the OpenAPI
specification dedicated to define a REST API and from which
a skeleton of an implementation can be generated. It should be
then also possible to generate the skeleton of a client for such
an API.
Swagger
provides tooling to th
@esteban, thx, I'll take a look at mastodon.
@peter, I remember playing with the Google API when Richard published
that. thx for the reminder.
@sven, I started reading Enterprise Pharo a couple of hours ago.
I don't quite get your section references. I presume you
don't mean "chapter 11 Persisti
With ZnClient you can also dynamically extend paths (#addPath:), specify
parameters (#formAt:put:, #queryAt:put:), provide raw #contents:, etc.
But what would be nice is to convert the responses to some domain objects.
So e.g. when I query trello for all lists, I would like to get as a result
not
Ben,
> On 5 Dec 2017, at 12:15, Ben Coman wrote:
>
> I'm just about to write my first client interface to a REST service.
> In some respects I understand this is as simple as doing GET responses
> using Zinc,
> but I'm inquiring about tutorials or libraries that might help. Most
> of the stuff
Hi,
> On 5 Dec 2017, at 12:15, Ben Coman wrote:
>
> I'm just about to write my first client interface to a REST service.
> In some respects I understand this is as simple as doing GET responses
> using Zinc,
yes, is about that.
GET/POST/PUT/DELETE
all have sense.
> but I'm inquiring about t
I'm just about to write my first client interface to a REST service.
In some respects I understand this is as simple as doing GET responses
using Zinc,
but I'm inquiring about tutorials or libraries that might help. Most
of the stuff turned up by searches is about server-side of REST.
cheers -ben
20 matches
Mail list logo
