date:20180914

Re: [go-nuts] Is it possible to build a module without a hosted repository?

2018-09-14 Thread K Davidson

This seems to work, thanks.

On Friday, September 14, 2018 at 6:38:15 PM UTC-7, Sam Whited wrote:
>
> On Fri, Sep 14, 2018, at 20:32, K Davidson wrote: 
> > Is there a way that I can build my package as a module without having to 
> > host it on the internet? 
>
> I've found myself just making up fake import statements. While you're 
> prototyping it doesn't hurt: 
>
> package main // import "golang.org/totally-official-and-real" 
>
> —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.

Re: [go-nuts] call of non-function C.testc

2018-09-14 Thread amandeep

Hi Ian,
   I did you told, but I could not find --debug=all option for readelf. 
However, there is --debug --all option with readelf. I am attaching the 
output below:

-bash-3.2$ /opt/csw/bin/greadelf --debug --all /b001/_cgo_.o   
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, big endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  REL (Relocatable file)
  Machine:   Sparc
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  2000 (bytes into file)
  Flags: 0x0
  Size of this header:   52 (bytes)
  Size of program headers:   0 (bytes)
  Number of program headers: 0
  Size of section headers:   40 (bytes)
  Number of section headers: 20
  Section header string table index: 17

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk 
Inf Al
  [ 0]   NULL 00 00 00  0  
 0  0
  [ 1] .text PROGBITS 34 14 00  AX  0  
 0  4
  [ 2] .rela.textRELA 000c4c 24 0c 18  
 1  4
  [ 3] .data PROGBITS 48 20 00  WA  0  
 0  8
  [ 4] .bss  NOBITS   68 00 00  WA  0  
 0  1
  [ 5] .rodata.str1.8PROGBITS 68 10 01 AMS  0  
 0  8
  [ 6] .debug_frame  PROGBITS 78 20 00  0  
 0  4
  [ 7] .rela.debug_frame RELA 000c70 18 0c 18  
 6  4
  [ 8] .debug_info   PROGBITS 98 000290 00  0  
 0  1
  [ 9] .rela.debug_info  RELA 000c88 000240 0c 18  
 8  4
  [10] .debug_abbrev PROGBITS 000328 00011d 00  0  
 0  1
  [11] .debug_arangesPROGBITS 000445 20 00  0  
 0  1
  [12] .rela.debug_arang RELA 000ec8 18 0c 18  
11  4
  [13] .debug_line   PROGBITS 000465 000128 00  0  
 0  1
  [14] .rela.debug_line  RELA 000ee0 0c 0c 18  
13  4
  [15] .debug_strPROGBITS 00058d 00017c 01  MS  0  
 0  1
  [16] .comment  PROGBITS 000709 1b 01  MS  0  
 0  1
  [17] .shstrtab STRTAB   000724 aa 00  0  
 0  1
  [18] .symtab   SYMTAB   000af0 000120 10 19  
13  4
  [19] .strtab   STRTAB   000c10 39 00  0  
 0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

Relocation section '.rela.text' at offset 0xc4c contains 3 entries:
 Offset InfoTypeSym.Value  Sym. Name + Addend
  0509 R_SPARC_HI22     .rodata.str1.8 + 0
0004  050c R_SPARC_LO10     .rodata.str1.8 + 0
000c  0e07 R_SPARC_WDISP30      printf + 0

Relocation section '.rela.debug_frame' at offset 0xc70 contains 2 entries:
 Offset InfoTypeSym.Value  Sym. Name + Addend
0014  0617 R_SPARC_UA32     .debug_frame + 0
0018  0217 R_SPARC_UA32     .text + 0

Relocation section '.rela.debug_info' at offset 0xc88 contains 48 entries:
 Offset InfoTypeSym.Value  Sym. Name + Addend
0006  0817 R_SPARC_UA32     .debug_abbrev + 0
000c  0b17 R_SPARC_UA32     .debug_str + 45
0011  0b17 R_SPARC_UA32     .debug_str + 10b
0015  0217 R_SPARC_UA32     .text + 0
0019  0217 R_SPARC_UA32     .text + 14
001d  0a17 R_SPARC_UA32     .debug_line + 0
002b  0b17 R_SPARC_UA32     .debug_str + e3
0032  0b17 R_SPARC_UA32     .debug_str + 13f
0039  0b17 R_SPARC_UA32     .debug_str + 121
0040  0b17 R_SPARC_UA32     .debug_str + 14d
0047  0b17 R_SPARC_UA32     .debug_str + 100
0052  0b17 R_SPARC_UA32     .debug_str + 1f
005e  0b17 R_SPARC_UA32     .debug_str + 1f
006b  0b17 R_SPARC_UA32     .debug_str + 148
007a  0b17 R_SPARC_UA32     .debug_str + de
0089  0b17 R_SPARC_UA32     .debug_str + 162
0098  0b17 R_SPARC_UA32

Re: [go-nuts] Is it possible to build a module without a hosted repository?

2018-09-14 Thread Sam Whited

On Fri, Sep 14, 2018, at 20:32, K Davidson wrote:
> Is there a way that I can build my package as a module without having to 
> host it on the internet?

I've found myself just making up fake import statements. While you're 
prototyping it doesn't hurt:

package main // import "golang.org/totally-official-and-real"

—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] Is it possible to build a module without a hosted repository?

2018-09-14 Thread K Davidson

I appologize if this has been asked before, I tried searching but all the 
posts I could find of a similar nature were asking about dependencies, 
rather than about the module specifically.

Is it possible to have a package as a module without having it hosted 
somewhere (like Github, or other internet endpoint?) 

I often like to prototype ideas locally, but the idea usually isn't worth 
all the effort of making a new repository, and all the work to set up git, 
as most of the time I end up scrapping it. However with GO111MODULE=on, go 
build seems to require a module line that is hosted at a url (ie: 
github.com/kidoda/quikcam) in order to build. With dependencies I can just 
use the -replace directive to point to a local directory, but I can't seem 
to find a way to do the same with the module.

Is there a way that I can build my package as a module without having to 
host it on the internet?

Thanks in advance,

-K

-- 
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] modules and package cyclic dips

2018-09-14 Thread Sameer Ajmani

Go modules can use the listed version or later minor versions. So if B
depends on v1.11 of A, then it can also work with v1.12 of A. Therefore a
valid set of versions for the build is A v1.12 and B v1.3.

On Mon, Sep 10, 2018 at 1:28 AM Scott Cotton  wrote:

> Well, ok.
>
> Did you mean if A v1.12 of a module depends on v1.3 of B which depends on
> v1.11 of A?
>
> So go modules don't actually necessarily depend on the listed
> dependencies?
>
> That is quite counteruintintive to me.
>
> It is much simpler in any case to use acyclic dependencies.
>
> Scott
>
> On 10 September 2018 at 04:25, Sameer Ajmani  wrote:
>
>> I think there's a disconnection between how you and I understand this
>> system works. In a given build, there is only a single version of a module;
>> there cannot be multiple copies, let alone many copies.So if v1.11 of
>> module A depends on v1.3 of module B, which in turn depends on v1.12 of
>> module A, then the build will choose A v1.12. The is only one version of A
>> in the build.
>>
>> On Sun, Sep 9, 2018 at 1:40 PM Scott Cotton  wrote:
>>
>>> Hi Sameer,
>>>
>>> Thanks for asking, here are some thoughts,
>>>
>>> With time, this could create man many many copies of (different
>>> versions) of a module.
>>> this would slow down fetch, storage, compilation, etc potentially a lot,
>>> and it would only
>>> get worse and worse over time.
>>>
>>> if a security patch is applied to the most recent version in a
>>> version-compatible space of
>>> a module that depends on an earlier version of itself, then the security
>>> hole may still exist.
>>> Moreover, if the SCC of module dependencies is outside the control of
>>> the authors of the
>>> module being patched, it seems there is might be no way they could
>>> propagate the patch
>>> without editing history, which violates the very notion of versioning to
>>> begin with.
>>>
>>> The notion of software moving forward by versioning is in part an
>>> increase in reliability,
>>> not just security patches, so I would be frightened to use cyclic
>>> modules even in code
>>> for which I were certain there would be no security patches (like fixed
>>> memory, known cpu bounds
>>> math algorithms for example)
>>>
>>> Other than that, it is to me very confusing and counter-intuitive that a
>>> version of some software
>>> depend on a previous version of itself.  Maybe I'm missing something in
>>> the modules
>>> specification or vision, and maybe, (even hopefully) I am wrong about
>>> these concerns.
>>>
>>> I could list more related ideas, but given that I might be wrong I'll
>>> leave it at that.
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>>
>>> On 9 September 2018 at 19:19, Sameer Ajmani  wrote:
>>>
 If a module depends on an earlier version itself, and successive
 versions are backwards compatible, why is it not OK for the current version
 to satisfy that dependency?

 On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton  wrote:

