[go-nuts] 2018/09/29 23:50:19 go-app-builder: Failed parsing input: parser: bad import "syscall" in main.go

[Tamás Gulácsi]

Maybe syscall in banned in appengine?

-- 
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] cgo use question

[Tamás Gulácsi]

You could export the C function in a Go wrapper in package A, and use that.
Maybe another exported  Go wrapper is needed in package B, I don't know.

-- 
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: Announcing pytogo. a crude but surprisingly effective Python to Go translator

[Eric Raymond]

Thanks, I'll fix the bug and add that to my test loads.
>
>
I discovered earlier today that an incautious rule steps on lambda 
expressions and some kinds of slice indexing.  The risks of not using a 
parser...

Until I ship 1.1 (shortly, probably tomiorrow), I recommend filtering your 
file in small sections, avoiding things like multiline strings.

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

Re: [go-nuts] net.TCPConn equivalent for setsockopt

[Dan Kortschak]

Yeah, I looked at that. It doesn't look like a good solution.

On Sun, 2018-09-30 at 21:03 -0500, robert engels wrote:
> use conn SetReadDeadline()
> 
> > 
> > On Sep 30, 2018, at 8:41 PM, Dan Kortschak  > edu.au> wrote:
> > 
> > I have been translating some C socket networking code (not my main
> > area
> > of expertise) and there is something that I don't see a way to do
> > with
> > net.TCPConn.
> > 
> > The original code sets a revc timeout using
> > 
> > ```
> > setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(timeout));
> > ```
> > 
> > Short of messing around with the fd and using
> > syscall.SetsockoptTimeval
> > (or unix.SetsockoptTimeval) which seems like overkill, is there a
> > sensible way to do this or is it omitted because it is not a useful
> > thing to do?
> > 
> > thanks
> > Dan
> > 

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

Re: [go-nuts] net.TCPConn equivalent for setsockopt

[robert engels]

This may help 
https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/

> On Sep 30, 2018, at 9:04 PM, robert engels  wrote:
> 
> But you need to set it on every call because it is an absolute time.
> 
>> On Sep 30, 2018, at 9:03 PM, robert engels  wrote:
>> 
>> use conn SetReadDeadline()
>> 
>>> On Sep 30, 2018, at 8:41 PM, Dan Kortschak  
>>> wrote:
>>> 
>>> I have been translating some C socket networking code (not my main area
>>> of expertise) and there is something that I don't see a way to do with
>>> net.TCPConn.
>>> 
>>> The original code sets a revc timeout using
>>> 
>>> ```
>>> setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(timeout));
>>> ```
>>> 
>>> Short of messing around with the fd and using syscall.SetsockoptTimeval
>>> (or unix.SetsockoptTimeval) which seems like overkill, is there a
>>> sensible way to do this or is it omitted because it is not a useful
>>> thing to do?
>>> 
>>> thanks
>>> Dan
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 

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

Re: [go-nuts] net.TCPConn equivalent for setsockopt

[robert engels]

But you need to set it on every call because it is an absolute time.

> On Sep 30, 2018, at 9:03 PM, robert engels  wrote:
> 
> use conn SetReadDeadline()
> 
>> On Sep 30, 2018, at 8:41 PM, Dan Kortschak  
>> wrote:
>> 
>> I have been translating some C socket networking code (not my main area
>> of expertise) and there is something that I don't see a way to do with
>> net.TCPConn.
>> 
>> The original code sets a revc timeout using
>> 
>> ```
>> setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(timeout));
>> ```
>> 
>> Short of messing around with the fd and using syscall.SetsockoptTimeval
>> (or unix.SetsockoptTimeval) which seems like overkill, is there a
>> sensible way to do this or is it omitted because it is not a useful
>> thing to do?
>> 
>> thanks
>> Dan
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] net.TCPConn equivalent for setsockopt

[robert engels]

use conn SetReadDeadline()

> On Sep 30, 2018, at 8:41 PM, Dan Kortschak  
> wrote:
> 
> I have been translating some C socket networking code (not my main area
> of expertise) and there is something that I don't see a way to do with
> net.TCPConn.
> 
> The original code sets a revc timeout using
> 
> ```
> setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(timeout));
> ```
> 
> Short of messing around with the fd and using syscall.SetsockoptTimeval
> (or unix.SetsockoptTimeval) which seems like overkill, is there a
> sensible way to do this or is it omitted because it is not a useful
> thing to do?
> 
> thanks
> Dan
> 
> -- 
> 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] Is this implementation of weak pointers safe?

[Dave Cheney]

Please don’t take os.File as justification, it’s one of the few uses of a 
finaliser in the std lib. If it were being written today I would argue that 
instead of silently closing the file, it should panic if the resource falls out 
of scope unclosed. 

As always, remember that finalisers are not guaranteed to run as they are tied 
to the gc cycle. In a well tuned application a finaliser can easily be delayed 
until the resource they are meant to mediate has been exhausted by 
overconsumption. 

Dave

-- 
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 this implementation of weak pointers safe?

[Ben Lubar]

On Sunday, September 30, 2018 at 4:56:20 PM UTC-5, Kane York wrote:
>
> In Go, it's usually better to use source code analysis to look for 
> forgotten Close calls, like the existing tooling for os.File (which does 
> have a finalizer, but doesn't need to).


*os.File has a finalizer for the same reason that this code needs one - it 
holds onto an external resource with some kind of ID that needs to be 
closed manually through an API call.

Even though runtime.SetFinalizer doesn't guarantee the finalizer will be 
called, the only reason it wouldn't be called is if the memory wasn't 
garbage-collected before the process exits (or the computer is unplugged, 
etc). In a long-running process, that isn't an issue for finalizers that 
just do cleanup.

-- 
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: Announcing pytogo. a crude but surprisingly effective Python to Go translator

[Michael Ellis]

Thanks for sharing this (and I'm honored to make your virtual acquaintance, 
Eric). 

 I'd love to make use of pytogo my own project. I've got a little over 20K 
lines that still need translation.

So I cloned it and gave it a quick try.  It seems to be choking on doc 
strings of the form.

"""
Some docstring text.
"""

All of my functions and modules have doc strings in that format. 

In case it's useful as a sample for your development, I've attached the 
file I tried to convert.  It's a short collection of miscellaneous utility 
functions that didn't quite fit elsewhere in the project. Here's what comes 
out when I try to convert it.

$ cat utils.py | ./pytogo
"""
`
func iterf(func, sentinel, *args, **kwargs) {
"""
}


If I chop out the doc strings from the top of the module and the first 
function, iterf, it makes it through the first function (which I realize is 
probably impossible to represent in Go) and then gives up at the 
triple-quotes in the next function,

