[go-nuts] Fancy Comments & Documentation

[Chris FractalBach]

So, I'm one of those people who sometimes adds comments like this to my 
code:

++
|   Program Title|
|   Author   |
|Date|
++
 Synopsis, Description, etc.
__


However, adding comments like this into Go code often ruins the 
documentation, so I have been avoiding it.
Are there any solutions to get the best of both worlds?

-- 
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: Why not tuples?

[Jan Mercl]

On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

>
> func (b *Bast) Parent(c Cursor) Cursor {
> if c.Index == 0 {
> c.Err = errors.New("No parent from the root")
> return c
> }
> c.Row--
> c.Index = c.Index>>1 - (c.Index+1)%2
> c.Err = nil
> return c
> }
>

This method looks like it should be defined be on *Cursor receiver, not
*Bast.

-- 

-j

-- 
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] Extension for type assertion of interface array

[nsakthi93]

Usescases that I came across doesn't involve []interface{}. 

My usecases will be similar to this sample code 


type landSpace struct {
//consider that landSpace implements all functions from both Shape and 
property interfaces
...
}
type Shape interface {
...
}


type property interface {

...
}


var a []*landSpace

func processShapes(shapes []Shape) {
//
}

func evaluateProperties(properties []Property) {
//
}



If I want to pass the variable 'a' to both the functions, then I have to 
write two functions to clone and typeAssert to respective interfaces.


On Wednesday, 18 April 2018 19:53:33 UTC+5:30, Jan Mercl wrote:
>
> On Wed, Apr 18, 2018 at 4:13 PM  wrote:
>
> When possible, avoid using '[]interface{}' and use just 'interface{}' 
> instead: https://play.golang.org/p/oPtPoGChkMZ.
>
>
> -- 
>
> -j
>

-- 
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: Why not tuples?

[Louki Sumirniy]

I think there is no really big reason to make a special tuple type for 
return values. The extra burden comes in specifying the type and wrapping 
the list in curly brackets, and predefining the elements in a type struct 
declaration. I am writing a dense binary tree implementation (dense as in 
not sparse like all previously invented BST's) and I have defined a 
'cursor' structure which very conveniently can be used as both parameter 
and return value, and has made my code 1000x more readable and 
maintainable. Here is some snippets from this code:

type Cursor struct {
Index Index
Row   Row
Err   error
}

An example where I am just passing things through:

func (b *Bast) Parent(c Cursor) Cursor {
if c.Index == 0 {
c.Err = errors.New("No parent from the root")
return c
}
c.Row--
c.Index = c.Index>>1 - (c.Index+1)%2
c.Err = nil
return c
}

And here is an example where I named the variable in the function so it 
creates a new instance that I can work on separately to the input value:

func (b *Bast) Find(d Data) (c Cursor) {
for notfound := true; notfound && c.Err == nil; {
if b.Store[c.Index] == d {
return c
}
if b.IsLeft(d, c) {
c = b.LeftChild(c)
} else {
c = b.RightChild(c)
}
if c.IsOutside(b) || b.Store[c.Index].IsEmpty() {
c.Err = errors.New("Did not find data in tree")
}
}
return c
}

On Saturday, 21 November 2009 03:23:43 UTC+2, ziyu_huang wrote:
>
> I like multiple return, when language support it, tuple is meaningless 
> to me. 
> Why add complex syntax when there already have simple one ? 
> A simple struct can do the same thing if you insist to .. 
>
> type ATuple { 
>rv1 int; 
>rv2 int; 
>rv3 string; 
> } 
>
> func tuple_return_func() { 
>a, b int; 
>... 
> return  ATuple { a, b, "some string"}; 
> } 
>
> ret := tuple_return_func(); 
>
>
>
> On 11月21日, 上午12時47分, Ben Tilly  wrote: 
> > On Fri, Nov 20, 2009 at 7:36 AM, Joseph Stewart 
> wrote: 
> > 
> > [...] 
> > 
> > > Being a Lua user, I've grown accustom to multiple return values... I'd 
> > > respectfully like this feature to remain. 
> > 
> > Ruby demonstrates that there is no contradiction.  If you add in the 
> > ability to flatten a tuple, or decide when to gather several things 
> > into a tuple, then the two features co-exist perfectly 
> > 
> > Inventing some syntax: 
> > 
> >   // explicit declaration 
> >   type SomeTuple [string, int] tuple; 
> > 
> >   // Interaction with multiple returns 
> >   myTuple := [ function_returning_multiple_values() ]; 
> >   this, that := @myTuple; 
> > 
> > Cheers, 
> > Ben 
>

-- 
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] (*net.TCPListener).File() switches to blocking mode