> Hi Sameer,
>
> When I had a module self-dependency, I considered the fact that it
> worked a bug.  I had not followed
> closely enough til this discussion to think of it as expected.
>
> As someone who has a tendency to often ask themself: "worse case how
> can this be a problem?"
>
> the list is indeed long and severe for modules which depend on
> themselves backwards in time.
>
> For cyclic dependencies which are somehow synchronised so that there
> is no backwards in time
> propagation, my impression would be "that's complicated", but I can't
> see offhand how it would be
> as problematic as backward in time self dependencies.
>
> Scott
>
>
>
> On 9 September 2018 at 18:38, Sameer Ajmani  wrote:
>
>> With respect to errors, I'm asking how things failed when you had a
>> cyclic module dependency. My expectation is that this should just work. 
>> If
>> your module 0.12 has a dependency on itself with min version 0.11, then
>> 0.12 satisfies that dependency (as long as it's following the import
>> compatibility rule, which isn't necessarily expected for pre-1.0 
>> modules).
>>
>> On Sun, Sep 9, 2018 at 9:10 AM Scott Cotton  wrote:
>>
>>> Hi Sameer,
>>>
>>> I don't know what is considered an error and not an error with
>>> cyclic module dependencies.
>>>
>>> Honestly, it makes my head hurt and simply requires too much thought
>>> that I'd rather spend on the code.
>>>
>>> For example, I don't want to think what will happen to some SCC in a
>>> module dependency graph after
>>> a decade of development, in particular if a module can depend on an
>>> earlier version of itself.
>>>
>>> Scott
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 9 September 2018 at 14:19, Sameer Ajmani 
>>> wrote:
>>>
 Are you seeing errors when there are cyclic module dependencies? As
 I recall, cyclic dependencies

[go-nuts] Re: setting text color in freetype library (https://github.com/golang/freetype)

2018-09-14 Thread diarselimi92

just set the Src to the color you want and it will change the color 
fg := image.Black
d := {
   Dst: rgba,
   Src: fg,  //<- 
Face: truetype.NewFace(f, {
Size: *size,
DPI: *dpi,
Hinting: h,
}),
   }



On Wednesday, August 1, 2018 at 6:38:47 PM UTC+2, zakaria amine wrote:
>
> Hi, 
>
> I am trying to set the color for the text drwan using freetype library 
> based on this example: 
> https://github.com/golang/freetype/blob/master/example/freetype/main.go
>
> I tried different combinations without luck. 
>
>
> Anybody having used this library before?
>
>
> Thanks.
>
> Zakaria 
>
>
>

-- 
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] A simplified generics constraint system.

2018-09-14 Thread alanfo

Thanks for your comments, Jonathan.

I did in fact deal with all the cases you mention in my 'fuller' proposal:

https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251

where I'd used a device to restrict the built-ins to just one following 
criticism by Ian that an earlier proposal I'd made had too many of them (it 
had 14). 

However, I decided instead to restrict the built-ins to a reasonable number 
(6) in the simplified proposal which meant that many of them had to go.

The example you mentioned was taken from the draft design paper and didn't 
compile for int8 there either. ohir has already made the point about 
overflow being a problem when dealing with integer types and, in practice, 
you shouldn't write code under any proposal unless you're sure that it will 
compile for all applicable types. It might help if type assertions could be 
applied to type parameters so you could test for 'awkward' types.

One thing that has been mentioned as a possible new feature in Go 2 is to 
change the 'int' and 'uint' types from being platform specific (32 or 64 
bit) to arbitrary precision (i.e. big.Int). This would then get rid of 
overflow problems when converting between integer types once and for all.

Personally, I hope this happens though I'd prefer 'int' and 'uint'  to be 
left as they are (on efficiency grounds) and introduce a new type - say 
'intz' - which would be arbitrary precision. In the circumstances, an 
unsigned version of this wouldn't be needed.

Alan   

On Friday, September 14, 2018 at 11:24:25 PM UTC+1, Jonathan Amsterdam 
wrote:
>
> I'm sympathetic to the general idea, but I don't think this quite does it. 
> In addition to introducing a bunch of new names, it's not expressive enough:
>
> - You can't express "string or []byte", as you note. There are many 
> algorithms where this would be useful. See the strings and bytes packages 
> for a start.
>
> - You can't support types that have bool and string as underlying types. 
> People often define their own string type, usually just for clarity. You 
> say they can just convert to string, but they can't if they have a 
> []MyString or the like. It's also confusingly inconsistent to support 
> underlying types for numbers but not bool or string.
>
> - Your convert example excludes complex types. You have no way to express 
> "any numeric type," which is what that example needs.
>
> - You can't get finer-grained than Integer. That excludes some code. For 
> instance, your Add1K example doesn't work, because it won't compile if T = 
> int8. It's not clear how important this is in practice.
>
>

-- 
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: net/http client: MaxConcurrentStreams exceeded

2018-09-14 Thread Eddie Shvartsman

Correction: current default client MaxConcurrentStreams is 1,000 

 

On Friday, September 14, 2018 at 4:47:27 PM UTC-5, Eddie Shvartsman wrote:
>
> Greetings! 
> We are seeing a problem at high RPS where repeated http2 calls using the 
> same Transport (reusing as recommended 
>  in go docs) are exceeding 
> the server's  MAX_CONCURRENT_STREAMS setting, resulting in a protocol 
> error. The server appears to be setting MAX_CONCURRENT_STREAMS to 100 as 
> indicated in this http2 debug output...
>
> 2018/09/13 11:18:04 http2: Framer 0xc42037b180: wrote DATA 
> flags=END_STREAM stream=1 len=0 data=""
> 2018/09/13 11:18:04 http2: Framer 0xc42037b180: read SETTINGS len=30, 
> settings: HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=100, 
> INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=16384
> 2018/09/13 11:18:04 http2: Transport received SETTINGS len=30, settings: 
> HEADER_TABLE_SIZE=4096, *MAX_CONCURRENT_STREAMS=100*, 
> INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=16384
> ...
> 2018/09/13 11:18:49 http2: Transport encoding header "content-type" = 
> "application/json"
> 2018/09/13 11:18:49 http2: Transport encoding header "content-length" = 
> "1547"
> 2018/09/13 11:18:49 http2: Transport encoding header "accept-encoding" = 
> "gzip"
> 2018/09/13 11:18:49 http2: Transport encoding header "user-agent" = 
> "Go-http-client/2.0"
> 2018/09/13 11:18:49 http2: Framer 0xc42037b180: wrote HEADERS 
> flags=END_HEADERS stream=17191 len=56
> 2018/09/13 11:18:49 http2: Transport readFrame error on conn 0xc420418e00: 
> (http.http2ConnectionError) connection error: PROTOCOL_ERROR
> 2018/09/13 11:18:49 http2: Framer 0xc42037b180: wrote GOAWAY len=8 
> LastStreamID=0 ErrCode=PROTOCOL_ERROR Debug=""
>
> If we reduce the RPS to <100, the error does not occur. 
>
> My modest understand of the protocol and how the go http client *should* 
> work is that the client and server negotiate MaxConcurrentStreams. My read 
> of the code is that the client's default is 250 streams; however, that 
> should be negotiated down to 100, given this is the maximum the server 
> supports (is that right?). My understanding of current behavior is that the 
> client should block if MaxConcurrentStreams is exceeded. 
>
> Any insights or help would be greatly appreciated. 
>

-- 
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] Contracts and fused multiply add

