Starfish | 15 Feb 01:46 2012
Picon

Reading cookies

Hello! 

I'm trying to read a cookie without success. 

To set a cookie, I write:

expiration := *time.LocalTime()
expiration.Year += 1
cookie := http.Cookie{Name: "browserID", Value: "my value", Expires: expiration}
http.SetCookie(w, &cookie)       

To read, I write (without success):

cookie, _ := r.Co okie("browserID")
fmt.Fprint(*w, cookie) 

I'm very grateful for any help!
Kyle Lemons | 15 Feb 01:53 2012
Picon

Re: type-safe net/rpc?

For an example of a type-safe wrapper, see the code generated by github.com/kylelemons/go-rpcgen (the EchoService example, for instance).  The EchoService instance returned by NewEchoServiceClient has explicit parameters, and farms out to the usual rpc.Call underneath.

On Tue, Feb 14, 2012 at 3:40 PM, Jeremy Thorpe <jeremyt <at> google.com> wrote:
Hi golang,

I am using the net/rpc package, and am so far very happy with it.
However, one slight frustration is that it is generally not type safe.
 I can get runtime errors like:

2012/02/14 13:25:32 rpc: client protocol error: gob: attempt to decode
into a non-pointer
2012/02/14 13:25:32 rpc: client protocol error: gob: decoding into
local type *uint64, received remote type

One tantalizing sentence on http://weekly.golang.org/pkg/net/rpc/ says:

"A server implementation will often provide a simple, type-safe
wrapper for the client."

What exactly does this mean?  Is there a way to refer in the client
code to the remote function, so that the argument types are known, and
I can have my errors at compile time?  Does this just mean that I
ought to write my own wrapper around rpc.Call?

Thanks!
-Jeremy

David Leimbach | 15 Feb 01:57 2012
Picon

Re: Something from Alef - the become statement


On Feb 14, 3:18 pm, "Thomas Bushnell, BSG" <tbushn...@...>
wrote:
> I think this is very interesting.
>
> It is called "tail call optimization", and is hardly an Alef invention. You
> can just spell it "return", and get the same effect; the compiler can
> simply detect the fact of the tail call and do the optimization.

No it's not an Alef invention.  I actually like being explicit, as you
say below :-).

Sometimes you want to be able to get a stack trace, and other times
you want the TCO to happen.  You can let other people argue about
whether it's good to be implicit or explicit about this :-).

>
> The advantage of "become" is that it *requires *the compiler to do the tail
> call optimization, but that can be done as well by making it a requirement
> of the language that "return" do so. Scheme has shown that this can be done
> to great effect, and that when programmers are *guaranteed *that the tail
> call optimization will happen, possibilities of considerable power show up.
>

Actually require is like return in the cases where it could not be
tail call optimized.

> You also give some things up. For example, if you wish to target the JVM,
> it is all but impossible to do it efficiently, because the JVM imposes
> rules about stack frames which make it impossible. (You can do it with
> trampolines, but at a considerable efficiency cost.)

Clojure has a special syntax to recur to the same function as the only
non-stack consuming looping construct, but it can only do looping, not
CPS style computation.

>
> I think it would be interesting to see what happens if something like this
> were done in Go, but experience shows that if you make it an optional thing
> the compiler *might *do (which is what GCC does, for example), then you
> don't get much benefit from it as a programmer; and if you make it a rule
> which the compiler *must *do, then programmers depend on it, and you can't
> remove the requirement without turning working code into broken code. So
> it's a Pretty Big Decision.
>

I agree it's a big decision, I'm just interested if anyone sees value
in this, the way it was done in Alef.

> Thomas
>
>
>
>
>
>
>
> On Tue, Feb 14, 2012 at 2:58 PM, David Leimbach <leim...@...> wrote:
> > Was thinking a little about Alef today.  Seemed like a pretty darned
> > nice language really that I hardly knew, and one of the things I
> > thought was rather novel about it was the "become" statement.
>
> > From the Alef User's Guide found here:
> >http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ug
>
> > "The become statement transfers control in one of two ways. If its
> > operand evaluates to anything other than a function, become behaves as
> > a return statement yielding the result of the evaluation. When the
> > operand is a function returning exactly the same type as the current
> > function, the current function is replaced by the operand function and
> > control is transferred to the beginning of that function. There is a
> > crucial difference between a subroutine call and this form of function
> > invocation: the former creates a new subroutine context on the stack
> > before transferring control; the latter replaces the current function
> > context with the new context and transfers control. When a function
> > invokes itself or when several functions invoke each other via mutual
> > recursion using become, the computation runs in constant space. When
> > used in this form, the become statement is useful for implementing
> > functional style programs.
> > "
>
> > I think this could be an interesting addition to Go, especially around
> > interface types.  It could enable some kinds of CPS style programming
> > that isn't really easily achieved in C or C++ without setjmp/longjmp
> > or ucontext stuff.
>
> > Anyone else think this is interesting?

Thomas Bushnell, BSG | 15 Feb 01:59 2012
Picon

Re: Re: Something from Alef - the become statement

On Tue, Feb 14, 2012 at 4:57 PM, David Leimbach <leimy2k-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:


Sometimes you want to be able to get a stack trace, and other times
you want the TCO to happen.  You can let other people argue about
whether it's good to be implicit or explicit about this :-).

