Re: [go-nuts] scheduling non determinism

[Scott Cotton]

Hi Ian,

2016-07-18 0:33 GMT+02:00 Ian Lance Taylor :

> On Sun, Jul 17, 2016 at 9:25 AM, Scott Cotton  wrote:
> >
> > I'm well aware of the benefits of non-deterministic select for many use
> > cases, I don't contest that at all or the decision to have it part of
> > golang.
> >
> > A clear and concrete problem is the following:  The sat solver
> competition
> > at satcompetition.org requires
> > deterministic solvers for reproducible results.  Suppose I have a
> > select{...} in a go program which solves sat,
> > and I want to enter it in the contest.  I can't.  Also, others can't
> > reproduce the results.  Also, the problem is hard
> > and very heuristic so minor variations can cause huge differences in
> runtime
> > (like 1s vs. 1 month).
>
> If the results of your program depend on the choices made in a select
> statement or in goroutine execution, then your program is in some
> sense racy.


Indeed, I agree.  And if the results do not depend on that...



> It's not necessarily racy in a way that causes undefined
> execution, but it's still racy in the sense that your results become
> unpredictable.


I don't agree.  Many randomised algorithms have varied performance based
on the random seed.  As per Rob's  select based rng:
chan := ...
select {
   case <- chan:
  return 1
   case <- chan:
  return 0
}

It is natural to use select and channels to express deliberately random
choices.

Whether they have a performance impact or not is completely orthogonal to
raciness.


> The answer to the problem is not to pin down the
> precise choices made by select statements and by the scheduler, it's
> to not write racy programs.
>

There are non-racy programs which exhibit this problem.Just pick any
randomised algorithm
and code a choice using select{}.  You will have performance replicability
issues.


>
> I'm not just being facetious: on a multi-processor system with
> GOMAXPROCS > 1, there is no way to pin down the scheduler sufficiently
> to ensure that the same program choices are made each time.  So if
> your results change based on scheduler decisions, you have no hope of
> reproducible results.  Don't write your program that way.
>

One could say the same thing about introducing cputicks() in select
statement
choices :)  Don't write concurrent non-deterministic programming languages
with no way to
determinize choices.  At least if you want to be able to seriously evaluate
them
and seriously replicate behaviour.

Since no one chimed in on how the scheduling/select choices are made, I
took a look-see myself.
A summary:

issue 5606048 introduced cputicks() in seeding fastrand1, the runtime rng
which determines map order,
mapping of G's to M's, and lockorder  for selects.  adding the option to
remove cputicks from this
seeding  looks to me like it would determinize the non-OS sources of
non-determinism.  Better to
give the option of setting the seed explicitly to the user, or at least to
some of my applications if the option
is not welcome as legitimate due to racy-ness paranoia.








>
> Ian
>



-- 
Scott Cotton
President, IRI France SAS
http://www.iri-labs.com

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

[go-nuts] [ANN] treqs: HTTP request tracing

[Ben Burkert]

Hi Gophers,

I've put together a small package for tracing individual HTTP requests
with runtime/trace.

docs: https://godoc.org/github.com/benburkert/treqs
repo: https://github.com/benburkert/treqs

Cheers,
-Ben

-- 
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: Did you try 1.7RC1 ?

[Karan Misra]

I cannot wait for Go 1.7 to land in AppEngine! After AppEngine switched to 
1.6 (from 1.4), the compilation speed have slowed down significantly.
And this definitely reflects in our dev habits (more flipping over to HN 
while we wait for the recompilation to happen.) Hopefully, the 1.7 updates 
lands soon enough.

On Saturday, July 16, 2016 at 9:48:40 PM UTC+5:30, oju...@gmail.com wrote:
>
> 1.7 is a significant improvement over previous versions, not only feature 
> wise, but performance wise. 
>  
> In my current job, for a batch processing task, I coded two versions 
> of the same program, one in Go and other in C++, both single threaded. I 
> tried hard to use the same algorithm and data structures.
>  
> For this specific situation, Go version consistently delivers the result 
> 20% faster than the C++ version (VisualStudio 2015 64bit fully optimized).
>  
> I am pretty sure the C++ version can be made faster, but I am really 
> impressed by the performance I got for free using Go.
>  
> Don't take my word for it. Go ahead, pick the hardest load you have and 
> try it under 1.7RC1.
>  
> Time has come to really put this RC to the test, my friends.
>
> 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: problems receiving data from a GPS

[EdgarAlejandro Vintimilla]

now I have this, but still not the correct results

package main

import (
"fmt"
"net"
"os"
//"strconv"
//"bytes"
//"io/ioutil"
//"net/http"
"reflect"
//"strings"
)

const (
CONN_HOST = ""
CONN_PORT = ""
CONN_TYPE = "tcp"
)

func main() {
// Listen for incoming connections.
l, err := net.Listen(CONN_TYPE, CONN_HOST+":"+CONN_PORT)
if err != nil {
fmt.Println("Error listening:", err.Error())
os.Exit(1)
}
// Close the listener when the application closes.
defer l.Close()
fmt.Println("Listening on " + CONN_HOST + ":" + CONN_PORT)
for {
// Listen for an incoming connection.
conn, err := l.Accept()
if err != nil {
fmt.Println("Error accepting: ", err.Error())
os.Exit(1)
}
// Handle connections in a new goroutine.
go handleRequest(conn)
}
}

// Handles incoming requests.
func handleRequest(conn net.Conn) {

  // Make a buffer to hold incoming data.
  buf := make([]byte, 1024)

  // Read the incoming connection into the buffer.
  reqLen, err := conn.Read(buf)
  buf = buf[:reqLen]

  if err != nil {
fmt.Println("Error reading:", err.Error())
  }

  var cadena string = ""
  for i := 0; i < len(buf)-1; i++ {
cadena += fmt.Sprintf("%x ", buf[i])
  }


  // Send a response back to person contacting us.
  conn.Write([]byte( "ok" ))
  fmt.Println("cadena: ", cadena, reflect.TypeOf(cadena) )
  fmt.Println( "\n" )

  // Close the connection when you're done with it.
  conn.Close()

}