2018-09-14 Thread jimmy frasche

If the contract further specified that the type must be ordered
without restricting it to just floating-point you could feature test

var d T = 3
if d/2 != 1 {
  // T is floatX
  if unsafe.Sizeof(d)  == 4 {
// float32
  } else {
// float64
  }
}

Similarly, you could test for unsigned with

var z T
if z - 1 > 0 {
  // T is uintX
} else {
  // T is intX or floatX
}

In both cases you have to kick out the complex numbers. Combined you
have a means of classifying the properties of the types that satisfy a
basic ordered arithmetic contract without having to use reflection or
unsafe.

Not especially readable, but it could be pulled out into a generic predicate:

contract Number(t T) {  t - t < t }

const (
  Int = iota
  Uint
  Float
)

func Kind(type T Number)(_ T) int {
  if T(3)/2 != 1 {
return Float
  } else if T(0) - 1 > 0 {
return Uint
  }
  return Int
}

With that you could write the must-FMA version as:

func maMustFMA(type T Number)(a, b, c T) T {
if Kind(a) == Float {
  return T(math.Fma(float64(a), float64(b), float64(c)))
}
return a*b + c
  }
}

On Wed, Sep 12, 2018 at 11:08 AM jimmy frasche  wrote:
>
> On Wed, Sep 12, 2018 at 11:02 AM Ian Lance Taylor  wrote:
> > You could perhaps choose an implementation based on unsafe.Sizeof.
> > But I agree that it's pretty ugly.
>
> Only if the contract were t * t + t < .1
>
> Part of the construction was that it accepted more than just floating points.

-- 
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] A simplified generics constraint system.

2018-09-14 Thread Jonathan Amsterdam

I'm sympathetic to the general idea, but I don't think this quite does it. 
In addition to introducing a bunch of new names, it's not expressive enough:

- You can't express "string or []byte", as you note. There are many 
algorithms where this would be useful. See the strings and bytes packages 
for a start.

- You can't support types that have bool and string as underlying types. 
People often define their own string type, usually just for clarity. You 
say they can just convert to string, but they can't if they have a 
[]MyString or the like. It's also confusingly inconsistent to support 
underlying types for numbers but not bool or string.

- Your convert example excludes complex types. You have no way to express 
"any numeric type," which is what that example needs.

- You can't get finer-grained than Integer. That excludes some code. For 
instance, your Add1K example doesn't work, because it won't compile if T = 
int8. It's not clear how important this is in practice.

-- 
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] A simplified generics constraint system.

2018-09-14 Thread alan . fox6

Well, I can't speak for the other simpler proposals but for my own there's 
very little to learn - just six built-ins where it's pretty obvious what 
they mean from their names and the rest is (in effect) just checking that a 
type satisfies a certain interface or, if it's a struct, has certain 
fields. If this can't express what you need, then you can't do it.

There was only one example in the draft design and overview papers which it 
couldn't cope with - the one which required the type to be either a string 
or a byte slice. All the rest could be dealt with as easily or more easily.

Having read all your past papers, I realize of course how long you've been 
working on this and wouldn't have come up now with the design you have if 
you didn't believe it was the best one for taking generics forward. 

So I really hope you can get the draft design to work since I, for one, 
would love to have generics even if the constraint system is more 
complicated than I would like. If you can't get it to work, then a simpler 
design would still be comprehensive enough for many of us.

Alan

On Friday, September 14, 2018 at 9:24:20 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Sep 14, 2018 at 10:47 AM,  > 
> wrote: 
> > 
> > The problem is that many people think the current draft design is too 
> > complex and I haven't seen a plausible suggestion from anyone (myself 
> > included) which would be appreciably simpler but as comprehensive, or 
> nearly 
> > so. 
> > 
> > This is why I'd concluded that, if a system could be devised which was 
> > simple but nonetheless addressed 90% of the use cases for generics, it 
> might 
> > be good enough. 
>
> We've been working on this for years.  It's far too soon to give up on 
> a reasonably complete solution. 
>
> And, as I tried to say earlier, a 90% solution has its own 
> complexities.  If the only reason to reject the design draft is 
> complexity, then it's not obvious that a 90% solution is really 
> simpler. 
>
> And, of course, we're only really going to understand the complexity 
> of the design draft when we can try writing real code that uses it. 
>
> Ian 
>

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

Re: [go-nuts] call of non-function C.testc

2018-09-14 Thread Ian Lance Taylor

On Fri, Sep 14, 2018 at 2:16 PM,   wrote:
> It would be the same. Please see below.
>
> -bash-3.2$ gcc --version
> gcc (GCC) 8.2.1 20180814
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Hmmm, not sure what is happening.  Especially not sure why it would
fail on Solaris 10 but work on Solaris 11, as you suggested earlier.
I have a feeling this is going to be some configuration error
somewhere.

I guess the next step in debugging would be to run this command,
copied from your earlier message, and then look at x.o to see how
__cgo__0 is defined in the debug info.  If you have the readelf
program from the GNU binutils you could run readelf --debug=all x.o.

Ian


gcc -w -Wno-error -o x.o -gdwarf-2 -c -xc -I /b001/ -g -O2 - < /* for ptrdiff_t and size_t below */

/* Define intgo when compiling with GCC.  */
typedef ptrdiff_t intgo;

typedef struct { const char *p; intgo n; } _GoString_;
typedef struct { char *p; intgo n; intgo c; } _GoBytes_;
_GoString_ GoString(char *p);
_GoString_ GoStringN(char *p, int l);
_GoBytes_ GoBytes(void *p, int n);
char *CString(_GoString_);
void *CBytes(_GoBytes_);
void *_CMalloc(size_t);

__attribute__ ((unused))
static size_t _GoStringLen(_GoString_ s) { return s.n; }

__attribute__ ((unused))
static const char *_GoStringPtr(_GoString_ s) { return s.p; }
#line 3 "/export/home/amandeep/sol10.go"

#include 

void testc() {
printf("Hello cgo");
}

#line 1 "cgo-generated-wrapper"
#line 1 "cgo-dwarf-inference"
__typeof__(testc) *__cgo__0;
long long __cgodebug_ints[] = {
0,
1
};
double __cgodebug_floats[] = {
0,
1
};
EOF

-- 
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/http client: MaxConcurrentStreams exceeded

2018-09-14 Thread Eddie Shvartsman

Greetings! 
We are seeing a problem at high RPS where repeated http2 calls using the 
same Transport (reusing as recommended 
 in go docs) are exceeding 
the server's  MAX_CONCURRENT_STREAMS setting, resulting in a protocol 
error. The server appears to be setting MAX_CONCURRENT_STREAMS to 100 as 
indicated in this http2 debug output...

2018/09/13 11:18:04 http2: Framer 0xc42037b180: wrote DATA flags=END_STREAM 
stream=1 len=0 data=""
2018/09/13 11:18:04 http2: Framer 0xc42037b180: read SETTINGS len=30, 
settings: HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=100, 
INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=16384
2018/09/13 11:18:04 http2: Transport received SETTINGS len=30, settings: 
HEADER_TABLE_SIZE=4096, *MAX_CONCURRENT_STREAMS=100*, 
INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=16384
...
2018/09/13 11:18:49 http2: Transport encoding header "content-type" = 
"application/json"
2018/09/13 11:18:49 http2: Transport encoding header "content-length" = 
"1547"
2018/09/13 11:18:49 http2: Transport encoding header "accept-encoding" = 
"gzip"
2018/09/13 11:18:49 http2: Transport encoding header "user-agent" = 
"Go-http-client/2.0"
2018/09/13 11:18:49 http2: Framer 0xc42037b180: wrote HEADERS 
flags=END_HEADERS stream=17191 len=56
2018/09/13 11:18:49 http2: Transport readFrame error on conn 0xc420418e00: 
(http.http2ConnectionError) connection error: PROTOCOL_ERROR
2018/09/13 11:18:49 http2: Framer 0xc42037b180: wrote GOAWAY len=8 
LastStreamID=0 ErrCode=PROTOCOL_ERROR Debug=""

If we reduce the RPS to <100, the error does not occur. 

