<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.go.general">
    <title>gmane.comp.lang.go.general</title>
    <link>http://blog.gmane.org/gmane.comp.lang.go.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97130"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97122"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97091"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97086"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97076"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97059"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97033"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97011"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97008"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/97003"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96994"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96993"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96989"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96987"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96977"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96973"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96963"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96947"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96946"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.go.general/96939"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97130">
    <title>[ANN] represent - Create static HTML presentations and articles</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97130</link>
    <description>&lt;pre&gt;I wrapped the beautifully clean and simple Present tool (from 
http://code.google.com/p/go.talks) to compile .slide and .article files 
into static HTML pages.

Useful for creating slides and articles that can be hosted on Github Pages, 
dirt-cheap web hosting, etc.

Here's a presentation about represent, which I compiled with represent:

http://cmars.github.io/represent/

Cheers!
Casey

&lt;/pre&gt;</description>
    <dc:creator>Casey Marshall</dc:creator>
    <dc:date>2013-05-22T22:40:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97122">
    <title>A more powerful go I18n library</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97122</link>
    <description>&lt;pre&gt;Remember me? ;) I recently asked some basic questions about godoc. At that 
time, I hinted at a project I was working on.

Its now in a state I feel confident showing to you:

code.google.com/p/ginta

* What is it?

It is a library for i18n, that should be easy to use, extend and customize 
to your needs

* Why do I need it?

Because there is no builtin mechanism in the language, and I did not find a 
project with comparable features yet

* What can it do?

While there is still a lot to do (including writing a formal roadmap), 
right now there is a way to load translations, access these resources, and 
format messages with dynamic data. This includes formats for dates and 
pluralization rules.

* How do I get it?

All code is available on google code, so go get should be sufficient. If 
there is a need for it, I might add packaged downloads further down the road

Thanks for your time, and back to your regularly scheduled discussions. ;)

&lt;/pre&gt;</description>
    <dc:creator>Stefan Schulz</dc:creator>
    <dc:date>2013-05-22T21:24:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97091">
    <title>Go 1.1 integration of net package and the scheduler</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97091</link>
    <description>&lt;pre&gt;I was reading in the release notes for Go 1.1 about performance
enhancements through the coupling of the net package and the scheduler and
I'm curious how that works. Could someone please give me a pointer to the
file(s) I should be looking at to better understand that?

&lt;/pre&gt;</description>
    <dc:creator>Bill Neubauer</dc:creator>
    <dc:date>2013-05-22T14:50:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97086">
    <title>[ANN] vgo - verifiable go</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97086</link>
    <description>&lt;pre&gt;Hi Gophers :)

I'd like to announce vgo, a model checker written in go that can
verify programs written in vgo.

tl;dr:

* https://en.wikipedia.org/wiki/Model_checking is some kind of
  universal testing methodology. It's awesome, though somewhat
  explosive...

* http://vgo.readthedocs.org/en/latest/tutorial.html has examples
  (with pictures!).

* the source is here: https://bitbucket.org/teythoon/vgo

* works fine with both go1 and go1.1.

What is vgo? Quoting the readme:

~~~ snip ~~~

vgo - verifiable go
===================

Verifiable go or vgo for short is a subset of the go programming
language introduced by Google that has been extended so that the
programmer can use a temporal logic (CTL) to express assumptions and
guarantees directly within the source code.

The tool is invoked like the go build system itself. It verifies that
the code has the desired properties and produces a compiled library or
aborts with an appropriate error message.

This has a number of advantages:

* The tool fits very well&lt;/pre&gt;</description>
    <dc:creator>justuswinter-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T16:17:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97076">
    <title>duplicate symbol reference __tcf_0 on osx lion</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97076</link>
    <description>&lt;pre&gt;anyone encountered this? this is the last line of compilation of a
little program that links to a statically compiled C library (it all
works fine if I link to the dylib instead). OSX is v10.7.5:

/usr/local/go/pkg/tool/darwin_amd64/6l -o $WORK/ent/_obj/exe/a.out -L
$WORK -L /Users/aam/pkg/darwin_amd64 $WORK/ent.a
/Users/aam/pkg/darwin_amd64/mav.a(_all.o): duplicate symbol reference:
__tcf_0 in both mav(__TEXT

note that the message from the compiler cuts there. the paths are
stripped from their original, longer versions.

this problem does not appear on 10.8 (Mountain Lion)

andrey

&lt;/pre&gt;</description>
    <dc:creator>andrey mirtchovski</dc:creator>
    <dc:date>2013-05-22T16:42:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97059">
    <title>A way to indicate library usage and perhaps ratings on godoc.org?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97059</link>
    <description>&lt;pre&gt;Hey all,

I've been looking for libraries on godoc.org recently and find myself 
wondering how to judge a library for use.  At the moment the only real way 
to do it is to read the source and/or try it out.  This is fine but when 
there are a lot of libraries doing a specific thing and no clear indicator 
of which if any is better than others it can be quite difficult and time 
consuming to decide which one to use.  

I realize lots of folks in the go community prefer to just work against the 
standard library, but clearly there are cases where you don't need or want 
to reinvent the wheel and where a library cna be useful.

I'm wondering if it'd be worthwhile to make an effort to support a 
mechanism to see the number of installs/uses of a library and/or let people 
using the library rate the library if they are finding it good.  I've seen 
this sort of mechanism work fairly well on NPM within the node.js 
community.  Obviously there are some technical difference in terms of 
something like tracking install&lt;/pre&gt;</description>
    <dc:creator>bex</dc:creator>
    <dc:date>2013-05-22T15:57:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97033">
    <title>Could (known) type names be removed from complex struct literals?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97033</link>
    <description>&lt;pre&gt;Hi,

struct literals often seem to be the most practical way to initialize 
objects, but in Go they require type names even in places where the types 
are already known. Could these type names not be omitted? 

package main

Similarly for various other situations:

package main

If this is obvious to everyone else / a FAQ etc. I apologize. ;-)

&lt;/pre&gt;</description>
    <dc:creator>mjy</dc:creator>
    <dc:date>2013-05-22T14:23:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97011">
    <title>Go binary portability to unsupported OS version</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97011</link>
    <description>&lt;pre&gt;Hi All

In R1, it list out OS and its' version requirements to compile Go compiler 
itself. 

As a system admin who need to support all kind of OS with various OS 
versions, 
My question is about the Go binary(generated static executable program by 
Go compiler).

A quick test(See R2) to compile helloword.go into Go binary on CentOS EL6 
64-bit, and move it RedHat EL5 64 bit works fine.
My understanding is that Go binary has a built in runtime that has libc 
from CentOS6/RHEL6  and no worry about libc version mis-match issue.

Can I extend this ok result  to RHEL 3  64-bit OS without testing ?
or Go binary compiled on Windows 7 64 bit and expect it work in Window 2008 
64-bit ?

What would be the  common denominators I need to watch out to ensure Go 
binary works in same OS but across OS version ?
Can Go binary from CentOS 6  work on the other OS(FreeBSD 9) as long as 
 ELF format (R3)and CPU architecture are the same ?

R1: http://golang.org/doc/install#requirements
R2:

[root&amp;lt; at &amp;gt;os104 tmp]# ls -lrt |tail -2
-&lt;/pre&gt;</description>
    <dc:creator>T.J. Yang</dc:creator>
    <dc:date>2013-05-22T12:58:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97008">
    <title>Is this acceptable Interface usage</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97008</link>
    <description>&lt;pre&gt;I'm very new to go. ~ 2 weeks.

I'm learning go by writing a small middleware system.

End points can be consumers or producers

I've just started to model this with interfaces

type Endpter interface {
GetName() string
GetEndPtType() string
}

type Consumer interface {
GetName() string
GetEndPtType() string
IsConsumer() bool
}
type Producer interface {
GetName() string
GetEndPtType() string
IsProducer() bool
}


So what I have is overlaping interfaces that have some methods in common.
 Is there some reason to avoid this or not?

Thanks

Eric

&lt;/pre&gt;</description>
    <dc:creator>Eric Palmer</dc:creator>
    <dc:date>2013-05-22T12:39:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/97003">
    <title>cloud datastore support?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/97003</link>
    <description>&lt;pre&gt;Hi,
I think there are lots of folks including me, like to use newly announced 
cloud datastore outside of appengine. in theory, it's as fast as dynamodb, 
probably cheaper, and easier to use (assume orm layer included). the python 
and java apis are there but not golang. is anyone working on it? if so, 
when will it be available? thanks

&lt;/pre&gt;</description>
    <dc:creator>tali.wang-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T10:54:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96994">
    <title>Scala code is 6000 lines. Go is about 3000.</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96994</link>
    <description>&lt;pre&gt;Hello,

