Re: [go-nuts] compress/bzip2：Why is there only a decompression function, no compression function.

['Joe Tsai' via golang-nuts]

> 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 contrast, my other responsibilities have 
continually kept any intention to merge the bzip2 encoder implementation at 
the bottom of the task list. The most complicated portion of a bzip2 
encoder is the implementation for a suffix array construction algorithm 
 (SACA). Such algorithms are 
fairly complex and require quite an investment by the reviewer to 
understand. Given that its' been years since I touched the code, I would 
hardly consider myself well-versed in SACAs at this point in time.

JT
On Tuesday, June 9, 2020 at 7:07:29 AM UTC-7 Michael Jones wrote:

> Chapter 13 in 'The Go Programming Language" uses bzip as an example of CGO 
> integration. Book is good, code is here:
> https://github.com/adonovan/gopl.io/tree/master/ch13/bzip
>
> On Mon, Jun 8, 2020 at 7:06 PM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> bzip2 compression is not trivial so making sure the review catches any
>> issues will take time. Finding people with the relevant expertise and
>> the time to do the review is not necessarily easy.
>>
>> Note that you can use the dsnet package.
>>
>> On Mon, 2020-06-08 at 18:55 -0700, lziq...@gmail.com wrote:
>> > 
>> > It seems that this issue was discussed long ago, but why is it not
>> > compressed because of the lack of reviewers? Why has this code called
>> > Joe Tsai never been merged? Does anyone have an official explanation?
>> > I don't understand too much.
>> > 在 2020年6月9日星期二 UTC+8上午5:30:34，kortschak写道：
>> > > Also see https://godoc.org/github.com/dsnet/compress/bzip2 and 
>> > > https://github.com/dsnet/compress/issues/58 
>> > > 
>> > > On Mon, 2020-06-08 at 13:14 -0400, Sam Whited wrote: 
>> > > > See: https://github.com/golang/go/issues/4828 
>> > > > 
>> > > > On Mon, Jun 8, 2020, at 05:09, lziq...@gmail.com wrote: 
>> > > > > Why is there no bzip2 compression algorithm, what is the
>> > > reason? Do 
>> > > > > you 
>> > > > > need to add it? 
>> > > > 
>> > > > —Sam 
>> > > > 
>> > > > -- 
>> > > > 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 golan...@googlegroups.com. 
>> > > > To view this discussion on the web visit 
>> > > > 
>> > > 
>> https://groups.google.com/d/msgid/golang-nuts/4e2007ea-0215-41d3-afdc-1f77330dbdbd%40www.fastmail.com
>> > >  
>> > > > . 
>> > > 
>> > > 
>> > 
>> > -- 
>> > 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/golang-nuts/d1ee336c-5ba7-4a60-9dc3-48f9d3141704o%40googlegroups.com
>> > .
>>
>>
>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9d35d55b58ac5b5c77e8290a2ad7319144535034.camel%40kortschak.io
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com*
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ade53cfa-f090-4127-a01d-6817dafbf2a8n%40googlegroups.com.

[go-nuts] Re: First column in sql rows.Scan is always zero

[Saied Seghatoleslami]

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.  The other odd thing was that after I fixed the ID field as below, the 
problem moved to the name field.  After that, I ended up changing 
everything as you see below.


func (p *Person) GetBack(get []string, g []interface{}) error {
for i, sp := range get {
switch sp {
case iD:
xID, ok := g[i].(*int)
if !ok {
return fmt.Errorf("ID (int) type assertion failed")
}
p.ID = *xID
case Name:
xName, ok := g[i].(*string)
if !ok {
return fmt.Errorf("Name (string) type assertion failed")
}
p.Name = *xName
case Email:
xEmail, ok := g[i].(*string)
if !ok {
return fmt.Errorf("Email (string) type assertion failed")
}
p.Email = *xEmail
case HashedPassword:
xPass, ok := g[i].(*string)
if !ok {
return fmt.Errorf("Hashed Password (string) type assertion failed")
}
p.HashedPassword = *xPass
case Created:
xCreated, ok := g[i].(*time.Time)
if !ok {
return fmt.Errorf("Created (time.Time) type assertion failed")
}
p.Created = *xCreated
case Role:
xRole, ok := g[i].(*string)
if !ok {
return fmt.Errorf("Role (string) type assertion failed")
}
p.Role = *xRole
case Active:
xActive, ok := g[i].(*bool)
if !ok {
return fmt.Errorf("Active (bool) type assertion failed")
}
p.Active = *xActive
case Online:
xOnline, ok := g[i].(*bool)
if !ok {
return fmt.Errorf("Online (bool) type assertion failed")
}
p.Online = *xOnline
}
}
return nil
}



