Re: [ANN] Blog post about gospecify

On Feb 1, 1:38 am, Tom Lieber <all...@...> wrote:
> "expected X == Y" and "expected X > Y"

Thanks for the inspiration! I think I just figured out a new syntax,
which would be more terse and even more expressive:

c.Expect(answer, Equals, 42)
c.Expect(answer, Not(Equals), 666)

The definitions of those methods are in pseudo-Go:

func (c *Context) Expect(actual interface{}, m Matcher, expected
interface{}) {...}
type Matcher func(actual interface{}, expected interface{}) bool
func Equals(actual interface{}, expected interface{}) bool {...}
func Not(m Matcher) Matcher {...}

This will require one to import the Equals etc. functions to the
current namespace (prefixing them with the package name would be
verbose), but I suppose it is acceptable in test code.

Re: fatal error: can't find import: reflect

On Jan 31, 4:43 pm, Russ Cox <r...@...> wrote:
> On Sun, Jan 31, 2010 at 01:17, Joe Poirier <jdpoir...@...> wrote:
>
> > On Jan 31, 1:29 am, Ian Lance Taylor <i...@...> wrote:
> > > Joe Poirier <jdpoir...@...> writes:
> > > > I was experimenting with adding a wrapper around a syscall, using the
> > > > instructions in syscall/mkall.sh, and ran in to a "can't import"
> > > > error.
>
> > > > Initially I created a wrapper stub in syscall_darwin.go and followed
> > > > the steps outlined in mkall.sh to autogen the required files. After
> > > > recompiling Go I called the wrapper function from a test file and it
> > > > worked as expected. When I tried to use the reflect package (import
> > > > "reflect") to add functionality to the wrapper the build fails due to
> > > > an import error. Also, attempts to import other packages in to
> > > > syscall_darwin.go fail as well.
>
> > > > Did I miss a step and/or is there an import restriction for building
> > > > the syscall package?
>
> > > > I'm using Go version 4711+ (the 1/27/10 release build I believe),and
> > > > darwin amd64.
>
> > > If I understand correctly, you want to add code to the syscalls
> > > package which imports the reflect package.  That won't work because it
> > > is a circular dependency.  The reflect package already depends
> > > (indirectly) on the syscalls package.
>
> > > If that's not what you are doing, can you provide some more details?

Re: proposed changes to http server

> > http.Stop()
> > http.WaitForReady()
> > http.WaitForStop()
>
> These are unnecessary.  Look at the tests in the src/pkg/gob directory
> for an example of how to start an http server.  If you arrange to share
> the net.Listener value, another goroutine can call l.Close() to knock it
> over, and then you'll know that it's done when http.Serve returns.

Great, I think I see how that's intended to work now.

> The second, non-transparent, change (but not impactful of existing
>
> > code).  I'd like to expose http.NewConn().
>
> Is that really all that's necessary?  If so, great, but the last time I
> looked at the spec it seemed like you'd need to do a bit more.

As long as I can build up a ReadWriteCloser of my own to pass in as
the I/O for the http.Conn then I can make it work.  I have a working
fcgi implementation already, and a branch of it mostly ported to this
structure... having some trouble with binary.Read/Write right now, but
I am confident that the basic idea will work once I iron out the
kinks.

There are a few parts of the spec that I think won't be utilized doing
it this way, for example, there is no correspondence between anything
in http.Request and FCGI_DATA, so no FCGI_DATA will be sent to a
responder, and there is no specific way to send error messages back

Re: new and make builtins require symbol table during parsing

Hello,

> > Subject: new and make builtins require symbol table during parsing
>
> The premise isn't true.

I see your point.

> The solution is to allow function call arguments to be either types
> or expressions and then let higher-level analysis decide which each
> is and complain appropriately when a type was expected and an
> expression found or vice versa.

As you might have guessed, I'm writing my own parser (compiler) as a
way to learn the language.  I've already have a parser-private "type
expression" that I'm using for conversions and composite literals.  It
should be easy enough to expose that to the semantic analyzer.  Thanks
for the tip .

-Brett

Is this a bug or am I doing something wrong?

Re: Is this a bug or am I doing something wrong?

You're trying to pass a method, but currently that doesn't work.  See
the section at the end of the Language Spec:

http://golang.org/doc/go_spec.html#Implementation_differences

-Ostsol

On Jan 31, 6:20 pm, Daniel Smith <dan...@...> wrote:
> Hello, quick question. Given:
>
> type Bug struct {}
>
> func (B *Bug) ShowBug(i, j int) (int, int) {
>     return j, i
>
> }
>
> type BugFunc func (B *Bug, i, j int) (int, int)
>
> type BugFuncHolder struct {
>     BF BugFunc
>
> }
>
> var BFH = BugFuncHolder{ShowBug}
>
> The compiler barfs:
>
> bug.go:15: undefined: ShowBug
>
> The problem goes away if I make ShowBug into a function taking a *Bug as its
> first parameter instead of a method. I thought I saw somewhere that you
> could convert between the two, like I attempt above. At minimum the error
> message is not correct or helpful.
>
> Thanks
>
> --
> Daniel Smithhttp://www.schaumburggoclub.org/

Re: Re: Is this a bug or am I doing something wrong?

Re: Re: Is this a bug or am I doing something wrong?

On Feb 1, 2010, at 1:19 PM, Ostsol wrote:

> You're trying to pass a method, but currently that doesn't work.  See
> the section at the end of the Language Spec:
>
> http://golang.org/doc/go_spec.html#Implementation_differences

Yes, but he's not what the compiler is complaining about.  ShowBug is  
a method but the expression
	var BFH = BugFuncHolder{ShowBug}
uses the identifier ShowBug, which is not defined at top scope, hence  
the compiler message.  ShowBug is only defined inside the scope of a  
value of type Bug or *Bug.

-rob

Go at Conferences?

Back in December I did a brief presentation on Go and my RubyGoLightly project here in London at Ruby Manor.
I've yet to put it online as the code was pants and I'm planning to replace it with snippets from my current
projects when they stabilise.

At the time I wasn't sure if Go would be a passing obsession or not (I always try out a few new languages every
year and most of them fall by the wayside) but I've been having so much fun working on GoLightly this year
that I decided to put in an OSCON proposal to come and babble about the project in the US. To be honest I'm not
sure a 40-min mix of virtual machine design and Go will necessarily be their cup of tea, but everyone keeps
saying there aren't enough women speaking at tech conferences so what the heck :)

Anyway, the question is: anyone else here given presentations on Go recently or hoping to do so during the
coming year?

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless  <at> reality.responds_to? :reason

Re: Re: fatal error: can't find import: reflect