I use reflect2 in our custom more robust deepcopy implementation in two
places:
1. When I need to grow slice.
Standard reflect package has no way to enlarge slice without call to
reflect.MakeSlice, which allocates unneeded slice header.
2. When I need to iterate map.
Using standard reflect packa
It is pity `func g = othermod.F` were rejected. It could simplify
refactoring.
For example, I've decided to move type and its constructor to other
package. I could easily alias type in its previous place to remain
compatibility, but I have to write ugly wrapper for constructor:
type SomeEnt
You are really toxic man. You are much more toxic than me.
If you don't like Go, why do you write your feces here? Why do you like to
be THE TROLL?
Do you like attention so much so you are ready to be ridiculous for it?
It looks so strange to me.
воскресенье, 22 марта 2020 г., 13:42:16 UTC+3 поль
Don't forget about calling to write barriers.
--
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.
To view this discussion o
> Unclear… revise… “it requires a lock & unlock for every get and put of an
> item"
Not quite exactly. One item per scheduler (could be count as native thread) is
stored in fast thread local storage. Yes, there are still locks, but for
separate lock per thread, and this is quite cheap, since no
Ruby has `if`, `switch` and `while` expressions.
next = if cur.val < val
cur.right
else
cur.left
end
Union type is not necessary, because there could be restriction forcing all
branches to have same type.
--
You received this message because
t
open and we hope it will be useful for community as well:
Package: https://github.com/joomcode/redispipe
Godoc : https://godoc.org/github.com/joomcode/redispipe
With best wishes,
Sokolov Yura aka funny-falcon.
--
You received this message because you are subscribed to the Google Groups
"
I'm trying to build simplest library in `shared` mode linked against shared
std.
Ubuntu 18.04 , go 1.11.1 installed with godeps.
$ sudo rm /usr/local/go/pkg/linux_amd64_dynlink/ -rf
$ sudo rm ~/.cache/go-build/ -rf
$ sudo go install -buildmode=shared std
$ mkdir ~/go/src/mylibrary
$ cat > ~/go/
er)
> v2, ?err := f2()
>
> go vet could then flag shadowing situations.
>
> More on the feedback wiki:
> https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
>
>
> On Sunday, October 28, 2018 at 3:24:48 AM UTC-7, Sokolov Yura wrote:
>>
>> First, I know this
First, I know this will not happen. It is just a dream.
Second, I'm not original: https://github.com/golang/go/issues/377
, https://groups.google.com/forum/#!topic/golang-dev/wg5K15tEJRQ
And this topic is just a forum for ideas.
I'm not really against := operator, but I'm against inconsistency bo
I'd recently made "practically secure rng":
https://github.com/funny-falcon/go-rando
It uses SipHash permutation core (so it has 256 bit permuation stsate +
counters), but also constantly reseeded from 1024 bit "entropy pool" that is
frequently refsreshed from crypto/rand.
--
You received thi
> - The meaning and implementation of CAS at document level (and a transaction
> involving multiple documents) might greatly differ from that of at a simple
> key level and
Badger provides multi-key transactions, so any high level logic may use it.
> - It requires to expose badger transactions
If you read Badgrer's README carefully (and if Badger's README tells the
truth), you'll see that Badger's transactions are implemented with sort of CAS:
- transaction remembersall version of all data it reads,
- on commit it rechecks that all data read during transaction were not modified,
- trans
CAS with presence of transactions... Why?
Badger had CAS before they added transactions. Since you use Badger, I hope
your storage is also transactional.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop re
There is semantic difference between callback passed for continuation of
asynchronous action, and closure/function passed as algorithm parameter.
sort.Slice and sync.Map.Range both accepts function/closure as algorithm
parameter, not as callback.
--
You received this message because you are s
Callbacks are rarely used in Go's ecosystem. Most of time you will use
callbacks only in your own libraries (if you put them in).
Unnamed functions are as simole as `callIt(func (arg Type, arg2 Type2) (res1
Type, res2 Type) { res1, res2 = body(); return res1, res2}) `
--
You received this messa
четверг, 3 мая 2018 г., 11:25:34 UTC+3 пользователь rog написал:
>
> FWIW, the thing I miss sometimes is the equivalent of C's:
>
> while((x = next()) != nil) {
> something()
> }
>
> In Go you need to do either:
>
> for x = next(); x != nil; x = next() {
> som
for {
Body()
if !Condition() {
break
}
}
It is thats simple, guys.
--
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 g
How it is compacted?
Values will be updated and deleted, storage file will grow. How garbage
will be collected?
вторник, 17 апреля 2018 г., 14:37:27 UTC+3 пользователь vadim kulibaba
написал:
>
> Hi Everyone,
>
> I finished simple and effective key/value store with nice api:
> https://github.com
Is it really needed? I thought body is decompressed automatically.
--
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
+1 for map's zero value. Huge inconsistency in a language.
I think, it were made for speed: map is just a pointer (to hidden struct).
Zero-map is just nil pointer. To make zero-value mutable there should be
assignment to a pointer on every access.
More over, map has reference identity ie it is
You didn't buffer writes.
libevent does a good job at buffer managment. Go's net.Conn and os.File are
unbuffered, ie they are almost "raw" file descriptors. You should use
bufio.Writer and bufio.Reader, or make buffering by hands. (Just don't forget
to flush bufio.Writer if response channel is e
If you know keys distribution, you may first split data on N non-intersecting
buckets, where N is number of CPU cores, and then use Sort on each bucket in
parallel.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
> it would be great to move to pcg.
Why? PCG isn't faster, isn't simpler and isn't better (though not worse either).
--
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
Why no one writes Go's version they've tested with?
HEAD of master branch is uniform?
--
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...@goo
Why io is not buffered?
https://github.com/go-hep/hep/blob/master/rootio/file.go#L95
Use bufio
--
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+unsubs
Following is a dangerous error-prone technique. If you use it in you program,
most likely you have a hidden bug, that will appear in high concurrency
situation.
```
func wait(c chan T) T {
v := <-c
c <- v;
return v;
}
```
I had proposal for future primitive: http
for a|b != 0 {
do_something()
--
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:
And I agree that socketpair and regular read from will also do the job.
https://github.com/prep/socketpair/blob/master/socketpair.go
--
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,
Isn't there a way to pass Go callback to Cgo? In this callback you may do
anything.
--
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...@googl
I've implemented AVL tree as index for
sort.Interface: https://github.com/funny-falcon/go-tree
(It is not strictly index, cause it could Swap elements).
So it could be used in conjunction with same type that is defined for
sort.Sort .
среда, 16 августа 2017 г., 3:17:29 UTC+3 пользователь Tong S
If you have a lot of "raw" data (ie without pointers), consider moving it into
mmap-ed slice. You will loose convenience of GC though (you will have to manage
those memory by yourself).
BTW, share your experience with such huge heap on Go. Does GC perform well?
Looks like you are first person wh
So, no scalable timers in 1.9 ?
https://go-review.googlesource.com/c/34784/15
It's a pity.
--
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...
To perform concurrent compaction/copying you should use Read Barriers. Read
barrier is very expensive. It is less expensive in Java, cause pointers always
looks into beginning of allocation (so redirect pointer is in known position).
But it will be very expensive in Go cause of interior pointers
1. Go's GC is quite predictable.
2. Go's runtime has no deallocation without GC for simplicity. You want to
return complexity to runtime.
3. Why not use other language? Go is quite opinionated by its creators. Either
you share that opinion, or use other language.
For example, D language can use b
Where will you store reference counter for interior pointer?
type st struct { j int }
type at { i int; s st }
var a at
var s st
dealWithSt(&s)
dealWithSt(&a.s)
So, you have two choices:
- either you have to find base address for pointer on every rc
increment/decrement - a
GC is triggered *after* allocation than crosses boundary. So your second
allocation is actually tries to complete before first allocation freed. And
Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause overcommit is
not enabled by default.
Use C/C++, or buy more memory, or change y
>> and to recover from them, but I *still* believe that crashing is the
>> right thing to do. You can not prevent crashes, even globally synchronized
>> ones, to happen. Because programmers are just humans and humans are
>> fallible and stuff happens. You need to be
he tools
> necessary to make the right decision (such as custom error references or
> types) but never to make the decision for me.
>
> I've yet to find a panic that would not be better served as a returned
> error.
>
> On Mon, Apr 24, 2017 at 7:24 AM Sokolov Yura >
> Notice that real unrecoverable errors are not subject to defer/recover()
at all.
If so, then how should I raise unrecoverable error, if I really know that
it is unrecoverable?
>
> Something like C style assert(): "guy, something goes completely wrong,
and it is
much better to stop functionin
Good day, people.
Title is a bit controversial :-)
I want to ask:
- how useful `recover` for you?
- Don't you think it is a bit "dangerous"?
I mean: panic usually means programmer error, so if it happens, then
program behaves incorrectly, and there is always a chance of serious
state corruption.
When you dereference pointer, you creates a copy at different address. But
runtime internals stores pointer to original ticker, not your copy. So, call to
Stop on your copy simply does nothing. All created tickers are alive and still
sending ticks.
--
You received this message because you are
Don't do this:
t.ticker = *time.NewTicker(t.period)
Never, never, never dereference anything you got from standard library by
pointer. (And not only from standard library).
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe fro
How often your application changes GOMAXPROCS at runtime?
What is the reason of this change?
What patterns of this change exist (ie is it bounded, is it frequent, etc)?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this grou
Did you try GOMAXPROC=1 ?
--
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.
Also it is single structure with single global mutex-lock.
--
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 opti
I suppose, prefetch instructions in AVX loop (for block after current) can
solve this issue.
--
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
Memory is slow. While slice fits to cache, memclr is measurably faster.
When slice doesn't fit cache, memclr at least not significantly faster.
I've heard, adaptive prefetching is turned on if there were 3 consequent
accesses to same cache-line in increasing address order. So, perhaps optimised
I don't like CoC.
But I like wise moderation.
I may to be toxic sometimes. I think, it is inevitable human nature (although
some tries to look like sweet candies).
But I don't want to be extremly toxic. I do not want to offend without reason.
I've been contacted privately by Andrew Gerrand two ti
6 01:10:36 -0700 (PDT)
> Sokolov Yura > wrote:
>
> > > If you want to make it possible, it's pretty easy:
> > https://play.golang.org/p/YWYFSL2QTe
> >
> > Thank you for fifth copy of almost same code. I clearly have no
> > enough experience to us
re it?
вторник, 18 октября 2016 г., 14:37:44 UTC+3 пользователь Konstantin
Khomoutov написал:
>
> On Tue, 18 Oct 2016 01:10:36 -0700 (PDT)
> Sokolov Yura > wrote:
>
> > > If you want to make it possible, it's pretty easy:
> > https://play.golang.org/p/YWYFSL2Q
illingly ignorant of promises and futures
>> i notice from the sidelines that the concepts seem to lack clarity and
>> vision. if five different implementations got them wrong there will be
>> five different people wondering why the stdlib one isn't working
>> right. t
Roger
> If you want to make it possible, it's pretty easy:
https://play.golang.org/p/YWYFSL2QTe
Thank you for fifth copy of almost same code. I clearly have no enough
experience to use close of channel and `sync.Once`.
Do you really think so?
> There's another idiom I quite like for futures (
понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь
adon...@google.com написал:
>
>
> Go does not take a strong Erlang-like stance against concurrency with
> shared variables, so mutexes really are critical to Go's concurrency.
>
Am I mistaken? Golang authors said mutexes are second c
понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto
Zanotto написал:
>
> I missed the chance to comment on github...
>
> This also works for implementing futures and it's simple, type-safe and
> can be used with select:
> https://play.golang.org/p/VDT36rC5A-
> Of course the synt
Konstantin
No, no sync.Cond.
Please, read links before writing answers.
Please.
понедельник, 17 октября 2016 г., 17:12:42 UTC+3 пользователь Konstantin
Khomoutov написал:
>
> On Sun, 16 Oct 2016 05:40:32 -0700 (PDT)
> Sokolov Yura > wrote:
>
> > "future" i
and (a
bit larger) to compiler.
понедельник, 17 октября 2016 г., 16:42:17 UTC+3 пользователь
adon...@google.com написал:
>
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>>
"future" is commonly used synchronization abstraction.
It could be implemented in a library, using mutex, channel and interface.
Example:
https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
But obviously, semantically future is just a channel with buffer of
capacity 1
Read carefully, and you will not need to do redundant work and write redundant
code.
It is really here:
https://github.com/golang/go/blob/release-branch.go1.6/src/net/tcpsock_posix.go
If you don't see it... Then you reading skill is weak.
--
You received this message because you are subscribe
Oh, in fact Go version is now faster :-) (look results above)
But uses more memory.
воскресенье, 9 октября 2016 г., 13:22:18 UTC+3 пользователь Sokolov Yura
написал:
>
> > The code is not making a reasonable comparison because it creates N
> goroutines. It should create onl
> The code is not making a reasonable comparison because it creates N
goroutines. It should create only GOMAXPROCS goroutines and use no channels
and use no WaitGroup. Then it would be roughly equal to what .net does.
> But we are already far away from what was my point. Nevermind ;-)
I've tried
It looks like .Net version never uses more than 1 core.
>
> If I made hash function slower, .Net version starts to be slower.
Within 1 core there much less to synchronize.
How can I increase number of cpu core used for default Task queue?
--
You received this message because you are subscribed t
:01.72elapsed 334%CPU (0avgtext+0avgdata
384608maxresident)k
256inputs+2464outputs (1major+125570minor)pagefaults 0swaps
воскресенье, 9 октября 2016 г., 12:47:48 UTC+3 пользователь Sokolov Yura
написал:
>
> Here is results for my version https://github.com/funny-falcon/headon
> I utilize r
Here is results for my version https://github.com/funny-falcon/headon
I utilize results by computing hash and summing it it main thread.
.Net still faster and uses less memory. But not dramatically faster. But
dramatically less memory.
It is pitty.
Here is results for .NET:
headon/parallelism/d
Doesn't it possible that .Net optimize out string formatting at all? Cause it
is never returned and has no side effect.
Doubdtfully Go will optimize out fmt.Sprintf.
Anyway, I think .Net core garbage collector just more efficient for extremely
short living objects. Does it has as short GC pause
Can you measure with sleep after sprintf (both in .Net and Go version)?
Let it be sleep for 1 millisecond. Or 500 microseconds.
--
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
Looks lije SetNoDelay is already called on dial.
Look into source.
--
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
Try this:
func (store *Store) addToStore(destination map[string]*Distribution, key
string, value int64) {
store.lock.Lock()
distribution, exists := destination[key]
if !exists {
store.lock.Unlock()
distribution = NewDistribution()
distributio
Some uses gccgo for mips hardware.
--
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://group
But still question is interesting: why decision is based on source code and not
on instructions size? Both functions likely to produce same assembler code.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
What is rate.Limiter ?
--
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
Go 100 off-heap.
You may use other in-memory database for data, running on a same machine. I
recomend Tarantool: http://tarantool.org - it is capable to handle hundreds of
thousands (up to million) requests per second on just one CPU core. If you need
more, then you may consider sharding. If yo
Couldn't it be Keep-Alive connections?
What if you add "Connection: close" header to every server response?
Or call SetKeepAlivesEnabled on
server https://golang.org/pkg/net/http/#Server.SetKeepAlivesEnabled
пятница, 29 июля 2016 г., 17:22:51 UTC+3 пользователь Manideep Attanti
написал:
>
> The
73 matches
Mail list logo