On Monday, June 8, 2020 at 7:03:14 PM UTC-4, Saied Seghatoleslami wrote:
>
> I am scanning database tables into a structure explicitly (with 
> ) that works just fine (working path below).  
>
> But my tables have different columns, so I am working to generalize the 
> API.  There are two methods that build and reverse a []interface{} to be 
> supplied to scan.  I have listed them in the problem path.  The last item 
> is the people data in the use case.
>
> It scans every column correctly except the first one that is the ID.  
>
> The problem path always returns zero for the ID field while the working 
> path works fine.  I have been staring at it for a day and experimenting 
> with different ideas but no success
>
> Any thoughts?
>
>
>
> //=. Working Path =
>
> //Person is the target for scan.
> type Person struct {
> ID int
> Name   string
> Email  string
> HashedPassword string
> Createdtime.Time
> Role   string
> Active bool
> Online bool
> }
>
> //inside the "get" method to get the data
>
> person := broker.Person{}
> for rows.Next() {
> err := rows.Scan(, , , //g...)
> , , )
> if err != nil {
> if errors.Is(err, sql.ErrNoRows) {
> return broker.ErrNoRecord
> }
> return err
> }
> newPeople = append(newPeople, person)
> //=. Problem Path =
>
> person := broker.Person{}
> g := person.GetItems(e.Get)
> for rows.Next() {
> err := rows.Scan(g...)
> if err != nil {
> if errors.Is(err, sql.ErrNoRows) {
> return broker.ErrNoRecord
> }
> return err
> }
> person.GetBack(e.Get, g)
> newPeople = append(newPeople, person) 
>
>
>
>
> //note that iD, Name, Email... are constants
>
> //GetItems uses the get string to generate an interface to be passed to the
> //sql.Execute statement for the INSERT sql command.
> func (p *Person) GetItems(get []string) []interface{} {
> var g = []interface{}{}
> for _, sp := range get {
> switch sp {
> case iD:
> g = append(g, )
> case Name:
> g = append(g, )
> case Email:
> g = append(g, )
> case HashedPassword:
> g = append(g, )
> case Created:
> g = append(g, )
> case Role:
> g = append(g, )
> case Active:
> g = append(g, )
> case Online:
> g = append(g, )
> }
> }
> return g
> }
>
> //GetBack reverses the get item and takes the interface items and gets the
> //underlying data back.
> func (p *Person) GetBack(get []string, g []interface{}) error {
> var ok bool
> for i, sp := range get {
> switch sp {
> case iD:
> p.ID, ok = g[i].(int)
> if !ok {
> return fmt.Errorf("ID (int) type assertion failed")
> }
> case Name:
> p.Name, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Name (string) type assertion failed")
> }
> case Email:
> p.Email, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Email (string) type assertion failed")
> }
> case HashedPassword:
> p.HashedPassword, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Hashed Password (string) type assertion failed")
> }
> case Created:
> p.Created, ok = g[i].(time.Time)
> if !ok {
> return fmt.Errorf("Created (time.Time) type assertion failed")
> }
> case Role:
> p.Role, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Role (string) type assertion failed")
> }
> case Active:
> p.Active, ok = g[i].(bool)
> if !ok {
> return fmt.Errorf("Active (bool) type 

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Robert Engels]

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 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 to 
> PowerPC instructions (only took a weekend according to legend, but, well, 
> legends).  It eventually evolved into something much more sophisticated and 
> performant.
> 
> The transition from PowerPC to Intel ended the Classic VM environment that 
> ran Mac OS 9, which included the old 68k translator in the ROM file.  On a 
> PowerPC Mac running OS X 10.4 (including G5s, which are 64-bit!), you can run 
> 68k apps from the dark ages just fine (as long as they didn't use 
> undocumented interfaces, etc).  I've been doing exactly this recently while 
> porting a very old Mac game to modern systems.
> 
> Anyway, no Classic support on Intel, thus no 68k either (and PowerPC only for 
> OS X apps).  The PowerPC emulation for Intel (Apple called it "Rosetta") was 
> a licensed third-party product that used JIT-style compilation, but it really 
> only worked for userland programs; it didn't support drivers and it 
> presumably wasn't close enough to the real deal to support the Classic 
> environment, so they dropped it in all Intel versions of Mac OS (10.5 dropped 
> it for PowerPC as well for reasons I don't quite understand, since that was 
> the last PowerPC version).
> 
> Anyway, given that the PowerPC translation on Intel only lasted through 10.6, 
> and Apple just dropped 32-bit Intel support in 10.15, I would expect 
> backwards compatibility support for Intel apps (if they're even planning it) 
> to drop within 2-3 revisions of macOS after the transition.  Just putting 
> that out there.
> 
>> On Jun 10, 2020, at 8:47 PM, Robert Engels  wrote:
>> 
>> When Macs first switched to Intel the OS included a Motorola 68k emulator so 
>> that existing Mac binaries would run. 
> 

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F52A2A9B-EC30-4C9B-BA9F-1B342F7AC668%40ix.netcom.com.

[go-nuts] Re: Initialize a nested map

[carrie . neustar]

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{} // or equivalent 
>
> fmt.Println(outer) 
> } 
>
> On Jan 11, 9:11 pm, Archos  wrote: 
> > Is correct to use a nested map like this one? If so, how is 
> > initialized? 
> > 
> > var pointers map[int]map[int][]string

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ff021ecd-db4b-4011-94d8-4d7c1c9e8a57o%40googlegroups.com.

[go-nuts] First column in sql rows.Scan is always zero

[Daniel Theophanes]

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/07fab98e-c217-4fbc-82c4-686de2ab30b9o%40googlegroups.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Robert Engels]

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 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 
>> to remember if there was a similar translator for the Alpha version, but 
>> given that Dave Cutler was at the helm of that transition (though not the 
>> VAX->Alpha transition at DEC), I wouldn't be surprised. 
> 
> While we're off-topic anyway, I do recall hearing a nifty talk 20+ years ago 
> on semi-static translation from x86 to Alpha, both under Windows NT, that DEC 
> implemented.  They were worried about the dearth of Windows NT/Alpha software 
> relative to the volumes of Windows NT/x86 software so translation made a lot 
> of sense.  I recall the speaker making a point that PowerPoint posed a 
> challenge for them because their tool looked for known compiler 
> code-generation patterns that they could exploit for performance 
> (correctness?), but at the time, PowerPoint was hand-coded in assembly 
> language.  Imagine!
> 
> — Scott
> 
> P.S.  I just checked, and amazingly, the paper is still on the Web: DIGITAL 
> FX!32 Running 32-Bit x86 Applications on Alpha NT
> -- 
> 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 on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/5870abde-8141-4402-b964-95f1feb4240fo%40googlegroups.com.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/EF7610B6-A6C2-4D88-9AF9-36AE1E888025%40ix.netcom.com.

Re: [go-nuts] Re: GO on multi-processor systems

[joe mcguckin]

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:20 PM UTC-7, Kevin Chadwick wrote:
>
> >> 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 
> was proven right in that regard and yet Linux still kept it 
> insecure/enabled, by default!!! 
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b760915d-7717-4db2-bbf2-34111596d2e2o%40googlegroups.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[Curtis Paul]

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 see 
> the monotonic component tacked on in the end: 
>
> $ cat t.go 
> package main 
> import ( 
>"fmt" 
>"time" 
> ) 
> func main() { 
>t := time.NewTicker(time.Second) 
>fmt.Println(<-t.C) 
> } 
> $ go run t.go 
> 2020-06-10 17:31:04.234797 -0600 MDT m=+1.003493724 
> $ 
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/50264e57-13a8-4e8c-a8c3-05ca5060b1e0o%40googlegroups.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[andrey mirtchovski]

> 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() {
   t := time.NewTicker(time.Second)
   fmt.Println(<-t.C)
}
$ go run t.go
2020-06-10 17:31:04.234797 -0600 MDT m=+1.003493724
$

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykVjdRG2SDXBF1DNT67tCYQs0tex3-KZvDE-i0UTQU2OmQ%40mail.gmail.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[Curtis Paul]

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 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'm not really sure what to expect with using ticker in terms of timing 
> accuracy. 
> > Is NewTicker() monotonic? 
>
> Tickers use the monotonic clock. 
>
>
> > Also not quite sure what "Stop the ticker to release associated 
> resources" refers to. 
> > 
> > time.NewTicker() 
> > 
> > "NewTicker returns a new Ticker containing a channel that will send the 
> time with a period specified by the duration argument. It adjusts the 
> intervals or drops ticks to make up for slow receivers. The duration d must 
> be greater than zero; if not, NewTicker will panic. Stop the ticker to 
> release associated resources." 
>
> In the current implementations of Go, Tickers are not garbage 
> collected.  They run until they are stopped.  So if you don't stop a 
> ticker, it will keep ticking until your program exits. 
>
> (It is possible that future implementations will garbage collect 
> Tickers, but it still won't hurt to stop a ticker that you no longer 
> need.) 
>
> Ian 
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dbcf834c-381e-43da-9318-2e18de5e5753o%40googlegroups.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[Curtis Paul]

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 time and 
that time would be evaluated by the functions that work with monotonic.
Just wondering if anyone has had experience or knows something more 
specific about it.

On Wednesday, June 10, 2020 at 4:50:52 PM UTC-6, andrey mirtchovski wrote:
>
> > 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 
> "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'm not really sure what to expect with using ticker in terms of timing 
> accuracy. 
> > Is NewTicker() monotonic? 
> > 
> > Also not quite sure what "Stop the ticker to release associated 
> resources" refers to. 
> > 
> > time.NewTicker() 
> > 
> > "NewTicker returns a new Ticker containing a channel that will send the 
> time with a period specified by the duration argument. It adjusts the 
> intervals or drops ticks to make up for slow receivers. The duration d must 
> be greater than zero; if not, NewTicker will panic. Stop the ticker to 
> release associated resources." 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ec9cf4f2-5404-4512-9b57-b4816ea47adeo%40googlegroups.com.
>  
>
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/926230a2-fd49-45dd-8926-3231d12179f5o%40googlegroups.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Scott Pakin]

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 
> to remember if there was a similar translator for the Alpha version, but 
> given that Dave Cutler was at the helm of that transition (though not the 
> VAX->Alpha transition at DEC), I wouldn't be surprised. 
>