On Sunday, July 17, 2016 at 2:05:22 PM UTC-5, Egon wrote:
>
> On Sunday, 17 July 2016 21:42:26 UTC+3, EdgarAlejandro Vintimilla wrote:
>>
>> Hi, I have a GPS that sends me data through a connection TCP
>>
>> the data it sends me are in ASCII, and I have to convert it to HEX
>>
>> for example in python I'm doing this 
>>
>> BUFFER_SIZE = 1024
>> conn, addr = s.accept()
>> data = conn.recv(BUFFER_SIZE)
>> data.encode("hex")
>> conn.close()
>> print data
>>
>> and it works.
>>
>> but in GO, 
>>
>>   buf := make([]byte, 1024)
>>   reqLen, err := conn.Read(buf)
>>
>
> Note, from here you are not using reqLen, you probably should do:
> buf = buf[:reqLen], although if the conn is not fast enough you may not 
> receive the full request.
>  
>
>>   if err != nil {
>> fmt.Println("Error: ", err.Error())
>>   }
>>
>>   fmt.Println("buf: ", buf) 
>>   fmt.Println("buf str: ", string(buf))
>>
>
> this []byte to string conversion assumes that "buf" is encoded as UTF8, so 
> if you have bytes that are larger than 0x7f you might get bizarre results. 
> *(Although 
> I know you mentioned ASCII, it might also be Extended ASCII)*
>  
>
>>   var str string = ""
>>   for i:=0; i< len(buf); i++{
>> str += strconv.FormatUint(uint64(buf[i]), 16)
>>   }
>>   fmt.Println("str: ", str) 
>>
>> or if I use io, error2 :=ioutil.ReadAll(connection) i do not get the 
>> exact data that it sends me in any way
>>
>
> data, err := ioutil.ReadAll(conn)
> if err != nil { panic(err) }
> enc := hex.EncodeToString(data)
> fmt.Println("hex:", enc)
>
>
> Also you should be probably reading up to the message sequence not 
> everything. Protocols usually define some ending character or sequence, or 
> have a leading length of message. I suspect you should read up-to a 
> line-feed instead of everything. And also that might be the reason that you 
> get different results from Go and Python.
>
> + 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: An efficient runtime expression evaluation

[ondrej . kokes]

Cheers, I tried replicating my endeavours 
(https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
It's essentially rewriting the inbuilt ast.Node into a simpler nested 
struct and then walking it.

In testing the performance, I started adding algebraic expressions, which 
make my walking more expensive, but don't change the 'native' expression 
evaluation (I guess due to constant folding).

As to your suggestion three - I do the variable lookup in the parsing 
stage, but I still need to retain the pointer, not the value itself, 
because I'm accessing an element of that given variable (time series), and 
this element (time period) changes at runtime.

One performance gain I can think of is to implement some pruning through 
the abovementioned constant folding and other optimisations, but I'd rather 
leave that as the last resort. Another thing that comes to mind is that I 
could return nested closures in some way - meaning that '1+3*x' would be, 
in go-like pseudocode, add(func() { return one }, func mul(func() { return 
three}, func() {return model[x]} )), where the one/tree are values passed 
to the closure when parsing the equation; but that's just now off the top 
of my head.

I attached a pprof result in the header.

Thanks again.

On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>
> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>>
>> Hi all,
>> I have a model with variables, let's call them a, b, c, ..., z. These are 
>> numerical values (time series loaded from a database) and I let the user 
>> specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 3*c; y = 
>> log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
>> algebraic relationships + a few functions (log, log2, log10, exp, 
>> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>>
>
> *Tip: include a working piece of code that you want to make faster, it 
> makes it easier for people to see the problems and common issues.*
>
>
>> Now, I get these relationships in a JSON and I parse them using 
>> go/parser. Then I walk the tree once and process it a bit - replacing 
>> keywords by pointers to my variable stores, replacing all the log/exp/sin 
>> with function pointers, leaving literals be literals etc. Each node is then 
>> a struct with a type and the actual contents (sadly a generic interface, 
>> because the value can be almost anything). The prep stage is now over.
>>
>> When actually running the model, I loop through years and within each 
>> year I solve each variable - I walk the tree and evaluate it where needed. 
>> The only non-trivial action is when I get to a model variable, I need to do 
>> a bit of lookup (it's a time series, so I need to look up the correct time 
>> period and other bits). Otherwise it's just literals, operators and 
>> function calls, all of which is fairly straightforward.
>>
>> This is all well and good. One of the issues is that it's rather slow. I 
>> thought it would be the recursive nature (and interface assertions), but 
>> converting all this into a shunting yard system didn't improve the 
>> performance dramatically. I've profiled the thing and removed a few 
>> hotspots, my question is not about profiling. I'm after a bit more general 
>> advice on how to handle these runtime evaluations and if there are better 
>> ways of doing so. Essentially some sort of a JIT (but Go does not have 
>> runtime assembly, right?), or maybe convert each expression into a closure 
>> or maybe a whole different algorithm or...?
>>
>
> Reduce the amount of code and indirection that you need to do, few basic 
> ideas:
> 1. implement a VM https://play.golang.org/p/dlmZ2lGPY7
> 2. operate on vectors of variables instead of single values 
> https://play.golang.org/p/25MIjIXs0D
> 3. try to do the lookup of all necessary variables before starting to 
> compute with them; if possible
>
> Obviously pprof is your friend. (
> https://blog.golang.org/profiling-go-programs)
>
> + 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] Re: Strange results from append

[Dan Kortschak]

On Sun, 2016-07-17 at 09:09 -0700, Evan Digby wrote:
> For now the solution is to explicitly make copies, which was the desired 
> result in the first place.
> 
> The code I posted earlier works as desired.

You don't need to make explicit copies. If you use three index slicing,
you get the behaviour you want.

https://play.golang.org/p/ENpRmubQV4

-- 
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] scheduling non determinism

[Ian Lance Taylor]

On Sun, Jul 17, 2016 at 9:25 AM, Scott Cotton  wrote:
>
> I'm well aware of the benefits of non-deterministic select for many use
> cases, I don't contest that at all or the decision to have it part of
> golang.
>
> A clear and concrete problem is the following:  The sat solver competition
> at satcompetition.org requires
> deterministic solvers for reproducible results.  Suppose I have a
> select{...} in a go program which solves sat,
> and I want to enter it in the contest.  I can't.  Also, others can't
> reproduce the results.  Also, the problem is hard
> and very heuristic so minor variations can cause huge differences in runtime
> (like 1s vs. 1 month).

If the results of your program depend on the choices made in a select
statement or in goroutine execution, then your program is in some
sense racy.  It's not necessarily racy in a way that causes undefined
execution, but it's still racy in the sense that your results become
unpredictable.  The answer to the problem is not to pin down the
precise choices made by select statements and by the scheduler, it's
to not write racy programs.

I'm not just being facetious: on a multi-processor system with
GOMAXPROCS > 1, there is no way to pin down the scheduler sufficiently
to ensure that the same program choices are made each time.  So if
your results change based on scheduler decisions, you have no hope of
reproducible results.  Don't write your program that way.

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] pprof where is my time going

