[go-nuts] Re: Deleting the /r/golang subreddit

[Dan Mullineux]

I completely agree with Brad on this.

I also closed my account the day it happened. 

-- 
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: Bloom filter

[Stanislav Paskalev]

Hi xrfang,

Myself and a friend recently wrote https://github.com/solarsea/quorum for a 
hackaton as a proof of concept whether bloom filters can be used as the 
basis for an anonymous voting system. The project includes a floom filter 
implementation (tweaked to show accumulated conflicts) and hash function 
generator based on the pearson hash function.

Free free to fork it away and use it :)

Regards,
Stanislav

On Monday, November 28, 2016 at 6:12:35 PM UTC+2, xrf...@gmail.com wrote:
>
> Hi Will,
>
> Could you please explain the memory characteristics of your 
> implementation? i.e. given boom.New(m, k), how much memory will the filter 
> consume? Is the memory consumption related to number of items in the 
> filter? If appropriate, function such as 
>
> func EstimateParameterByMemory(mem int) (m, k int)
> func (f *BloomFilter) MemoryConsumption() int
>
> will be very useful in my case.
>
> Thank you very much!
>
> xrfang
>
> 在 2011年5月21日星期六 UTC+8下午10:24:05，Will Fitzgerald写道：
>>
>> I've written an implementation of Bloom filters, using the BitSet 
>> package. You can find it at
>>
>> https://github.com/willf/bloom
>>
>> As usual, comments welcome. 
>>
>> Will
>>
>

-- 
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] sharing "go runtime VM" for many go application

[Konstantin Khomoutov]

On Mon, 28 Nov 2016 21:45:16 -0800 (PST)
Thaniyarasu Kannusamy  wrote:

> we all knows that sharing "Linux Kernel" is possible in container
> world. i also want to know further that, 
> is sharing "Go Runtime VM" is possible in anyway ?
> so we can able to share a common "Go Runtime VM" for many go
> application. if that is possible then we can able to run 'Go Runtime
> VM' effectively in serverless architecture.
> 
> i know that 'Go Runtime VM' must be start from a "func main()"

You might be confusing things here.

The first thing to note is that Go implementations I know of do not
currently implement the so-called "free-standing" compilation mode
which would produce executables not requiring a particular kernel to
work.  Instead, the Go runtime which gets linked statically or
dynamically to all the executables produced by Go compilers make heavy
use of the kernel of the underlying host OS.  In particular, it assumes
the kernel implements virtual memory, threads, file and socket I/O,
timers and other stuff. That is, as per your definition, the
"serverless" would not have excluded the kernel itself out of the
picture.

Now, if you're okay with still having the Linux kernel in the picture,
all you need to have a Go program work on a bare kernel is to change
the command line of your kernel to include the

  init=/path/to/your/go/program

string.  After booting, the kernel would run the indicated program as
its "pid 0" process (which is usually something colloquially called an
"init process").  This is really no magic: you will have the kernel and
the single process running on it.  This way, you can have a working
solution consisting of pretty much two or three files: the kernel
image, your executable and (possibly) an initramfs image with the early
boot environment for your kernel.  Pretty much "serverless", I'd say.

But then you should consider what happens if your single process dies
for some reason.  Obviously, if such a setup is intended for sustained
service, you'd need something to monitor your process and restart it.
If that's handled outside your kernel+process combo (say, a container
solution handles this somehow) that's okay; otherwise you'd still need
to have some "not-so-serverless" solution to provide intelligent
restarting of your application and maybe logging.

Now let's move to "the containers".  The only means running programs
interact with the kernel is by using the so-called "system calls" (or
"syscalls" for short).  Leaving aside the question of how they are
actually implemented, the crucial fact about them is that performing a
syscall has noticeable runtime overhead.

What this leads us to is that should you somehow "factored out" the Go
runtime, you'd need to turn it into pretty much the same kind of
"service" the kernel is to the processes: it'd need to implement
something akin to syscalls, and these would have considerable
call overhead -- simply due to the reason you'd need to protect that VM
from the Go processes it powers.

If you're okay with giving up protection (that is, it's okay for any Go
process to crash the VM and bring down the other Go processes running
on it), let's see what is left.  Go runtime basically implements
management of the goroutines -- their requirements for memory (stacks
and heap) and I/O -- and provides a set of library functions.
I fathom the overhead of the Go runtime scheduler in terms of CPU and
memory is not that big so that if you would have just a single instance
of it per N Go processes, it would make any noticeable difference.

You have mentioned sandboxing implemented in node.js.  That could
possibly be done to our imaginary "Go runtime host process" as well but
sandboxing is a very complex stuff, prone to bugs.  Node appears to get
that "for free" -- merely by virtue this stuff is implemented by the JS
engine it piggybacks on (actually, that's the whole reason Node
came to existence: someone got bored enough to notice that a typical
browser's engine these days has support for both JS and networking at
the same time).  I'm not sure it's sensible to tread the same road: the
OS does process separation just OK, and if you want, you have more
powerful stuff to help it -- such as AppArmor/SELinux and seccomp.
In-kernel support for containers (actually, it's all about resource
"namespacing" and having separate limits for them) is essentially also
about "sandboxing" -- just on another level.

To round up, I think you got hooked onto some buzzwords a bit.
The fact node.js does X does not mean X is good or at all needed. ;-)

-- 
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: sharing "go runtime VM" for many go application

[Thaniyarasu Kannusamy]

Thanks for you reply

-- 
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: sharing "go runtime VM" for many go application

[Jason Stillwell]

If your talking about creating a Golang Application Server, where multiple 
unrelated goroutines are running together, and loaded seperately as well. 
This is possible, I suppose, using the new v1.8 plugin architecture. You 
could have the managing central main goroutine load the plugins on demand, 
and kick off the code.

But you'll be missing a lot of standard and vital components from other 
application servers. There will be no real sandboxing. All the plugins will 
be sharing the same memory with no control stopping one from accessing the 
memory and resources of another. Furthermore you wont' be able to unload or 
reload an "application" (plugin). 

Frankly you're better off just running the applications as separate 
processes. You can always whip up an external managing process that starts 
and restarts them, just like init.d of runit

On Monday, November 28, 2016 at 9:47:19 PM UTC-8, Thaniyarasu Kannusamy 
wrote:
>
> we all knows that sharing "Linux Kernel" is possible in container world.
> i also want to know further that, 
> is sharing "Go Runtime VM" is possible in anyway ?
> so we can able to share a common "Go Runtime VM" for many go application.
> if that is possible then we can able to run 'Go Runtime VM' effectively in 
> serverless architecture.
>
> i know that 'Go Runtime VM' must be start from a "func main()"
>
> Thanks
> Thani
>

