to get the output to be:
foo
hello
bar
world
Any ideas?
Thanks,
Scott
--
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
A quick aside regarding the code that you posted. Postgres (bizarrely,
IMHO) stores longitude first, then latitude, so:
return fmt.Sprintf("POINT(%v %v)", p.Lat, p.Lng)
should be:
return fmt.Sprintf("POINT(%v %v)", p.Lng, p.Lat)
Thanks for sharing your code!
On Tuesday, February 18, 2014 a
You're loading in an RSA key but signing with HS512, try changing:
signMethod := jws.GetSigningMethod("HS512")
to
signMethod := jws.GetSigningMethod("RS256")
On Monday, June 20, 2016 at 10:14:10 PM UTC-4, macmilla...@gmail.com wrote:
>
> I get this error 'Error serializing the key. json: er
ts to be passed to the function, it is
> best to redesign it and use a data structure that encapsulates the
> arguments. Otherwise, what is wrong with this?
>
>
> // Great is a really great function anArg does this and anotherArg does
> that.
> func Great(anArg int, anotherAr
Ian's and Lutz's responses get to the heart of how comments on parameters
are different from comments on struct field, constant and variable
initializations, namely that the documentation framework (whether in an IDE
or via godoc) elevates comments on functions to a different status than
"inter
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 for
n Go one would more naturally write
for _, e := range s {
fmt.Print(e + 1)
}
— Scott
--
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+unsu
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
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
ant to check out the launch blog post
<http://zikichombo.org/blog/launch> for a more personal introduction).
Best,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails f
sox, at the level of say Web
Audio or Apple Audio Units. We think
Go can simplify things a lot in this space.
Scott
On Wednesday, 8 August 2018 08:37:48 UTC+2, Jimmy Tang wrote:
>
> this looks interesting, I've been using various go sox bindings for doing
> various sound p
at doing MDCT, and it would be nice if go-num had
that. In the meantime I think the audio-specific parts of zikichombo's fft
justify it living apart.
Scott
On 8 August 2018 at 20:36, Sebastien Binet wrote:
> Scott,
>
> One thing that wasn't completely clear to me in the
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
our head around and reasonably powerful but require less
code/effort than actually rolling your own. For Go, I've used pigeon
<https://github.com/mna/pigeon> for a few projects (e.g., edif2qmasm
<https://github.com/lanl/edif2qmasm>, for which a PEG parser is probably
overki
nd
hearty "go for it" for compiler writers to make it fast :)
Nice work on the proposal.
Scott
On Friday, 31 August 2018 18:47:45 UTC+2, Daniela Petruzalek wrote:
>
> I agree with Tristan in regards to orthogonality.
>
> Seeing the draft with all those complexities added
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&
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
apable of thinking this idea through and
making it as solid as the proposal overnight. Just expressing the opinion
that unifying the concepts of contract and interface seems to me like a
good idea to explore, and that a priori assuming they are different doesn't
help advance exploring it.
Hi all,
I just found out that there is a wiki
<https://github.com/golang/go/wiki/Go2GenericsFeedback> for this kind of
discussion, looks to me like a better venue, more organised, more
interest,
and just recently proposed on golang.org.
Scott
On Sunday, 2 September 2018 10:09:43
such feedback. For example, is there is a plan to revise the draft
proposal based on feedback for 1.12? Is there some tentative goal to have
a working prototype by some specific version?
Best,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-n
o overhead w.r.t. solving problems without cardinality
constraints. Handling cardinality constraints is also difficult to
predict; I recommend ignoring all expert opinions about who is better and
simply benchmark).
Scott
On Friday, 22 December 2017 02:25:53 UTC+1, Fabien wrote:
>
> Shor
ier version
of itself? (I saw this once...)
Any ideas out there?
Best,
Scott
--
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...@g
Hi Paul,
On 9 September 2018 at 13:44, Paul Jolly wrote:
> Hi Scott,
>
> > Should cyclic module dependencies be allowed?
>
> Yes, indeed in some situations they are totally necessary.
>
> I wrote up an experience report on this very topic:
> htt
dule
dependency graph after
a decade of development, in particular if a module can depend on an earlier
version of itself.
Scott
On 9 September 2018 at 14:19, Sameer Ajmani wrote:
> Are you seeing errors when there are cyclic module dependencies? As I
> recall, cyclic dependencies
ing time coding than figuring
out
or worrying about chains of cyclic dependencies going back in time
indefinitely.
Scott
On 9 September 2018 at 14:55, Paul Jolly wrote:
> > Interesting. I'm not sure what cyclic module dependencies means. I do
> know some package managers
Hi Paul,
On 9 September 2018 at 16:26, Paul Jolly wrote:
> Hi Scott,
>
> > Yes I see that in terms of compatibility it "all works out", but it seems
> > underspecified what should happen.
>
> Which bit do you think is underspecified?
>
Perhaps how to ensure
matic as backward in time self dependencies.
Scott
On 9 September 2018 at 18:38, Sameer Ajmani wrote:
> With respect to errors, I'm asking how things failed when you had a cyclic
> module dependency. My expectation is that this should just work. If your
> module 0.12 has a dependenc
n the
modules
specification or vision, and maybe, (even hopefully) I am wrong about these
concerns.
I could list more related ideas, but given that I might be wrong I'll leave
it at that.
Thanks,
Scott
On 9 September 2018 at 19:19, Sameer Ajmani wrote:
> If a module depends on an earlier v
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 dependencies?
That is quite counteruintintive to me.
It is much simpler in any case to use acyclic dependencies.
Scott
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
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
heck/handle
while still retaining the key benefits of that approach. See what you
think.
— Scott
--
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 em
(lambda (Top)
(lambda ()
(Top '())
(Uncomment the printf to see the double execution. Weird, huh?)
Thanks for the challenge,
— Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
rvativism causing headaches for real code, only for
contrived examples.
If it's really not possible to make compile-time detection work, I'd say
that the returnfrom in f should exit the goroutine but not return its
argument from g. This is consistent with the case of returning from a
con
n it seems to me that
is not the intended use case for cycles and that might be undesirable or
even lead to the inability of a module maintainer in the cycle
to effectively propagate an update.
If I come across anything more concrete, I'll file an issue. Just food for
thought at this poi
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:
find the idea useful and would like to use pre-release info
with modules.
So can anyone comment, inform, or provide a pointer to some documentation
about pre-releases as they relate to modules?
Best,
Scott
On 15 September 2018 at 22:11, Sameer Ajmani wrote:
> Thanks. The relationship
it? (I would think not,
but reading the docs I would think it would update to the alpha)
Scott
On 16 September 2018 at 16:44, wrote:
> Hi Scott,
>
> Modules do provide support for semver pre-release notation. You can read
> more about it in these sections of the documentation, f
ntly, a prerelease is not a kind of release in
the docs on tip.golang.org.
Best,
Scott
--
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+uns
sired
scheduling priority/type (as pointed out on a related thread in golang-dev)
The question is: does this as of go1.11 interfere with Go runtime internal
prioritising of threads?
The other question is: may it one day interfere with Go runtime internal
prioritising of threads?
Best,
Scott
--
Thanks all,
Indeed useful.
Will continue exploring the "it's hard to say" part on golang-dev, as that
might be useful as well.
Best,
Scott
On 17 September 2018 at 20:43, robert engels wrote:
> Then it should be fairly trivial to call cgo to raise the priority of the
>
build).
Best,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
a main module. They are marked needs fix and go1.1.2. I think
your use case is related. I haven't had a problem with that one because I
just set up my workflow to run tests where there are go.mod files.
Best,
Scott
On Thursday, 20 September 2018 21:21:32 UTC+2, John wrote:
>
> Jus
flexibility in implementing
the statement above from golang.org
might allow a more informed basis on which to take modules out of
preliminary status. But others
may depend on or like modules behaviour like this. I have no way of
knowing.
Also, yes I agree the listing of the deleted go.mod
Hi @thepudds,
Good to hear and glad to have followed up so as to have introduced in the
conversation how to address the concern in that post.
Thanks for the great summary of how to give effective feedback about about
modules and the general context.
Best,
Scott
On Saturday, 22 September
not secret) github member.
Best,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more
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
ider type theory formal, as in pure form (like system F,
type systems for ocaml) "formal" as well.
There are also things like proof carrying code which contains a proof that
remote execution is safe in some way.
so what "formal" is not formally defined :)
Hopefully, this will help
taphysics: not as far as I know :)
generic: at least a general way of doing it.
Scott
>
> thanks
> Dan
>
--
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,
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...@gma
;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
g the C functions.
My attempts so far have all yielded link errors. Either the C function is
undefined in one of the two Go packages (at build or runtime, depending on
how I use "extern") or I get multiple symbol definitions.
Scott
--
You received this message because you are su
y, no make, 2 -- cgo C function called by C in more than
one package)?
Scott
On Sun, 30 Sep 2018 at 13:57, Simon Ritchie wrote:
>
> Write a separate package to handle the C stuff and call it from the other two.
>
> I built a wrapper for a c++ library:
> https://github.com/gob
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:
>
>
which means I either need to make a C
library separately or copy+rename or use static functions fC tand have go
get and go modules work.
hmm...
maybe I'll copy the C code and make the functions static file members. If
that's the best solution, it is disappointing :(
Scott
On Su
this later
issue, but it's pretty heady stuff and outside the scope of
what I want to have to think about when coding, so as to focus efforts more
readily on the objective of the code rather than heady type theory.
practical operator overloading isn't a solved problem AFAIK, much
nal C dependency for the purpose of using more
pure Go and less cgo :)
Thanks in any event for your help, it was also informative to me.
Scott
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "golang-nuts" group.
> To unsubscribe from t
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:
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
expectations by the OS of what the call should not
do are such that go's runtime treatment of cgo->go on the foreign thread is
undesirable.
So I need to call C without calling by Go //export in this very particular
case.
Scott
On Mon, 1 Oct 2018 at 10:42, Tamás Gulácsi wrote:
&g
about, no extra tools to
learn.
The disadvantages: probably less flexible. less opportunity to contribute
to shared tooling.
Hope that helps anyone considering workflows with multiple modules
Scott
On Sunday, 9 September 2018 21:19:34 UTC+2, thepud...@gmail.com wrote:
>
> Hi al
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) {
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
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,
the emission/addition of pre-emption instructions
in the function it annotates?
3. Can it be used with gccgo?
Thanks for any info,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receivin
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
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
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
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
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
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
d the runtime doesn't specify what
sys calls it might or might not use.
So it is not really a question of whether you are using the syscall package
correctly or its organisation w.r.t. operating systems.
Scott
On Monday, 8 October 2018 13:54:26 UTC+2, Jan Mercl wrote:
>
> On Mon,
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
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),
don't suffer from these problems in any case (eg
plugins).
Scott
On Friday, 19 October 2018 02:13:01 UTC+2, Tharaneedharan Vilwanathan wrote:
>
> Hi Ian,
>
> Good question. I don't have an answer.
>
> But this raises some questions:
>
> Should Go be anticip
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
publishes a C library and decides to use Go for part of its
implementation should not have to say "we use Go so if you use cgo, then
..."
This combination is perhaps hypothetical at this point for Go, but there
are low level Rust libraries like this where the consumer doesn'
, that's close enough for many purposes. But it gets more complicated
with carries/rounding and other functions (such as trig).
Scott
> On Mon, Oct 22, 2018 at 3:24 PM Vasiliy Tolstov > wrote:
>
>> Thanks for suggestions.
>> If somebody can look at github.com/unis
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
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
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
either use examples or
build on a set of standard supplied contracts by embedding.
Scott
On Wednesday, 17 October 2018 21:57:48 UTC+2, Marvin Renich wrote:
>
> * Ian Lance Taylor > [181016 17:59]:
> > The contract system in the generics design draft does not have this
>
d. For example,
if it were linked while the stack is high/deep, then where would the
runtime put the stack? where would the runtime system stack be placed?
It's very different than applying a runtime to byte code.
Scott
>
>
> Sent from my iPhone
>
> > On Oc
more topic, but it happens. Not sure
myself how or if the question of happiness with or without aging gophers is
relevant.
Scott
>
> On Sun, 2018-10-28 at 07:31 -0500, Robert Engels wrote:
> > Next thing Gophers will be crying for is lambda syntax... just wait.
>
from everything else and I do want Go in general to focus on expanding the
scope of where it excels.
Scott
>
> BR fino
>
>
>> It would be nice if cross-platform GUIs were easier to write, but they
>> are not. The incentives are all wrong. Platform vendors wan
k/
>
Thanks for doing the performance analysis of spakin/awk
<https://github.com/spakin/awk>! Once I find the time to work on that
project some more, I'll certainly look into implementing some of your
suggestions.
— Scott
--
You received this message because you are subscribe
n the context of the
defer statement. it will then apply the function to the previously
evaluated bar upon function exit (or after other defers
if there are any).
Hope that helps
Scott
On Wednesday, 19 December 2018 23:42:01 UTC+1, Victor Giordano wrote:
>
> Perhaps someone could explai
lt;https://github.com/gobuffalo/packr>? Something else?
Thanks,
— Scott
--
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...@googl
Donavan of the golang analysis packages.
2. GopherSat authors.
3. Others who have worked on formal projects in Go but less visibly.
4. go-critic and staticcheck.io authors.
Please do feel free to contact me off-line or here on go-nuts for details.
Best,
Scott
--
You received this message
necessary imply being a formal tech expert. It might even help to not be
an expert so as to avoid bias in inclusion. On the other hand, of course
if someone with impressive credentials put their name on it that would help
too.
Scott
On Wednesday, 23 January 2019 13:59:59 UTC+1, Marko Ristin w
+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 so welcome, inquiries here on go-nuts or
in private reply welcome for github invites.
Best,
Scott
--
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
darn fast for a CDCL solver in
Go, measuring up to standard CDCL C/C++ solvers
in a variety of tests.
This release corresponds with a dedication of the stewardship of Gini to
the community. Please feel free to follow up
here on go-nuts or in private reply about how to gain access.
Best
Scott
open to stewardship by the community.
Best,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more
feel free to contact Marko with contributions and ideas related to
sharing and
coordinating work related to formal logic technologies in and for Go.
Cheers,
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
support
int(bool) conversions in Go.1.5
<https://groups.google.com/forum/#!topic/golang-nuts/wyuBhAb1Rzk/discussion>
).
— Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
nks for reading, I hope this post gets some folks thinking and I also
ask that it not be taken as invitation
for technical debate, as I unfortunately don't have time to engage that.
Best
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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
orkaround for this problem?
>
Yes:
powerseries -nterms=10 -- "-x ^ 10"
The "--" means "end of flag arguments."
— Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
get the
latest commit, whatever its version?
Thanks,
— Scott
--
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...@googlegrou
1 - 100 of 160 matches
Mail list logo
