Thanks, Dan. Those seem like well-reasoned points.
On Mon, Nov 2, 2020 at 9:33 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> There are two parts. The worse part is the negative conditional
> (unless), which has the problem that humans are bad at negations;
> nearly
Hello Kurtis,
I am thinking about that, but wanted to ask on this list first.
Thanks for your reply.
Patrick
>
>
--
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
There are two parts. The worse part is the negative conditional
(unless), which has the problem that humans are bad at negations;
nearly always when there is a complex condition with an "unless", it
needs to be mentally refactored into an "if !" (when working through
other people's bugs, I
On Mon, Nov 2, 2020 at 8:52 PM Patrick wrote:
> there is the bidi package under golang.org/x/text/unicode/bidi which
> works fine but has no implemented API.
>
> I am currently implementing the API for my own project and I'd like to ask
> why the API is unimplemented, if somebody else is working
I don't think I'm personally sold on this proposal either, but I'm curious
what bad experiences you've had with post-fix conditionals. I haven't
personally used a language with post-fix conditionals and it sounds like
that might be to my benefit :)
On Mon, Nov 2, 2020 at 9:09 PM 'Dan Kortschak'
My first professional programming language was Perl, decades later I
still wake up in a sweat thinking about post-fix conditionals and the
'unless' conditional.
Please no.
On Mon, 2020-11-02 at 14:26 -0800, Jeffrey Paul wrote:
> Hello Gophers,
>
> There's two tiny pieces of syntactic sugar I
Hello all,
there is the bidi package under golang.org/x/text/unicode/bidi which works
fine but has no implemented API.
I am currently implementing the API for my own project and I'd like to ask
why the API is unimplemented, if somebody else is working on implementing
the API and if not,
Hello Gophers,
There's two tiny pieces of syntactic sugar I really miss from a few other
languages that I think would add a nice bit of ergonomics and convenience to Go
(which I now play as my main) without increasing any magic or spooky action at
a distance.
They are:
- postfix conditionals
I'd also assume that `GOMAXPROCS=1` doesn't disable the preemptive
scheduling of goroutines in recent Go versions - I believe
`GODEBUG=asyncpreemptoff=1` is required for that.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
Hi,
another thing to keep in mind is that `GOMAXPROCS=1` does not actually make
your program single-threaded:
The GOMAXPROCS variable limits the number of operating system threads that
> can execute user-level Go code simultaneously. There is no limit to the
> number of threads that can be
On Sun, Nov 1, 2020 at 9:15 PM Ting Yuan wrote:
> I find it is tricky to debug a concurrency Go program in multi-core
> systems, so I wonder if there is a way to make the program run in
> deterministically. Can I assume a program with GOMAXPROCS(1) can be
> deterministically
> executed ?
>
In
Not really.
I'll just rewrite them in go if there isn't a tool I need, or it the
interface is crappy. I have built a few databases from scratch, so writing
simple tools is trivial.
On Mon, 2 Nov 2020, 5:25 pm Tyler Compton, wrote:
> I saw yq but it seemed like it was written in python, which
>
> I saw yq but it seemed like it was written in python, which I have no time
> for.
>
You're going to be limiting your tooling options quite a bit in that case
:)
On Mon, Nov 2, 2020 at 8:49 AM alex breadman wrote:
> Thanks for the reply.
>
> I just did it for fun actually, and for the
Thanks for the reply.
I just did it for fun actually, and for the purpose of learning to make
GitHub actions.
I saw yq but it seemed like it was written in python, which I have no time
for.
The dasel one looks the best imo.
On Mon, 2 Nov 2020, 4:41 pm Howard C. Shaw III,
wrote:
> If
If written because you needed experience and writing a program to perform a
task you need done is better for learning, then go you! But if you are
legitimately looking to solve a problem, you might want to throw a quick
search out first before implementing Yet Another X.
For yamlfukr update
On Mon, Nov 2, 2020 at 12:30 PM irvan hendrik wrote:
> yes. because when I marshal it to json the number got messed up.
> when I entered value 10.0 it became 10.
> If I use json.number it keeps the format 10.0.
Sounds like conflating data and their representation. I'm not a json
expert, but
yes. because when I marshal it to json the number got messed up.
when I entered value 10.0 it became 10.
If I use json.number it keeps the format 10.0.
Regards.
On Mon, Nov 2, 2020 at 2:46 PM Brian Candler wrote:
> Is there a particular reason why you don't just do this?
>
> type Product
Hi,
Can someone tell me why does OpStoreReg of type int16, int32, etc. occupy 8
bytes on the stack? And where is this handled ? 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
Thanks. I ended up simplifying the test and remove the dependency on
external packages.
On Sunday, November 1, 2020 at 11:42:43 PM UTC+2 kortschak wrote:
> Ah, it just clicked.
>
> You're indirectly using go/packages, which will (unless configured not
> to), cause changes to the go.mod and
19 matches
Mail list logo