While we're off-topic anyway, I do recall hearing a nifty talk 20+ years 
ago on semi-static translation from x86 to Alpha, both under Windows NT, 
that DEC implemented.  They were worried about the dearth of Windows 
NT/Alpha software relative to the volumes of Windows NT/x86 software so 
translation made a lot of sense.  I recall the speaker making a point that 
PowerPoint posed a challenge for them because their tool looked for known 
compiler code-generation patterns that they could exploit for performance 
(correctness?), but at the time, PowerPoint was hand-coded in assembly 
language.  Imagine!

— Scott

P.S.  I just checked, and amazingly, the paper is still on the Web: DIGITAL 
FX!32 Running 32-Bit x86 Applications on Alpha NT 


-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5870abde-8141-4402-b964-95f1feb4240fo%40googlegroups.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[Ian Lance Taylor]

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 referring to adjusting real time 
> clock or monotonic clock?
>
> I'm not really sure what to expect with using ticker in terms of timing 
> accuracy.
> Is NewTicker() monotonic?

Tickers use the monotonic clock.


> Also not quite sure what "Stop the ticker to release associated resources" 
> refers to.
>
> time.NewTicker()
>
> "NewTicker returns a new Ticker containing a channel that will send the time 
> with a period specified by the duration argument. It adjusts the intervals or 
> drops ticks to make up for slow receivers. The duration d must be greater 
> than zero; if not, NewTicker will panic. Stop the ticker to release 
> associated resources."

In the current implementations of Go, Tickers are not garbage
collected.  They run until they are stopped.  So if you don't stop a
ticker, it will keep ticking until your program exits.

(It is possible that future implementations will garbage collect
Tickers, but it still won't hurt to stop a ticker that you no longer
need.)

Ian

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWccj0n1D%2BhaKvPRU0eVSDeJENDyBXzPMxb6p4WkHZiDw%40mail.gmail.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[andrey mirtchovski]

> 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 "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'm not really sure what to expect with using ticker in terms of timing 
> accuracy.
> Is NewTicker() monotonic?
>
> Also not quite sure what "Stop the ticker to release associated resources" 
> refers to.
>
> time.NewTicker()
>
> "NewTicker returns a new Ticker containing a channel that will send the time 
> with a period specified by the duration argument. It adjusts the intervals or 
> drops ticks to make up for slow receivers. The duration d must be greater 
> than zero; if not, NewTicker will panic. Stop the ticker to release 
> associated resources."
>
> --
> 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 on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ec9cf4f2-5404-4512-9b57-b4816ea47adeo%40googlegroups.com.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykWnn1_PFCEGmX1Y1srH1anEMoZqUb6LoZ2DeiWffGM%2BHg%40mail.gmail.com.

[go-nuts] Regarding time.NewTicker() and monotonic time

[Curtis Paul]

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'm not really sure what to expect with using ticker in terms of timing 
accuracy.
Is NewTicker() monotonic?

Also not quite sure what "Stop the ticker to release associated resources" 
refers to.

time.NewTicker()

"NewTicker returns a new Ticker containing a channel that will send the 
time with a period specified by the duration argument. It adjusts the 
intervals or drops ticks to make up for slow receivers. The duration d must 
be greater than zero; if not, NewTicker will panic. Stop the ticker to 
release associated resources."

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ec9cf4f2-5404-4512-9b57-b4816ea47adeo%40googlegroups.com.

Re: [go-nuts] Re: GO on multi-processor systems

[Kevin Chadwick]

>> 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 was 
proven right in that regard and yet Linux still kept it insecure/enabled, by 
default!!!

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D29E1BC0-C83F-4AD1-9455-D907EA261B70%40gmail.com.

[go-nuts] Re: GO on multi-processor systems

['simon place' via golang-nuts]

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 number.

also since the OS is 'just' a program, it too could be running with 
reserved cores or inside any emulator. (would guess windows will detect and 
do licence/pricing related restrictions on you though.)