[ajay aggarwal]

Hello,

I am trying to analyze why I am getting low throughput for my app. Below is 
the 30 second CPU profile output. I would expect more time spent in 
net/http serve. Not sure if runtime.mcall and runtime.schedule taking 
almost 1/4th of the time is concerning. When I did a "web mcall" it didn't 
show who is calling mcall. The web graph started with mcall. Any help will 
be much appreciated. Thanks!

(pprof) top 5 -cum

0.09s of 32s total ( 0.28%)

Dropped 449 nodes (cum <= 0.16s)

Showing top 5 nodes out of 249 (cum >= 7.49s)

 flat  flat%   sum%cum   cum%

0 0% 0% 22.17s 69.28%  runtime.goexit

0.01s 0.031% 0.031%  8.73s 27.28%  net/http.(*conn).serve

0 0% 0.031%  7.77s 24.28%  runtime.mcall

0.07s  0.22%  0.25%  7.62s 23.81%  runtime.schedule

0.01s 0.031%  0.28%  7.49s 23.41%  net/http.serverHandler.ServeHTTP



-- 
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] scheduling non determinism

[Jesper Louis Andersen]

On Sun, Jul 17, 2016 at 6:25 PM, Scott Cotton  wrote:

> A clear and concrete problem is the following:  The sat solver competition
> at satcompetition.org requires
> deterministic solvers for reproducible results.  Suppose I have a
> select{...} in a go program which solves sat,
> and I want to enter it in the contest.  I can't.  Also, others can't
> reproduce the results.  Also, the problem is hard
> and very heuristic so minor variations can cause huge differences in
> runtime (like 1s vs. 1 month).
>

In Haskell, there is a concurrency framework called Haxl with this
interesting property: You can run it sequentially (with a deterministic
execution path) or in parallel. This gives rise to the obvious test that a
program must behave the same irrespective of its execution mode. And it
must do so throughout many runs, otherwise the result is not correct.

I see the problem, but I would probably go the route others suggest: make
sure your program behaves as if it had a deterministic execution path and
that you can't tell it apart looking from the outside of the whole thing.
The other solution, changing select to be deterministic, sounds brittle to
me. It will work right now, but it is prone to breaking later.


-- 
J.

-- 
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] scheduling non determinism

[Scott Cotton]

Hello Val,

Thanks for your thoughts.

Indeed, for single user goroutine, I think your list is more or less ok.  I
can reliably reproduce single goroutine performance results in my code and
it is in line with your list.  (rand.Seed is not necessary b/c there is a
default
seed of 1).

There was a famous issue with floats in minisat and heuristics, so indeed
that can be an issue.  In practice,
using 64 bit floats gave sufficient precision to make the heuristics well
defined, and that is accepted as
sufficiently deterministic for the sat competition, even though
theoretically there could be some non-determinism.  Some even made their
own floating point values and operations in C structs to make it
 theoretically deterministic.

For concurrent programs, obviously the program needs to be race-free -- no
reads of data that could hold different values based on grouting scheduling
of writes (using happens-before).  There are also as Ergon noted OS level
effects, but they are in practice mitigated for things like the sat
competition where the entire OS and hardware is
dedicated to a given program, and so the OS will likely schedule threads
the same way every time, as they program
makes exactly the same requests to the OS every time.

I would also note that usage of a channel which has more than one receiver
goroutine or more than one sender goroutine at any time will introduce
non-determinism.

It is not clear to me what is a legitimate "side effect" in your list.
What is the difference between a side-effect and
whether the program will generate the same output in all schedulings?

What if select choice order or channel operation orderings have only
performance impact and no side effects w.r.t. correctness, race-freeness,
or output of the program? I would like to be able to reliably reproduce
that.  They are interesting constructs and it would be simpler to have 1
way of determinising their behaviour at runtime than to re-engineer, often
without them, for every occasion that needs reproducibility.

Scott




2016-07-17 21:25 GMT+02:00 Val :

> Hello Scott
> Determinism for runtime, not just builds, looks like a nice feature to
> have for some problems including yours.
> Sadly I don't have the solution, but it would be great to make 2 lists of
> how to achieve deterministic/reproducible executions in go :
>
> *Sequential programs* (only 1 user goroutine)
> - Use rand.Seed to tame random generators ... quite obviously.
> - Not iterate on map, when iteration order has side effects. Consider
> using a temporary slice to force known iteration order of the map contents.
> - Not use time.Now()
> - Not allow any external input (FS, network, etc.) to vary from run to
> run. Reading a file is ok, if unchanged.
> - Not rely on exact results of floating-points calculations  (they may or
> may not be deterministic, I'm not an expert on that topic but I suspect
> something)
> - other?
>
> *Concurrent programs* (multiple goroutines)
> - All of the above
> - Never let any event A have side effects on any instruction B, unless the
> relation "A happens-before B " is
> reliably proven. This looks tough and restrictive, but if you don't have it
> it's easy to think of a "1s vs. 1 month" perf loss. E.g. when A is used to
> cut (prune) a big calculation tree B, but A happens "sometimes after" B has
> already started. In practice, I would recommend independent tasks meeting
> at rendez-vous points, using WaitGroups as Egon suggested.
> - Not use select{}, unless it is reliably proven that the choice order has
> no side effects.
> - other?
>
> It's an open question for me, please share your ideas!
> Cheers
> Val
>
> On Sunday, July 17, 2016 at 6:25:32 PM UTC+2, Scott Cotton wrote:
>>
>> Hi,
>>
>> I'm well aware of the benefits of non-deterministic select for many use
>> cases, I don't contest that at all or the decision to have it part of
>> golang.
>>
>> A clear and concrete problem is the following:  The sat solver
>> competition at satcompetition.org requires
>> deterministic solvers for reproducible results.  Suppose I have a
>> select{...} in a go program which solves sat,
>> and I want to enter it in the contest.  I can't.  Also, others can't
>> reproduce the results.  Also, the problem is hard
>> and very heuristic so minor variations can cause huge differences in
>> runtime (like 1s vs. 1 month).
>>
>> A concurrent algorithm for SAT can be interesting and maybe even give on
>> average good results.  But the entire thing will be rejected by the
>> scientific community on the grounds that they can't reliably reproduce
>> results.
>>
>> Best
>> Scott
>>
>>
>>
>> 2016-07-17 18:12 GMT+02:00 Jesper Louis Andersen > >:
>>
>>>
>>> On Sun, Jul 17, 2016 at 6:05 PM, Scott Cotton  wrote:
>>>
 I'm looking for information/pointers for making the scheduling and
 select {} choices determinisable for an application domain in which
 