$ cat utils.py | ./pytogo
func iterf(func, sentinel, *args, **kwargs) {
return iter(lambda  { func(*args, **kwargs), sentinel)
}


func base36encode(number) {
"""
}




On Sunday, September 30, 2018 at 6:48:14 AM UTC-4, Eric Raymond wrote:
>
> I have mentioned before on this list that I am engaged in source 
> translation of a largeish Python prgram - 14KLOC - to Go.  I found the 
> automated AST-based translation tools already available unsatisfactory; 
> they don't produce a quality of Go code I would consider maintainable.  So 
> I wrote my own using crude, old-school regexp-bashing.
>
> This turned out to be surprisingly effective.  The following is from the 
> manual page:
>
> * Opens Python block scopes with { and closes them with }.
>
> * Changes docstrings to comments.
>
> * Changes comments from #-led to //-led
>
> * Translates Python boolean constants True, False to Go true, false
>
> * Translates Python "in range" to Go ":= range",  You will need to fix
>   up the comma and range clauses by hand.
>
> * Maps Python single-quote literals to Go double-quote literals.
>
> * Translates Python logical connectives and or not to Go && || !.
>
> * Changes Python None to Go nil.
>
> * Changes "def " at the left margin to "func ".
>
> * Common cases of various Python string library methods - capitalize(), 
> count(), endswith(), find(), join(), lower(), lstrip(), rfind(), replace(), 
> rstrip(), split(), startswith(), split(), upper() - are translated to Go 
> string library calls.
>
> * Some common Python standard library calls, notably from os and 
> os.filepath, are translated into Go equivalents. The result is not  
> guaranteed to be perfectly correct; a Python call that throws a signal on 
> failure may map into a Go function with an error return. But it will always 
> be a step in the right direction, and the Go compiler will respond with 
> indicative error messages.
>
> * The append() method of Python is translated to a call to Go's append 
> intrinsic.
>
> * Python's "del foo[bar]" is translated to Go "delete(foo, bar)". Note 
> that this can false-match on a list del with a numeric key; this
>   will throw a compilation error in Go and you can hand-fix it.
>
> * Trailing line-continuation backslashes are removed.
>
> * Python r-prefix string literals become Go backtick literals
>
> * Python try/finally/catch become pseudo-statements with delimited block 
> scopes.  You will need to fix these up by hand.
>
> * Single-line % expressions with a string-literal left hand and either 
> tuple or single-variable right hands are translated into fmt.Sprintf 
> calls.  You will need to translate %-cookies by hand; %r -> %v or %q is the 
> usual trouble spot.
>
> * Changes multiline strings to backtick literals. You'll need to fix up 
> backslash escapes and %-cookies yourself.
>
> * Many, but not necessarily all, cases where Go ":=" assignment can 
> replace a plain "=" assignment in Python are translated.
>
> This doesn't do a complete job, of course.  But it takes a lot of the pain 
> out of hand-translation, and it does preserve comments and structure.  
> Probably the automated block scope closing is the biggest single win; 
> that's a tedious, fiddly job by hand and mistakes are all too easy.
>
> Future releases will translate a larger subset of Python standard library 
> calls.
>
> The repository is at https://gitlab.com/esr/pytogo and the project home 
> page at http://www.catb.org/esr/pytogo/
>

-- 
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.
"""
Miscellaneous utility functions.
"""
def iterf(func, sentinel, *args, **kwargs):
"""
The Python built-in 'iter' doesn't explicityly handle functions with
arguments.  This variation accomplishes that by currying with lambda.

[go-nuts] 2018/09/29 23:50:19 go-app-builder: Failed parsing input: parser: bad import "syscall" in main.go

[unlichat2018]

Hi,

Anyone has encountered this error before when trying to run your app in app 
engine console:

dev_appserver.py app.yaml


2018/09/29 23:50:19 go-app-builder: Failed parsing input: parser: bad 
import "syscall" in main.goWARNING 2018-09-29 23:50:19,127 instance.py:297] 
Could not get PID of instanceERROR 2018-09-29 23:50:19,128 instance.py:300] 
'_GoBuildFailureRuntimeProxy' object has no attribute '_process'

-- 
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 this implementation of weak pointers safe?

['Kane York' via golang-nuts]

In Go, it's usually better to use source code analysis to look for forgotten 
Close calls, like the existing tooling for os.File (which does have a 
finalizer, but doesn't need to).

-- 
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] Constraints for generics

[Robert Engels]

Using a subset of types makes it unusable for generic collections. You don’t 
want to write multiple tree maps. That is what Go has today and what generics 
is primarily attempting to fix, so at the end of the day if I can’t write a 
completely generic collection class I will bet the farm that your, or proposals 
like it, will never be accepted. There’s just not enough added value for the 
primary use cases. 

> On Sep 30, 2018, at 1:09 PM, Wojciech S. Czarnecki  wrote:
> 
> On Sun, 30 Sep 2018 10:18:25 -0500
> robert engels  wrote:
> 
>> Yes, it is a very similar if not the same issue, 
>> since the type switch must be at the TOP LEVEL
> 
> No, in my CGG `for type switch` contract does not need to be at top level.
> It is proposed in Chris' but still yours:
> 
>> you guarantee the entire method will be duplicated multiple times.
> 
> is a false statement, the straw man you want Christian (or me) to fight.
> 
>> How you continually do not see the problem with this
>> I am not sure, but I think it is because you are using trivial methods
> 
> How you continually do not see that **every** compile time switch case
> code is reusable for **many** user types in the restricted set described
> by a contract I am not sure, but I think it is because you are somehow
> blinded by "the years of common knowledge" in the c++/java practice;
> and lack of Go's thereof.
> 
> Fundamental misunderstanding here is that generics you breathe are about
> writing code that deals with possibly infinite set of abstract types. 
> With all that mess of declarations scattered over many places, type
> parameters that need to be dully filled in every place of concrete use;
> then wonders of overgeneralized constructs even their author needs
> to study cautiously the day after tomorrow.
> 
> Mine's (and to some extent Chris') proposal is about writing code that deals
> with restricted (by the contract) set of concrete types and operating on
> something that's common to said types. Had you seen that, you would know
> that each "case:" is just a contract for some subset.
> 
> 
>> Here is a fairly simple generic method from TreeMap.java
> 
> I do not discuss java nor I fight straw men built upon it on Go focused list.
> 
> CGG (https://github.com/ohir/gonerics) is not about extending Java. 
> It is about giving elegant solution to current problem of code repetition
> within Go1 real projects. Call it generics or not, it is.
> 
> Anyway, this is a Christian Surlykke's proposal thread, so please discuss
> **his** proposal here, not CGG. I just warned Christian, and other readers,
> about straw man I wasted some time fighting it on CGG threads - in hope that
> he will not waste his.
> 
> -- 
> 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] Constraints for generics

