[go-nuts] Re: A question about Type Sets

Great to see you playing with generics. I'll leave it up to the experts to reply about whether the compilation problems are bugs. But I have a suggestion: don't try to define Vec in an interface with a type set. Just use T[] -- looks like it might simplify things. Scott On Tuesday, August 2

[go-nuts] GitHub go-formal ownership

Hello Gophers, The go-formal github organisation at http://github.com/go-formal is a GitHub organisation for sharing and coordinating work related to formal logic technologies in and for Go. Effective immediately, Marko Ristin-Kaufmann (marko.ris...@gmail.com) is the new acting steward of go-f

[go-nuts] [ANN] Irifrance R&D open on GitHub

Hello Gophers, For some time, IRI France, SAS operated as a business and in doing so was also able to publish a few cool open source Go R&D projects that have been of some interest and use to others. IRI France, SAS the business is closing, but the github organisation housing the above project

[go-nuts] [ANN] Gini sat solver v1.0

Hello Gophers, I'm happy to announce the Gini SAT solver has finally reached v1.0. http://github.com/irifrance/gini The Gini SAT solver is pretty full-featured for library use, including a simple and efficient logic library and concurrent and distributed utilities. It's also pretty darn fast

[go-nuts] [ANN] Reach -- a symbolic safety model checker

Hello Gophers, I'm happy to announce Reach, a symbolic safety model checker and general symbolic reachability tool for Boolean/binary logic. http://github.com/irifrance/reach This announcement coincides with a dedication of the stewardship of reach to the community. Any and all are so welcome

[go-nuts] Re: the latest "go install"

+1 On Friday, 25 January 2019 08:53:13 UTC+1, Daniel Skinner wrote: > > This will probably sound stupid, but I think it's important; I recently > tried to install a util I had written in Go that depended on a third party > library and the install simply didn't work. Maybe it's a failure of > re

Re: [go-nuts] GitHub go-formal ownership

ny knowledge requirements? >> >> I already develop github.com/Parquery/gocontracts and I am quite >> interested in the topic so I might be a potential candidate. >> >> Cheers Marko >> >> Le mer. 23 janv. 2019 à 10:20, Scott Cotton > > a écrit :

[go-nuts] GitHub go-formal ownership

Hello Gophers, Some time ago, I started the go-formal github organisation as a place for formal analysis tools in and for Go. I am looking for a volunteer to take over ownership of the github organisation go-formal as I will be unable to that role starting in the coming weeks. The administrat

[go-nuts] Re: Defer, clousures and structs

Hi, I think it's pretty clear with 3 rules: 1. Go is call by value, so structs are copied on calls while pointer to structs are not. 2. Methods a.M(x) are just function calls f(a, x). 2. defer foo(bar) will evaluate the expression leading to a function, foo, and the argument bar, in the con

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

On Saturday, 10 November 2018 16:49:40 UTC+1, Fino wrote: > > Flutter comes out, and using Dart... > Flutter looks nice > > Gophers should all working hard, to make Go occupy more domain area, > besides docker, k8s and blockchain. > 100% agreed. > > I think GUI/Game Engine and BigDat

Re: [go-nuts] Re: Go 2 Proposal Comments

On Monday, 29 October 2018 00:25:04 UTC+1, kortschak wrote: > > Prior to about a couple of months ago, it was very rare to see anything > here about exciting additions to the language from aging gophers. I > think it's probably fair to say that many of us were quite happy with > that situation

Re: [go-nuts] Re: Go 2 Proposal Comments

On Sunday, 28 October 2018 15:31:54 UTC+1, Robert Engels wrote: > > To clarify, think of the performance improvements in the GC in Go from 1.1 > to 1.11. Amazing. But you only get these via recompiling which is a > barrier. Many java installations frequently get performance improvements > with

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Hi Marvin, I think a lot of us like the fact that when we see "a == b" in Go we know what it is without looking up a redefinition somewhere. To me, "a (==) b" is better if there is operator overloading, but I don't like it in any case. One problem with operator overloading is that, to use opera

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Thursday, 18 October 2018 08:00:56 UTC+2, Beoran wrote: > > After reading his proposal, I think you should help Burak Sedar work out > his proposal in the other thread. > Where is Burak Sedar's proposal? > It is conceptually a lot easier than the idea of contracts, but likely to > be

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