On Wednesday, 10 June 2020 21:03:41 UTC+1, 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 to Linux.
>
> Will the GO scheduler schedule GO routines on both CPU's?
>
> If the scheduler is running on one core, how does it manage to put GO 
> routines on other cores and/or CPU's? Does it create system threads (or 
> pthreads) on each of the other 
> cores and CPU's? Can it pin a thread to a specific core, or are you at the 
> mercy of the OS thread scheduler?
>
> Inquiring minds want to know...
>
> Thanks,
>
> Joe
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1b05ce92-7b3b-44cc-8eb3-7b42dca91777o%40googlegroups.com.

Re: [go-nuts] function multiple returned values signature, compiler optimisation/feature question

['simon place' via golang-nuts]

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. 
>
> 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, or a simpler case 
> of the general one. 
>
> From about the same time, the early symbolic algebra systems had this same 
> notion in their runtimes of iteritavely evaluating expressions until a 
> fixed point In code terms was reached. REDUCE and MACSYMA are in my 
> thoughts here. Mathematica has a sense of this too in some of its 
> programming modes, an organic rule-driven rewrite system. (It is brilliant 
> at the task)
>
> Not something seen in general languages very much. Some flavor of it in C 
> metaprogramming. 
>
> On Wed, Jun 10, 2020 at 11:28 AM 'simon place' via golang-nuts <
> golan...@googlegroups.com > 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 also don't use all the returned values (using '_') does the 
>> compiler optimise? does it compile multiple times so dead code is removed 
>> from the version used with some return values unneeded?
>>
>> i would guess it doesn't, but i wanted to check, because i seem to keep 
>> coming over this, probably the way i think, seems to me to reduce the 
>> solution space.
>>
>> also this seems to, in some ways, overlap with generics, particularly if 
>> there were new language features that let you specify some high 
>> level/simple code path changes, things specific to the problem that the 
>> compiler could never determine.
>>
>> i guess with code generation its possible, but that doesn't feel like the 
>> best way to go.
>>
>> i could have tested for this but am also interested in all 
>> architectures/future developments/other ways to achieve this.
>>
>> thanks.
>>
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/3369daf2-2cbd-4390-875b-e62eb4fab73ao%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4296-d199-4386-b4fb-c6eb41654309o%40googlegroups.com.

Re: [go-nuts] function multiple returned values signature, compiler optimisation/feature question

[Michael Jones]

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, or a simpler case
of the general one.

>From about the same time, the early symbolic algebra systems had this same
notion in their runtimes of iteritavely evaluating expressions until a
fixed point In code terms was reached. REDUCE and MACSYMA are in my
thoughts here. Mathematica has a sense of this too in some of its
programming modes, an organic rule-driven rewrite system. (It is brilliant
at the task)

Not something seen in general languages very much. Some flavor of it in C
metaprogramming.

On Wed, Jun 10, 2020 at 11:28 AM 'simon place' via golang-nuts <
golang-nuts@googlegroups.com> 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 also don't use all the returned values (using '_') does the
> compiler optimise? does it compile multiple times so dead code is removed
> from the version used with some return values unneeded?
>
> i would guess it doesn't, but i wanted to check, because i seem to keep
> coming over this, probably the way i think, seems to me to reduce the
> solution space.
>
> also this seems to, in some ways, overlap with generics, particularly if
> there were new language features that let you specify some high
> level/simple code path changes, things specific to the problem that the
> compiler could never determine.
>
> i guess with code generation its possible, but that doesn't feel like the
> best way to go.
>
> i could have tested for this but am also interested in all
> architectures/future developments/other ways to achieve this.
>
> thanks.
>
>
> --
> 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 on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3369daf2-2cbd-4390-875b-e62eb4fab73ao%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQxHLbLcbs84rUc-09gR8j4nm-jQH7yqU9BrHSnC_iM4%3Dg%40mail.gmail.com.

[go-nuts] Re: GO on multi-processor systems

[Sam Mortimer]

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 to Linux.
>
> Will the GO scheduler schedule GO routines on both CPU's?
>
> If the scheduler is running on one core, how does it manage to put GO 
> routines on other cores and/or CPU's? Does it create system threads (or 
> pthreads) on each of the other 
> cores and CPU's? Can it pin a thread to a specific core, or are you at the 
> mercy of the OS thread scheduler?
>
> Inquiring minds want to know...
>
> Thanks,
>
> Joe
>

FYI - Go on linux uses the result of a sched_getaffinity() system call to 
determine cpu count:
https://github.com/golang/go/blob/e92be18fd8b525b642ca25bdb3e2056b35d9d73c/src/runtime/os_linux.go#L82

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b4a1721c-78e0-4993-b55e-5578f2ca1339o%40googlegroups.com.

[go-nuts] Re: GO on multi-processor systems

[Tamás Gulácsi]

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 cores available to Linux.
>
> Will the GO scheduler schedule GO routines on both CPU's?
>
> If the scheduler is running on one core, how does it manage to put GO 
> routines on other cores and/or CPU's? Does it create system threads (or 
> pthreads) on each of the other 
> cores and CPU's? Can it pin a thread to a specific core, or are you at the 
> mercy of the OS thread scheduler?
>
> Inquiring minds want to know...
>
> Thanks,
>
> Joe
>


AFAIK it will use all cores, that's 24 on you.
It will use 24 system threads to run goroutines (and many more for 
syscalls),
and it's  at the mercy of the OS thread scheduler :)

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/56e8c321-c668-423b-a710-7a6da28fd62co%40googlegroups.com.

[go-nuts] Re: First column in sql rows.Scan is always zero

