Re: [go-nuts] Re: Golang 1.9 failing with excelize (simple case works under 1.8.3)

[Sam Whited]

On Mon, Aug 28, 2017, at 22:59, silviucap...@gmail.com wrote:
> Interesting... For this portion of code:
> 
> https://github.com/360EntSecGroup-Skylar/excelize/blob/master/rows.go#L76-L85
> 
> The xml decoder returns row and col token types for  1.8.3 but rushes
> into 
> an EOF for 1.9

In Go 1.8 the patch in 02240408a1 was ported to restore error masking
behavior from 1.7 (which is why you get output in 1.8). I don't see that
patch in 1.9.

See also https://golang.org/issue/19333

—Sam

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

[go-nuts] Any historical discussion around support "go generate -parallel n"?

[Guanhua Jiang]

I'm just wondering if there has been discussions about having "go generate" 
tool support a "-parallel n" flag such that it would run go generate on 
each file concurrently throughout a package(s). The motivation is this: a 
typical build process that involves file generation may need to support the 
//go:generate directive in any arbitrary file in the repo. When the number 
of files gets larger and larger, it essentially iterates over each file to 
trigger the commands, as generate.go:155 

 suggests. 
I'm wondering if there's anything stopping us from supporting going through 
all of these files concurrently; and if not, would it be a nice feature to 
support for "go generate"?

-- 
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: math/big

[Alex Dvoretskiy]

Thanks, Michael!

On Monday, August 28, 2017 at 3:33:52 PM UTC-7, Alex Dvoretskiy wrote:
>
> Does anyone uses package "math/big"? And what purpose? 
>
> It looks like hard package to work with. At least at the beggining.
> Even simple line of code takes some efforts to convert to big.Float:
>
> y := float64(py) / float64(heightP) * (ymax - ymin) + ymin
>

-- 
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] can list.List.Push* or Get return nil?

[snmed]

Hi 

As far as the docs are right:

For Back: Back returns the last element of list l or nil.

For PushBack:  PushBack inserts a new element e with value v at the back of 
list l and returns e.

So if you push nil, you get nil otherwise you get always your pushed element.

Cheers

-- 
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: Golang 1.9 failing with excelize (simple case works under 1.8.3)

[silviucapota]

Interesting... For this portion of code:

https://github.com/360EntSecGroup-Skylar/excelize/blob/master/rows.go#L76-L85

The xml decoder returns row and col token types for  1.8.3 but rushes into 
an EOF for 1.9

If the document gets re-saved with LibreOffice for example, it works, so it 
may be invalid, but still... maybe some changes in the Xml parsed inner 
workings ?

On Monday, 28 August 2017 14:55:25 UTC-4, G Shields wrote:
>
> here is the xlsx data file
> FYI this fails on both mac and ubuntu with 1.9
>
>
> On Friday, August 25, 2017 at 3:10:40 PM UTC-7, G Shields wrote:
>>
>> Under 1.8.3 the program run:
>> package main
>>
>> import (
>> "fmt"
>> "os"
>> "strconv"
>>
>> "github.com/Luxurioust/excelize"
>> )
>>
>> func checkErr(err error) {
>> if err != nil {
>> fmt.Println(err)
>> os.Exit(1)
>> }
>>
>> }
>> func main() {
>>
>> xlsx, err := excelize.OpenFile("test.xlsx")
>> checkErr(err)
>> mysheet := xlsx.GetSheetName(1)
>> index := xlsx.GetSheetIndex(mysheet)
>> rows := xlsx.GetRows("Sheet" + strconv.Itoa(index))
>> for _, row := range rows {
>> for _, colCell := range row {
>> fmt.Print(colCell, "\t")
>> }
>> fmt.Println()
>> }
>> }
>>
>> With results of:
>> naAppleOrangePear
>> Small233
>> Normal524
>> Large678
>> Success: process exited with code 0.
>>
>> Under 1.9 I get no data and no errors:
>> Success: process exited with code 0.
>>
>

-- 
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] Problems with regexp

[Hugh S. Myers]

(.*) is greedy… try ([^\[]+) this should consume all till it runs into the
open bracket, your next group…

On Mon, Aug 28, 2017 at 7:17 PM, Paulo Coutinho 
wrote:

> Hi,
>
> Well, I'm having a problem with regular expressions, so all online regexp
> testers work, including those that run on go.
>
> But locally and on the playground does not work and I do not understand
> what is wrong.
>
> Can anyone help me with this? Follow the code link:
>
> Https://play.golang.org/p/yVpU--tuSr
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Problems with regexp

[Paulo Coutinho]

Hi,

Well, I'm having a problem with regular expressions, so all online regexp 
testers work, including those that run on go.

But locally and on the playground does not work and I do not understand 
what is wrong.

Can anyone help me with this? Follow the code link:

Https://play.golang.org/p/yVpU--tuSr

Thanks.

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

Re: [go-nuts] Re: [ANN] Gomail v2: sending emails faster

[yhj772709]

Thanks very much.

But, what I mean of setting timeout is giving up this sending, and try to 
send another email


在 2017年8月29日星期二 UTC+8上午9:59:24，Antonio Sun写道：
>
>
>
> On Sun, Aug 27, 2017 at 10:31 PM, > wrote:
>
>>
>> Without setting timeout on sending, it spent 5 minutes to send an email. 
>> Badly, it will hang up, then cause bug on production.
>>
>
> That means the mail server is busy. Setting shorter timeout will 
> stress mail server even more and make things worse for everyone. 
>
> The proper way is wait, and retry (dialing), with each retry waiting twice 
> as long as before. So even if the remote mail server is down for a few 
> hours, you email can still go through eventually. 
>
>
>

-- 
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: [ANN] Gomail v2: sending emails faster

[Antonio Sun]

On Sun, Aug 27, 2017 at 10:31 PM,  wrote:

>
> Without setting timeout on sending, it spent 5 minutes to send an email.
> Badly, it will hang up, then cause bug on production.
>

That means the mail server is busy. Setting shorter timeout will
stress mail server even more and make things worse for everyone.

The proper way is wait, and retry (dialing), with each retry waiting twice
as long as before. So even if the remote mail server is down for a few
hours, you email can still go through eventually.

-- 
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] math/big

[Michael Jones]

oops! that's actually a**1024 ...was rushing and typed the Printf legend
too quickly.

On Mon, Aug 28, 2017 at 5:14 PM, Michael Jones 
wrote:

> I use it frequently / constantly / 24/7 :-)
>
> it's purpose is to enable integer, rational, and real arithmetic at chosen
> precisions greater than the hardware's native CPU arithmetic.
>
> One property of such thousand or million digit numbers is that they cannot
> be moved around the way '5' and '3' are in "j:=5+3"; instead, they are
> referred to by address. Since the data may be very large, where to put
> temporary values is an important concern for performance and for memory
> use. Enabling these means an api that is much more detailed than typical
> higher-level language math.
>
> I regret that it is not simpler and more natural (thus various go
> proposals) but even as it it is it's great!
>
> https://play.golang.org/p/-FbM22rv4u
>
> On Mon, Aug 28, 2017 at 3:33 PM, Alex Dvoretskiy 
> wrote:
>
>> Does anyone uses package "math/big"? And what purpose?
>>
>> It looks like hard package to work with. At least at the beggining.
>> Even simple line of code takes some efforts to convert to big.Float:
>>
>> y := float64(py) / float64(heightP) * (ymax - ymin) + ymin
>>
>> --
>> 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.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
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] math/big

[Michael Jones]

I use it frequently / constantly / 24/7 :-)

it's purpose is to enable integer, rational, and real arithmetic at chosen
precisions greater than the hardware's native CPU arithmetic.

One property of such thousand or million digit numbers is that they cannot
be moved around the way '5' and '3' are in "j:=5+3"; instead, they are
referred to by address. Since the data may be very large, where to put
temporary values is an important concern for performance and for memory
use. Enabling these means an api that is much more detailed than typical
higher-level language math.

I regret that it is not simpler and more natural (thus various go
proposals) but even as it it is it's great!

https://play.golang.org/p/-FbM22rv4u

On Mon, Aug 28, 2017 at 3:33 PM, Alex Dvoretskiy 
wrote:

> Does anyone uses package "math/big"? And what purpose?
>
> It looks like hard package to work with. At least at the beggining.
> Even simple line of code takes some efforts to convert to big.Float:
>
> y := float64(py) / float64(heightP) * (ymax - ymin) + ymin
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
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] can list.List.Push* or Get return nil?

[BeaT Adrian]

Hello, I just started to learn golang and I have a small dillema.

My programming is too defensive OR how can I replicate this scenario (for 
my test coverage sake)

list = list.New()
element := list.PushBack(item)
 if element == nil {
 //don't know how this can happen, just being defensive
 return false
 }


or 
element:= list.Back()
//can element be nil ? 

I browsed the list.List code but still haven't found a solution how to 
replicate this case.

Thanks!!

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

[go-nuts] math/big

[Alex Dvoretskiy]

Does anyone uses package "math/big"? And what purpose? 

It looks like hard package to work with. At least at the beggining.
Even simple line of code takes some efforts to convert to big.Float:

