GTUG Talks

[Rob 'Commander' Pike]

The GTUG talks from last night are on youtube.com:

Rob Pike: Lexical Scanning in Go: http://www.youtube.com/watch?v=HxaD_trXwRE

Andrew Gerrand: Cuddle: A Go App Engine Demo: http://www.youtube.com/watch?v=HQtLRqqB-Kk

Fun and frolic.

-rob

[Bjorn Tipling]

These are great. Thank you for doing this and making it public.

[macbirdie]

Great timing with the lexer talk actually, as I was starting to make
one for a different type of templates in my code. Thanks for sharing,
Rob!

Given the new templates will appear in the next release, I've been
wanting to ask if there is any chance that App Engine Go SDK will be a
bit faster to keep up with the releases? Especially that it's in
experimental stage anyway and API versioning is in place.

Say I want to use the new templates. I'd have to probably backport the
package and put it in my code and then clean up, after the new GAE
version comes out. Having that and the fact that I'm trying to write a
Go webapp that will be able to run both on App Engine and as a
standalone server (which gives me possibility to use the latest
release or even a weekly Go revision), that can be a bit frustrating.

[David Symonds]

On Wed, Aug 31, 2011 at 7:39 PM, macbirdie <maciej.r...@gmail.com> wrote:

> Given the new templates will appear in the next release, I've been
> wanting to ask if there is any chance that App Engine Go SDK will be a
> bit faster to keep up with the releases? Especially that it's in
> experimental stage anyway and API versioning is in place.

Go on App Engine will always lag by at least a little, and will, over
time, support releases for longer.

> Say I want to use the new templates. I'd have to probably backport the
> package and put it in my code and then clean up, after the new GAE
> version comes out. Having that and the fact that I'm trying to write a
> Go webapp that will be able to run both on App Engine and as a
> standalone server (which gives me possibility to use the latest
> release or even a weekly Go revision), that can be a bit frustrating.

http://code.google.com/p/appengine-go-backports/ may be of interest to
you. Let us know if there's any other packages you'd be interested in
having maintained as a backport.

Dave.

[John Asmuth]

You can always copy the new template package in by hand. There is no fundamental language change that it requires; it's just a new package.

[Paul Borman]

There is a call to a new reflect.Value method, NumMethods.  Fortunately it is only used to see if there are any methods so you can just use v.Method(0) and recover the panic when there are not any.

[Russ Cox]

On Wed, Aug 31, 2011 at 10:57, Paul Borman <bor...@google.com> wrote:
> There is a call to a new reflect.Value method, NumMethods.  Fortunately it
> is only used to see if there are any methods so you can just use v.Method(0)
> and recover the panic when there are not any.

Or use v.Type().NumMethod().

[macbirdie]

Thanks for the replies, guys.

I'm aware of the backports project and that I could put the code in my
project without any major changes (if I'm lucky) myself, but it's
still fiddly, especially that, as I said, my app by design will be
able to run on the latest release of Go as a standalone server,
without the App Engine. In that case there will be some duplication of
code used (both included and provided by Go library) and that may feel
somehow dirty. ;) Thankfully new template is an easy case, but what if
the newer code relies on some updated core language features or other
updated packages' functionality? Reminds me of the many cases when
writing PHP code I had to either backport some features or simply not
use a new language feature that made it suck a bit less, just because
the provider lagged far behind the releases, only then to update the
code when they did finally upgrade the servers.

Seems like I'll have to bite the bullet and just use the backported
minty-fresh code and be done with it.

url package would be also nice to have in the backports, Dave.


Love the community support!

[André Moraes]

You could make some really crazy stuff in the Makefile, so you could
select what files will be compiled when running stand-alone and what
files will be copied to Google App Engine.

This will need some work but can be done.

Probably you are already making something like that to handle the datastore api.

--
André Moraes
http://andredevchannel.blogspot.com/

[Maciej Rutkowski]

Yeah, I'm thinking of creating kind of a deploy script that separates
the code for standalone and App Engine app, since for example App
Engine dev server doesn't like it if there are any *.go files in the
root app folder (along with app.yaml). Surely I have some work to do
to make the project structure right, since it would be nice to still
be able to take advantage of dev_appserver's quick edit-run cycles of
Go code.

I haven't decided on how to handle datastore/blobstore yet, but yeah,
some file mangling will definitely be in order.