Re: [go-nuts] Overriding cgo version

[James Pettyjohn]

Ya, it's noted in there it was for tests only. I think that should be a 
part of the build env, not the source. I've rolled back for now.

On Wednesday, April 26, 2017 at 5:06:57 PM UTC-7, Ian Lance Taylor wrote:
>
> [ + mpvl ] 
>
> On Wed, Apr 26, 2017 at 4:39 PM, James Pettyjohn  > wrote: 
> > I just updated my dependency on golang.org/x/text and found they added 
> a 
> > hard depedency on ICU 57. 
> > 
> >> ld: library not found for -licui18n.57 
> >> clang: error: linker command failed with exit code 1 (use -v to see 
> >> invocation) 
> > 
> > 
> > Trying to build this on a mac where homebrew installed icu4c as it 
> brings in 
> > icu 58. 
> > 
> > This appears to be caused by 
> > https://github.com/golang/text/blob/master/cases/icu.go#L16 . 
> > 
> > Is there a way to override this at compilation time? 
>
> No.  It's just a test, though.  Perhaps there needs to be a simple way 
> to disable, or to enable, that test. 
>
> Ian 
>

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

[go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

[mhhcbon]

I like it too, i'm only worried by the size of the app once everything it 
setup.

I wonder if its not possible to have something smaller,
obviously with less capabilities.

imho, i m interested mostly in window positioning and decoration.
Communication is less interesting to me as i can work with http apis, or so.

any ideas ?

On Tuesday, April 25, 2017 at 9:54:22 PM UTC+2, Asticode wrote:
>
> Hi everyone,
>
> I'm happy to announce astilectron, a GO library to build cross platform GUI 
> apps in HTML/JS/CSS: https://github.com/asticode/go-astilectron
>
> I needed a way to build a cross platform GUI app in GO but none of the 
> projects out there were meeting my needs (they were either only 
> MacOSX-compatible or not maintained anymore). At the same time, I knew about 
> Electron which is cross-platform and well maintained. So I did the maths and 
> took a shot at creating a ligthweight library that could rely on Electron and 
> be available in GO.
>
> I've started it this week-end so this is still in beta but in a nutshell, 
> here's what it already does:
>
> - on start it provisions the necessary dependencies (electron and a custom 
> electron app I've made in NodeJS that provides an API over TCP). This means 
> that worst case scenario it downloads the distributions and unzips them. Best 
> case scenario (and thanks to the possibility of setting your own Provisioner) 
> you can embed the distributions in your binary using go-bindata and only 
> unzip them if they're not already set up.
> - then you're good to go and can create windows and interact with them: move, 
> resive, maximize, close, etc.
> - each window is a browser therefore you can either load static .html files, 
> a remote URL or the local GO server you've just started :D
> - you can communicate between your GO app and the javascript in you server
> - did I mention this is cross-platform? :D
>
> Here's the architecture of the project:
>
> +-+TCP+-+IPC   
> +-+
> + your GO app |<->+ custom Electron app +<>+ win1: 
> (HTML/JS/CSS) +
> +-+   +-+ |
> +-++
>   | | +>+ win2: 
> (HTML/JS/CSS) +
>   | +--+||  
> +-++
>   +-+ Electron +++-->+ win3: 
> (HTML/JS/CSS) +
> +--+ 
> +-+
>
> I'd like to use this beta version to see if people are interested in that 
> sort of project. If so, I'll dedicate more hours to add more features. Let me 
> know in the comments section.
>
> Of course I welcome any kind of contributions, may it be finding bugs or 
> proposing enhancements.
>
> Long live Golang!
>
> Cheers
> Asticode
>
>

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

[go-nuts] [ANN][wip] plumber: builds pipes to transform a data stream

[mhhcbon]

Hi,

*Purpose*

builds pipes to transform a data stream.
It comes with a generator to avoid you some copy paste, 
and provide a standard bytes stream to get started with []byte.

*Example*

Following example reads a source of []byte, os.Stdin, 
as a list of versions, one per line, 
manipulates and transforms the chunks 
until the data is written on the sink, os.Stdout.


//Package cmd implement a cli tool to manipulate Versions.
package main

import (
"os"

"github.com/mh-cbon/semver/cmd/stream"
)

func main() {

src := os.Stdin

pipeSrc := stream.NewByteReader(src)
pipe := pipeSrc.
Pipe(stream.NewBytesSplitter(' ', '\n')).
Pipe(&stream.BytesTrimer{}).
Pipe(&stream.VersionFromByte{SkipInvalid: true}).
Pipe(&stream.VersionSorter{Asc: true}).
Pipe(&stream.LastVersionOnly{}).
Pipe(&stream.VersionToByte{}).
Pipe(stream.NewBytesPrefixer("- ", "\n"))

pipe.Sink(stream.NewByteSink(dest))

if err := pipeSrc.Consume(); err != nil {
panic(err)
}
os.Exit(0)
}


*URL*
https://mh-cbon.github.io/plumber/
https://github.com/mh-cbon/plumber

*WIP?*

yeah, let s write tests ect when its needed.


HTH

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

[go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

[Asticode]

I do agree with you regarding the size of the app once everything is setup.

Honestly chosing Electron is more a choice by default than anything else.

imo the chosen project should:

- be cross platform
- be well maintained
- allow creating non-native looks through HTML/JS/CSS since I think it's 
the easiest for the most of us

Here's a list of what I've tried so far:

- https://github.com/andlabs/ui : drawbacks are it has limited features, 
force you to have a native look and can't do things like capturing the 
"Enter" key event in an input box
- https://github.com/miketheprogrammer/go-thrust : drawback is it's not 
maintained anymore
- https://github.com/alexflint/gallium : drawback is it's not 
cross-platform (only MacOSX last time I checked)
- https://github.com/murlokswarm/app : drawback is it's not cross-platform 
(only MacOSX too)
- https://github.com/arvitaly/gopherjs-electron : drawback is it's not 
maintained anymore
- https://github.com/rrohrer/go-electroncontrol : drawback is it's not 
maintained anymore
- https://github.com/nodekit-io/nodekit : drawback is it's not maintained 
anymore

As you can see none of them meet the 3 requirements.

Which leaves us with Electron which is cross platform, well maintained and 
allow creating non-native looks through HTML/CSS/JS.

If there are other projects I've missed, feel free to let me know, once 
again chosing Electron is more of a choice by default than anything else.

PS : if you're only interested in window positioning and decoration, and 
don't care about dealing with HTML/CSS/JS I recommend using 
https://github.com/andlabs/ui which is an awesome project!


Le jeudi 27 avril 2017 11:33:10 UTC+2, mhh...@gmail.com a écrit :
>
> I like it too, i'm only worried by the size of the app once everything it 
> setup.
>
> I wonder if its not possible to have something smaller,
> obviously with less capabilities.
>
> imho, i m interested mostly in window positioning and decoration.
> Communication is less interesting to me as i can work with http apis, or 
> so.
>
> any ideas ?
>
> On Tuesday, April 25, 2017 at 9:54:22 PM UTC+2, Asticode wrote:
>>
>> Hi everyone,
>>
>> I'm happy to announce astilectron, a GO library to build cross platform GUI 
>> apps in HTML/JS/CSS: https://github.com/asticode/go-astilectron
>>
>> I needed a way to build a cross platform GUI app in GO but none of the 
>> projects out there were meeting my needs (they were either only 
>> MacOSX-compatible or not maintained anymore). At the same time, I knew about 
>> Electron which is cross-platform and well maintained. So I did the maths and 
>> took a shot at creating a ligthweight library that could rely on Electron 
>> and be available in GO.
>>
>> I've started it this week-end so this is still in beta but in a nutshell, 
>> here's what it already does:
>>
>> - on start it provisions the necessary dependencies (electron and a custom 
>> electron app I've made in NodeJS that provides an API over TCP). This means 
>> that worst case scenario it downloads the distributions and unzips them. 
>> Best case scenario (and thanks to the possibility of setting your own 
>> Provisioner) you can embed the distributions in your binary using go-bindata 
>> and only unzip them if they're not already set up.
>> - then you're good to go and can create windows and interact with them: 
>> move, resive, maximize, close, etc.
>> - each window is a browser therefore you can either load static .html files, 
>> a remote URL or the local GO server you've just started :D
>> - you can communicate between your GO app and the javascript in you server
>> - did I mention this is cross-platform? :D
>>
>> Here's the architecture of the project:
>>
>> +-+TCP+-+IPC   
>> +-+
>> + your GO app |<->+ custom Electron app +<>+ win1: 
>> (HTML/JS/CSS) +
>> +-+   +-+ |
>> +-++
>>   | | +>+ win2: 
>> (HTML/JS/CSS) +
>>   | +--+||  
>> +-++
>>   +-+ Electron +++-->+ win3: 
>> (HTML/JS/CSS) +
>> +--+ 
>> +-+
>>
>> I'd like to use this beta version to see if people are interested in that 
>> sort of project. If so, I'll dedicate more hours to add more features. Let 
>> me know in the comments section.
>>
>> Of course I welcome any kind of contributions, may it be finding bugs or 
>> proposing enhancements.
>>
>> Long live Golang!
>>
>> Cheers
>> Asticode
>>
>>

-- 
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] Strange Go runtime behavior related to xml.Unmarshal

[Nikos Anastopoulos]

Hi list, 

I have a Go app that, among others, continuously parses XML files to 
extract dynamic info. This seems to cause a strange behavior in the Go 
runtime, according to which the underlying Go threads keep increasing over 
time. 

I verified this by commenting out several parts of my app code, coming up 
to a minimal working version which essentially calls xml.Unmarshal 
repetitively. You can have a look at it here: 
https://gist.github.com/anastop/e533628e5624c81b8822fda512aefaab

When executing this minimal version on my platform (Ubuntu 16.04.2, Xeon 
E5-2699 / 88 CPUs, go1.8), I observe that it starts with 4 Linux threads in 
total and within 4 minutes it reaches e.g. 28 (and goes up), which is 
unusual w.r.t. what I observe with other Go apps. The problem becomes even 
worse when this code becomes part of my larger app, where I have observed 
Go thread counts reaching up to several hundreds (e.g. 300-400).

Just to mention that I do not see any other strange behavior like increase 
in memory usage. 

As I want this app to introduce a minimal level of noise to other 
co-running apps, I am wondering whether this is a known/expected behavior, 
or I should resort to other workarounds to meet my requirements. 

Thanks in advance, 
Nikos

-- 
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: Recover considered harmful

[Johan Bolmsjö]

Den måndag 24 april 2017 kl. 11:02:55 UTC+2 skrev Sokolov Yura:
>
> I want to ask:
> - how useful `recover` for you?
>

In one piece of code it was extremely handy. A TLV protocol decoder taking 
a bytes buffer as input. The TLVs could be nested so TLVs containing TLVs 
etc. Instead of manually bounds checking each TLV i just relied on the out 
of bounds checking provided by Go. In the top level decode function I 
recovered the out of bounds panic raised by the run time and converted it 
to an error that was returned the usual way. So yea, basically excpetions 
:-)
 

> - Don't you think it is a bit "dangerous"?
>
> No, but in my own "library code" I have never called panic without 
internally caught it with recover and converter it to an error. I don't 
count bounds checking panics etc as I count those as bugs (with the 
exception of the example above).
 

-- 
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] google-api-go-client: drive/v3 - remove file properties or appProperties

[Sylvain Rouquette]

Hello,

I'm using the google drive api v3 for Go to send requests (update), and I'm 
trying to remove appProperties I created on a file.

Here is the comment from drive-gen.go:
type File struct {
// AppProperties: A collection of arbitrary key-value pairs which are
// private to the requesting app.
// Entries with null values are cleared in update and copy requests.
AppProperties map[string]string `json:"appProperties,omitempty"`

I guess this comment is a copy from other implementation, since you can't 
nil a string in Go, or maybe it means that if appProperties is nil, it is 
completely removed.

I tried to use NullFields and ForceSendFields, but based on the 
implementation, it seems to only works on keys (like appProperties) in the 
file when it is serialized, and it doesn't parse recursively.

Is there a way to remove a property?

-- 
 

*"This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
sender immediately"*

-- 
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: Recover considered harmful

[Jesper Louis Andersen]

On Wed, Apr 26, 2017 at 10:55 AM Peter Herth  wrote:

>
> No, panic certainly does not do that. It prints the stack trace. A proper
> logger could add additional information about the program state at the
> point of the panic, which is not visible from the stack trace. It also
> might at least be reasonable to perform an auto-save before quitting.
>
>
Additional comments in a haphazard order:

It makes sense to accept a panic() in a Go program will have some
collateral requests being taken down as a consequence. This argument can be
extended however. Since the operating system kernel might be wrong, it is
better to halt the operating system whenever a Goroutine panics. After all,
the logic seems, who can be sure the operating system forget to release a
Mutex lock? And why stop there? The hardware on which you are running may
have a failure. Better replace that whenever a goroutine panics!

In practice---I think this is due to work by Peter J. Denning
originally---we use process isolation at the OS level to guard against such
failure. We ought to use a layered model, where each layer guards the
layers below it. There is a 7 year old blogpost I wrote on the subject, in
which I used an onion as a metaphor for the model[0], and it is one of the
blog posts which have had more readers than other posts.

In general, failure is something you ought to capture for post-mortem
analysis. Get the core-dump, push it into your blob store, restart the
process and then attach a debugger to the blob to figure out what is wrong.
In my experience, it is also important to have access to the memory state
of the program in addition to the backtrace if the problem is complex.

What Erlang people acutely understands is that the granularity of failure
matter. A single request failing in a system is, usually, localized to that
single request. If, however, we have a situation as Roger Pepper mentions
where a mutex is locked, the failure of single requests should at some
point escalate to larger parts of the system. This is where the concept of
a "restart strategy" in Erlang systems are necessary: more than K failures
in a time-frame window of W increases the granularity and resets larger
parts of the system. Eventually, the whole node() resets, which is akin to
a Go panic() which isn't getting caught. The advantage is that the size of
the failure determines its impact: small errors have small impact. Large
errors have large impact.

Dave Cheney touches on another important point: if you care about requests
and a panic in one Go process can make other requests running collaterally
fail, then you should build your load balancer such that it retries the
requests on another worker[1].

Yet another point worth mentioning is that a panic() can have a large
recovery time for a process. If you have a large heap of several hundred
gigabytes of data, reestablishing such heap after a failure might take a
long time. Thus, it can be beneficial to restart parts of the system at a
finer granularity first, before resorting to rebooting the full process.
Likewise, if a system knows it is in a bad state, it is often faster to
report said state to the load-balancer rather than relying on it eventually
figuring it out. Depending on your SLA, you may fail many requests in the
mean time and this may affect your reliability measure. This is especially
true if your system has a high processing rate of requests, which makes it
far more sensitive to latency fluctuations.

So what is a Go programmer to do? The solution, at least from my view, is
to use the 'context' package to establish a tree of work-areas for
different parts of the Go program. Failure in one tree can then be handled
by failing a given context, and if the system can clean up, you can
continue operating. The question is, then, what to do with cross-cutting
concerns where one context talks to the goroutines of another context in
the tree. My guess is you signal that by closing channels appropriately,
but I'm not sure. Erlang systems provide a monitor-concept for this very
situation, in which you can subscribe to the lifetime of another part of
the system. If it fails, a message is sent to you about its failure so you
can take action.

[0]
http://jlouisramblings.blogspot.dk/2010/11/on-erlang-state-and-crashes.html

[1] Beware of a "poisonous" request however! A single bad request that
panics a system and then getting retried in the load balancer can easily
take down all of your backend worker pool.

-- 
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: Recover considered harmful

[mhhcbon]

>
> Most languages, who stick with Exceptions, usually has two kind of 
> exceptions:
> - "exception for regular error", i.e. wrong input, wrong system state, or 
> for "control flow"
> - and "fatal exceptions",
>

agree to that. 
Current error management is not satisfying and pushes the community to find 
a convention**, 
unfortunately it seems impossible to reach, 
the only one who made things goes forward is Dave Cheney with pkg/errors.

** One might say, by now all errors must implement IsFatal so that the 
consumer can determine the severity of error it is dealing with.
It is not impossible to do today, but two packages not written together 
with this rule in mind won t match.
And consensus has not come, so we are left with a broken leg.

PS: panic is just another capability provided, there s no need to fell into 
some dogma like `never use it`,
like everything else in go, use it with care, or panic and fix it.

On Wednesday, April 26, 2017 at 7:30:36 AM UTC+2, Sokolov Yura wrote:
>
> It looks like there is two point of view:
>
> - optimists who never used to build mutable shared state by them self, and 
> they hope libraries they use also don't use mutable shared state,
> - and those who know that mutable shared state usually exists.
>
> In absence of mutable shared state it is perfectly valid to recover to 
> immitate what PHP or Erlang does. But PHP and Erlang has real "process" 
> isolation, and they tend to not recover cause conurrent requests are really 
> "not affected".
>
> Erlang's philosophy is "let it crash" cause there is always "superwiser" 
> in a separate isolated "process" who will respawn "worker process".
>
> PHP will let whole process to crash if it meets C-level "assert" cause 
> process doesn't serve more than one request at time, and there is also 
> always a superwiser who will spawn new process to serve requests.
>
> But in Go you have no such support from runtime. So, you have to inspect 
> all third-party libraries to check they doesn't have mutable shared state, 
> if you want to `recover`. But if you did inspect them, then why didn't you 
> prevent them from 'panic'? Why did you pass input that leads to panic you 
> "allowed to recover"? You didn't test your program enough?
>
> Most languages, who stick with Exceptions, usually has two kind of 
> exceptions:
> - "exception for regular error", i.e. wrong input, wrong system state, or 
> for "control flow"
> - and "fatal exceptions",
> First kind of exceptions are safe to catch and recover from.
> Second kind is always documented as "you'd better crash, but don't recover 
> from it". They usually have separate inheritance root, so regular 'catch' 
> doesn't catch them (some exceptions even checked by runtime to not be 
> catched). And everyone in safe mind will not catch those exceptions.
>
> Go says:
> - first kind is just an error. Return error, analyze error, rereturn 
> error, and you will be happy, and your hair will shine.
> - Second kind is... yeah, it should be panic. You'd better not recover. 
> But you know what... I'm sometimes use it for control flow... and I do 
> recover in 'net/http' cause I pretend to be new PHP... So, you have no 
> "blessed way" to "fatal error". Go ahead, and do your own "super-panic" 
> with "debug.PrintStack(); os.Exit(1)".
>
> I'm sad falcon.
>
> PS. To be fair, "fatal exceptions" usually allows to eval `finally` 
> statements, so my point for "optimize defer in absence of recover" is not 
> perfectly valid.
>
> 26 апр. 2017 г. 7:24 AM пользователь "Chris G"  > написал:
>
>>
>>
>> On Tuesday, April 25, 2017 at 7:52:25 PM UTC-7, Dave Cheney wrote:
>>>
>>> > Yes, and then crashes the program. In the scenario I described, with 
>>> thousands of other requests in flight that meet an abrubt end.  That could 
>>> be incredibly costly, even if it's been planned for
>>>
>>> There are a host of other reasons that can take a server offline 
>>> abruptly. It seems like a odd misallocation of resources to try to prevent 
>>> one specific case - a goroutine panics due to a programming error or input 
>>> validation failure -- both which are far better addressed with testing.
>>>
>> There's a cost benefit analysis to be done, for sure, but I don't always 
>> believe it to be a misallocation of resources.  I don't believe it's costly 
>> for every program, and for programs where it's important, I don't believe 
>> it to always be a hard problem to accomplish.  To your point, for a great 
>> many programs, the effort probably isn't worth the reward.
>>  
>>
>>> To try to postpone the exit of a program after a critical error to me 
>>> implies a much more complex testing and validation process that has 
>>> identified all the shared state in the program and verified that it is 
>>> correct in the case that a panic is caught.
>>>
>> Not always applicable, but there are some relatively easy ways of coping 
>> with that:
>> - Don't have shared state to begin with (for a large number of programs, 
>> this i

[go-nuts] Re: google-api-go-client: drive/v3 - remove file properties or appProperties

[Sylvain Rouquette]

I don't think there is a solution with the current implementation, I 
reported the bug.
https://github.com/google/google-api-go-client/issues/201

-- 
 

*"This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
sender immediately"*

-- 
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] Change imaginary part of a complex