y := float64(py) / float64(heightP) * (ymax - ymin) + ymin

-- 
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: Go 1.9 introduced error on UDP Multicast JoinGroup

[Harley Laue]

Might be a good excuse to try deposit (https://github.com/golang/dep)

I think

$ dep ensure -update

Might be roughly what you would have wanted in this case.

On Mon, Aug 28, 2017, 12:13 Paul Stead  wrote:

> Excellent catch James!  I looked, and it seems my x/net/ipv4 files were
> all from 2015.  I forced an update of those using go get -u, and things
> seem good now.  I'll need a way to ensure things get updated more
> completely going forward I guess.
>
> thank you.
> Paul
>
> On Mon, Aug 28, 2017 at 11:37 AM, James Bardin  wrote:
>
>>
>>
>> On Sunday, August 27, 2017 at 7:36:22 PM UTC-4, oldCoderException wrote:
>>>
>>> No.  I just downloaded and used 1.9 on its release last week.  I've
>>> reverted to 1.8.3 for now and, as mentioned, it's working fine for me.
>>>
>>>
>
>> Are you certain you also have the latest version of golang.org/x/net/ipv4
>> ?
>>
> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/PYT1wJYHEP0/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>

-- 
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: migration of github.com/gonum/plot to gonum.org/v1/plot

[Sebastien Binet]

hi there,

as mentioned here:
 https://github.com/gonum/plot/issues/372

with relevant PRs here:
 https://github.com/gonum/plot/pull/374
 https://github.com/gonum/plot/pull/376

we (the Gonum community) plan to migrate the import of gonum/plot from:
 "github.com/gonum/plot/..."

to:
 "gonum.org/v1/plot/..."

The switch shall happen Monday the 4th of September.

Unlike the migration of github.com/gonum/{matrix, stat, ...} to their
gonum.org/v1/gonum/{mat,stat,...} counterparts that left the originals
unchanged and still-working, we can't do that for gonum/plot.

so you'll have to update your code.

the good news is that it's very easy:

$> go get -u golang.org/x/tools/cmd/fiximports
$> cd $GOPATH/src/github.com/me/pkg

$> fiximports -replace "github.com/gonum/plot=gonum.org/v1/plot"  ./...

and, to fix non-go files:

$> find $GOPATH/src/github.com/me/pkg \
  -type f \
  -exec sed -i -e 's|"github.com/gonum/plot|"gonum.org/v1/plot|g' {} \;

The other good news is that after that n-th migration, we'll be in good
shape to provide (finally?) stable import paths.

If that doesn't work for you, or if you have any issue with the migration,
feel free to comment here or on one of the PRs.

cheers,
sebastien.

-- 
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: Generics and readability

['David Chase' via golang-nuts]

One distinction that might be helpful is the difference between people 
using a generic data structure
and people writing a generic data structure.  It's much more important that 
the code that makes use
of generics be readable than it is that the body of the generic be 
readable; after all, the existing generic
map implementation is a mashup of compiler and runtime stuff, and few 
people expect to be reading
that.

This does require that people who use generic data structures don't feel a 
need to grovel around in the
source code to figure out how it works.  


On Thursday, August 24, 2017 at 11:14:58 AM UTC-4, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

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

[go-nuts] Re: database/sql - prepared select statements only work on first invocation

[Ain]

On Monday, August 28, 2017 at 10:13:28 PM UTC+3, Uli Kunitz wrote:
>
> I can't replicate your issue. I have create following example, which works 
> perfectly for me on Linux, AMD64 and go 1.9:
>
> https://gist.github.com/ulikunitz/d5335e0667fb57b2d12c8ffa5404b031
>
> You  should create something comparable so that others can test your code.
>

Your code works for me too. But If I swich to firebird driver then the 
error is back... Might be driver specific issue after all... must test some 
more.
Thakns for taking time to test it.


ain

-- 
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: Go 1.9 introduced error on UDP Multicast JoinGroup

[Paul Stead]

Excellent catch James!  I looked, and it seems my x/net/ipv4 files were all
from 2015.  I forced an update of those using go get -u, and things seem
good now.  I'll need a way to ensure things get updated more completely
going forward I guess.

thank you.
Paul

On Mon, Aug 28, 2017 at 11:37 AM, James Bardin  wrote:

>
>
> On Sunday, August 27, 2017 at 7:36:22 PM UTC-4, oldCoderException wrote:
>>
>> No.  I just downloaded and used 1.9 on its release last week.  I've
>> reverted to 1.8.3 for now and, as mentioned, it's working fine for me.
>>
>>

> Are you certain you also have the latest version of golang.org/x/net/ipv4
> ?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/PYT1wJYHEP0/unsubscribe.
> To unsubscribe from this group and all its topics, 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: database/sql - prepared select statements only work on first invocation

[Uli Kunitz]

I can't replicate your issue. I have create following example, which works 
perfectly for me on Linux, AMD64 and go 1.9:

https://gist.github.com/ulikunitz/d5335e0667fb57b2d12c8ffa5404b031

You  should create something comparable so that others can test your code.

-- 
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: Golang 1.9 failing with excelize (simple case works under 1.8.3)

[G Shields]

here is the xlsx data file
FYI this fails on both mac and ubuntu with 1.9


On Friday, August 25, 2017 at 3:10:40 PM UTC-7, G Shields wrote:
>
> Under 1.8.3 the program run:
> package main
>
> import (
> "fmt"
> "os"
> "strconv"
>
> "github.com/Luxurioust/excelize"
> )
>
> func checkErr(err error) {
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
>
> }
> func main() {
>
> xlsx, err := excelize.OpenFile("test.xlsx")
> checkErr(err)
> mysheet := xlsx.GetSheetName(1)
> index := xlsx.GetSheetIndex(mysheet)
> rows := xlsx.GetRows("Sheet" + strconv.Itoa(index))
> for _, row := range rows {
> for _, colCell := range row {
> fmt.Print(colCell, "\t")
> }
> fmt.Println()
> }
> }
>
> With results of:
> naAppleOrangePear
> Small233
> Normal524
> Large678
> Success: process exited with code 0.
>
> Under 1.9 I get no data and no errors:
> Success: process exited with code 0.
>

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


test.xlsx
Description: MS-Excel 2007 spreadsheet

[go-nuts] Re: Go 1.9 introduced error on UDP Multicast JoinGroup

[James Bardin]

On Sunday, August 27, 2017 at 7:36:22 PM UTC-4, oldCoderException wrote:
>
> No.  I just downloaded and used 1.9 on its release last week.  I've 
> reverted to 1.8.3 for now and, as mentioned, it's working fine for me.
>
>
>>>
Are you certain you also have the latest version of golang.org/x/net/ipv4? 

-- 
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] Sort 3 pointers?

[Val]

Yep, that totally makes sense!  I think I would go this path if Vertex was 
declared in a third-party package that I can't alter.

On Monday, August 28, 2017 at 4:17:41 PM UTC+2, Egon wrote:
>
> Oh, forgot one obvious solution, store/check all the combinations of the 
> triangle in the map :D
>
> https://play.golang.org/p/Rqn8LLI4li
> https://play.golang.org/p/0TY_Bcugw8
>
> On Monday, 28 August 2017 16:58:07 UTC+3, Val wrote:
>>
>> @Jakob  sorry what I wrote was confusing, I meant : vertices have strong 
>> identity (same pointer), and triangles are just keys for the map so they 
>> need to be very stable.  A triangle pointer wouldn't solve the case. When I 
>> encounter 3 vertex pointers A, B, C, then I need a "key" to determine if 
>> triangle ABC (or CAB, etc.) is already in the map.
>>
>> @Axel indeed I had not taken into account that the GC may "change the 
>> pointers, while preserving ==" so basically yes ordering pointers looks 
>> unreliable.
>>
>> @Kulti checking equality of triangles by checking combinations of vertex 
>> equality would be interesting but it would make the program really super 
>> slow: instead of a O(1) map lookup, each existence check would cost O(n) to 
>> traverse all the existing triangles, which is too slow because we have 1M+ 
>> triangles. This is because we can't use Triangle as a map key when equality 
>> is computed by a func instead of ==.
>>
>> @Egon those are nice workarounds, thanks.  X,Y,Z are weak, they change 
>> all the time.
>>
>> I will try to minimize code clutter, minimize memory and cpu overhead, 
>> maximize safety and readability.  So I think the best tradeoff so far is to 
>> add a field Vertex.ID, because I have the chance to do it, though it does 
>> clutter a little a fundamental data structure of the whole program.
>> Thank you all for insights!
>>
>> On Monday, August 28, 2017 at 3:20:39 PM UTC+2, Axel Wagner wrote:
>>>
>>> FTR, I don't think ordering by pointer (no matter whether using unsafe 
>>> or not) is reliable and safe. The GC is free to move data around at any 
>>> point, including during your sort.
>>> I don't think there are a lot of ways around that. You could basically 
>>> build your own allocator and add a way for it to return a reliable id. e.g. 
>>> it allocates a []Vertex and the id is the index of the vertex in that 
>>> slice. You can calculate it using unsafe by (roughly. No guarantees here. 
>>> Unsafe is subtle)
>>>
>>> func ID(v *Vertex) int {
>>> i := int(uintptr(unsafe.Pointer(v))) - 
>>> int(uintptr(unsafe.Pointer(&Vertex[0])))
>>> if i < 0 || i > len(pool) {
>>> panic("not pool-allocated")
>>> }
>>> return i
>>> }
>>>
>>> (not that you need to take care to do both conversions in the same 
>>> expression, to satisfy the unsafe.Pointer 
>>>  rules).
>>>
>>> Apart from that, Egon gave a couple of good suggestions :)
>>>
>>> On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  wrote:
>>>
 In that case, maybe use *Triangle pointers instead of Triangle values, 
 and let that address be the identity for map purposes? Then the Vertex 
 order etc doesn't matter any more.

 //jb

 > On 28 Aug 2017, at 14:03, Val  wrote:
 >
 > That's actually a clever idea, I had not thought of that when 
 dismissing the vertex struct inspection. Thanks!
 >
 > But it turns out that X,Y,Z will change often during my program 
 execution: vertices move, but their identity (and the triangles identity) 
 must be strongly preserved.
 >
 > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
 > On 28 Aug 2017, at 13:13, Val  wrote:
 > >
 > > To achieve this, I consider normalizing the triplet so that all 
 keys of the map verify
 > >   A < B < C
 > > for some arbitrary definition of < .  This ensures that I can 
 detect any Triangle already present as key in the map, regardless the 
 order 
 of its Vertex pointers.
 >
 > Can't you sort the Vertex slice by their X,Y,Z position? (You're then 
 not relying on the coordinates for identity, only for order. This breaks 
 for triangles that are actually lines or points, which may or may not be 
 an 
 issue and can be handled separately...)
 >
 > //jb
 >
 > --
 > 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>