My modest understand of the protocol and how the go http client *should* 
work is that the client and server negotiate MaxConcurrentStreams. My read 
of the code is that the client's default is 250 streams; however, that 
should be negotiated down to 100, given this is the maximum the server 
supports (is that right?). My understanding of current behavior is that the 
client should block if MaxConcurrentStreams is exceeded. 

Any insights or help would be greatly appreciated. 

-- 
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] call of non-function C.testc

2018-09-14 Thread amandeep

It would be the same. Please see below.

-bash-3.2$ gcc --version
gcc (GCC) 8.2.1 20180814
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


On Friday, September 14, 2018 at 1:34:20 PM UTC-7, Ian Lance Taylor wrote:
>
> On Fri, Sep 14, 2018 at 1:40 AM,  > 
> wrote: 
> > 
> > oh yes, I am using gccgo. I configured gccgo from source. Below is the 
> go 
> > version output: 
> > go version go1.10.3 gccgo (GCC) 8.2.1 20180814 solaris/sparc 
>
> What version of GCC are you using?  What is the output of `gcc --version`? 
>
> Ian 
>

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

Re: [go-nuts] call of non-function C.testc

2018-09-14 Thread Ian Lance Taylor

On Fri, Sep 14, 2018 at 1:40 AM,   wrote:
>
> oh yes, I am using gccgo. I configured gccgo from source. Below is the go
> version output:
> go version go1.10.3 gccgo (GCC) 8.2.1 20180814 solaris/sparc

What version of GCC are you using?  What is the output of `gcc --version`?

Ian

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

Re: [go-nuts] A simplified generics constraint system.

2018-09-14 Thread Ian Lance Taylor

On Fri, Sep 14, 2018 at 10:47 AM,   wrote:
>
> The problem is that many people think the current draft design is too
> complex and I haven't seen a plausible suggestion from anyone (myself
> included) which would be appreciably simpler but as comprehensive, or nearly
> so.
>
> This is why I'd concluded that, if a system could be devised which was
> simple but nonetheless addressed 90% of the use cases for generics, it might
> be good enough.

We've been working on this for years.  It's far too soon to give up on
a reasonably complete solution.

And, as I tried to say earlier, a 90% solution has its own
complexities.  If the only reason to reject the design draft is
complexity, then it's not obvious that a 90% solution is really
simpler.

And, of course, we're only really going to understand the complexity
of the design draft when we can try writing real code that uses it.

Ian

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

Re: [go-nuts] Announcing a Fyne GUI toolkit

2018-09-14 Thread Andrew Williams

Hi,

Thanks. There is an efl opengl driver which we could utilise instead of the 
sofware driver with a small change - if your hardware supports it.
It would also be possible to provide an alternative driver that 
communicates directly with opengl, but this is a lot more work.
I have designed the backend to be loosely coupled so that other options 
could be provided (i.e. we could write a webgl/webasm driver or a native 
mobile one). I am writing up documentation about the requirements for 
drivers but it is basically a canvas that can draw 
line/rect/text/images(including svg) and some basic window handling.

Current drivers are "desktop" which uses EFL and "test" used for in-memory 
unit testing of the widgets etc.

I hope that helps,
Andrew

On Friday, 14 September 2018 18:57:14 UTC+1, Ian Davis wrote:
>
>
> On Fri, 14 Sep 2018, at 6:02 PM, Andrew Williams wrote:
>
>
> It's now well into development and ready for people to get involved. There 
> is a long way to go but it feels like a solid base.
> Instructions for getting started, if you need them, are at 
> https://github.com/fyne-io/bootstrap/blob/master/README.md .
> If you want to know more we're also in the #fyne channel on the gopher 
> Slack server.
>
>
> This looks very impressive. 
>
> Is it possible to interface it with opengl or vulcan?
>

-- 
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] goey - Declarative, cross-platform GUIs

2018-09-14 Thread robert engels

Robert,

You might want to look at https://github.com/fyne-io/fyne 


R

> On Sep 11, 2018, at 8:24 AM, Robert Johnstone  wrote:
> 
> Hello,
> 
> I've taken a previous comment about screenshots seriously.  They will be up 
> in a little bit.
> 
> The layout widgets are actually all platform-independent.  Initially, I was 
> relying on the layout widgets in GTK, but it was too hard to get feature 
> parity.  For a OSX port, layout will be easy, but it won't match any platform 
> specific guidelines without more work.
> 
> - Robert
> 
> 
> On Monday, 10 September 2018 14:25:05 UTC-4, Robert Engels wrote:
> I wonder about the design, and how it will work. Since it uses the native 
> components behind the scene, you will get great fidelity but the layout can 
> be very difficult to accomplish.
> 
> This is why Java’s Swing uses only a single native component (Canvas), and 
> does all of the text/drawing/event handling in Java.
> 
> I wouldn’t think an OSX port would be that hard, but before investing the 
> effort, I’d love to see the same ‘demo program’ run side by side between 
> linux and windows to check the fidelity - because this could be a show 
> stopped.
> 
> Any plans for a more involved demo application? 
> 
> 
>> On Sep 10, 2018, at 12:06 PM, Robert Johnstone > 
>> wrote:
>> 
>> Hello,
>> 
>> There isn't a porting guide, but I can provide some guidance.  
>> 
>> 1) In goey/base, copy widget_linux.go to widget_darwin.go to create stubs 
>> for Control and NativeElement, but don't worry about any implementation yet.
>> 
>> 2) In goey, temporarily remove all of the files for the controls.  You need 
>> to implement three functions, 'run', 'do', and 'loop' to manage the GUI 
>> event loop.  Actually, if you look at the code for WIN32 and for GTK, you 
>> might find you that you don't need both 'run' and 'loop'.
>> 
>> 3) In goey, implement Window for darwin.  Again, you can stub out most of 
>> the methods.  There is a example, ExampleNewWindow, which if you replace 
>> {} with nil, provide a minimal example of showing a window.  
>> 
>> 4) At that point, you should have most of the difficult work done.  The next 
>> steps will be to port over the controls one-by-one, but the infrastructure 
>> will be in place, so that work con be done a small piece at a time.
>> 
>> Let me know if that helps, or if you have any other questions.
>> 
>> Robert
>>  
>> 
>> On Friday, 7 September 2018 11:05:23 UTC-4, Robert Engels wrote:
>> I might be able to do it if there was a “porting guide” that describes what 
>> needs to be - at least in general terms - rather than just looking at the 
>> existing code and making a guess
>> 
>>> On Sep 7, 2018, at 10:01 AM, Robert Johnstone gmail.com 
>>> > wrote:
>>> 
>>> Hello,
>>> 
>>> I would be very happy to support macOS, but unfortunately I don't have any 
>>> experience on that platform.  Sorry, no concrete plans.
>>> 
>>> - Robert
>>> 
>>> 
>>> 
>>> On Thursday, 6 September 2018 19:44:52 UTC-4, Richard Wilkes wrote:
>>> Hi, Robert.
>>> 
>>> Do you have any plans to add macOS support to this?
>>> 
>>> - Rich
>>> 
>>> On Wednesday, September 5, 2018 at 9:07:41 PM UTC-7, Robert Johnstone wrote:
>>> This is an initial announcement of goey, a package for declarative, 
>>> cross-platform GUIs.  The range of controls, their supported properties and 
>>> events, should roughly match what is available in HTML.  However, 
>>> properties and events may be limited to support portability.  Additionally, 
>>> styling of the controls will be limited, with the look of controls matching 
>>> the native platform.
>>> 
>>> A minimal example of a complete application can be found at 
>>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton 
>>> .
>>> 
>>> * README:  https://bitbucket.org/rj/goey/src/default/README.md 
>>> 
>>> * godoc: https://godoc.org/bitbucket.org/rj/goey 
>>> 
>>> 
>>> Feedback welcome.
>>> 
>>> 
>>> -- 
>>> 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

Re: [go-nuts] Announcing a Fyne GUI toolkit

2018-09-14 Thread Ian Davis


On Fri, 14 Sep 2018, at 6:02 PM, Andrew Williams wrote:
> 
> It's now well into development and ready for people to get involved.
> There is a long way to go but it feels like a solid base.> Instructions for 
> getting started, if you need them, are at
> https://github.com/fyne-io/bootstrap/blob/master/README.md .> If you want to 
> know more we're also in the #fyne channel on the gopher
> Slack server.
This looks very impressive. 