[go-nuts] Re: xorm - 4.3 - panic: gob: registering duplicate names

[DM]

No.

Is this something related to the below issue:-

https://groups.google.com/forum/#!topic/golang-nuts/VnFs2Cv0_UY

If yes how can I get around this problem in xorm?

On Saturday, 16 July 2016 00:09:45 UTC+5:30, DM wrote:
>
> I am getting the below exception with xorm - 4.3 and golang 1.4.2. Any 
> idea what could be going wrong? Is this some known issue xorm - 4.3 or 
> some thing other going wrong?
>
> panic: gob: registering duplicate names for models.SalesOrderItemAttribute: 
> "*models.SalesOrderItemAttribute" != 
> "order-subscriber/models.SalesOrderItemAttribute"
>
> goroutine 71 [running]:
> encoding/gob.RegisterName(0xc208120750, 0x2f, 0x9d0cc0, 0xc2084dafc0)
> /usr/local/go/src/encoding/gob/type.go:832 +0x568
> encoding/gob.Register(0x9d0cc0, 0xc2084dafc0)
> /usr/local/go/src/encoding/gob/type.go:884 
> +0x20fgithub.com/go-xorm/xorm.(*Engine).GobRegister(0xc20856e3f0, 0x9d0cc0, 
> 0xc2084dafc0, 0x9d0cc0)
> /home/jabong-release/go/src/github.com/go-xorm/xorm/engine.go:679 
> +0x32github.com/go-xorm/xorm.(*Engine).autoMapType(0xc20856e3f0, 0x9d0cc0, 
> 0xc2084dafc0, 0x59, 0x59)
> /home/jabong-release/go/src/github.com/go-xorm/xorm/engine.go:670 
> +0x290github.com/go-xorm/xorm.(*Session).innerInsertMulti(0xc208606fc0, 
> 0x86d0c0, 0xc2081f5e80, 0x8, 0x0, 0x0)
> /home/jabong-release/go/src/github.com/go-xorm/xorm/session.go:2071 
> +0x30cgithub.com/go-xorm/xorm.(*Session).Insert(0xc208606fc0, 0xc2086153a0, 
> 0x1, 0x1, 0x0, 0x0, 0x0)
> /home/jabong-release/go/src/github.com/go-xorm/xorm/session.go:2034 
> +0x260github.com/go-xorm/xorm.(*Engine).Insert(0xc20856e3f0, 0xc2086153a0, 
> 0x1, 0x1, 0x0, 0x0, 0x0)
> /home/jabong-release/go/src/github.com/go-xorm/xorm/engine.go:1284 +0x99
> order-subscriber/dao.InsertItemAttributes(0xc208223180, 0x8, 0xa, 0x0, 0x0, 
> 0xd5a938, 0x0, 0xd5a938, 0x0, 0xd5a938, ...)
> 
> /var/lib/jenkins/jobs/CI_order-subscriber_pkg_creation/workspace/src/order-subscriber/dao/dao.go:236
>  +0x35d
>
> The code that is throwing that error looks something like below:-
>
> func InsertItemAttributes(data []Model.SalesOrderItemAttribute, rc 
> utilhttp.RequestContext, logKey string) error {
> prf := logger.NewProfiler()
> dataDogAgent := monitor.GetInstance()
> logger.StartProfile(prf, "insert_order_item_attributes")
> xEngine, _ := utils.GetInstance().Orm(true)
> //  xEngine.ShowSQL = true
>
> logger.InfoSpecific(logKey, "Trying to insert item attributes : ", data)
> _, err := xEngine.Insert()
> ...
>
> The structure SalesOrderItemAttribute looks something like below:-
>
> type SalesOrderItemAttribute struct {
> IdSalesOrderItemAttribute int   `xorm:"not null pk autoincr INT(10)"`
> FkSalesOrderAttributeSet  int   `xorm:"not null index INT(10)"`
> FkSalesOrderItem  int   `xorm:"not null index INT(10)"`
> Value string`xorm:"not null VARCHAR(255)"`
> CreatedAt time.Time `xorm:"index DATETIME"`
> UpdatedAt time.Time `xorm:"not null default 
> 'CURRENT_TIMESTAMP' TIMESTAMP"`
> }
>
>

-- 
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] scheduling non determinism

[Val]

Hello Scott
Determinism for runtime, not just builds, looks like a nice feature to have 
for some problems including yours.
Sadly I don't have the solution, but it would be great to make 2 lists of 
how to achieve deterministic/reproducible executions in go :

*Sequential programs* (only 1 user goroutine)
- Use rand.Seed to tame random generators ... quite obviously.
- Not iterate on map, when iteration order has side effects. Consider using 
a temporary slice to force known iteration order of the map contents.
- Not use time.Now()
- Not allow any external input (FS, network, etc.) to vary from run to run. 
Reading a file is ok, if unchanged.
- Not rely on exact results of floating-points calculations  (they may or 
may not be deterministic, I'm not an expert on that topic but I suspect 
something)
- other?

*Concurrent programs* (multiple goroutines)
- All of the above
- Never let any event A have side effects on any instruction B, unless the 
relation "A happens-before B " is 
reliably proven. This looks tough and restrictive, but if you don't have it 
it's easy to think of a "1s vs. 1 month" perf loss. E.g. when A is used to 
cut (prune) a big calculation tree B, but A happens "sometimes after" B has 
already started. In practice, I would recommend independent tasks meeting 
at rendez-vous points, using WaitGroups as Egon suggested.
- Not use select{}, unless it is reliably proven that the choice order has 
no side effects.
- other?