-- 
You received this message becau

Re: [go-nuts] Sort 3 pointers?

[Val]

Good point.  We actually do have quite a lot of code that does copy 
everything from one step of computation to next one, for clarity and 
separation of concerns.
We're not afraid to do it one more time if needed, i.e.  translating all 
fundamental Vertices to some "VerticesWithID", and then back.
It is a linear loop, typically dwarfed by the computations inside each step 
which cost >= O(n log n).
The small downsides are : code bloat (boilerplate), memory usage which 
might grow up to ~2x, and a little cpu runtime spent if copying data.

On Monday, August 28, 2017 at 4:22:34 PM UTC+2, Egon wrote:
>
>
> Is there a reason you are dragging all the data of the fundamental 
> data-structure around for this computation?
>
>>
>>>

-- 
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] Sort 3 pointers?

[Val]

Thank you Sébastien, I may use some of it (Orientation, etc) in the 
project.  Having a Point.ID is the straightforwardest way to go anyway.

On Monday, August 28, 2017 at 4:03:44 PM UTC+2, Sebastien Binet wrote:
>
> Valentin,
>
> On Mon, Aug 28, 2017 at 3:58 PM, Val > 
> wrote:
>
>> @Jakob  sorry what I wrote was confusing, I meant : vertices have strong 
>> identity (same pointer), and triangles are just keys for the map so they 
>> need to be very stable.  A triangle pointer wouldn't solve the case. When I 
>> encounter 3 vertex pointers A, B, C, then I need a "key" to determine if 
>> triangle ABC (or CAB, etc.) is already in the map.
>>
>> @Axel indeed I had not taken into account that the GC may "change the 
>> pointers, while preserving ==" so basically yes ordering pointers looks 
>> unreliable.
>>
>> @Kulti checking equality of triangles by checking combinations of vertex 
>> equality would be interesting but it would make the program really super 
>> slow: instead of a O(1) map lookup, each existence check would cost O(n) to 
>> traverse all the existing triangles, which is too slow because we have 1M+ 
>> triangles. This is because we can't use Triangle as a map key when equality 
>> is computed by a func instead of ==.
>>
>> @Egon those are nice workarounds, thanks.  X,Y,Z are weak, they change 
>> all the time.
>>
>> I will try to minimize code clutter, minimize memory and cpu overhead, 
>> maximize safety and readability.  So I think the best tradeoff so far is to 
>> add a field Vertex.ID, because I have the chance to do it, though it does 
>> clutter a little a fundamental data structure of the whole program.
>>
>
> not sure if that would help but, in the context of a Delaunay 
> triangulation, we had to implement a few things that sound like related to 
> your issue:
>
> - https://godoc.org/go-hep.org/x/hep/fastjet/internal/predicates
> - https://godoc.org/go-hep.org/x/hep/fastjet/internal/delaunay
>
> hth,
> -s
>
>
> Thank you all for insights!
>>
>> On Monday, August 28, 2017 at 3:20:39 PM UTC+2, Axel Wagner wrote:
>>>
>>> FTR, I don't think ordering by pointer (no matter whether using unsafe 
>>> or not) is reliable and safe. The GC is free to move data around at any 
>>> point, including during your sort.
>>> I don't think there are a lot of ways around that. You could basically 
>>> build your own allocator and add a way for it to return a reliable id. e.g. 
>>> it allocates a []Vertex and the id is the index of the vertex in that 
>>> slice. You can calculate it using unsafe by (roughly. No guarantees here. 
>>> Unsafe is subtle)
>>>
>>> func ID(v *Vertex) int {
>>> i := int(uintptr(unsafe.Pointer(v))) - 
>>> int(uintptr(unsafe.Pointer(&Vertex[0])))
>>> if i < 0 || i > len(pool) {
>>> panic("not pool-allocated")
>>> }
>>> return i
>>> }
>>>
>>> (not that you need to take care to do both conversions in the same 
>>> expression, to satisfy the unsafe.Pointer 
>>>  rules).
>>>
>>> Apart from that, Egon gave a couple of good suggestions :)
>>>
>>> On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  wrote:
>>>
 In that case, maybe use *Triangle pointers instead of Triangle values, 
 and let that address be the identity for map purposes? Then the Vertex 
 order etc doesn't matter any more.

 //jb

 > On 28 Aug 2017, at 14:03, Val  wrote:
 >
 > That's actually a clever idea, I had not thought of that when 
 dismissing the vertex struct inspection. Thanks!
 >
 > But it turns out that X,Y,Z will change often during my program 
 execution: vertices move, but their identity (and the triangles identity) 
 must be strongly preserved.
 >
 > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
 > On 28 Aug 2017, at 13:13, Val  wrote:
 > >
 > > To achieve this, I consider normalizing the triplet so that all 
 keys of the map verify
 > >   A < B < C
 > > for some arbitrary definition of < .  This ensures that I can 
 detect any Triangle already present as key in the map, regardless the 
 order 
 of its Vertex pointers.
 >
 > Can't you sort the Vertex slice by their X,Y,Z position? (You're then 
 not relying on the coordinates for identity, only for order. This breaks 
 for triangles that are actually lines or points, which may or may not be 
 an 
 issue and can be handled separately...)
 >
 > //jb
 >
 > --
 > 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 
>>>

[go-nuts] Custom ServeMux and pprof

[Dave Cheney]

Copy lines 72-76 into your project. 
https://golang.org/src/net/http/pprof/pprof.go#L72

-- 
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: Generics and readability

[Henrik Johansson]

I don't know I have met many a newbie from university who didn't know their
way around the Java world but would happily work with Haskell because their
advanced courses used it.

On Mon, 28 Aug 2017, 12:30 Wojciech S. Czarnecki  wrote:

> On Sun, 27 Aug 2017 17:28:07 +
> Jesper Louis Andersen  wrote:
>
> > The advantage of having the extra syntactic abstraction in a language is
> > not something you would tend to dismiss too easily I think. While it
> > filters away some contributors from the code base, it also, on the flip
> > side, makes  programmers work more efficiently.
>
> It filters out *all* contributors who are not in the 'more experienced'
> set.
> It allows that few who are already more experienced to *write* faster, but
> every man-second gained at writing is then lost and negated just at
> second read (i.e. peer review). Also, with 'feature rich' languages a
> man-hour
> gain for one experienced programmer easily becomes a whole-team-week
> lost at first debug session.
>
> > However, I don't think the inspiration should be C#, Java or C++. I'd
> > rather look toward
>
> Every one of us would rather look toward already internalized constructs
> of former/first love. Go authors are good at fending us off that urges :)
>
> > The advantage of having the extra syntactic abstraction in a language is
> > not something you would tend to dismiss too easily I think.
>
> On contrary I am happy to dismiss horrors of hours of digging in huge
> pile of sources just to grasp how clever and experienced my predecessor
> was. With go almost everything written by others is clear and in sight.
> What is not right in sight is a single incantation of go doc away.
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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] Using pprof on publicly accessible servers

[Konstantin Khomoutov]

On Mon, Aug 28, 2017 at 08:25:05AM -0700, st ov wrote:

> It's recommended to add pprof to servers
> 
> import _ "net/http/pprof"
> 
> Is this true even for publicly exposed servers? How do you limit access?