-- 
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: sharing "go runtime VM" for many go application

[Dave Cheney]

>  All the plugins will be sharing the same memory with no control stopping one 
> from accessing the memory and resources of another. Furthermore you wont' be 
> able to unload or reload an "application" (plugin). 

This may not be correct. Assuming that they plugin does not use the unsafe 
paxkage then the memory safety guarnetees of Go should apply. A plugin would 
bit be able to discover a reference to another value unless it is explicitly 
provided with one. 

Have a look at the singularity project from Microsoft research a decade ago who 
applied this idea to an entire operating system in a single address space.  

-- 
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] Sendgrid on App Engine urlfetch client instead of defaulthttp client

[Tamás Gulácsi]

customClient.Do(&request)

-- 
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: sharing "go runtime VM" for many go application

[Konstantin Khomoutov]

On Tue, 29 Nov 2016 01:14:40 -0800 (PST)
Dave Cheney  wrote:

> >  All the plugins will be sharing the same memory with no control
> > stopping one from accessing the memory and resources of another.
> > Furthermore you wont' be able to unload or reload an
> > "application" (plugin). 
> 
> This may not be correct. Assuming that they plugin does not use the
> unsafe paxkage then the memory safety guarnetees of Go should apply.
> A plugin would bit be able to discover a reference to another value
> unless it is explicitly provided with one.

What would happen if a plugin panic()s or merely eats up inordinate
amounts of memory?  The OS (usually) has tricks up its sleeve to handle
all such cases.

I know I'm stating the obvious things you're definitely familiar with
-- just trying to highlight the process separation implemented by a
typical general-purpose OS is still a real thing.

-- 
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: sharing "go runtime VM" for many go application

[Dave Cheney]

I'm was only considering the case where a plugin could access the memory of
something it wasn't supposed to.

On Tue, 29 Nov 2016, 20:35 Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Tue, 29 Nov 2016 01:14:40 -0800 (PST)
> Dave Cheney  wrote:
>
> > >  All the plugins will be sharing the same memory with no control
> > > stopping one from accessing the memory and resources of another.
> > > Furthermore you wont' be able to unload or reload an
> > > "application" (plugin).
> >
> > This may not be correct. Assuming that they plugin does not use the
> > unsafe paxkage then the memory safety guarnetees of Go should apply.
> > A plugin would bit be able to discover a reference to another value
> > unless it is explicitly provided with one.
>
> What would happen if a plugin panic()s or merely eats up inordinate
> amounts of memory?  The OS (usually) has tricks up its sleeve to handle
> all such cases.
>
> I know I'm stating the obvious things you're definitely familiar with
> -- just trying to highlight the process separation implemented by a
> typical general-purpose OS is still a real thing.
>

-- 
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: need library suggestions on writing a record program

[Ronny Bangsund]

On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com wrote:
>
> I've been wondering how I should setup input fields. should termbox be 
> responsible for it? or termui as you suggested (this  seems more for 
> monitoring...) or even gocui?
>
 I've tested termui and GOCUI extensively, and found both to be the best 
options for exactly that sort of thing. I did have to modify things/make 
custom widgets to get lists working how *I* like them, but it's very easy 
to use.

I'm leaning slightly towards GOCUI personally, but that doesn't mean you 
should reach for that without testing termui. Both are fairly easy to set 
up, but they have different ways of handling input and updating the display.

If anyone is kind enough to show some example code of a page with input 
> fields maybe 1-2 input fields it'd greatly help.
>
 There isn't really much to it. There are very few widgets - everything is 
basically a bit of text, with or without a border, with different colours 
and/or cursors to indicate its purpose. Examples of what you need would be 
useful.

For more direct help I can recommend the Gopher Slack (I can show more of 
my code there).

-- 
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: Sendgrid on App Engine urlfetch client instead of defaulthttp client

[Val]

Hi, note that there also exist a specialized group "google-appengine-go" :
https://groups.google.com/forum/#!forum/google-appengine-go

Tamás' answer looks good, good luck

On Tuesday, November 29, 2016 at 1:46:35 AM UTC+1, vanmuld...@gmail.com 
wrote:
>
> I'm running my API backend in Go on App Engine
>
> When a user creates an account, he gets sent an activation email.
>
> The normal tutorial for this doesn't work since App engine refuses the 
> default http client and I have the urlfetch one
>
> I've been trying to figure this out for hours but can't seem to get it 
> right
>
> My code right now 
>
> requestHeaders := make(map[string]string)
> requestHeaders["Authorization"] = "Bearer api_key"
> requestHeaders["User-Agent"] = "sendgrid/3.1.0o"
> requestHeaders["Accept"] = "application/json"
>
> request := Request{
> Method : "POST",
> BaseURL : "https://api.sendgrid/com/v3/mail/send";,
> Headers : requestHeaders,
>
> }
> request.Body = []byte(` {
> "personalizations": [
>{
>"to": [
>{
>"email": "`+user_email+`"
>}
>],
>"substitutions" : {
> "-username-" : "`+username+`",
> "-code-" : "`+user_code+`",
> "-email-" : "`+user_email+`"
>}
>}
>],
>"from": {
>"email": "noreply@"
>},
>"template_id" : "f69ce275-2421-4fca-beb0-247482ea3af0"
> }`)
>
> customClient := urlfetch.Client(appengine.NewContext(r))
> response,err := customClient.Do(request)
>
> Which gives me "Cannot use request (type Request) as type *http.Request in 
> argument to customClient.Do
>
> Where do I add in the bit that makes the call use the urlfetch instead of 
> the default http client?
>
> Many 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: Sendgrid on App Engine urlfetch client instead of defaulthttp client

[vanmulders1992]

I tried &request which gave me

cannot use &request (type*Request) as type*http.Request in argument to 
customClient.Do