Is it possible to interface it with opengl or vulcan?

-- 
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] A simplified generics constraint system.

2018-09-14 Thread alan . fox6

Ian,

Ian,

Well, if a simple comprehensive solution can be found, then I'm sure we'll 
all be in favor of it.

The problem is that many people think the current draft design is too 
complex and I haven't seen a plausible suggestion from anyone (myself 
included) which would be appreciably simpler but as comprehensive, or 
nearly so. 

This is why I'd concluded that, if a system could be devised which was 
simple but nonetheless addressed 90% of the use cases for generics, it 
might be good enough.

Even simpler solutions are better than some languages have. Having 
programmed in C# for many years, I was frustrated that you couldn't write 
useful generic functions for numerics at all and, even though they've added 
a lot of stuff lately, you still can't. As Robert has just mentioned, Java 
generics are far from perfect also.

Alan


On Friday, September 14, 2018 at 6:16:47 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Sep 14, 2018 at 3:32 AM, alanfo > 
> wrote: 
> > 
> > I was then brought back to reality by this post by Robert Engels in the 
> > 'Generics - Why contracts?' thread: 
> > 
> > "As I’ve said elsewhere, a SIMPLE to use and understand solution that 
> covers 
> > 90% is better than a complex one to cover 100% IMO, and fits in well 
> with 
> > the rest of Go design. Go leaves out a lot - and it's a good choice." 
>
> I've seen several people express this idea in different ways.  I want 
> to challenge it. 
>
> I agree that simple is essential.  That is not in dispute.  If the 
> current design draft is too complex, we can not adopt it as is. 
>
> However, it does not follow that a 90% solution, whatever that is 
> taken to mean, is acceptable. 
>
> A 90% solution is frustrating, in exactly the same way that some 
> people find the fact that Go currently lacks generics to be 
> frustrating.  That is, for generic programming, Go is already a 90% 
> solution.  Some people find the missing 10% to be annoying, 
> frustrating, and confusing.  This will continue to happen if we add 
> another 90% solution to the problem. 
>
> A 90% solution is complex, because by definition it means that there 
> are special cases, complex cases, that do not work as expected. 
> Everybody who learns Go has to learn not only how to implement the 
> 90%, they also have to learn where that 90% stops. 
>
> A 90% solution is not orthogonal, by definition.  Go is in some ways 
> not very orthogonal, but it is orthogonal in this way: all concepts in 
> Go that can be meaningfully used together, work together as one would 
> expect them to.  There are no missing elements. 
>
> When considering changes to the Go language, please do not settle for 
> a 90% solution. 
>
> Ian 
>

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

Re: [go-nuts] A simplified generics constraint system.

2018-09-14 Thread robert engels

I think you hit the nail on the head, Go already uses a 90% solution in many 
areas, and that is why it is both simple and useful.

In the case of generics programming though, it is 0% (unless you count 
interface{} as being generic - I don’t)

Java went for over a decade without generics, and many fought to exclude it 
even then, still there were a lot of proposals, and type-erasure was chosen for 
the least impact on the language and stdlibs, which left some things to runtime 
checking. I would argue the Java solution is 90% generics. It doesn’t do 
everything, and some things are difficult but doable (like generic arrays).

It might be constructive for all of the generics proponents for Go to go back 
and read the Java language developers/arguments on generics.

This may be very helpful as well 
https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics



> On Sep 14, 2018, at 12:16 PM, Ian Lance Taylor  wrote:
> 
> On Fri, Sep 14, 2018 at 3:32 AM, alanfo  wrote:
>> 
>> I was then brought back to reality by this post by Robert Engels in the
>> 'Generics - Why contracts?' thread:
>> 
>> "As I’ve said elsewhere, a SIMPLE to use and understand solution that covers
>> 90% is better than a complex one to cover 100% IMO, and fits in well with
>> the rest of Go design. Go leaves out a lot - and it's a good choice."
> 
> I've seen several people express this idea in different ways.  I want
> to challenge it.
> 
> I agree that simple is essential.  That is not in dispute.  If the
> current design draft is too complex, we can not adopt it as is.
> 
> However, it does not follow that a 90% solution, whatever that is
> taken to mean, is acceptable.
> 
> A 90% solution is frustrating, in exactly the same way that some
> people find the fact that Go currently lacks generics to be
> frustrating.  That is, for generic programming, Go is already a 90%
> solution.  Some people find the missing 10% to be annoying,
> frustrating, and confusing.  This will continue to happen if we add
> another 90% solution to the problem.
> 
> A 90% solution is complex, because by definition it means that there
> are special cases, complex cases, that do not work as expected.
> Everybody who learns Go has to learn not only how to implement the
> 90%, they also have to learn where that 90% stops.
> 
> A 90% solution is not orthogonal, by definition.  Go is in some ways
> not very orthogonal, but it is orthogonal in this way: all concepts in
> Go that can be meaningfully used together, work together as one would
> expect them to.  There are no missing elements.
> 
> When considering changes to the Go language, please do not settle for
> a 90% solution.
> 
> Ian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] A simplified generics constraint system.

2018-09-14 Thread Ian Lance Taylor

On Fri, Sep 14, 2018 at 3:32 AM, alanfo  wrote:
>
> I was then brought back to reality by this post by Robert Engels in the
> 'Generics - Why contracts?' thread:
>
> "As I’ve said elsewhere, a SIMPLE to use and understand solution that covers
> 90% is better than a complex one to cover 100% IMO, and fits in well with
> the rest of Go design. Go leaves out a lot - and it's a good choice."

I've seen several people express this idea in different ways.  I want
to challenge it.

I agree that simple is essential.  That is not in dispute.  If the
current design draft is too complex, we can not adopt it as is.

However, it does not follow that a 90% solution, whatever that is
taken to mean, is acceptable.

A 90% solution is frustrating, in exactly the same way that some
people find the fact that Go currently lacks generics to be
frustrating.  That is, for generic programming, Go is already a 90%
solution.  Some people find the missing 10% to be annoying,
frustrating, and confusing.  This will continue to happen if we add
another 90% solution to the problem.

A 90% solution is complex, because by definition it means that there
are special cases, complex cases, that do not work as expected.
Everybody who learns Go has to learn not only how to implement the
90%, they also have to learn where that 90% stops.

A 90% solution is not orthogonal, by definition.  Go is in some ways
not very orthogonal, but it is orthogonal in this way: all concepts in
Go that can be meaningfully used together, work together as one would
expect them to.  There are no missing elements.

When considering changes to the Go language, please do not settle for
a 90% solution.

Ian

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

Re: [go-nuts] Re: Go 2 error-handling counter-proposal: returnfrom

2018-09-14 Thread roger peppe

On 14 September 2018 at 17:45, Scott Pakin  wrote:
> On Friday, September 14, 2018 at 12:30:46 AM UTC-6, rog wrote:
>>
>> What about here, where the call stack associated with g is still live?
>>
>>  func g() error {
>>  Top:
>> f := func(err error) { returnfrom Top, nil }
>> c := make(chan struct{})
>> go func() {
>> defer close(c)
>> f(nil)
>> }()
>> <-c
>> }
>>
>> ?
>
>
> Yeah, in my proposal, under Issues, I do mention that the interaction with
> goroutines needs to be thought through.
>
> With respect to your example, I hope we can all agree that it would be odd
> and un-Go-like for the goroutine to cause g to return, right?  Hence, I'd
> argue that the best solution would be to generate an error at compile time.
> "I see that the evaluation of an anonymous function is being passed to go.
> That function calls f.  f lexically includes a returnfrom.  The returnfrom
> lexically refers to a label, Top, that's outside the anonymous function.
> Error!"  I'm not positive the compiler can do that in all cases, but I'd
> think a conservative approach ought to work.  That is, if an anonymous
> function might call a function that might returnfrom an invalid location,
> the compiler should still issue an error message.  I can't imagine such
> conservativism causing headaches for real code, only for contrived examples.
>
> If it's really not possible to make compile-time detection work, I'd say
> that the returnfrom in f should exit the goroutine but not return its
> argument from g.  This is consistent with the case of returning from a
> continuation that's no longer live.

