Re: [go-nuts] two questions

[Zlatko Čalušić]

On 13.02.2017 17:50, Simon Perfer wrote:


I've been working on a pet science project: building an initramfs with 
only one file. Specifically, an executable written in Go.



The only thing I can't figure out is how to do a "modprobe" in Go 
without actually having the modprobe utility. Is there a libkmod 
library available? If not, how would I go about creating a wrapper for 
the libkmod library? Never done this before.



Finally, if I'm relying on C libraries like libkmod does this preclude 
me from creating a statically-compiled binary? Goal being, again, that 
I am creating an initramfs with only a single file: the compiled Go 
binary.



Thanks!




Hello Simon,

that definitely looks like a nice project. I like simplicity. Do share 
when you feel ready.


I straced modprobe, and behind the scenes it just calls init_module(). 
So, it should be pretty simple to call from Go.


NAME
   init_module, finit_module - load a kernel module

DESCRIPTION
   init_module() loads an ELF image into kernel  space, performs  
any  necessary  symbol
   relocations,  initializes module parameters to values provided 
by the caller, and then
   runs the module's init function.  This system call requires 
privilege.


Hope it helps!

--
Zlatko

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

Re: [go-nuts] Go 1.8 Beta 1 is released

[Zlatko Čalušić]

On 02.12.2016 11:09, minux wrote:


On Fri, Dec 2, 2016 at 4:58 AM, Zlatko Čalušić <mailto:zcalu...@bitsync.net>> wrote:


Hello,

and thanks for another great Go release!

I have just one question, and it's not specific to this beta, but
all Go betas and rc-s.

I compile Go from repository like this:

cd $HOME/src/go.googlesource.com/go <http://go.googlesource.com/go>
git checkout -f master
git clean -fdx
git pull --ff-only
git checkout -f go1.8beta1
cd src && make.bash

The resulting binary unfortunately is not labeled as go1.8beta1,
but instead:

go version *devel +41908a5* Thu Dec 1 02:54:21 2016 + linux/amd64

What follows next is that various Go software, where developers
decided to explicitely test for Go version (and of course don't
deal well with devel versions) fails to compile. One example is
gopherjs, it's uncompilable with this beta version, unless I
manually edit the source and remove gratuitous checks.

The question is, how do I persuade the compiled beta to report
version as go1.8beta1?


Because betas are just tags from the master branch, there is no way to 
change the
VERSION file to read go1.8beta1. If you're going to report an issue, 
just include the
full "go version" and it should be fine. If you insist on having go 
version report go1.8beta1,
you can create a VERSION file at $GOROOT that read "go1.8beta1" and 
rebuild Go.
However this is not recommended as git repository is a moving target 
and if you
checkout a new revision without removing the VERSION file, the 
reported version

would still be go1.8beta1, which will be really confusing.

However, if you download the go1.8beta1 source tarball, then the 
VERSION file will

correctly indicate go1.8beta1.


Ah, I see... Thank you for the hint minux!

I can live with a bit of manual editing, it's not that beta's are 
released every day. :)


Also git clean -fdx step from my simple compilation script takes care of 
removing stale VERSION files, so all should be OK.


go version *go1.8beta1* linux/amd64

Yay! :)

Now, to see if gopherjs fancies THIS version string...

--
Zlatko

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

Re: [go-nuts] Go 1.8 Beta 1 is released

[Zlatko Čalušić]

Hello,

and thanks for another great Go release!

I have just one question, and it's not specific to this beta, but all Go 
betas and rc-s.


I compile Go from repository like this:

cd $HOME/src/go.googlesource.com/go
git checkout -f master
git clean -fdx
git pull --ff-only
git checkout -f go1.8beta1
cd src && make.bash

The resulting binary unfortunately is not labeled as go1.8beta1, but 
instead:


go version *devel +41908a5* Thu Dec 1 02:54:21 2016 + linux/amd64

What follows next is that various Go software, where developers decided 
to explicitely test for Go version (and of course don't deal well with 
devel versions) fails to compile. One example is gopherjs, it's 
uncompilable with this beta version, unless I manually edit the source 
and remove gratuitous checks.


The question is, how do I persuade the compiled beta to report version 
as go1.8beta1?


I have a feeling there should be a simple recipe for that, which would 
better the chance of successful compile for various picky projects. :)


Thanks for any hint you can provide.

Regards,

On 01.12.2016 04:40, Chris Broadfoot wrote:

Hello gophers,

We have just released go1.8beta1, a beta version of Go 1.8.
It is cut from the master branch at the revision tagged go1.8beta1.

There are no known problems or regressions.
Please try running production workloads and your unit tests with the 
new version.


It is important that we find bugs *before* issuing a release candidate.
The release candidate is planned for the first week of January.
Your help in testing this beta is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.8beta1

To find out what has changed in Go 1.8, read the draft release notes:
https://beta.golang.org/doc/go1.8

Documentation for Go 1.8 is available at:
https://beta.golang.org/

Our goal is to release the final version of Go 1.8 on February 1st.

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


--
Zlatko

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

Re: [go-nuts] Go protocol proxy, best practices

[Zlatko Čalušić]