Either through your custom ServeMux or by reverse-proxying to your Go
server via something which has configurable access rules.

-- 
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] Custom ServeMux and pprof

[Konstantin Khomoutov]

On Mon, Aug 28, 2017 at 08:31:11AM -0700, st ov wrote:

> How do you add pprof to a custom ServeMux?
> 
> https://golang.org/pkg/net/http/#ServeMux
> 
> Its my understanding that the following import only adds handlers to the 
> default mux.
> 
> import _ "net/http/pprof"

https://blog.cloudflare.com/exposing-go-on-the-internet/#servemux

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

[go-nuts] Re: database/sql - prepared select statements only work on first invocation

[Ain]

On Monday, August 28, 2017 at 7:37:42 PM UTC+3, Tamás Gulácsi wrote:
>
> QueryRow closes the underlyin Stmt - see the docs.


Where in the doc this is mentioned?

https://godoc.org/database/sql#Stmt.QueryRow
<>
 
https://godoc.org/database/sql#Tx.QueryRow
<>

I also had a quick look at the code and didn't see the statement closed 
(but I have not digged really into code, just a quick look).


ain

-- 
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] database/sql - prepared select statements only work on first invocation

[Tamás Gulácsi]

QueryRow closes the underlyin Stmt - see the docs.

-- 
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 the Wait function of sync.WaitGroup behave as a memory barrier?

[honzajde]

I am trying to write a simple code that calls bunch of get requests in 
goroutines and stores result on the struct, that's all -- now I know that 
it is correct with just wg.Wait, ugh go would really suck compared to 
javascript if it was not true...
so far not go but godoc manages to trick me:) 
I have also discovered https://github.com/golang/go/issues/5045 - highly 
recommended for everyone who get's to this old post

Dne pondělí 28. srpna 2017 7:49:51 UTC+2 Ian Lance Taylor napsal(a):
>
> On Sat, Aug 26, 2017 at 4:34 AM, honzajde > 
> wrote: 
> > 
> > Back to the primary question: Is it safe to read condition if I add a 
> break 
> > to the loop like this? 
>
> Yes.  sync.WaitGroup.Wait would be useless if it didn't provide a 
> happens-before relationship from changes made in the goroutine that 
> calls Done to the goroutine that calls Wait. 
>
> I suppose this could be documented in the docs for sync.WaitGroup, but 
> it also kind of falls under the "Go is not trying to trick you" rule. 
>
> 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] RedisDB (Redis server version 2.2.12) Unable to get Cluster Info

[Tamás Gulácsi]

Apples with oranges? In Python, you call "info", in Go "cluster info".

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

[go-nuts] Re: database/sql - prepared select statements only work on first invocation

[Ain]

On Monday, August 28, 2017 at 5:07:30 PM UTC+3, Christian Joergensen wrote:
>
> On Monday, August 28, 2017 at 3:52:54 PM UTC+2, Ain wrote:
>>
>> Does anyone use prepared select statements sucessfully? With which 
>> DB/driver?
>> I'm sure that if my code is silly someone would have pointed it out so 
>> I'm wondering am I the only one trying to use prepared select statements...
>>
>
> Have you seen the last comment on:
> https://godoc.org/database/sql#Tx.Prepare
>

As I understand, this comment (To use an existing prepared statement on 
this transaction, see Tx.Stmt) doesn't apply to the code I posted, it would 
fall under the first part of the documentation.
 
 

> It looks like you're missing the call to:
> https://godoc.org/database/sql#Tx.Stmt
>

I don't think so. As I understand I would need to use Tx.Stmt 
 if I want to use an statement 
prepared outside of the current tx in the current tx. This is not the case 
with the code I posted - it prepares the statement in the tx and then tryes 
to use it twice.


ain

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

[go-nuts] Re: database/sql - prepared select statements only work on first invocation

[Ain]

On Monday, August 28, 2017 at 5:13:09 PM UTC+3, Uli Kunitz wrote:
>
> Where are you calling Exec on the statement?
>

I'm talking about SELECT statements.
https://godoc.org/database/sql#Tx.Exec
<>


ain

 

>
> On Monday, August 28, 2017 at 3:52:54 PM UTC+2, Ain wrote:
>>
>> Hi
>>
>> Tested with 1.9 and got the same behaviour - first row is returned OK, 
>> the second returns error.
>>
>> Does anyone use prepared select statements sucessfully? With which 
>> DB/driver?
>> I'm sure that if my code is silly someone would have pointed it out so 
>> I'm wondering am I the only one trying to use prepared select statements...
>>
>>
>> TIA
>> ain
>>
>>
>>
>> On Thursday, August 17, 2017 at 12:03:47 AM UTC+3, Ain wrote:
>>>
>>> Hi
>>>
>>> I tried to use prepared statements and it works first time, but fails on 
>>> second query. Ie code like
>>>
>>> tx, err := db.Begin()
>>> if err != nil {
>>> log.Fatalf("Error starting tx: %v", err)
>>> }
>>> defer tx.Rollback()
>>> st, err := tx.Prepare("select foo from t where id=?")
>>> if err != nil {
>>> log.Fatalf("Error preparing stmnt: %v", err)
>>> }
>>> defer st.Close()
>>> var n int
>>> err = st.QueryRow(1).Scan(&n)
>>> if err != nil {
>>> log.Fatalf("Error selecting(1): %v", err)
>>> }
>>> fmt.Println("[1] =", n)
>>> err = st.QueryRow(2).Scan(&n)
>>> if err != nil {
>>> log.Fatalf("Error selecting(2): %v", err)
>>> }
>>> fmt.Println("[2] =", n)
>>>
>>> the first row value is printed OK but the second QueryRow fails with 
>>> "Error op_response:0" message (this is with Firebird driver 
>>> github.com/nakagami/firebirdsql). Both id's exist in the DB so single 
>>> row is expected for both executions.
>>> I also got error with "github.com/mattn/go-sqlite3" driver so I don't 
>>> think this is a driver specific issue... either I use it the wrong way or 
>>> there is a bug in the database/sql?
>>>
>>> go version go1.8.1 linux/amd64
>>>
>>> TIA
>>> ain
>>>
>>

-- 
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] Add factory argument to built-in make() function?

['Axel Wagner' via golang-nuts]

I don't really understand what you are suggesting, I think.

On Sun, Aug 27, 2017 at 8:38 PM, RogerV  wrote:

> Would it be feasible for the built-in make() function to be enhanced to
> also accept a factory signifier as an additional argument? The idea would
> be that I could go and implement my own custom variations of map and slice


Not sure I understand this suggestion. AIUI, you want to be able to do
something like
var s = make(map[A]B, MakeT)
Where MakeT returns a value of some custom data type T (say an RB-Tree
based map). I assume you then want to be able to use the returned value
interchangeable with a map[A]B.

Is this correct? If not, can you describe what you are suggesting
differently?

while using make() to instantiate instances of them to where the returned
> object is fully initialized and ready for use per standard make()
> semantics. I would also get the advantage of make() determining what types
> are in the map or slice - some of the benefit of generics.


> There would be a registration API to register a factory mechanism and
> establish the factory signifier that is used in conjunction to the enhanced
> make() function.
>
> Could it be one more modest measure to forestall adding full blown
> generics but get a little bit of the benefit?


> --
> 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] Custom ServeMux and pprof

[st ov]

How do you add pprof to a custom ServeMux?

https://golang.org/pkg/net/http/#ServeMux

Its my understanding that the following import only adds handlers to the 
default mux.

import _ "net/http/pprof"



-- 
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] Using pprof on publicly accessible servers

[st ov]

It's recommended to add pprof to servers

import _ "net/http/pprof"


Is this true even for publicly exposed servers? How do you limit access?

How useful is pprof for clusters since it only profiles a single server?


-- 
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] Sort 3 pointers?

[Kulti]

Hi.

Normalization may not work in some degenerated cases. How about to check
equality of triangles, smth like this: https://play.golang.org/p/W9Gc00HD7E


On Mon, Aug 28, 2017 at 2:13 PM Val  wrote:

> Hello,
> I have some geometry data modelling with
>   type Triangle [3]*Vertex
>
> (The exact definition of Vertex is unimportant here, but I'd like to avoid
> adding more fields inside Vertex if possible.)
>
> Then I'd like to use a triplet of vertices as the entry point of a map
> containing more data like color, texture, etc.:
>   var mesh map[Triangle]Data
>
> When I traverse a big list of Vertices (following edges) to construct the
> list of all Triangles and their Data, it's important that I don't recreate
> Data for triangles that have already been visited, even if triplet is in a
> different order:
>  A B C
>  A C B
>  B A C
>  B C A
>  C A B
>  C B A
> ... are all the same triangle in my specific modelling.
>
> To achieve this, I consider normalizing the triplet so that all keys of
> the map verify
>   A *<* B *<* C
> for some arbitrary definition of *<* .  This ensures that I can detect
> any Triangle already present as key in the map, regardless the order of its
> Vertex pointers.
>
> Unfortunately for this approach, direct pointer arithmetic doesn't exist
> in go: I can test individual Vertex pointers for equality with ==, but not
> for ordering with < or sort.Slice or sort.Sort.
> I could "print a numerical string representation" of each Vertex and use
> the strings as keys, but this looks costly and I'm not sure about this way
> being reliable.
> I could try package unsafe to convert pointers to uintptr, but this looks
> unsafe and may impair portability.
>
> My problem arises from the fact that a Vertex doesn't hold its own ID,
> it's a value object whose identity is solely determined by its memory
> location (its pointer), which is usually fine except for this normalization
> step!
> Note that I can't rely on the values of X, Y, Z coordinates for Vertex
> identity, because several Vertices may be at the same geographical
> position. Inspecting the values stored in each Vertex is irrelevant.
>
> Any creative idea ?
> This may be a starting point: https://play.golang.org/p/qvldUtH68C
>
> 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.
>

