Re: [go-nuts] Re: Ioctl Syscall with go and c

[Tamás Gulácsi]

2018. augusztus 23., csütörtök 21:50:54 UTC+2 időpontban sbez...@cisco.com 
a következőt írta:
>
> I copied the whole thing to https://github.com/sbezverk/vfio 
>
> Running it without actual vfio/iommu might be problematic though. 
>
> Before this specific ioctl can be run 2 open calls must succeed. See func 
> main. 
>
> Thank you for looking into this problem 
> Serguei 
>
> Sent from my iPhone 
>
> > On Aug 23, 2018, at 12:49 PM, Tamás Gulácsi  > wrote: 
> > 
> > Cany you give a complete example? 
> > 
> >  https://play.golang.org/p/ZQSf-PwMtd9 
> > 
> > says 
> > 
> >  "device=18446744073709551615 errno=inappropriate ioctl for device" 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

Ok, clearly I cannot test it - either I don't have the required setup, or 
the needed knowledge of what the hell is VFIO.

Some googling around says:

VFIO_GROUP_GET_DEVICE_FD - _IOW(VFIO_TYPE, VFIO_BASE + 6, char) * * Return a 
new file descriptor for the device object described by * the provided string.  
The string should match a device listed in * the devices subdirectory of the 
IOMMU group sysfs entry.  The * group containing the device must already be 
added to this context. * Return: new file descriptor on success, -errno on 
failure. * Availability: When attached to container */

The strange thing in vfio.go GetGroupFD is the use of *string - as you don't 
want to modify that path, you shouldn't use a pointer.
But that's nothing to do with the ioctl.

The fill of buffer, and the use seems legit.

IF you have a working C program, I'd try to strace both C and Go and see what's 
different.

-- 
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] Connecting to a nondefault database with denisenkom

[Femi]

This is potentially a noob question but I thought I would ask anyway. I am 
trying to connect to a nondefault database using denisenkom/go-mssqldb. I 
am able to connect to master using the code below but swapping the master 
database to a database that I created fails. I figured that I can do 
something like " 
select * from HospitalDb.dbo.Patient" but would like to be able to connect 
directly to HospitalDb using the connection string below. Any suggestion 
would be appreciated.


condb, errdb := sql.Open("mssql", "server=.\\Standard;user 
id=sa;password=prestige;encrypt=disable;database=master")

-- 
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] Does runtime.RaceDisable not work in non-std library ?

[Dave Cheney]

Hi,

Can you please do two things to help with this error report.

1. Please include the entire data race report -- we need this to match up 
the line with the source code you've provided in the gist
2. Please double check that you are not copying a your sync.Pool type by 
value, this can happen if you have a type declared on sync.Pool, not 
*sync.Pool, or it could happen if you do something like this

var x sync.Pool
y := x

Thanks

Dave

On Friday, 24 August 2018 13:46:10 UTC+10, nea...@gmail.com wrote:
>
> Hi lan,
>
> The sync.Pool has memory accesses in per-p private storage. Why it not 
> reports `DATA RACE`, but it reports when I copy those code outside stdlib?
> I'm confused about this, or there is something wrong in 
> https://gist.github.com/lrita/efa8c4ae555b4b7cceee29b4ed819652 
> Thanks.
>
> 在 2018年8月24日星期五 UTC+8上午4:36:06，Ian Lance Taylor写道：
>>
>> On Thu, Aug 23, 2018 at 12:43 AM,   wrote: 
>> > package main 
>> > 
>> > import "runtime" 
>> > 
>> > var a int 
>> > 
>> > func calc() { 
>> > for i := 0; i < 10; i++ { 
>> > go func() { 
>> > for { 
>> > runtime.RaceDisable() 
>> > a++ 
>> > runtime.RaceEnable() 
>> > } 
>> > }() 
>> > 
>> > } 
>> > } 
>> > 
>> > func main() { 
>> > calc() 
>> > } 
>> > 
>> > go run -race a.go 
>>
>> Thanks for the example.  As the docs for runtime.RaceDisable say, it 
>> only applies to synchronization events, like mutex locks.  It doesn't 
>> apply to memory accesses. 
>>
>> Ian 
>>
>>
>> > 在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道： 
>> >> 
>> >> On Wed, Aug 22, 2018 at 3:25 AM,   wrote: 
>> >> > 
>> >> > When I copy the sync.Pool's source code in a repo, and using 
>> >> > `//go:linkname` 
>> >> > link those runtime functions manually. 
>> >> > When I run `go test -race`, it reports `DATA RACE`. 
>> >> > But the sync.Pool with the same test case does not report  `DATA 
>> RACE`. 
>> >> > 
>> >> > Does runtime.RaceDisable not work in non-std library ? 
>> >> 
>> >> It should work.  I think you'll have to show us your code. 
>> >> 
>> >> 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...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
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] Does runtime.RaceDisable not work in non-std library ?

[nealhoo]

Hi lan,

The sync.Pool has memory accesses in per-p private storage. Why it not 
reports `DATA RACE`, but it reports when I copy those code outside stdlib?
I'm confused about this, or there is something wrong in 
https://gist.github.com/lrita/efa8c4ae555b4b7cceee29b4ed819652 
Thanks.

在 2018年8月24日星期五 UTC+8上午4:36:06，Ian Lance Taylor写道：
>
> On Thu, Aug 23, 2018 at 12:43 AM,  > 
> wrote: 
> > package main 
> > 
> > import "runtime" 
> > 
> > var a int 
> > 
> > func calc() { 
> > for i := 0; i < 10; i++ { 
> > go func() { 
> > for { 
> > runtime.RaceDisable() 
> > a++ 
> > runtime.RaceEnable() 
> > } 
> > }() 
> > 
> > } 
> > } 
> > 
> > func main() { 
> > calc() 
> > } 
> > 
> > go run -race a.go 
>
> Thanks for the example.  As the docs for runtime.RaceDisable say, it 
> only applies to synchronization events, like mutex locks.  It doesn't 
> apply to memory accesses. 
>
> Ian 
>
>
> > 在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道： 
> >> 
> >> On Wed, Aug 22, 2018 at 3:25 AM,   wrote: 
> >> > 
> >> > When I copy the sync.Pool's source code in a repo, and using 
> >> > `//go:linkname` 
> >> > link those runtime functions manually. 
> >> > When I run `go test -race`, it reports `DATA RACE`. 
> >> > But the sync.Pool with the same test case does not report  `DATA 
> RACE`. 
> >> > 
> >> > Does runtime.RaceDisable not work in non-std library ? 
> >> 
> >> It should work.  I think you'll have to show us your code. 
> >> 
> >> 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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: function's argument default value

[Louki Sumirniy]

I don't think the benefits are obvious and being able to leave out 
parameters by specifying one by name is of dubious benefit. Could you not 
simply write a short set of if statements that insert a default by using a 
nulled sentinel. Like this:

func PrintMessage(s string) {
  if s == "" {
s = "default value"
  }
  DoSomeThing(s)
}

Then call it

PrintMessage("")



On Friday, 24 August 2018 01:38:36 UTC+2, Masoud Ghorbani wrote:
>
> You're right but I think developers of Go can think about that because its 
> benefits are obvious.
>
> On Friday, August 24, 2018 at 1:23:32 AM UTC+4:30, Axel Wagner wrote:
>>
>> On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani  
>> wrote:
>>
>>> Your opinion is like to say all of the python application should rethink 
>>> and re-write their structure because they used default values.
>>>
>>
>> One general thing to observe in all these discussions is, that Go is not 
>> Python (or Rust, Haskell, C#,…). Different languages have different goals, 
>> weigh them differently and choose different solutions to get there - and 
>> that's okay. Saying something isn't right for Go isn't the same as saying 
>> something isn't right for a different language. In the same way, saying 
>> some other language is doing something is not a convincing argument that Go 
>> should do it too.
>>  
>>
>>> I think having default values for parameters is just a feature which 
>>> will make codebase readable and smaller than before.
>>>
>>> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy 
>>> wrote:

 There is a default value for everything in Go. Null. 0, "" and nil. As 
 someone else said, if you want a parameter to be optional you probably 
 need 
 ...interface{} and then infer no parameter as 'use the default'. Going a 
 little further, you can build default values into a constructor function 
 for an interfaced type. 

 Oh, probably the neatest solution is to make a struct that lets you 
 input the parameters either in-order or with labels instead. Then you can 
 use {} to mean 'use defaults' or whichever parameters are not 
 specified get automatically set to default, either unlabeled and ordered 
 such that the values that will be asserted to defaults are not the first 
 ones in a struct literal used to feed parameters in. Or make the names 
 nice 
 and concise so they aren't troublesome to add (and if your code is going 
 to 
 often use defaults, probably you won't even have to specify many values 
 very often anyway).

 Assertions and labeled parameters are nice features but they don't 
 really save you that much time. I would suggest that it's more likely you 
 need to rethink the structure of your application and make slightly 
 different named parameters for those calls that will use defaults for 
 specific parameters.

 Another thing is that you can make null variables imply the use of 
 defaults, then you only need to put 'nil' '""' or '0' into these 
 parameters 
 and the code will test and fill them automatically. Or if null isn't 
 handy, 
 you can define sentinel values for a type that indicate 'use defaults'.

 On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>