[Wojciech S. Czarnecki]

On Sun, 30 Sep 2018 10:18:25 -0500
robert engels  wrote:

> Yes, it is a very similar if not the same issue, 
> since the type switch must be at the TOP LEVEL

No, in my CGG `for type switch` contract does not need to be at top level.
It is proposed in Chris' but still yours:

> you guarantee the entire method will be duplicated multiple times.

is a false statement, the straw man you want Christian (or me) to fight.

> How you continually do not see the problem with this
> I am not sure, but I think it is because you are using trivial methods

How you continually do not see that **every** compile time switch case
code is reusable for **many** user types in the restricted set described
by a contract I am not sure, but I think it is because you are somehow
blinded by "the years of common knowledge" in the c++/java practice;
and lack of Go's thereof.

Fundamental misunderstanding here is that generics you breathe are about
writing code that deals with possibly infinite set of abstract types. 
With all that mess of declarations scattered over many places, type
parameters that need to be dully filled in every place of concrete use;
then wonders of overgeneralized constructs even their author needs
to study cautiously the day after tomorrow.

Mine's (and to some extent Chris') proposal is about writing code that deals
with restricted (by the contract) set of concrete types and operating on
something that's common to said types. Had you seen that, you would know
that each "case:" is just a contract for some subset.


> Here is a fairly simple generic method from TreeMap.java

I do not discuss java nor I fight straw men built upon it on Go focused list.

CGG (https://github.com/ohir/gonerics) is not about extending Java. 
It is about giving elegant solution to current problem of code repetition
within Go1 real projects. Call it generics or not, it is.

Anyway, this is a Christian Surlykke's proposal thread, so please discuss
**his** proposal here, not CGG. I just warned Christian, and other readers,
about straw man I wasted some time fighting it on CGG threads - in hope that
he will not waste his.

-- 
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] Constraints for generics

[Scott Cotton]

On Sun, 30 Sep 2018 at 17:56, robert engels  wrote:
>
> I think you address the first, with a “toUnsigned” method, but I am not sure 
> that semantically makes sense for a lot of types except numerics, but 
> “shifting” is only supported on numeric types anyway.
>
> I have always thought that not having automatic conversions for numerics in 
> Go is a bit strange. I think it makes some code much safer, but it also makes 
> a lot of code a PITA and way more difficult to read.

For me the amount of code which is much safer and more clear is much
more than that which is more contorted by explicit casting.  When a
language encourages or discourages code style by having rules which
solve some problems and make other ways of expressing more difficult,
there is tendency for people to find other more natural ways of
expressing those later things, so they show up less.


>
> As I’ve said before, I think people are over complicating it, and if Go had 
> ‘generic type-safe collections” - possibly even just adding new options to 
> ‘make' to say “concurrent” and maybe a few other “OR-able options”, like 
> “ordered_keys”, etc and and do it behind the scenes (the runtime picks 
> different implementations, and possible allow the developer to register 
> others), and then keep the current syntax (for maps, slices, etc.) and just 
> about everyone would be happy.
>
> The non-collection cases can readily be solved with interfaces in most cases.
>

Maybe you can write up these ideas, make them concrete enough to think
through and consider w.r.t. other proposals?

I have an intuition that in any event some kind of genuine generic
programming would be good, and I find the contracts idea very
thoroughly considered and the idea of specifying relations over types
by example compelling in general and for Go in particular.  Still
working on (better) unifying the relation of contracts to interfaces,
but that's in no way a rejection of the basic ideas in the contracts
draft proposal.

Scott


> On Sep 30, 2018, at 10:32 AM, Scott Cotton  wrote:
>
>
>
> On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote:
>>
>> The static switch is a big problem. For any complex method you are going to 
>> completely duplicate all of the code. Not good.
>>
>> Far better to map operators to interfaces then you only need a single method 
>> implementation.
>
>
> I don't think you can easily do that with Go, take for example the constraint 
> (according to the draft proposal syntax and semantics)
> contract unsigned(x T) {
> 1 << x
> }
>
> Another problem is pointer dereferencing
>
> contract p(x T) {
>   *x
> }
>
> if you define an operator for pointer dereferencing on T by a method, then 
> all the rules about what is addressable and dereferencable in Go become very 
> complicated, especially w.r.t. interfaces
>
> Finally, all standard languages with operator overloading either
> 1) don't allow you to implement numbers generically for implementations where 
> constants for 0, 1, Pi, ... may have different binary representation than the 
> constant in the language (such as fixed point numbers); or
> 2) like C++ allow constants to be substituted via templates.
>
> I think some of the literature on "Dependent types" may address this later 
> issue, but it's pretty heady stuff and outside the scope of
> what I want to have to think about when coding, so as to focus efforts more 
> readily on the objective of the code rather than heady type theory.
>
> practical operator overloading isn't a solved problem AFAIK, much less for Go.
>
> Scott
>
>
>>
>>
>> On Sep 30, 2018, at 5:33 AM, Christian Surlykke  wrote:
>>
>> Hi
>>
>> I made a proposal for generics with constraints about ½ a year ago, which I 
>> posted to the (very long) thread on issue 15292. I've now made a version 2, 
>> in case anybody would like to read it.
>>
>> This version adapts to the generics syntax now proposed by the Go team and 
>> is somewhat simpler than the previous version.
>>
>> br. Chr.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>


-- 
Scott Cotton
http://www.iri-labs.com

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

Re: [go-nuts] cgo use question

[Scott Cotton]

On Sun, 30 Sep 2018 at 17:55, Simon Ritchie  wrote:
>
> Aagh!  I misunderstood the question.  Apologies for that.
>

I could have phrased the question more clearly also, sorry.


> There may still be a grain of usefulness in my answer.  There are limits to 
> the complexity of the C code that you can call with cgo.  (It’s even worse if 
> you are calling C++, as I was.)  You can magic away a lot of those problems 
> by writing an extra layer of C that hides the complexities.
>
> However, this probably involves having make around to bind everything 
> together.  I agree that this is a nuisance, because your user may not have 
> make, particularly if they are using Windows.  There is a version of gnu make 
> available for that, but using it just led me to a different world of pain.
>

I found a workaround finally.   Basically:
- in package A, when #including f.h via cgo, I add directive #cgo -DA
- in f.h, I only declare the functions if A is defined
#ifdef A
void f();
#endif
- in f.h, I put a pointer to f in a struct.
typedef struct S {
   void (*f)();
} S;