[Tamás Gulácsi]

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 
> ) that works just fine (working path below).  
>
> But my tables have different columns, so I am working to generalize the 
> API.  There are two methods that build and reverse a []interface{} to be 
> supplied to scan.  I have listed them in the problem path.  The last item 
> is the people data in the use case.
>
> It scans every column correctly except the first one that is the ID.  
>
> The problem path always returns zero for the ID field while the working 
> path works fine.  I have been staring at it for a day and experimenting 
> with different ideas but no success
>
> Any thoughts?
>
>
>
> //=. Working Path =
>
> //Person is the target for scan.
> type Person struct {
> ID int
> Name   string
> Email  string
> HashedPassword string
> Createdtime.Time
> Role   string
> Active bool
> Online bool
> }
>
> //inside the "get" method to get the data
>
> person := broker.Person{}
> for rows.Next() {
> err := rows.Scan(, , , //g...)
> , , )
> if err != nil {
> if errors.Is(err, sql.ErrNoRows) {
> return broker.ErrNoRecord
> }
> return err
> }
> newPeople = append(newPeople, person)
> //=. Problem Path =
>
> person := broker.Person{}
> g := person.GetItems(e.Get)
> for rows.Next() {
> err := rows.Scan(g...)
> if err != nil {
> if errors.Is(err, sql.ErrNoRows) {
> return broker.ErrNoRecord
> }
> return err
> }
> person.GetBack(e.Get, g)
> newPeople = append(newPeople, person) 
>
>
>
>
> //note that iD, Name, Email... are constants
>
> //GetItems uses the get string to generate an interface to be passed to the
> //sql.Execute statement for the INSERT sql command.
> func (p *Person) GetItems(get []string) []interface{} {
> var g = []interface{}{}
> for _, sp := range get {
> switch sp {
> case iD:
> g = append(g, )
> case Name:
> g = append(g, )
> case Email:
> g = append(g, )
> case HashedPassword:
> g = append(g, )
> case Created:
> g = append(g, )
> case Role:
> g = append(g, )
> case Active:
> g = append(g, )
> case Online:
> g = append(g, )
> }
> }
> return g
> }
>
> //GetBack reverses the get item and takes the interface items and gets the
> //underlying data back.
> func (p *Person) GetBack(get []string, g []interface{}) error {
> var ok bool
> for i, sp := range get {
> switch sp {
> case iD:
> p.ID, ok = g[i].(int)
> if !ok {
> return fmt.Errorf("ID (int) type assertion failed")
> }
> case Name:
> p.Name, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Name (string) type assertion failed")
> }
> case Email:
> p.Email, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Email (string) type assertion failed")
> }
> case HashedPassword:
> p.HashedPassword, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Hashed Password (string) type assertion failed")
> }
> case Created:
> p.Created, ok = g[i].(time.Time)
> if !ok {
> return fmt.Errorf("Created (time.Time) type assertion failed")
> }
> case Role:
> p.Role, ok = g[i].(string)
> if !ok {
> return fmt.Errorf("Role (string) type assertion failed")
> }
> case Active:
> p.Active, ok = g[i].(bool)
> if !ok {
> return fmt.Errorf("Active (bool) type assertion failed")
> }
> case Online:
> p.Online, ok = g[i].(bool)
> if !ok {
> return fmt.Errorf("Online (bool) type assertion failed")
> }
> }
> }
> return nil
> }
>
> exchange := Exchange{
> Table: table,
> Put:   []string{},
> Spec:  []string{iD},
> Get: []string{iD, Name, Email, HashedPassword, Created,
> Active, Online},
> People: []Person{
> Person{ID: id},
> },
> Action: "get",
> }
>
>
>
I don't see anything obviously wrong here.
Sprinkle it with log.Printfs around everywhere iD is, and make sure that it 
IS getting set, with the correct value!

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/afbb767b-601c-47f1-9a42-714be988b805o%40googlegroups.com.

[go-nuts] GO on multi-processor systems

[joe mcguckin]

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 scheduler is running on one core, how does it manage to put GO 
routines on other cores and/or CPU's? Does it create system threads (or 
pthreads) on each of the other 
cores and CPU's? Can it pin a thread to a specific core, or are you at the 
mercy of the OS thread scheduler?

Inquiring minds want to know...

Thanks,

Joe

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/54e11b33-5c76-4eed-ae34-76a41f20f781o%40googlegroups.com.

Re: [go-nuts] function multiple returned values signature, compiler optimisation/feature question

['simon place' via golang-nuts]

> 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 to if 
this might be worth it, but you probably have to  code to it and so the 
results wouldn't then clearly differentiate.
 

> We could implement the general optimization by compiling a function 
> multiple times, for each permutation of the possible results.  


i feel it might not be that bad; you only need the permutations that are 
actually being used and the feeling i have is that a given problem, and so 
a given program, will tend to only use a small selected subset of 
permutations.
 

> But I think it's clear that that effort would generally be wasted.  So we 
> would need some way to decide when this optimization would be useful. 
> And note that any effort in this area would tend to go against the 
> overall goal of fast compilation time. 
>

given above is correct you could probably just limit the number.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b823a6b2-f027-416c-9464-664e5df05561o%40googlegroups.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[David Riley]

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 process like Java or WASM.

Well. Actually, currently POWER, as long as I'm being pedantic. :-)


- Dave

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/039A4634-08AD-4EAE-BB25-498B456B46D2%40gmail.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[David Riley]

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 for 
> the new machine code target encourages people to install newer versions in 
> the case. The history is old and long here. M68K to PowerPC, PowerPC to x86, 
> x86 to DEC Alpha, VAX to Alpha RISC, and even more. Apple have been involved 
> in at least two such models in the past, so I wouldn't count this out as a 
> strategy.

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 to remember 
if there was a similar translator for the Alpha version, but given that Dave 
Cutler was at the helm of that transition (though not the VAX->Alpha transition 
at DEC), I wouldn't be surprised.

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 
process like Java or WASM.


- Dave

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B924AC7A-F592-4FFA-A56F-75134C626D04%40gmail.com.

Re: [go-nuts] function multiple returned values signature, compiler optimisation/feature question

[Ian Lance Taylor]

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 also don't use all the returned values (using '_') does the 
> compiler optimise? does it compile multiple times so dead code is removed 
> from the version used with some return values unneeded?
>
> i would guess it doesn't, but i wanted to check, because i seem to keep 
> coming over this, probably the way i think, seems to me to reduce the 
> solution space.
>
> also this seems to, in some ways, overlap with generics, particularly if 
> there were new language features that let you specify some high level/simple 
> code path changes, things specific to the problem that the compiler could 
> never determine.
>
> i guess with code generation its possible, but that doesn't feel like the 
> best way to go.
>
> i could have tested for this but am also interested in all 
> architectures/future developments/other ways to achieve this.

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.

Of course, if the function is inlined, then any code leading to
results that are not needed will be discarded.  But most functions are
not inlined.