> Why there isn't function argument default value in Golang explicitly 
> like Typescript and Python?
>
 -- 
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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: function's argument default value

[Louki Sumirniy]

I have to agree. The idiomatic solution would be defining multiple 
functions that wrap around another, and it is not onerously boilerplatey. 
As Ian says, default values do constitute effectively function overloads.

There is  reason why function overloading is not available in Go. Just go 
look at some typical c++ code. Not only overloading but operator 
overloading as well. Looking at one source file you may not be able to 
figure out what any symbol in the file actually refers to. Watch the way 
symbol analysis tools like Codelens give you references to a given 
symbol... I know in the bitcoin codebase, nearly every symbol in the whole 
damn codebase codelens suggests like 5 different definitions for 
everything. One of them is correct, of course, but the only way to find out 
is to compile it, and an eternity later it just does stuff and because the 
source code is so difficult to analyse, you are still none the wiser.

I would think that for those who really really need such  feature, the 
solution would be with using a code generator/preprocessor. But then you 
will lose a lot of the advantage of writing it in Go in the first place.

On Friday, 24 August 2018 02:51:37 UTC+2, andrey mirtchovski wrote:
>
> > You're right but I think developers of Go can think about that because 
> its benefits are obvious. 
>
> can you please enumerate those benefits? many gophers are not 
> convinced they are obvious. 
>

-- 
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: function's argument default value

[andrey mirtchovski]

> You're right but I think developers of Go can think about that because its 
> benefits are obvious.

can you please enumerate those benefits? many gophers are not
convinced they are obvious.

-- 
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: function's argument default value

[Masoud Ghorbani]

You're right but I think developers of Go can think about that because its 
benefits are obvious.

On Friday, August 24, 2018 at 1:23:32 AM UTC+4:30, Axel Wagner wrote:
>
> On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani  > wrote:
>
>> Your opinion is like to say all of the python application should rethink 
>> and re-write their structure because they used default values.
>>
>
> One general thing to observe in all these discussions is, that Go is not 
> Python (or Rust, Haskell, C#,…). Different languages have different goals, 
> weigh them differently and choose different solutions to get there - and 
> that's okay. Saying something isn't right for Go isn't the same as saying 
> something isn't right for a different language. In the same way, saying 
> some other language is doing something is not a convincing argument that Go 
> should do it too.
>  
>
>> I think having default values for parameters is just a feature which will 
>> make codebase readable and smaller than before.
>>
>> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>>
>>> There is a default value for everything in Go. Null. 0, "" and nil. As 
>>> someone else said, if you want a parameter to be optional you probably need 
>>> ...interface{} and then infer no parameter as 'use the default'. Going a 
>>> little further, you can build default values into a constructor function 
>>> for an interfaced type. 
>>>
>>> Oh, probably the neatest solution is to make a struct that lets you 
>>> input the parameters either in-order or with labels instead. Then you can 
>>> use {} to mean 'use defaults' or whichever parameters are not 
>>> specified get automatically set to default, either unlabeled and ordered 
>>> such that the values that will be asserted to defaults are not the first 
>>> ones in a struct literal used to feed parameters in. Or make the names nice 
>>> and concise so they aren't troublesome to add (and if your code is going to 
>>> often use defaults, probably you won't even have to specify many values 
>>> very often anyway).
>>>
>>> Assertions and labeled parameters are nice features but they don't 
>>> really save you that much time. I would suggest that it's more likely you 
>>> need to rethink the structure of your application and make slightly 
>>> different named parameters for those calls that will use defaults for 
>>> specific parameters.
>>>
>>> Another thing is that you can make null variables imply the use of 
>>> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
>>> and the code will test and fill them automatically. Or if null isn't handy, 
>>> you can define sentinel values for a type that indicate 'use defaults'.
>>>
>>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:

 Why there isn't function argument default value in Golang explicitly 
 like Typescript and Python?

>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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: function's argument default value

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani
 wrote:
> I didn't get the relation of function overloading with parameters default
> value. actually, function overloading means define functions with similar
> names.

Right.  After adding a default value for the parameter, you have two
functions with similar names:
F(int)
F()

It's exactly as though you overloaded F.

Ian


> On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani
>>  wrote:
>> >
>> > Your opinion is like to say all of the python application should rethink
>> > and
>> > re-write their structure because they used default values. I think
>> > having
>> > default values for parameters is just a feature which will make codebase
>> > readable and smaller than before.
>>
>> Default values for parameters is in effect a simple form of function
>> overloading.  If F(int) has a default value for the parameter, then
>> you've overloaded F with another function F() that takes no arguments.
>> Go doesn't have function overloading in general, and it doesn't have
>> default parameter values either.
>>
>> 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.

-- 
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: function's argument default value

[Masoud Ghorbani]

I didn't get the relation of function overloading with parameters default 
value. actually, *function overloading* 
 
means define functions with similar names.

On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor wrote:
>
> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani 
> > wrote: 
> > 
> > Your opinion is like to say all of the python application should rethink 
> and 
> > re-write their structure because they used default values. I think 
> having 
> > default values for parameters is just a feature which will make codebase 
> > readable and smaller than before. 
>
> Default values for parameters is in effect a simple form of function 
> overloading.  If F(int) has a default value for the parameter, then 
> you've overloaded F with another function F() that takes no arguments. 
> Go doesn't have function overloading in general, and it doesn't have 
> default parameter values either. 
>
> 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] internal compilation error while compiling gccgo from source solaris 10

[Amandeep Gautam]

Running inside the gdb worked. Seems like a problem with libmpfr. Will try 
compiling it from source.
Following is the end of the GDB output:

/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go:658:43: error: 
expected integer, floating, complex, or string type
   s.errorString("integer overflow on token " + tok)
   ^
/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go:688:52: error: 
expected integer, floating, complex, or string type
   s.errorString("unsigned integer overflow on token " + tok)
^

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfbb8df24 in mpfr_init2 () from /opt/csw/lib/sparcv8/libmpfr.so.4
(gdb) bt
#0  0xfbb8df24 in mpfr_init2 () from /opt/csw/lib/sparcv8/libmpfr.so.4
#1  0xff1d8bac in mpc_init2 () from /usr/lib/libmpc.so.3
#2  0x001c5500 in Numeric_constant::check_complex_type (this=0xffbff0e8, 
type=0x1094488, issue_error=, location=...)
at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/expressions.cc:16745
#3  0x001c588c in Numeric_constant::set_type (this=0xffbff0e8, 
type=0x11f4f38, issue_error=, loc=...)
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/types.h:751
#4  0x001c5944 in Integer_expression::do_check_types (this=0x11f50a0) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/expressions.h:535
#5  0x001e7d04 in check_types (gogo=, this=) 
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/expressions.h:920
#6  Check_types_traverse::expression (this=, expr=0x123ba88) 
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:3306
#7  0x001b3fc8 in Expression::traverse (pexpr=0x123ba88, 
traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/expressions.cc:45
#8  0x0022eb8c in Statement::traverse (this=0x123ba78, block=0x123c128, 
pindex=0xffbff294, traverse=0xffbff6d4)
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/statements.cc:54
#9  0x001ea9f0 in Block::traverse (this=0x123c128, traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:6063
#10 0x0022eb8c in Statement::traverse (this=0x123ba98, block=0x11f5078, 
pindex=0xffbff35c, traverse=0xffbff6d4)
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/statements.cc:54
#11 0x001ea9f0 in Block::traverse (this=0x11f5078, traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:6063
#12 0x0022df60 in If_statement::do_traverse (this=0x11f6370, 
traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/statements.cc:84
#13 0x0022eb8c in Statement::traverse (this=0x11f6370, block=0x11f5028, 
pindex=0xffbff484, traverse=0xffbff6d4)
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/statements.cc:54
#14 0x001ea9f0 in Block::traverse (this=0x11f5028, traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:6063
#15 0x0022eb8c in Statement::traverse (this=0x11f6390, block=0x11f4f60, 
pindex=0xffbff54c, traverse=0xffbff6d4)
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/statements.cc:54
#16 0x001ea9f0 in Block::traverse (this=0x11f4f60, traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:6063
#17 0x001eac80 in Function::traverse (this=0x11f6a88, traverse=0xffbff6d4) 
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:5135
#18 0x001ec6f0 in Bindings::traverse (this=0x10b4f60, traverse=0xffbff6d4, 
is_global=) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.h:2584
#19 0x001eca38 in Gogo::traverse (this=0x10f03f8, traverse=0xffbff6d4) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.h:3200
#20 0x001ecd2c in Gogo::check_types (this=0x10f03f8) at 
/export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:3316
#21 0x001e7700 in go_parse_input_files (filenames=0x10cf468, 
filename_count=4, only_check_syntax=)
at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/go.cc:136
#22 0x001e2480 in go_langhook_parse_file () at 
/export/home/amandeep/gccgo-src/gcc/go/go-lang.c:329
#23 0x006b97d4 in compile_file () at 
/export/home/amandeep/gccgo-src/gcc/toplev.c:455
#24 0x00e1c9f4 in toplev::main(int, char**) () at ./insn-modes-inline.h:38
#25 0x00e1e1e4 in main (argc=21, argv=0xffbffa44) at 
/export/home/amandeep/gccgo-src/gcc/main.c:39