On Monday, 28 November 2016 19:46:35 UTC-5, vanmuld...@gmail.com wrote:
>
> I'm running my API backend in Go on App Engine
>
> When a user creates an account, he gets sent an activation email.
>
> The normal tutorial for this doesn't work since App engine refuses the 
> default http client and I have the urlfetch one
>
> I've been trying to figure this out for hours but can't seem to get it 
> right
>
> My code right now 
>
> requestHeaders := make(map[string]string)
> requestHeaders["Authorization"] = "Bearer api_key"
> requestHeaders["User-Agent"] = "sendgrid/3.1.0o"
> requestHeaders["Accept"] = "application/json"
>
> request := Request{
> Method : "POST",
> BaseURL : "https://api.sendgrid/com/v3/mail/send";,
> Headers : requestHeaders,
>
> }
> request.Body = []byte(` {
> "personalizations": [
>{
>"to": [
>{
>"email": "`+user_email+`"
>}
>],
>"substitutions" : {
> "-username-" : "`+username+`",
> "-code-" : "`+user_code+`",
> "-email-" : "`+user_email+`"
>}
>}
>],
>"from": {
>"email": "noreply@"
>},
>"template_id" : "f69ce275-2421-4fca-beb0-247482ea3af0"
> }`)
>
> customClient := urlfetch.Client(appengine.NewContext(r))
> response,err := customClient.Do(request)
>
> Which gives me "Cannot use request (type Request) as type *http.Request in 
> argument to customClient.Do
>
> Where do I add in the bit that makes the call use the urlfetch instead of 
> the default http client?
>
> Many 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.

Re: [go-nuts] Re: need library suggestions on writing a record program

[Egon]

On Tuesday, 29 November 2016 14:03:13 UTC+2, Ronny Bangsund wrote:
>
>
>
> On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com wrote:
>>
>> I've been wondering how I should setup input fields. should termbox 
>> be responsible for it? or termui as you suggested (this  seems more for 
>> monitoring...) or even gocui?
>>
>  I've tested termui and GOCUI extensively, and found both to be the best 
> options for exactly that sort of thing. I did have to modify things/make 
> custom widgets to get lists working how *I* like them, but it's very easy 
> to use.
>
> I'm leaning slightly towards GOCUI personally, but that doesn't mean you 
> should reach for that without testing termui. Both are fairly easy to set 
> up, but they have different ways of handling input and updating the display.
>
> If anyone is kind enough to show some example code of a page with input 
>> fields maybe 1-2 input fields it'd greatly help.
>>
>  There isn't really much to it. There are very few widgets - everything is 
> basically a bit of text, with or without a border, with different colours 
> and/or cursors to indicate its purpose. Examples of what you need would be 
> useful.
>
> For more direct help I can recommend the Gopher Slack (I can show more of 
> my code there).
>
>
Depending on how much different behavior you need, it's possible to 
implement your own basic library for handling UI on the terminal.

You can take a look at a proof of concept 
here: https://github.com/egonelbre/exp/blob/master/dos/main.go

Of course, you would need to re-implement it yourself and adjust to your 
own needs.

NB: Dig around in the code-base, if you don't feel comfortable with it, 
then you probably should use an existing library.

+ Egon


 

-- 
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: Deleting the /r/golang subreddit

[nwjlyons via golang-nuts]

Just don't moderate it. No need to go nuclear.

On Thursday, 24 November 2016 23:53:32 UTC, bradfitz wrote:
>
> In light of the CEO of Reddit admitting to editing user comments (see 
> dozen news stories today), I propose we delete the /r/golang subreddit.
>
> That is so beyond unethical and immature, I no longer want anything to do 
> with that site. I will be deleting my account on Reddit after backing up my 
> content, and I will no longer be a moderator of /r/golang.
>
> If other moderators of /r/golang feel strongly that it should remain, I 
> suppose you're welcome to keep it going.
>
> But if the other moderators want to abandon it and focus our conversation 
> elsewhere (or build a replacement), I'm happy to just delete /r/golang.
>
> Opinions?
>
>

-- 
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] POST multipart/form-data failing when boundary contains equals

[floweredisland]

If I try to parse a POST body request with Content-Type header set as 
multipart/form-data; boundary1423874274=== with the string 
===1423874274===  set as a boundary, doing a net/hhtp ParseMultipartForm or 
trying to parse the content-type header with a mime ParseMediaType both 
give the "mime: invalid media parameter" error ().
If I set the boundary as ---21331293-- insted, everything works as 
expected. 

Steps to reproduce: Make a simple POST call to a standard running 
http.Server and set the Content-Type header as something like 
multipart/form-data; 
boundary148234432947===.
Even using multipart/form-data; boundary=-==148234432947=== triggered the 
error

Is it a bug in go parsing methods, or is using equals at the start of the 
boundary string effectively illegal and everything is working as intended?

-- 
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 to properly load assets in Golang+Gopherjs?

[Omar Mustardo]

I've been learning how to do opengl/webgl graphics in Golang using 
https://github.com/goxjs/
It has conditional compilation so it can be compiled and run on either 
desktop as usual, or with gopherjs for web.

Most recently, I've made a spinning cube demo: 
https://omustardo.github.io/textured-cube/index.html
Code: https://github.com/Omustardo/demos/tree/master/texturedcube
Based off of an intro WebGL 
tutorial: 
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL

It worked out nicely, but gave me a bit of trouble when it came to loading 
the texture file. In order to maintain the desktop+web support, I had to 
add conditional compilation and deal with each case separately. The 
solution uses standard file reading for desktop and a http.Get request for 
web. I hard-coded my workspace base directory for desktop, and used the 
relative "assets/image.png" for web. Relevant code is in the link above in 
the assetloader folder. 

The issues that I've found with this approach are:
* I'm unable to run `gopherjs build` and load the demo locally because 
http.Get doesn't load local files. I can still use `gopherjs serve` so it 
isn't too bad.
* Hardcoding the base directory won't work well for collaboration / sharing.

I don't think there's a way to get around conditional compilation without 
embedding static asset files in the binary, which I'd rather avoid.
For the desktop version, I've considered using 
filepath.Join(os.Getenv("GOPATH"), "path/to/demo/basedir") rather than 
hardcoding the base directory, but then it depends on people having GOPATH 
set, and having only a single path (as opposed to multiple semicolon 
delimited ones). I also thought about somehow making symlinks to the assets 
directory, but that seems worse.
I don't have any better ideas for the web version, but I also haven't done 
much web development so perhaps someone knows a better way to get local 
assets in javascript than http.Get?

Thanks,
Omar

-- 
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] Shape detection and perspective transforms

[j . arpino]

Hi All,


I wonder if anyone out there can help me. I am looking to write some code 
that will open an image and detect a rectangle in that image. The rectangle 
may be a little skewed due to the camera angle/perspective so ideally a 
transform of the image to fix this is ideal.