this struct def is not guarded by the #ifdef
- I populate the fn pointer in package A at runtime for instances of struct S.

Then in package B
- I pass the *C.S struct to C via cgo function call.
- I #include "f.h" from package A without -DA
- I pass the *C.S struct to C via cgo function call, and get the
function pointers out of it to call.

Everything builds and runs fine without link errors.



> Have you considered having two separate pieces of software, one in C and one 
> in Go and linking them together with grpc?  That would allow you to ship your 
> solution as two binaries.
>

Yes, but in this case the shared C functionality is tiny, <100LOC it
would be a shame.  Also, ironically enough, the end goal of the
contorted cgo usage above is to bypass cgo->go at runtime for a very
particular use case which needs it (definitely not recommended in
general).  It would be silly to make a thin C shim and distribute
separately as an external C dependency for the purpose of using more
pure Go and less cgo :)

Thanks in any event for your help, it was also informative to me.

Scott



> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/ruLltGrPWBg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Scott Cotton
http://www.iri-labs.com

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

Re: [go-nuts] Constraints for generics

[robert engels]

I think you address the first, with a “toUnsigned” method, but I am not sure 
that semantically makes sense for a lot of types except numerics, but 
“shifting” is only supported on numeric types anyway.

I have always thought that not having automatic conversions for numerics in Go 
is a bit strange. I think it makes some code much safer, but it also makes a 
lot of code a PITA and way more difficult to read.

As I’ve said before, I think people are over complicating it, and if Go had 
‘generic type-safe collections” - possibly even just adding new options to 
‘make' to say “concurrent” and maybe a few other “OR-able options”, like 
“ordered_keys”, etc and and do it behind the scenes (the runtime picks 
different implementations, and possible allow the developer to register 
others), and then keep the current syntax (for maps, slices, etc.) and just 
about everyone would be happy.

The non-collection cases can readily be solved with interfaces in most cases.

> On Sep 30, 2018, at 10:32 AM, Scott Cotton  wrote:
> 
> 
> 
> On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote:
> The static switch is a big problem. For any complex method you are going to 
> completely duplicate all of the code. Not good. 
> 
> Far better to map operators to interfaces then you only need a single method 
> implementation. 
> 
> I don't think you can easily do that with Go, take for example the constraint 
> (according to the draft proposal syntax and semantics)
> contract unsigned(x T) {
> 1 << x
> } 
> 
> Another problem is pointer dereferencing
> 
> contract p(x T) {
>   *x
> }
> 
> if you define an operator for pointer dereferencing on T by a method, then 
> all the rules about what is addressable and dereferencable in Go become very 
> complicated, especially w.r.t. interfaces
> 
> Finally, all standard languages with operator overloading either 
> 1) don't allow you to implement numbers generically for implementations where 
> constants for 0, 1, Pi, ... may have different binary representation than the 
> constant in the language (such as fixed point numbers); or
> 2) like C++ allow constants to be substituted via templates.
> 
> I think some of the literature on "Dependent types" may address this later 
> issue, but it's pretty heady stuff and outside the scope of
> what I want to have to think about when coding, so as to focus efforts more 
> readily on the objective of the code rather than heady type theory.
>  
> practical operator overloading isn't a solved problem AFAIK, much less for Go.
> 
> Scott
> 
>  
> 
> On Sep 30, 2018, at 5:33 AM, Christian Surlykke > 
> wrote:
> 
>> Hi 
>> 
>> I made a proposal for generics with constraints about ½ a year ago, which I 
>> posted to the (very long) thread on issue 15292. I've now made a version 2 
>> , in 
>> case anybody would like to read it. 
>> 
>> This version adapts to the generics syntax now proposed by the Go team and 
>> is somewhat simpler than the previous version.
>> 
>> br. Chr.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com <>.
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

[go-nuts] cgo use question

[Simon Ritchie]

Aagh!  I misunderstood the question.  Apologies for that.

There may still be a grain of usefulness in my answer.  There are limits to the 
complexity of the C code that you can call with cgo.  (It’s even worse if you 
are calling C++, as I was.)  You can magic away a lot of those problems by 
writing an extra layer of C that hides the complexities.

However, this probably involves having make around to bind everything together. 
 I agree that this is a nuisance, because your user may not have make, 
particularly if they are using Windows.  There is a version of gnu make 
available for that, but using it just led me to a different world of pain.

Have you considered having two separate pieces of software, one in C and one in 
Go and linking them together with grpc?  That would allow you to ship your 
solution as two binaries.

-- 
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] Constraints for generics

[Scott Cotton]

On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote:
>
> The static switch is a big problem. For any complex method you are going 
> to completely duplicate all of the code. Not good. 
>
> Far better to map operators to interfaces then you only need a single 
> method implementation. 
>

I don't think you can easily do that with Go, take for example the 
constraint (according to the draft proposal syntax and semantics)
contract unsigned(x T) {
1 << x
} 

Another problem is pointer dereferencing

contract p(x T) {
  *x
}

if you define an operator for pointer dereferencing on T by a method, then 
all the rules about what is addressable and dereferencable in Go become 
very complicated, especially w.r.t. interfaces

Finally, all standard languages with operator overloading either 
1) don't allow you to implement numbers generically for implementations 
where constants for 0, 1, Pi, ... may have different binary representation 
than the constant in the language (such as fixed point numbers); or
2) like C++ allow constants to be substituted via templates.

I think some of the literature on "Dependent types" may address this later 
issue, but it's pretty heady stuff and outside the scope of
what I want to have to think about when coding, so as to focus efforts more 
readily on the objective of the code rather than heady type theory.
 
practical operator overloading isn't a solved problem AFAIK, much less for 
Go.

Scott

 

>
> On Sep 30, 2018, at 5:33 AM, Christian Surlykke  > wrote:
>
> Hi 
>
> I made a proposal for generics with constraints about ½ a year ago, which 
> I posted to the (very long) thread on issue 15292. I've now made a version 
> 2 , 
> in case anybody would like to read it. 
>
> This version adapts to the generics syntax now proposed by the Go team and 
> is somewhat simpler than the previous version.
>
> br. Chr.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: [go-nuts] Is this implementation of weak pointers safe?

[Ben Lubar]