[Val]

Thank you Thomas for insight!

On Thursday, April 20, 2017 at 10:21:23 PM UTC+2, Thomas Bushnell, BSG 
wrote:
>
> The other way is to add the c to its conjugate and then add the imaginary 
> part, using cmplx.Conj. But that really amounts to what you're doing 
> already.
>
> On Thu, Apr 20, 2017 at 3:20 AM Val > 
> wrote:
>
>> Hello folks
>> To keep real part of a complex, and set its imag part, I'm doing
>>   c = complex(real(c), -5.0)
>>
>> Is there a more concise way, something like   c.imag = -5.0  ? I know 
>> this one doesn't compile, but I may be missing something obvious.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[go-nuts] Errors from Gob

[Chris Hopkins]

So amusingly I've just had Gob report the following error:

panic: write gob_fetch.txt: host is down

It referring to a file as a host is of course understandable but it's a 
little troublesome because as far as I can tell the file should be 
perfectly writable having just been created and checked for errors on 
os.Create a few lines earlier.
I have a vague memory that there was a package someone major in the Go 
project wrote to create an error stack. I guess this hasn't been ported to 
the whole standard library given the above error.

What's the current thinking on this sort of error handling? It's hard to 
say "Handle errors properly" when the standard library is butchering the 
original error message. Or is there a way to extract the source error 
message that I am missing? [at the moment I'm just doing a panic(err)]

Thanks

Chris

-- 
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] docker multi-stage builds and small binary sizes