On Thursday, August 23, 2018 at 2:25:38 PM UTC-7, Ian Lance Taylor wrote:
>
> On Thu, Aug 23, 2018 at 2:14 PM, Amandeep Gautam 
> > wrote: 
> > 
> > /export/home/amandeep/gccgo-obj/./gcc/go1 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go -quiet -dumpbase 
> doc.go 
> > -mcpu=v9 -auxbase-strip .libs/fmt.o -g -O2 -version -fgo-pkgpath=fmt 
> -fPIC 
> > -I . -L/export/home/amandeep/gccgo-obj/./gcc -o /var/tmp//ccmxS20e.s 
> > 
> > and I got: 
> > 
> > GNU Go (GCC) version 

Re: [go-nuts] internal compilation error while compiling gccgo from source solaris 10

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 2:14 PM, Amandeep Gautam
 wrote:
>
> /export/home/amandeep/gccgo-obj/./gcc/go1
> /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go
> /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go
> /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go
> /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go -quiet -dumpbase doc.go
> -mcpu=v9 -auxbase-strip .libs/fmt.o -g -O2 -version -fgo-pkgpath=fmt -fPIC
> -I . -L/export/home/amandeep/gccgo-obj/./gcc -o /var/tmp//ccmxS20e.s
>
> and I got:
>
> GNU Go (GCC) version 8.2.1 20180814 (sparc-sun-solaris2.10)
> compiled by GNU C version 8.2.1 20180814, GMP version 6.1.2, MPFR
> version 4.0.0, MPC version 1.0.2, isl version csw-0.18-GMP
>
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> GNU Go (GCC) version 8.2.1 20180814 (sparc-sun-solaris2.10)
> compiled by GNU C version 8.2.1 20180814, GMP version 6.1.2, MPFR
> version 4.0.0, MPC version 1.0.2, isl version csw-0.18-GMP
>
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go:8:9: error: import
> file 'strconv' not found
>   "strconv"
>  ^
> /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go:9:14: error: import
> file 'unicode/utf8' not found
>   "unicode/utf8"
>   ^
> ... and many more before ending into ...
>
> /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go:688:52: error: expected
> integer, floating, complex, or string type
>s.errorString("unsigned integer overflow on token " + tok)
> ^
> Segmentation Fault (core dumped)
>
> I tried analyzing the core dumped. so I did: gdb
> /export/home/amandeep/gccgo-obj/./gcc/go1 ./core  and below is how the promt
> looks:
>
> GNU gdb (GDB) 7.7
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "sparc-sun-solaris2.10".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /export/home/amandeep/gccgo-obj/./gcc/go1...done.
>
> warning: Couldn't find general-purpose registers in core file.
>
> warning: Wrong size fpregset in core file.
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
>
> warning: Couldn't find general-purpose registers in core file.
>
> warning: Couldn't find general-purpose registers in core file.
> Error in re-setting breakpoint -1: PC register is not available
> Error in re-setting breakpoint -2: PC register is not available
> Error in re-setting breakpoint -3: PC register is not available
> Error in re-setting breakpoint -4: PC register is not available
> Error in re-setting breakpoint -5: PC register is not available
> Core was generated by `/export/home/amandeep/gccgo-obj/./gcc/go1
> /export/home/amandeep/gccgo-src/libgo'.
>
> warning: Couldn't find general-purpose registers in core file.
>
> warning: Wrong size fpregset in core file.
> PC not available
> #-1  in ?? ()
> (gdb) bt
> #-1  in ?? ()
> #0   in ?? ()
> frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) n
> frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) y
> Command aborted.
>
> Have I steps mentioned correctly? Any suggestions on the next steps?

There is something badly wrong with your gdb.  Unfortunately I can't
help you with that.  I have not seen that behavior before.

I guess you could hope that the problem is only with the core file,
and run the program inside gdb rather than trying to look at the core.

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] internal compilation error while compiling gccgo from source solaris 10

[Amandeep Gautam]

Thanks. I did do that befor but thought you meant different. I ran the 
following:

/export/home/amandeep/gccgo-obj/./gcc/gccgo 
-B/export/home/amandeep/gccgo-obj/./gcc/ 
-B/usr/gnu/sparc-sun-solaris2.10/bin/ -B/usr/gnu/sparc-sun-solaris2.10/lib/ 
-isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem 
/usr/gnu/sparc-sun-solaris2.10/sys-include -O2 -g -I . -c -fgo-pkgpath=fmt 
/export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go  -fPIC -o .libs/fmt.o

and got:

Reading specs from /export/home/amandeep/gccgo-obj/./gcc/specs
COLLECT_GCC=/export/home/amandeep/gccgo-obj/./gcc/gccgo
Target: sparc-sun-solaris2.10
Configured with: /export/home/amandeep/gccgo-src/configure 
--prefix=/usr/gnu --enable-languages=go --with-as=/opt/csw/gnu/as 
--with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld 
--with-gmp-include=/opt/csw/include --with-gmp-lib=/opt/csw/lib 
--with-mpfr=/opt/csw --with-mpfr-include=/opt/csw/include 
--with-mpfr-lib=/opt/csw/lib --with-mpc=/opt/csw --with-isl=/opt/csw 
--with-isl-include=/opt/csw/include --with-isl-lib=/opt/csw/lib 
--with-build-time-tools=/opt/csw/gnu --enable-multilib --enable-shared 
--enable-static --disable-nls --disable-libquadmath --disable-libssp 
--disable-lto --disable-libgomp
Thread model: posix
gcc version 8.2.1 20180814 (GCC) 
COLLECT_GCC_OPTIONS='-B' '/export/home/amandeep/gccgo-obj/./gcc/' '-B' 
'/usr/gnu/sparc-sun-solaris2.10/bin/' '-B' 
'/usr/gnu/sparc-sun-solaris2.10/lib/' '-isystem' 
'/usr/gnu/sparc-sun-solaris2.10/include' '-isystem' 
'/usr/gnu/sparc-sun-solaris2.10/sys-include' '-v' '-O2' '-g' '-I' '.' '-c' 
'-fgo-pkgpath=fmt' '-fPIC' '-o' '.libs/fmt.o' '-shared-libgcc' '-mcpu=v9'
 /export/home/amandeep/gccgo-obj/./gcc/go1 
/export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go -quiet -dumpbase 
doc.go -mcpu=v9 -auxbase-strip .libs/fmt.o -g -O2 -version -fgo-pkgpath=fmt 
-fPIC -I . -L/export/home/amandeep/gccgo-obj/./gcc -o /var/tmp//ccmxS20e.s
GNU Go (GCC) version 8.2.1 20180814 (sparc-sun-solaris2.10)
compiled by GNU C version 8.2.1 20180814, GMP version 6.1.2, MPFR 
version 4.0.0, MPC version 1.0.2, isl version csw-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Go (GCC) version 8.2.1 20180814 (sparc-sun-solaris2.10)
compiled by GNU C version 8.2.1 20180814, GMP version 6.1.2, MPFR 
version 4.0.0, MPC version 1.0.2, isl version csw-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/export/home/amandeep/gccgo-src/libgo/go/fmt/format.go:8:9: error: import 
file 'strconv' not found
  "strconv"
 ^
/export/home/amandeep/gccgo-src/libgo/go/fmt/format.go:9:14: error: import 
file 'unicode/utf8' not found
  "unicode/utf8"
  ^
/export/home/amandeep/gccgo-src/libgo/go/fmt/print.go:8:8: error: import 
file 'errors' not found
  "errors"
^
/export/home/amandeep/gccgo-src/libgo/go/fmt/print.go:9:4: error: import 
file 'io' not found
  "io"

* and many more like this before ending as follows:*

/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go:688:52: error: 
expected integer, floating, complex, or string type
   s.errorString("unsigned integer overflow on token " + tok)
^
gccgo: internal compiler error: Segmentation Fault signal terminated 
program go1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Before running this, I have already exported the paths as I did in the 
script in the first post. These are below:

export PATH=/opt/csw/bin:/usr/sbin:$PATH:/usr/sfw/bin:/usr/ccs/bin
export LD_OPTIONS='-R/opt/csw/lib'
export M4=/opt/csw/bin/gm4

As suggested, next I ran:

/export/home/amandeep/gccgo-obj/./gcc/go1 
/export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go -quiet -dumpbase 
doc.go -mcpu=v9 -auxbase-strip .libs/fmt.o -g -O2 -version -fgo-pkgpath=fmt 
-fPIC -I . -L/export/home/amandeep/gccgo-obj/./gcc -o /var/tmp//ccmxS20e.s

and I got:

GNU Go (GCC) version 8.2.1 20180814 (sparc-sun-solaris2.10)
compiled by GNU C version 8.2.1 20180814, GMP version 6.1.2, MPFR 
version 4.0.0, MPC version 1.0.2, isl version csw-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Go (GCC) version 8.2.1 20180814 (sparc-sun-solaris2.10)
compiled by GNU C version 8.2.1 20180814, GMP version 6.1.2, MPFR 
version 4.0.0, MPC version 1.0.2, isl version csw-0.18-GMP

GGC heuristics: --param 

Re: [go-nuts] Re: function's argument default value

['Axel Wagner' via golang-nuts]

On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani 
wrote:

> Your opinion is like to say all of the python application should rethink
> and re-write their structure because they used default values.
>

One general thing to observe in all these discussions is, that Go is not
Python (or Rust, Haskell, C#,…). Different languages have different goals,
weigh them differently and choose different solutions to get there - and
that's okay. Saying something isn't right for Go isn't the same as saying
something isn't right for a different language. In the same way, saying
some other language is doing something is not a convincing argument that Go
should do it too.


> I think having default values for parameters is just a feature which will
> make codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default value for everything in Go. Null. 0, "" and nil. As
>> someone else said, if you want a parameter to be optional you probably need
>> ...interface{} and then infer no parameter as 'use the default'. Going a
>> little further, you can build default values into a constructor function
>> for an interfaced type.
>>
>> Oh, probably the neatest solution is to make a struct that lets you input
>> the parameters either in-order or with labels instead. Then you can use
>> {} to mean 'use defaults' or whichever parameters are not
>> specified get automatically set to default, either unlabeled and ordered
>> such that the values that will be asserted to defaults are not the first
>> ones in a struct literal used to feed parameters in. Or make the names nice
>> and concise so they aren't troublesome to add (and if your code is going to
>> often use defaults, probably you won't even have to specify many values
>> very often anyway).
>>
>> Assertions and labeled parameters are nice features but they don't really
>> save you that much time. I would suggest that it's more likely you need to
>> rethink the structure of your application and make slightly different named
>> parameters for those calls that will use defaults for specific parameters.
>>
>> Another thing is that you can make null variables imply the use of
>> defaults, then you only need to put 'nil' '""' or '0' into these parameters
>> and the code will test and fill them automatically. Or if null isn't handy,
>> you can define sentinel values for a type that indicate 'use defaults'.
>>
>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>>
>>> Why there isn't function argument default value in Golang explicitly
>>> like Typescript and Python?
>>>
>> --
> 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.
>

-- 
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: function's argument default value

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani
 wrote:
>
> Your opinion is like to say all of the python application should rethink and
> re-write their structure because they used default values. I think having
> default values for parameters is just a feature which will make codebase
> readable and smaller than before.

Default values for parameters is in effect a simple form of function
overloading.  If F(int) has a default value for the parameter, then
you've overloaded F with another function F() that takes no arguments.
Go doesn't have function overloading in general, and it doesn't have
default parameter values either.

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] internal compilation error while compiling gccgo from source solaris 10

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 1:24 AM, Amandeep Gautam
 wrote:
> Hi Ian,
>   I ran the following after changing directory to
> /export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo/:
>
> files=`echo /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go
> /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go
> /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go
> /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go errors.gox io.gox
> math.gox os.gox reflect.gox strconv.gox sync.gox unicode/utf8.gox | sed -e
> 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/bash ./libtool --tag GO
> --mode=compile --verbose /export/home/amandeep/gccgo-obj/./gcc/gccgo
> -B/export/home/amandeep/gccgo-obj/./gcc/
> -B/usr/gnu/sparc-sun-solaris2.10/bin/ -B/usr/gnu/sparc-sun-solaris2.10/lib/
> -isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem
> /usr/gnu/sparc-sun-solaris2.10/sys-include   -O2 -g -I . -c
> -fgo-pkgpath=`echo fmt.lo | sed -e 's/.lo$//' -e
> 's|golang_org|vendor/golang_org|'`  -o fmt.lo $files
>
> I still get the same compilation error:
>
> go1: internal compiler error: Segmentation Fault
> 0x6b9757 crash_signal
> /export/home/amandeep/gccgo-src/gcc/toplev.c:325
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
>
> and did not get any more output using the verbose option. What should have
> been done differently?