On Sunday, September 30, 2018 at 4:00:32 AM UTC-5, Tamás Gulácsi wrote:
>
> 2018. szeptember 30., vasárnap 6:20:37 UTC+2 időpontban Ben Lubar a 
> következőt írta:
>>
>> On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote:
>>>
>>> Quoting Ben Lubar (2018-09-29 14:40:28) 
>>> >[1]https://play.golang.org/p/iBAii-f84Sq 
>>> >vet is complaining because the unsafe.Pointer usage would normally 
>>> be 
>>> >dangerous around the garbage collector, but since I have a 
>>> finalizer on 
>>> >the "real" pointer and there is no way the code could access the 
>>> >uintptr with the same value as the real pointer once the finalizer 
>>> has 
>>> >run or been removed by Close, shouldn't this code be safe? 
>>>
>>> From the unsafe package's documentation: 
>>>
>>> > Even if a uintptr holds the address of some object, the garbage 
>>> > collector will not update that uintptr's value if the object moves 
>>>
>>> One valid implementation strategy for a garbage collector is to do arena 
>>> allocation, and on a GC pass copy all *live* objects out of an arena 
>>> into another one for longer-lived objects, and then free the old arena. 
>>> In this case, your uintptrs would still still contain the old addresses, 
>>> even though the objects have moved. Note that the finalizer is never run 
>>> in this case, because the object has been moved without being garbage. 
>>>
>>> Whether what you're doing is actually safe depends heavily on the 
>>> implementation details of the garbage collector. It may or may not 
>>> be possible for it to break given the current implementation; 
>>> I don't know enough about it to be sure. But a correct implementation 
>>> of the runtime could very well corrupt memory given the code you 
>>> linked; even if it works now, it's possible in a future release of 
>>> Go this could break. 
>>>
>>> Hope this helps, 
>>>
>>> -Ian 
>>>
>>
>> Is there any way to implement this safely, or should I just give up on 
>> the weak pointer idea?
>>
>
>
> What will your *Session keep from getting collected if you have only weak 
> pointers to it? Nothing.
>
> What are you trying to achieve?
>
> You have Session.Close. Why not have it clean up after itself - even from 
> the session registry?
> Just have a "sessions=make(map[SessionID]*Session)", and do a 
> "sessionsMtx.Lock(); delete(sessions, sess.id); sessionsMtx.Unlock()" in 
> Session.Close.
>
> A WeakValueMap would eliminate the need of this explicit cleanup, but we 
> don't have weak maps in Go.
> And Finalizers are totally unreliable - you don't know when will they be 
> called, if called at all.
>

Even if the finalizer is never called, it still holds a reference to the 
pointer, so the session won't be garbage-collected before then.

The only thing the weak pointer lets me do is write a message that will 
hopefully be seen by the developer if they forget to close the session. The 
finalizer closes the session anyway, so the weak pointer never exists when 
the thing it points to doesn't exist.

Another way I could theoretically do this is decouple the session from its 
data and store the data in the map but not the session object. That way, 
the session object could still be garbage collected even if the data is 
still in the map. 

-- 
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] Constraints for generics

[robert engels]

Btw, I realize that in this particular case, you would probably write a 
“compareKeys” method to perform the key comparison, and that would have the 
type switch, but I was trying to show that in general a method that uses a lot 
of math and or comparison operations will need to be duplicated, probably more 
so for the math operations.


> On Sep 30, 2018, at 10:18 AM, robert engels  wrote:
> 
> Yes, it is a very similar if not the same issue, since the type switch must 
> be at the TOP LEVEL, you guarantee the entire method will be duplicated 
> multiple times. How you continually do not see the problem with this I am not 
> sure, but I think it is because you are using trivial methods to “test” the 
> situation.
> 
> Here is a fairly simple generic method from TreeMap.java, do you really want 
> N versions of this when the container have ints and some user interface 
> object? And since K and V are different types, it is even worse.
> 
> And I think you should review the definition of straw-man, because that 
> doesn’t apply.
> 
> If you review the following code, you see that compareTo is used deeply when 
> comparing keys. Under your proposals, I will need to duplicate the entire 
> method, since the simple comparison test will be different for the primitives 
> (==) and structs (compareTo()).
> 
> Maybe you can rewrite the following method under your proposal to prove me 
> wrong… You’ll also notice that this methods supports keys that aren’t 
> “comparable” by passing a “comparator” to the ctor.
> 
> public V put(K key, V value) {
> Entry t = root;
> if (t == null) {
> compare(key, key); // type (and possibly null) check
> 
> root = new Entry<>(key, value, null);
> size = 1;
> modCount++;
> return null;
> }
> int cmp;
> Entry parent;
> // split comparator and comparable paths
> Comparator cpr = comparator;
> if (cpr != null) {
> do {
> parent = t;
> cmp = cpr.compare(key, t.key);
> if (cmp < 0)
> t = t.left;
> else if (cmp > 0)
> t = t.right;
> else
> return t.setValue(value);
> } while (t != null);
> }
> else {
> if (key == null)
> throw new NullPointerException();
> @SuppressWarnings("unchecked")
> Comparable k = (Comparable) key;
> do {
> parent = t;
> cmp = k.compareTo(t.key);
> if (cmp < 0)
> t = t.left;
> else if (cmp > 0)
> t = t.right;
> else
> return t.setValue(value);
> } while (t != null);
> }
> Entry e = new Entry<>(key, value, parent);
> if (cmp < 0)
> parent.left = e;
> else
> parent.right = e;
> fixAfterInsertion(e);
> size++;
> modCount++;
> return null;
> }
> 
>> On Sep 30, 2018, at 9:27 AM, Wojciech S. Czarnecki > > wrote:
>> 
>>>  Robert Engels mailto:reng...@ix.netcom.com>> wrote 
>>> about what
 Christian Surlykke mailto:christ...@surlykke.dk>> 
 wrote:
>> 
>>> The static switch is a big problem. For any complex method you are going to
>>> completely duplicate all of the code. Not good. 
>> 
>> Now the same straw man argument I read in "critique" about my [1] solution is
>> raised against other person's proposal. 
>> 
>> No! One need not to "completely duplicate" the code. Not even to mention
>> "all", or most. And "static switch" is **not** "a big problem". 
>> It is a solution to the problem. 
>> 
>> For the practical generic code we need to deal with outstanding cases/types
>> via the variant generation. Usually, a variant involving **different** code
>> or even different underlying algorithm. That's what a `compile-time switch`
>> over possible specialized code variants is for. Both in mine's and in Chris'
>> proposal.
>> 
>>> Far better to map operators to interfaces then you only need a single
>>> method implementation. 
>> 
>> Oh, just a single? Rly? Just a single method implementation for each of
>> possibly hundreds or thousands of future user types? Aren't you "going
>> to completely duplicate all of the code"? Even for non-complex methods?
>> (Its current state of affairs, btw).
>> 
>> @Christian  mailto:christ...@surlykke.dk>>
>> Read other threads' replies made from reng...@ix.netcom.com 
>> , esp ones of
>> "java's better" attitude, before you start to write a reply to an unfounded
>> critique. Fighting someone else's straw man makes no sense at all.
>> 
>> [1] 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 