Most Scheme systems deal with this by tracing function invocations, which (it turns out) is usually even more valuable than a stack trace. They maintain a (variably sized) buffer which you can use to hold as many as you want.

Thomas

Jessta | 15 Feb 02:32 2012
Picon

Re: Re: Go I/O not failsafe?

On Wed, Feb 15, 2012 at 1:54 AM, Mike Coleman <tutufan@...> wrote:
> Just to clarify, by "novice" programmers, I don't really mean CS101
> students.  I'm talking about scientists/accountants/many sysadmins/
> etc--people who don't care about programming per se, but who are just
> trying to solve a problem.

Go is not the language for people that can't handle doing error checking.
If you can't handle checking for an error then it's unlikely you'll
take in to account integer overflows, avoid race conditions, safely
concurrently access memory and resources , deal with mutable state,
deadlocks, livelocks and all the other things that come with using a
systems language.
Non-programmer scientists/accountants/sysadmins will likely have more
luck with python, their code will be small, slow, single threaded and
unreliable anyway.

> Here is my definition of "failsafe".  If I run the standard "hello
> world" program in a language like so
>
>    $ ./helloworld > /dev/full
>
> it should bomb, with both an error message complaining about a failed
> write, and an error status.

This seems like a fairly leak definition of "failsafe", there are
plenty of other ways for code to fail badly that doesn't involve any
I/O or any errors. These are generally called "bugs" and occur when a
program acts in a way the programmer didn't expect. They often lead to
silent data corruption and are often quite hard to find.

Missing error checks are easy to find in comparison, they are so easy
that a program can be written to find them. So it seems silly to spend
any time worrying about them.

--

-- 
=====================
http://jessta.id.au

David Leimbach | 15 Feb 02:37 2012
Picon

Re: Something from Alef - the become statement


On Feb 14, 3:47 pm, Evan Shaw <eds...@...> wrote:
> It's an interesting idea, but I think I would rarely use this feature
> in practice. I'll default to being opposed to adding it.

On deeper reflection I'm beginning to agree with you.

In trying to explore this further a bit I'm having some trouble coming
up with a good way for this to work out with respect to panic/recover.

func OpenCPS(name string, onError func(Error), next func(*File))  {
    file, err := os.Open(string)
    if file != nil {
        become next(file)
    }
    else if err != nil {
        become onError(err)
    }
}

A couple things look a bit weird here.

1. Become doesn't feel like it would work very well the way Go
currently works with return statements. With the version of Go I have
installed, Go would complain if I used "return" where "become" is
here.  Become would have to be the last statement of the function to
avoid that and that seems to mean that I'd need to capture both the
function in some external var as well as the arguments to it that are
appropriate.  It would be a function of interface{} with an
interface{} var.  Messy.

2. What happens with Panic/Recover when one becomes another function?

This could get really hairy really fast I reckon.

Go really doesn't need to be a functional language anyway :-).

Dave

David Leimbach | 15 Feb 02:38 2012
Picon

Re: Something from Alef - the become statement


On Feb 14, 4:59 pm, "Thomas Bushnell, BSG" <tbushn...@...>
wrote:
> On Tue, Feb 14, 2012 at 4:57 PM, David Leimbach <leim...@...> wrote:
>
> > Sometimes you want to be able to get a stack trace, and other times
> > you want the TCO to happen.  You can let other people argue about
> > whether it's good to be implicit or explicit about this :-).
>
> Most Scheme systems deal with this by tracing function invocations, which
> (it turns out) is usually even more valuable than a stack trace. They
> maintain a (variably sized) buffer which you can use to hold as many as you
> want.
>

It's like a built-in Writer Monad!

> Thomas

Krzysztof Kowalik | 15 Feb 03:33 2012
Picon

Blog post about new go tool

Hello!


I just published my new blog post about the go command. I think even people who are very familiar with it will find some useful thoughts there. Here's the link: http://areyoufuckingcoding.me/2012/02/14/the-go-tool/

Cheers, nu7
Kyle Lemons | 15 Feb 03:44 2012
Picon

Re: Reading cookies

On Tue, Feb 14, 2012 at 4:46 PM, Starfish <ahnold-ur4TIblo6goN+BqQ9rBEUg@public.gmane.org> wrote:

Hello! 

I'm trying to read a cookie without success. 

To set a cookie, I write:

expiration := *time.LocalTime()
expiration.Year += 1
cookie := http.Cookie{Name: "browserID", Value: "my value", Expires: expiration}
http.SetCookie(w, &cookie)       

Are you sure the cookie is being set? (do you see it in your browser's cookie list)  Something in the back of my mind says you're missing something important (domain, maybe?)
 
To read, I write (without success):

cookie, _ := r.Cookie("browserID")
fmt.Fprint(*w, cookie)

Well, first off, don't ignore errors...  However, it's probably the failure of the cookie to get set. 
Kyle Lemons | 15 Feb 03:54 2012
Picon

Re: Blog post about new go tool

Hello!

I just published my new blog post about the go command. I think even people who are very familiar with it will find some useful thoughts there. Here's the link: http://areyoufuckingcoding.me/2012/02/14/the-go-tool/

Cheers, nu7

"Go tool resolves dependencies by checking out HEAD version of the repository."

Not strictly true.  The go tool doesn't say much (anything?) about it yet, but it will look for tags based on the version of Go you have installed.  See the source/tests for examples. (basically, go.weekly.yyyy-mm-dd or go.release.r## ... not sure about go1)

Gmane