Don't use that command, use the command that that prints out: the line
that starts with "libtool: compile:".

Ian


> On Monday, August 20, 2018 at 6:41:54 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Sun, Aug 19, 2018 at 9:39 PM, Amandeep Gautam
>>  wrote:
>>
>> > gmake[3]: Entering directory
>> > '/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo'
>> > gmake[4]: Entering directory
>> > '/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo'
>> > /opt/csw/bin/gmkdir -p .; files=`echo
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go errors.gox io.gox
>> > math.gox os.gox reflect.gox strconv.gox sync.gox unicode/utf8.gox | sed
>> > -e
>> > 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/bash ./libtool --tag GO
>> > --mode=compile /export/home/amandeep/gccgo-obj/./gcc/gccgo
>> > -B/export/home/amandeep/gccgo-obj/./gcc/
>> > -B/usr/gnu/sparc-sun-solaris2.10/bin/
>> > -B/usr/gnu/sparc-sun-solaris2.10/lib/
>> > -isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem
>> > /usr/gnu/sparc-sun-solaris2.10/sys-include   -O2 -g -I . -c
>> > -fgo-pkgpath=`echo fmt.lo | sed -e 's/.lo$//' -e
>> > 's|golang_org|vendor/golang_org|'`  -o fmt.lo $files
>> > libtool: compile:  /export/home/amandeep/gccgo-obj/./gcc/gccgo
>> > -B/export/home/amandeep/gccgo-obj/./gcc/
>> > -B/usr/gnu/sparc-sun-solaris2.10/bin/
>> > -B/usr/gnu/sparc-sun-solaris2.10/lib/
>> > -isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem
>> > /usr/gnu/sparc-sun-solaris2.10/sys-include -O2 -g -I . -c
>> > -fgo-pkgpath=fmt
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go
>> > /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go  -fPIC -o
>> > .libs/fmt.o
>> > go1: internal compiler error: Segmentation Fault
>> > 0x6b9757 crash_signal
>> > /export/home/amandeep/gccgo-src/gcc/toplev.c:325
>> > Please submit a full bug report,
>> > with preprocessed source if appropriate.
>> > Please include the complete backtrace with any bug report.
>> > See  for instructions.
>> > gmake[4]: *** [Makefile:3324: fmt.lo] Error 1
>>
>>
>> Thanks.  Unfortunately, I don't know what could be causing this.
>> Everything looks fine, except that the compiler is crashing.  I'm not
>> seeing this on Solaris 11.  I think you will have to debug the
>> compiler.  To see more about what is happening, run the "compile:"
>> command by itself.  It should crash in the same way.  Then run it with
>> the -v option to see how the go1 program is being run.  Running the
>> go1 program with those arguments should crash.  That is what you need
>> to debug; presumably there is a NULL pointer dereference or something.
>>
>> 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.

-- 
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 

Re: [go-nuts] Does runtime.RaceDisable not work in non-std library ?

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 12:43 AM,   wrote:
> package main
>
> import "runtime"
>
> var a int
>
> func calc() {
> for i := 0; i < 10; i++ {
> go func() {
> for {
> runtime.RaceDisable()
> a++
> runtime.RaceEnable()
> }
> }()
>
> }
> }
>
> func main() {
> calc()
> }
>
> go run -race a.go

Thanks for the example.  As the docs for runtime.RaceDisable say, it
only applies to synchronization events, like mutex locks.  It doesn't
apply to memory accesses.

Ian


> 在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道：
>>
>> On Wed, Aug 22, 2018 at 3:25 AM,   wrote:
>> >
>> > When I copy the sync.Pool's source code in a repo, and using
>> > `//go:linkname`
>> > link those runtime functions manually.
>> > When I run `go test -race`, it reports `DATA RACE`.
>> > But the sync.Pool with the same test case does not report  `DATA RACE`.
>> >
>> > Does runtime.RaceDisable not work in non-std library ?
>>
>> It should work.  I think you'll have to show us your code.
>>
>> 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.

-- 
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: Ioctl Syscall with go and c

['Serguei Bezverkhi (sbezverk)' via golang-nuts]

I copied the whole thing to https://github.com/sbezverk/vfio

Running it without actual vfio/iommu might be problematic though.

Before this specific ioctl can be run 2 open calls must succeed. See func main.

Thank you for looking into this problem
Serguei

Sent from my iPhone

> On Aug 23, 2018, at 12:49 PM, Tamás Gulácsi  wrote:
> 
> Cany you give a complete example?
> 
>  https://play.golang.org/p/ZQSf-PwMtd9
> 
> says
> 
>  "device=18446744073709551615 errno=inappropriate ioctl for device"
> 
> -- 
> 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.

-- 
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: Local cache of dependencies

[wilk]