It's an open question for me, please share your ideas!
Cheers
Val

On Sunday, July 17, 2016 at 6:25:32 PM UTC+2, Scott Cotton wrote:
>
> Hi,
>
> I'm well aware of the benefits of non-deterministic select for many use 
> cases, I don't contest that at all or the decision to have it part of 
> golang.
>
> A clear and concrete problem is the following:  The sat solver competition 
> at satcompetition.org requires 
> deterministic solvers for reproducible results.  Suppose I have a 
> select{...} in a go program which solves sat,
> and I want to enter it in the contest.  I can't.  Also, others can't 
> reproduce the results.  Also, the problem is hard
> and very heuristic so minor variations can cause huge differences in 
> runtime (like 1s vs. 1 month). 
>
> A concurrent algorithm for SAT can be interesting and maybe even give on 
> average good results.  But the entire thing will be rejected by the 
> scientific community on the grounds that they can't reliably reproduce 
> results.
>
> Best
> Scott 
>
>
>
> 2016-07-17 18:12 GMT+02:00 Jesper Louis Andersen  >:
>
>>
>> On Sun, Jul 17, 2016 at 6:05 PM, Scott Cotton > > wrote:
>>
>>> I'm looking for information/pointers for making the scheduling and 
>>> select {} choices determinisable for an application domain in which 
>>> non-determinism in scheduling/select causes problems.
>>>
>>
>> Out of curiosity, what is that domain?
>>
>> The reason I'm asking is that the non-deterministic select is put into 
>> place in order to prevent starvation and also to prevent programmers on 
>> relying on a specific order. The hope is that a concurrency error will 
>> uncover itself while the system is running because the odd schedule is 
>> likely to occur if at all possible.
>>
>> Also, in most concurrency systems, you have the opposite situation: the 
>> system has determinism. The lamented sigh here is that you often want some 
>> kind of fairness among processes to make sure you avoid starvation.
>>
>> There may be good subtle reasons for your domain, which is why I'm asking 
>> what the problem is.
>>
>> -- 
>> J.
>>
>
>
>
> -- 
> Scott Cotton
> President, IRI France SAS
> http://www.iri-labs.com
>
>
>

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

[go-nuts] Re: problems receiving data from a GPS

[Egon]

On Sunday, 17 July 2016 21:42:26 UTC+3, EdgarAlejandro Vintimilla wrote:
>
> Hi, I have a GPS that sends me data through a connection TCP
>
> the data it sends me are in ASCII, and I have to convert it to HEX
>
> for example in python I'm doing this 
>
> BUFFER_SIZE = 1024
> conn, addr = s.accept()
> data = conn.recv(BUFFER_SIZE)
> data.encode("hex")
> conn.close()
> print data
>
> and it works.
>
> but in GO, 
>
>   buf := make([]byte, 1024)
>   reqLen, err := conn.Read(buf)
>

Note, from here you are not using reqLen, you probably should do:
buf = buf[:reqLen], although if the conn is not fast enough you may not 
receive the full request.
 

>   if err != nil {
> fmt.Println("Error: ", err.Error())
>   }
>
>   fmt.Println("buf: ", buf) 
>   fmt.Println("buf str: ", string(buf))
>

this []byte to string conversion assumes that "buf" is encoded as UTF8, so 
if you have bytes that are larger than 0x7f you might get bizarre results. 
*(Although 
I know you mentioned ASCII, it might also be Extended ASCII)*
 

>   var str string = ""
>   for i:=0; i< len(buf); i++{
> str += strconv.FormatUint(uint64(buf[i]), 16)
>   }
>   fmt.Println("str: ", str) 
>
> or if I use io, error2 :=ioutil.ReadAll(connection) i do not get the exact 
> data that it sends me in any way
>

data, err := ioutil.ReadAll(conn)
if err != nil { panic(err) }
enc := hex.EncodeToString(data)
fmt.Println("hex:", enc)


Also you should be probably reading up to the message sequence not 
everything. Protocols usually define some ending character or sequence, or 
have a leading length of message. I suspect you should read up-to a 
line-feed instead of everything. And also that might be the reason that you 
get different results from Go and Python.

+ 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] How can I convert ASCII to HEX?

[EdgarAlejandro Vintimilla]

thanks 

On Saturday, July 16, 2016 at 2:42:23 PM UTC-5, Michael Jones wrote:
>
> Lots of ways...
> https://play.golang.org/p/D54ZRdLX_A
>
> On Sat, Jul 16, 2016 at 8:14 PM, EdgarAlejandro Vintimilla <
> eav...@gmail.com > wrote:
>
>> I want to convert ascii character to hex
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

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

[go-nuts] Re: scheduling non determinism

[Egon]

On Sunday, 17 July 2016 19:05:44 UTC+3, Scott Cotton wrote:
>
> Hi all,
>
> I'm looking for information/pointers for making the scheduling and 
> select {} choices determinisable for an application domain in which 
> non-determinism in scheduling/select causes problems.
>

This seems like queues are the wrong solution for communication in this 
case.

Just a simple case

ch := make(chan int)
go computeSquare(ch, 1)
go computeSquare(ch, 2)

fmt.Println(<-ch, <-ch)

Now, due to things running at different speeds, OS switching, and the 
inherent indeterminism in CPU, you can end up with either 1 or 4 as the 
output. Even if the Go scheduler does not interrupt, the OS or/and the CPU 
itself can cause the indeterminism.

The only reasonable way I can see this being solved is to introduce an 
order to the results.

ch1 := make(chan int)
ch2 := make(chan int)

go computeSquare(ch1, 1)
go computeSquare(ch2, 2)

fmt.Println(<-ch1, <-ch2)

Now there are different ways of approaching the ordering of intermediate 
results... and the nicest one will entirely depend on the problem at 
hand... But the basic premise is that, distribute the workload giving each 
process/thread/goroutine a token. Merge the results together you need to 
process the tokens in a particular order... *Of course each process in turn 
can split the work similarly. *But when you want to schedule new work e.g. 
a new iteration, all previous work must have been done. For random, you 
would need to also split your seed somehow...