-- 
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] Sort 3 pointers?

[Egon]

On Monday, 28 August 2017 16:58:07 UTC+3, Val wrote:
>
> @Jakob  sorry what I wrote was confusing, I meant : vertices have strong 
> identity (same pointer), and triangles are just keys for the map so they 
> need to be very stable.  A triangle pointer wouldn't solve the case. When I 
> encounter 3 vertex pointers A, B, C, then I need a "key" to determine if 
> triangle ABC (or CAB, etc.) is already in the map.
>
> @Axel indeed I had not taken into account that the GC may "change the 
> pointers, while preserving ==" so basically yes ordering pointers looks 
> unreliable.
>
> @Kulti checking equality of triangles by checking combinations of vertex 
> equality would be interesting but it would make the program really super 
> slow: instead of a O(1) map lookup, each existence check would cost O(n) to 
> traverse all the existing triangles, which is too slow because we have 1M+ 
> triangles. This is because we can't use Triangle as a map key when equality 
> is computed by a func instead of ==.
>
> @Egon those are nice workarounds, thanks.  X,Y,Z are weak, they change all 
> the time.
>
> I will try to minimize code clutter, minimize memory and cpu overhead, 
> maximize safety and readability.  So I think the best tradeoff so far is to 
> add a field Vertex.ID, because I have the chance to do it, though it does 
> clutter a little a fundamental data structure of the whole program.
>

Is there a reason you are dragging all the data of the fundamental 
data-structure around for this computation?

e.g. type Vertex2 struct { X, Y, Z float64 }

For graph layouting I wrote, I decided to explicitly separate "API" and the 
"internal" implementation structures.
It keeps things significantly nicer, at the cost of the extra copy or 
redirect.

Thank you all for insights!
>
> On Monday, August 28, 2017 at 3:20:39 PM UTC+2, Axel Wagner wrote:
>>
>> FTR, I don't think ordering by pointer (no matter whether using unsafe or 
>> not) is reliable and safe. The GC is free to move data around at any point, 
>> including during your sort.
>> I don't think there are a lot of ways around that. You could basically 
>> build your own allocator and add a way for it to return a reliable id. e.g. 
>> it allocates a []Vertex and the id is the index of the vertex in that 
>> slice. You can calculate it using unsafe by (roughly. No guarantees here. 
>> Unsafe is subtle)
>>
>> func ID(v *Vertex) int {
>> i := int(uintptr(unsafe.Pointer(v))) - 
>> int(uintptr(unsafe.Pointer(&Vertex[0])))
>> if i < 0 || i > len(pool) {
>> panic("not pool-allocated")
>> }
>> return i
>> }
>>
>> (not that you need to take care to do both conversions in the same 
>> expression, to satisfy the unsafe.Pointer 
>>  rules).
>>
>> Apart from that, Egon gave a couple of good suggestions :)
>>
>> On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  wrote:
>>
>>> In that case, maybe use *Triangle pointers instead of Triangle values, 
>>> and let that address be the identity for map purposes? Then the Vertex 
>>> order etc doesn't matter any more.
>>>
>>> //jb
>>>
>>> > On 28 Aug 2017, at 14:03, Val  wrote:
>>> >
>>> > That's actually a clever idea, I had not thought of that when 
>>> dismissing the vertex struct inspection. Thanks!
>>> >
>>> > But it turns out that X,Y,Z will change often during my program 
>>> execution: vertices move, but their identity (and the triangles identity) 
>>> must be strongly preserved.
>>> >
>>> > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
>>> > On 28 Aug 2017, at 13:13, Val  wrote:
>>> > >
>>> > > To achieve this, I consider normalizing the triplet so that all keys 
>>> of the map verify
>>> > >   A < B < C
>>> > > for some arbitrary definition of < .  This ensures that I can detect 
>>> any Triangle already present as key in the map, regardless the order of its 
>>> Vertex pointers.
>>> >
>>> > Can't you sort the Vertex slice by their X,Y,Z position? (You're then 
>>> not relying on the coordinates for identity, only for order. This breaks 
>>> for triangles that are actually lines or points, which may or may not be an 
>>> issue and can be handled separately...)
>>> >
>>> > //jb
>>> >
>>> > --
>>> > 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...@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 

Re: [go-nuts] Sort 3 pointers?

[Egon]

Oh, forgot one obvious solution, store/check all the combinations of the 
triangle in the map :D

https://play.golang.org/p/Rqn8LLI4li
https://play.golang.org/p/0TY_Bcugw8

On Monday, 28 August 2017 16:58:07 UTC+3, Val wrote:
>
> @Jakob  sorry what I wrote was confusing, I meant : vertices have strong 
> identity (same pointer), and triangles are just keys for the map so they 
> need to be very stable.  A triangle pointer wouldn't solve the case. When I 
> encounter 3 vertex pointers A, B, C, then I need a "key" to determine if 
> triangle ABC (or CAB, etc.) is already in the map.
>
> @Axel indeed I had not taken into account that the GC may "change the 
> pointers, while preserving ==" so basically yes ordering pointers looks 
> unreliable.
>
> @Kulti checking equality of triangles by checking combinations of vertex 
> equality would be interesting but it would make the program really super 
> slow: instead of a O(1) map lookup, each existence check would cost O(n) to 
> traverse all the existing triangles, which is too slow because we have 1M+ 
> triangles. This is because we can't use Triangle as a map key when equality 
> is computed by a func instead of ==.
>
> @Egon those are nice workarounds, thanks.  X,Y,Z are weak, they change all 
> the time.
>
> I will try to minimize code clutter, minimize memory and cpu overhead, 
> maximize safety and readability.  So I think the best tradeoff so far is to 
> add a field Vertex.ID, because I have the chance to do it, though it does 
> clutter a little a fundamental data structure of the whole program.
> Thank you all for insights!
>
> On Monday, August 28, 2017 at 3:20:39 PM UTC+2, Axel Wagner wrote:
>>
>> FTR, I don't think ordering by pointer (no matter whether using unsafe or 
>> not) is reliable and safe. The GC is free to move data around at any point, 
>> including during your sort.
>> I don't think there are a lot of ways around that. You could basically 
>> build your own allocator and add a way for it to return a reliable id. e.g. 
>> it allocates a []Vertex and the id is the index of the vertex in that 
>> slice. You can calculate it using unsafe by (roughly. No guarantees here. 
>> Unsafe is subtle)
>>
>> func ID(v *Vertex) int {
>> i := int(uintptr(unsafe.Pointer(v))) - 
>> int(uintptr(unsafe.Pointer(&Vertex[0])))
>> if i < 0 || i > len(pool) {
>> panic("not pool-allocated")
>> }
>> return i
>> }
>>
>> (not that you need to take care to do both conversions in the same 
>> expression, to satisfy the unsafe.Pointer 
>>  rules).
>>
>> Apart from that, Egon gave a couple of good suggestions :)
>>
>> On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  wrote:
>>
>>> In that case, maybe use *Triangle pointers instead of Triangle values, 
>>> and let that address be the identity for map purposes? Then the Vertex 
>>> order etc doesn't matter any more.
>>>
>>> //jb
>>>
>>> > On 28 Aug 2017, at 14:03, Val  wrote:
>>> >
>>> > That's actually a clever idea, I had not thought of that when 
>>> dismissing the vertex struct inspection. Thanks!
>>> >
>>> > But it turns out that X,Y,Z will change often during my program 
>>> execution: vertices move, but their identity (and the triangles identity) 
>>> must be strongly preserved.
>>> >
>>> > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
>>> > On 28 Aug 2017, at 13:13, Val  wrote:
>>> > >
>>> > > To achieve this, I consider normalizing the triplet so that all keys 
>>> of the map verify
>>> > >   A < B < C
>>> > > for some arbitrary definition of < .  This ensures that I can detect 
>>> any Triangle already present as key in the map, regardless the order of its 
>>> Vertex pointers.
>>> >
>>> > Can't you sort the Vertex slice by their X,Y,Z position? (You're then 
>>> not relying on the coordinates for identity, only for order. This breaks 
>>> for triangles that are actually lines or points, which may or may not be an 
>>> issue and can be handled separately...)
>>> >
>>> > //jb
>>> >
>>> > --
>>> > 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...@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] GoBkm 0.9 released

[Thomas Bellembois]

Hi Gophers !

I have released a new version of the GoBkm bookmarks manager.