I found some opencv tutorials (opencv tutorial: 
http://blog.ayoungprogrammer.com/2013/04/tutorial-detecting-multiple-rectangles.html/#comment-733)
 
that appear to do what i am after but i dont think the functions used in 
the example exist in the go-opencv library. Any help with any info of code 
that might do something similar already out there would be great.

Cheers,

James

-- 
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] runtime.GC - documentation

[Carlos]

Hi,


In https://golang.org/pkg/runtime/#GC it says:

It may also block the entire program.
>

Is this still correct? I understand that GC still pauses, but being under 
100us mark I wonder this affirmative still makes sense. 

All in all, if it does block, it will block no longer than 100us.



- cc 

-- 
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: POST multipart/form-data failing when boundary contains equals

[floweredisland]

I think I already found the answer 
here https://github.com/golang/go/issues/8532

-- 
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: Sendgrid on App Engine urlfetch client instead of defaulthttp client

[Tamás Gulácsi]

It seems that customClient.Do needs a http.Request, not your Request (what's 
that?)

```
request, err := http.NewRequest("POST", 
"https://api.sendgrid/com/v3/mail/send";, strings.NewReader(` {
"personalizations": [
   {
   "to": [
   {
   "email": "`+user_email+`"
   }
   ],
   "substitutions" : {
"-username-" : "`+username+`",
"-code-" : "`+user_code+`",
"-email-" : "`+user_email+`"
   }
   }
   ],
   "from": {
   "email": "noreply@"
   },
   "template_id" : "f69ce275-2421-4fca-beb0-247482ea3af0"
}`),
)
if err != nil {
log.Fatal(err)
}
req.Header["Authorization"] = "Bearer api_key"
req.Header["User-Agent"] = "sendgrid/3.1.0o"
req.Header["Accept"] = "application/json"

customClient := urlfetch.Client(appengine.NewContext(r))
response, err := customClient.Do(request)
```

-- 
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: Sendgrid on App Engine urlfetch client instead of defaulthttp client

[vanmulders1992]

I've changed my code to use a normal POST request not using sendgrid 
libraries and that worked fine. Should have tried that sooner!

On Tuesday, 29 November 2016 12:08:08 UTC-5, Tamás Gulácsi wrote:
>
> It seems that customClient.Do needs a http.Request, not your Request 
> (what's that?)
>
> ```
> request, err := http.NewRequest("POST", "
> https://api.sendgrid/com/v3/mail/send";, strings.NewReader(` {
> "personalizations": [
>{
>"to": [
>{
>"email": "`+user_email+`"
>}
>],
>"substitutions" : {
>"-username-" : "`+username+`",
>"-code-" : "`+user_code+`",
>"-email-" : "`+user_email+`"
>}
>}
>],
>"from": {
>"email": "noreply@"
>},
>"template_id" : "f69ce275-2421-4fca-beb0-247482ea3af0"
> }`),
> )
> if err != nil {
> log.Fatal(err)
> }
> req.Header["Authorization"] = "Bearer api_key"
> req.Header["User-Agent"] = "sendgrid/3.1.0o"
> req.Header["Accept"] = "application/json"
>
> customClient := urlfetch.Client(appengine.NewContext(r))
> response, err := customClient.Do(request)
> ```
>
>

-- 
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: need library suggestions on writing a record program

[biatche]

Did you write that code just for this thread? I really appreciate it. That 
gives me options. It runs and its possible for me to setup something based 
on this.

On Tuesday, November 29, 2016 at 11:10:44 PM UTC+8, Egon wrote:
>
> On Tuesday, 29 November 2016 14:03:13 UTC+2, Ronny Bangsund wrote:
>>
>>
>>
>> On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com 
>> wrote:
>>>
>>> I've been wondering how I should setup input fields. should termbox 
>>> be responsible for it? or termui as you suggested (this  seems more for 
>>> monitoring...) or even gocui?
>>>
>>  I've tested termui and GOCUI extensively, and found both to be the best 
>> options for exactly that sort of thing. I did have to modify things/make 
>> custom widgets to get lists working how *I* like them, but it's very easy 
>> to use.
>>
>> I'm leaning slightly towards GOCUI personally, but that doesn't mean you 
>> should reach for that without testing termui. Both are fairly easy to set 
>> up, but they have different ways of handling input and updating the display.
>>
>> If anyone is kind enough to show some example code of a page with input 
>>> fields maybe 1-2 input fields it'd greatly help.
>>>
>>  There isn't really much to it. There are very few widgets - everything 
>> is basically a bit of text, with or without a border, with different 
>> colours and/or cursors to indicate its purpose. Examples of what you need 
>> would be useful.
>>
>> For more direct help I can recommend the Gopher Slack (I can show more of 
>> my code there).
>>
>>
> Depending on how much different behavior you need, it's possible to 
> implement your own basic library for handling UI on the terminal.
>
> You can take a look at a proof of concept here: 
> https://github.com/egonelbre/exp/blob/master/dos/main.go
>
> Of course, you would need to re-implement it yourself and adjust to your 
> own needs.
>
> NB: Dig around in the code-base, if you don't feel comfortable with it, 
> then you probably should use an existing library.
>
> + Egon
>
>
>  
>

-- 
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] Are Go locks/mutex not the same as ordinary locks/mutexes?

[Roger Alsing]

Coming from C++/C# background where locks/mutexes are considered evil due 
to blocking threads.
Due to how the Go goroutine scheduler works, are the Go counterpart of 
those primitives "different"?

Should I see the Go variants of these primitives more like yield points 
where the execution of a goroutine yields to let other goroutines run.
And thus not resulting in the same resource code/weight as the primitives 
has in other languages?

-- 
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: need library suggestions on writing a record program

[Egon]

On Tuesday, 29 November 2016 19:35:21 UTC+2, bia...@gmail.com wrote:
>
> Did you write that code just for this thread?
>

Yeah, had 2hrs of fun with it :)
 

> I really appreciate it. That gives me options. It runs and its possible 
> for me to setup something based on this.
>

> On Tuesday, November 29, 2016 at 11:10:44 PM UTC+8, Egon wrote:
>>
>> On Tuesday, 29 November 2016 14:03:13 UTC+2, Ronny Bangsund wrote:
>>>
>>>
>>>
>>> On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com 
>>> wrote:

 I've been wondering how I should setup input fields. should termbox 
 be responsible for it? or termui as you suggested (this  seems more for 
 monitoring...) or even gocui?