On 22-08-2018, Conor Hackett wrote:
> --=_Part_816_169128197.1534976743243
> Content-Type: multipart/alternative; 
>   boundary="=_Part_817_1168505210.1534976743243"
>
> --=_Part_817_1168505210.1534976743243
> Content-Type: text/plain; charset="UTF-8"
>
> Hey Guys,
>
> So, adding your "vendor" directory to SCM is a contentious topic at best.
>
> I personally would rather not vendor the dependencies but I do need to keep 
> the required code in my control and I consider third party repos out of my 
> control.
>
> Similar to how maven works (and others I am sure), is there some tooling 
> that will enable me to cache/store/save third party dependencies on my 
> local machine/server etc in order to

With go module when you go get a module it cache it in $GOPATH/pkg/mod
Maybe you just need to backup this directory.


-- 
William

-- 
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] Old fashioned Unix password crypt

[Lucio]

Am I missing something altogether too trivial, or is the modified DES 
encryption used in the old fashioned Unix /etc/passwd file just not 
implemented in Go at all, not even as a reasonably easily found user 
package?

Even though crypt(3) is no doubt dated, there may be value in some Go 
support for it, if only for archaeological purposes. In my case, I just 
have some old database whose internal access control uses crypt-compatible 
password encryption and it is too much bother at this point to change that 
for the rare occasions when it is needed.

If push comes to shove, I can code the algorithm myself in Go, but I'd 
rather spend my time on more rewarding tasks.

Lucio.

-- 
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: Stream directory content on the fly over HTTP using TAR archive

[Tamás Gulácsi]

2018. augusztus 23., csütörtök 18:39:01 UTC+2 időpontban Remi Ferrand a 
következőt írta:
>
> Hi everyone,
>
> This is my first message on this list so please apologize if this 
> discussion has already showed up in the past.
>
> What I'm trying to do is quite simple.
>
> I do have a directory with files I want to share to a friend from my 
> workstation.
> I would like him to:
> 1. point his web browser to an URL
> 2. be prompted for credentials (basic auth' is ok for my use-case)
> 3. get a prompt to download a TAR archive that contains my workstation's 
> directory and files structure.
>
> My question is about the third point.
>
> I do not want the TAR archive to be built on my workstation and then be 
> sent over HTTP once the archive contains all the files.
> Sometimes, my workstation does not have enough free disk space to store 
> the temporary TAR archive and then send it.
> I would like the TAR archive to be generated on the fly and *streamed 
> over HTTP* without any storage on my workstation disk.
>
> I've written a simple code here  
> that does what I want.
> Everything seems to work.
>
> The code is written in hurry and I've used
>
> exec.Command
>
> to spawn the subprocess "tar cf -".
> I would like to avoid using the external tar util.
>
> I'm just starting in GoLang but I know that there is a package 
> *archive/tar* that allows to create TAR archives.
>
> I can't figure out how *archive/tar* can be used in my use case (i.e not 
> generating the full TAR archive on my workstation and only then send it 
> once the archive is generated).
>
> If someone has already played with the *archive/tar* package and sees how 
> I can use it to achieve what I want, any help would be appreciated in order 
> to improve my GoLang skills
>
> Thanks !
>
> Cheers
>
> Rémi
>
>
Just use "tw := tar.NewWriter(w)" where w is your http.ResponseWriter (it 
satisfies the io.Writer interface) after you checked everything and have 
set w.Header.Set("Content-Type", "application/x-tar").
Then for each file (use filepath.Walk) tw.WriteHeader(th) (of 
tar.FileInfoHeader(fi) of fi := fh.Stat())) then io.Copy(tw, fh):

tw := tar.NewWriter(w)
filepath.Walk(".", func(path string, info os.FileInfo, err error) error {
  if err != nil {
return err
  }
  th, err := tar.FileInfoHeader(info)
  if err != nil {
return err
  }
  fh, err := os.Open(path)
  if err != nil {
return err
  }
  defer fh.Close()
  if err = tw.WriteHeader(th); err != nil {
return err
  }
  _, err = io.Copy(tw, fh)
  return err
})



-- 
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: Ioctl Syscall with go and c

[Tamás Gulácsi]

Cany you give a complete example?

  https://play.golang.org/p/ZQSf-PwMtd9

says

  "device=18446744073709551615 errno=inappropriate ioctl for device"

-- 
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] Data Access Object generator for Postgres using pgx

[umakanthdiwakar]

As part of our product enhancements, we develop microservices using GO and 
Postgres. pgx was the driver of choice, given its superior performance 
w.r.t pq. However, the procedural nature of coding in pgx or pq was a 
stumbling block for developer productivity. Hence we designed a typical 
single table access object, templatized it and used it as a basis to 
generate the entire database access code by reading Postgres meta-data. 
This has been hosted at https://github.com/umakanthdiwakar/pgx-daogen. Hope 
it proves useful. Feel free to post features you would like to see in the 
generator. Contributions are also welcome.

Uma

-- 
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: Local cache of dependencies

[James Warren]

Hey Conor,

Athens  is a new project in its early 
stages which deals with this problem space, its closely linked to the new 
modules features coming in go1.11. It's still in very early stages but 
looks very interesting - definitely one to keep an eye on.

Cheers,
James

On Wednesday, August 22, 2018 at 11:34:14 PM UTC+1, Conor Hackett wrote:
>
> Hey Guys,
>
> So, adding your "vendor" directory to SCM is a contentious topic at best.
>
> I personally would rather not vendor the dependencies but I do need to 
> keep the required code in my control and I consider third party repos out 
> of my control.
>
> Similar to how maven works (and others I am sure), is there some tooling 
> that will enable me to cache/store/save third party dependencies on my 
> local machine/server etc in order to
>
> a) reduce operational risk of a repo/code disappearing
> b) potentially speeding up build time
>
> This post is more of a sanity check -- I have been searching for such 
> tooling for a while now and am about to spin up a new project do something 
> along these lines.
>
> Thanks 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.

[go-nuts] Local cache of dependencies

[Antonio Troina]

Hi Conor  

Have you looked at Project Athens already?
Here’s the link, you can easily find the GitHub repo and see what it’s all 
about: https://docs.gomods.io/

I know you can run it locally or on a server in the cloud, so it sounds 
something similar to what you have just described.

-- 
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: Ioctl Syscall with go and c

['Serguei Bezverkhi (sbezverk)' via golang-nuts]

Hello Jake,

Apologies about formatting, here is correctly formatted code:

// GetGroupFD gets File descriptor for a specified by PCI address device
func GetGroupFD(group int, pciDevice string) (int, error) {
buffer := make([]byte, len(pciDevice)+1)
for i, c := range pciDevice {
buffer[i] = uint8(c)
}
ioctlID := VFIO_GROUP_GET_DEVICE_FD()
fmt.Printf("VFIO_GROUP_GET_DEVICE_FD() returned: %04x\n", 
ioctlID)
buffer[len(pciDevice)] = 0x0
fmt.Printf("pciDevice: %s\n", string(buffer))
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer([0])),
)
if errno != 0 {
return 0, fmt.Errorf("fail to get file 
descriptor for %d with errno: %+v", group, errno)
}
return int(device), nil
}

I have also addressed your suggestions without any success. It is latest Centos 
7.5.

Thank you
Serguei

From:  on behalf of "jake6...@gmail.com" 

Date: Thursday, August 23, 2018 at 12:27 PM
To: golang-nuts 
Subject: Re: [go-nuts] Re: Ioctl Syscall with go and c

First off, I don't know how you are posting your code samples, but they are 
unreadable in my Firefox and Chrome on windows.

Second, I would point out that the system you use for converting a "string" to 
the buffer will fail if there are any non-ascii characters.

Third, OT, but I wonder why pciDevice is a string pointer, instead of a string?

Personally, I don't see anything decisively incorrect, but there is a lot of 
context that is missing. If you wanted to indicate your OS, and provide a 
complete working sample, I'm sure I, or someone else could help more.

One thing that jumps out at me is the use of  
uintptr(unsafe.Pointer()), in your initial example. It is hidden by the 
function  VFIO_GROUP_GET_DEVICE_FD(), which is not provided, in your larger 
example. Are you sure you want the pointer to that value, and not the actual 
value? Maybe uintptr(ioctlId)) instead. Seems more standard for IOCTL to me.

And, of course the changes you made to create an appropriate string buffer are 
necessary.


On Thursday, August 23, 2018 at 11:47:18 AM UTC-4, sbez...@cisco.com wrote:
Hi Max,

Thanks for the suggestion, unfortunately it did not help, see below:

func GetGroupFD(group int, pciDevice *string) (int, error) {
fmt.Printf("VFIO_GROUP_GET_DEVICE_FD() returned: %04x\n", 
VFIO_GROUP_GET_DEVICE_FD())
buffer := make([]byte, len(*pciDevice)+1)
for i, c := range *pciDevice {
buffer[i] = uint8(c)
}
buffer[len(*pciDevice)] = 0x0
fmt.Printf("pciDevice: %s\n", string(buffer))
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(VFIO_GROUP_GET_DEVICE_FD()),
uintptr(unsafe.Pointer([0])),
)
if errno != 0 {
return 0, fmt.Errorf("fail to get file descriptor for %d with errno: 
%+v", group, errno)
}
return int(device), nil
}