[Ian Lance Taylor]

On Wed, Apr 18, 2018 at 7:25 PM, Steven Roth  wrote:
>
> I just wrote some code for graceful restart of a web server, following
> models available on the web.  Unlike those models, my code didn't work.  The
> parent (old) web server refused to exit.  The call to server.Shutdown
> returned success, and the listener got closed, but the server.Serve call
> never returned.  After some differential debugging, I figured out this was
> because of an unexpected side effect of the File method of the listener:  it
> puts the connection in blocking mode.  In my case, I was calling that method
> at the time I created the listener, which means the connection was in
> blocking mode at the time server.Serve called its Accept method, so the
> Accept never returned.  When I moved my call to the File method to happen
> later, everything started working properly.
>
> So now I'm curious:  _why_ does calling File on net.TCPListener change the
> behavior of the listener?  Is that a bug that I should report?

Before about Go 1.9 or so the os package could not handle a
non-blocking descriptor, so File had to change the connection to
blocking mode in order to make it usable.  Now, however, the os
package does use nonblocking descriptors where possible.  We could
probably change the File method to use a nonblocking *os.File.  Please
do open an issue for that.

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] http "alt" attribute value for img tag?

[l vic]

I need to get "alt" value from html "img" tag:


...
message










What would be the correct way in Go to read "alt" values into array?

Thank you,



-- 
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] (*net.TCPListener).File() switches to blocking mode

[Steven Roth]

I just wrote some code for graceful restart of a web server, following
models available on the web.  Unlike those models, my code didn't work.
The parent (old) web server refused to exit.  The call to server.Shutdown
returned success, and the listener got closed, but the server.Serve call
never returned.  After some differential debugging, I figured out this was
because of an unexpected side effect of the File method of the listener:
it puts the connection in blocking mode.  In my case, I was calling that
method at the time I created the listener, which means the connection was
in blocking mode at the time server.Serve called its Accept method, so the
Accept never returned.  When I moved my call to the File method to happen
later, everything started working properly.

So now I'm curious:  _why_ does calling File on net.TCPListener change the
behavior of the listener?  Is that a bug that I should report?

Regards,
Steve

-- 
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] The Go code formatter

[Jérôme LAFORGE]

I have already confronted to this problem with table driven test. 

-- 
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 golang ORM that supports Vertica VSQL?

[Big K]

Does anyone know of a ORM library for golang that supports Vertica VSQL?

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] Re: code structure question

[Keith Brown]

I like the idea of putting each command in an ishell.Cmd.

Yeah, I wasn't sure about the struct. Basically, I wanted an easy way to 
map my code

so, I was thinking a yaml file (I suppose I can create a struct from it).

- clear
- greet 
  - user
  - (no user) #if no user is specified then greet all users
- list 
  - tables
  - acls
- red
- blue 
- exit

I guess I was sort of looking for a GRPC (protoful file) model where I 
specify my specs in a file and go by it -- single source of truth.