We could implement the general optimization by compiling a function
multiple times, for each permutation of the possible results.  But I
think it's clear that that effort would generally be wasted.  So we
would need some way to decide when this optimization would be useful.
And note that any effort in this area would tend to go against the
overall goal of fast compilation time.

Ian

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUq34gWU1RryhxLsixwmsN2fOXg%3Dg%3DqvN%2BgGTtHc0azEg%40mail.gmail.com.

[go-nuts] First column in sql rows.Scan is always zero

[David Suarez]

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 
through a debugger at that point might confirm why it isnt falling into your 
expected area vs my above guess based on the case mismatch of your ahortened 
example. 
 Good luck!  I am sure you will figure it out soon... David

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cfb4e2e8-7616-49a2-92f7-bdcf450b5cdao%40googlegroups.com.

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

[Michael Jones]

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.
>
> This allows code to be adaptive to device optimal read sizes, network
> happenstance, the size of various buffers in code that you can’t see, etc.
>
> Maximum flexibility, simple formulaic coding:
>
> While not done, Use this, Ask for more.
>
> On Wed, Jun 10, 2020 at 7:45 AM Ronny Bangsund 
> wrote:
>
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/115eb9de-b821-44ae-a91c-b8dde26c28beo%40googlegroups.com
>> 
>> .
>>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyYhEsr_%3DQUKr_GoBAiRcSCvGsZU%3DAoSm98Pih8n6mEbQ%40mail.gmail.com.

[go-nuts] function multiple returned values signature, compiler optimisation/feature question

['simon place' via golang-nuts]

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 it compile multiple times so dead code is removed 
from the version used with some return values unneeded?

i would guess it doesn't, but i wanted to check, because i seem to keep 
coming over this, probably the way i think, seems to me to reduce the 
solution space.

also this seems to, in some ways, overlap with generics, particularly if 
there were new language features that let you specify some high 
level/simple code path changes, things specific to the problem that the 
compiler could never determine.

i guess with code generation its possible, but that doesn't feel like the 
best way to go.

i could have tested for this but am also interested in all 
architectures/future developments/other ways to achieve this.

thanks.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3369daf2-2cbd-4390-875b-e62eb4fab73ao%40googlegroups.com.

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

[Michael Jones]

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
happenstance, the size of various buffers in code that you can’t see, etc.

Maximum flexibility, simple formulaic coding:

While not done, Use this, Ask for more.

On Wed, Jun 10, 2020 at 7:45 AM Ronny Bangsund 
wrote:

> 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 discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/115eb9de-b821-44ae-a91c-b8dde26c28beo%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQxja1C%2BEGRToUSkK2iBz2Hqna1dxB0%3DD0hyP-8v5Fr%2BwA%40mail.gmail.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Ian Lance Taylor]

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 to compile and run my go 
> programs on ARM Macs ?

We are tracking this at https://golang.org/issue/38485.

Ian

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX54rByHptEdhT8yCioozzC%3DOwsAPnwuf6r5YaWUaKHBg%40mail.gmail.com.

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

[Keith Randall]

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, but I
> don't know how the gc works.
>

Correct.


>
> On Monday, June 8, 2020 at 9:41:21 PM UTC+3, Ian Lance Taylor wrote:
>>
>> On Mon, Jun 8, 2020 at 10:44 AM Viktor Kojouharov 
>> wrote:
>> >
>> > The full code can be seen in this diff:
>> >
>> >
>> https://github.com/urandom/go/commit/d10ccdd907dac690bfcb31df1115ce1508775458
>> >
>> > The just of it is, I've added an extra field to a struct (the chan) of
>> type unsafe.Pointer. The value is then copied (allegedly) to a target
>> pointer in chanrecv using typedmemmove. The types of both pointers are the
>> same, as defined by the chan's elemtype
>>
>> I only took a quick look, but it looks like you have added a pointer
>> field to hchan, and presumably the garbage collector needs to know
>> about that pointer.  If you look at makechan in runtime/chan.go, you
>> will see that a channel whose element type does not contain any
>> pointers is allocated in such a way that the garbage collector never
>> looks at it.  That will break with your new pointer, as the collector
>> can collect the value to which the new pointer points without changing
>> that pointer.
>>
>> Ian
>>
>>
>>
>> > On Monday, June 8, 2020 at 3:12:18 AM UTC+3, keith@gmail.com
>> wrote:
>> >>
>> >> Showing us some code would really help. It's hard to understand what
>> you are doing from this brief description. Also, where does the SIGBUS
>> occur? What pc, and what address?
>> >>
>> >> What types are you passing as the first argument to typedmemmove?
>> Where did you get them from?
>> >>
>> >> This is a fine question for golang-dev, but don't expect a whole lot
>> of help - reaching into the runtime to call typedmemmove is very
>> unsupported.
>> >>
>> >> On Sunday, June 7, 2020 at 10:02:21 AM UTC-7, Michael Jones wrote:
>> >>>
>> >>> Thank you. I now officially know that I don’t understand. Sorry.
>> >>>
>> >>> On Sun, Jun 7, 2020 at 7:54 AM Viktor Kojouharov 
>> wrote:
>> 
>>  The pointer is being copied via typedmemmove, which itself calls
>> memmove, which, according to its documentation, copies bytes from the
>> source to the destination. Not sure why that would be impossible,
>> considering it does work for some code (the source pointer preserves its
>> data)
>> 
>>  Not sure what you mean by "copied via unsafe". Also, the source
>> pointer never goes out of scope. It's part of a struct that is passed to
>> the function that calls typedmemmove, and its lifetime is more or less
>> static. So while the destination pointers go out of scope, the source one
>> never does.
>> 
>> 
>>  On Sunday, June 7, 2020 at 4:45:40 PM UTC+3, Michael Jones wrote:
>> >
>> > Do you mean that you have a problem with the value of the pointer?
>> That is "copying the pointer." This seems impossible.
>> >
>> > Attempting to access through a pointer copied via unsafe is
>> (generally) inviting doom, and seems highly possible. The instant the last
>> pointer to that data goes out of scope the address range occupied by the
>> formerly pointed to items is formally inaccessible. Using unsafe to keep a
>> shadow copy of the address and then poking around is quite likely to fail,
>> and even when it does not, it is quite likely to be meaningless. (random
>> data from some other use).
>> >
>> > If I misunderstood, please forgive me.
>> >
>> > On Sun, Jun 7, 2020 at 6:15 AM Viktor Kojouharov <
>> vkojo...@gmail.com> wrote:
>> >>
>> >> p.s. should such questions be posted in golang-dev, since it deals
>> with runtime internals?
>> >>
>> >> --
>> >> 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 golan...@googlegroups.com.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/71d7fb5c-3ef5-4611-b9ce-299f7b90945eo%40googlegroups.com.
>>
>> >
>> >
>> >
>> > --
>> > Michael T. Jones
>> > michae...@gmail.com
>> 
>>  --
>>  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 golan...@googlegroups.com.
>>  To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/fa18bf7e-8965-4917-9d81-00a8f43289c3o%40googlegroups.com.
>>
>> >>>
>> >>> --
>> >>> Michael T. Jones
>> >>> michae...@gmail.com
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop 

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

