Wait... you can ship a Go binary that dynamically links with the Go runtime and
stdlib at runtime??? Awesome. Can you point me to the docs on this. I’ve always
considered the “single binary” taunted feature as somewhat of a limitation
because of this.
> On Oct 22, 2018, at 9:41 PM, Ian Lance T
> Ian Denhardt :
> > But I think fundamentally folks have to
> > make choice: do we want to be able to write `<` for user defined types, or
> > do
> > we want to be able to look at the `<` operator and know for certain that
> > it's
> > not calling a method? You can't have both.
You can have alm
On Mon, Oct 22, 2018 at 7:18 PM, robert engels wrote:
>
> I think there is a bigger concern than shipping binaries. I believe that the
> Go stdlib and runtime should be shipped as a shared library, and be field
> upgradable independent of the binaries. This is the only reasonable way to
> to distr
I think there is a bigger concern than shipping binaries. I believe that the Go
stdlib and runtime should be shipped as a shared library, and be field
upgradable independent of the binaries. This is the only reasonable way to to
distribute security patches in an efficient and stable manner.
Thi
I think Binary-only packages are very important for Go's Eco, something
like maven(Java) & sbt(scala)
- all it's dep packages should save in the same repo, together, like a
snapshot, or similar concept like docker image
- use a manifest file to list all the dep package's name and version
it's
Hi Patrick,
I guess it's largely a matter of taste but one of the reasons why I prefer
contracts to interfaces is precisely because you only need one contract for
the type parameters as a whole.
This keeps the type parameter section of the generic function/type
relatively brief when you have m
On Mon, Oct 22, 2018 at 10:41 PM Eric S. Raymond wrote:
> Axel Wagner :
> > But personally I don't see the point of introducing a custom iterator
> concept
> > just to *occasionally* save one or two lines of code.
>
> Don't despise saving lines of code. There's a well-known law the name of
> whi
Thanks for suggestions.
If somebody can look at github.com/unistack-org/go-crush package
(ported ceph crush to go) i'l be happy.
Now weight represented as float32, i'm try to use
https://github.com/shopspring/decimal but code looks ugly with many
conversations. And also as i see ceph code (mapper.c
Seems natural to have an architecture where one loop reads the input and
passes complete lines to a consumer. This reading loop would store lines in
a list (array, buffer,...) and thus be able to resubmit them to the
consumer.
On Mon, Oct 22, 2018 at 1:57 PM Sun Frank wrote:
> Hi Everyone:
>
> I
Hi Everyone:
I came across a problem which puzzled me for couple of days. I am trying to
write a* SSH client with a Interactive Shell *using golang, but i also need
to record the command(or keystroke history) of the user typed, like the
history feature, here's my working code:
ce := func(err
Quoting robert engels (2018-10-22 16:01:18)
> I am sure it has been discussed, but why the aversion to using < > in
> type declarations? I guess I just don’t understand using bracketing
> notations that are already used for something else.
This was mentioned in the draft design, but using `<` at
Hi go nuts,
https://play.golang.org/p/ylYlbVMQ24-
I recently hit an error where I had been calling methods on a struct.
Originally, the fields in the struct were never changed, but after some
iterations, i added some state to my struct. The methods which modified
the state were always work
Axel Wagner :
> But personally I don't see the point of introducing a custom iterator concept
> just to *occasionally* save one or two lines of code.
Don't despise saving lines of code. There's a well-known law the name of
which I've forgotten that defect rates per KLOC are rougly constant across
Tamás Gulácsi :
> You can achive sth like this with a function returning a chan.
I'm aware of this. There's a good essay on iterator patterns
https://ewencp.org/blog/golang-iterators/index.html
that goes into three of the possibilties in detail. It covers the
problem with the channel idiom, too
On Fri, Oct 19, 2018 at 10:48 AM alanfo wrote:
> In the light of all the feedback there's been, I've put together a
> proposal which sticks closely to the original design and only changes what
> most people consider needs to be changed in some way. Some recent ideas
> which seemed plausible but w
You can achive sth like this with a function returning a chan.
Or create a filtering function and apply it, creating a second slice.
Neither is perfect - the first is closer to the python generator, the secobd is
to the declared use case.
--
You received this message because you are subscribed
On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich wrote:
>
> * Burak Serdar [181018 15:08]:
> > tbh, I am not trying to avoid operator overloading, I am trying to
> > avoid the contracts. With operator overloading, you can write:
> >
> > func F(a,b type T like(int,X)) {
> >if a > ...
> >
I am sure it has been discussed, but why the aversion to using < > in type
declarations? I guess I just don’t understand using bracketing notations that
are already used for something else.
When I see [] I can immediately see - ah, slice/map reference.
When I see () I can immediately see - ah fu
* Burak Serdar [181018 15:08]:
> tbh, I am not trying to avoid operator overloading, I am trying to
> avoid the contracts. With operator overloading, you can write:
>
> func F(a,b type T like(int,X)) {
>if a ...
>}
> }
>
> provided X is a type that supports <.
Are you trying to avo
Observation: this discussion is very close to the debate around operator
overloading. In fact, if we add generics to the language, we could
define interfaces (I will use Alan Fox's square bracket syntax, as I
think it improves readability):
type Iterator[type Elem] interface {
Next() bool
There's also the additional objection that this doesn't play well with
break/return - if the iterator needs to do some cleanup (say, closing a
file or something). IMO, these days, just use bufio.Scanner-like iterators
or just a channel+context, if syntax is that important to you. But
personally I d
On Mon, Oct 22, 2018 at 12:31 PM Liam wrote:
>
> You might want to read the links on the feedback wiki, if you haven't already:
> https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
>
> Quite a lot of them suggest named handlers.
One difference in this proposal is that handler err { } defi
You might want to read the links on the feedback wiki, if you haven't
already:
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
Quite a lot of them suggest named handlers.
Feel free to add your gist link to the wiki!
On Monday, October 22, 2018 at 7:33:38 AM UTC-7, Burak Serdar wrote:
David Anderson :
> https://github.com/golang/go/issues/13027 is a past proposal to allow the
> `range` operation to work on arbitrary types (although it was originally
> proposed as a narrow enhancement on container/list only). Didn't get very
> far, but sprinkled in the bug are some of the objecti
Thank you Ian.
On Monday, 22 October 2018 21:46:44 UTC+5:30, Ian Davis wrote:
>
>
>
>
> On Mon, 22 Oct 2018, at 4:36 PM, Sathish VJ wrote:
>
> So, I also tried with
> *go test -v -bench=. -test.benchtime=0.1s *
> and that does complete.
>
> But is the implication that StopTimer/StartTimer is t
On Mon, 22 Oct 2018, at 4:36 PM, Sathish VJ wrote:
> So, I also tried with
> *go test -v -bench=. -test.benchtime=0.1s *
> and that does complete.
>
> But is the implication that StopTimer/StartTimer is too costly to use
> even for this simple benchmark?
See https://github.com/golang/go/iss
No, think about it...
If the setup time is 1 minute per iteration, and the timed activity is 1 usec
per iteration, then in order to time for 1 second the test would need to run
for a million minutes….
You need to restructure the test to avoid the setup on every test invocation.
> On Oct 22, 20
So, I also tried with
*go test -v -bench=. -test.benchtime=0.1s *
and that does complete.
But is the implication that StopTimer/StartTimer is too costly to use even
for this simple benchmark?
On Monday, 22 October 2018 21:00:20 UTC+5:30, Jan Mercl wrote:
>
>
>
>
> On Mon, Oct 22, 2018 at 5:2
On Mon, Oct 22, 2018 at 5:21 PM Sathish VJ wrote:
I believe it does actually end, it's just the timeout kicks in sooner.
The testing package attempts to make the benchmark run for at least 1 sec
by default, IINM. Your code has two parts. The measured one is like 1 nsec.
The non-measured is tens
Play Link: https://play.golang.org/p/YppC11kwyLz
Running this command hangs the program: go test -v -bench=.
*"*** Test killed with quit: ran too long (10m0s)."*
But if I comment out the stop/start timer, it is fine.
I tried both with go1.10 and go1.11. Same result.
I have no other file in that
It is public, but github is behaving weirdly since this morning. I
include it here:
This is a suggestion to make error handling more explicit than what's
described in the official proposal.
An error handler is declared as:
handle err { return err }
This declares err as an error variable, and an
I got a 404 when I tried to access this. Perhaps it is not public?
Jon
On Monday, October 22, 2018 at 10:33:38 AM UTC-4, Burak Serdar wrote:
>
> I read the error handling proposal recently, and although I like it in
> general, I don't like the fact that it hides the actual error
> variables fro
Production Version : gopkg.in/resty.v1
godoc : https://godoc.org/gopkg.in/resty.v1
Changelog:
Enhancement
* Debug log callback added to customize log info before logging it #180
#182 PR #186 @jeevatkm
* Updated every reference to point to `gopkg.in/resty.v1` inline with go
mod for
I read the error handling proposal recently, and although I like it in
general, I don't like the fact that it hides the actual error
variables from the flow. Also, I think the error chaining method as
described in the proposal is not very useful. So I came up with this
suggestion:
https://gist.git
https://godoc.org/golang.org/x/image/math/fixed might provide some hints how to
work with this kind of type.
The idea is to use a special type and provide all operations you need.
https://godoc.org/math/big#Rat might be helpful to create first tests of the
basic math operations with maximum pre
Sorry, the uncommented "todo not working" was left in by me so it wouldn't
compile. It won't work when I fix that either, of course.
func getListField(db *sql.DB, table string, item string, field string) (
> string, error) {
> tableName := listFieldToTableName(table, field)
> if !TableExi
Hi! It seems that the driver sometimes does not return an error if a column
is null and I scan for s string, but instead returns the column name. I
have to explicitly use the following function to test for null.
func FieldIsNull(db *sql.DB, table string, item string, field string) bool {
var
Does it possible to avoid conversation and works only with fixed point
(if this can bring performance speedup)?
пн, 22 окт. 2018 г. в 16:13, Vasiliy Tolstov :
>
> пн, 22 окт. 2018 г. в 16:02, Jan Mercl <0xj...@gmail.com>:
> >
> > On Mon, Oct 22, 2018 at 2:35 PM Vasiliy Tolstov wrote:
> >
> > > Doe
пн, 22 окт. 2018 г. в 16:02, Jan Mercl <0xj...@gmail.com>:
>
> On Mon, Oct 22, 2018 at 2:35 PM Vasiliy Tolstov wrote:
>
> > Does reading this 4 bytes to uint32 and use math.Float32frombits looks
> > right?
>
> It does not look right, see
> https://en.wikipedia.org/wiki/Q_(number_format)#Q_to_flo
On Mon, Oct 22, 2018 at 2:35 PM Vasiliy Tolstov wrote:
> Does reading this 4 bytes to uint32 and use math.Float32frombits looks
right?
It does not look right, see
https://en.wikipedia.org/wiki/Q_(number_format)#Q_to_float
--
-j
--
You received this message because you are subscribed to the
Hi! I have some binary format that contains in 4 bytes Q16.16 fixed
point number in LittleEndian. Does reading this 4 bytes to uint32 and
use math.Float32frombits looks right? And also as i understand if in
my code i use float32 i have performance decrease vs if i work with
fixed point int?
--
V
Thank you, that was a helpful response.
--
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://
On Monday, 22 October 2018 07:17:57 UTC+2, Ian Lance Taylor wrote:
>
> On Sat, Oct 20, 2018 at 1:26 PM, jclc via golang-nuts
> > wrote:
> >
> > Currently I don't use them, but couldn't binary packages be used to
> > distribute CGO-dependent packages for developers who might not have a C
> >
Yes Robert's observation that you need all values to merge sorted data, and
that channels don't provide this. However, if the implementation receives
on channels ahead of time, then this isn't a problem because you do have
one value from each source to decide how to proceed.
On Sunday, 21 Oc
Hi Volker,
On Mon, Oct 22, 2018 at 10:57 AM Volker Dobler
wrote:
> The Go 2 draft generics draft has been discussed a lot,
> especially contracts have drawn a lot of attention and
> other ways to limit the set of possible type were suggested.
>
> Most discussions orbited around very basic polymo
The Go 2 draft generics draft has been discussed a lot,
especially contracts have drawn a lot of attention and
other ways to limit the set of possible type were suggested.
Most discussions orbited around very basic polymorphic
functions like polymorphic Min or a Map functions. I do consider
a poly
46 matches
Mail list logo