>>>  I've tested termui and GOCUI extensively, and found both to be the best 
>>> options for exactly that sort of thing. I did have to modify things/make 
>>> custom widgets to get lists working how *I* like them, but it's very easy 
>>> to use.
>>>
>>> I'm leaning slightly towards GOCUI personally, but that doesn't mean you 
>>> should reach for that without testing termui. Both are fairly easy to set 
>>> up, but they have different ways of handling input and updating the display.
>>>
>>> If anyone is kind enough to show some example code of a page with input 
 fields maybe 1-2 input fields it'd greatly help.

>>>  There isn't really much to it. There are very few widgets - everything 
>>> is basically a bit of text, with or without a border, with different 
>>> colours and/or cursors to indicate its purpose. Examples of what you need 
>>> would be useful.
>>>
>>> For more direct help I can recommend the Gopher Slack (I can show more 
>>> of my code there).
>>>
>>>
>> Depending on how much different behavior you need, it's possible to 
>> implement your own basic library for handling UI on the terminal.
>>
>> You can take a look at a proof of concept here: 
>> https://github.com/egonelbre/exp/blob/master/dos/main.go
>>
>> Of course, you would need to re-implement it yourself and adjust to your 
>> own needs.
>>
>> NB: Dig around in the code-base, if you don't feel comfortable with it, 
>> then you probably should use an existing library.
>>
>> + Egon
>>
>>
>>  
>>
>

-- 
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] zb - an opinionated repo based tool for working with go

[Joshua Rubin]

Hi All,

I've been working on a new tool to help with some of the challenges we've 
had working with repositories that contain multiple packages. It has turned 
into a useful tool that has replaced my use of the go command for many 
things.

https://github.com/joshuarubin/zb

*Benefits*

   - Faster builds (by defaulting to go install except for main packages, 
   and by running concurrent go install commands when the dependency tree 
   allows)
   - Faster testing (by caching test results and not retesting except when 
   necessary)
   - Faster linting (by caching lint results from gometalinter)
   - Did I mention fast!
   - Automatically runs go generate if its dependency calculation 
   determines it's required
   - Operates on all packages in a repository (by default) with intelligent 
   support for vendored packages
   - Can complement other build tools like make
   - Does not interfere with tools like govendor or gb
   - Built in shell auto-completion
   

*Commands*

 build build all of the packages in each of the projects
 clean remove executables in repo produced by build
 commands  list all of the executables that will be emitted by the 
build command
 install   compile and install all of the packages in each of the 
projects
 lint  gometalinter with cache and better defaults
 list  lists the packages in the repos of the packages named by the 
import paths, one per line.
 test  test all of the packages in each of the projects and cache 
the results

Please take a look at the README 
 for full details.

This is still a pre 1.0 product. There are a few outstanding issues 
 to resolve, but I'd also love to 
get some community feedback as well.

Thanks a bunch!

-- 
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] Supervisor Golang app

[gnikosn]

Hi my environment variables are :

GOPATH="/root/work"


GOROOT="/usr/local/go" 

and my supervisor of my app are : 

[program:appname]

command=/work/bin/appname

autostart=true

autorestart=true

startretries=10

user=appname

directory=/src/appname

redirect_stderr=true

stdout_logfile=/var/log/supervisor/appname.log

stdout_logfile_maxbytes=50MB

stdout_logfile_backups=10



  IN LOG FILE :INFO 
spawnerr: can't find command '/work/bin/appname'

 What i am doing wrong ?   
 



   
   

   



-- 
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] Processing Images with baked data

[khalil . claybon]

I know there is an image package that exist in Golang that implements 
encode and decode functionality, but how can I get other data from an 
image?. For example I am trying to get iTXt chunks from PNG images, is 
there any way I can do this?

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

Re: [go-nuts] Are Go locks/mutex not the same as ordinary locks/mutexes?

[Ian Lance Taylor]

On Tue, Nov 29, 2016 at 9:51 AM, Roger Alsing  wrote:
> Coming from C++/C# background where locks/mutexes are considered evil due to
> blocking threads.
> Due to how the Go goroutine scheduler works, are the Go counterpart of those
> primitives "different"?
>
> Should I see the Go variants of these primitives more like yield points
> where the execution of a goroutine yields to let other goroutines run.
> And thus not resulting in the same resource code/weight as the primitives
> has in other languages?

Yes.  A Go sync.Mutex blocks a goroutine, not a thread.  Goroutines
are lighter weight than threads--they are basically just a stack.

Ian

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

Re: [go-nuts] runtime.GC - documentation

[Ian Lance Taylor]

[ +rlh, austin ]

On Tue, Nov 29, 2016 at 7:29 AM, Carlos  wrote:
> Hi,
>
>
> In https://golang.org/pkg/runtime/#GC it says:
>
>> It may also block the entire program.
>
>
> Is this still correct? I understand that GC still pauses, but being under
> 100us mark I wonder this affirmative still makes sense.
>
> All in all, if it does block, it will block no longer than 100us.
>
>
>
> - cc
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: need library suggestions on writing a record program

[biatche]

If you already knew theres an existing library, why write a new one? 
Self-challenge of some sort? :) It's really something though.

On Wednesday, November 30, 2016 at 1:51:20 AM UTC+8, Egon wrote:
>
> On Tuesday, 29 November 2016 19:35:21 UTC+2, bia...@gmail.com wrote:
>>
>> Did you write that code just for this thread?
>>
>
> Yeah, had 2hrs of fun with it :)
>  
>
>> I really appreciate it. That gives me options. It runs and its possible 
>> for me to setup something based on this.
>>
>
>> On Tuesday, November 29, 2016 at 11:10:44 PM UTC+8, Egon wrote:
>>>
>>> On Tuesday, 29 November 2016 14:03:13 UTC+2, Ronny Bangsund wrote:



 On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com 
 wrote:
>
> I've been wondering how I should setup input fields. should 
> termbox be responsible for it? or termui as you suggested (this  seems 
> more 
> for monitoring...) or even gocui?
>
  I've tested termui and GOCUI extensively, and found both to be the 
 best options for exactly that sort of thing. I did have to modify 
 things/make custom widgets to get lists working how *I* like them, but 
 it's 
 very easy to use.

 I'm leaning slightly towards GOCUI personally, but that doesn't mean 
 you should reach for that without testing termui. Both are fairly easy to 
 set up, but they have different ways of handling input and updating the 
 display.

 If anyone is kind enough to show some example code of a page with input 
> fields maybe 1-2 input fields it'd greatly help.
>
  There isn't really much to it. There are very few widgets - everything 
 is basically a bit of text, with or without a border, with different 
 colours and/or cursors to indicate its purpose. Examples of what you need 
 would be useful.

 For more direct help I can recommend the Gopher Slack (I can show more 
 of my code there).