On Wednesday, April 18, 2018 at 9:09:08 AM UTC-4, matthe...@gmail.com wrote:
>
> Consider putting each ishell.Cmd in a separate file. Otherwise you can put 
> them in a slice var so you don’t have to AddCmd each one explicitly.
>
> I’m not sure what defining a struct accomplishes, can you provide more 
> detail?
>
> Matt
>
> On Tuesday, April 17, 2018 at 8:25:17 PM UTC-5, Keith Brown wrote:
>>
>> I am writing an interactive CLI tool which looks like this, using 
>> abisoft/ishell
>>
>> ./tool
>> >>> help
>>
>> Sample Interactive Shell
>> >>> help
>>
>> Commands:
>>   clear  clear the screen
>>   greet  greet user
>>   exit   exit the program
>>   help   display help
>>
>> >>> greet Someone Somewhere
>> Hello Someone Somewhere
>> >>> exit
>>
>> My tool will have many subcommands. 
>>
>> So, greet  < subcommand> and I was wondering what would be a 
>> good way to structure the program. I was thinking of putting everything in 
>> one large struct and have nested structs for commands similar to JSON 
>> encoded file.
>>
>> any thoughts?
>>
>>

-- 
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: Extension for type assertion of interface array

[matthewjuran]

I think if you opened a proposal it would be merged into the generics 
discussion: https://github.com/golang/go/issues/15292

There may be other ways to write the program, can you provide a concrete 
example of where you’ve needed this?

Matt

On Wednesday, April 18, 2018 at 9:13:59 AM UTC-5, Sakthi Natesan wrote:
>
> Go supports below type assertion 
>
> t := i.(T)
> and 
> t, ok := i.(T)
>
> Can this feature be extended to array of interfaces as mentioned below?
>
> t := i.([]T)
> and 
> t, ok := i.([]T)
>
>
> I have been using Golang for almost four years and I have come across use 
> cases requiring this feature many times. So far, I write a function for 
> each specific case which clones the array into new array with type asserted 
> to new type. I repeat the same pattern of assertion for array of different 
> types and perform extra array copy each time I assert. Is there a better 
> alternative solution with existing Go feature or Is there a chance that 
> this feature will be supported in future?
>
> sample 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.

Re: [go-nuts] Extension for type assertion of interface array

[Jan Mercl]

On Wed, Apr 18, 2018 at 4:22 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Apr 18, 2018 at 4:13 PM  wrote:
>
> When possible, avoid using '[]interface{}' and use just 'interface{}'
> instead: https://play.golang.org/p/oPtPoGChkMZ.
>
>
>
The link should have been: https://play.golang.org/p/aLKIxkr3VKg




> --
>
> -j
>
-- 

-j

-- 
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] Extension for type assertion of interface array

[Jan Mercl]

On Wed, Apr 18, 2018 at 4:13 PM  wrote:

When possible, avoid using '[]interface{}' and use just 'interface{}'
instead: https://play.golang.org/p/oPtPoGChkMZ.


-- 

-j

-- 
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] Extension for type assertion of interface array

[nsakthi93]

Go supports below type assertion 

t := i.(T)
and 
t, ok := i.(T)

Can this feature be extended to array of interfaces as mentioned below?

t := i.([]T)
and 
t, ok := i.([]T)


I have been using Golang for almost four years and I have come across use 
cases requiring this feature many times. So far, I write a function for 
each specific case which clones the array into new array with type asserted 
to new type. I repeat the same pattern of assertion for array of different 
types and perform extra array copy each time I assert. Is there a better 
alternative solution with existing Go feature or Is there a chance that 
this feature will be supported in future?

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

Re: [go-nuts] Usage example inside a lib project

[matthewjuran]

An example directory works too and is pretty common.

Matt

On Wednesday, April 18, 2018 at 7:45:45 AM UTC-5, Federico Paolinelli wrote:
>
> Il giorno mercoledì 18 aprile 2018 08:41:30 UTC-4, Jan Mercl ha scritto:
>>
>> On Wed, Apr 18, 2018 at 2:35 PM Federico Paolinelli  
>> wrote:
>>
>> See https://golang.org/pkg/testing/#hdr-Examples. Put the examples into 
>> the foo_test.go file.
>>
>>
>>
> Oh, didn't realize that it was a convention. Thanks a lot! 
>

-- 
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: code structure question

[matthewjuran]

