[go-nuts] Re: Proposal: return if any not nil

[charraster]

The OP's idea is the best one so far. What about the following.

r, err := os.Open("blah.txt")
*return* nil *if* r == nil, err *if* err != nil

basically every return field could be followed by an optional if clause 
with an expression that must evaluate to bool.

The return only happens if all optional if clauses evaluate to true.

Could be also used to bubble errors up the stack

r, err := os.Open("blah.txt")
*return* nil, fmt.Errorf("File open failed") *if* err != nil



-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[charraster]

code of conduct workers should work on adding generics to compilers


-- 
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: Data locality in large slices

[charraster]

Tu cast pola s ktorou pracujes mas v L1/ L2 cache. V momente ked 
pristupujes k inej casti pola ktora je niekolko megabajtov vzdialena tak 
procesor musi natiahnut tie udaje z ram do cache. Neviem presne cisla ale 
trva to zhruba tych 300 strojovych cyklov . Vypadok L2 neviem kolko trva, 
je to v manualoch.

On Wednesday, August 3, 2016 at 4:24:08 PM UTC+2, ondrej...@gmail.com wrote:
>
> Downgrading to 1.6.3, I'm also getting consistent benchmark results. I'll 
> try 1.7 on my Mac at home later today, to see if it's a 1.7 thing or a 
> Windows thing or...?
>
> On Wednesday, 3 August 2016 14:55:20 UTC+1, C Banning wrote:
>>
>> PS - that's with Go v1.6.
>>
>> On Wednesday, August 3, 2016 at 7:49:49 AM UTC-6, C Banning wrote:
>>>
>>> On MacBook Pro, 2.6 GHz Intel Core i7, 8 GB 1600 MHz memory, running OS 
>>> X 10.11.6, your benchmarks look pretty consistent:
>>>
>>>
>>> BenchmarkStart-4  20 1.45 ns/op
>>>
>>> BenchmarkEnd-420 1.47 ns/op
>>>
>>> BenchmarkHereThere-4  20 1.46 ns/op
>>>
>>> BenchmarkStartEnd-4   20 1.46 ns/op
>>>
>>> BenchmarkEndStart-4   20 1.46 ns/op
>>>
>>> BenchmarkFirst-4  20 0.59 ns/op
>>>
>>> BenchmarkSecond-4 20 0.59 ns/op
>>>
>>> BenchmarkLast-4   20 0.59 ns/op
>>>
>>> BenchmarkPenultimate-4 20 0.58 ns/op
>>>
>>> On Wednesday, August 3, 2016 at 5:56:32 AM UTC-6, Ondrej wrote:

 I wanted to see if there was a difference when loading values from a 
 large-ish slice (1 elements) - to see if caches, locality and other 
 things had any meaningful impacts. Whilst individual value loading (just a 
 single element) seemed to be equally fast regardless of element position 
 (see bench of First, Second, Last, Penultimate), when combining loading of 
 various values, there seem to be almost a 2.5x difference between loading 
 first four values and loading last four values (first two benchmarks).
 Loading the same values, just in different order, also yields different 
 execution times. But alternating loading (0, n, 1, n-1) seems to be faster 
 than loading first two values and last two values.

 (Setting the test slice to be an array instead wipes all differences 
 between benchmarks.)

 Can anyone point me to a resource - be it Go specific or on computer 
 science principles - that would explain these large differences?

 Thanks!

 https://play.golang.org/p/oMqDvXI9YW

>>>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[charraster]

On Wednesday, August 3, 2016 at 6:16:37 PM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Aug 3, 2016 at 9:12 AM, T L  
> wrote: 
> > 
> > On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote: 
> >> 
> >> True, but it would still be just the same loop, it wouldn't actually be 
> >> significantly faster. And you'd need to put quite some machinery into a 
> >> pretty rarely used functionality, which means it also wouldn't be 
> cleaner. 
> >> 
> >> The thing is, that the memory representation of []T and []J, with J 
> being 
> >> an interface type, is very different form each other and differs also 
> for 
> >> each (T, J) pair, AIUI. So you can't really efficiently generalize 
> this. The 
> >> only thing it could possibly safe you, is writing the actual loop and 
> in 
> >> general go doesn't really do this kind of tradeoff (saving small 
> amounts of 
> >> trivial work by complicating the language and -implementation). 
> > 
> > 
> > so the copy buitlin function is not essential? 
>
> Correct. 
>
> Although it is worth noting that, in the absence of significant 
> compiler optimizations that the gc compiler does not currently 
> implement, the copy builtin can be much more efficient than the 
> ordinary user written loop; see 
> https://golang.org/src/runtime/memmove_amd64.s.  That is not true of a 
> function that converts from []T to []interface. 
>
> Ian 
>