>>> Depending on how much different behavior you need, it's possible to 
>>> implement your own basic library for handling UI on the terminal.
>>>
>>> You can take a look at a proof of concept here: 
>>> https://github.com/egonelbre/exp/blob/master/dos/main.go
>>>
>>> Of course, you would need to re-implement it yourself and adjust to your 
>>> own needs.
>>>
>>> NB: Dig around in the code-base, if you don't feel comfortable with it, 
>>> then you probably should use an existing library.
>>>
>>> + Egon
>>>
>>>
>>>  
>>>
>>

-- 
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: Supervisor Golang app

[Diego Medina]

Hi,


it isn't finding the actual binary of your go app. The binary could be in 
one of two places, 

if you run go install
it goes to 

$GOPATH/bin

which is /root/work/bin

if you did go build, it is at the root of your project directory

Hope that helps.

On Tuesday, November 29, 2016 at 1:03:09 PM UTC-5, gni...@gmail.com wrote:
>
> Hi my environment variables are :
>
> GOPATH="/root/work"
>
>
> GOROOT="/usr/local/go" 
>
> and my supervisor of my app are : 
>
> [program:appname]
>
> command=/work/bin/appname
>
> autostart=true
>
> autorestart=true
>
> startretries=10
>
> user=appname
>
> directory=/src/appname
>
> redirect_stderr=true
>
> stdout_logfile=/var/log/supervisor/appname.log
>
> stdout_logfile_maxbytes=50MB
>
> stdout_logfile_backups=10
>
>
>   
> IN LOG FILE :INFO 
> spawnerr: can't find command '/work/bin/appname'
>
>  What i am doing wrong ? 
>
>
>
>
>
>
>
>  
>   
>
>
>

-- 
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] Golang asm to real asm table/doc/tool

[matt]

Is there a table/file/doc/tool to look up e.g. "MOVBU.P" as a real operation 
e.g. "ldrb (post increment)". Asked on twitter earlier, but here is probably 
more appropriate.

-- 
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] Golang asm to real asm table/doc/tool

[Aram Hăvărneanu]

Hi Matt,

There isn't any such document, but you can read the source code or use objdump.

-- 
Aram Hăvărneanu

-- 
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] runtime.GC - documentation

[Rick Hudson]

The documentation is correct. The current runtime.GC() implementation
invokes a Stop The World (STW) GC that completes before runtime.GC()
returns. It is useful when doing benchmarking to avoid some of the
non-determinism caused by the GC.




On Tue, Nov 29, 2016 at 1:15 PM, Ian Lance Taylor  wrote:

> [ +rlh, austin ]
>
> On Tue, Nov 29, 2016 at 7:29 AM, Carlos  wrote:
> > Hi,
> >
> >
> > In https://golang.org/pkg/runtime/#GC it says:
> >
> >> It may also block the entire program.
> >
> >
> > Is this still correct? I understand that GC still pauses, but being under
> > 100us mark I wonder this affirmative still makes sense.
> >
> > All in all, if it does block, it will block no longer than 100us.
> >
> >
> >
> > - cc
> >
> > --
> > 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] Golang asm to real asm table/doc/tool

[matt]

Aram, I've been using objdump as a workaround, but it's not very satisfying. 
Normally I have a reference (architecture manual) when programming in assembly. 
Where in the source code does it map say MOVBU.P to ldrb post increment?

-- 
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: need library suggestions on writing a record program

[Egon]

On Tuesday, 29 November 2016 20:37:55 UTC+2, bia...@gmail.com wrote:
>
> If you already knew theres an existing library, why write a new one?
>

It's a proof-of-concept not a library -- libraries take several magnitudes 
more effort.

I've written, I guess 7+ different versions of UI 
libraries/proof-of-concepts. Partly due to work, partly because I want a 
proper GUI library for Go; but I'm still trying to find a design I'm 
satisfied with.

Different libraries make different trade-offs... when they don't make 
important trade-offs they will be difficult to use or not useful in 
practice.

The approach I showed, makes trade-offs in making UI "less flexibible", but 
at the same-time it makes easier to manage different content and records.

Now the other libraries tend to make UI more "flexible", but they make 
handling the business and binding with business logic harder.

(Of course, there are also differences in event logic and ease of 
understanding...)

*Also there's no reason you couldn't combine ideas from both approaches.*

Self-challenge of some sort? :) It's really something though. 
>

For me, it was mainly a relaxing and clarifying exercise. Rewriting code 
helps me to see new viewpoints and figure out how to better structure code. 
Also, in this case, was useful for someone else.

+ Egon
 

>
> On Wednesday, November 30, 2016 at 1:51:20 AM UTC+8, Egon wrote:
>>
>> On Tuesday, 29 November 2016 19:35:21 UTC+2, bia...@gmail.com wrote:
>>>
>>> Did you write that code just for this thread?
>>>
>>
>> Yeah, had 2hrs of fun with it :)
>>  
>>
>>> I really appreciate it. That gives me options. It runs and its possible 
>>> for me to setup something based on this.
>>>
>>
>>> On Tuesday, November 29, 2016 at 11:10:44 PM UTC+8, Egon wrote:

 On Tuesday, 29 November 2016 14:03:13 UTC+2, Ronny Bangsund wrote:
>
>
>
> On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com 
> wrote:
>>
>> I've been wondering how I should setup input fields. should 
>> termbox be responsible for it? or termui as you suggested (this  seems 
>> more 
>> for monitoring...) or even gocui?
>>
>  I've tested termui and GOCUI extensively, and found both to be the 
> best options for exactly that sort of thing. I did have to modify 
> things/make custom widgets to get lists working how *I* like them, but 
> it's 
> very easy to use.
>
> I'm leaning slightly towards GOCUI personally, but that doesn't mean 
> you should reach for that without testing termui. Both are fairly easy to 
> set up, but they have different ways of handling input and updating the 
> display.
>
> If anyone is kind enough to show some example code of a page with 
>> input fields maybe 1-2 input fields it'd greatly help.
>>
>  There isn't really much to it. There are very few widgets - 
> everything is basically a bit of text, with or without a border, with 
> different colours and/or cursors to indicate its purpose. Examples of 
> what 
> you need would be useful.
>
> For more direct help I can recommend the Gopher Slack (I can show more 
> of my code there).
>
>
 Depending on how much different behavior you need, it's possible to 
 implement your own basic library for handling UI on the terminal.

 You can take a look at a proof of concept here: 
 https://github.com/egonelbre/exp/blob/master/dos/main.go

 Of course, you would need to re-implement it yourself and adjust to 
 your own needs.

 NB: Dig around in the code-base, if you don't feel comfortable with it, 
 then you probably should use an existing library.

 + Egon


  