Consider putting each ishell.Cmd in a separate file. Otherwise you can put 
them in a slice var so you don’t have to AddCmd each one explicitly.

I’m not sure what defining a struct accomplishes, can you provide more 
detail?

Matt

On Tuesday, April 17, 2018 at 8:25:17 PM UTC-5, Keith Brown wrote:
>
> I am writing an interactive CLI tool which looks like this, using 
> abisoft/ishell
>
> ./tool
> >>> help
>
> Sample Interactive Shell
> >>> help
>
> Commands:
>   clear  clear the screen
>   greet  greet user
>   exit   exit the program
>   help   display help
>
> >>> greet Someone Somewhere
> Hello Someone Somewhere
> >>> exit
>
> My tool will have many subcommands. 
>
> So, greet  < subcommand> and I was wondering what would be a good 
> way to structure the program. I was thinking of putting everything in one 
> large struct and have nested structs for commands similar to JSON encoded 
> file.
>
> any thoughts?
>
>

-- 
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] Usage example inside a lib project

[Federico Paolinelli]

Il giorno mercoledì 18 aprile 2018 08:41:30 UTC-4, Jan Mercl ha scritto:
>
> On Wed, Apr 18, 2018 at 2:35 PM Federico Paolinelli  > wrote:
>
> See https://golang.org/pkg/testing/#hdr-Examples. Put the examples into 
> the foo_test.go file.
>
>
>
Oh, didn't realize that it was a convention. Thanks a lot! 

-- 
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] Usage example inside a lib project

[Jan Mercl]

On Wed, Apr 18, 2018 at 2:35 PM Federico Paolinelli 
wrote:

See https://golang.org/pkg/testing/#hdr-Examples. Put the examples into the
foo_test.go file.


-- 

-j

-- 
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] Creating snap app using Go

[Kaveh Shahbazian]

How one should make a snap app using Go (1.10.1)?

The snapcraft tool uses Go 1.6.

-- 
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] [ANN] Slowpoke (database engine)

[recoilme]

Keys storage not grow, they are overriding on an update, values override too if 
size of old value is sufficient