Re: [go-nuts] Constraints for generics

[robert engels]

Yes, it is a very similar if not the same issue, since the type switch must be 
at the TOP LEVEL, you guarantee the entire method will be duplicated multiple 
times. How you continually do not see the problem with this I am not sure, but 
I think it is because you are using trivial methods to “test” the situation.

Here is a fairly simple generic method from TreeMap.java, do you really want N 
versions of this when the container have ints and some user interface object? 
And since K and V are different types, it is even worse.

And I think you should review the definition of straw-man, because that doesn’t 
apply.

If you review the following code, you see that compareTo is used deeply when 
comparing keys. Under your proposals, I will need to duplicate the entire 
method, since the simple comparison test will be different for the primitives 
(==) and structs (compareTo()).

Maybe you can rewrite the following method under your proposal to prove me 
wrong… You’ll also notice that this methods supports keys that aren’t 
“comparable” by passing a “comparator” to the ctor.

public V put(K key, V value) {
Entry t = root;
if (t == null) {
compare(key, key); // type (and possibly null) check

root = new Entry<>(key, value, null);
size = 1;
modCount++;
return null;
}
int cmp;
Entry parent;
// split comparator and comparable paths
Comparator cpr = comparator;
if (cpr != null) {
do {
parent = t;
cmp = cpr.compare(key, t.key);
if (cmp < 0)
t = t.left;
else if (cmp > 0)
t = t.right;
else
return t.setValue(value);
} while (t != null);
}
else {
if (key == null)
throw new NullPointerException();
@SuppressWarnings("unchecked")
Comparable k = (Comparable) key;
do {
parent = t;
cmp = k.compareTo(t.key);
if (cmp < 0)
t = t.left;
else if (cmp > 0)
t = t.right;
else
return t.setValue(value);
} while (t != null);
}
Entry e = new Entry<>(key, value, parent);
if (cmp < 0)
parent.left = e;
else
parent.right = e;
fixAfterInsertion(e);
size++;
modCount++;
return null;
}

> On Sep 30, 2018, at 9:27 AM, Wojciech S. Czarnecki  wrote:
> 
>>  Robert Engels  wrote about what
>>> Christian Surlykke  wrote:
> 
>> The static switch is a big problem. For any complex method you are going to
>> completely duplicate all of the code. Not good. 
> 
> Now the same straw man argument I read in "critique" about my [1] solution is
> raised against other person's proposal. 
> 
> No! One need not to "completely duplicate" the code. Not even to mention
> "all", or most. And "static switch" is **not** "a big problem". 
> It is a solution to the problem. 
> 
> For the practical generic code we need to deal with outstanding cases/types
> via the variant generation. Usually, a variant involving **different** code
> or even different underlying algorithm. That's what a `compile-time switch`
> over possible specialized code variants is for. Both in mine's and in Chris'
> proposal.
> 
>> Far better to map operators to interfaces then you only need a single
>> method implementation. 
> 
> Oh, just a single? Rly? Just a single method implementation for each of
> possibly hundreds or thousands of future user types? Aren't you "going
> to completely duplicate all of the code"? Even for non-complex methods?
> (Its current state of affairs, btw).
> 
> @Christian  
> Read other threads' replies made from reng...@ix.netcom.com, esp ones of
> "java's better" attitude, before you start to write a reply to an unfounded
> critique. Fighting someone else's straw man makes no sense at all.
> 
> [1] 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.

-- 
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] cgo use question

[Scott Cotton]

Hi again,

As a followup, it seems the same or similar problems occur with assigning 
function pointers across Go packages via cgo.

When trying to assign a C function "fC" defined via cgo in package A to a C 
function pointer "fCPtr" in package B, even at runtime via Go, I get:

Undefined symbols for architecture x86_64:

  "_fC", referenced from:

  __cgohack_fC in _cgo_main.o

 (maybe you meant: _fCPtr, __cgohack_fC , __cgohack_fCPtr )



when building B.  A builds just fine.  It seems I just can't reference one 
cgo C function across packages, which means I either need to make a C 
library separately or copy+rename or use static functions fC  tand have go 
get and go modules work.


hmm...

maybe I'll copy the C code and make the functions static file members.  If 
that's the best solution, it is disappointing :(


Scott



On Sunday, 30 September 2018 14:20:41 UTC+2, Scott Cotton wrote:
>
> Hi all,
>
> For info, short of a solution for linking cgo specific C functions cross 
> package, I think one can do this with C function pointers, which at least 
> is a close approximation of directly calls.
>
> Best,
> Scott
>
> On Sunday, 30 September 2018 14:08:28 UTC+2, Scott Cotton wrote:
>>
>> Thanks 
>>
>> In my case, believe it or not -- and for a very particular use case, 
>> I cannot call the shared C functionality from Go, it must be called 
>> from C. And I want to avoid telling consumers to use make to create a 
>> C library, so that go get and modules will work. 
>>
>> It looks to me like your solution, at least from the README calls 
>> make, and I can't find an example (though I may well have missed 
>> something) of shared package specific cgo C code outside of a C 
>> library being called by C in another package. 
>>
>> Can you clarify if or how your suggestion will meet my requirements (1 
>> -- go tool only, no make, 2 -- cgo C function called by C in more than 
>> one package)? 
>>
>> Scott 
>> On Sun, 30 Sep 2018 at 13:57, Simon Ritchie  
>> wrote: 
>> > 
>> > Write a separate package to handle the C stuff and call it from the 
>> other two. 
>> > 
>> > I built a wrapper for a  c++ library:  
>> https://github.com/goblimey/rplidar_sdk_go.  The c++ code used various 
>> features that defeated cgo, so I ended up with a multi-layered solution. 
>> > 
>> > One thing I discovered is that cgo has a nasty habit of rewriting the 
>> Go code that calls C code, including trampling on your comments, so keeping 
>> that code in  a separate layer is a good idea. 
>> > 
>> > -- 
>> > You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group. 
>> > To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/ruLltGrPWBg/unsubscribe. 
>> > To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts+unsubscr...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>
>>
>> -- 
>> Scott Cotton 
>> http://www.iri-labs.com 
>>
>

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

Re: [go-nuts] Constraints for generics

[Wojciech S. Czarnecki]

>   Robert Engels  wrote about what
>> Christian Surlykke  wrote:

> The static switch is a big problem. For any complex method you are going to
> completely duplicate all of the code. Not good. 

Now the same straw man argument I read in "critique" about my [1] solution is
raised against other person's proposal. 

