Hello Ian,
Thank you for your answer.
On Sun, 05/26/19, May 26, 2019 at 07:59:07PM -0400, Ian Lance Taylor wrote:
> This is not valid. The rule is that SliceHeader is only valid when
> inspecting an actual slice header. You have to write
>
> h.Data = uintptr(unsafe.Pointer(&b))
> h.Len
This is a bit of an aside, I agree with everything Ian said, but:
On Thu, May 23, 2019 at 7:59 PM Ian Lance Taylor wrote:
> If a language is to change over time, this specification or
> implementation must change. Somebody has to decide how changes will
> be made. All successful languages have
On Sun, May 26, 2019 at 11:30 AM Sergey Kamardin wrote:
>
> func ReadHeader(r io.Reader) (Header, error) {
> var (
> b [16]byte
> bts []byte
> )
> h := (*reflect.SliceHeader)(unsafe.Pointer(&b
Please don't. Java is not relevant here and the advice given by other
prior to this post in the thread is not incorrect. Using atomic
operations (in this case it would be atomic.Value's Load and Store
methods) invokes a write barrier, which is fundamentally just a memory
synchronisation. In pkg syn
Hello Gophers,
I'm playing with tcell, but I found a strange problem when I try to clear
the screen.
I wrote the code on gist:
https://gist.github.com/lskbr/9fc28e999ad414edfaf8aef07eb316a9
The code that clear the screen is commented out. When it is used, the
screen is cleared, but the first c
On Sun, 26 May 2019 at 19:17, Jan Mercl <0xj...@gmail.com> wrote:
> On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris
> wrote:
>
> > From what i understand you propose to create a new object and switch out
> the old one with the new one using the atomic package of go.
>
> That cannot work. Stri
And for the OP, there are atomics defined for strings - so what I referred you
to is still valid.
> On May 26, 2019, at 4:21 PM, Robert Engels wrote:
>
> I said nothing to the contrary. I was referring to the structures the poster
> discussed - which are not heap allocated within an array whic
I said nothing to the contrary. I was referring to the structures the poster
discussed - which are not heap allocated within an array which differs from
Java objects.
I think you would be better served by doing more reading and listening and less
yelling.
> On May 26, 2019, at 3:25 PM, Wojci
On Sun, 26 May 2019 13:50:13 -0500
Robert Engels wrote:
> This is an advantage that Java offers over Go for concurrent programming.
> Since everything is reference you don’t face this distinction. Which is why
> most Go uses channels, which are implemented with locks.
It would be good and fruitf
* especially
> On May 26, 2019, at 1:51 PM, Robert Engels wrote:
>
> Using atomics, which is what I stated to do, avoids the data race and is Edie
> sully useful with weak atomics.
>
>> On May 26, 2019, at 1:37 PM, Sotirios Mantziaris
>> wrote:
>>
>> I was thrown of by the previous comment.
Thanks for the clarification Robert.
On Sunday, May 26, 2019 at 9:50:56 PM UTC+3, Robert Engels wrote:
>
> I was referring to updating a reference to a string, which can be updated
> atomically.
>
> This is an advantage that Java offers over Go for concurrent programming.
> Since everything is
Using atomics, which is what I stated to do, avoids the data race and is Edie
sully useful with weak atomics.
> On May 26, 2019, at 1:37 PM, Sotirios Mantziaris
> wrote:
>
> I was thrown of by the previous comment.
> I think i will create some "atomic" types that handle using mutexes with
>
I was referring to updating a reference to a string, which can be updated
atomically.
This is an advantage that Java offers over Go for concurrent programming. Since
everything is reference you don’t face this distinction. Which is why most Go
uses channels, which are implemented with locks.
I was thrown of by the previous comment.
I think i will create some "atomic" types that handle using mutexes with
setter and getter methods.
Thanks Jan
On Sunday, May 26, 2019 at 9:17:44 PM UTC+3, Jan Mercl wrote:
>
> On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris
> > wrote:
>
> > From wha
On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris
wrote:
> From what i understand you propose to create a new object and switch out the
> old one with the new one using the atomic package of go.
That cannot work. String is a multi word value. There's nothing in the
atomic package that can upd
>From what i understand you propose to create a new object and switch out
the old one with the new one using the atomic package of go.
If that is the case i cannot use it since i don't control the field
directly.
I am using the SetString method of the Value struct in the reflect package.
// SetS
Ignore the incorrect comments from the others. There are many valid cases where
relaxed concurrency rules apply and you don’t need synchronization just atomic
ops (and with certain platform this is not needed - eg java volatile)That is
why GC systems can outperform non GC systems in concurrent s
Hi Peter,
Thank you for your answer.
Actually it is not so – please see the rule (6) of the unsafe package
documentation:
https://golang.org/pkg/unsafe/
--
Regards,
Sergey.
On Sun, 05/26/19, May 26, 2019 at 09:43:13AM -0700, peterGo wrote:
> Sergey Kamardin,
>
> Your code is invalid. A uintpt
Sergey Kamardin,
Your code is invalid. A uintptr variable is an integer, not a pointer.
type SliceHeader: https://golang.org/pkg/reflect/#SliceHeader
SliceHeader is the runtime representation of a slice. It cannot be used
safely or portably and its representation may change in a later release.
On Sun, May 26, 2019, at 13:44, Mark Bauermeister wrote:
> Is there any alternative that would allow loading the files
> dynamically during development and baking them into the source upon
> release? Or am I better off just writing some custom logic that simply
> tries to load the file from the fil
I understand, i have to synchronize access...
Coming from another language i had some guarantees on some assignments
mostly int. A string might be a issue here of course...
I have to refactor my code in order to make is safe.
thanks.
On Sunday, May 26, 2019 at 6:13:56 PM UTC+3, Jan Mercl wrote:
On Sun, May 26, 2019 at 5:30 PM Sergey Kamardin wrote:
I'm not sure what the goal is, but the code looks like doing the same
as just `bts := b[:]`. But then it's equal to just `bts :=
make([]byte, 16)`. Remember, there si no stack nor heap wrt the
language specification, so there is no guaranteed
Hello gophers,
I have a question which relates mostly to the ideology of unsafe usage.
In `github.com/gobwas/ws` WebSocket library I used an optimization for
reading WebSocket frame headers into stack based slices (to reduce the
number of heap allocations):
func ReadHeader(r io.Reader)
On Sun, 26 May 2019 07:03:35 -0700 (PDT)
Sotirios Mantziaris wrote:
> Let's assume that the string field Name has the value `Mr. Smith` and we
> change this to `Mr. Anderson` in the goroutine, what are the possible
> values that i could bet on a read?
> If these are either `Mr. Smith` or `Mr.
On Sun, May 26, 2019 at 4:03 PM Sotirios Mantziaris
wrote:
> Let's assume that the string field Name has the value `Mr. Smith` and we
> change this to `Mr. Anderson` in the goroutine, what are the possible values
> that i could bet on a read?
>
> If these are either `Mr. Smith` or `Mr. Anderso
Let's assume that the string field Name has the value `Mr. Smith` and we
change this to `Mr. Anderson` in the goroutine, what are the possible
values that i could bet on a read?
If these are either `Mr. Smith` or `Mr. Anderson` i am very ok with that
because i want the value to be eventually co
On Sun, May 26, 2019 at 3:45 PM Sotirios Mantziaris
wrote:
> Is there a chance that reading and assigning values might not be atomic?
Accessing a the full multi word value is non-atomic on most, if not
all architectures.
--
You received this message because you are subscribed to the Google Gro
Actually.
To answer my own question, this probably suffices for most/all of my use
cases.
func LoadScript(script string) {
L := lua.NewState()
defer L.Close()
file, err := Asset(script)
if err = L.DoFile(script); err != nil {
L.DoString(string(file))
}
}
On Sunday,
i am working on a library for configuration named harvester(
https://github.com/taxibeat/harvester), which will be soon properly open
sourced, where i can dynamically reconfigure the configuration from an
outside system (consul).
The user provides a struct with some tags
type testConfig struct
My use case is a game engine that uses Lua scripts.
Naturally, Lua scripts can be changed during runtime without rebuilding the
entire project.
Since go-bindata doesn't actually load the file during runtime but merely
precompiles it to a string representation, it doesn't work for dynamic
conten
30 matches
Mail list logo