I see that it's possible to make rules that might work. But it's
fairly clear to me that this returnfrom statement is not an
*orthogonal* feature in the way that Go strives to make features
orthogonal to one another. It uses function values, but you can't use
those values in the way that all other function values can be used in
Go. You have to use them in a very stylised way for it to be useful,
with a bunch of fairly arbitrary rules, which to me says that this
doesn't fit well with the language, I'm afraid. I much prefer the
original draft proposal.

  cheers,
rog.


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

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

Re: [go-nuts] Re: Go 2 error-handling counter-proposal: returnfrom

2018-09-14 Thread Scott Pakin

On Friday, September 14, 2018 at 12:30:46 AM UTC-6, rog wrote:
>
> What about here, where the call stack associated with g is still live?
>
>  func g() error {
>  Top:
> f := func(err error) { returnfrom Top, nil }
> c := make(chan struct{})
> go func() {
> defer close(c)
> f(nil)
> }()
> <-c
> }
>
> ?
>

Yeah, in my proposal, under Issues 
, I 
do mention that the interaction with goroutines needs to be thought through.

With respect to your example, I hope we can all agree that it would be odd 
and un-Go-like for the goroutine to cause g to return, right?  Hence, I'd 
argue that the best solution would be to generate an error at compile 
time.  "I see that the evaluation of an anonymous function is being passed 
to go.  That function calls f.  f lexically includes a returnfrom.  The 
returnfrom lexically refers to a label, Top, that's outside the anonymous 
function.  Error!"  I'm not positive the compiler can do that in all cases, 
but I'd think a conservative approach ought to work.  That is, if an 
anonymous function *might* call a function that *might* returnfrom an 
invalid location, the compiler should still issue an error message.  I 
can't imagine such conservativism causing headaches for real code, only for 
contrived examples.

If it's really not possible to make compile-time detection work, I'd say 
that the returnfrom in f should exit the goroutine but not return its 
argument from g.  This is consistent with the case of returning from a 
continuation that's no longer live.

— Scott

-- 
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 simplified generics constraint system.

2018-09-14 Thread alan . fox6

Thanks for those comments, guys.

I've responded to them in the same place.

-- 
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] A simplified generics constraint system.

2018-09-14 Thread Eric S. Raymond

alanfo :
> Any comments or constructive criticism are of course welcome.

I applaud this step in the direction of simplicity.

I've left a more specific comment on the issue.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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] Binary module and security reasons

2018-09-14 Thread Vitold S

Hello my friends,