e.g. the simplest thing that could work

var mu sync.Mutex
var results [8]struct {
done  bool
value int
}

for i := range results {
go func(index int){
result := index * index

mu.Lock()
results[index].value = result
results[index].done = true
mu.Unlock()
}(i)
}

*// alternatively you can also use here WaitGroup to wait that all 
computations have been completed.*

var total int
for i := range results {
var value int
for {
mu.Lock()
if results[i].done {
value = results[i].value
mu.Unlock()
break
}
mu.Unlock()
time.Sleep(time.Millisecond)
}

total = (total << 1) | value
}

fmt.Println(total)

*tl;dr; don't use queues for communicating results from different 
threads/goroutines/processes/computers.*

*+ Egon*


> For my own purposes I plan to make a determinisable version of the
> gc toolchain where one can set a random seed via an environmental variable.
> If there is shared interest in this endeavour, please chime in.
>
> If any gc officianados could comment about how to go about this (on 
> technical grounds, not contribution IP requirements), it would be 
> appreciated.
>
> Thanks,
>
> -- 
> Scott Cotton
> http://www.iri-labs.com
>
>
>

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

[go-nuts] Re: [ANN] UniDoc PDF Toolkit for golang

[Alfred Hall]

Hi Daniel and thanks for your reply.

Our goal is to provide the library free of use for noncommercial and
personal use. However, for any commercial use we require that the library
is purchased under a commercial license, although initial testing can be
done with the open source version. We believe that the dual licensing with
AGPL + commercial license is the best way to achieve this, but we are open
to any suggestions and will take them under consideration.

Examples of other projects with a similar license model that we have looked
at: iText, iTextSharp, ServiceStack.

Definitely makes sense to highlight this a bit better on our page and we
will do that :). We are looking for input form software license specialists
about using AGPL in Go programs.

Cheers.
Alf


On Sat, Jul 16, 2016 at 3:33 PM, Daniel Theophanes 
wrote:

> I would recommend you clarify your public / commercial licensing and make
> it more prominent in advertising and home page.
>
> I would also note that AGPL is probably unusable in most Go programs
> (statically linked and all). -Daniel
>
> On Saturday, July 16, 2016 at 8:22:00 AM UTC-7, ah...@owlglobal.io wrote:
>>
>> Hi all.
>>
>> Today we are releasing UniDoc version 1.0, a comprehensive open source
>> PDF toolkit written in Go. Please see our release post
>> http://unidoc.io/news/launching-unidoc.
>>
>> We have big plans for this library documented on our website.
>>
>> The current feature set is:
>>  - Merge PDF
>>  - Split PDF
>>  - Protect PDF
>>  - Unlock PDF
>>
>> This is used for the majority of document processed at
>> https://foxyutils.com.
>>
>> Website: http://unidoc.io
>> GitHub: http://github.com/unidoc/unidoc
>> Email: sup...@unidoc.io
>>
>> Appreciate any feedback, comments, suggestions
>>
>> Enjoy.
>> Alf
>>
>

-- 
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] scheduling non determinism

[Scott Cotton]

Hi,

I'm well aware of the benefits of non-deterministic select for many use
cases, I don't contest that at all or the decision to have it part of
golang.

A clear and concrete problem is the following:  The sat solver competition
at satcompetition.org requires
deterministic solvers for reproducible results.  Suppose I have a
select{...} in a go program which solves sat,
and I want to enter it in the contest.  I can't.  Also, others can't
reproduce the results.  Also, the problem is hard
and very heuristic so minor variations can cause huge differences in
runtime (like 1s vs. 1 month).

A concurrent algorithm for SAT can be interesting and maybe even give on
average good results.  But the entire thing will be rejected by the
scientific community on the grounds that they can't reliably reproduce
results.

Best
Scott



2016-07-17 18:12 GMT+02:00 Jesper Louis Andersen <
jesper.louis.ander...@gmail.com>:

>
> On Sun, Jul 17, 2016 at 6:05 PM, Scott Cotton  wrote:
>
>> I'm looking for information/pointers for making the scheduling and
>> select {} choices determinisable for an application domain in which
>> non-determinism in scheduling/select causes problems.
>>
>
> Out of curiosity, what is that domain?
>
> The reason I'm asking is that the non-deterministic select is put into
> place in order to prevent starvation and also to prevent programmers on
> relying on a specific order. The hope is that a concurrency error will
> uncover itself while the system is running because the odd schedule is
> likely to occur if at all possible.
>
> Also, in most concurrency systems, you have the opposite situation: the
> system has determinism. The lamented sigh here is that you often want some
> kind of fairness among processes to make sure you avoid starvation.
>
> There may be good subtle reasons for your domain, which is why I'm asking
> what the problem is.
>
> --
> J.
>



-- 
Scott Cotton
President, IRI France SAS
http://www.iri-labs.com

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

Re: [go-nuts] scheduling non determinism

[Jesper Louis Andersen]

On Sun, Jul 17, 2016 at 6:05 PM, Scott Cotton  wrote:

> I'm looking for information/pointers for making the scheduling and
> select {} choices determinisable for an application domain in which
> non-determinism in scheduling/select causes problems.
>

Out of curiosity, what is that domain?

The reason I'm asking is that the non-deterministic select is put into
place in order to prevent starvation and also to prevent programmers on
relying on a specific order. The hope is that a concurrency error will
uncover itself while the system is running because the odd schedule is
likely to occur if at all possible.

Also, in most concurrency systems, you have the opposite situation: the
system has determinism. The lamented sigh here is that you often want some
kind of fairness among processes to make sure you avoid starvation.

There may be good subtle reasons for your domain, which is why I'm asking
what the problem is.

-- 
J.

-- 
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: Strange results from append

[Evan Digby]

Hi TL,

It's identical between the two runs as best as can be with a rebuild in between 
two runs. The values used are the same.

I'm going to dig into the assembly a bit when I get the time.

For now the solution is to explicitly make copies, which was the desired result 
in the first place.

The code I posted earlier works as desired.

Thanks!

Evan

-- 
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] scheduling non determinism

[Scott Cotton]

Hi all,

I'm looking for information/pointers for making the scheduling and
select {} choices determinisable for an application domain in which
non-determinism in scheduling/select causes problems.