[Sankar]

Anyone aware of links explaining if-we-can/how-to create lean containers 
for golang http servers by using the new multi-stage build options in 
Docker ? Similar to: https://codefresh.io/blog/node_docker_multistage/ 

That would be very handy than doing GOOS=linux builds and then copying the 
binary in to a docker SCRATCH/Alpine container.

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: Oracle db and panics on interrupt

[Didier Spezia]

I'm not sure it can help with the problem, but starting with Oracle 11, OCI 
installs some custom signal handlers (even catching segmentation faults).
They can be deactivated by setting options in the sqlnet.ora file.
Here, we run all our OCI clients with:

DIAG_SIGHANDLER_ENABLED=FALSE
DIAG_ADR_ENABLED=FALSE
DIAG_DDE_ENABLED=FALSE

Regards,
Didier.


On Wednesday, April 26, 2017 at 10:25:09 PM UTC+2, Tamás Gulácsi wrote:
>
> 2017. április 26., szerda 20:33:13 UTC+2 időpontban Pierre Curto a 
> következőt írta:
>>
>> Hello,
>>
>> I am unsure where to log the following issue:
>> whenever I send an interrupt signal to a go process running an Oracle 
>> query, it panics with either "fatal: morestack on g0" or "fatal error: 
>> runtime: stack split at bad time".
>>
>> A sample code reproducing the issue is here 
>> . Of course an Oracle instance and 
>> libs are required for it to work.
>>
>> Should it be reported to the maintainers of the Oracle package or the Go 
>> team?
>> It seems to me it should be the later, but I want to make sure.
>>
>
> You can report it at rana/ora, but I'll ask it here anyway: is this 
> avoidable?
> My first instinct says no, we don't know what interrupt handlers are in 
> use in the OCI library - maybe re-install/shield some after instantiating 
> the library? 
>

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