No! One need not to "completely duplicate" the code. Not even to mention
"all", or most. And "static switch" is **not** "a big problem". 
It is a solution to the problem. 

For the practical generic code we need to deal with outstanding cases/types
via the variant generation. Usually, a variant involving **different** code
or even different underlying algorithm. That's what a `compile-time switch`
over possible specialized code variants is for. Both in mine's and in Chris'
proposal.

> Far better to map operators to interfaces then you only need a single
> method implementation. 

Oh, just a single? Rly? Just a single method implementation for each of
possibly hundreds or thousands of future user types? Aren't you "going
to completely duplicate all of the code"? Even for non-complex methods?
(Its current state of affairs, btw).

@Christian  
Read other threads' replies made from reng...@ix.netcom.com, esp ones of
"java's better" attitude, before you start to write a reply to an unfounded
critique. Fighting someone else's straw man makes no sense at all.

[1] 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] Re: Constraints for generics

[K Davidson]

Hi,

Just a couple of friendly notes / impressions: I couldn't help but notice 
how many new gramars, or additions would need to be added to the language 
in order to support a feature aiming to be simple, in a language where one 
of the top driving goals it to be as simple as possible. Also no built in 
types would be able to satisfy both of the constraints, because you can't 
declare methods on builtin types in order to satisfy the interface. 
Lastly, remember this code:

package main

import (
"fmt"
)

type word string

func main() {
var x word = "hello"

var z string = x
}

Wont compile, with the message:

"cannot use w (type word) as type string in assignment"

But:



package main

import (
"fmt"
)

type word string

func main() {
var w word
w = "What am I?"
var z string

fmt.Printf("w is a: %T. z is a %T.\n", w, z)

Does, and prints out:

w is a: main.word. z is a string.

( Runnable example: https://play.golang.org/p/wek23WOXNEJ )

Because they are two different things, It would be akin to attempting to 
assign an int value to a var of type uint16.




-- 
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] cgo use question

[Scott Cotton]

Hi all,

For info, short of a solution for linking cgo specific C functions cross 
package, I think one can do this with C function pointers, which at least 
is a close approximation of directly calls.

Best,
Scott

On Sunday, 30 September 2018 14:08:28 UTC+2, Scott Cotton wrote:
>
> Thanks 
>
> In my case, believe it or not -- and for a very particular use case, 
> I cannot call the shared C functionality from Go, it must be called 
> from C. And I want to avoid telling consumers to use make to create a 
> C library, so that go get and modules will work. 
>
> It looks to me like your solution, at least from the README calls 
> make, and I can't find an example (though I may well have missed 
> something) of shared package specific cgo C code outside of a C 
> library being called by C in another package. 
>
> Can you clarify if or how your suggestion will meet my requirements (1 
> -- go tool only, no make, 2 -- cgo C function called by C in more than 
> one package)? 
>
> Scott 
> On Sun, 30 Sep 2018 at 13:57, Simon Ritchie  
> wrote: 
> > 
> > Write a separate package to handle the C stuff and call it from the 
> other two. 
> > 
> > I built a wrapper for a  c++ library:  
> https://github.com/goblimey/rplidar_sdk_go.  The c++ code used various 
> features that defeated cgo, so I ended up with a multi-layered solution. 
> > 
> > One thing I discovered is that cgo has a nasty habit of rewriting the Go 
> code that calls C code, including trampling on your comments, so keeping 
> that code in  a separate layer is a good idea. 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> Google Groups "golang-nuts" group. 
> > To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/ruLltGrPWBg/unsubscribe. 
> > To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Scott Cotton 
> http://www.iri-labs.com 
>

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

Re: [go-nuts] using 'go function_call()' inside Go program

[Hemant Singh]

Hi Justin,


Got it - thanks much!

Hemant

On Saturday, September 29, 2018 at 11:58:30 PM UTC-4, Justin Israel wrote:
>
>
>
> On Sun, Sep 30, 2018 at 3:47 PM Hemant Singh  > wrote:
>
>> I have a question.  I have changed the open goping.go code to return 
>> error from functions. 
>>
>> The following function is implemented in a .goping.go file.
>>
>> func ping(config *Config, address, name string, pattern *regexp.Regexp) 
>> error {  }
>>
>> Another function shown below, in the same .go file, calls 'go ping()'.  
>> As one can see above, the ping function returns an error.  How do I change 
>> the 'go ping()' code below to grab the error returned from calling ping()?  
>> I could also use a URL to where a description exists for using 'go 
>> function_call' inside a Go program.
>>
>> func ping_main(address string) error {
>> go ping(config, address, "DstIP", LATENCY_PATTERN)
>> }
>>
>
> In this current form, it is not possible to grab the error because you are 
> not waiting on the ping() to finish when you call it asynchronously in a 
> goroutine. If you need the error, the most obvious thing to do is to call 
> it in a blocking fashion:
>
> func ping_main(address string) error {
> return ping(config, address, "DstIP", LATENCY_PATTERN)
> }
>
> ​
>
> But if you need to call it in a non-blocking way, then you have to arrange 
> a way to receive the error value later once the ping is complete. Wrapping 
> the existing ping() function might be a way to go:
>
> func ping_main(address string) <-chan error {
> err := make(chan error, 1)
> go func() {
> err <- ping(config, address, "DstIP", LATENCY_PATTERN)
> }()
> return err
> }
>
> ​
>
> This means the ping still runs in a non-blocking way, but will report the 
> return value when it is complete.
>  
>
>>
>> Best,
>>
>> Hemant
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] cgo use question

[Scott Cotton]

Thanks

In my case, believe it or not -- and for a very particular use case,
I cannot call the shared C functionality from Go, it must be called
from C. And I want to avoid telling consumers to use make to create a
C library, so that go get and modules will work.

It looks to me like your solution, at least from the README calls
make, and I can't find an example (though I may well have missed
something) of shared package specific cgo C code outside of a C
library being called by C in another package.

Can you clarify if or how your suggestion will meet my requirements (1
-- go tool only, no make, 2 -- cgo C function called by C in more than
one package)?

Scott
On Sun, 30 Sep 2018 at 13:57, Simon Ritchie  wrote:
>
> Write a separate package to handle the C stuff and call it from the other two.
>
> I built a wrapper for a  c++ library:  
> https://github.com/goblimey/rplidar_sdk_go.  The c++ code used various 
> features that defeated cgo, so I ended up with a multi-layered solution.
>
> One thing I discovered is that cgo has a nasty habit of rewriting the Go code 
> that calls C code, including trampling on your comments, so keeping that code 
> in  a separate layer is a good idea.
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/ruLltGrPWBg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Scott Cotton
http://www.iri-labs.com

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