Right now I review go ui  module ( https://github.com/andlabs/ui ) and 
compile example and happy that I can create cross platofrm UI application 
without HTML engine involving.
But little later when I start research module I found compile and linking 
with binary *.a files under platforms. It look like speedup compilation but 
may contain binary blob and proprietary firmware
or some unsecure code.

Right now I fell that Go wery young and designeless bridge between C and 
Go. I happy to see that source code on C compile with Go module but it 
require create some thing like make scenarios.

Can we ask Rob about ideas to simplify and safe all our from using unsigned 
*.a binary compilation.

P.S. Main my idea is get a simple way to excange executing between Go and C 
source code.

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: using go modules replace with old repos

2018-09-14 Thread John Shahid



Ping.

John Shahid  writes:

> Hi all,
>
> Is there a way to use the go module `replace' directive for packages
> that don't have go.mod yet ? I tried doing that and I get the following
> error:
>
>> go: parsing ../pkg/go.mod: open /path/to/pkg/go.mod: no such file or
>> directory
>
> According to https://github.com/golang/go/issues/24110 it looks like
> this is the intended behavior.  My question is why the go tool (e.g. go
> get) can deal with such package when downloading it from github and
> could give it a pseudo version without a go.mod file but refuses to when
> the source code is local.
>
> I'm happy to construct a sample github project to repro the issue if
> that is needed.
>
> Thanks,
>
> -js

-- 
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] A simplified generics constraint system.

2018-09-14 Thread alan . fox6

Well, it's easy enough if you check that it's a non-negative integer to 
start with :)

If it's negative, you'd have to decide what to do - return an error, panic 
or circumvent the problem in some other way.

Alan

On Friday, September 14, 2018 at 1:40:41 PM UTC+1, ohir wrote:
>
> On Fri, 14 Sep 2018 03:32:09 -0700 (PDT) 
> alanfo > wrote: 
>   
> > https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab 
> > 
> > Any comments or constructive criticism are of course welcome. 
>
> > https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab 
> > " it is easy enough to convert between signed and unsigned integers so I 
> > don't think this is an important enough use case to justify its 
> inclusion." 
>
> Easy? 
>
> https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
>  
> https://play.golang.org/p/wZh8gv47wjz Play with sized ;) 
>
> CGG: https://github.com/ohir/gonerics 
>
> -- 
> 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.

[go-nuts] A new API for modular static analysis

2018-09-14 Thread 'Alan Donovan' via golang-nuts

[bcc: golang-{dev,nuts}]

I've been working on a common interface for modular static analysis of Go
packages, and have built prototypes of several drivers, including a
replacement for the existing standalone 'vet' command and for the
implementation of 'go vet'.

Please read the code and doc and let me know what you think.

cheers
alan

Code https://go-review.googlesource.com/c/tools/+/134935
Doc
https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk

-- 
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] A new API for modular static analysis

2018-09-14 Thread 'Alan Donovan' via golang-nuts

[bcc: golang-{dev,nuts}]

I've been working on a common interface for modular static analysis of Go
packages, and have built prototypes of several drivers, including a
replacement for the existing standalone 'vet' command and for the
implementation of 'go vet'.

Please read the code and doc and let me know what you think.

cheers
alan

Code https://go-review.googlesource.com/c/tools/+/134935
Doc
https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk

-- 
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] Generics - Min challenge

2018-09-14 Thread Jesper Louis Andersen

On Wed, Sep 12, 2018 at 4:49 PM Wojciech S. Czarnecki 
wrote:

>
> This is not metaprogramming!
>
> Every and each statement is written by the human author in plain Go
> and no code is produced by the program itself.
>
>
The key of metaprogramming is the ability to treat code as data which can
be manipulated. That is, it gives you access to some form of the AST of the
program in question which you can manipulate at compile time. If you forgo
the principle of treating code as data, then you end up with a definition
in which every compiler is metaprogramming, insofar it produces code based
on code. I'll refrain from judging if this or that is metaprogramming, but
the code-as-data principle tends to be a non-negotiable property to most
people I think.

In some languages, the '<' operator can be given new instances of
implementation such that the Less method isn't needed. This circumvents
much of the challenge originally posed. Haskell is one such language, and I
believe this is also possible in C++ though my C++ is rusty to put it
fairly.

The other solution is to force the programmer to provide a signature of the
required form, so in the case you have to write a Less method which uses
'<' internally, in turn making operator fit the signature of the scheme you
have. This is used by OCaml.

It is worthwhile to add to the discussion that you can have this implicit
or explicit. In the structural or implicit variant, the compiler figures
out what you want and picks the correct instance at compile time. In the
nominal or explicit variant, the programmer provides the implementation
they want. An important subtlety is that if we are using the implicit
variant, then there can be no ambiguity in the choice. There can only be
one Less for a type so to speak. In the explicit case, we can have several
Less orderings and choose among them as programmers. But we also require
more programmer cognitive load while doing so.

-- 
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] Go 2 error-handling: choose requirements!

2018-09-14 Thread Robert Engels

Until Go has typed errors and a throws clause (I.e exceptions) it’s pointless. 
You need to be able to be certain errors are handled or passed up at compile 
time. The throws clause facilitates this. It allows refactoring without 
breakage. 

Until then just live with the boilerplate and keep your apps simple - not that 
isn’t a good choice anyway. 

Sent from my iPhone

> On Sep 14, 2018, at 6:38 AM, Liam  wrote:
> 
> There are thirty-something counter-proposals on the feedback wiki! It's a bit 
> of a train wreck :-p
> 
> What that means, I believe, is that many folks see different requirement sets 
> for a new error-handling idiom, so the union of the sets is broad, and the Go 
> team's draft design targets a narrow set. Hence the dozens of "better ideas" 
> on the wiki, each targeted to a different requirement set. What we need isn't 
> a better idea, it's a consensus on the requirements for a broadly acceptable 
> solution.
> 
> I see some points of consensus:
>   a less distracting error handling idiom than if err != nil { 
> recurring_procedure }
>   reusable error handlers within a function and/or package
>   a way to invoke one of several error handlers by name; over 1/3rd of wiki 
> posts suggest this
> 
> Other points to seek consensus:
> 
>   Assuming a way to select one of several handlers when calling a function...
> In what ways can handlers be uniquely identified?
>   e.g. handler name, parameter name, label
> What are the classes of syntax to select a handler? e.g.
>   v, handler := fn (p)
>   v := builtin(fn (p), handler)
>   v := fn (p)  handler
>   v := handler  fn (p)
>   v := fn  handler (p)
> 
>   Should functions returning an error be nestable in function calls?
> func f(int)(int, error); x(f(p))
> If so, which of the above classes of syntax to select a handler can nest?
> 
>   Should handlers work for return values other than the last one? e.g.
> handler, v := f(p)
> 
>   Should handlers accept any type, or just error?
> 
>   Should a handler be able to continue the function, or only abort it?
> 
>   Should a handler be able to invoke another handler by name?
> 
>   Should handlers support context accretion in the error?
> err = fmt.Errorf("blurb: %v", err)
> If so, what are the options? e.g. implicit chain, explicit chain, 
> per-scope context accretor
> 
>   Should a handler appear before or after the statements that may invoke it?
> 
>   Should there be package-level handlers, accessible from any package 
> function?
> 
>   Should there be a "magical" default handler?
> What should a default handler do in main & goroutine functions which 
> don't return?
> 
>   Should new keywords be considered?
> 
> 
> In the event that anyone responds to the above questions instead of posting 
> yet another counter-proposal, I'll post a tally of responses for each point 
> :-)
> 
> Cheers!
> 
> 
>> On Thursday, September 13, 2018 at 12:29:03 PM UTC-7, Scott Pakin wrote:
>> I recently added to the Go 2 Error Handling Feedback page my thoughts on how 
>> to improve upon the draft design for error handling:
>> 
> 
> -- 
> 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] CGG (Craftsman Generics) Update

2018-09-14 Thread Wojciech S. Czarnecki

Changes:

Add break statement to `for type switch`.

> **break** statement can be given as the last case in the `for type switch`
> to signal that at least one substituted type does not make sense for the
> func code. If break statement is reached it effects in compile error of
> "func/method 'identifier' can not be used with 'given' type(s)".  

https://github.com/ohir/gonerics

=== Current state of CGG (TL;DR)

* no new keywords. Only ones known to Go1.
* contract uses already known Go type definitions and casts.
* only one new syntax construct for user, and three for generic code
- x.pkg.Method() generic method call via package selector
- (x type T) declarations — as in team's proposal
- for type contract; tied to the package or func
- for type switch that can further specialise code on matched type


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

[go-nuts] Go 2 error-handling: choose requirements!

2018-09-14 Thread Liam

There are *thirty-something* counter-proposals on the feedback wiki 
! It's a bit of 
a train wreck :-p

What that means, I believe, is that many folks see different requirement 
sets for a new error-handling idiom, so the union of the sets is broad, and 
the Go team's draft design targets a narrow set. Hence the dozens of 
"better ideas" on the wiki, each targeted to a different requirement set. 
What we need isn't a better idea, it's a consensus on the requirements for 
a broadly acceptable solution.

I see some points of consensus:
  a less distracting error handling idiom than if err != nil { 
recurring_procedure }
  reusable error handlers within a function and/or package
  a way to invoke one of several error handlers by name; over 1/3rd of wiki 
posts suggest this

Other points to seek consensus:

  Assuming a way to select one of several handlers when calling a 
function...
In what ways can handlers be uniquely identified?
  e.g. handler name, parameter name, label
What are the classes of syntax to select a handler? e.g.
  v, handler := fn (p)
  v := builtin(fn (p), handler)
  v := fn (p)  handler
  v := handler  fn (p)
  v := fn  handler (p)

  Should functions returning an error be nestable in function calls?
func f(int)(int, error); x(f(p))
If so, which of the above classes of syntax to select a handler can 
nest?

  Should handlers work for return values other than the last one? e.g.
handler, v := f(p)

  Should handlers accept any type, or just error?

  Should a handler be able to continue the function, or only abort it?

  Should a handler be able to invoke another handler by name?

  Should handlers support context accretion in the error?
err = fmt.Errorf("blurb: %v", err)
If so, what are the options? e.g. implicit chain, explicit chain, 
per-scope context accretor

  Should a handler appear before or after the statements that may invoke it?

  Should there be package-level handlers, accessible from any package 
function?

  Should there be a "magical" default handler?
What should a default handler do in main & goroutine functions which 
don't return?

  Should new keywords be considered?

In the event that anyone responds to the above questions instead of posting 
yet another counter-proposal, I'll post a tally of responses for each point 
:-)

Cheers!

On Thursday, September 13, 2018 at 12:29:03 PM UTC-7, Scott Pakin wrote:
>
> I recently added to the Go 2 Error Handling Feedback 
>  page my 
> thoughts on how to improve upon the draft design for error handling 
> 
> :
>
>

-- 
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] A simplified generics constraint system.

2018-09-14 Thread alanfo

It's now more than a fortnight since the Go 2 Draft Generics Design was 
published and, like many others, I have spent considerable time:

1. Steeped in discussions about the draft.

2. Reading feedback papers by others (Roger Peppe's are particularly 
illuminating) most of whom share my opinion that 'contracts' are 
unsatisfactory and should be replaced, amended or simplified in various 
ways.

3. Attempting to devise a workable alternative to contracts (as envisaged 
in the draft) myself.

I was then brought back to reality by this post by Robert Engels in the 
'Generics - Why contracts?' thread:
 
"As I’ve said elsewhere, a SIMPLE to use and understand solution that 
covers 90% is better than a complex one to cover 100% IMO, and fits in well 
with the rest of Go design. Go leaves out a lot - and it's a good choice."

This convinced me that the draft design itself and many third party 
proposals (including my own) were too ambitious and what we needed was 
something much simpler that gave us 90% coverage and which everybody could 
understand. 

So I've added a simplified proposal to the feedback page which I feel meets 
this more limited aim. For anyone interested, here's the link:

https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab

Although the new proposal is largely a simplified version of my 'full fat' 
proposal, the paper itself is much more comprehensive as I've included 
notes on why I think certain contracts should be built-in (but not others) 
and have also tried to address the problems that were raised in the draft 
design and overview papers themselves. 

Any comments or constructive criticism are of course welcome.

-- 
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] Generics - Min challenge

2018-09-14 Thread Wojciech S. Czarnecki

[Bcc: drchase]
On Wed, 12 Sep 2018 10:55:26 +0200
"Wojciech S. Czarnecki"  wrote:

> func Min(a, b T) T {

`func Min(a, b type T) type T` of course.

Late correction but needed.

>   for type switch {
>   case T func(T) Less(T) T:
>   return a.Less(b)
>   }
>   if a < b {
>return a
>   }
>   return b
> }

The `func Min(a, b T) T ` was valid at first hours of CGG proposal life.
Then, there, both compiler and user were directed to line below
with `for type` construct to differentiate between generic/non generic.

It would be bad for compiler though. And for reader, as in the next step
contract scope emerged. 

TC,

-- 
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] call of non-function C.testc

2018-09-14 Thread amandeep

oh yes, I am using gccgo. I configured gccgo from source. Below is the go 
version output:
*go version go1.10.3 gccgo (GCC) 8.2.1 20180814 solaris/sparc *

Following is the output of what is

-bash-3.2$ go build -x sol10.go
  
WORK=/tmp/go-build151901300
mkdir -p $WORK/b001/
cd $WORK
/usr/gnu/bin/gccgo -fsplit-stack -c -x c - || true
cd /export/home/amandeep
CGO_LDFLAGS='"-g" "-O2"' 
/usr/gnu/libexec/gcc/sparc-sun-solaris2.10/8.2.1/cgo -objdir $WORK/b001/ 
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 
./sol10.go
# command-line-arguments
./sol10.go:15:5: call of non-function C.testc

As suggested, next I ran with -debug-gcc option:

-bash-3.2$ CGO_LDFLAGS='"-g" "-O2"' 
/usr/gnu/libexec/gcc/sparc-sun-solaris2.10/8.2.1/cgo -debug-gcc -objdir 
$WORK/b001/ -importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g 
-O2 ./sol10.go 
$ gcc -E -dM -xc -I /b001/ -g -O2 - < /* for ptrdiff_t and size_t below */

/* Define intgo when compiling with GCC.  */
typedef ptrdiff_t intgo;

typedef struct { const char *p; intgo n; } _GoString_;
typedef struct { char *p; intgo n; intgo c; } _GoBytes_;
_GoString_ GoString(char *p);
_GoString_ GoStringN(char *p, int l);
_GoBytes_ GoBytes(void *p, int n);
char *CString(_GoString_);
void *CBytes(_GoBytes_);
void *_CMalloc(size_t);

__attribute__ ((unused))
static size_t _GoStringLen(_GoString_ s) { return s.n; }

__attribute__ ((unused))
static const char *_GoStringPtr(_GoString_ s) { return s.p; }
#line 3 "/export/home/amandeep/sol10.go"
 
#include 

void testc() {
printf("Hello cgo");
}

#line 1 "cgo-generated-wrapper"
EOF
#define __DBL_MIN_EXP__ (-1021)
#define __FLT32X_MAX_EXP__ 1024
#define _SYS_FEATURE_TESTS_H 
#define __UINT_LEAST16_MAX__ 0x
#define __ATOMIC_ACQUIRE 2
#define __FLT128_MAX_10_EXP__ 4932
#define __sun_attr___packed__ __attribute__((__packed__))
#define __FLT_MIN__ 1.1754943508222875079687365374568e-38F
#define __GCC_IEC_559_COMPLEX 2
#define __UINT_LEAST8_TYPE__ unsigned char
#define _T_WCHAR_ 
#define __INTMAX_C(c) c ## LL
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 0xff
#define __sun_attr___VPRINTFLIKE__(__n) __attribute__((__format__(printf, 
__n, 0)))
#define _FILEDEFED 
#define __WINT_MAX__ 0x7fffL
#define __FLT32_MIN_EXP__ (-125)
#define stderr (&__iob[2])
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 0xU
#define __WCHAR_MAX__ 0x7fffL
#define _LONG_LONG_ALIGNMENT 8
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ 
((double)4.94065645841246544176568792868221372e-324L)
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define _OBP 
#define __GCC_IEC_559 2
#define __FLT32X_DECIMAL_DIG__ 17
#define _IOFBF 
#define __sun_attr___pure__ __attribute__((__pure__))
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define __FLT64_DECIMAL_DIG__ 17
#define _XOPEN_VERSION 3
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __UINT_FAST64_MAX__ 0xULL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define L_cuserid 9
#define ___sun_attr_inner(__a) __sun_attr_ ##__a
#define __sun_attr___noreturn__ __attribute__((__noreturn__))
#define __GNUC_PATCHLEVEL__ 1
#define __FLT32_HAS_DENORM__ 1
#define __UINT_FAST8_MAX__ 0xff
#define __has_include(STR) __has_include__(STR)
#define __size_t 
#define __DEC64_MAX_EXP__ 385
#define _WCHAR_T_DEFINED 
#define __INT8_C(c) c
#define __INT_LEAST8_WIDTH__ 8
#define sparc 1
#define __UINT_LEAST64_MAX__ 0xULL
#define __sun_attr__(__a) ___sun_attr_inner __a
#define __SHRT_MAX__ 0x7fff
#define __LDBL_MAX__ 1.18973149535723176508575932662800702e+4932L
#define __FLT64X_MAX_10_EXP__ 4932
#define __UINT_LEAST8_MAX__ 0xff
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __FLT128_DENORM_MIN__ 
6.47517511943802511092443895822764655e-4966F128
#define __UINTMAX_TYPE__ long long unsigned int
#define __DEC32_EPSILON__ 1E-6DF
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __OPTIMIZE__ 1
#define putchar(x) putc((x), stdout)
#define __unix 1
#define __UINT32_MAX__ 0xU
#define __SIZE_T 
#define __LDBL_MAX_EXP__ 16384
#define __FLT128_MIN_EXP__ (-16381)
#define __WINT_MIN__ (-__WINT_MAX__ - 1)
#define __sun 1
#define __FLT128_MIN_10_EXP__ (-4931)
#define __INT_LEAST16_WIDTH__ 16
#define _SIZE_T_DEFINED_ 
#define __SCHAR_MAX__ 0x7f
#define _LONG_ALIGNMENT 4
#define __FLT128_MANT_DIG__ 113
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __INT64_C(c) c ## LL
#define _INT_ALIGNMENT 4
#define __DBL_DIG__ 15
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __FLT64X_MANT_DIG__ 113
#define _SYS_CCOMPILE_H 
#define getchar() getc(stdin)
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 4
#define clearerr(p) ((void)((p)->_flag &= ~(_IOERR | _IOEOF)))

Re: [go-nuts] Generics - Min challenge

2018-09-14 Thread Wojciech S. Czarnecki

On Thu, 13 Sep 2018 10:29:21 -0700 (PDT)
Manlio Perillo  wrote:

> `try` tries each block at compile time, and use the first block that 
> compiles successfully.

How the reader of this will know what will compile and what not?
Esp doing "by a finger"/"paper and pencil" codewalk?.

But you just rediscovered the very clever technique under
current generics proposal from the team: (just s/contract/try/ ;)

Instead of trying to compile a generic func the contract is tried first
so whole type matching is done for all substituted types at once
and using current well tested compiler.

If "contract" block does not compile, types do not fit. If it does,
compiler is free to make a variant, compile it and (for positive
outcome) tag an object code with current types for possible reuse
then move on. 

I admired this approach for a moment, until I tried to make sense
of what exactly "this contract" means for "given code" on a few
contrived examples. It did not click. So while I still admire brilliancy
of the compiler reuse, I don't think that it is good for Go.

> Well, probably there are a lot of issue with this proposal.
It just can't be read by a human. Compiler would cope with that.

> Manlio 
> 

-- 
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] Re: Go 2 error-handling counter-proposal: returnfrom

2018-09-14 Thread roger peppe

What about here, where the call stack associated with g is still live?

 func g() error {
 Top:
f := func(err error) { returnfrom Top, nil }
c := make(chan struct{})
go func() {
defer close(c)
f(nil)
}()
<-c
}

?

On 14 September 2018 at 06:35, Scott Pakin  wrote:

> On Thursday, September 13, 2018 at 4:00:28 PM UTC-6, Jonathan Amsterdam
> wrote:
>>
>> What's the meaning of this code?
>>
>>func main() {
>>f := g()
>>f()
>> }
>>
>>func g() func() {
>>Top:
>>return func() { returnfrom Top,   nil}
>>}
>>
>
> It means you're an evil programmer.  
>
> My thinking is that returning from a no-longer-accessible continuation
> should simply be a no-op.  Stepping through your example, f := g()
> assigns func() { returnfrom Top, nil } to f.  At this point the call
> stack associated with g() is no longer live.  f() executes, turning into 
> returnfrom
> Top, nil.  The returnfrom causes the inner function to return immediately
> and instructs g() to return nil.  But because the continuation
> corresponding to the call to g that returned the inner function no longer
> exists, there's no place to send that nil, and nothing happens.
>
> I believe this is a simpler and more Go-like semantics than, say, Scheme's
> call/cc, which *does* execute the f := g() statement twice:
>
> (define (main)
>   (let ((f (g)))
> ;(printf "Calling f = ~s~n" f)
> (f)))
>
> (define (g)
>   (call/cc
>(lambda (Top)
>  (lambda ()
>(Top '())
>
>
> (Uncomment the printf to see the double execution.  Weird, huh?)
>
> Thanks for the challenge,
> — Scott
>
> --
> 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.

40 matches

Mail list logo