On Sunday, 28 October 2018 05:13:15 UTC+1, Lucio wrote: > > On Sunday, 28 October 2018 01:58:56 UTC+2, Scott Cotton wrote: >> >> >> [ ... ] >> Then a cross platform App would just implement for each platform. That >> would be more work for app writers

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

On Saturday, 27 October 2018 23:31:11 UTC+2, Ian Lance Taylor wrote: > > On Sat, Oct 27, 2018 at 7:02 AM, Space A. > wrote: > > > > I wish go2 team would focus on cross-platform GUI rather than > nobody-needed > > generics after all. There is nothing you can do atm, write your own > library

Re: [go-nuts] Q16.16 fixed point numbers in go

On Wednesday, 24 October 2018 18:52:27 UTC+2, Michael Jones wrote: > > https://en.wikipedia.org/wiki/Q_(number_format) says it all. > > you can use fixed point all the way...just shift after multiplies and > before divides and use double-width (int32) or wider math. > > Yes, that's close enough

Re: [go-nuts] Re: do you use binary-only packages?

On Monday, 22 October 2018 07:17:57 UTC+2, Ian Lance Taylor wrote: > > On Sat, Oct 20, 2018 at 1:26 PM, jclc via golang-nuts > > wrote: > > > > Currently I don't use them, but couldn't binary packages be used to > > distribute CGO-dependent packages for developers who might not have a C > >

Re: [go-nuts] Python heapq.merge in golang using channels?

Yes Robert's observation that you need all values to merge sorted data, and that channels don't provide this. However, if the implementation receives on channels ahead of time, then this isn't a problem because you do have one value from each source to decide how to proceed. On Sunday, 21 Oc

Re: [go-nuts] Re: do you use binary-only packages?

Hi dharani, I don't think the bigger questions about end products or services are so much implied by the question. BOPs are just one form of binary that have some problems for users and maintainenance, and there are workarounds to supplying a package with binary dependencies that don't suffe

Re: [go-nuts] Go language should become an ANSI and ISO standard.

I think standards have a tendency to end up failing to be standard because of a plethora of standards, the need to make optional parts which render the standard impractical for basic tasks (eg open al), the fact that large market interests tend to have their own version (eg open SL ES android),

Re: [go-nuts] go:nosplit

On Mon, 8 Oct 2018 at 16:30, Ian Lance Taylor wrote: > On Mon, Oct 8, 2018 at 4:50 AM, Scott Cotton wrote: > Your real concern > has to do with running audio code without interruption. That concern, > too, is abstract. We don't know how well it works today and we don

Re: [go-nuts] go:nosplit

Oct 8, 2018 at 1:50 PM Scott Cotton > wrote: > > > However, I wanted to state that if the language doesn't specify this, > and the language also doesn't specify what sys-calls are used on what > platforms in what circumstances, then one can readily conclude that any G

Re: [go-nuts] go:nosplit

On Monday, 8 October 2018 06:02:13 UTC+2, Ian Lance Taylor wrote: > > On Fri, Oct 5, 2018 at 11:57 PM, Scott Cotton > wrote: > > > > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor > wrote: > >> > >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cott

Re: [go-nuts] go:nosplit

On Sat, 6 Oct 2018 at 08:57, Scott Cotton wrote: > > > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote: > >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton wrote: >> > > >> In fact >> we definitely do want to add other preemption checks that oc

Re: [go-nuts] go:nosplit

