[go-nuts] Re: C.dll callback golang func will stuck

[Wanghb Wang]

在 2016年9月10日星期六 UTC+8上午5:01:14，James Bardin写道：
>
> You have a busy loop in main. Use another method to block, like a read in 
> stdin, wait for a signal, etc. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

[Dan Kortschak]

Can you explain the rationale behind the classification of libraries as
libraries or not libraries? It seems pretty arbitrary.

(I'm interested from a sociological perspective, but not enough to
bother to go to the benchmarks game discussion forum).

On Fri, 2016-09-09 at 15:08 -0700, 'Isaac Gouy' via golang-nuts wrote:
> 
> On Wednesday, September 7, 2016 at 7:44:28 PM UTC-7, Jason E. Aten wrote:
> >
> > Observe that the java benchmark continues to be allowed to use an 
> > accelerated hash table library.
> >
> 
> "accelerated" ?
> 
> By all means, post your reasons for *why that Java library should not be 
> used* in the benchmarks game discussion forum.
> 
> Let's have pity on golang-nuts.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Isaac Gouy' via golang-nuts]

On Wednesday, September 7, 2016 at 6:47:59 PM UTC-7, Clark Wierda wrote:

> Apparently, you can only use approved libraries that produce the ranking 
> he wants.
>


Which one of us is the language advocate? :-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] cgo and OSX "main thread"

[Martin Bertschler]

There is also a great wiki article on how to execute functions on the main 
thread from multiple goroutines. It helped me a lot when I did some GUI 
development experiments.
https://github.com/golang/go/wiki/LockOSThread

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: difference between template.Execute and template.ExecuteTemplate()

[Val]

Hello 
It seems that the relevant part of the doc is here 
 :

> Each template is named by a string specified when it is created. Also, 
> each template is associated with zero or more other templates that it may 
> invoke by name; such associations are transitive and form a name space of 
> templates. 
>

So, a *Template always has a name, whether explicitly set by user calling 
New(name), or automatically assigned by ParseFiles or ParseGlob. Also, you 
can have nested template definitions 
, 
which create additional template names.
At first I thought a *Template would "contain" one or more named "things", 
but the doc suggests that the right terminology would be "a template may 
have associated templates".

I wrote this example showing that Execute / ExecuteTemplate give different 
results, for different names invoked :
Execute 
ExecuteTemplate "phase1" 
ExecuteTemplate "phase2" 
ExecuteTemplate "phase3" 
ExecuteTemplate "wrongName" 

Cheers
 Val

On Friday, September 9, 2016 at 2:18:44 PM UTC+2, mir.an...@gmail.com wrote:
>
> Hi,
>
> func (t *Template) Execute(wr io.Writer, data interface{}) error
> func (t *Template) ExecuteTemplate(wr io.Writer, name string, data 
> interface{}) error
>
> Can someone tell me the difference between the above two functions ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] C.dll callback golang func will stuck

[James Bardin]

You have a busy loop in main. Use another method to block, like a read in 
stdin, wait for a signal, etc. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reading long text without newline from stdin

[Ian Lance Taylor]

On Fri, Sep 9, 2016 at 12:36 PM,   wrote:
>
> On Friday, 9 September 2016 18:45:24 UTC+2, Ian Lance Taylor wrote:
>>
>> On Fri, Sep 9, 2016 at 7:22 AM,   wrote:
>> >
>> > I was trying to read a longer text from stdin, without any newline. I
>> > tried
>> > it with many ways: fmt.Scan, bufio.NewScanner, bufio ReadLine,
>> > ioutil.ReadAll. A sample code looks like this:
>> >
>> > stackoverflow.com/questions/27196195/golang-read-from-pipe-reads-tons-of-data#answer-27196786
>> > If the length was just a bit longer than 4096 characters, the result was
>> > always the same: it was cut at 4096 characters.
>> >
>> > When I saved the text to a file, and read from there, every method
>> > worked.
>> > If I changed the spaces to newlines, every method worked from stdin. So
>> > only
>> > this combination was wrong. Looks like a bug for me.
>> >
>> > I wanted to use it for hackerrank.com excercises, where this is the
>> > typical
>> > input: long line given through stdin, without newline.
>> >
>> > Can anyone help me please?
>>
>> Show us the exact code you are running, and tell us about the system
>> on which you are running it.
>
> Almost the same code as the example I linked, I only changed the log to fmt
> print, and the buffer size from 4*1024 to 8*1024. So when I run it, enter a
> string with 4900 characters without newline, it waits for more input. Even
> if I end it with EOF (Ctrl+d) immediately, It writes this: Bytes: 4096
> Chunks: 1.
>
> I'm on Arch linux 32 bit. Latest go:

You are just typing the string on a terminal?  I'm pretty sure that
you are running into the terminal input buffer size, which is 4096 on
GNU/Linux (look for N_TTY_BUF_SIZE in the kernel sources).  That is
how many characters you can type on a terminal in canonical mode
before hitting a newline.  This has nothing to do with Go.  I expect
that you will see the same behavior with the cat program.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reading long text without newline from stdin

[vendelin8]

On Friday, 9 September 2016 18:45:24 UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Sep 9, 2016 at 7:22 AM,   wrote: 
> > 
> > I was trying to read a longer text from stdin, without any newline. I 
> tried 
> > it with many ways: fmt.Scan, bufio.NewScanner, bufio ReadLine, 
> > ioutil.ReadAll. A sample code looks like this: 
> > 
> stackoverflow.com/questions/27196195/golang-read-from-pipe-reads-tons-of-data#answer-27196786
>  
> > If the length was just a bit longer than 4096 characters, the result was 
> > always the same: it was cut at 4096 characters. 
> > 
> > When I saved the text to a file, and read from there, every method 
> worked. 
> > If I changed the spaces to newlines, every method worked from stdin. So 
> only 
> > this combination was wrong. Looks like a bug for me. 
> > 
> > I wanted to use it for hackerrank.com excercises, where this is the 
> typical 
> > input: long line given through stdin, without newline. 
> > 
> > Can anyone help me please? 
>
> Show us the exact code you are running, and tell us about the system 
> on which you are running it. 
>
> Ian 
>


Almost the same code as the example I linked, I only changed the log to fmt 
print, and the buffer size from 4*1024 to 8*1024. So when I run it, enter a 
string with 4900 characters without newline, it waits for more input. Even 
if I end it with EOF (Ctrl+d) immediately, It writes this: Bytes: 4096 
Chunks: 1.

I'm on Arch linux 32 bit. Latest go:
$ go version
go version go1.7.1 linux/386

The code:

package main

import (
"bufio"
"fmt"
"io"
"os"
)

func main() {
nBytes, nChunks := int64(0), int64(0)
r := bufio.NewReader(os.Stdin)
buf := make([]byte, 0, 8*1024)
for {
n, err := r.Read(buf[:cap(buf)])
buf = buf[:n]
if n == 0 {
if err == nil {
continue
}
if err == io.EOF {
break
}
fmt.Println(err)
}
nChunks++
nBytes += int64(len(buf))
// process buf
if err != nil && err != io.EOF {
fmt.Println(err)
}
}
fmt.Println("Bytes:", nBytes, "Chunks:", nChunks)
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] cgo and OSX "main thread"

[Alex Flint]

I am using cgo to wrap a library that creates an OSX UI, which requires
things to be run on the "main thread". Sometimes my cgo calls end up on the
main thread and sometimes they do not (I check this with [NSThread
isMainThread]). I understand that cgo threads are guaranteed to run on an
OS-allocated stack, but what does this mean w.r.t. the OSX "main thread"?
Has anyone else faced this problem before?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reading long text without newline from stdin

[Ian Lance Taylor]

On Fri, Sep 9, 2016 at 7:22 AM,   wrote:
>
> I was trying to read a longer text from stdin, without any newline. I tried
> it with many ways: fmt.Scan, bufio.NewScanner, bufio ReadLine,
> ioutil.ReadAll. A sample code looks like this:
> stackoverflow.com/questions/27196195/golang-read-from-pipe-reads-tons-of-data#answer-27196786
> If the length was just a bit longer than 4096 characters, the result was
> always the same: it was cut at 4096 characters.
>
> When I saved the text to a file, and read from there, every method worked.
> If I changed the spaces to newlines, every method worked from stdin. So only
> this combination was wrong. Looks like a bug for me.
>
> I wanted to use it for hackerrank.com excercises, where this is the typical
> input: long line given through stdin, without newline.
>
> Can anyone help me please?

Show us the exact code you are running, and tell us about the system
on which you are running it.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] reading long text without newline from stdin

