Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2015-05

Google APIs

8 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Van Canneyt

Hello,

Some of you may have noticed that a package 'Google APis' has been added to FPC in subversion. These contain the Google APIs as generated from the Google Discovery Service (~70 APIS).

I am of the opinion that such Web APIs have meanwhile the same importance as the native APIS that make up the desktop; the world is increasingly connected to Internet, and Google, MS Office365 apis (and many others) will become more and more part of the toolset of a programmer.

Object Pascal Programmers should not be left behind.

Mattias Gaertner kindly gave permission to add a package to the 'components' directory of Lazarus. It will register the Google API components on the component palette (it uses the images provided by Google itself)

Many of the APIS will probably not be used by most programmers, but some of the core APIs will be useful for a lot of people:

Google Calendar, Google Drive, Google Tasks, Google Mail, Blogger, Youtube etc.

There are already 4 example programs in the package directory, I will add more as time permits (Google Mail and Translate are definitely on my list).

Note: you will need to create OAuth client ID and secret keys to make them work.

The components as committed to Lazarus SVN will compile out of the box with FPC 3.1.

The components can also be compiled with FPC 2.6.4 (in fact they were developed with FPC 2.6.4) but then some extra files must be copied from the FPC 3.1 repository to the components dir in lazarus. (I will commit instructions for this later on)

One of the design goals was to be able to use the various TCP/IP implementations for FPC; FPC 2.6.4 will only work with Synapse, but since 3.1 contains support for the HTTPS protocol, TFPHTTPClient can be used in 3.1.

Some of the components have been used in some private projects, so they work, but I would welcome experiences, suggestions for improvement, comments.

One thing which I still plan to do is to adapt the code generator so it also creates fpdoc documentation. (the code generator is committed to SVN)

If I broke something in the lazarus SVN or forgot a file (always an option ;) ) please let me know and I will fix it ASAP. But if you don't install the package, there should be no side effects to the commit.

For those of you that read Blaise Pascal magazine: the Google APIs will be featured in the next issue (issue 41 for the English version).

As usual, comments, suggestions and contributions welcome.

Michael.

PS. The REST API for MS Office365 is next.

Reply by email

Martin Frb

Are there any known conditions, in which inlining is applied, despite a {$INLINE off}
on top of the unit?
(fpc trunk and 2.6.4)

Reply by email

Sven Barth
to Martin Frb
Martin Frb wrote
Are there any known conditions, in which inlining is applied, despite a {$INLINE off} on top of the unit? (fpc trunk and 2.6.4)

$INLINE OFF only tells the compiler not to generate inlining information for functions (either explicitely using "inline" or automatically because the autoinline optimization is enabled). It does however not stop the compiler from inlining methods that /do/ have inline information (because they are from a different unit for example).

Regards,
Sven

Reply by email

Martin Frb
to Sven Barth
Sven Barth wrote 11 lines
On 09.05.2015 18:12, Martin Frb wrote: > Are there any known conditions, in which inlining is applied, despite a > {$INLINE off} > on top of the unit? > (fpc trunk and 2.6.4) $INLINE OFF only tells the compiler not to generate inlining information for functions (either explicitely using "inline" or automatically because the autoinline optimization is enabled). It does however not stop the compiler from inlining methods that /do/ have inline information (because they are from a different unit for example).

It does not work for me in units. fpc trunk r30815.

If I copy all the code into the main project, then it works (and I get all the hints, about inlining disabled.).

But the above, stopping with the debugger, and stepping in:
- there is on "call" instruction from "main" to "x1"
- and then there is no further call, the body of this function already has the writeln
yet it should have calls to the other methods.

Reply by email

Martin Frb
to Martin Frb
Martin Frb wrote 12 lines
It does not work for me in units. fpc trunk r30815. If I copy all the code into the main project, then it works (and I get all the hints, about inlining disabled.). But the above, stopping with the debugger, and stepping in: - there is on "call" instruction from "main" to "x1" - and then there is no further call, the body of this function already has the writeln yet it should have calls to the other methods.

Ah, it seems to work, if I put the directive after the "interface" line.

Is that documented? Or is that unexpected?

Reply by email

Sven Barth
to Martin Frb
"Martin Frb" wrote 7 lines
On 09/05/2015 19:54, Martin Frb wrote: > > > It does not work for me in units. fpc trunk r30815. > > If I copy all the code into the main project, then it works (and I get

all the hints, about inlining disabled.).

> > But the above, stopping with the debugger, and stepping in: > - there is on "call" instruction from "main" to "x1" > - and then there is no further call, the body of this function already

has the writeln

Show quoted text 5 lines
> yet it should have calls to the other methods. > Ah, it seems to work, if I put the directive after the "interface" line. Is that documented? Or is that unexpected?

I'd say that's unexpected.

Regards,
Sven

Reply by email

Alfred
to Martin Frb: Ah, it seems to work, if I put the directive after the "interface" line. Is that…

Thanks very much for a very nice feature !!
I am testing (with the supplied demo) the Calendar APIs. And run into error 204.

This (inside googleservice):
S:=TJSONObject(D).Get('kind','');
returns "calendar#calendarList"

This seems to result into a failure to get an objectclass at:
BC:=GoogleFactory.GetObjectClass(s);

But I am not sure ... debugging not optimal on Windows.

Part of the request body as found in request.log:

Body:
{
"kind": "calendar#calendarList",
"etag": "\"1431343270180000\"",
"nextSyncToken": "00001431343270180000",
"items": [
{
"kind": "calendar#calendarListEntry",
"etag": "\"0\"",
"id": "",

Reply by email

Michael Van Canneyt
to Alfred
Alfred wrote 12 lines
Thanks very much for a very nice feature !! I am testing (with the supplied demo) the Calendar APIs. And run into error 204. This (inside googleservice): S:=TJSONObject(D).Get('kind',''); returns "calendar#calendarList" This seems to result into a failure to get an objectclass at: BC:=GoogleFactory.GetObjectClass(s); But I am not sure ... debugging not optimal on Windows.

Strange, I didn't bump into this error ?

I will have a look tonight.
There is some 2.6.4/i386 specific error I must look into as well :(

Michael.

Reply by email