https://github.com/tbellembois/gobkm/releases/tag/0.9

The main improvement is the new GUI.

Regards,

Thomas

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

[go-nuts] Re: database/sql - prepared select statements only work on first invocation

[Uli Kunitz]

Where are you calling Exec on the statement?

On Monday, August 28, 2017 at 3:52:54 PM UTC+2, Ain wrote:
>
> Hi
>
> Tested with 1.9 and got the same behaviour - first row is returned OK, the 
> second returns error.
>
> Does anyone use prepared select statements sucessfully? With which 
> DB/driver?
> I'm sure that if my code is silly someone would have pointed it out so I'm 
> wondering am I the only one trying to use prepared select statements...
>
>
> TIA
> ain
>
>
>
> On Thursday, August 17, 2017 at 12:03:47 AM UTC+3, Ain wrote:
>>
>> Hi
>>
>> I tried to use prepared statements and it works first time, but fails on 
>> second query. Ie code like
>>
>> tx, err := db.Begin()
>> if err != nil {
>> log.Fatalf("Error starting tx: %v", err)
>> }
>> defer tx.Rollback()
>> st, err := tx.Prepare("select foo from t where id=?")
>> if err != nil {
>> log.Fatalf("Error preparing stmnt: %v", err)
>> }
>> defer st.Close()
>> var n int
>> err = st.QueryRow(1).Scan(&n)
>> if err != nil {
>> log.Fatalf("Error selecting(1): %v", err)
>> }
>> fmt.Println("[1] =", n)
>> err = st.QueryRow(2).Scan(&n)
>> if err != nil {
>> log.Fatalf("Error selecting(2): %v", err)
>> }
>> fmt.Println("[2] =", n)
>>
>> the first row value is printed OK but the second QueryRow fails with 
>> "Error op_response:0" message (this is with Firebird driver 
>> github.com/nakagami/firebirdsql). Both id's exist in the DB so single 
>> row is expected for both executions.
>> I also got error with "github.com/mattn/go-sqlite3" driver so I don't 
>> think this is a driver specific issue... either I use it the wrong way or 
>> there is a bug in the database/sql?
>>
>> go version go1.8.1 linux/amd64
>>
>> TIA
>> ain
>>
>

-- 
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: Add factory argument to built-in make() function?

[Rick]

Interesting idea! Throw in operator overloading to retain the current make 
and its signature and the new make with addition of factory arg?

On Sunday, 27 August 2017 11:38:47 UTC-7, RogerV wrote:
>
> Would it be feasible for the built-in make() function to be enhanced to 
> also accept a factory signifier as an additional argument?
>
> The idea would be that I could go and implement my own custom variations 
> of map and slice while using make() to instantiate instances of them to 
> where the returned object is fully initialized and ready for use per 
> standard make() semantics. I would also get the advantage of make() 
> determining what types are in the map or slice - some of the benefit of 
> generics.
>
> There would be a registration API to register a factory mechanism and 
> establish the factory signifier that is used in conjunction to the enhanced 
> make() function.
>
> Could it be one more modest measure to forestall adding full blown 
> generics but get a little bit of the benefit?
>
>

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

[go-nuts] Re: database/sql - prepared select statements only work on first invocation

[Christian Joergensen]

On Monday, August 28, 2017 at 3:52:54 PM UTC+2, Ain wrote:
>
> Does anyone use prepared select statements sucessfully? With which 
> DB/driver?
> I'm sure that if my code is silly someone would have pointed it out so I'm 
> wondering am I the only one trying to use prepared select statements...
>

Have you seen the last comment on:
https://godoc.org/database/sql#Tx.Prepare

It looks like you're missing the call to:
https://godoc.org/database/sql#Tx.Stmt

Cheers,

Christian 

-- 
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] Sort 3 pointers?

[Sebastien Binet]

Valentin,

On Mon, Aug 28, 2017 at 3:58 PM, Val  wrote:

> @Jakob  sorry what I wrote was confusing, I meant : vertices have strong
> identity (same pointer), and triangles are just keys for the map so they
> need to be very stable.  A triangle pointer wouldn't solve the case. When I
> encounter 3 vertex pointers A, B, C, then I need a "key" to determine if
> triangle ABC (or CAB, etc.) is already in the map.
>
> @Axel indeed I had not taken into account that the GC may "change the
> pointers, while preserving ==" so basically yes ordering pointers looks
> unreliable.
>
> @Kulti checking equality of triangles by checking combinations of vertex
> equality would be interesting but it would make the program really super
> slow: instead of a O(1) map lookup, each existence check would cost O(n) to
> traverse all the existing triangles, which is too slow because we have 1M+
> triangles. This is because we can't use Triangle as a map key when equality
> is computed by a func instead of ==.
>
> @Egon those are nice workarounds, thanks.  X,Y,Z are weak, they change all
> the time.
>
> I will try to minimize code clutter, minimize memory and cpu overhead,
> maximize safety and readability.  So I think the best tradeoff so far is to
> add a field Vertex.ID, because I have the chance to do it, though it does
> clutter a little a fundamental data structure of the whole program.
>

not sure if that would help but, in the context of a Delaunay
triangulation, we had to implement a few things that sound like related to
your issue:

- https://godoc.org/go-hep.org/x/hep/fastjet/internal/predicates
- https://godoc.org/go-hep.org/x/hep/fastjet/internal/delaunay

hth,
-s


Thank you all for insights!
>
> On Monday, August 28, 2017 at 3:20:39 PM UTC+2, Axel Wagner wrote:
>>
>> FTR, I don't think ordering by pointer (no matter whether using unsafe or
>> not) is reliable and safe. The GC is free to move data around at any point,
>> including during your sort.
>> I don't think there are a lot of ways around that. You could basically
>> build your own allocator and add a way for it to return a reliable id. e.g.
>> it allocates a []Vertex and the id is the index of the vertex in that
>> slice. You can calculate it using unsafe by (roughly. No guarantees here.
>> Unsafe is subtle)
>>
>> func ID(v *Vertex) int {
>> i := int(uintptr(unsafe.Pointer(v))) - int(uintptr(unsafe.Pointer(&Ve
>> rtex[0])))
>> if i < 0 || i > len(pool) {
>> panic("not pool-allocated")
>> }
>> return i
>> }
>>
>> (not that you need to take care to do both conversions in the same
>> expression, to satisfy the unsafe.Pointer
>>  rules).
>>
>> Apart from that, Egon gave a couple of good suggestions :)
>>
>> On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  wrote:
>>
>>> In that case, maybe use *Triangle pointers instead of Triangle values,
>>> and let that address be the identity for map purposes? Then the Vertex
>>> order etc doesn't matter any more.
>>>
>>> //jb
>>>
>>> > On 28 Aug 2017, at 14:03, Val  wrote:
>>> >
>>> > That's actually a clever idea, I had not thought of that when
>>> dismissing the vertex struct inspection. Thanks!
>>> >
>>> > But it turns out that X,Y,Z will change often during my program
>>> execution: vertices move, but their identity (and the triangles identity)
>>> must be strongly preserved.
>>> >
>>> > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
>>> > On 28 Aug 2017, at 13:13, Val  wrote:
>>> > >
>>> > > To achieve this, I consider normalizing the triplet so that all keys
>>> of the map verify
>>> > >   A < B < C
>>> > > for some arbitrary definition of < .  This ensures that I can detect
>>> any Triangle already present as key in the map, regardless the order of its
>>> Vertex pointers.
>>> >
>>> > Can't you sort the Vertex slice by their X,Y,Z position? (You're then
>>> not relying on the coordinates for identity, only for order. This breaks
>>> for triangles that are actually lines or points, which may or may not be an
>>> issue and can be handled separately...)
>>> >
>>> > //jb
>>> >
>>> > --
>>> > 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...@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.goo

Re: [go-nuts] Sort 3 pointers?

[Val]

@Jakob  sorry what I wrote was confusing, I meant : vertices have strong 
identity (same pointer), and triangles are just keys for the map so they 
need to be very stable.  A triangle pointer wouldn't solve the case. When I 
encounter 3 vertex pointers A, B, C, then I need a "key" to determine if 
triangle ABC (or CAB, etc.) is already in the map.

@Axel indeed I had not taken into account that the GC may "change the 
pointers, while preserving ==" so basically yes ordering pointers looks 
unreliable.

@Kulti checking equality of triangles by checking combinations of vertex 
equality would be interesting but it would make the program really super 
slow: instead of a O(1) map lookup, each existence check would cost O(n) to 
traverse all the existing triangles, which is too slow because we have 1M+ 
triangles. This is because we can't use Triangle as a map key when equality 
is computed by a func instead of ==.

@Egon those are nice workarounds, thanks.  X,Y,Z are weak, they change all 
the time.

I will try to minimize code clutter, minimize memory and cpu overhead, 
maximize safety and readability.  So I think the best tradeoff so far is to 
add a field Vertex.ID, because I have the chance to do it, though it does 
clutter a little a fundamental data structure of the whole program.
Thank you all for insights!

