My goodness, it is a great honor to get your detailed explanation. It seems
that this is a fairly complicated algorithm. If I have time and can solve
this problem, I try to solve it. Thank you.
在 2020年6月11日星期四 UTC+8下午12:37:30，Joe Tsai写道：
>
> > Why has this code called Joe Tsai never been merged?
Thanks a lot, Ian, it works now.
On Thursday, June 11, 2020 at 2:17:23 PM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Jun 10, 2020 at 11:05 PM xiang...@gmail.com
> > wrote:
> >
> > Wondering if the 'expression' part of an if-statement should be in one
> line only, given the following case, 'go
On Wed, Jun 10, 2020 at 11:05 PM xiangdong...@gmail.com
wrote:
>
> Wondering if the 'expression' part of an if-statement should be in one line
> only, given the following case, 'go tool compile' will report a syntax error
>
> Enter code here...
> package p
>
> func cf1() int {
> return 0
Hi all,
Wondering if the 'expression' part of an if-statement should be in one line
only, given the following case, 'go tool compile' will report a syntax error
Enter code here...
package p
func cf1() int {
return 0
}
func cf2() int {
return 10
}
func f() {
*if cf2() -
> Why has this code called Joe Tsai never been merged?
I am Joe Tsai and the reason why my bzip2 encoder implementation has not
been merged is because I have not had time to do it. Though I am a
contributor to the standard library, curating and improving it is not my
primary responsibility. In
Thank you very much for your help. Following your suggestions and more
experimentation, the problem ended up being that I was asserting int,
string and bool types rather than *int, *string and *bool types. I should
have gotten a not ok back, but apparently not. I will have to figure out
why.
Yep. My timeline/memory was wrong. It was the 68k to PowerPC. Intel required
dual binaries. Thanks for the correction.
> On Jun 10, 2020, at 8:26 PM, David Riley wrote:
>
> Not quite. When they switched to PowerPC, that was the case; the initial one
> was a table-driven instruction translato
Not quite. When they switched to PowerPC, that was the case; the initial one
was a table-driven instruction translator in ROM originally written for the
M88k, which had been the original target before Motorola canned it, but it was
apparently a relatively simple thing to change the translations
This is so helpful, even in 2020. Thank you!
On Wednesday, January 11, 2012 at 3:29:18 AM UTC-8, kortschak wrote:
>
> package main
>
> import "fmt"
>
> func main() {
> outer := make(map[int]map[int][]string)
> outer[1] = make(map[int][]string)
> outer[1][2] = []string
Can you try to use
github.com/golang-sql/table
? That might help.
--
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 v
When Macs first switched to Intel the OS included a Motorola 68k emulator so
that existing Mac binaries would run.
> On Jun 10, 2020, at 6:17 PM, Scott Pakin wrote:
>
>
>> On Wednesday, June 10, 2020 at 1:24:24 PM UTC-6, David Riley wrote:
>> This is certainly pedantry, but it's worth noting
Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer).
It's my understanding that there is a significant performance penalty and I
don't share my machines
with anyone else, so I'm not concerned with information leaking between
processes.
Joe
On Wednesday, June 10, 2020 at 3:01
It sure does...thanks again :)
On Wednesday, June 10, 2020 at 5:34:23 PM UTC-6, andrey mirtchovski wrote:
>
> > Cool, makes sense. Assuming NewTicker does return monotonic time.
> >
> > I wonder if there is a way to verify.
>
> just fmt.Println the value you receive on the ticker chan, you'll
> Cool, makes sense. Assuming NewTicker does return monotonic time.
>
> I wonder if there is a way to verify.
just fmt.Println the value you receive on the ticker chan, you'll see
the monotonic component tacked on in the end:
$ cat t.go
package main
import (
"fmt"
"time"
)
func main() {
Cool, makes sense. Assuming NewTicker does return monotonic time.
I wonder if there is a way to verify.
On Wednesday, June 10, 2020 at 5:04:24 PM UTC-6, Ian Lance Taylor wrote:
>
> On Wed, Jun 10, 2020 at 3:48 PM Curtis Paul > wrote:
> >
> > It sounds like NewTicker will dynamically adjust to
Ya, I didn't see anything specific in that part of the doc regarding
NewTicker and monotonic. I did see that some things in time. do not
consider monotonic clock.
Then the blurb on NewTicker didn't say anything about monotonic.
I guess it's safe to assume NewTicker returns a monotonic clock tim
On Wednesday, June 10, 2020 at 1:24:24 PM UTC-6, David Riley wrote:
>
> This is certainly pedantry, but it's worth noting that the VAX to Alpha
> translation in VMS wasn't dynamic recompilation, but static. There are
> almost certainly similar examples; I'm not familiar enough with NT history
>
On Wed, Jun 10, 2020 at 3:48 PM Curtis Paul wrote:
>
> It sounds like NewTicker will dynamically adjust to keep tick time "accurate".
>
> Does anyone know if the time data that NewTicker returns (i.e. via it's
> channel, etc...) includes monotonic time?
> And if so is the definition of NewTicker
> Does anyone know if the time data that NewTicker returns (i.e. via it's
> channel, etc...) includes monotonic time?
it's right at the top: https://golang.org/pkg/time/
On Wed, Jun 10, 2020 at 4:48 PM Curtis Paul wrote:
>
> It sounds like NewTicker will dynamically adjust to keep tick time "ac
It sounds like NewTicker will dynamically adjust to keep tick time
"accurate".
Does anyone know if the time data that NewTicker returns (i.e. via it's
channel, etc...) includes monotonic time?
And if so is the definition of NewTicker referring to adjusting real time
clock or monotonic clock?
I
>> What about where there are multiple cpus? My servers have 2, 6 core
>> Xeons. With hyper threading, it looks like 24 cores available to
>Linux.
I know the latest issues also affect hyper threading/SMT but you shoukld
consider switching it off or using AMD, if you care about security. OpenBSD
seems to me whats relevant is that the core count is 'below' in the
software stack, so transparent, so here it will be 24.
but, like all progs, go progs use what they're told about, so you could
'see' less or you COULD be running inside an emulator that mimics,
potentially very slowly, any numb
surely simply recompiling a chunk of code with particular result(s) unused,
allows dead code removal from that version?
On Wednesday, 10 June 2020 21:43:14 UTC+1, Michael Jones wrote:
>
> This is beyond most translation systems.
>
> Interestingly, the exceptions are themselves old in origin.
>
This is beyond most translation systems.
Interestingly, the exceptions are themselves old in origin.
The LISP compiler, emerging after interpretation was the universal
environment for LISP, was able to “execute” the program being compiled to
discover what could be evaluated to a static conclusion
On Wednesday, June 10, 2020 at 1:03:41 PM UTC-7, joe mcguckin wrote:
>
> I read somewhere that the default # of GO threads is the number of cores
> of the cpu.
>
> What about where there are multiple cpus? My servers have 2, 6 core
> Xeons. With hyper threading, it looks like 24 cores available
2020. június 10., szerda 22:03:41 UTC+2 időpontban joe mcguckin a
következőt írta:
>
> I read somewhere that the default # of GO threads is the number of cores
> of the cpu.
>
> What about where there are multiple cpus? My servers have 2, 6 core
> Xeons. With hyper threading, it looks like 24 c
2020. június 9., kedd 1:03:14 UTC+2 időpontban Saied Seghatoleslami a
következőt írta:
>
> I am scanning database tables into a structure explicitly (with
> &struct.field) that works just fine (working path below).
>
> But my tables have different columns, so I am working to generalize the
> A
I read somewhere that the default # of GO threads is the number of cores of
the cpu.
What about where there are multiple cpus? My servers have 2, 6 core Xeons.
With hyper threading, it looks like 24 cores available to Linux.
Will the GO scheduler schedule GO routines on both CPU's?
If the sch
> Currently the compiler does not do the kind of optimization you
> describe. A function is compiled once, and computes all of its
> results. The caller receives all the results, and ignores ones that
> it does not need.
>
yes, i suppose the code generation route might give some insight as
On Jun 10, 2020, at 3:23 PM, David Riley wrote:
>
> Also worth noting that IBM i (f/k/a System i and AS/400) traditionally stores
> its executables as an IR form to be compiled to native code (currently PPC)
> on execution, though my recollection is that this is a one-time process, not
> a JIT
On Jun 10, 2020, at 5:50 AM, Jesper Louis Andersen
wrote:
>
> 2. Dynamic binary translation from machine-code to machine-code has been used
> in the past for these architectural changes. While this carries a penalty, it
> also provides a short-term solution. The added efficiency of recompiles
On Wed, Jun 10, 2020 at 11:28 AM 'simon place' via golang-nuts
wrote:
>
> when you have functions that return multiple values, because its more
> efficient to generate in one go when you are using ALL returned values;
>
> like in math, where you have Sin(), Cos() and Sincos()
>
> and when you als
Lol! Lack of sleep is real... apologies for the horrible keyboard offset
below. What I was trying to suggest was to check the case on your ID field.
In your struct it is all capitalized. The constant and my guess the
dereferenced string is a lower case i with a capital D. Running your code
Philosophically
On Wed, Jun 10, 2020 at 11:26 AM Michael Jones
wrote:
> Philosophy, this is one of the Go library’s most beautiful designs. It
> allows the one in charge—the program you write—to say what should happen,
> while allowing everything subordinate to be guided on how it should happen.
when you have functions that return multiple values, because its more
efficient to generate in one go when you are using ALL returned values;
like in math, where you have Sin(), Cos() and Sincos()
and when you also don't use all the returned values (using '_') does the
compiler optimise? does i
Philosophy, this is one of the Go library’s most beautiful designs. It
allows the one in charge—the program you write—to say what should happen,
while allowing everything subordinate to be guided on how it should happen.
This allows code to be adaptive to device optimal read sizes, network
happens
On Wed, Jun 10, 2020 at 2:32 AM Christophe Meessen
wrote:
>
> There is a rumor that Apple will announce at the WWDC2020, the 22 june, that
> the Macs of generation 2021 and beyond will use ARM processors in place of
> the Intel processors.
>
> Is Golang ready to follow this move ? Will I be able
On Wed, Jun 10, 2020 at 4:15 AM Viktor Kojouharov
wrote:
> Thanks Ian. Adding to that allocation to cover the element size did the
> trick. Out of curiosity, the momery allocated by mallocgc is still tracked
> by the gc, right?
> A brief look at the code seems to indicate that this is the case,
Reading in small chunks is handy for progress displays too.
--
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
Typically, a network communication system, like gRPC for example, will
accept contexts for network calls and turn context done-ness into an error.
The typical signature of an RPC-backed function is
func(context.Context, req *Request) (*Response, error)
If the context times out or is cancell
Ah, I was wrong. It is the iOS, watchOS, tvOS stuff that does that. The
name is "Bitcode".
On Wed, Jun 10, 2020 at 12:52 PM Robert Engels
wrote:
> The App Store does not store LLVM IR code for Mac software - at least not
> by default. It stores compiled binaries and optional debug symbols.
>
> O
Thanks Ian. Adding to that allocation to cover the element size did the
trick. Out of curiosity, the momery allocated by mallocgc is still tracked
by the gc, right?
A brief look at the code seems to indicate that this is the case, but I
don't know how the gc works.
On Monday, June 8, 2020 at 9
The App Store does not store LLVM IR code for Mac software - at least not by
default. It stores compiled binaries and optional debug symbols.
> On Jun 10, 2020, at 4:51 AM, Jesper Louis Andersen
> wrote:
>
>
> I'd say Go is as ready as you can be for that move. darwin/arm64 is currently
>
I'd say Go is as ready as you can be for that move. darwin/arm64 is
currently a fully supported architecture, and I doubt you need lots of work
in order to make the port to an eventual new Mac generation. By far the
most complex part of that port is support of arm64, but that work has
already been
There is a rumor that Apple will announce at the WWDC2020, the 22 june,
that the Macs of generation 2021 and beyond will use ARM processors in
place of the Intel processors.
Is Golang ready to follow this move ? Will I be able to compile and run my
go programs on ARM Macs ?
--
You received
45 matches
Mail list logo