[go-nuts] Re: Errors from Gob

[hbhaskaran]

> should be perfectly writable having just been created and checked for 
errors on os.Create a few lines earlier

past performance is not a predictor of future results :p

are you writing to an NFS mount point?


On Thursday, April 27, 2017 at 8:55:36 AM UTC-7, Chris Hopkins wrote:
>
> So amusingly I've just had Gob report the following error:
>
> panic: write gob_fetch.txt: host is down
>
> It referring to a file as a host is of course understandable but it's a 
> little troublesome because as far as I can tell the file should be 
> perfectly writable having just been created and checked for errors on 
> os.Create a few lines earlier.
> I have a vague memory that there was a package someone major in the Go 
> project wrote to create an error stack. I guess this hasn't been ported to 
> the whole standard library given the above error.
>
> What's the current thinking on this sort of error handling? It's hard to 
> say "Handle errors properly" when the standard library is butchering the 
> original error message. Or is there a way to extract the source error 
> message that I am missing? [at the moment I'm just doing a panic(err)]
>
> Thanks
>
> Chris
>
>

-- 
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: Oracle db and panics on interrupt

[Tamás Gulácsi]

2017. április 27., csütörtök 18:18:19 UTC+2 időpontban Didier Spezia a 
következőt írta:
>
>
> I'm not sure it can help with the problem, but starting with Oracle 11, 
> OCI installs some custom signal handlers (even catching segmentation 
> faults).
> They can be deactivated by setting options in the sqlnet.ora file.
> Here, we run all our OCI clients with:
>
> DIAG_SIGHANDLER_ENABLED=FALSE
> DIAG_ADR_ENABLED=FALSE
> DIAG_DDE_ENABLED=FALSE
>
> Regards,
> Didier.
>
>>
>>
Thanks a lot, Didier! 

-- 
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: Recover considered harmful

[Dave Cheney]

The take away for me is; prefer returning an error to to caller wherever 
possible. Overuse of panic begats overuse of recover and that just leads to 
more problems [1].

1. https://github.com/golang/go/issues/13879

-- 
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] terminal package that utilize io.ReadWriter