>>>

-- 
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] Golang asm to real asm table/doc/tool

[Aram Hăvărneanu]

On Tue, Nov 29, 2016 at 8:59 PM, matt  wrote:
> Where in the source code does it map say MOVBU.P to ldrb post increment?

It's complicated, there's no trivial easily-visible mapping (although
for this one instruction the actual concrete mapping chosen is
probably trivial), there's relatively complex code that decides what
to do with an instruction like MOVBU.P. Look in oplook, buildop and
asmout.

However, for the vast majority of instruction that still doesn't
actually say "ldrb post increment" anywhere in the code. You just have
to follow the code and functions like oprrr, opmvl, etc, and then read
the bits.

It's much easier to use objdump if you are unsure of a particular instruction.

However, you rarely have to use objdump. Mostly only to add new
instructions. Go uses consistent calling convention and syntax between
architectures, and a large class of consistent pseudo-instructions
like MOVW, MOVD, etc; the only things that vary are the
more-specialized instructions and the name of the register.

If you need a specialized instruction it's easy. It usually has the
same name as the one from the platform manual (there are exceptions).

If you don't need specialized instructions, just use generic
instructions with whatever addressing mode that you want. If a
particular address mode is not supported, or a multi-instruction
sequence is not generated for a particular architecture and complex
addressing mode the assembler will complain. You can always know what
code means semantically, so there's no problem.

Sometimes you want to see the actual generated code without any
pseudo-instructions, when this is the case, just use objdump.

I understand all this is not ideal, but it really isn't that bad. I
write more assembly than Go these days, and I never have a problem
with the lack of this mapping.

That being said, for sparc64 there is indeed a much better documented mapping.

-- 
Aram Hăvărneanu

-- 
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: need library suggestions on writing a record program

[Seb Binet]

FYI, you may also want to have a look at tcell:
 https://github.com/gdamore/tcell

it was very easy to spin up a few tools with it.

-s


On Tue, Nov 29, 2016 at 9:42 PM, Egon  wrote:

> On Tuesday, 29 November 2016 20:37:55 UTC+2, bia...@gmail.com wrote:
>>
>> If you already knew theres an existing library, why write a new one?
>>
>
> It's a proof-of-concept not a library -- libraries take several magnitudes
> more effort.
>
> I've written, I guess 7+ different versions of UI
> libraries/proof-of-concepts. Partly due to work, partly because I want a
> proper GUI library for Go; but I'm still trying to find a design I'm
> satisfied with.
>
> Different libraries make different trade-offs... when they don't make
> important trade-offs they will be difficult to use or not useful in
> practice.
>
> The approach I showed, makes trade-offs in making UI "less flexibible",
> but at the same-time it makes easier to manage different content and
> records.
>
> Now the other libraries tend to make UI more "flexible", but they make
> handling the business and binding with business logic harder.
>
> (Of course, there are also differences in event logic and ease of
> understanding...)
>
> *Also there's no reason you couldn't combine ideas from both approaches.*
>
> Self-challenge of some sort? :) It's really something though.
>>
>
> For me, it was mainly a relaxing and clarifying exercise. Rewriting code
> helps me to see new viewpoints and figure out how to better structure code.
> Also, in this case, was useful for someone else.
>
> + Egon
>
>
>>
>> On Wednesday, November 30, 2016 at 1:51:20 AM UTC+8, Egon wrote:
>>>
>>> On Tuesday, 29 November 2016 19:35:21 UTC+2, bia...@gmail.com wrote:

 Did you write that code just for this thread?

>>>
>>> Yeah, had 2hrs of fun with it :)
>>>
>>>
 I really appreciate it. That gives me options. It runs and its possible
 for me to setup something based on this.

>>>
 On Tuesday, November 29, 2016 at 11:10:44 PM UTC+8, Egon wrote:
>
> On Tuesday, 29 November 2016 14:03:13 UTC+2, Ronny Bangsund wrote:
>>
>>
>>
>> On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com
>> wrote:
>>>
>>> I've been wondering how I should setup input fields. should
>>> termbox be responsible for it? or termui as you suggested (this  seems 
>>> more
>>> for monitoring...) or even gocui?
>>>
>>  I've tested termui and GOCUI extensively, and found both to be the
>> best options for exactly that sort of thing. I did have to modify
>> things/make custom widgets to get lists working how *I* like them, but 
>> it's
>> very easy to use.
>>
>> I'm leaning slightly towards GOCUI personally, but that doesn't mean
>> you should reach for that without testing termui. Both are fairly easy to
>> set up, but they have different ways of handling input and updating the
>> display.
>>
>> If anyone is kind enough to show some example code of a page with
>>> input fields maybe 1-2 input fields it'd greatly help.
>>>
>>  There isn't really much to it. There are very few widgets -
>> everything is basically a bit of text, with or without a border, with
>> different colours and/or cursors to indicate its purpose. Examples of 
>> what
>> you need would be useful.
>>
>> For more direct help I can recommend the Gopher Slack (I can show
>> more of my code there).
>>
>>
> Depending on how much different behavior you need, it's possible to
> implement your own basic library for handling UI on the terminal.
>
> You can take a look at a proof of concept here:
> https://github.com/egonelbre/exp/blob/master/dos/main.go
>
> Of course, you would need to re-implement it yourself and adjust to
> your own needs.
>
> NB: Dig around in the code-base, if you don't feel comfortable with
> it, then you probably should use an existing library.
>
> + Egon
>
>
>
>
 --
> 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] runtime.GC - documentation

[Josh Hoak]

To clarify, the GC method has different behavior than how the background
garbage collector works. GC calls gcStart with blocking mode, whereas the
normal background garbage collector is called from proc.go
 and malloc.go
 with non-blocking mode.  As I
read the code, GC eschews the fancy concurrent behavior of the new garbage
collector.

On Tue, Nov 29, 2016 at 11:46 AM, Rick Hudson  wrote:

> The documentation is correct. The current runtime.GC() implementation
> invokes a Stop The World (STW) GC that completes before runtime.GC()
> returns. It is useful when doing benchmarking to avoid some of the
> non-determinism caused by the GC.
>
>
>
>
> On Tue, Nov 29, 2016 at 1:15 PM, Ian Lance Taylor  wrote:
>
>> [ +rlh, austin ]
>>
>> On Tue, Nov 29, 2016 at 7:29 AM, Carlos  wrote:
>> > Hi,
>> >
>> >
>> > In https://golang.org/pkg/runtime/#GC it says:
>> >
>> >> It may also block the entire program.
>> >
>> >
>> > Is this still correct? I understand that GC still pauses, but being
>> under
>> > 100us mark I wonder this affirmative still makes sense.
>> >
>> > All in all, if it does block, it will block no longer than 100us.
>> >
>> >
>> >
>> > - cc
>> >
>> > --
>> > 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] runtime.GC - documentation

[Rick Hudson]

That is correct.

On Tuesday, November 29, 2016, Josh Hoak  wrote:

> To clarify, the GC method has different behavior than how the background
> garbage collector works. GC calls gcStart with blocking mode, whereas the
> normal background garbage collector is called from proc.go
>  and malloc.go
>  with non-blocking mode.  As I
> read the code, GC eschews the fancy concurrent behavior of the new garbage
> collector.
>
> On Tue, Nov 29, 2016 at 11:46 AM, Rick Hudson  > wrote:
>
>> The documentation is correct. The current runtime.GC() implementation
>> invokes a Stop The World (STW) GC that completes before runtime.GC()
>> returns. It is useful when doing benchmarking to avoid some of the
>> non-determinism caused by the GC.
>>
>>
>>
>>
>> On Tue, Nov 29, 2016 at 1:15 PM, Ian Lance Taylor > > wrote:
>>
>>> [ +rlh, austin ]
>>>
>>> On Tue, Nov 29, 2016 at 7:29 AM, Carlos >> > wrote:
>>> > Hi,
>>> >
>>> >
>>> > In https://golang.org/pkg/runtime/#GC it says:
>>> >
>>> >> It may also block the entire program.
>>> >
>>> >
>>> > Is this still correct? I understand that GC still pauses, but being
>>> under
>>> > 100us mark I wonder this affirmative still makes sense.
>>> >
>>> > All in all, if it does block, it will block no longer than 100us.
>>> >
>>> >
>>> >
>>> > - cc
>>> >
>>> > --
>>> > 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.

[go-nuts] Large 2D slice performance question

[Mandolyte]

I have a fairly large 2D slice of strings, about 115M rows. These are 
(parent, child) pairs that, processed recursively, form a tree. I am 
"materializing" all possible trees as well as determining for each root 
node all child nodes for all levels for it.

I am using the simple sort.Search() to locate each parent and, without 
profiling, I suspect that a large chunk of time is being spent in that 
sort.Search() function.

Since the data is static, I am leveraging multiple go routines, but find 
that 3 concurrent searches for Win7 and 7 concurrent on Linux is optimum. 
Some of the larger trees are still taking 20+ minutes to process. So 
concurrency helps, but has limits.

I wondered if there were a way to significantly improve the search 
performance. A search of godoc turned up some in-memory key-value stores; 
but probably excessive for what I need. I was thinking of a btree index of 
the parent column returning the index might do the trick.

Any advice?

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.

Re: [go-nuts] Re: need library suggestions on writing a record program

[Mandolyte]

Also https://github.com/cznic/wm... It actually implements an event driven 
model. There's a demo that's easy to see what it can do.

-- 
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] BuckHashSys growth

[Levi Corcoran]

While investigating climbing memory usage for one of our services, I've 
noticed a continual increase in the BuckHashSys metric from 
runtime.MemStats ("bytes of memory in profiling bucket hash tables"), from 
0 to ~2.5GB in the span of about 20 days, and no signs of stopping.  This 
is an application with a fairly steady ~8GB HeapInUse.

I've checked and we're using the default MemProfileRate granularity.  We do 
regularly call runtime.ReadMemStats() (every 30 seconds) for logging 
purposes, and we do have the pprof endpoints wired up for debugging as 
needed, although we shouldn't have anything regularly capturing profile 
data AFAIK.

This is currently on Go 1.5.3 for various reasons, although I believe 
they're upgrading to 1.7x with their next deployment and I'm eager to see 
how things behave there.

What factors could be contributing to that continual climb of BuckHashSys 
and how can we control/mitigate that?

-- 
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] BuckHashSys growth

[Ian Lance Taylor]

On Tue, Nov 29, 2016 at 6:57 PM, Levi Corcoran  wrote:
>
> While investigating climbing memory usage for one of our services, I've
> noticed a continual increase in the BuckHashSys metric from runtime.MemStats
> ("bytes of memory in profiling bucket hash tables"), from 0 to ~2.5GB in the
> span of about 20 days, and no signs of stopping.  This is an application
> with a fairly steady ~8GB HeapInUse.
>
> I've checked and we're using the default MemProfileRate granularity.  We do
> regularly call runtime.ReadMemStats() (every 30 seconds) for logging
> purposes, and we do have the pprof endpoints wired up for debugging as
> needed, although we shouldn't have anything regularly capturing profile data
> AFAIK.
>
> This is currently on Go 1.5.3 for various reasons, although I believe
> they're upgrading to 1.7x with their next deployment and I'm eager to see
> how things behave there.
>
> What factors could be contributing to that continual climb of BuckHashSys
> and how can we control/mitigate that?

Each time the heap profile captures a new stack--a stack that hasn't
been seen before--the stack is saved in memory accounted for in
BuckHashSys.  While I could easily be missing something, I don't see
anything else that could cause BuckHashSys to grow over time.  So this
could happen if you are doing heap profiling in an application that
allocates memory in lots and lots of different places.  It might be
worth looking at a heap profile to see how spread out memory
allocation is.

Ian

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

Re: [go-nuts] BuckHashSys growth

[Levi Corcoran]

Thanks much.  Memory allocation does indeed appear 'spread out' as a result 
of some recursive function calls of varying depth that get called during 
serialization, and a variety of code paths that can trigger the 
serialization, at least after a quick skim through portions of very large 
/debug/pprof/heap?debug=1 output.  From longer-running instances, the 
profiles actually get too large to retrieve in entirety (many-GB memory 
spikes when they are accessed hit container memory limits).

Can you clarify what makes it a new/unique stack worthy of tracking?  And 
should these profile stacks get GC'd once the memory allocation that 
triggered them gets GC'd, or are they retained forever (should their 
overhead scale with 'Alloc' or 'TotalAlloc')?

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