For my own purposes I plan to make a determinisable version of the
gc toolchain where one can set a random seed via an environmental variable.
If there is shared interest in this endeavour, please chime in.

If any gc officianados could comment about how to go about this (on
technical grounds, not contribution IP requirements), it would be
appreciated.

Thanks,

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

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

Re: [go-nuts] Re: goimports has been updated

[Vince Prignano]

https://github.com/golang/go/issues/16402

On Saturday, July 16, 2016 at 9:51:16 PM UTC-7, bradfitz wrote:
>
> Please file a bug. I lose emails.
>
>
> On Sat, Jul 16, 2016 at 1:29 PM, Vince Prignano  > wrote:
>
>> I just noticed that import paths that start with an uppercase letter 
>> don't get imported automatically after the update.
>>
>> Looking at the code and  
>> https://github.com/golang/tools/blob/master/imports/fix.go#L651,
>> I tried to change the behavior, using strings.ToLower on 
>> `lastTwoComponents` like:
>>
>> for _, pkg := range dirScan {
>> if 
>> !strings.Contains(strings.ToLower(lastTwoComponents(pkg.importPathShort)), 
>> pkgName) {
>> // Speed optimization to minimize disk I/O:
>> // the last two components on disk must contain the
>> // package name somewhere.
>> //
>> // This permits mismatch naming like directory
>> // "go-foo" being package "foo", or "pkg.v3" being "pkg",
>> // or directory "google.golang.org/api/cloudbilling/v1"
>> // being package "cloudbilling", but doesn't
>> // permit a directory "foo" to be package
>> // "bar", which is strongly discouraged
>> // anyway. There's no reason goimports needs
>> // to be slow just to accomodate that.
>> continue
>> }
>> if !canUse(filename, pkg.dir) {
>> continue
>> }
>> candidates = append(candidates, pkg)
>> }
>>
>> and the imports work again like before.
>>
>>
>> This is the test case:
>>  
>> func TestFindImportGoPath(t *testing.T) {
>> goroot, err := ioutil.TempDir("", "goimports-")
>> if err != nil {
>> t.Fatal(err)
>> }
>> defer os.RemoveAll(goroot)
>>
>> origStdlib := stdlib
>> defer func() {
>> stdlib = origStdlib
>> }()
>> stdlib = nil
>>
>> withEmptyGoPath(func() {
>> // Test against imaginary bits/bytes package in std lib
>> bytesDir := filepath.Join(goroot, "src", "pkg", "bits", "Bytes")
>> for _, tag := range build.Default.ReleaseTags {
>> // Go 1.4 rearranged the GOROOT tree to remove the "pkg" path component.
>> if tag == "go1.4" {
>> bytesDir = filepath.Join(goroot, "src", "bits", "Bytes")
>> }
>> }
>> if err := os.MkdirAll(bytesDir, 0755); err != nil {
>> t.Fatal(err)
>> }
>> bytesSrcPath := filepath.Join(bytesDir, "bytes.go")
>> bytesPkgPath := "bits/Bytes"
>> bytesSrc := []byte(`package bytes
>>
>> type Buffer2 struct {}
>> `)
>> if err := ioutil.WriteFile(bytesSrcPath, bytesSrc, 0775); err != nil {
>> t.Fatal(err)
>> }
>> build.Default.GOROOT = goroot
>>
>> got, rename, err := findImportGoPath("bytes", map[string]bool{"Buffer2": 
>> true}, "x.go")
>> if err != nil {
>> t.Fatal(err)
>> }
>> if got != bytesPkgPath || !rename {
>> t.Errorf(`findImportGoPath("bytes", Buffer2 ...)=%q, %t, want "%s", 
>> false`, got, rename, bytesPkgPath)
>> }
>>
>> got, rename, err = findImportGoPath("bytes", map[string]bool{"Missing": 
>> true}, "x.go")
>> if err != nil {
>> t.Fatal(err)
>> }
>> if got != "" || rename {
>> t.Errorf(`findImportGoPath("bytes", Missing ...)=%q, %t, want "", false`, 
>> got, rename)
>> }
>> })
>> }
>>
>>
>>
>> -Vince
>>
>> On Thursday, July 14, 2016 at 10:34:36 PM UTC-7, bradfitz wrote:
>>
>>> goimports has been updated.
>>>
>>> If you've been frustrated by its speed lately, run:
>>>
>>>$ go get -u golang.org/x/tools/cmd/goimports
>>>
>>> ... and things should be much nicer.
>>>
>>> Details at https://golang.org/cl/24941
>>>
>>> If I broke something, file a bug: https://golang.org/issues/new
>>>
>>> The general speed tracking bug is https://golang.org/issue/16367 (don't 
>>> use for new bugs, only for speed)
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] [ANN] goimports-update-ignore makes goimports faster, maintains .goimportsignore

[Brad Fitzpatrick]

Nice!

I got the honor of filing the first feature request:
https://github.com/pwaller/goimports-update-ignore/issues/1  :-)


On Sat, Jul 16, 2016 at 4:28 AM, Peter Waller  wrote:

> With , goimports now supports
> a mechanism for ignoring non-go-code directories. For cluttered source
> directories, this makes goimports quite a lot faster.
>
> The problem is, if you want to get the most benefit of this you may need
> to make and maintain a big ignore file.
>
> Enter goimports-update-ignore. See
> https://github.com/pwaller/goimports-update-ignore for more information.
>
> For me, goimports-update-ignore brings the CPU time down from 4200ms to
> 600ms and runtime from 800ms to 200ms.
>
>
> ---
>
> Here's what the result looks like.
>
> $ goimports-update-ignore -measure-only
> Ignored 0 directories. goimports considers 44367 directories in 877ms
> (cpu=4208ms).
>
> $ goimports-update-ignore -max-depth 1
> Ignored 34 directories. goimports considers 27794 directories in 486ms
> (cpu=2224ms).
>
> $ goimports-update-ignore -max-depth 2
> Ignored 118 directories. goimports considers 25461 directories in 406ms
> (cpu=1820ms).
>
> $ goimports-update-ignore -max-depth 3
> Ignored 304 directories. goimports considers 13238 directories in 267ms
> (cpu=1224ms).
>
> $ goimports-update-ignore -max-depth 4
> Ignored 572 directories. goimports considers 11194 directories in 234ms
> (cpu=684ms).
>
> $ goimports-update-ignore -max-depth 5
> Ignored 797 directories. goimports considers 9943 directories in 193ms
> (cpu=664ms).
>
> --
> 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] Re: TCP Server