I found this statement in http://go-lang.cat-v.org/quotes:


“*I have reimplemented a networking project from Scala to Go. Scala code is 


This sounds really exciting and puzzles me. I would like to know whether it 
is true and, if so, how it can be explained. At first sight it seems as if 
the advances in programming languages since C were almost of little use as 
what expressiveness is concerned (aka lines of code). Some modernized C 
comes along like Go and beats the heck of all languages that are supposed 
state-of-the-art like f.ex. Scala (you know what I mean, so please no 
discussions whether Scala is state-of-the-art or not ;-)).

How can this be explained? Delegation and implicitly implementing 
interfaces results in such code reduction? I wished I would understand this 
better. Any ideas?

Cheers, Bienlien

&lt;/pre&gt;</description>
    <dc:creator>Bienlein</dc:creator>
    <dc:date>2013-05-22T09:01:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96993">
    <title>http.Request.FormValue for multiple select</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96993</link>
    <description>&lt;pre&gt;Hello

I have this in my webform

&amp;lt;select multiple="multiple" name="appName"&amp;gt;
    &amp;lt;option id="appName1"&amp;gt;appName1&amp;lt;/option&amp;gt;
    &amp;lt;option id="appName2"&amp;gt;appName2&amp;lt;/option&amp;gt;                               
&amp;lt;/select&amp;gt;

When I try to send my form with appName1 and appName2 selected and print 
the value with

appName := r.FormValue("appName")
fmt.Println("Application Name -&amp;gt; ", appName)

It's print only Application Name -&amp;gt; appName1.

Do you know please how I can get the two selected values ?

Thanks for your help

&lt;/pre&gt;</description>
    <dc:creator>Hicham Bellahcene</dc:creator>
    <dc:date>2013-05-22T09:00:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96989">
    <title>Go debugger with Android Studio?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96989</link>
    <description>&lt;pre&gt;I just re-read the slide on go_talk-20091030.pdf  (you can goole it 
annouced on Nov. 2,2009)

On p. 42, it showed "A custom debugger is underway; not quite ready yet(but 
close)"

Go 1.1 announced, is there any news about this sentence?

Or, the debugger was gdb at that time?

&lt;/pre&gt;</description>
    <dc:creator>dlin</dc:creator>
    <dc:date>2013-05-22T08:30:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96987">
    <title>Parse invalid/malformed/incomplete XML</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96987</link>
    <description>&lt;pre&gt;Hi,

I have a huge amount of malformed XML that was previously accepted and 
parsed by Ruby. Now I have to reparse it using Go. What are you using to 
parse invalid/malformed/incomplete XML?

Most popular errors I see are:
- &amp;lt;a&amp;gt;&amp;lt;b&amp;gt;&amp;lt;/b&amp;gt; - missing tag
- &amp;lt;a&amp;gt;&amp;lt;b&amp;gt;&amp;lt;/b - truncated XML
- &amp;lt;foo-bar&amp;gt;&amp;lt;/foo_bar&amp;gt; - miss-spelled closing tag

Thanks.

&lt;/pre&gt;</description>
    <dc:creator>Vladimir Mihailenco</dc:creator>
    <dc:date>2013-05-22T08:17:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96977">
    <title>Tool similar to guard in go</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96977</link>
    <description>&lt;pre&gt;Hello everyone.
  I have developed a tool that is similar to guard in go. It just watches 
files in specified folder and executes some console command when specific 
files are changed. Pretty simple. Here is link if anyone interested - 
https://github.com/romanoff/gow

But while developing tool I had one problem related to concurrency. Here - 
https://github.com/romanoff/gow/blob/master/gow_config.go#L42-44 somehow if 
I would use pointer instead of value ( (r *rule) and supplied self (not 
*self)), program was breaking. As well as if I would write "go 
self.handleEvents()". Can someone explain me why? Thanks a lot.

&lt;/pre&gt;</description>
    <dc:creator>Andrew Romanov</dc:creator>
    <dc:date>2013-05-22T06:51:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96973">
    <title>GNU/Hurd</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96973</link>
    <description>&lt;pre&gt;Any bets on how long until Minux or one of the other crazy gophers ports Go
to this...

http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hurd_2013.html

:)