If no - it will grow. I have plans to add compaction on backup in future. 
Right now backup may be implemented in three command (sets(gets(keys(

> On 18 Apr 2018, at 11:31, Sokolov Yura  wrote:
> 
> How it is compacted?
> Values will be updated and deleted, storage file will grow. How garbage will 
> be collected?
> 
> вторник, 17 апреля 2018 г., 14:37:27 UTC+3 пользователь vadim kulibaba 
> написал:
> Hi Everyone,
> 
> I finished simple and effective key/value store with nice api:
> https://github.com/recoilme/slowpoke 
> 
> The performance was not a target of this database but it performs well and 
> not so slow as i expected. It just stores values in files and keys with value 
> addresses in memory, with persistence. No LSM-tree, no BTree, no mmap, just 
> standard library (hash table+slice in goroutine).
> 
> Let me know what you think!
> 
> -- 
> 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/eGW7eDvdnBw/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] Usage example inside a lib project

[Federico Paolinelli]

Hi everyone, I am pretty new to golang and I have the following question.

I developed a lib for internal use here at work. It has it's own package 
and tests inside the git repo.
Now, I would like to add an example of how to use it, but if I add a 
package main file it will be interpreted as a command and installed 
whenever someone does a go install (which is not good, I guess).

An approach I saw in various projects is to include a non test function in 
a test file just to show how the lib should be used.
Examples: 
- https://github.com/sirupsen/logrus/blob/master/example_hook_test.go
- https://github.com/juju/errors/blob/master/example_test.go

Is this the right approach? In this way the example functions are not 
included in the release (since they belong to tests) and do not interfere 
with tests (since the name / args do not fit), but how am I supposed to try 
them inside a main?

Thanks in advance,

Federico

-- 
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] question about asm doc

[buaa . cch]

I also wonder if there are some official doc about this stack layout on 
amd64..

在 2018年4月18日星期三 UTC+8上午3:48:46，Ian Lance Taylor写道：
>
> On Tue, Apr 17, 2018 at 9:46 AM,   
> wrote: 
> > here: 
> > https://github.com/golang/go/files/447163/GoFunctionsInAssembly.pdf 
>
> OK, you'll have to ask Michael Munday, CC'ed. 
>
> Ian 
>
> > 在 2018年4月17日星期二 UTC+8下午10:15:07，Ian Lance Taylor写道： 
> >> 
> >> On Tue, Apr 17, 2018 at 5:33 AM,  wrote: 
> >> > 
> >> > Official doc (golang.org/doc/asm) said that: 
> >> > 
> >> > The SP pseudo-register is a virtual stack pointer used to refer to 
> >> > frame-local variables and the arguments being prepared for function 
> calls. 
> >> > It points to the top of the local stack frame, so references should 
> use 
> >> > negative offsets in the range [−framesize, 0): x-8(SP), y-4(SP), and 
> so on. 
> >> > 
> >> > And I've found a slide introduce the amd64 stack frame layout. 
> >> > 
> >> > So, is the -framesize a correct value? If I count from the SP(virtual 
> >> > register), the min address will exceed the stack frame address range. 
> >> 
> >> I don't think the diagram you are looking at describes how the Go 
> >> assembler works.  I note that it seems to say IBM on the side.  Where 
> >> did you find the diagram? 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [go-nuts] The Go code formatter

[Ali Altun]

A lof of similar situation, this kind of formating approach is needed. 
For example, the unformatted (or more precisely the manual formatted part) 
is mode readable for me. 
It may not be objective.

// Before Go gofmt'ed

aTempl := []map[string]interface{}{
> {"fname": "id", "label": "Id", "boyut4": "01"},
> {"fname": "exp", "label": "Exp", "boyut4": "02"},
> {"fname": "atarih", "label": "Atarih", "boyut4": "05"},
> {"fname": "kimlk", "label": "Kimlik", "boyut4": "03"},
> {"fname": "perso", "label": "Perso", "boyut4": "04"},
> }



// After Go gofmt'ed

aTempl := []map[string]interface{}{
> {"fname": "id", "label": "Id", "boyut4": "01"},
> {"fname": "exp", "label": "Exp", "boyut4": "02"},
> {"fname": "atarih", "label": "Atarih", "boyut4": "05"},
> {"fname": "kimlk", "label": "Kimlik", "boyut4": "03"},
> {"fname": "perso", "label": "Perso", "boyut4": "04"},
> }
>
 

-- 
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] The Go code formatter

[Ali Altun]

aTempl := []map[string]interface{}{
{"fname": "id", "label": "Id", "boyut4": "01"},
{"fname": "exp", "label": "Exp", "boyut4": "02"},
{"fname": "atarih", "label": "Atarih", "boyut4": "05"},
{"fname": "kimlk", "label": "Kimlik", "boyut4": "03"},
{"fname": "perso", "label": "Perso", "boyut4": "04"},
}


On Wednesday, 18 April 2018 13:29:37 UTC+2, Jan Mercl wrote:
>
> On Wed, Apr 18, 2018 at 1:24 PM Ali Altun  > wrote:
>
> > There is a code part in the https://golang.org/pkg/sort/#example_
> > The Go code formatter doesn't change this code. 
>
> The code is already gofmt'ed, so no change is expected.
>
> > Similarly, how can I make it leave the following code snippet unchanged? 
> Does this have a technique?
>
> No, gofmt puts a line break after the opening left brace of any statement 
> block that's not a function block with a short and simple body.
>
> -- 
>
> -j
>

-- 
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] The Go code formatter

[Jan Mercl]

On Wed, Apr 18, 2018 at 1:24 PM Ali Altun  wrote:

> There is a code part in the https://golang.org/pkg/sort/#example_
> The Go code formatter doesn't change this code.

The code is already gofmt'ed, so no change is expected.

> Similarly, how can I make it leave the following code snippet unchanged?
Does this have a technique?

No, gofmt puts a line break after the opening left brace of any statement
block that's not a function block with a short and simple body.

