On Thu, 27 Feb 2020 at 22:25, David Finkel wrote:
>
>
> On Thu, Feb 27, 2020 at 1:52 PM roger peppe wrote:
>
>> If you really just want to reverse rune-by-rune, it's pretty
>> straightforward:
>>
>> func Reverse(s string) string {
>> r := make([]byte, 0, len(s))
>> for len(s) > 0
On Thu, 27 Feb 2020 19:03:02 -0800 (PST)
bucha...@gmail.com wrote:
> Can someone please explain the columns printed by "go tool objdump"?
> instruction. I'm not sure what columns 2, 3, and 5 are.
Column $2 is the memory address offset, $3 is the entire instruction
encoded in hexadecimal, $5 is a
Can someone please explain the columns printed by "go tool objdump"?
For example:
TEXT %22%22.main(SB) gofile../Users/abuchanan/projects/gobuild/simple/main.
go
main.go:30x2db65488b0c25MOVQ GS:0, CX
[5:9]R_TLS_LE
main.go:30x2e4483b61
lol!
Where are you rob?
We miss you!
On Thursday, 27 February 2020 23:23:57 UTC, Rob 'Commander' Pike wrote:
>
> Once bytten, twice shy.
>
> -rob
>
>
> On Fri, Feb 28, 2020 at 10:17 AM Jesper Louis Andersen <
> jesper.lo...@gmail.com > wrote:
>
>> The key observation is that you only look at a by
Once bytten, twice shy.
-rob
On Fri, Feb 28, 2020 at 10:17 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:
> The key observation is that you only look at a byte once.
>
> On Thu, Feb 27, 2020, 22:49 Amnon Baron Cohen wrote:
>
>> You are right.
>> I had wrongly assumed that u
The key observation is that you only look at a byte once.
On Thu, Feb 27, 2020, 22:49 Amnon Baron Cohen wrote:
> You are right.
> I had wrongly assumed that utf8.DecodeLastRuneInString has O(n) runtime.
> But it has constant runtime as it reads at most 4 bytes at the end of the
> string.
>
>
> O
On Thu, Feb 27, 2020 at 1:52 PM roger peppe wrote:
> If you really just want to reverse rune-by-rune, it's pretty
> straightforward:
>
> func Reverse(s string) string {
> r := make([]byte, 0, len(s))
> for len(s) > 0 {
> _, n := utf8.DecodeLastRuneInString(s)
>
On Mon, Feb 24, 2020 at 9:36 AM Elias Naur wrote:
>> For example, with Gio, I had to download a set of .DLL files and extract
>> them into the root folder of my Go build, as documented on the Gio website.
>
>
> I happen to be working on a direct3d port of Gio which I hope to have ready
> within
You are right.
I had wrongly assumed that utf8.DecodeLastRuneInString has O(n) runtime.
But it has constant runtime as it reads at most 4 bytes at the end of the
string.
On Thursday, 27 February 2020 21:47:19 UTC, kortschak wrote:
>
> Why? There's a single correctly sized allocation made up fron
Why? There's a single correctly sized allocation made up front and then
a linear time walk along the encoded runes with truncation after each
rune.
On Thu, 2020-02-27 at 13:05 -0800, Amnon Baron Cohen wrote:
> O(n^2)
>
> On Thursday, 27 February 2020 18:53:01 UTC, rog wrote:
> > If you really jus
As Ian pointed out you need to use
GODEBUG=asyncpreemptoff=1
> On Feb 27, 2020, at 2:26 PM, Peter Kleiweg wrote:
>
>
> GODEBUG=noasyncpreempt=1 makes no difference.
>
> I added the option -race and I got some warnings from that, all happening in
> a call to reactor.Run().
> When I disable
O(n^2)
On Thursday, 27 February 2020 18:53:01 UTC, rog wrote:
>
> If you really just want to reverse rune-by-rune, it's pretty
> straightforward:
>
> func Reverse(s string) string {
> r := make([]byte, 0, len(s))
> for len(s) > 0 {
> _, n := utf8.DecodeLastRuneInSt
The magic behind contexts is that they use a channel but without sending
any data over it. Instead, *closing* the channel is a signal to terminate.
This allows you to have multiple goroutines listening on the channel, and
they will *all* receive the termination signal, as a broadcast. (It
wou
GODEBUG=noasyncpreempt=1 makes no difference.
I added the option -race and I got some warnings from that, all happening
in a call to reactor.Run().
When I disable all tests that use reactor.Run() the test run no longer
freezes. So I have to look at
the implementation of the reactor.
I still ge
Hi Brian,
Thanks for your help. I will try out to implement your samples in my
project.
But still studying Goroutines and now Context.
El miércoles, 26 de febrero de 2020, 10:41:26 (UTC-3), Brian Candler
escribió:
>
> Perhaps slightly clearer:
> https://play.golang.org/p/DDZxqaEFi-T
>
>
On Thu, Feb 27, 2020 at 10:07 AM Robert Engels wrote:
>
> Does it freeze if you use GODEBUG=noasyncpreempt=1 ?
Sorry, I got it wrong earlier. It's GODEBUG=asyncpreemptoff=1.
I can verify that the tests seem to pass with
GODEBUG=asyncpreemptoff=1, and hang without it.
I took a quick look at Tes
If you really just want to reverse rune-by-rune, it's pretty
straightforward:
func Reverse(s string) string {
r := make([]byte, 0, len(s))
for len(s) > 0 {
_, n := utf8.DecodeLastRuneInString(s)
i := len(s) - n
r = append(r, s[i:]...)
Does it freeze if you use GODEBUG=noasyncpreempt=1 ?-Original Message-
From: Peter Kleiweg
Sent: Feb 27, 2020 11:59 AM
To: golang-nuts
Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
Op donderdag 27 februari 2020 18:50
Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor:
>
> On Thu, Feb 27, 2020 at 9:41 AM Robert Engels > wrote:
> >
> >
> > I re-read your comments, and I agree that a rare error is still and
> error, and needs to be handled, but if it the platform is introducing lots
> of e
On Thu, Feb 27, 2020 at 9:41 AM Robert Engels wrote:
>
>
> I re-read your comments, and I agree that a rare error is still and error,
> and needs to be handled, but if it the platform is introducing lots of
> errors, is that the library writers issue?
>
> Maybe an easy solution is a flag to disa
I re-read your comments, and I agree that a rare error is still and error, and
needs to be handled, but if it the platform is introducing lots of errors, is
that the library writers issue?
Maybe an easy solution is a flag to disable the signal usage for tight-loop
preemption as a "backwards c
I think the difference is that a user program can block signals when working
with certain devices. With Go that is not possible so the only choice is to not
use Go.
Unless I am missing something else?
> On Feb 27, 2020, at 9:52 AM, Ian Lance Taylor wrote:
>
> On Wed, Feb 26, 2020 at 8:36 PM
FYI, strided iteration is something we're trying to do better but this is
very tricky code, and it is also possible for it to get very expensive at
compile time.
On Saturday, February 22, 2020 at 4:42:03 PM UTC-5 Nigel Tao wrote:
> On 2/23/20, Bruno Albuquerque wrote:
> > Would adding an expl
On Wed, Feb 26, 2020 at 8:36 PM Robert Engels wrote:
>
> The problem is that Go designers are taking the position that any sys call
> should be able to be interrupted. This is invalid. For the vast majority or
> “unix” os an interrupt is a very rare condition and so they treat it as an
> error.
PC loser-ing is a brilliant thing which also finds its use in various
proofs about programming languages.
I guess the primary problem is that you have code out there which doesn't
assume the presence of a signal handler in the code, yet suddenly you get
EINTR back because of signal delivery in oth
On Thursday, February 27, 2020 at 2:15:14 AM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo > wrote:
> >
> > On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor
> wrote:
> >>
> >> On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo
> wrote:
>
26 matches
Mail list logo