Any other suggestions?
Thank you
Serguei

From: > on behalf of Max 
>
Date: Thursday, August 23, 2018 at 10:46 AM
To: golang-nuts >
Subject: Re: [go-nuts] Re: Ioctl Syscall with go and c

Hi Serguei,

a Go string or *string do not correspond to a C char *
You must pass the address of the first byte of a sufficiently large buffer:

func GetGroupFD(group int, pciDevice *string) (int, error) {
  const N = 256
  var buffer [N]byte
  device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
[0],
)
   /* if ioctl() is successful, find '\0' in buffer[] and copy the relevant 
portion in *pciDevice */
}

On Thursday, August 23, 2018 at 2:55:29 PM UTC+2, sbez...@cisco.com wrote:
I changed code a little bit to be able to examine variables:

 func GetGroupFD(group int, pciDevice *string) (int, error) {
ioctlId := 0x3b6a
var buffer uintptr
buffer = uintptr(unsafe.Pointer(pciDevice))

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving 

[go-nuts] Re: Local cache of dependencies

[David Skinner]

Modules rarely disappear but when they do it can have a profound impact on 
a project. I am really paranoid so I sometimes fork a project to a private 
repo just to have it on hand just in case. I have used git submodules from 
the git command line as a solution. I still do, but I would not recommend 
it to anyone. I just do it because i know how and i am too lazy to figure 
out a better way.

On Wednesday, August 22, 2018 at 5:34:14 PM UTC-5, Conor Hackett wrote:
>
> Hey Guys,
>
> So, adding your "vendor" directory to SCM is a contentious topic at best.
>
> I personally would rather not vendor the dependencies but I do need to 
> keep the required code in my control and I consider third party repos out 
> of my control.
>
> Similar to how maven works (and others I am sure), is there some tooling 
> that will enable me to cache/store/save third party dependencies on my 
> local machine/server etc in order to
>
> a) reduce operational risk of a repo/code disappearing
> b) potentially speeding up build time
>
> This post is more of a sanity check -- I have been searching for such 
> tooling for a while now and am about to spin up a new project do something 
> along these lines.
>
> Thanks 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.

Re: [go-nuts] Re: Ioctl Syscall with go and c

[jake6502]

First off, I don't know how you are posting your code samples, but they are 
unreadable in my Firefox and Chrome on windows. 

Second, I would point out that the system you use for converting a "string" 
to the buffer will fail if there are any non-ascii characters. 

Third, OT, but I wonder why pciDevice is a string pointer, instead of a 
string?

Personally, I don't see anything *decisively *incorrect, but there is a lot 
of context that is missing. If you wanted to indicate your OS, and provide 
a complete working sample, I'm sure I, or someone else could help more. 

One thing that jumps out at me is the use of  
*uintptr(unsafe.Pointer())*, in your initial example. It is hidden 
by the function  *VFIO_GROUP_GET_DEVICE_FD()*, which is not provided, in 
your larger example. Are you sure you want the pointer to that value, and 
not the actual value? Maybe *uintptr(ioctlId))* instead. Seems more 
standard for IOCTL to me. 

And, of course the changes you made to create an appropriate string buffer 
are necessary.


On Thursday, August 23, 2018 at 11:47:18 AM UTC-4, sbez...@cisco.com wrote:
>
> Hi Max,
>
>  
>
> Thanks for the suggestion, unfortunately it did not help, see below:
>
>  
>
> func GetGroupFD(group int, pciDevice *string) (int, error) {
>
> fmt.Printf("VFIO_GROUP_GET_DEVICE_FD() returned: %04x\n", 
> VFIO_GROUP_GET_DEVICE_FD())
>
> buffer := make([]byte, len(*pciDevice)+1)
>
> for i, c := range *pciDevice {
>
> buffer[i] = uint8(c)
>
> }
>
> buffer[len(*pciDevice)] = 0x0
>
> fmt.Printf("pciDevice: %s\n", string(buffer))
>
> device, _, errno := syscall.Syscall(
>
> syscall.SYS_IOCTL,
>
> uintptr(group),
>
> uintptr(VFIO_GROUP_GET_DEVICE_FD()),
>
> uintptr(unsafe.Pointer([0])),
>
> )
>
> if errno != 0 {
>
> return 0, fmt.Errorf("fail to get file descriptor for %d with 
> errno: %+v", group, errno)
>
> }
>
> return int(device), nil
>
> }
>
>  
>
> Any other suggestions?
>
> Thank you
>
> Serguei
>
>  
>
> *From: *> on behalf of Max <
> massimilia...@gmail.com >
> *Date: *Thursday, August 23, 2018 at 10:46 AM
> *To: *golang-nuts >
> *Subject: *Re: [go-nuts] Re: Ioctl Syscall with go and c
>
>  
>
> Hi Serguei,
>
>  
>
> a Go string or *string do not correspond to a C char *
>
> You must pass the address of the first byte of a sufficiently large buffer:
>
>  
>
> func GetGroupFD(group int, pciDevice *string) (int, error) {
>
>   const N = 256
>
>   var buffer [N]byte
>
>   device, _, errno := syscall.Syscall(
> syscall.SYS_IOCTL,
> uintptr(group),
> uintptr(unsafe.Pointer()),
> [0],
> )
>
>/* if ioctl() is successful, find '\0' in buffer[] and copy the 
> relevant portion in *pciDevice */
>
> }
>
>
> On Thursday, August 23, 2018 at 2:55:29 PM UTC+2, sbez...@cisco.com 
> wrote: 
>
> I changed code a little bit to be able to examine variables:
>
>  
>
>  func GetGroupFD(group int, pciDevice *string) (int, error) {
>
> ioctlId := 0x3b6a 
>
> var buffer uintptr
>
> buffer = uintptr(unsafe.Pointer(pciDevice))
>
>  
>
> -- 
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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] kitty, a lightweight microservice framework extending go-kit

[Jean-François Bustarret]

We just open-sourced kitty, a microservice framework extending go-kit - 
https://github.com/objenious/kitty

Kitty's goal is to ease development of microservices deployed on Kubernetes 
(or any similar orchestration platform).

Kitty has an opinion on:

- transports: only HTTP is supported (additional transports might be added),
- errors: an error may be Retryable (e.g. 5XX status codes) or not (e.g. 
4XX status codes),
- status codes: unless specified, request decoding errors will generate 400 
HTTP status codes.

Kitty has no opinion on:

- logging: no logs are generated by default, you can plug your logger and 
it will get additional context,
- packages: kitty only imports go-kit and the standard library,
- routers: you can use any router (a Gorilla Mux implementation is 
available in a sub-package, other routers can easily be plugged),
- encoding: use whatever encoding you want (JSON, messagepack, protobuf, 
...),
- monitoring, metrics and tracing: use Istio, a sidecar process or a 
middleware.

Kitty includes 2 sub-packages:

- backoff: Retryable-aware exponential backoff (only Retryable errors 
trigger retries),
- circuitbreaker: Retryable-aware circuit breaker (only Retryable errors 
trigger the circuit breaker).

This is an alpha release - the package should be fairly stable, but non 
backwards-compatible changes might happen.

License: MIT

-- 
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] Local cache of dependencies

[Jim Ancona]

I believe Athens (https://github.com/gomods/athens) is meant to address
this use case in the Go modules world.

Jim

On Wed, Aug 22, 2018 at 7:51 PM Conor Hackett  wrote:

> Thanks Sam,
>
> I'll have a look out of curiosity but I am very reluctant to
> introduce/recommend Git submodules to any of my projects. You might say
> it's because I don't understand how they work that I fear them but they
> have caused much heartache in the past and a recent team I was on had
> nothing but trouble as a whole. Surely there is a better way?
>
> I will look at it for inspiration though and I appreciate your reply :)
>
> Conor
>
> On Thursday, 23 August 2018 00:35:49 UTC+1, Sam Vilain wrote:
>>
>> Check out vendetta - it uses git submodules, so you keep a cache of the
>> 3rd party repo in git but not the actual content. You get small repos and
>> reproducible builds.
>>
>> Sam
>>
>> On Aug 22, 2018 3:25 PM, Conor Hackett  wrote:
>>
>> Hey Guys,
>>
>> So, adding your "vendor" directory to SCM is a contentious topic at best.
>>
>> I personally would rather not vendor the dependencies but I do need to
>> keep the required code in my control and I consider third party repos out
>> of my control.
>>
>> Similar to how maven works (and others I am sure), is there some tooling
>> that will enable me to cache/store/save third party dependencies on my
>> local machine/server etc in order to
>>
>> a) reduce operational risk of a repo/code disappearing
>> b) potentially speeding up build time
>>
>> This post is more of a sanity check -- I have been searching for such
>> tooling for a while now and am about to spin up a new project do something
>> along these lines.
>>
>> Thanks 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...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
> 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.
>