Hello,

it would be hard to give you a complete solution without knowing many 
more details about your application.


So to comment on just one part, spawning goroutine, or two, per 
connection. It is absolutely THE correct way in Go. All those goroutines 
will be effectively mapped to system threads by the Go scheduler, and 
you need not worry too much about that, like in other languages. It's 
one of the distinct Go advantages, where developers job is easier thanks 
to simple yet very powerful abstractions.


Now, the number of goroutines will grow if you have many connections, 
but how many is too much? I've successfully launched hundreds of 
thousands of goroutines on the notebook I'm typing this message on, and 
the machine was perfectly usable whole time. And I was limited only by 
available memory, mind you. So, on the adequate server... you get the idea.


If you really care about the number of goroutines, then you should 
concentrate on proper timeouts and error handling, so in the case that 
systems you interface with are too slow or get unavailable, that you 
exit stale goroutines properly at some point, not just continue 
accumulating them.


Also, it could be that diameter server you mention is too slow because 
your Go app is too efficient. :) In that case you will need to actually 
limit the concurrency in your app, to give the diameter time to process 
all incoming requests.


Googling "golang concurrency patterns" will give you a lots of material 
to chew on and learn. I would advise reading the results from 
blog.golang.org first, because they're of high quality and very 
insightful, you can learn a lot from simple examples there.


On 25.08.2016 08:41, kvrat...@gmail.com wrote:

Hi all,

I'm looking for some good practices of concurrent programming in Go.

My software works and even customer satisfied :). But I feel job doesn't done 
perfectly.

The task was to convert some well documented but proprietary protocol to 
Diameter with custom dictionary.

But my feelings are not about protocols but about concurrent model which I 
implemented.

I spawn  goroutline per connection and this goroutline is responsible to 
assembly protocol messages from tcp stream.

Then I spawn another goroutline to process protocol message (calculate Crc and 
etc and make request to Diameter server, receive answer from Diameter server, 
and send response to server).

This per-message goroutline gets two arguments. There are request  and channel.

As soon as per-request goroutline creates response it sends it to channel.

Channel is processed by per-connection goroutine to send response.

I feel this simple model is not correct and stable under load. For example 
diameter server can be slow and number of goroutines and channels will grow 
dramatically.

When I did similar job in erlang I used this process model. But there 
supervisor controlled per-request workers.

Originally C-version uses several native threads with async logic (select and 
epoll) inside them.

Probably same async model can be implemented in Go by I would like to have 
benefits of Go using its concurrency features.

Could you advise correct concurrent model for my task?



--
Zlatko

--
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] building an exe that will embed import in the .exe

[Zlatko Čalušić]

Hello,

When you compile go program, all your source and source from all 
imported packages is compiled together in the same binary (.exe). You 
don't need to worry about it. That's actually one of the go strengths, 
no dll hell.



On 03.08.2016 07:57, ov35...@gmail.com wrote:

Hi,

i have a program that imports a package from github.com/abc...
when i build the .exe how can i have the package/dependency included 
in the .exe ?


thanks,
Al


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


--
Zlatko

--
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] goimports has been updated

[Zlatko Čalušić]

On 15.07.2016 16:31, Jan Mercl wrote:


On Fri, Jul 15, 2016 at 4:29 PM Thomas Frössman > wrote:


> Yeah. I also have (several) linux trees, gcc's and stuff in my 
GOPATH.. I would really like some global config way to tell 
goimports/gorename/... to ignore a bunch of subtrees.


I do not use goimports. My 2c anyway: What about checking for 
.goimportsignore in the root of the subtree that should be skipped?


As we're speaking of Git trees here, I wouldn't like poluting them with 
extra files. Git is very picky about that, for a good reason.


Also, it could be another performance hit, because now goimports tool 
would need to check the existence of .goimportsignore file in each and 
every folder (not unlike Apache's .htaccess).


I think I'd rather see a single ~/.config/goimports/goimports.ini config 
file, where we could have a section along these lines:


[Ignore]
git.kernel.org/torvalds/linux
...

The config file might become useful later for other possible customizations.

Regards,

--
Zlatko

--
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] goimports has been updated

[Zlatko Čalušić]

I'd like to second this!

Also have the linux tree in $GOPATH, and ever since I put it there 
goimports slowed down. Some kind of subtree exclusion mechanism would be 
great.


Nevertheless, thank you for your work on probably the most useful Go 
tool out there, Brad! I can't imagine programming in Go without 
goimports anymore, it's that addictive. ;)


Best regards,

On 15.07.2016 14:47, Peter Waller wrote:

Awesome!

For me it brings the CPU time from 6.5s to 3s. Wall from 2.9s to 2s. A 
noticable improvement.


One thing that still makes it slow for me (2s instead of 500ms, I just 
tested), is that I have several of deep trees which aren't go code in 
my $GOPATH/src. To name a few: linux, clang, llvm.


I feel silly for asking, but any chance of having a mechanism to 
ignore these non-go trees, or does anyone have any other clever ideas 
how to avoid this?


I'd prefer not to store other directories separately just because they 
aren't go code.

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


--
Zlatko

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