On Monday, August 28, 2017 at 3:20:39 PM UTC+2, Axel Wagner wrote:
>
> FTR, I don't think ordering by pointer (no matter whether using unsafe or 
> not) is reliable and safe. The GC is free to move data around at any point, 
> including during your sort.
> I don't think there are a lot of ways around that. You could basically 
> build your own allocator and add a way for it to return a reliable id. e.g. 
> it allocates a []Vertex and the id is the index of the vertex in that 
> slice. You can calculate it using unsafe by (roughly. No guarantees here. 
> Unsafe is subtle)
>
> func ID(v *Vertex) int {
> i := int(uintptr(unsafe.Pointer(v))) - 
> int(uintptr(unsafe.Pointer(&Vertex[0])))
> if i < 0 || i > len(pool) {
> panic("not pool-allocated")
> }
> return i
> }
>
> (not that you need to take care to do both conversions in the same 
> expression, to satisfy the unsafe.Pointer 
>  rules).
>
> Apart from that, Egon gave a couple of good suggestions :)
>
> On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  > wrote:
>
>> In that case, maybe use *Triangle pointers instead of Triangle values, 
>> and let that address be the identity for map purposes? Then the Vertex 
>> order etc doesn't matter any more.
>>
>> //jb
>>
>> > On 28 Aug 2017, at 14:03, Val > wrote:
>> >
>> > That's actually a clever idea, I had not thought of that when 
>> dismissing the vertex struct inspection. Thanks!
>> >
>> > But it turns out that X,Y,Z will change often during my program 
>> execution: vertices move, but their identity (and the triangles identity) 
>> must be strongly preserved.
>> >
>> > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
>> > On 28 Aug 2017, at 13:13, Val  wrote:
>> > >
>> > > To achieve this, I consider normalizing the triplet so that all keys 
>> of the map verify
>> > >   A < B < C
>> > > for some arbitrary definition of < .  This ensures that I can detect 
>> any Triangle already present as key in the map, regardless the order of its 
>> Vertex pointers.
>> >
>> > Can't you sort the Vertex slice by their X,Y,Z position? (You're then 
>> not relying on the coordinates for identity, only for order. This breaks 
>> for triangles that are actually lines or points, which may or may not be an 
>> issue and can be handled separately...)
>> >
>> > //jb
>> >
>> > --
>> > 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...@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: database/sql - prepared select statements only work on first invocation

[Ain]

Hi

Tested with 1.9 and got the same behaviour - first row is returned OK, the 
second returns error.

Does anyone use prepared select statements sucessfully? With which 
DB/driver?
I'm sure that if my code is silly someone would have pointed it out so I'm 
wondering am I the only one trying to use prepared select statements...


TIA
ain



On Thursday, August 17, 2017 at 12:03:47 AM UTC+3, Ain wrote:
>
> Hi
>
> I tried to use prepared statements and it works first time, but fails on 
> second query. Ie code like
>
> tx, err := db.Begin()
> if err != nil {
> log.Fatalf("Error starting tx: %v", err)
> }
> defer tx.Rollback()
> st, err := tx.Prepare("select foo from t where id=?")
> if err != nil {
> log.Fatalf("Error preparing stmnt: %v", err)
> }
> defer st.Close()
> var n int
> err = st.QueryRow(1).Scan(&n)
> if err != nil {
> log.Fatalf("Error selecting(1): %v", err)
> }
> fmt.Println("[1] =", n)
> err = st.QueryRow(2).Scan(&n)
> if err != nil {
> log.Fatalf("Error selecting(2): %v", err)
> }
> fmt.Println("[2] =", n)
>
> the first row value is printed OK but the second QueryRow fails with 
> "Error op_response:0" message (this is with Firebird driver 
> github.com/nakagami/firebirdsql). Both id's exist in the DB so single row 
> is expected for both executions.
> I also got error with "github.com/mattn/go-sqlite3" driver so I don't 
> think this is a driver specific issue... either I use it the wrong way or 
> there is a bug in the database/sql?
>
> go version go1.8.1 linux/amd64
>
> TIA
> ain
>

-- 
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: Convert grid of colors to SVG

[ajstarks]

Also note that the "richter" program is included in the package.

On Monday, August 28, 2017 at 9:35:25 AM UTC-4, ajstarks wrote:
>
> it would be helpful to better understand what you want to do, but:
>
> https://speakerdeck.com/ajstarks/svgo-code-plus-picture-examples
>
> includes the code below (with many other examples would should be 
> illustrate the capabilities of the package)
>
> package main
>
>
> import (
>
> "math/rand"
>
> "os"
>
> "time"
>
>
> "github.com/ajstarks/svgo"
>
> )
>
>
> var (
>
> canvas = svg.New(os.Stdout)
>
> width  = 500
>
> height = 500
>
> )
>
>
> // inspired by Gerhard Richter's 256 colors, 1974
>
> func main() {
>
> rand.Seed(time.Now().Unix())
>
> canvas.Start(width, height)
>
> canvas.Rect(0, 0, width, height)
>
>
> w, h, gutter := 24, 18, 5
>
> rows, cols := 16, 16
>
> top, left := 20, 20
>
>
> for r, x := 0, left; r < rows; r++ {
>
> for c, y := 0, top; c < cols; c++ {
>
> canvas.Rect(x, y, w, h,
>
> canvas.RGB(rand.Intn(255), rand.Intn(255), rand.Intn(255)))
>
> y += (h + gutter)
>
> }
>
> x += (w + gutter)
>
> }
>
> canvas.End()
>
> }
>
>

-- 
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: Convert grid of colors to SVG

[ajstarks]

it would be helpful to better understand what you want to do, but:

https://speakerdeck.com/ajstarks/svgo-code-plus-picture-examples

includes the code below (with many other examples would should be 
illustrate the capabilities of the package)

package main


import (

"math/rand"

"os"

"time"


"github.com/ajstarks/svgo"

)


var (

canvas = svg.New(os.Stdout)

width  = 500

height = 500

)


// inspired by Gerhard Richter's 256 colors, 1974

func main() {

rand.Seed(time.Now().Unix())

canvas.Start(width, height)

canvas.Rect(0, 0, width, height)


w, h, gutter := 24, 18, 5

rows, cols := 16, 16

top, left := 20, 20


for r, x := 0, left; r < rows; r++ {

for c, y := 0, top; c < cols; c++ {

canvas.Rect(x, y, w, h,

canvas.RGB(rand.Intn(255), rand.Intn(255), rand.Intn(255)))

y += (h + gutter)

}

x += (w + gutter)

}

canvas.End()

}

-- 
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] Sort 3 pointers?

['Axel Wagner' via golang-nuts]

FTR, I don't think ordering by pointer (no matter whether using unsafe or
not) is reliable and safe. The GC is free to move data around at any point,
including during your sort.
I don't think there are a lot of ways around that. You could basically
build your own allocator and add a way for it to return a reliable id. e.g.
it allocates a []Vertex and the id is the index of the vertex in that
slice. You can calculate it using unsafe by (roughly. No guarantees here.
Unsafe is subtle)

func ID(v *Vertex) int {
i := int(uintptr(unsafe.Pointer(v))) -
int(uintptr(unsafe.Pointer(&Vertex[0])))
if i < 0 || i > len(pool) {
panic("not pool-allocated")
}
return i
}

(not that you need to take care to do both conversions in the same
expression, to satisfy the unsafe.Pointer 
rules).

Apart from that, Egon gave a couple of good suggestions :)

On Mon, Aug 28, 2017 at 3:02 PM, Jakob Borg  wrote:

> In that case, maybe use *Triangle pointers instead of Triangle values, and
> let that address be the identity for map purposes? Then the Vertex order
> etc doesn't matter any more.
>
> //jb
>
> > On 28 Aug 2017, at 14:03, Val  wrote:
> >
> > That's actually a clever idea, I had not thought of that when dismissing
> the vertex struct inspection. Thanks!
> >
> > But it turns out that X,Y,Z will change often during my program
> execution: vertices move, but their identity (and the triangles identity)
> must be strongly preserved.
> >
> > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
> > On 28 Aug 2017, at 13:13, Val  wrote:
> > >
> > > To achieve this, I consider normalizing the triplet so that all keys
> of the map verify
> > >   A < B < C
> > > for some arbitrary definition of < .  This ensures that I can detect
> any Triangle already present as key in the map, regardless the order of its
> Vertex pointers.
> >
> > Can't you sort the Vertex slice by their X,Y,Z position? (You're then
> not relying on the coordinates for identity, only for order. This breaks
> for triangles that are actually lines or points, which may or may not be an
> issue and can be handled separately...)
> >
> > //jb
> >
> > --
> > 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.
>

-- 
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] Sort 3 pointers?

[Jakob Borg]

In that case, maybe use *Triangle pointers instead of Triangle values, and let 
that address be the identity for map purposes? Then the Vertex order etc 
doesn't matter any more.

//jb