-- 
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: Ioctl Syscall with go and c

['Serguei Bezverkhi (sbezverk)' via golang-nuts]

I changed code a little bit to be able to examine variables:

 func GetGroupFD(group int, pciDevice *string) (int, error) {
ioctlId := 0x3b6a
var buffer uintptr
buffer = uintptr(unsafe.Pointer(pciDevice))
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
buffer,
)

(gdb) p 
$8 = (uintptr *) 0xc4200c7b88
(gdb) x/g 0xc4200c7b88
0xc4200c7b88:   0x00c4200c7d08
(gdb) x/g 0x00c4200c7d08
0xc4200c7d08:   0x00c4200122d0
(gdb) x/g 0x00c4200122d0
0xc4200122d0:   0x3a31383a30303030

0x30303030 is start of expected string “:81:11.1”,  first 4 bytes are not 
part of it. Anybody knows where those 4 bytes could have come from? And how to 
get rid of them?
Thank you
Serguei

From:  on behalf of Tamás Gulácsi 

Date: Thursday, August 23, 2018 at 8:13 AM
To: golang-nuts 
Subject: [go-nuts] Re: Ioctl Syscall with go and c

Is it \0-terminated?

2018. augusztus 23., csütörtök 13:02:13 UTC+2 időpontban sbez...@cisco.com a 
következőt írta:
Hello,

I am converting some C code to Go and hit an issue with one particular Syscall:

In C:

device = ioctl(group, 0x3b6a, path);
where path is char[N]

In Go:
ioctlId := 0x3b6a
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer(pciDevice)),
)
Where pciDevice is *string with exactly the same value as path in C.

When I run Go bits on the same h/w, same OS, same everything, it fails with 
"errno 22 (invalid argument)". It seems that the issue is how string gets 
passed to Syscall, but I could not find any examples how to do it correctly.
Appreciate some advice here.

Thank you
Serguei
--
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.

-- 
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: Ioctl Syscall with go and c

[Tamás Gulácsi]

Is it \0-terminated?

2018. augusztus 23., csütörtök 13:02:13 UTC+2 időpontban sbez...@cisco.com 
a következőt írta:
>
> Hello, 
>
> I am converting some C code to Go and hit an issue with one particular 
> Syscall: 
>
> In C: 
>
> device = ioctl(group, 0x3b6a, path); 
> where path is char[N] 
>
> In Go: 
> ioctlId := 0x3b6a 
> device, _, errno := syscall.Syscall( 
> syscall.SYS_IOCTL, 
> uintptr(group), 
> uintptr(unsafe.Pointer()), 
> uintptr(unsafe.Pointer(pciDevice)), 
> ) 
> Where pciDevice is *string with exactly the same value as path in C. 
>
> When I run Go bits on the same h/w, same OS, same everything, it fails 
> with "errno 22 (invalid argument)". It seems that the issue is how string 
> gets passed to Syscall, but I could not find any examples how to do it 
> correctly. 
> Appreciate some advice here. 
>
> Thank you 
> Serguei 
>
>

-- 
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] Ioctl Syscall with go and c

['Serguei Bezverkhi (sbezverk)' via golang-nuts]

Hello,

I am converting some C code to Go and hit an issue with one particular Syscall:

In C:

device = ioctl(group, 0x3b6a, path);
where path is char[N]

In Go:
ioctlId := 0x3b6a
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer(pciDevice)),
)
Where pciDevice is *string with exactly the same value as path in C.

When I run Go bits on the same h/w, same OS, same everything, it fails with 
"errno 22 (invalid argument)". It seems that the issue is how string gets 
passed to Syscall, but I could not find any examples how to do it correctly.
Appreciate some advice here.

Thank you
Serguei

-- 
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: function's argument default value

[Louki Sumirniy]

Actually, going a little further, I would like to see a change in Golang 
where parameter and return tuples can be set the same way as structs - so 
if you use named labels ( label="value ) it assumes null for any others 
specified. Then you can add one more feature, which is also related and 
gives you what you want - that you can specify defaults inside the 
parameter block in a function header for values when you want something 
other than null values when unspecified using labels.

On Thursday, 23 August 2018 09:44:17 UTC+2, Masoud Ghorbani wrote:
>
> Your opinion is like to say all of the python application should rethink 
> and re-write their structure because they used default values. I think 
> having default values for parameters is just a feature which will make 
> codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default value for everything in Go. Null. 0, "" and nil. As 
>> someone else said, if you want a parameter to be optional you probably need 
>> ...interface{} and then infer no parameter as 'use the default'. Going a 
>> little further, you can build default values into a constructor function 
>> for an interfaced type. 
>>
>> Oh, probably the neatest solution is to make a struct that lets you input 
>> the parameters either in-order or with labels instead. Then you can use 
>> {} to mean 'use defaults' or whichever parameters are not 
>> specified get automatically set to default, either unlabeled and ordered 
>> such that the values that will be asserted to defaults are not the first 
>> ones in a struct literal used to feed parameters in. Or make the names nice 
>> and concise so they aren't troublesome to add (and if your code is going to 
>> often use defaults, probably you won't even have to specify many values 
>> very often anyway).
>>
>> Assertions and labeled parameters are nice features but they don't really 
>> save you that much time. I would suggest that it's more likely you need to 
>> rethink the structure of your application and make slightly different named 
>> parameters for those calls that will use defaults for specific parameters.
>>
>> Another thing is that you can make null variables imply the use of 
>> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
>> and the code will test and fill them automatically. Or if null isn't handy, 
>> you can define sentinel values for a type that indicate 'use defaults'.
>>
>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>>
>>> Why there isn't function argument default value in Golang explicitly 
>>> like Typescript and Python?
>>>
>>

-- 
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: function's argument default value

[Louki Sumirniy]

Actually, my real opinion is that I like these default argument values, I 
also like concise asserts at the head of functions that automatically 
sanitise data. But they cost quite a lot which is likely why Go doesn't 
have them. Default arguments are the least useful of the two, asserts have 
a much greater effect on correctness which is why many functional languages 
let you set such conditions in a function.

On Thursday, 23 August 2018 09:44:17 UTC+2, Masoud Ghorbani wrote:
>
> Your opinion is like to say all of the python application should rethink 
> and re-write their structure because they used default values. I think 
> having default values for parameters is just a feature which will make 
> codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default value for everything in Go. Null. 0, "" and nil. As 
>> someone else said, if you want a parameter to be optional you probably need 
>> ...interface{} and then infer no parameter as 'use the default'. Going a 
>> little further, you can build default values into a constructor function 
>> for an interfaced type. 
>>
>> Oh, probably the neatest solution is to make a struct that lets you input 
>> the parameters either in-order or with labels instead. Then you can use 
>> {} to mean 'use defaults' or whichever parameters are not 
>> specified get automatically set to default, either unlabeled and ordered 
>> such that the values that will be asserted to defaults are not the first 
>> ones in a struct literal used to feed parameters in. Or make the names nice 
>> and concise so they aren't troublesome to add (and if your code is going to 
>> often use defaults, probably you won't even have to specify many values 
>> very often anyway).
>>
>> Assertions and labeled parameters are nice features but they don't really 
>> save you that much time. I would suggest that it's more likely you need to 
>> rethink the structure of your application and make slightly different named 
>> parameters for those calls that will use defaults for specific parameters.
>>
>> Another thing is that you can make null variables imply the use of 
>> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
>> and the code will test and fill them automatically. Or if null isn't handy, 
>> you can define sentinel values for a type that indicate 'use defaults'.
>>
>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>>
>>> Why there isn't function argument default value in Golang explicitly 
>>> like Typescript and Python?
>>>
>>

-- 
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] internal compilation error while compiling gccgo from source solaris 10

[Amandeep Gautam]

Hi Ian,
  I ran the following after changing directory to 
/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo/:

files=`echo /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
/export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go errors.gox io.gox 
math.gox os.gox reflect.gox strconv.gox sync.gox unicode/utf8.gox | sed -e 
's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/bash ./libtool --tag GO 
--mode=compile --verbose /export/home/amandeep/gccgo-obj/./gcc/gccgo 
-B/export/home/amandeep/gccgo-obj/./gcc/ 
-B/usr/gnu/sparc-sun-solaris2.10/bin/ -B/usr/gnu/sparc-sun-solaris2.10/lib/ 
-isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem 
/usr/gnu/sparc-sun-solaris2.10/sys-include   -O2 -g -I . -c 
-fgo-pkgpath=`echo fmt.lo | sed -e 's/.lo$//' -e 
's|golang_org|vendor/golang_org|'`  -o fmt.lo $files

I still get the same compilation error:

go1: internal compiler error: Segmentation Fault
0x6b9757 crash_signal
/export/home/amandeep/gccgo-src/gcc/toplev.c:325
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

and did not get any more output using the verbose option. What should have 
been done differently?

On Monday, August 20, 2018 at 6:41:54 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Aug 19, 2018 at 9:39 PM, Amandeep Gautam 
> > wrote: 
>
> > gmake[3]: Entering directory 
> > '/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo' 
> > gmake[4]: Entering directory 
> > '/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo' 
> > /opt/csw/bin/gmkdir -p .; files=`echo 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go errors.gox io.gox 
> > math.gox os.gox reflect.gox strconv.gox sync.gox unicode/utf8.gox | sed 
> -e 
> > 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/bash ./libtool --tag GO 
> > --mode=compile /export/home/amandeep/gccgo-obj/./gcc/gccgo 
> > -B/export/home/amandeep/gccgo-obj/./gcc/ 
> > -B/usr/gnu/sparc-sun-solaris2.10/bin/ 
> -B/usr/gnu/sparc-sun-solaris2.10/lib/ 
> > -isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem 
> > /usr/gnu/sparc-sun-solaris2.10/sys-include   -O2 -g -I . -c 
> > -fgo-pkgpath=`echo fmt.lo | sed -e 's/.lo$//' -e 
> > 's|golang_org|vendor/golang_org|'`  -o fmt.lo $files 
> > libtool: compile:  /export/home/amandeep/gccgo-obj/./gcc/gccgo 
> > -B/export/home/amandeep/gccgo-obj/./gcc/ 
> > -B/usr/gnu/sparc-sun-solaris2.10/bin/ 
> -B/usr/gnu/sparc-sun-solaris2.10/lib/ 
> > -isystem /usr/gnu/sparc-sun-solaris2.10/include -isystem 
> > /usr/gnu/sparc-sun-solaris2.10/sys-include -O2 -g -I . -c 
> -fgo-pkgpath=fmt 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/doc.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/format.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/print.go 
> > /export/home/amandeep/gccgo-src/libgo/go/fmt/scan.go  -fPIC -o 
> .libs/fmt.o 
> > go1: internal compiler error: Segmentation Fault 
> > 0x6b9757 crash_signal 
> > /export/home/amandeep/gccgo-src/gcc/toplev.c:325 
> > Please submit a full bug report, 
> > with preprocessed source if appropriate. 
> > Please include the complete backtrace with any bug report. 
> > See  for instructions. 
> > gmake[4]: *** [Makefile:3324: fmt.lo] Error 1 
>
>
> Thanks.  Unfortunately, I don't know what could be causing this. 
> Everything looks fine, except that the compiler is crashing.  I'm not 
> seeing this on Solaris 11.  I think you will have to debug the 
> compiler.  To see more about what is happening, run the "compile:" 
> command by itself.  It should crash in the same way.  Then run it with 
> the -v option to see how the go1 program is being run.  Running the 
> go1 program with those arguments should crash.  That is what you need 
> to debug; presumably there is a NULL pointer dereference or something. 
>
> 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] Re: function's argument default value

[Masoud Ghorbani]

Your opinion is like to say all of the python application should rethink 
and re-write their structure because they used default values. I think 
having default values for parameters is just a feature which will make 
codebase readable and smaller than before.

On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>
> There is a default value for everything in Go. Null. 0, "" and nil. As 
> someone else said, if you want a parameter to be optional you probably need 
> ...interface{} and then infer no parameter as 'use the default'. Going a 
> little further, you can build default values into a constructor function 
> for an interfaced type. 
>
> Oh, probably the neatest solution is to make a struct that lets you input 
> the parameters either in-order or with labels instead. Then you can use 
> {} to mean 'use defaults' or whichever parameters are not 
> specified get automatically set to default, either unlabeled and ordered 
> such that the values that will be asserted to defaults are not the first 
> ones in a struct literal used to feed parameters in. Or make the names nice 
> and concise so they aren't troublesome to add (and if your code is going to 
> often use defaults, probably you won't even have to specify many values 
> very often anyway).
>
> Assertions and labeled parameters are nice features but they don't really 
> save you that much time. I would suggest that it's more likely you need to 
> rethink the structure of your application and make slightly different named 
> parameters for those calls that will use defaults for specific parameters.
>
> Another thing is that you can make null variables imply the use of 
> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
> and the code will test and fill them automatically. Or if null isn't handy, 
> you can define sentinel values for a type that indicate 'use defaults'.
>
> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>
>> Why there isn't function argument default value in Golang explicitly like 
>> Typescript and Python?
>>
>

-- 
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] Does runtime.RaceDisable not work in non-std library ?

[buaa . cch]

package main
import "runtime"
var a int
func calc() {
for i := 0; i < 10; i++ {
go func() {
for {
runtime.RaceDisable()
a++
runtime.RaceEnable()
}
}()

}
}
func main() {
calc()
}

go run -race a.go


在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道：
>
> On Wed, Aug 22, 2018 at 3:25 AM,  > wrote: 
> > 
> > When I copy the sync.Pool's source code in a repo, and using 
> `//go:linkname` 
> > link those runtime functions manually. 
> > When I run `go test -race`, it reports `DATA RACE`. 
> > But the sync.Pool with the same test case does not report  `DATA RACE`. 
> > 
> > Does runtime.RaceDisable not work in non-std library ? 
>
> It should work.  I think you'll have to show us your code. 
>
> 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] Re: What is the behavior of an HTTP persistent connection in Go?

[golangnutter]

Thanks this really is a great explanation.
So new connections will be created if there are no idle connection 
available.

The following article suggests setting the Transport.MaxIdleConnsPerHost to 
the same value as Transport.MaxIdleConns to allow any host to use all 
connections if necessary.
http://tleyden.github.io/blog/2016/11/21/tuning-the-go-http-client-library-for-load-testing/



On Tuesday, August 21, 2018 at 5:18:05 AM UTC-7, Kevin Conway wrote:
>
> > Are requests sent serially ...  so that other concurrent requests to 
> the same host are blocked
>
> When sending requests using HTTP/1, each connection will handle only one 
> request at a time except when using pipelining. When sending requests using 
> HTTP/2, each connection may manage any number of requests. The 
> http.Transport does a lot to abstract this behavior so it looks the same to 
> a developer. As far as blocking, the http.Transport will never "block" 
> while waiting for a connection to return to the pool. Unlike the connection 
> pool in Java, for example, the http.Transport connection pool does not 
> limit the number of open connections. If there are no idle connections in 
> the pool then the http.Transport will make another one on-demand and use 
> that for the request.
>
> > forget to Close() a Response.Body
>
> This can definitely become a problem and is a common mistake made by new 
> go devs. A good answer to this question with more detail is here: 
> https://stackoverflow.com/a/33238755
>
> > Transport.IdleConnTimeout will close any connections automatically for 
> me right?
>
> When configuring your connection pool, it is important to keep in mind 
> that all of the logic for removing an old connection from the pool and 
> closing it is based on *idle* time. For example, IdleConnTimeout of 30s 
> will cause connections that have gone unused for 30s to close. There is, as 
> of go1.10, still no way to define a maximum lifetime of a connection that 
> is in-use.
>
> > pool of clients ... to allow for parallel requests
>
> Each client already manages any number of connections for HTTP/1 calls and 
> handles multiple, concurrent HTTP/2 calls on a single connection per host. 
> You do not need to do anything else to get the behavior you want.
>
> >  I could increase the Transport.MaxIdleConns or 
> Transport.MaxIdleConnsPerHost
>
> Like the connection timeout, it is important to recognize that the 
> connection limits are based on *idle* connections. There is no setting, as 
> of go1.10, that allows you to set a maximum number of active connections 
> for HTTP/1. The HTTP/2 support in http.Transport already has a built-in 
> limit because it enforces use of a single connection for all concurrent 
> requests so you don't have to do anything special for HTTP/2. However, 
> there is no limit to the number of connections http.Transport will make for 
> a HTTP/1 calls.
>
>
>
> On Tue, Aug 21, 2018 at 12:32 AM > 
> wrote:
>
>> Also do you have any recommendations for deriving appropriate values for 
>> Transport.MaxIdleConns 
>> or Transport.MaxIdleConnsPerHost?
>>
>>
>> On Monday, August 20, 2018 at 12:59:07 AM UTC-7, golang...@gmail.com 
>> wrote:
>>>
>>> The http.Transport caches connections for future re-use
>>> https://golang.org/pkg/net/http/#Transport
>>>
>>> Are requests sent serially by which I mean only one request and response 
>>> can be handled by this persistent connection at a time, so that other 
>>> concurrent requests to the same host are blocked until a response is 
>>> received and closed?
>>>
>>> If I forget to Close() a Response.Body, does that leave the connection 
>>> open so that it can't be shared? Do other concurrent requests open a new 
>>> connection during that time? 
>>>
>>> And if I do forget, by default the Transport.IdleConnTimeout will close 
>>> any connections automatically for me right?
>>>
>>> I understand that persistent connections save on protocol overhead, but 
>>> if it can only handle one request at a time wouldn't in some cases it be 
>>> better to have a pool of clients each with their own persistent connection 
>>> to the same host to allow for parallel requests?
>>>
>>> Alternatively, I could increase the Transport.MaxIdleConns or 
>>> Transport.MaxIdleConnsPerHost right? Which would trade throughput for 
>>> server resources to maintain those connections.
>>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.