On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote: > On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton wrote: > > In fact > we definitely do want to add other preemption checks that occur at > points other than function entry (issues #10958, #24543). And if > there is anothe

Re: [go-nuts] go:nosplit

On Sat, 6 Oct 2018 at 02:10, Ian Lance Taylor wrote: > On Fri, Oct 5, 2018 at 3:21 PM, Scott Cotton wrote: > > > > On Fri, 5 Oct 2018 at 23:46, Scott Cotton wrote: > >> > >> Thanks much for the info. > >> > >> Do you have any more pointers abo

Re: [go-nuts] go:nosplit

On Fri, 5 Oct 2018 at 23:46, Scott Cotton wrote: > Thanks much for the info. > > Do you have any more pointers about how one may assess whether or ensure > that a stack overflow check > is not necessary in order to safely use this directive? > Perhaps the compiler automaticall

Re: [go-nuts] go:nosplit

Thanks much for the info. Do you have any more pointers about how one may assess whether or ensure that a stack overflow check is not necessary in order to safely use this directive? Scott On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote: > On Fri, Oct 5, 2018 at 2:10 PM, Scott Cot

[go-nuts] go:nosplit

Hi all, I have for the longest time thought of "go:nosplit" as a runtime-specific thing which wasn't available to arbitrary package authors. Then, I found this from "go doc compile" ``` //go:nosplit The //go:nosplit directive specifies that the next function declared in the file must not inc

Re: [go-nuts] deadlock "runtime.(*sigctx).preparePanic"

gets back to > the go side and this is the most difficult part - not knowing what the > panic actually is. > > My current "workaround" is to timeout the cgo call in my code but I'm > obviously leaking goroutines. > > - Paul > > On Wednesday, October 3,

Re: [go-nuts] deadlock "runtime.(*sigctx).preparePanic"

in alpha, though, and if you try it you will likely need the latest PR which isn't yet merged. Scott On Wednesday, 3 October 2018 10:07:22 UTC+2, Scott Cotton wrote: > > don't know if it's related, but maybe adding below to your callback (from > portaudio callback) will

Re: [go-nuts] deadlock "runtime.(*sigctx).preparePanic"

don't know if it's related, but maybe adding below to your callback (from portaudio callback) will shed some light on your problem defer func() { // Don't let PortAudio silently swallow panics. if x := recover(); x != nil { buf := make([]byte, 1<<10) for runtime.Stack(buf, true) == len(buf) {

Re: [go-nuts] Re: How to setup your development environment using Go modules

Hi all, wanted to follow up to @thepudds summary below. I work with multiple modules. For me, I have found the following helpful 1. keeping dependencies acyclic 2. organising the granularity of what is the smallest module to be as coarse as possible, so there aren't too many modules and rel

Re: [go-nuts] cgo use question

topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Scott Cotton http://www.iri-labs.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. T

Re: [go-nuts] cgo use question

topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Scott Cotton http://www.iri-labs.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe fr

Re: [go-nuts] Constraints for generics

ea of specifying relations over types by example compelling in general and for Go in particular. Still working on (better) unifying the relation of contracts to interfaces, but that's in no way a rejection of the basic ideas in the contracts draft proposal. Scott > On Sep 30, 2018, at 10:

Re: [go-nuts] cgo use question

his topic, visit > https://groups.google.com/d/topic/golang-nuts/ruLltGrPWBg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Scott C

Re: [go-nuts] Constraints for generics

On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote: > > The static switch is a big problem. For any complex method you are going > to completely duplicate all of the code. Not good. > > Far better to map operators to interfaces then you only need a single > method implementation.

Re: [go-nuts] cgo use question

nday, 30 September 2018 14:20:41 UTC+2, Scott Cotton wrote: > > Hi all, > > For info, short of a solution for linking cgo specific C functions cross > package, I think one can do this with C function pointers, which at least > is a close approximation of directly calls. > >

Re: [go-nuts] cgo use question

Hi all, For info, short of a solution for linking cgo specific C functions cross package, I think one can do this with C function pointers, which at least is a close approximation of directly calls. Best, Scott On Sunday, 30 September 2018 14:08:28 UTC+2, Scott Cotton wrote: > >

Re: [go-nuts] cgo use question

e. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Scott Cotton http://www.iri-labs.com -- You received this message because you are subscribed to the Goo

[go-nuts] cgo use question

Howdy Gophers, I've a got cgo question. Suppose I want to use cgo in 2 packages and have one C function used in C code in both packages. Is there a way to do this with the go tool only? I am trying to avoid a build that needs make or the like to build a c library, or copying and renaming the

Re: [go-nuts] go mod tidy pulls in too much

;sntz=1&usg=AFQjCNF6hRXvDGfAJDpqZUX63pGCvsvm3A> Best, Scott On Saturday, 29 September 2018 15:53:53 UTC+2, Scott Cotton wrote: > > Hi all, > > I think this is related to https://github.com/golang/go/issues/26913 > which is closed but still has commentary that seems unresolved after it was > cl

Re: [go-nuts] go mod tidy pulls in too much

Hi all, I think this is related to https://github.com/golang/go/issues/26913 which is closed but still has commentary that seems unresolved after it was closed . Scott On Friday, 28 September 2018 20:11:29 UTC+2, Harmen wrote: > > On Fri, Sep 28, 2018 at 10:19:50AM -0700, thepud...@gmail.com

[go-nuts] Re: proposal: generic generics proposal

On Thursday, 20 September 2018 01:59:27 UTC+2, kortschak wrote: > > It's pretty clear for the flood of emails to golang-nuts and golang-dev > regarding the recent generics/contracts proposal that there are many > ways to implement generics proposals. > > Because of this and risks associated wi

Re: [go-nuts] [ANN] go-formal github organisation

clarify for those without prior exposure to the field. Scott On Thu, 27 Sep 2018 at 11:42, Jan Mercl <0xj...@gmail.com> wrote: > On Thu, Sep 27, 2018 at 11:38 AM Scott Cotton wrote: > > > I've just created a github organisation for formal tools in and for Go. > > Pl

[go-nuts] Re: [ANN] go-formal github organisation

And of course, it's at https://github.com/go-formal On Thursday, 27 September 2018 11:38:08 UTC+2, Scott Cotton wrote: > > Hi all, > > I've just created a github organisation for formal tools in and for Go. > > There's not much there now, but it is open to all t

[go-nuts] [ANN] go-formal github organisation

Hi all, I've just created a github organisation for formal tools in and for Go. There's not much there now, but it is open to all to list and house related repos. Membership is open upon request (for now just send an email to w...@iri-labs.com), we ask only that you be an open (not secret) gi

Re: [go-nuts] Re: Using modules with go test ./...

st them on your own blog, or > on Medium, or as a Github Gist (use a .md extension for Markdown), or as a > publicly-readable Google doc, and then link them here." > > In any event, as a member of the community, I would certainly encourage > feedback from other members of

Re: [go-nuts] Re: Using modules with go test ./...

Hi all, I for one would also consider the interface an improvement if as part of making modules work outside of a "main module" included making go test ./... work as before. Perhaps ./... could mean find each top level module in src/ and test. I am not sure what the modules implementors would

[go-nuts] Re: Using modules with go test ./...

I think you need to have a main module defined so there must be a go.mod in cwd or upwards in the directory tree, perhaps also with related .go files (not sure). There are some issues such as this one where usage is confusing due to a lack of a main

[go-nuts] go mobile android release?

Howdy Gophers, Noob question for go mobile. I was wondering if anyone knows a good way to conditionally compile for native android apps based on the android version? (build tag android is too general for something I'm working on as is the the range of supported versions in gomobile build).

Re: [go-nuts] Runtime threads/OS thread scheduling

‘audio thread/routine after call runtime,LockOSthread() - nice ! > > > On Sep 17, 2018, at 1:36 PM, Ian Lance Taylor wrote: > > > > On Mon, Sep 17, 2018 at 10:39 AM, Scott Cotton wrote: > >> > >> Wanted to ask about the Go runtime use of threads. Specifical

[go-nuts] Runtime threads/OS thread scheduling

Hi all, Wanted to ask about the Go runtime use of threads. Specifically, suppose I've got an app in mind that would run OS-priveleged and use specially scheduled threads, like SCHED_RR in linux for example. One could do this with chrt or calling from a process/thread at the desired scheduling

Re: [go-nuts] modules and package cyclic dips

Hi all, I just ran a test and answered my own question: It does not consider a "prerelease" a "release", so get get -u doesn't update to prereleases. In case it helps anyone, this distinction of terminology was unclear to me in the move to support prereleases. Apparently, a prerelease is not a

Re: [go-nuts] modules and package cyclic dips

or example: > > https://tip.golang.org/cmd/go/#hdr-Module_queries > https://tip.golang.org/cmd/go/#hdr-Pseudo_versions > https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get > > --thepudds > > On Sunday, September 16, 2018 at 10:31:43 AM UTC-4, Scott Cotton wrote: &g

Re: [go-nuts] modules and package cyclic dips

r if you have both >> 'require foo v1.1.1' and a 'require foo v1.2.2'. >> >> In any event, this is all still fairly new, and everyone is still >> learning about the overall system. (The broader community is of course >> learning about

Re: [go-nuts] modules and package cyclic dips

lar module are added to the list, > then at the end only the latest version (according to semantic version > ordering) is kept for use in the build." > > > --thepudds > > On Saturday, September 15, 2018 at 6:34:55 AM UTC-4, Scott Cotton wrote:

Re: [go-nuts] modules and package cyclic dips

B v1.3. > > On Mon, Sep 10, 2018 at 1:28 AM Scott Cotton > wrote: > >> Well, ok. >> >> Did you mean if A v1.12 of a module depends on v1.3 of B which depends on >> v1.11 of A? >> >> So go modules don't actually necessarily depend on the listed

Re: [go-nuts] modules and package cyclic dips

simple solution: don't use cycles between module dependencies (eg go.mod requirements). I'm afraid however that this leaves me in a relatively uninformed state to inform a discussion about cycles in "how the system works" in much more detail. Best, Scott On Mond

Re: [go-nuts] Modules + go get

Yes I think defaulting to go get -u without modules is best too. Because modules allow version compatibility, and so code intended for use with modules may not work at the repo HEAD, asking go get to fetch without building may be more reliable. Best, Scott On Monday, 10 September 2018 11:00:47

Re: [go-nuts] modules and package cyclic dips

ds on v1.3 of module B, which in turn depends on v1.12 of > module A, then the build will choose A v1.12. The is only one version of A > in the build. > > On Sun, Sep 9, 2018 at 1:40 PM Scott Cotton wrote: > >> Hi Sameer, >> >> Thanks for asking, here are some tho

Re: [go-nuts] modules and package cyclic dips

ersion itself, and successive versions > are backwards compatible, why is it not OK for the current version to > satisfy that dependency? > > On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton wrote: > >> Hi Sameer, >> >> When I had a module self-dependency, I considere

Re: [go-nuts] modules and package cyclic dips

y on itself with min version 0.11, then 0.12 > satisfies that dependency (as long as it's following the import > compatibility rule, which isn't necessarily expected for pre-1.0 modules). > > On Sun, Sep 9, 2018 at 9:10 AM Scott Cotton wrote: > >> Hi Sameer,

Re: [go-nuts] modules and package cyclic dips

> > or worrying about chains of cyclic dependencies going back in time > indefinitely. > > As would I, but I think in some situations these cycles are > unavoidable, assuming you can't collapse the two modules down into one > (and in the GopherJS we can't). > You cou

Re: [go-nuts] modules and package cyclic dips

ion in > this situation) and compatibility within that major version, > everything works out, even when running go test all from either of the > modules involved in the cycle. > > I found this easiest to reason about by looking at the process > involved with _introducing_ the submodul

Re: [go-nuts] modules and package cyclic dips

assume the module > requirement graph is acyclic." > On Sun, Sep 9, 2018 at 7:58 AM Scott Cotton wrote: > >> Hi Paul, >> >> On 9 September 2018 at 13:44, Paul Jolly wrote: >> >>> Hi Scott, >>> >>> > Should cyclic module depende

Re: [go-nuts] modules and package cyclic dips

to rebuild go.mod at an untagged HEAD (I think) that was a few commits ahead of say v0.1.2. Then go.mod had that my module required v0.1.1 of itself in go.mod "indirectly". All I could figure out was that the module dependency cycle A -> B -> A had B depending on an older version of

[go-nuts] modules and package cyclic dips

Hi all, I am wondering about cyclic dependencies w.r.t. modules. I haven't been able to find anything related, but also haven't verified all the possible related discussion venues, which would take a while. Let me start out with an observation: Suppose module A has packages A A/x modu

[go-nuts] Re: Announcing gophersat, a SAT and Pseudo-Boolean solver, v1.0.0

Hi, Gini was benchmarked on a reasonably sized set of randomly selected sat competition problems against minisat and picosat. It did very well, before there was even gophersat. SAT competition problems are much harder than many application use case problems because they are of interest as a

[go-nuts] generic proposal timeline for next iteration

Hi all, I am interested in potentially putting some time into reviewing and possibly writing up the results of reviewing the generics proposal. As I'm quite stretched for time to do this, it would help me plan if the go team could say anything about timelines for the next round or rounds of such

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

ypes >> could be partially unified, and contracts significantly simplified, >> which I think is quite pertinent to the above discussion. >> >> Doc here: >> >> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69 >> >> >> >> On

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote: > > I don't understand what you are trying to say. You assert that there > wouldn't be a type-error, but you don't actually justify that. > There are 2 examples, both are (to me) intuitive suggestions and not the result of a phd

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

On Saturday, 1 September 2018 19:26:00 UTC+2, Scott Cotton wrote: > > > > On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote: >> >> On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton wrote: >> >>> My intuition is that interfaces would be obsole

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote: > > On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton > wrote: > >> My intuition is that interfaces would be obsolete -- and that's a very >> good thing. >> > > They wouldn't. You can&

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

I think the draft is a very good start. In fact, there are many times when I find myself wondering whether to use interfaces when something like a contract in that draft is a more natural fit. I would encourage the authors to consider that math std lib package for float32 as a test case that w

Fwd: [go-nuts] Re: [ANNOUNCE] for gopher audiophiles.

Oops, I forgot to CC golang-nuts.. -- Forwarded message -- From: Scott Cotton Date: 8 August 2018 at 21:48 Subject: Re: [go-nuts] Re: [ANNOUNCE] for gopher audiophiles. To: Zellyn Zellyn, We are collaborating with the go-audio github organisation. They have lots to offer

Re: [go-nuts] Re: [ANNOUNCE] for gopher audiophiles.

rious interested parties, and reach a consensus that is >> both efficient and Go-like. >> >> Good luck! I look forward to reading updates on the project blog. >> >> Zellyn >> >> >> On Tuesday, August 7, 2018 at 11:33:48 PM UTC-4, Scott Cotton wrote: >&

[go-nuts] Re: [ANNOUNCE] for gopher audiophiles.

rocessing (for machine learning) will your toolkit aim to > provide similar functionality but in native go? > > On Wednesday, 8 August 2018 04:33:48 UTC+1, Scott Cotton wrote: >> >> Hello all, >> >> I am pleased to announce a new project dedicated to renderi

[go-nuts] [ANNOUNCE] for gopher audiophiles.

Hello all, I am pleased to announce a new project dedicated to rendering "awesome" sound processing and i/o in Go, ZikiChombo , The project is in alpha, and this announcement is mostly geared toward people potentially interested in helping. (you may want to check out t

Re: [go-nuts] stdatomic.h, cgo, and sync/atomic

stency (acquire and release) between the goroutine and the thread? Or is the fact that the go scheduler may put the goroutine on different threads over time going to pose a risk, thus (cringe) inviting a fix with runtime.LockOSThread()? Hmm this is getting complicated... Scott On 1 August 2018 a

Re: [go-nuts] stdatomic.h, cgo, and sync/atomic

Thanks for clarifying On 1 August 2018 at 18:47, Ian Lance Taylor wrote: > On Wed, Aug 1, 2018 at 8:21 AM, Scott Cotton wrote: > > Thanks Ian, > > > > Nice article on volatile, even though I wasn't at all thinking of > promoting > > "volatile" a

Re: [go-nuts] Re: formal verification in Go? someday perhaps?

A late followup, shameless plug https://github.com/irifrance/gini Best, Scott Le mardi 28 juin 2016 09:49:21 UTC+2, Sebastien Binet a écrit : > > > > On Tue, Jun 28, 2016 at 12:24 AM, Daniel Skinner > wrote: > >> > I think a better question is: can go tools for formal verification >> become a

Re: [go-nuts] A few go 2 suggestions

to identiy goroutines to implement this, as far as I know. Best Scott Le mercredi 11 octobre 2017 01:15:48 UTC+2, kortschak a écrit : > > On Tue, 2017-10-10 at 06:13 -0700, Scott Cotton wrote: > > 1. "defer go" extend defers to work on goroutine exit with > > mechanis

[go-nuts] A few go 2 suggestions

Hi all, Been thinking about go 2 ideas, and I wanted to put forth some motivated but rough ideas. Here she goes: 1. "defer go" extend defers to work on goroutine exit with mechanism just like defer, but if we say "defer go f()" instead of "defer f()" then we run on goroutine exit. Very big

[go-nuts] Re: Go 1.7 is released

Hello all, Great work go team, thanks! We got a speedup with 1.7 v 1.6 using the SSA backend Scott Le mardi 16 août 2016 01:28:23 UTC+2, Chris Broadfoot a écrit : > > Hello gophers, > > We just released Go 1.7. > > You can read the announcement blog post here: > https://blog.golang.org/go1.7

[go-nuts] Re: ANNOUNCE: gini

CI > (it is free for open source projects). Automatically testing and linting > has its perks. You could use https://github.com/alecthomas/gometalinter > or have a look at one of my projects on how to integrate them plus TravisCI. > > On Monday, July 25, 2016 at 12:50:37 AM UTC+2, Scott Co

[go-nuts] Re: ANNOUNCE: gini

0 Jul 2016, 2:22 AM Scott Cotton wrote: > >> Thanks. >> >> Out of curiosity, are you using sat solvers in visual effects pipelines? >> > > I was using it for a new version of the package dependency resolver > component of our environment management system. >

[go-nuts] Re: ANNOUNCE: gini

ndency right in. > Cool to see a pure Go solution. > > Justin > > On Sunday, July 24, 2016 at 9:33:31 AM UTC+12, Scott Cotton wrote: >> >> I'm happy to announce the first public beta release of mini, available at >> github <http://github.com/IRIFrance/g

[go-nuts] Re: ANNOUNCE: gini

ance in the long term, we plan to have >> gini compete in sat races and sat competitions annually. To this end, we >> are happy to collaborate with gophers, the curious, raw speed junkies, >> algorithm officianados, and logicians alike. >> >> Cheers, >> &

[go-nuts] Re: ANNOUNCE: gini

es. Also, please make the whole > project go-getable. > > Looking forward to see where this project is going, exciting! Can you link > to the papers where you demonstrate that you outperform picosat and minisat? > > On Saturday, July 23, 2016 at 11:33:31 PM UTC+2, Scott Cotton

[go-nuts] ANNOUNCE: gini

tition. To maintain performance in the long term, we plan to have gini compete in sat races and sat competitions annually. To this end, we are happy to collaborate with gophers, the curious, raw speed junkies, algorithm officianados, and logicians alike. Cheers, -- Scott Cotton President, IRI

Re: [go-nuts] scheduling non determinism

Hi Ian, 2016-07-18 0:33 GMT+02:00 Ian Lance Taylor : > On Sun, Jul 17, 2016 at 9:25 AM, Scott Cotton wrote: > > > > I'm well aware of the benefits of non-deterministic select for many use > > cases, I don't contest that at all or the decision to have it part of

Re: [go-nuts] scheduling non determinism

dez-vous points, using WaitGroups as Egon suggested. > - Not use select{}, unless it is reliably proven that the choice order has > no side effects. > - other? > > It's an open question for me, please share your ideas! > Cheers > Val > > On Sunday, July 17, 2016 at 6:2

Re: [go-nuts] scheduling non determinism

:00 Jesper Louis Andersen < jesper.louis.ander...@gmail.com>: > > On Sun, Jul 17, 2016 at 6:05 PM, Scott Cotton wrote: > >> I'm looking for information/pointers for making the scheduling and >> select {} choices determinisable for an application domain in which >> non-determinis

[go-nuts] scheduling non determinism

set a random seed via an environmental variable. If there is shared interest in this endeavour, please chime in. If any gc officianados could comment about how to go about this (on technical grounds, not contribution IP requirements), it would be appreciated. Thanks, -- Scott Cotton http://ww

Re: [go-nuts] Re: formal verification in Go? someday perhaps?

; http://blog.adacore.com/testing-static-formal. Basically, showing how >>>>> you can do formal verifications in ADA2012. Is it realistic to think that >>>>> a >>>>> feature like that would someday arrive to Go? >>>> >>>> -- >>

Re: [go-nuts] Re: formal verification in Go? someday perhaps?

feature like that would someday arrive to Go? >> >> -- >> 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