[Ronny Bangsund]

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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/115eb9de-b821-44ae-a91c-b8dde26c28beo%40googlegroups.com.

Re: [go-nuts] Using context package for goroutines cancellation is quite verbose

[Jonathan Amsterdam]

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 cancelled, a good RPC library will return 
from this call immediately with a non-nil error. So context done-ness 
checking is just part of ordinary error checking.

I'm not sure how you're mapping the RPCs to channels. If you're doing

res, err := RPC(ctx, req)
if err != nil { return ... }
ch <- res

then you indeed have a problem: you'll need another check whenever you 
receive from the channel. But if you're doing

res, err := RPC(ctx, req)
ch <- rpcResult{res, err}

then receivers don't have to check ctx.Done, but of course they do have to 
check the error:

result <- ch
if result.err != nil { ...}
// use result.res
 
Channels are a bit awkward either way, so for the Google Cloud client 
libraries we use an iterator pattern (
https://github.com/googleapis/google-cloud-go/wiki/Iterator-Guidelines).

On Tuesday, June 9, 2020 at 8:04:21 AM UTC-4, Yegor Roganov wrote:
>
> Thanks Ian, it's nice to know that we're using Go correctly.
>
> I agree that more code doesn't really matter, and I think I'd be 
> completely fine with this situation had there been a vet check that ensured 
> that no selects are forgotten.
> Let's see if generics change something in this area.
>
> On Monday, June 8, 2020 at 10:46:05 PM UTC+3, Ian Lance Taylor wrote:
>>
>> On Mon, Jun 8, 2020 at 9:59 AM Yegor Roganov  wrote: 
>> > 
>> > My team is developing a cloud-based data processing application, and a 
>> large bulk of the application's job is doing network calls to other 
>> services. 
>> > Go's goroutines and channel-based communication are an excellent fit, 
>> but in order for the application to be able to properly shut down, 
>> > simple construct of sending to a channel `myChan <- value` needs to 
>> actually be something like: 
>> > 
>> > ``` 
>> > 
>> > select { 
>> > case myChan <- value: 
>> > case <-ctx.Done(): 
>> >return ctx.Err() 
>> > } 
>> > 
>> > ``` 
>> > 
>> > As you see, a simple one line construct needs to be replaced with a 
>> select on context.Done EVERYWHERE. 
>> > My two gripes with this situation are: 
>> > 
>> > 1) It's more code and "clutter" which makes code less clear 
>> > 2) It's easy to forget to do a select on context.Done, and then an 
>> application is unable to shut down. 
>> > 
>> > Am I doing something wrong? Does someone relate with me? 
>>
>> You are not doing anything wrong, and, you're right: it's more code. 
>>
>> In general, Go prefers code to be explicit rather than implicit, so I 
>> don't really agree that this makes the code less clear.  I think that 
>> this code is clear to anybody who knows Go, and with more experience 
>> it becomes fairly idiomatic. 
>>
>> But you're absolutely right that it's easy to forget to do a select. 
>>
>> Personally I think that this is an area where generics can help.  For 
>> example, from the design draft published last year, see 
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md#channels
>>  
>> .  I think the right step here is going to be see how generics can 
>> help with these common patterns before trying other approaches.  I 
>> acknowledge that that is a slow process. 
>>
>> Ian 
>>
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de39eb18-2188-4236-ac33-6ec9109ce68fo%40googlegroups.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Jesper Louis Andersen]

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.
>
> On Jun 10, 2020, at 4:51 AM, Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
> 
> 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 done.
>
> However, it might still require some extra bits of work here and there if
> I should hazard a guess. So immediate support might not be present. Then
> again, Apple would need to have some kind of plan in place for the move in
> general. I can see two paths they can take:
>
> 1. Most of the Apple Store, at least to my knowledge, stores LLVM IR
> rather than the final machine code product. This allows Apple to recompile
> programs in the store for a new architecture. While this won't support
> certain programs with Intel assembly, the vast majority of programs would
> be supported almost from the first day.
>
> 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 for the new machine code target encourages people to install
> newer versions in the case. The history is old and long here. M68K to
> PowerPC, PowerPC to x86, x86 to DEC Alpha, VAX to Alpha RISC, and even
> more. Apple have been involved in at least two such models in the past, so
> I wouldn't count this out as a strategy.
>
> On Wed, Jun 10, 2020 at 11:32 AM Christophe Meessen <
> christophe.mees...@gmail.com> 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 to compile and run
>> my go programs on ARM Macs ?
>>
>> --
>> 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 on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/f8bd2b7a-99e1-47f1-8cc5-3d37a1aeade5o%40googlegroups.com
>> 
>> .
>>
>
>
> --
> J.
>
> --
> 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 on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUbDPbMz_io9DMTmcxD04axZ6Ap8ff2OANfZPED8YQ3VA%40mail.gmail.com
> 
> .
>
>

-- 
J.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiU9xD7QrOvTbrtAU_42zXPZoCTyvbMJDntN4ObEekCZSg%40mail.gmail.com.

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