-- 

-j

-- 
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] The Go code formatter

[Ali Altun]

There is a code part in the https://golang.org/pkg/sort/#example_
The Go code formatter doesn't change this code. 

func (a ByAge) Len() int { return len(a) }
> func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
> func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
>

Similarly, how can I make it leave the following code snippet unchanged? 
Does this have a technique?
?

if cKtipi == "relan" || cKtipi == "rolan" { cSorec = "rec0" }
> if cKtipi == "nelan" || cKtipi == "nolan" { cSorec = "new0" }
> if cKtipi == "owlan" || cKtipi == "orlan" { cSorec = "oRec" }

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

[agruetz45]

Jakob,

Thank you. I knew I had to be missing some nuance of how to use the library 
correctly.

Thanks,
Anthony

On Wednesday, April 18, 2018 at 1:44:13 AM UTC-7, Jakob Borg wrote:
>
> That is a much too large value to be precisely represented by a float64. 
> You need more bits, and you need to tell big.Float how many bits that is: 
>
> *https://play.golang.org/p/btm6-_9NQgB 
> *
>
> //jb
>
> On 18 Apr 2018, at 09:57, agru...@gmail.com  wrote:
>
> I have been playing with the karatsuba algorithm and was doing some 
> testing testing to compute the correct values of two large numbers 
> 3141592653589793238462643383279502884197169399375105820974944592 
> and 2718281828459045235360287471352662497757247093699959574966967627. 
> When working with the math/big package I noticed this oddity, I am sure I 
> am doing something wrong but hopefully someone can help point it out. If 
> notice from below the value out of big.NewFloat(myFloat) does not match the 
> value from printing out g. It also does not match if I print using 
> g.Float64() and then print the value from that. Should not this be the same 
> thing in and the same thing out? Thanks in advance. 
>
> // 
> 8539734222673567065463550869546574495034888535765114961879601127067743044893204848617875072216249073013374895871952806582723184
>  
> - correct
> // 
> 8539734222673566930176750436921930623970378254642185393758656420093500067115747270318696482879857934897660315084890343252951040
>  
> - incorrect but this is what I get with the big.NewFloat().Mul
>
> f := big.NewFloat(float64(
> 3141592653589793238462643383279502884197169399375105820974944592)) 
> //.SetPrec(9223372036854775807) 
> //.SetMode(big.ToZero)
> g := big.NewFloat(float64(
> 2718281828459045235360287471352662497757247093699959574966967627)) 
> //.SetPrec(9223372036854775807) 
> //.SetMode(big.ToZero)
> 2718281828459045271981924443963747209279784634148078442319446016.00 
> this is what g prints vs what was input
>
> h := big.NewFloat(1).Mul(f, g).SetPrec(9223372036854775807) 
> //.SetMode(big.ToZero)
>
> a := float64(
> 3141592653589793238462643383279502884197169399375105820974944592) * 
> float64(2718281828459045235360287471352662497757247093699959574966967627)
>
> fmt.Printf("%f\n", f)
> fmt.Printf("%f\n", g) //prints out 
> 2718281828459045271981924443963747209279784634148078442319446016.00
> fmt.Printf("%f\n", a)
> fmt.Printf("%f\n", h)
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: [go-nuts] math/big oddities

[Jakob Borg]

That is a much too large value to be precisely represented by a float64. You 
need more bits, and you need to tell big.Float how many bits that is:

https://play.golang.org/p/btm6-_9NQgB

//jb

On 18 Apr 2018, at 09:57, agruet...@gmail.com wrote:

I have been playing with the karatsuba algorithm and was doing some testing 
testing to compute the correct values of two large numbers 
3141592653589793238462643383279502884197169399375105820974944592 and 
2718281828459045235360287471352662497757247093699959574966967627. When working 
with the math/big package I noticed this oddity, I am sure I am doing something 
wrong but hopefully someone can help point it out. If notice from below the 
value out of big.NewFloat(myFloat) does not match the value from printing out 
g. It also does not match if I print using g.Float64() and then print the value 
from that. Should not this be the same thing in and the same thing out? Thanks 
in advance.