&lt;/pre&gt;</description>
    <dc:creator>Brad Fitzpatrick</dc:creator>
    <dc:date>2013-05-22T06:32:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96963">
    <title>int usage instead of uint</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96963</link>
    <description>&lt;pre&gt;Hi all,

I'm just curious why functions such as len() and cap() return an 'int' 
instead of a 'uint'. I see several downsides of using signed types in these 
situations:

    (1) it's confusing since it's implied that negative values might be 
returned (and perhaps should be checked for?), and
    (2) it throws away half of the usable values for the type 
(2147483648 values thrown out on 32-bit machines)

It's of course a pedantic observation, but for a language with a focus on 
correctness such as Go, why are signed types used in such situations?

Thanks!

David

&lt;/pre&gt;</description>
    <dc:creator>davekeck-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T06:05:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96947">
    <title>Is this a bug of eclipse plugin on win7?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96947</link>
    <description>&lt;pre&gt;There is a sample.

package main

func main(){
   recurse()
}

func recurse(){
   recurse()
}

I run this code under eclipse environment on windows 7, it will cause my 
computer into deep death. keyboard and mouse are working, but system no 
response.

But using control-c to break it if run in a dos command box.

my environment:
windows 7
eclipse Juno service release 2, build id 20130225-0426
go version: 1.0 and 1.1



&lt;/pre&gt;</description>
    <dc:creator>Xiao Liang</dc:creator>
    <dc:date>2013-05-22T03:51:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96946">
    <title>Goweb Version 2 Beta 1!</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96946</link>
    <description>&lt;pre&gt;Hey everyone!

I'm posting to let everyone know about our update to the Goweb project. 
We've rewritten pretty much the entire thing from scratch to make it 
smarter, faster and more flexible.

If you're looking for a lightweight, flexible and easy way to provide REST 
capability to your go server, give it a look!

Please do feel free to submit issues, feature requests and pull requests!

http://stretchr.org/goweb/tree/v2

I hope some of you find it useful! :)

Thanks!

-Tyler

&lt;/pre&gt;</description>
    <dc:creator>tyler-gaJn0Q6uDvtWk0Htik3J/w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T02:45:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96939">
    <title>Single-buffer read from continuous read</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96939</link>
    <description>&lt;pre&gt;When reading from a continuous stream of data, I've used the following 
approach:
http://godoc.org/bitbucket.org/kardianos/rsync/sbuffer

With the following being the intended usage:
https://bitbucket.org/kardianos/rsync/src/default/proto/proto.go#cl-430

This appears to be a sound approach when there is a maximum packet size 
defined so the single-buffer can be capped at a reasonable level. Even 
though I only ever read into a single buffer, I can always get a contiguous 
slice to work with after each read.

Now, I have not profiled this nor have I compared this to alternate 
methods. This method was novel to me when I wrote it, however I imagine 
that many people have seen it. I used a similar (but more complex and 
integrated) method for my main streaming rsync delta reads (
https://bitbucket.org/kardianos/rsync/src/default/rsync.go#cl-227).

I'm looking for comments and possibly better alternative methods that 
perform at least as well, not so much to replace code but to better 
understand options for wh&lt;/pre&gt;</description>
    <dc:creator>Daniel Theophanes</dc:creator>
    <dc:date>2013-05-22T02:59:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.go.general/96936">
    <title>acheiving interning of strings</title>
    <link>http://comments.gmane.org/gmane.comp.lang.go.general/96936</link>
    <description>&lt;pre&gt;I'm doing an analysis of a large data set (120-150M) records which
represent spatial data (high thoughput genome sequence data with
consideration of the, for those who are interested [1]).

The string fields of the records are from a small set of values (not
determinable prior to the analysis) - the data structure that describes
the fields is here [2] - but the record reading makes it likely
(certain?) that each instance of the string values will be distinct
items. I need to store the entire set of records, so would like to be
able to intern the string values. The application heap size is on the
order of 100GB when running the analysis - at the moment I just discard
these strings.

How would I go about this in a reasonably efficient manner? 

I'm thinking something on the lines of this, but it feels magical:

type store map[string]string

func (is store) intern(s string) string {
t, ok := is[s]
if ok {
return t
}
is[s] = s
return s
}

The rationale for this is that if the string has been seen, the ret&lt;/pre&gt;</description>
    <dc:creator>Dan Kortschak</dc:creator>
    <dc:date>2013-05-22T02:21:16</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.go.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.go.general</link>
  </textinput>
</rdf:RDF>