[Viktor Kojouharov]

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:41:21 PM UTC+3, Ian Lance Taylor wrote:
>
> On Mon, Jun 8, 2020 at 10:44 AM Viktor Kojouharov  > wrote: 
> > 
> > The full code can be seen in this diff: 
> > 
> > 
> https://github.com/urandom/go/commit/d10ccdd907dac690bfcb31df1115ce1508775458 
> > 
> > The just of it is, I've added an extra field to a struct (the chan) of 
> type unsafe.Pointer. The value is then copied (allegedly) to a target 
> pointer in chanrecv using typedmemmove. The types of both pointers are the 
> same, as defined by the chan's elemtype 
>
> I only took a quick look, but it looks like you have added a pointer 
> field to hchan, and presumably the garbage collector needs to know 
> about that pointer.  If you look at makechan in runtime/chan.go, you 
> will see that a channel whose element type does not contain any 
> pointers is allocated in such a way that the garbage collector never 
> looks at it.  That will break with your new pointer, as the collector 
> can collect the value to which the new pointer points without changing 
> that pointer. 
>
> Ian 
>
>
>
> > On Monday, June 8, 2020 at 3:12:18 AM UTC+3, keith@gmail.com wrote: 
> >> 
> >> Showing us some code would really help. It's hard to understand what 
> you are doing from this brief description. Also, where does the SIGBUS 
> occur? What pc, and what address? 
> >> 
> >> What types are you passing as the first argument to typedmemmove? Where 
> did you get them from? 
> >> 
> >> This is a fine question for golang-dev, but don't expect a whole lot of 
> help - reaching into the runtime to call typedmemmove is very unsupported. 
> >> 
> >> On Sunday, June 7, 2020 at 10:02:21 AM UTC-7, Michael Jones wrote: 
> >>> 
> >>> Thank you. I now officially know that I don’t understand. Sorry. 
> >>> 
> >>> On Sun, Jun 7, 2020 at 7:54 AM Viktor Kojouharov  
> wrote: 
>  
>  The pointer is being copied via typedmemmove, which itself calls 
> memmove, which, according to its documentation, copies bytes from the 
> source to the destination. Not sure why that would be impossible, 
> considering it does work for some code (the source pointer preserves its 
> data) 
>  
>  Not sure what you mean by "copied via unsafe". Also, the source 
> pointer never goes out of scope. It's part of a struct that is passed to 
> the function that calls typedmemmove, and its lifetime is more or less 
> static. So while the destination pointers go out of scope, the source one 
> never does. 
>  
>  
>  On Sunday, June 7, 2020 at 4:45:40 PM UTC+3, Michael Jones wrote: 
> > 
> > Do you mean that you have a problem with the value of the pointer? 
> That is "copying the pointer." This seems impossible. 
> > 
> > Attempting to access through a pointer copied via unsafe is 
> (generally) inviting doom, and seems highly possible. The instant the last 
> pointer to that data goes out of scope the address range occupied by the 
> formerly pointed to items is formally inaccessible. Using unsafe to keep a 
> shadow copy of the address and then poking around is quite likely to fail, 
> and even when it does not, it is quite likely to be meaningless. (random 
> data from some other use). 
> > 
> > If I misunderstood, please forgive me. 
> > 
> > On Sun, Jun 7, 2020 at 6:15 AM Viktor Kojouharov  
> wrote: 
> >> 
> >> p.s. should such questions be posted in golang-dev, since it deals 
> with runtime internals? 
> >> 
> >> -- 
> >> 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 golan...@googlegroups.com. 
> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/71d7fb5c-3ef5-4611-b9ce-299f7b90945eo%40googlegroups.com.
>  
>
> > 
> > 
> > 
> > -- 
> > Michael T. Jones 
> > michae...@gmail.com 
>  
>  -- 
>  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 golan...@googlegroups.com. 
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/fa18bf7e-8965-4917-9d81-00a8f43289c3o%40googlegroups.com.
>  
>
> >>> 
> >>> -- 
> >>> Michael T. Jones 
> >>> michae...@gmail.com 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Robert Engels]

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 
> 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 done.
> 
> However, it might still require some extra bits of work here and there if I 
> should hazard a guess. So immediate support might not be present. Then again, 
> Apple would need to have some kind of plan in place for the move in general. 
> I can see two paths they can take:
> 
> 1. Most of the Apple Store, at least to my knowledge, stores LLVM IR rather 
> than the final machine code product. This allows Apple to recompile programs 
> in the store for a new architecture. While this won't support certain 
> programs with Intel assembly, the vast majority of programs would be 
> supported almost from the first day.
> 
> 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 for 
> the new machine code target encourages people to install newer versions in 
> the case. The history is old and long here. M68K to PowerPC, PowerPC to x86, 
> x86 to DEC Alpha, VAX to Alpha RISC, and even more. Apple have been involved 
> in at least two such models in the past, so I wouldn't count this out as a 
> strategy.
> 
>> On Wed, Jun 10, 2020 at 11: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 to compile and run my 
>> go programs on ARM Macs ? 
>> -- 
>> 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 on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f8bd2b7a-99e1-47f1-8cc5-3d37a1aeade5o%40googlegroups.com.
> 
> 
> -- 
> J.
> -- 
> 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 on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUbDPbMz_io9DMTmcxD04axZ6Ap8ff2OANfZPED8YQ3VA%40mail.gmail.com.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21E7231A-F136-4860-8D39-9E18A341BCD1%40ix.netcom.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Jesper Louis Andersen]

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 done.

However, it might still require some extra bits of work here and there if I
should hazard a guess. So immediate support might not be present. Then
again, Apple would need to have some kind of plan in place for the move in
general. I can see two paths they can take:

1. Most of the Apple Store, at least to my knowledge, stores LLVM IR rather
than the final machine code product. This allows Apple to recompile
programs in the store for a new architecture. While this won't support
certain programs with Intel assembly, the vast majority of programs would
be supported almost from the first day.

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 for the new machine code target encourages people to install
newer versions in the case. The history is old and long here. M68K to
PowerPC, PowerPC to x86, x86 to DEC Alpha, VAX to Alpha RISC, and even
more. Apple have been involved in at least two such models in the past, so
I wouldn't count this out as a strategy.

On Wed, Jun 10, 2020 at 11:32 AM Christophe Meessen <
christophe.mees...@gmail.com> 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 to compile and run my
> go programs on ARM Macs ?
>
> --
> 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 on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f8bd2b7a-99e1-47f1-8cc5-3d37a1aeade5o%40googlegroups.com
> 
> .
>


-- 
J.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUbDPbMz_io9DMTmcxD04axZ6Ap8ff2OANfZPED8YQ3VA%40mail.gmail.com.

[go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Christophe Meessen]

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 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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f8bd2b7a-99e1-47f1-8cc5-3d37a1aeade5o%40googlegroups.com.