[Vasiliy Tolstov]

I have some ReadWriter stream interface, that utilize custom rpc to
send/recv data from/to endpoint.
I need terminal package to run on client that understand standard
terminal escape symbols and can be used with ReadWriter interface.
On another end of enpoint runned bash.

I'm try ssh/terminal package but when i'm use it and enter date
command i get something like:
[root@143177 ~]# [root@143177 ~]# [root@143177 ~]# [root@143177 ~]#
date[root@143177 ~]# [root@143177 ~]# [root@143177 ~]# bash:
[root@143177: command not found[root@143177 ~]# [root@143177 ~]#
[root@143177 ~]# bash: [root@143177: command not found[root@143177 ~]#
[root@143177 ~]# [root@143177 ~]# bash: [root@143177: command not
found[root@143177 ~]# [root@143177 ~]# [root@143177 ~]# datebash:
[root@143177: command not found[root@143177 ~]# [root@143177 ~]#
[root@143177 ~]# bash: [root@143177: command not found[root@143177 ~]#
[root@143177 ~]# [root@143177 ~]# [root@143177 ~]#

custom ReadWriter when Read returns recieved data immediately if it
present, writer blocks while write data and returns when all data in
buffer writed.
-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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] Weird performance with exp/shiny

[Zellyn]

I'm sure I'm doing something hideously wrong with shiny, since my emulator 
runs three times faster on my MacBook if I run it under VirtualBox/Ubuntu. 
Yes, you read that right.
Here, I tweeted an animated gif of them running side by 
side: https://twitter.com/zellyn/status/857674501928222720

I ripped out the emulator code and made it simply plot a pixel each frame. 
Here's the result, which still runs much faster under a virtual machine: 
https://play.golang.org/p/par16HK1X2

I'm sure I'm doing the wrong kind of texture update / buffer copy / 
something wrong. Please, educate me! Extra points for explaining enough to 
us all that we could understand what's actually going on.

Thanks,

Zellyn

-- 
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 productive simple conf loader

[zsounder]

goconf 

   - Read configuration automatically based on the given struct's field 
   name.
   - Load configuration from multiple sources
   - multiple file inherit

-- 
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: Mapping restricted types to Go

[alan . t . conway]

This is a MUCH simpler solution. I'm learning:

package main

// AnnotationKey is used as a map key for particular AMQP maps.
// It holds an interface{} which must be either a Symbol or a uint64
type AnnotationKey struct {
value interface{}
}

type Symbol string

func AnnotationKeySymbol(v Symbol) AnnotationKey { return AnnotationKey{v} }
func AnnotationKeyULong(v uint64) AnnotationKey  { return AnnotationKey{v} }
func (ak AnnotationKey) Get() interface{}{ return ak.value }

func main() {
k := AnnotationKeySymbol(Symbol("foo"))
println(k.Get().(Symbol))
k = AnnotationKeyULong(42)
println(k.Get().(uint64))
}


-- 
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] How let go and c code work Alternately in the same thread