[vendelin8]

Hi,

I was trying to read a longer text from stdin, without any newline. I tried 
it with many ways: fmt.Scan, bufio.NewScanner, bufio ReadLine, 
ioutil.ReadAll. A sample code looks like this:
stackoverflow.com/questions/27196195/golang-read-from-pipe-reads-tons-of-data#answer-27196786
If the length was just a bit longer than 4096 characters, the result was 
always the same: it was cut at 4096 characters.

When I saved the text to a file, and read from there, every method worked. 
If I changed the spaces to newlines, every method worked from stdin. So 
only this combination was wrong. Looks like a bug for me.

I wanted to use it for hackerrank.com excercises, where this is the typical 
input: long line given through stdin, without newline.

Can anyone help me please?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] gta - test combinations of deps

[Sam Boyer]

hi folks,

i've just gotten a new project to a vaguely-working-alpha state (release 
early, release often!) that facilitates automatically testing combinations 
of possible dependency versions: https://github.com/sdboyer/gta. it's 
gps-based (https://github.com/sdboyer/gps), and is at least sorta 
cross-package-manager.

it's kinda like git bisect, but for your deps! feedback is very, very 
welcome.

kudos to spf13 for suggesting something like this in the first place.

cheers
sam

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: interactive debugger for go ??

[Tim Shannon]

Visual Studio Code has a great Go implementation with the Delve debugger 
built in, and it runs on windows / mac / linux.

On Tuesday, September 6, 2016 at 11:42:13 AM UTC-5, JM wrote:
>
> Will there be a debugger that will allow me to step into my code, watch 
> the flow, and  go line by line  in real time, see values set, etc..?  does 
> this  already exist and  i'm  just not  aware  of  it?  I'm not a full time 
> go dev right now, but use it part time so I may just  not know about this.
>
> Worst case  can  someone let  me know what  the most  popular debugger for 
>  go  is (that runs on windows preferably or ubuntu)?
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] difference between template.Execute and template.ExecuteTemplate()

[Asit Dhal]

In case of second one, in the name string parameter, you need to specify 
the template name.



On 9/9/2016 14:04, mir.ansar...@gmail.com wrote:

Hi,

func (t *Template) Execute(wr io.Writer, data interface{}) error
func (t *Template) ExecuteTemplate(wr io.Writer, name string, data
interface{}) error

Can someone tell me the difference between the above two functions ?
--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Warm Regards,
Asit Dhal
http://asit-dhal.github.io/

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [database/sql] Scan rows to string arrays

[jnaradajayasingha]

TX!, This works for me

On Tuesday, March 12, 2013 at 2:38:15 AM UTC+5:30, Frank Blechschmidt wrote:
>
> Found it.
>
> Working solution:
> var result [][]string
> rows := repo.dbHandler.Query(sQuery)
> cols := rows.Columns()
> pointers := make([]interface{}, len(cols))
> container := make([]string, len(cols))
> for i, _ := range pointers {
> pointers[i] = [i]
> }
> for rows.Next() {
> rows.Scan(pointers...)
> result = append(result, container)
> }
>
>
>
>
>  
>
> On Monday, March 11, 2013 9:34:49 PM UTC+1, Frank Blechschmidt wrote:
>>
>> Hey!
>>
>> How to put SQL rows into an array of string arrays? (/convert SQL result 
>> to string matrix)
>>
>> Thanks and best regards
>> Frank
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] What is the correct usage for the -msan flag?

[Markus Zimmermann]

Hi gophers!

I am trying to integrate -msan for testing into 
https://github.com/go-clang/bootstrap using Go 1.7.1 and LLVM 3.9.0 inside 
an Ubuntu Trusty 64bit VM. The Kernel is 3.13.0.

I am executing a test using the following command:

CC=clang CGO_LDFLAGS="-L`llvm-config --libdir` -fsanitize=memory" 
> CGO_CPPFLAGS='-fsanitize=memory -fsanitize-memory-track-origins 
> -fno-omit-frame-pointer' go test -timeout 60s -v -msan 
> -test.run=TestBasicParsing
>

And the address sanitizer detects a problem for this test giving me the 
following output:

Uninitialized bytes in __interceptor_memchr at offset 6 inside 
> [0x7080bf58, 7)
> ==32156==WARNING: MemorySanitizer: use-of-uninitialized-value
> #0 0x7fdbcc7e3c85  
> (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x653c85)
> #1 0x7fdbcc7f40a7  
> (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x6640a7)
> #2 0x7fdbd0723bbe  
> (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0xc05bbe)
> #3 0x7fdbd07334ca  
> (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0xc154ca)
> #4 0x7fdbcffaef39  
> (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0x490f39)
> #5 0x7fdbcff8c504  
> (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0x46e504)
> #6 0x7fdbcfd8178e  
> (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0x26378e)
> #7 0x7fdbcc7be314  
> (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x62e314)
> #8 0x7fdbcc7be393  
> (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x62e393)
> #9 0x7fdbcc8214bc  
> (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x6914bc)
> #10 0x7fdbcf908183  (/lib/x86_64-linux-gnu/libpthread.so.0+0x8183)
> #11 0x7fdbced0d37c  (/lib/x86_64-linux-gnu/libc.so.6+0xfa37c)
>
>   Uninitialized value was stored to memory at
> #0 0x42d0d5  
> (/tmp/go-build816629300/github.com/go-clang/bootstrap/clang/_test/clang.test+0x42d0d5)
> #1 0x7fdbcbf479bd  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbb9bd)
>
>   Uninitialized value was stored to memory at
> #0 0x42d0d5  
> (/tmp/go-build816629300/github.com/go-clang/bootstrap/clang/_test/clang.test+0x42d0d5)
> #1 0x7fdbcbf46e2f  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbae2f)
>
>   Uninitialized value was created by a heap allocation
> #0 0x42b6d9  
> (/tmp/go-build816629300/github.com/go-clang/bootstrap/clang/_test/clang.test+0x42b6d9)
> #1 0x7fdbcbeeadac  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x5edac)
>
> SUMMARY: MemorySanitizer: use-of-uninitialized-value 
> (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x653c85)
>


I have the following questions concerning the usage of the -msan flag:
a.) Are these the preferred arguments to use the -msan flag?
b.) Why are there no line numbers in the traces?
c.) Any advice on how I can debug such problems?
d.) What are the official minimum requirements for the -msan flag? (LLVM >= 
3.8? ...?)

I appreciate any input since I am completely lost on how to address this 
problem :-/

Cheers,
Markus

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Request to backport OSX Sierra fix in 1.6.4

[gary . willoughby]

Purely out of interest, why not upgrade to v1.7.1?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is SizedReaderAt coming back in 1.8?

['Ingo Oeser' via golang-nuts]

The missing inclusion stems from a misunderstanding of the intended api.

The Size method should return the upper bound for the offset passed to ReadAt 
known ahead of time. 

If the upper bound cannot be detected, the SizedReaderAt will simply fail 
creation. 

When the Size changes, ReadAt will return any errors related to that. 

So there really is no need for Size to return an error.

The misunderstanding happened while trying to make os.File satisfy this 
interface, while it actually needs a small helper function doing File.Stat 
ahead of time and a small intermediate type to convert between them.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is SizedReaderAt coming back in 1.8?

[Dan Kortschak]

The problem is that some Size methods return (int64, error) and others
return int64, so the interface was removed, since it can't match all the
types in the stdlib that it might be useful for.

You can easily define it yourself for your own use though, and provide a
shim for the types that don't quite fit (the ugliness that follows is
why it's not there) https://play.golang.org/p/j0PednO__i


On Thu, 2016-09-08 at 21:40 -0700, Carl Mastrangelo wrote:
> It seems that io.SizedReaderAt was added temporarily during the 1.7
> cycle, but promptly removed.  I see an standing github issue for it
> (15822) but it doesn't seem to have much activity.  
> 
> I would like to express my hope that it comes back (and hopefully
> others will to).  A use case that I am interested in is turning a
> ReaderAt into a Reader, which is currently non-trivial to convert.
> The io package has a SectionReader, but to create one of those you
> need to know the size, which a plain ReaderAt won't provide.
> 
> There are some other places in the API that would benefit from such a
> class, such as the archive/zip package.  Currently, it is not possible
> to read from an in memory Zip file, because the only method to open
> zips is OpenReader(name string) !?  I understand that the index is at
> the back of the file, so a plain reader can't be passed in.  However,
> a SizedReaderAt would conveniently fit as a zip Reader, since it know
> the size in advance.  



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.