> On 28 Aug 2017, at 14:03, Val  wrote:
> 
> That's actually a clever idea, I had not thought of that when dismissing the 
> vertex struct inspection. Thanks!
> 
> But it turns out that X,Y,Z will change often during my program execution: 
> vertices move, but their identity (and the triangles identity) must be 
> strongly preserved.
> 
> On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
> On 28 Aug 2017, at 13:13, Val  wrote: 
> > 
> > To achieve this, I consider normalizing the triplet so that all keys of the 
> > map verify 
> >   A < B < C 
> > for some arbitrary definition of < .  This ensures that I can detect any 
> > Triangle already present as key in the map, regardless the order of its 
> > Vertex pointers. 
> 
> Can't you sort the Vertex slice by their X,Y,Z position? (You're then not 
> relying on the coordinates for identity, only for order. This breaks for 
> triangles that are actually lines or points, which may or may not be an issue 
> and can be handled separately...) 
> 
> //jb
> 
> -- 
> 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: Sort 3 pointers?

[Egon]

When are two vertices considered equal?
If by X, Y, Z, then what is the precision of if?

How often does Vertex position change?
How often are new Triangles created?

Anyways:

1. if you can use unsafe: https://play.golang.org/p/6cMS6aMCz7
2. if you cannot use unsafe and can add 1 field to 
vertex: https://play.golang.org/p/gVCU795Abw
2.1. you can store the ID and create one as needed in external 
map[*Vertex]int, with the obvious drawbacks
3. or use index into the vertex array as 
ID: https://play.golang.org/p/gtkKbmOyvw

On Monday, 28 August 2017 14:13:34 UTC+3, Val wrote:
>
> Hello,
> I have some geometry data modelling with
>   type Triangle [3]*Vertex
>
> (The exact definition of Vertex is unimportant here, but I'd like to avoid 
> adding more fields inside Vertex if possible.)
>
> Then I'd like to use a triplet of vertices as the entry point of a map 
> containing more data like color, texture, etc.:
>   var mesh map[Triangle]Data
>
> When I traverse a big list of Vertices (following edges) to construct the 
> list of all Triangles and their Data, it's important that I don't recreate 
> Data for triangles that have already been visited, even if triplet is in a 
> different order:
>  A B C
>  A C B
>  B A C
>  B C A
>  C A B
>  C B A
> ... are all the same triangle in my specific modelling.
>
> To achieve this, I consider normalizing the triplet so that all keys of 
> the map verify
>   A *<* B *<* C
> for some arbitrary definition of *<* .  This ensures that I can detect 
> any Triangle already present as key in the map, regardless the order of its 
> Vertex pointers.
>
> Unfortunately for this approach, direct pointer arithmetic doesn't exist 
> in go: I can test individual Vertex pointers for equality with ==, but not 
> for ordering with < or sort.Slice or sort.Sort.
> I could "print a numerical string representation" of each Vertex and use 
> the strings as keys, but this looks costly and I'm not sure about this way 
> being reliable.
> I could try package unsafe to convert pointers to uintptr, but this looks 
> unsafe and may impair portability.
>
> My problem arises from the fact that a Vertex doesn't hold its own ID, 
> it's a value object whose identity is solely determined by its memory 
> location (its pointer), which is usually fine except for this normalization 
> step!
> Note that I can't rely on the values of X, Y, Z coordinates for Vertex 
> identity, because several Vertices may be at the same geographical 
> position. Inspecting the values stored in each Vertex is irrelevant.
>
> Any creative idea ?
> This may be a starting point: https://play.golang.org/p/qvldUtH68C
>
> 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] Convert grid of colors to SVG

[steve_bagwell]

Thanks Konstantin.  That's a good point.  I've posted an issue on that 
repo. Unfortunately, there is another issue there from Sep 2016 which 
doesn't appear to have a reply yet. We'll see if I get a reply.

On Monday, August 28, 2017 at 3:36:13 AM UTC-4, Konstantin Khomoutov wrote:
>
> On Fri, Aug 25, 2017 at 10:18:17AM -0700, steve_...@sil.org  
> wrote: 
>
>
> So, this begs the question: why producing yet another narrow-scoped 
> library when there exist another one which has pretty much of stuff 
> already packed in? 
>
> Is it possible for you to came in touch with the svgo maintainers and 
> discuss integrating your code into that library? 
>
>

-- 
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] Sort 3 pointers?

[Val]

That's actually a clever idea, I had not thought of that when dismissing 
the vertex struct inspection. Thanks!

But it turns out that X,Y,Z will change often during my program execution: 
vertices move, but their identity (and the triangles identity) must be 
strongly preserved.

On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote:
>
> On 28 Aug 2017, at 13:13, Val > wrote: 
> > 
> > To achieve this, I consider normalizing the triplet so that all keys of 
> the map verify 
> >   A < B < C 
> > for some arbitrary definition of < .  This ensures that I can detect any 
> Triangle already present as key in the map, regardless the order of its 
> Vertex pointers. 
>
> Can't you sort the Vertex slice by their X,Y,Z position? (You're then not 
> relying on the coordinates for identity, only for order. This breaks for 
> triangles that are actually lines or points, which may or may not be an 
> issue and can be handled separately...) 
>
> //jb

-- 
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] Sort 3 pointers?

[Jakob Borg]

On 28 Aug 2017, at 13:13, Val  wrote:
> 
> To achieve this, I consider normalizing the triplet so that all keys of the 
> map verify
>   A < B < C
> for some arbitrary definition of < .  This ensures that I can detect any 
> Triangle already present as key in the map, regardless the order of its 
> Vertex pointers.

Can't you sort the Vertex slice by their X,Y,Z position? (You're then not 
relying on the coordinates for identity, only for order. This breaks for 
triangles that are actually lines or points, which may or may not be an issue 
and can be handled separately...)

//jb

-- 
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] Sort 3 pointers?

[Val]

Hello,
I have some geometry data modelling with
  type Triangle [3]*Vertex

(The exact definition of Vertex is unimportant here, but I'd like to avoid 
adding more fields inside Vertex if possible.)

Then I'd like to use a triplet of vertices as the entry point of a map 
containing more data like color, texture, etc.:
  var mesh map[Triangle]Data

When I traverse a big list of Vertices (following edges) to construct the 
list of all Triangles and their Data, it's important that I don't recreate 
Data for triangles that have already been visited, even if triplet is in a 
different order:
 A B C
 A C B
 B A C
 B C A
 C A B
 C B A
... are all the same triangle in my specific modelling.

To achieve this, I consider normalizing the triplet so that all keys of the 
map verify
  A *<* B *<* C
for some arbitrary definition of *<* .  This ensures that I can detect any 
Triangle already present as key in the map, regardless the order of its 
Vertex pointers.

Unfortunately for this approach, direct pointer arithmetic doesn't exist in 
go: I can test individual Vertex pointers for equality with ==, but not for 
ordering with < or sort.Slice or sort.Sort.
I could "print a numerical string representation" of each Vertex and use 
the strings as keys, but this looks costly and I'm not sure about this way 
being reliable.
I could try package unsafe to convert pointers to uintptr, but this looks 
unsafe and may impair portability.

My problem arises from the fact that a Vertex doesn't hold its own ID, it's 
a value object whose identity is solely determined by its memory location 
(its pointer), which is usually fine except for this normalization step!
Note that I can't rely on the values of X, Y, Z coordinates for Vertex 
identity, because several Vertices may be at the same geographical 
position. Inspecting the values stored in each Vertex is irrelevant.

Any creative idea ?
This may be a starting point: https://play.golang.org/p/qvldUtH68C

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: Generics and readability

[Wojciech S. Czarnecki]

On Sun, 27 Aug 2017 17:28:07 +
Jesper Louis Andersen  wrote:

> The advantage of having the extra syntactic abstraction in a language is
> not something you would tend to dismiss too easily I think. While it
> filters away some contributors from the code base, it also, on the flip
> side, makes  programmers work more efficiently.

It filters out *all* contributors who are not in the 'more experienced' set.
It allows that few who are already more experienced to *write* faster, but
every man-second gained at writing is then lost and negated just at
second read (i.e. peer review). Also, with 'feature rich' languages a man-hour
gain for one experienced programmer easily becomes a whole-team-week
lost at first debug session.

> However, I don't think the inspiration should be C#, Java or C++. I'd
> rather look toward

Every one of us would rather look toward already internalized constructs
of former/first love. Go authors are good at fending us off that urges :)

> The advantage of having the extra syntactic abstraction in a language is
> not something you would tend to dismiss too easily I think.

On contrary I am happy to dismiss horrors of hours of digging in huge
pile of sources just to grasp how clever and experienced my predecessor
was. With go almost everything written by others is clear and in sight.
What is not right in sight is a single incantation of go doc away.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Convert grid of colors to SVG

[Konstantin Khomoutov]

On Fri, Aug 25, 2017 at 10:18:17AM -0700, steve_bagw...@sil.org wrote:

> > There's svgo: https://github.com/ajstarks/svgo 
[...]
> Thanks Andrey,
> SVGO didn't seem to include that particular functionality. Maybe I just 
> didn't look carefully enough?

So, this begs the question: why producing yet another narrow-scoped
library when there exist another one which has pretty much of stuff
already packed in?

Is it possible for you to came in touch with the svgo maintainers and
discuss integrating your code into that library?

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