using
this.
Evan Jones
On Monday, July 13, 2020 at 9:31:23 PM UTC-4 Ian Lance Taylor wrote:
> On Mon, Jul 13, 2020 at 6:03 PM Jason E. Aten wrote:
> >
> > go1.14.4 / darwin / amd64
> >
> > I'm tracking down an issue where a certain code (not sure where, in
>
binary, which is amd64 Linux compiling for i386 Linux. To your
knowledge, is there anything that I need to do so that VDSO is not used by
a pure go program compiled with the standard toolchain? Will the go runtime
detect the absence of AT_SYSINFO_EHDR in the aux vector at runtime and use
INT 0x80
y why
glibc code would be linked in considering that CGO_ENABLED=0 is set. Am I
misunderstanding what the linker is doing here?
Thanks in advance,
Evan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
o, come to think
> of it, I'm not sure how to implement it; even pthread_setspecific
> relies on TLS.
>
> One option would be to change Go on x86 to store the required
> information in a register. That is how it works on some other
> processors, so it would be feasible,
r build
>> options it looks like this isn't possible, but I am hoping someone with
>> knowledge on the matter can comment definitively.
>>
>> Thanks,
>> Evan
>>
>> --
>> You received this message because you are subscribed to the Goo
Hi all,
Is it possible to build pure Go (no cgo) programs targeting i386 without
TLS support? From reviewing the compiler flags and the compiler build
options it looks like this isn't possible, but I am hoping someone with
knowledge on the matter can comment definitively.
Thanks,
12:45 -0800, Evan Borgstrom wrote:
> > Our CI pipeline already does `git status -s -uno` and if there is any
> > output prints the diff & exits.
> >
> > However, this happens at the END of a build (after running lint,
> > build,
> > test, doc generation, etc)
Our CI pipeline already does `git status -s -uno` and if there is any
output prints the diff & exits.
However, this happens at the END of a build (after running lint, build,
test, doc generation, etc), which means you could wait ~minutes before you
get the feedback. We have specialized checks for
n.SetBorder(true).SetRect(0, 0, 22, 3)
if err := app.SetRoot(button, false).SetFocus(button).Run(); err != nil {
panic(err)
}
}
*** what am i not doing correctly? what can i do to learn more what's
going on?
On Wednesday, January 31, 2018 at 1:50:02 PM UTC+8, evan wrote:
>
> i can debug my
thank you both for the info
On Tuesday, January 30, 2018 at 8:20:15 PM UTC+8, evan wrote:
>
> also, could a Go Team-supported GUI library be in Go's near future?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To uns
i can debug my web app server code with no problem with the Go, VSCODE, and
Delve setup.
the client connecting to that web app is a console app, which primarily
does the following:
gets json data from the server, stuffs the data into the table widget of
the terminal user interface (3rd party G
Just to clarify, i meant GUI library for Desktop App
On Tuesday, January 30, 2018 at 8:20:15 PM UTC+8, evan wrote:
>
> also, could a Go Team-supported GUI library be in Go's near future?
>
--
You received this message because you are subscribed to the Google Groups
"gol
also, could a Go Team-supported GUI library be in Go's near future?
--
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
thank you both for your replies!
On Sunday, January 28, 2018 at 2:49:01 PM UTC+8, evan wrote:
>
>
> in the code snippet below which is inside a function, is "defer
> resp.Body.Close() " in the appropriate position?
> am i required to always do a resp.Body.Close()?
in the code snippet below which is inside a function, is "defer
resp.Body.Close() " in the appropriate position?
am i required to always do a resp.Body.Close()?
...
resp, err := client.Do(req)
log.Printf("resp: %+v\n", resp)
if resp.StatusCode != http.StatusOK {
return errors.NewHTTPErr
thanks! seems to be working out for me too so far. makes me wonder what the
use cases might be for sql.NullXYZ and other similar types from non-stdlib
packages other than making the connection to db nulls more obvious maybe?
On Saturday, January 27, 2018 at 10:12:23 PM UTC+8, Reinhard Luediger w
i'm actually using "github.com/markbates/pop/nulls" because i need correct
json
marshalling and unmarshalling.
but i was wondering: aside from above json requirements, and writing helper
methods such as those discussed in
-
thanks for the detailed 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://grou
after reading https://golang.org/pkg/database/sql/, i'm still not quite
sure how to do error handling with respect to tx (transaction) operations.
coming from a java/c# background, where once an exception is raised, i know
what to do in the "catch" and "finally" blocks, i'm not as sure with go
thank you both for the info!
On Tuesday, January 9, 2018 at 9:18:07 PM UTC+8, evan wrote:
>
> i have a 64bit windows 10 development machine. some of the machines in
> our production environment are still 32bit windows 8.x and 7.x machines.
>
> would it be possible for me to c
i have a 64bit windows 10 development machine. some of the machines in our
production environment are still 32bit windows 8.x and 7.x machines.
would it be possible for me to create exe's for those 32 bit machines from
my 64bit development machine? if yes, how?
--
You received this message be
c# has a decimal type that i can map my numeric(12,2) column data type to,
but golang doesnt have a decimal type.
i'm trying to avoid storing money values as cents then converting them to
dollar values when needed, and
also would like to stay close to using database/sql's standard API as much
a
:31 AM UTC-6, Dave Cheney wrote:
>
>
>
> On Friday, 4 August 2017 15:46:39 UTC+10, Evan Leis wrote:
>>
>> I ran into this same problem, and found this post!
>> It looks like you're making the same simple mistake I was:
>>
>> # erroneous:
>> defer
I ran into this same problem, and found this post!
It looks like you're making the same simple mistake I was:
# erroneous:
defer f.Close()
defer trace.Stop()
You must stop the trace *before* closing the output file.
# corrected:
defer func() {
trace.Stop()
panic(f.Close()) # Be sure to handl
and so has our progressively increasing response time.
Sweet.
Thanks again!
Evan
On Monday, 12 December 2016 14:36:14 UTC-8, Evan Digby wrote:
>
> Hi Dave,
>
> Thanks for the insight. I'll look further into the heap creep. I'll also
> try to get together a log of a r
Hi Dave,
Thanks for the insight. I'll look further into the heap creep. I'll also
try to get together a log of a run past 8 hours over the next day or so on
a machine we're not regularly restarting the go process on to see if it
shows anything different.
Thanks again,
Evan
to go up until
the response times are unacceptable and we must restart the process.
Thank you!
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
y, 12 November 2016 12:57:07 UTC-8, Evan Digby wrote:
>
> I think I've eyeballed a bug in my code that *might* cause this but I
> won't be at a computer for a day or two to verify. I'll keep here posted!
--
You received this message because you are subscribed to the Google
I think I've eyeballed a bug in my code that *might* cause this but I won't be
at a computer for a day or two to verify. I'll keep here posted!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving ema
ace to paste:
https://play.golang.org/p/w9WYsNnkv6
On Thursday, 10 November 2016 17:34:08 UTC-8, Evan Digby wrote:
>
> I'm actually struggling to come up with a toy example that identically
> reproduces the results. I wonder if there are some compiler optimizations
> happening
day, 11 November 2016 12:06:21 UTC+11, Evan Digby wrote:
>>
>> Is it expected that if multiple sub-benchmarks are run in the same
>> benchmark, the cost of the setup will impact the results from the first
>> benchmark but not the second?
>>
>> func BenchmarkInt
Is it expected that if multiple sub-benchmarks are run in the same
benchmark, the cost of the setup will impact the results from the first
benchmark but not the second?
func BenchmarkIntersection(b *testing.B) {
// Long setup -- ~5.5 seconds
b.Run("basic 1", func(b *testing.B) {
for i :
cedure, but leaves the
code in a state where it doesn't meet the requirements without proper ops
procedures. This may be a tradeoff that we accept, but leave things
precarious for future developers and ops who inherit this code.
Okay, time for me to sleep!
Thanks again everyone for the ti
-apologies for miscommunication the
original question.
Evan
On Tue, 13 Sep 2016 at 14:48 Egon wrote:
>
>
> On Wednesday, 14 September 2016 00:18:26 UTC+3, Evan Digby wrote:
>>
>> Hi Egon,
>>
>> My requirements are more simple than a graceful http shutdown. I simply
t becomes similar to the last point, except easier because
we already know the state the message was in.
In our use case we will always exit shortly after a close. It's safe to
assume the process will die after close returns.
Thanks again,
Evan
On Tue, 13 Sep 2016 at 14:08 Egon wrote:
> O
Hi John,
Thank you!
The h.closed channel, if checked properly (after the RLock), prevents the
race condition that Augusto pointed out in his post a few back.
I fixed my implementation here: https://play.golang.org/p/QTkSJAOPtE
Thanks again,
Evan
On Tue, 13 Sep 2016 at 14:04 John Souvestre
because it will wait until they're done. If the test does the waiting, then
we aren't validating that the implementation itself does the waiting.
I'm trying to find a clean way to validate that the waiting is done by the
Close call.
Thanks again for your effort in this!
Evan
On
Hi Augusto,
I do owe you an apology. Our production code has the check on the closed
channel after the RLock, not before. In this case you are 100% correct.
This was a bad transcription of the production code to the toy example.
Thanks again,
Evan
On Tuesday, 13 September 2016 13:24:03 UTC-7
ty to keep up-to-date
on something that is core-Go.
Since our requirements don't require a full "graceful" shutdown and are
easily implemented in a few lines of code by wrapping the handler with an
RLock, we would rather minimize the dependence on third party libraries.
Tha
ad lock.
We actually don't care if "Handle" completes in this example. We only care
if that our task handler starts processing a message that it completes the
processing.
Thanks again,
Evan
On Tuesday, 13 September 2016 13:24:03 UTC-7, aro...@gmail.com wrote:
>
> The mutex ap
n add a waitgroup Add or Rlock
before the goroutine is spawned (among other sync requirements to ensure no
new connections are accepted, etc).
Thanks again,
Evan
On Tuesday, 13 September 2016 13:11:17 UTC-7, Egon wrote:
>
> On Tuesday, 13 September 2016 22:52:27 UTC+3, Evan Digby
est.
This race condition is why the current "test" needs the "allStarted" wait
group.
Thanks,
Evan
On Tuesday, 13 September 2016 13:06:39 UTC-7, John Souvestre wrote:
>
> Ø The RW mutex is used by the implementation to guarantee that all
> handlers are complete befo
g to
test.
Thanks again!
On Tuesday, 13 September 2016 12:49:07 UTC-7, John Souvestre wrote:
>
> Hi Evan.
>
>
>
> I looked at the code you posted. I’m having a problem seeing exactly what
> you are trying to do. Also, it appears to be using multiple
> synchronizat
gt; earlier, there is no race.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *Evan Digby
> *Sent:* 2016 September 13, Tue 14:19
> *To:* golang-nuts
>
, if a sleep is the only way, a sleep is the only way. I hope it
isn't!
Thanks!
Evan
On Tuesday, 13 September 2016 12:47:40 UTC-7, Egon wrote:
>
> counter := intr64(N)
> release := make(chan struct{})
>
> ...
> for i := 0; i < N; i ++ {
> h.Handle(func() {
>
ch, since the lock approach
> could block an outstanding task. The key to using waitgroups is to call
> Add() outside of goroutines that might call done:
>
> https://play.golang.org/p/QVWoy8fCmI
>
> On Tuesday, September 13, 2016 at 12:19:16 PM UTC-7, Evan Digby wrote:
>>
irst, also racy.
If you have something else in mind can you elaborate on how it would help
in this case?
Thanks again!
Evan
On Tuesday, 13 September 2016 12:01:29 UTC-7, John Souvestre wrote:
>
> Have you considered using a sync.WaitGroup?
>
>
>
> John
>
> John Sou
Has anyone come across a good way, non-racy way to ensure that N tasks are
guaranteed to be completed after a function is called? Essentially I have a
“Close” function that must be guaranteed to block until all tasks are
finished. Achieving this was pretty simple: wrap each task in an RLock, and
Sorry, I didn't see your longer high-level overview post--I see the vision
a bit more clearly now.
Have you used slack? It might be a good place to start discussion to hammer
out some details before moving onto a google doc. I find shared google docs
can be challenging without at least a founda
This is something I would be interested in working on/supporting. I have 14
month old twins so I have to limit my expectations for coding outside of
work these days, but this type of project I'd be keen on as an amateur
photographer/astrophotographer. I've often looked at contributing to
existi
BenchmarkCombine6-4 1000 145 ns/op
Since my full use case (wasn't included in the original post) requires
appending more than one thing in a loop, that exaggerates this issue
further.
Thanks!
Evan
On Sunday, 17 July 2016 16:31:33 UTC-7, kortschak wrote:
>
> On Su
lace.
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.c
while the append will result in
references? If so, then the append is likely better.
Thanks again!
Evan
On Friday, 15 July 2016 19:20:57 UTC-7, Nate Finch wrote:
>
> it is almost always a bad idea to use append and assign the result to a
> different value than the thing you're appending to
ith.
I don't necessarily need to have that question answered (although I would
like to know!), as the solution will be the same regardless. If I need to
always ensure that this will be a different array underneath, I need to
write that code explicitly.
Thank you,
Evan
On Frida
e all that change between the two results. I'm at a loss. I will keep
trying to reproduce in go playground.
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 fro
make(chan struct{})
defer close(t.doneDoing)
select {
case <-t.closed:
return
case <-t.doCalled:
}
// Let's start doing!
for {
select {
case <-t.closed:
return
case <-time.After(time.Millisecond):
fmt.Println("Doing a thing!")
}
}
}
https://play.golang.org/p/qA3_oFF_E
Filed issue: https://github.com/golang/go/issues/16156
Thanks all.
--
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
her than "that's what happens". Feel
> free to file an issue.
>
> -rob
>
>
> On Wed, Jun 22, 2016 at 1:29 PM, Evan Digby > wrote:
>
>> Hi Rob,
>>
>> Thanks! I'm using 1.6. I guess my question wasn't too clear now that I
>> read i
as empty string? If that's expected, why
would it not return an error when parsing and not executing?
I think the "same base template" info from my original post is a red
herring, because I imagine it's not "redefining" if they're not part of the
same tree someho
I'm noticing that if I accidentally create a second template with the same
name but no content there is no error reported when I "parse" it, but then
when I attempt to execute it I do see an error:
https://play.golang.org/p/Rj3433vvju
Is this expected behaviour? Why wouldn't it simply return an
To further this, if you do need your internal model to be a concrete struct
rather than interface this approach still fits:
https://play.golang.org/p/_wrgN1FltA
On Friday, 17 June 2016 15:02:43 UTC-7, Evan Digby wrote:
>
> One approach to deal with this would be to abstract your internal
One approach to deal with this would be to abstract your internal model as
an interface from the model you receive and mutate them to match. This also
gives you the power to truncate/round/mutate a float however best suites
your needs rather than hoping the library truncates/rounds/mutates in a
Currying is translating the evaluation of a function with multiple arguments
into evaluating a sequence of functions with one argument. Not sure how this
doesn't qualify, even if a closure was used to accomplish this.
As for the value, at the very least there is the same value as using closures
I played around tonight trying to come up with a better way, but instead I
came up with 2 decidedly worse ways (particularly considering
readability/maintenance is the primary concern of the question). I think
they're novel enough to share!
https://play.golang.org/p/w9YxsEFlF8
1) Original
2)
Unfortunately there's a reason why password managers still require a
passphrase. It's simply not secure to store the key anywhere near the
secure files.
I'm not saying password managers are perfect--they have their own security
issues--but it seems that you're attempting to closely mimic that
Apologies. I meant "as Axel" stated :)
On Monday, 13 June 2016 10:06:12 UTC-7, Evan Digby wrote:
>
> As Haddock stated, it is basically impossible to prevent it from being
> accessible to someone looking. Embedding as plaintext will be trivial to
> extract, and essentially
As Haddock stated, it is basically impossible to prevent it from being
accessible to someone looking. Embedding as plaintext will be trivial to
extract, and essentially any method you use to encrypt/obfuscate it
(encrypt the encryption??) will only be slightly less trivial to extract.
Typically
67 matches
Mail list logo