[Caleb Doxsey]

Hi Edgar,

Have you done much web development in the past? The easiest option may be 
google app engine. You can create a restful HTTP API pretty easily and it 
comes with a lot of functionality out of the box. You can find a 
getting-started tutorial here: 
https://cloud.google.com/appengine/docs/go/gettingstarted/creating-guestbook. 
I also have a series of videos that walk through almost every aspect of 
building websites with app engine: 
http://www.golang-book.com/guides/bootcamp, though it's so much material 
that it may be difficult to find what you are looking for. App engine is 
also nice because they have a free tier available so it won't cost you 
anything to get started.

HTTP has some advantages over TCP. It's a lot easier to debug, equally 
usable from a website or a mobile app and plays well with proxies and CDNs. 
The overhead isn't too bad either.

For TCP you probably have to create a virtual machine and install your app 
as a service. The easiest way to do this would be to use the startup-data 
script that both google and amazon offer when you start an instance. I use 
this script: 
https://github.com/calebdoxsey/cloud-machine/blob/master/install.bash and I 
curl and eval it setting environment variables before hand:

#!/bin/bash

export CF_TOKEN=

curl 
https://raw.githubusercontent.com/calebdoxsey/cloud-machine/master/install.bash 
| /bin/bash 

The "proper" way to do this is using orchestration tools or containers, but 
either of those is going to require a tremendous amount of additional 
knowledge.

Hope that helps,
- Caleb

On Thursday, July 14, 2016 at 10:41:32 AM UTC-4, EdgarAlejandro Vintimilla 
wrote:
>
> Thanks, basically is a GPS that sends data to the server. It's for a fit 
> traker. 
>
> What is the best way to put into producción this server?

-- 
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: What dependency management tool do you use?

[Mateusz Czapliński]

W dniu wtorek, 12 lipca 2016 22:15:29 UTC+2 użytkownik Johann Höchtl 
napisał:

> What do others use?
>

Where I work, we've evaluated what was available some year ago, but nothing 
fit our envisioned usecases. So we took our time, sit down and meticulously 
analyzed what we need, wrote design docs, argued over them hard, and 
finally wrote the code. Since then, we've never looked back, it just works 
for us, we don't even think about it as a problem anymore. We've even 
open-sourced it; but we didn't advertise, because we weren't at freedom to 
add the final, yet so important touch: of writing a proper readme... I find 
it extremely unfortunate and painful from point of view of this project, 
but internally we had to quickly shift our gears and really focus on much, 
much more important stuff - which still keeps us really busy.

But enough explaining myself; what I'd really like is to summarize pros & 
cons of the tool below, plus add some links for further reading for anyone 
interested:

Features:
- main command "vendo recreate" analyzes all .go files in your repo, across 
all build tags and platforms; then recursively analyzes all their external 
dependencies (now assuming only predeclared platforms and default build 
tags). Whole repos (because LICENSE & consistency) are copied into _vendor/ 
subdir (because `go test ./...` & `go build ./...`), registered in 
vendor.json (older version which still supported our approach) with 
revision ID and precise date (awesome in cases like code.google.com winding 
down and everyone going hg->git). Git, hg, bzr are supported as source 
repos (more can be easily added). Code from vendored repos is `git add`-ed 
automatically, ignoring .git/.hg/.bzr dirs; unused repos are detected and 
auto-removed.
- private patching is explicitly supported by design ("comment" field in 
vendor.json should be updated with patch description); though public forks 
are practically superior and more encouraged.
- `go get -u` functionality is supported via "vendo update". Selected 
upstream repos are cloned based on info in "vendor.json", then updated as 
expected.
- permissive BSD license (3-clause).

Limitations:
- does not currently use the "canonical" vendor/ directory structure, thus 
requiring: `GOPATH=$ROOT/_vendor:$GOPATH`. Reasons: mostly for ease of `go 
build ./...`, `go test ./...` etc; also vendor/ was not yet certain when we 
did it. TODO: support vendor/ and add some helper wrapper for ./... ?
- no README yet. Sorry :(
- uses older version of vendor.json specification (many changes were done 
later, while ignoring backwards compatibility, and we noticed them much too 
late);
- currently supports only git as the "master" VCS;
- we planned for some helpful `git commit`-time hooks, but didn't implement 
them yet; lack of them doesn't really hurt us enough that we could with 
straight face allocate some time for it; at least for the time being.

More details:
- the original use-cases design doc: 
https://github.com/zpas-lab/vendo/blob/master/use-cases.md
- example results:
  https://github.com/zpas-lab/vendo/blob/master/vendor.json
  https://github.com/zpas-lab/vendo/tree/master/_vendor
- the main repo: https://github.com/zpas-lab/vendo/

NOTE: If anyone has questions, you're very welcome, but *please* make sure 
my email is in CC. Unfortunately I don't have enough time now to check 
golang-nuts regularly :/

Best Regards,
/Mateusz Czapliński.

-- 
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] Nexer 1.1.1 code name: Billy

[Val]

Hello,
ok but what is Nexer?

-- 
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: why treat int and []int differently here?

[andrey mirtchovski]

> @all, thanks for the explanation!

in my view, all the "details" come from reasoning about Go through the
sieve of other programming languages. nothing wrong in doing that, as
long as the original intention is understood. for me, Go will always
be looked through the sieve of C, in particular the kind of C the
authors wrote for Plan 9. even though some of the decisions may have
looked strange to me at one point or another, summarily Go is much
more complete.

the standard library implementation on the other hand should be looked
through the sieve of Go and Go alone. and perhaps the go1
compatibility guarantee :)

-- 
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: why treat int and []int differently here?

[T L]

@all, thanks for the explanation!

Golang is a simple language full of details.

On Sunday, July 17, 2016 at 4:15:12 AM UTC+8, T L wrote:
>
>
> package main
>>
>> func fi(i int) {}
>> func fis(is []int) {}
>>
>> type TI int
>> type TIS []int
>>
>> func main() {
>> var ti TI
>> fi(ti) // cannot use ti (type TI) as type int in argument to fi
>> 
>> var tis TIS
>> fis(tis) // no problems! 
>> }
>>
>>

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