[go-nuts] cgo use question

[Simon Ritchie]

Write a separate package to handle the C stuff and call it from the other two.

I built a wrapper for a  c++ library:  
https://github.com/goblimey/rplidar_sdk_go.  The c++ code used various features 
that defeated cgo, so I ended up with a multi-layered solution.

One thing I discovered is that cgo has a nasty habit of rewriting the Go code 
that calls C code, including trampling on your comments, so keeping that code 
in  a separate layer is a good idea.

-- 
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] Constraints for generics

[Robert Engels]

The static switch is a big problem. For any complex method you are going to 
completely duplicate all of the code. Not good. 

Far better to map operators to interfaces then you only need a single method 
implementation. 

> On Sep 30, 2018, at 5:33 AM, Christian Surlykke  wrote:
> 
> Hi 
> 
> I made a proposal for generics with constraints about ½ a year ago, which I 
> posted to the (very long) thread on issue 15292. I've now made a version 2, 
> in case anybody would like to read it. 
> 
> This version adapts to the generics syntax now proposed by the Go team and is 
> somewhat simpler than the previous version.
> 
> br. Chr.
> -- 
> 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] Announcing pytogo. a crude but surprisingly effective Python to Go translator

[Eric Raymond]

I have mentioned before on this list that I am engaged in source 
translation of a largeish Python prgram - 14KLOC - to Go.  I found the 
automated AST-based translation tools already available unsatisfactory; 
they don't produce a quality of Go code I would consider maintainable.  So 
I wrote my own using crude, old-school regexp-bashing.

This turned out to be surprisingly effective.  The following is from the 
manual page:

* Opens Python block scopes with { and closes them with }.

* Changes docstrings to comments.

* Changes comments from #-led to //-led

* Translates Python boolean constants True, False to Go true, false

* Translates Python "in range" to Go ":= range",  You will need to fix
  up the comma and range clauses by hand.

* Maps Python single-quote literals to Go double-quote literals.

* Translates Python logical connectives and or not to Go && || !.

* Changes Python None to Go nil.

* Changes "def " at the left margin to "func ".

* Common cases of various Python string library methods - capitalize(), 
count(), endswith(), find(), join(), lower(), lstrip(), rfind(), replace(), 
rstrip(), split(), startswith(), split(), upper() - are translated to Go 
string library calls.

* Some common Python standard library calls, notably from os and 
os.filepath, are translated into Go equivalents. The result is not  
guaranteed to be perfectly correct; a Python call that throws a signal on 
failure may map into a Go function with an error return. But it will always 
be a step in the right direction, and the Go compiler will respond with 
indicative error messages.

* The append() method of Python is translated to a call to Go's append 
intrinsic.

* Python's "del foo[bar]" is translated to Go "delete(foo, bar)". Note that 
this can false-match on a list del with a numeric key; this
  will throw a compilation error in Go and you can hand-fix it.

* Trailing line-continuation backslashes are removed.

* Python r-prefix string literals become Go backtick literals

* Python try/finally/catch become pseudo-statements with delimited block 
scopes.  You will need to fix these up by hand.

* Single-line % expressions with a string-literal left hand and either 
tuple or single-variable right hands are translated into fmt.Sprintf 
calls.  You will need to translate %-cookies by hand; %r -> %v or %q is the 
usual trouble spot.

* Changes multiline strings to backtick literals. You'll need to fix up 
backslash escapes and %-cookies yourself.

* Many, but not necessarily all, cases where Go ":=" assignment can replace 
a plain "=" assignment in Python are translated.

This doesn't do a complete job, of course.  But it takes a lot of the pain 
out of hand-translation, and it does preserve comments and structure.  
Probably the automated block scope closing is the biggest single win; 
that's a tedious, fiddly job by hand and mistakes are all too easy.

Future releases will translate a larger subset of Python standard library 
calls.

The repository is at https://gitlab.com/esr/pytogo and the project home 
page at http://www.catb.org/esr/pytogo/

-- 
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] Constraints for generics

[Christian Surlykke]

Hi 

I made a proposal for generics with constraints about ½ a year ago, which I 
posted to the (very long) thread on issue 15292. I've now made a version 2 
, in 
case anybody would like to read it. 

This version adapts to the generics syntax now proposed by the Go team and 
is somewhat simpler than the previous version.

br. Chr.

-- 
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 this implementation of weak pointers safe?

[Tamás Gulácsi]

2018. szeptember 30., vasárnap 6:20:37 UTC+2 időpontban Ben Lubar a 
következőt írta:
>
> On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote:
>>
>> Quoting Ben Lubar (2018-09-29 14:40:28) 
>> >[1]https://play.golang.org/p/iBAii-f84Sq 
>> >vet is complaining because the unsafe.Pointer usage would normally 
>> be 
>> >dangerous around the garbage collector, but since I have a finalizer 
>> on 
>> >the "real" pointer and there is no way the code could access the 
>> >uintptr with the same value as the real pointer once the finalizer 
>> has 
>> >run or been removed by Close, shouldn't this code be safe? 
>>
>> From the unsafe package's documentation: 
>>
>> > Even if a uintptr holds the address of some object, the garbage 
>> > collector will not update that uintptr's value if the object moves 
>>
>> One valid implementation strategy for a garbage collector is to do arena 
>> allocation, and on a GC pass copy all *live* objects out of an arena 
>> into another one for longer-lived objects, and then free the old arena. 
>> In this case, your uintptrs would still still contain the old addresses, 
>> even though the objects have moved. Note that the finalizer is never run 
>> in this case, because the object has been moved without being garbage. 
>>
>> Whether what you're doing is actually safe depends heavily on the 
>> implementation details of the garbage collector. It may or may not 
>> be possible for it to break given the current implementation; 
>> I don't know enough about it to be sure. But a correct implementation 
>> of the runtime could very well corrupt memory given the code you 
>> linked; even if it works now, it's possible in a future release of 
>> Go this could break. 
>>
>> Hope this helps, 
>>
>> -Ian 
>>
>
> Is there any way to implement this safely, or should I just give up on the 
> weak pointer idea?
>


What will your *Session keep from getting collected if you have only weak 
pointers to it? Nothing.

What are you trying to achieve?

You have Session.Close. Why not have it clean up after itself - even from 
the session registry?
Just have a "sessions=make(map[SessionID]*Session)", and do a 
"sessionsMtx.Lock(); delete(sessions, sess.id); sessionsMtx.Unlock()" in 
Session.Close.

A WeakValueMap would eliminate the need of this explicit cleanup, but we 
don't have weak maps in Go.
And Finalizers are totally unreliable - you don't know when will they be 
called, if called at all.

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