[hui zhang]

How let go and c code work Alternately in the same thread with 
goroutine(corouting mechanism)
Check the code below.  c and go code in one thread they just do work 1 by 1.
Expected Result 

> Do CWork
> Do GoWork
> Do CWork
> Do GoWork
> Do CWork
> .


//c code
> void CWork() {
> while(1) {
>--Print Do CWork
>--Coroutine Stop
> --switch to GoWork()
> }
> }
> int main() {
> CWork();
> }
> //go code 
> func GoWork() {
> for {
> --Print Do GoWork
>--Coroutine Stop
> --switch back to CWork()
> }
> }


 

-- 
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: Oracle db and panics on interrupt

[pierre . curto]

Hello,

Thanks a lot indeed, I did not know about those.

I still get crashes on OSX besides the variables being read by the OCI libs 
(traces shows they are).

The other thing is that when this happens, the process goes into an 
infinite loop spitting "fatal: morestack on g0" for ever, and kill -9 is 
the only to put it out of misery. Is *that* expected although I know that 
custom signal handlers break cgo? Shouldnt it just panic and exit?


Le jeudi 27 avril 2017 21:07:35 UTC+2, Tamás Gulácsi a écrit :
>
>
> 2017. április 27., csütörtök 18:18:19 UTC+2 időpontban Didier Spezia a 
> következőt írta:
>>
>>
>> I'm not sure it can help with the problem, but starting with Oracle 11, 
>> OCI installs some custom signal handlers (even catching segmentation 
>> faults).
>> They can be deactivated by setting options in the sqlnet.ora file.
>> Here, we run all our OCI clients with:
>>
>> DIAG_SIGHANDLER_ENABLED=FALSE
>> DIAG_ADR_ENABLED=FALSE
>> DIAG_DDE_ENABLED=FALSE
>>
>> Regards,
>> Didier.
>>
>>>
>>>
> Thanks a lot, Didier! 
>

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