// 
8539734222673567065463550869546574495034888535765114961879601127067743044893204848617875072216249073013374895871952806582723184
 - correct
// 
8539734222673566930176750436921930623970378254642185393758656420093500067115747270318696482879857934897660315084890343252951040
 - incorrect but this is what I get with the big.NewFloat().Mul

f := 
big.NewFloat(float64(3141592653589793238462643383279502884197169399375105820974944592))
 //.SetPrec(9223372036854775807) //.SetMode(big.ToZero)
g := 
big.NewFloat(float64(2718281828459045235360287471352662497757247093699959574966967627))
 //.SetPrec(9223372036854775807) //.SetMode(big.ToZero)
2718281828459045271981924443963747209279784634148078442319446016.00 this is 
what g prints vs what was input

h := big.NewFloat(1).Mul(f, g).SetPrec(9223372036854775807) 
//.SetMode(big.ToZero)

a := 
float64(3141592653589793238462643383279502884197169399375105820974944592) * 
float64(2718281828459045235360287471352662497757247093699959574966967627)

fmt.Printf("%f\n", f)
fmt.Printf("%f\n", g) //prints out 
2718281828459045271981924443963747209279784634148078442319446016.00
fmt.Printf("%f\n", a)
fmt.Printf("%f\n", h)

--
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: [ANN] Slowpoke (database engine)

[Sokolov Yura]

How it is compacted?
Values will be updated and deleted, storage file will grow. How garbage 
will be collected?

вторник, 17 апреля 2018 г., 14:37:27 UTC+3 пользователь vadim kulibaba 
написал:
>
> Hi Everyone,
>
> I finished simple and effective key/value store with nice api:
> https://github.com/recoilme/slowpoke
>
> The performance was not a target of this database but it performs well and 
> not so slow as i expected. It just stores values in files and keys with 
> value addresses in memory, with persistence. No LSM-tree, no BTree, no 
> mmap, just standard library (hash table+slice in goroutine).
>
> Let me know what you think!
>

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

[agruetz45]

I have been playing with the karatsuba algorithm and was doing some testing 
testing to compute the correct values of two large numbers 
3141592653589793238462643383279502884197169399375105820974944592 
and 2718281828459045235360287471352662497757247093699959574966967627. When 
working with the math/big package I noticed this oddity, I am sure I am 
doing something wrong but hopefully someone can help point it out. If 
notice from below the value out of big.NewFloat(myFloat) does not match the 
value from printing out g. It also does not match if I print using 
g.Float64() and then print the value from that. Should not this be the same 
thing in and the same thing out? Thanks in advance.

// 
8539734222673567065463550869546574495034888535765114961879601127067743044893204848617875072216249073013374895871952806582723184
 
- correct
// 
8539734222673566930176750436921930623970378254642185393758656420093500067115747270318696482879857934897660315084890343252951040
 
- incorrect but this is what I get with the big.NewFloat().Mul

f := big.NewFloat(float64(
3141592653589793238462643383279502884197169399375105820974944592)) 
//.SetPrec(9223372036854775807) 
//.SetMode(big.ToZero)
g := big.NewFloat(float64(
2718281828459045235360287471352662497757247093699959574966967627)) 
//.SetPrec(9223372036854775807) 
//.SetMode(big.ToZero)
2718281828459045271981924443963747209279784634148078442319446016.00 
this is what g prints vs what was input

h := big.NewFloat(1).Mul(f, g).SetPrec(9223372036854775807) 
//.SetMode(big.ToZero)

a := float64(
3141592653589793238462643383279502884197169399375105820974944592) * float64(
2718281828459045235360287471352662497757247093699959574966967627)

fmt.Printf("%f\n", f)
fmt.Printf("%f\n", g) //prints out 
2718281828459045271981924443963747209279784634148078442319446016.00
fmt.Printf("%f\n", a)
fmt.Printf("%f\n", h)

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