Enabling user to do conversion from []*Tto[]*U   (the slices 
contain pointers) would be easy, doing a slight modification in the 
compilers.
We did tricks like this already in modified versions of go


Enabling user to do conversion from []T  (T is arbitrary not just fixed 
size type)   to   []interface would be possible with a deep modification 
involving linkers and other stuff (that I don't understand very well).

Dealing with []T when T is an interface would be nightmare difficult and I 
don't even know where would I begin

i believe in go experts they are more than capable to deal with this

-- 
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: A proposal for generic in go

[charraster]

> How does the compiler know sizeof(T)? 
>


interesting question. About obtaining sizeof(T). The sizeof(T) is known 
from the call site calling the generic function, in particular from the 
type of variable that's passed to the generic function. What If generic 
function calls another generic function (possibly in different "module"? 
Now the T in callee is equal to T in caller, so sizeof is same, no need to 
do anything. (remember i use single parametric so there is no T1, T2 etc...)

After obtaining sizeof(T), it needs to be passed to the function. I'm no 
call convention expert so In my experiment I've did the stupid simplest 
thing to make it work,  Before a call to a generic function, I emitted  
runtime setter to store it, then in function i get it from runtime. there 
is race, sure but can be swept under the rug by putting it to thread 
specific place, maybe G(goroutine) . 
 

> If it's passed as an argument or saved together with the struct or 
> something in that regard, you end up with the "java approach", if you have 
> the compiler specializes the function per size, you end up with the "C++ 
> approach" (also, in either case, there is no need for the "only pointers 
> are allowed" kludge), from
>


If go goes the Java way but does it somehow differently. Something clever 
but very practical. I believe this is possible.

Perhaps modify Golang's 2.0 calling convention, that EVERY function must 
get upon compilation one extra invisible-to programmer argument that is 
pointer that
when said function is generic, points to sizeof(T) storage place .
If you're calling to non-generic function it's just NULL, and it seems like 
a waste? but does it slow it down everything so much??

 

> http://research.swtch.com/generic
> The most basic rule, for everyone arguing in favor of generics, is, that 
> they need to decide which tradeoff they make and how they justify it. That 
> blog post should be step 1 for everyone wanting to propose generics.
>

-- 
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: A proposal for generic in go

[charraster]

On Friday, July 1, 2016 at 1:53:46 PM UTC+2, Andrew Mezoni wrote:
>
> >> Now imagine that T=int8
>
> Generic struct always has the same size only because it uses pointers.
>
> type S  struct {
>   elem ***T
>   arr []T
> }
>
> I believe you've made a mistake here, elem needs to be *T , not T

-- 
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: A proposal for generic in go

[charraster]

On Wednesday, June 15, 2016 at 3:04:05 AM UTC+2, xingtao zhao wrote:
>
> Here is my proposal for generic in go: 
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>
> Many parts has not been finished, and just initial thoughts. In the 
> proposal, I want to keep back compatibility. And I try to add the 
> orthogonal feature only and keep the language still simple enough. 
>
> Please add your comments on it. Hope it is useful and could inspire some 
> new features in go 2.0
>
>
the parametrized struct got me interested, how to best handle the embedding 
the arbitrary type.

Especially passing said struct to a generic function. 



type S struct {

I1  int

C1  char

*T1  T*

I2  int

*Ts1 [2]T*

Is1 [10]int

Ts2 [53]T

C2  char

T2  T

Ts3 [2]T

Tp1 *T

I3  int
}


Now imagine that T=int8
For the reason, the following concrete struct satisfies the template:

type ActualS struct {

I1  int

C1  char

*T1  i*nt8

I2  int

*Ts1 [2]**i*nt8

Is1 [10]int

Ts2 [53]*i*nt8

C2  char

T2  *i*nt8

Ts3 [2]*i*nt8

Tp1 *T

I3  int
}

Now, the concrete struct is passed to the algorithm that accepts S. 

func IllegalAlgo(x S) {
  x.T1 = x.T2   
}

 I think this should not be allowed, because variable x could have 
different sizes based on sizeof(T).

But passing the arbitrary large struct S via pointer could work:

func OKAlgo(x *S) {
  x.T1 = x.T2   
}

Now.
Obvious mode of operation would be that the procedure or algorithm would 
perform the multiplications by sizeof(T) to access fields.
In my opinion, would be best to move the generic-sized objects to the end 
(or require them to be placed at the end). This way said algorithm could 
operate on almost the whole object without need for arithmetic. 

type S struct {

I1  int

C1  char

I2  int

Is1 [10]int

C2  char

Tp1 *T

I3  int

//
*T1  T*

*Ts1 [2]T*

Ts2 [53]T

T2  T

Ts3 [2]T
}


 

> 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: polymorphism (for Go 2.0), new fast playground is live

[charraster]

On Thursday, June 16, 2016 at 3:20:10 PM UTC+2, Sean Russell wrote:
>
> I'm sorry -- the "share" button doesn't seem to be working, or doesn't 
> work in Firefox or Chrome.  And I have a window hung on "waiting for remote 
> server," so I might have broken your playground.  
>
 
TL:DR type conversion from arbitrary type to another arbitrary type is not 
directly possible with my proposal and needs to be done in two passes via a 
common type.


This is a tough task, and won't work directly using single parametric 
polymorphism the way you propose. 

Type conversion between two arbitrary types could become the single most 
significant weak spot of single parametric polymorphism and
a huge argument for multi parametric .


> Here's my code in (hopefully) compileable form for your processor:
>
> package main
>
> impoort "strconv"
>
> // Given:
> func map(f(*), a []*, result []*) {
>for i, k := range a {
>   result[i] = f(k)
>}
> }
>
>

This function would compile, but would not do what you want. map()
would not convert arbitrary types. It would simply duplicate slices.

map() would not be callable with different types of *a* and *result, *



 

> func main() {
>a := "a" ; aa := "aa"; aaa = "aaa"
>mylen := func(k *string) *int { 
>   rv := len(*k)
>   return 
>}
>map(mylen, []*string{, , }, make([]*int, 3))  // Is this 
> possible?
>
>one := 1; two := 2; three := 3
>myItoA := func(k *int) *string {
>   rv := strconv.Itoa(*k)
>   return 
>}
>map(myItoa, []*int{,,}, make([]*string, 3))  // once 
> more, for profit
>
>map(strconv.Itoa, []*int{}, make([]*float, 1)) // Is this a 
> runtime error?
> }
>




The way to solve this example (slice type conversion), while keeping the 
style, would be to do it in two passes:

First pass: convert []*anything to []interface{}
Second pass: convert []interface{} to []*something_else

//First pass just wraps the values to interface{}:

func wrapvalues(in []*, out *[]interface{}) {
for i:=0; i < len(in), i++ {
*out = append(*out, in[i])
 }
}

//Second pass does the heavy lifting and conversion:

func toslice(convert func(*,interface{}),  in *[]interface{}, out []*) {
for i:=0; i < len(in), i++ {
convert( out[i], in[i])
 }
}

// conversion function from *int to *string

func int_to_str(in interace{}, out *string) {
   var i = in.(int)
   *out = strconv.Itoa(i)
}

// called like this

var originalslice []*int
var intermediate []interface{}
var result []*string = make( []*string, len(originalslice))

wrapvalues(originalslice, )
toslice(int_to_str, , result)


Other solutions:
An one-liner, simply traverse the original slice, and convert elements on 
the go:

func foreach_slice(slice []*, call func(*)) {
for i := range slice {
call(slice[i])
}
}

foreach_slice(as, func(arg *string){var i int; i = len(*arg); bs = 
append(bs,)})

http://tsoh.host/test.html#075b8a23

Reusable conversion routine, is able to convert arbitrary slice to another 
arbitrary slice.
Each element is converted via string and then to the target type
Routine can be called using one-liner and is fully type safe:

slice_via_str_from(as, my_float64_to_string).to(bs, my_string_to_int)

http://tsoh.host/test.html#eaa6317e


>
> And, yeah... the pointers are a bit of trouble.  By the time all of the 
> wrapping and referencing is done, it's only a little easier than just using 
> interface{} everywhere with casts.  If you don't get type safety with this, 
> I feel like the syntactic sugar value is pretty modest.
>
> --- SER
>


I feel that the type safety is preserved

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