ok, I'm banning myself from this forum for a while. Sorry about this. I'm
not right at the moment.
On Sunday, 5 May 2019 21:55:57 UTC+2, Louki Sumirniy wrote:
>
> I think the key thing is the Add function I have written is not concurrent
> safe. I didn't intend it to be as I only ha
at to you. Try running the stdlib wait group tests against your code.
> They will fail.
>
> On May 4, 2019, at 4:22 PM, Louki Sumirniy > wrote:
>
> Those who follow some of my posts here might know that I was discussing
> the subject of channels and waitgroups rec
I didn't intend Add to be used concurrently, by the way. One pool one
thread for the controller.
On Sunday, 5 May 2019 21:09:40 UTC+2, Louki Sumirniy wrote:
>
> If at 13 in the else clause, if I first test for a non-nil wg.ops and
> close it if it's open, I think that stops that cha
> on this thing, it's going to fail.
>
> -- Marcin
>
>
> On Sun, May 5, 2019 at 8:33 AM Louki Sumirniy > wrote:
>
>> just had to drop an update, I further improved it, now when it stops it
>> resets itself and you can use Add again, I removed the unnecessary
&g
need to prevent goroutine leaks.
On Sunday, 5 May 2019 17:18:52 UTC+2, Louki Sumirniy wrote:
>
> I figured out that the API of my design had a flaw separating starting the
> goroutine and adding a new item, so as you can see in this code, I have
> merged them and notice that there
and 100 worker routines the lack of
complex extra code makes this a better implementation. Probably the
original is fine for smaller worker pools.
On Sunday, 5 May 2019 13:01:58 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 12:45 PM Louki Sumirniy
> > wrote:
> >
> >
Ahaha! you made a race, actually! I mean I made a race, but that code
exposed it.
I'm gonna just go away for a while. My brain doesn't really seem to be keen
on doing this kind of thinking right at this minute.
On Sunday, 5 May 2019 12:54:25 UTC+2, Louki Sumirniy wrote:
>
> hang on,
you wrote, but the above completes the code and shows the
condition is handled.
On Sunday, 5 May 2019 12:27:10 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
> > wrote:
>
> > Is there ANY other use case for waitgroup other than preventin
ok, you found another flaw :) Not adding is now accounted for but waiting
twice isn't.
On Sunday, 5 May 2019 12:27:10 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
> > wrote:
>
> > Is there ANY other use case for waitgroup other than preventin
wrote:
>
> On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
> > wrote:
>
> > Is there ANY other use case for waitgroup other than preventing a
> goroutine leak or ensuring that it empties the channels at the end of
> execution?
>
> I don't think this question is r
and mine is also incorrect. now it handles your test but not intended
operation. :)
On Sunday, 5 May 2019 12:25:29 UTC+2, Louki Sumirniy wrote:
>
> With your (imho incorrect) code, the following small modification defers
> starting the channel until an add has been called and passes
With your (imho incorrect) code, the following small modification defers
starting the channel until an add has been called and passes the test:
https://play.golang.org/p/sEFcwcPMdHF
On Sunday, 5 May 2019 11:54:40 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 11:46 AM Louki Su
Is there ANY other use case for waitgroup other than preventing a goroutine
leak or ensuring that it empties the channels at the end of execution?
On Sunday, 5 May 2019 11:54:40 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
> > wrote:
>
> >
.
That would mean your code, which breaks this code, also breaks the rule
about never starting a goroutine without having a way to stop it. My code
only fails when the caller is also failing.
On Saturday, 4 May 2019 23:53:03 UTC+2, Jan Mercl wrote:
>
> On Sat, May 4, 2019 at 11:22 PM
Those who follow some of my posts here might know that I was discussing the
subject of channels and waitgroups recently, and I wrote a very slim and
simple waitgroup that works purely with a channel.
Note that it is only one channel it requires, at first I had a ready and
done channel, but
The rename tool is great, but be aware that it doesn't work if the compiler
encounters even one error anywhere in the project. If the code is already
complete and runs fine, rename works just fine, and is more selective than
a blanket S The rename tool parses the code into an AST, so it fully
potentially rtl) would be a lot
easier than the good old days when the compiler only recognised ascii.
On Friday, 3 May 2019 19:30:33 UTC+2, Ian Lance Taylor wrote:
>
> On Fri, May 3, 2019 at 8:25 AM Louki Sumirniy
> > wrote:
> >
> > https://en.wikipedia.org/wiki/Unicode#G
,
because if slice types match this unrolling is implicit, I mean, the
programmer obviously intends the two slices be spliced into one new one...
On Friday, 3 May 2019 19:13:02 UTC+2, Ian Lance Taylor wrote:
>
> On Fri, May 3, 2019 at 7:57 AM Louki Sumirniy
> > wrote:
> >
, 3 May 2019 12:10:32 UTC+2, ohir wrote:
>
> On Thu, 2 May 2019 17:22:15 -0700 (PDT)
> Louki Sumirniy > wrote:
>
> > I'm quite aware of that it's part of the ARP, and allows the router to
>
>https://tools.ietf.org/html/rfc826 [read updates too]
>
> Main so
https://i.postimg.cc/BbQDrTy1/Screenshot-from-2019-05-03-18-06-02-2x.png
I installed a few nicknacks today after reading stuff about BCE and escape
analysis, and made some change to my config and now vscode is showing me
all the bounds checks.
There is a LOTTA bounds checks in the standard
, Jan Mercl wrote:
>
> On Fri, May 3, 2019 at 5:14 PM Louki Sumirniy
> > wrote:
>
> > If the 'letter' classification is the same as used in .NET's unicode
> implementation, this info lists the categories of symbols that unicode
> classifies as letters:
>
> https
ave seen source code from chinese authors that has comments in cn
> traditional. So does this mean, in theory, I can use any valid unicode
> letter from alphabet (or even pictograpic) language scripts??
>
> On Friday, 3 May 2019 16:43:09 UTC+2, Ian Lance Taylor wrote:
>>
>&g
from alphabet (or even pictograpic) language scripts??
On Friday, 3 May 2019 16:43:09 UTC+2, Ian Lance Taylor wrote:
>
> On Fri, May 3, 2019 at 7:28 AM Louki Sumirniy
> > wrote:
> >
> > It would be incredibly computationally costly to add a natural language
>
ing it never matters - I have significant HFT experience and sone
> HPC - but in MOST cases it holds true.
>
> So micro optimizing the CPU usually has little effect on total runtime.
>
> Broken algs, ON^2, are another story.
>
> On May 3, 2019, at 9:38 AM, Louki Sumirniy >
wrote:
>
> On Fri, May 3, 2019 at 7:34 AM Louki Sumirniy
> > wrote:
> >
> > The ellipsis has two uses in Go, one is in variadic parameters, the
> other is in the slice append operator. It is essentially an iterator that
> takes a list and turns it into a slice
Ah, just want to give a big thanks for making this tool, I will be needing
to do a lot of optimisation in a few weeks once I finish all the
implementation and initial debugging. This should help a lot.
On Monday, 22 April 2019 16:20:04 UTC+2, mediam...@gmail.com wrote:
>
> Hello,
>
>
> we have
There is a big difference between the parameters of these two functions.
One is a slice of interface, the other is only a a single string parameter.
fmt print functions all have nasty messy interface switching and reflection
internally hence the significant overhead.
A lot of people clearly
It would be incredibly computationally costly to add a natural language
translator to the compilation process. I'm not sure, but I think also
identifiers in Go can only be plain ASCII, ie pure latin script (and
initial character must be a letter)
These days in most countries where foreign
The ellipsis has two uses in Go, one is in variadic parameters, the other
is in the slice append operator. It is essentially an iterator that takes a
list and turns it into a slice (parameters) or takes a slice and turns it
into a recursive iteration (append). Parameters with the ellipsis are
I'd also go further and point out that the Go language has a somewhat
peculiar and unique feature that code reusability is not considered a holy
grail. If I really needed a library that was written in portuguese, it
would not be hard to figure out how to rename everything for my easier
It looks like it should be an array T to me, then:
var T = [5][256]uint32
On Thursday, 2 May 2019 03:45:07 UTC+2, kortschak wrote:
>
> var T0, T1, T2, T3, T5 [256]uint32
>
> https://play.golang.org/p/6Cm4p_NyD8m
>
> On Wed, 2019-05-01 at 18:40 -0700, lgo...@gmail.com wrote:
> > The following
019 14:09:09 UTC+2, Louki Sumirniy wrote:
>>
>> The function has a very specific purpose that I have encountered in
>> several applications, that being to automatically set the netmask based on
>> the IP being one of the several defined ones, 192, 10, and i forget whic
channel, and the done uses a 'comma ok' check and breaks when that produces
a false value, otherwise it pushes the op back on the channel in case it
was meant for the main loop: https://play.golang.org/p/zuNAJvwRlf-
On Friday, 3 May 2019 02:50:42 UTC+2, Louki Sumirniy wrote:
>
> oh, I did
.
On Friday, 3 May 2019 02:39:09 UTC+2, Louki Sumirniy wrote:
>
> I more or less eventually figured that out since it is impossible to query
> the number of workers without a race anyway, and then I started toying with
> atomic.Value and made that one race as well (obviously the valu
itives under the hood so you are not saving anything
> by using multiple channels instead of a single wait group.
>
> On May 2, 2019, at 5:57 PM, Louki Sumirniy > wrote:
>
> As I mentioned earlier, I wanted to see if I could implement a waitgroup
> with channels instead
outer.
>
> On May 2, 2019, at 7:20 AM, Louki Sumirniy > wrote:
>
> Upon review one thing occurred to me also - Netmasks are specifically a
> fast way to decide at the router which direction a packet should go. The
> interface netmask is part of the IP part of the header and a
As I mentioned earlier, I wanted to see if I could implement a waitgroup
with channels instead of the stdlib's sync.Atomic counters, and using a
special type of concurrent datatype called a PN Converged Replicated
Datatype. Well, I'm not sure if this implementation precisely implements
this
gt; https://play.golang.org/p/-eqKggUEjhQ
>
> On 02/05/2019 21:09, Louki Sumirniy wrote:
>
> I have been spending my time today getting my knowledge of this subject
> adequate enough to use channels for a UDP transport with FEC creating
> sharded pieces of the packets, and I
oup irrelevant.
What I'm curious about is, what reasons would I have for not wanting to use
this feature of closed channels as a stop signal versus using a waitgroup?
On Thursday, 2 May 2019 16:20:26 UTC+2, Louki Sumirniy wrote:
>
> It's not precisely the general functionality that I will implem
is ignored when another
one comes in later. That most closely models what I am building.
On Thursday, 2 May 2019 13:26:47 UTC+2, Louki Sumirniy wrote:
>
> Yeah, I was able to think a bit more about it as I was falling asleep
> later and I realised how I meant it to run. I had
:09 UTC+2, Louki Sumirniy wrote:
>
> The function has a very specific purpose that I have encountered in
> several applications, that being to automatically set the netmask based on
> the IP being one of the several defined ones, 192, 10, and i forget which
> others.
>
>
The function has a very specific purpose that I have encountered in several
applications, that being to automatically set the netmask based on the IP
being one of the several defined ones, 192, 10, and i forget which others.
Incorrect netmask can result in not recognising a LAN address that is
y 2019 10:30:28 UTC+2, Øyvind Teig wrote:
>
> Hi, Louki Sumirniy
>
> This is not really a response to your problem in particular, so it may
> totally miss your target. It's been a while since I did anything in this
> group. However, it's a response to the use of buffered c
I am working on a reliable UDP transport currently, and I am writing it
using exclusively buffered channels.
The way it works is there is three goroutines, one accepts new input,
forwards it to an intermediate 'incoming' worker, who checks if the new
data can be bundled (it is for reed solomon
I just ran into an issue with a closure inside a function that I originally
created elsewhere with the same names as where I transplanted the closure
definition, and it took me quite some time to root out all the references
to the outer scope.
Scope bleed and shadowing with closures is
I have become quite interested in tail-call optimisation and more distantly
in code that assembles trees of closures all tied to the same scope through
parameters to reduce stack management for complex but not always
predictable input.
As I have learned from some reading, tail call
I have been doing a lot of work involving essentially declarative
(nominally) complex data types involving several layers of encapsulation.
I had seen here and there examples of this 'Fluent' method-based pipeline
chaining, with methods passing through receivers to invoke multiple
distinct
;
> https://g.co/kgs/2Q3a5n
>
> On Mar 17, 2019, at 2:36 PM, Louki Sumirniy > wrote:
>
> So I am incorrect that only one goroutine can access a channel at once? I
> don't understand, only one select or receive or send can happen at one
> moment per channel, so that mea
sted is more like a condition variable or monitor
> than it is like a mutex.
>
> Also note that in your second playground post, you're spawning 12
> goroutines, so I'm not sure what "goroutine1" and "goroutine2" are
> supposed to mean.
>
> Kind r
control that only one reader or writer is working at one moment
on two variables. that the race detector is flagging in my code.
On Sunday, 17 March 2019 20:51:33 UTC+1, Jan Mercl wrote:
>
> On Sun, Mar 17, 2019 at 8:36 PM Louki Sumirniy > wrote:
>
> > So I am incorrect that
, Louki Sumirniy wrote:
>
> So I am incorrect that only one goroutine can access a channel at once? I
> don't understand, only one select or receive or send can happen at one
> moment per channel, so that means that if one has started others can't
> start.
>
> I was s
this works as a mutex and only one thread
gets access to the channel per send/receive (one per side).
On Sunday, 17 March 2019 14:55:58 UTC+1, Jan Mercl wrote:
>
> On Sun, Mar 17, 2019 at 1:04 PM Louki Sumirniy > wrote:
>
> > My understanding of channels is they basicall
in parallel, that's the point,
a single element in the channel means only one access at a time and thus it
is a bottleneck that protects from simultaneous read and right by parallel
threads.
On Sunday, 17 March 2019 14:55:58 UTC+1, Jan Mercl wrote:
>
> On Sun, Mar 17, 2019 at 1:04 PM Louki Su
I didn't even think of the idea of using buffered channels, I was trying to
not lean too far in towards that side of thing, but it is good you mention
it, it would be simple to just pre-allocate a buffer and trigger the print
call only when that buffer fills up (say like half a screenful, maybe
I just wrote this a bit over a month ago:
https://git.parallelcoin.io/dev/pod/src/branch/master/pkg/util/cl
It was brutal simple before (only one 600 line source lots of type
switches) but it now also has a registration system for setting up
arbitrary subsystem log levels.
By the way, I could
I didn't mention actually excluding access by passing data through values
either, this was just using a flag to confine accessor code to one thread,
essentially, which has the same result as a mutex as far as its granularity
goes.
On Sunday, 17 March 2019 13:04:26 UTC+1, Louki Sumirniy wrote
at once. If you ask me, that's better
and more logical than callbacks.
On Sunday, 17 March 2019 11:05:35 UTC+1, Jan Mercl wrote:
>
>
> On Sun, Mar 17, 2019 at 10:49 AM Louki Sumirniy > wrote:
>
> > I just ran into my first race condition-related error and it made me
> wo
I am currently dealing with a race related bug, at least, I found a bug,
and it coincided with a race when I enabled the race detector, and the bug
is a deadlock, and the shared shut-down button clearly can be pressed on
and off in the wrong order.
So my first strategy in fixing the bug is
I just ran into my first race condition-related error and it made me wonder
about how one takes advantage of the mutex properties of channels.
If I understand correctly, this is a simple example:
mx := make(chan bool)
// in separate scope, presumably...
go func() {
<-mx
That is a strange setting for GOBIN... Isn't that the folder `go install`
puts binaries? I always set it to ~/bin and put that also in my path. I
like to use `go install` instead of `go build` because then I don't have to
remember not to let it slip through into a commit.
On Sunday, 3 March
The function is really just looking up the IP prefixes of the non-routeable
address ranges. It has nothing to do with CIDR, it is for generating a sane
default mask when the user has not specified the mask.
It most definitely should not be deprecated, as these nonrouteable
addresses are
. sorry for the confusion.
>
> 2019년 3월 2일 토요일 오후 8시 46분 50초 UTC+9, Louki Sumirniy 님의 말:
>>
>> Only an assigment to a pre-declared map[string]interface{} in a loop
>> walking the first layer of that complex map type is required to put the
>> values into that type, it's
It won't flag any error whatsoever, actually, but if you don't free that
allocation correctly it will not be freed until termination.
On Friday, 1 March 2019 06:36:50 UTC+1, Cholerae Hu wrote:
>
> Consider the following code:
> ```
> package main
>
> /*
> struct B {
> int i;
> };
>
> struct A
It makes sense to me - since very often many of the parts that are
processed are stand-alone and compile correctly (almost) by themselves
(maybe a package clause to be complete in a source). These smaller pieces
have to have one pass to grab their trees and symbols, and joined to the
other
The stack requirements are quite important, I think you have to either take
care of freeing by adding assembler function that does that, or if you can
instead allocate the buffers from Go variable declarations the GC will take
care of it, if it is possible to do this (very likely I think yes,
It shouldn't really be surprising. Go and Java share the use of interfaces,
but Go's concurrency is far lighter weight, and on top, Java has the extra
burden of a virtual machine before it actually hits the CPU as binary code.
I suspect also that the Go version could handle a much greater level
This would only be true if *derivatives* were specified. Go links
everything static by default, so in *very* broad terms, the binaries are
derivative of the stdlib in the distributed go compiler package. I think
really the proper way to look at this is this exact subject is simply not
There is one place where derivative is irrelevant, that would be where a
patent sticks to the algorithm, and this patently idiotic situation is not
universally applicable, some jurisdictions never added this kind of lunacy
to copyright law (unfortunately, not all).
As I understand it, the
These two points really nail it:
On Wednesday, 27 February 2019 11:02:23 UTC+1, Chris Hopkins wrote:
>
>
> What made me stay is the clarity and simplicity. So many languages seem to
> be an exercise in showing off how clever you are, by using x clever
> pattern. Go doesn't seem to suffer this.
I just wanted to jot down and share my personal most important reason, and
make this thread a short sample of the most important aspect of Go that
drove you to learn and use it.
For me, it was this: I have been tinkering with programming on and off over
the years since I was 8 years old, when
I never went that far into learning SQL, but I assume that 'LIKE' is a
substring match. As I see it, the two ways to improve the speed of it are
to prioritise the easier to detect, and most frequent conditions, and
whenever there is a shortcut, use it. This might mean double or more as
many
Assuming there is bytes in the system's entropy pool, you can also skip the
scrambling step, though I don't know what overhead consuming these bytes
entails compared to a standard PRNG. Then the biggest part of it is making
the raw bytes into float. I'm not sure - could you take 4 random bytes,
stages of the design
process, is that what is added doesn't take something away, especially
something that isn't obvious and explicit. The most dangerous bugs are the
least visible.
On Tuesday, 26 February 2019 00:37:50 UTC+1, Burak Serdar wrote:
>
> On Mon, Feb 25, 2019 at 3:06 PM Louki Su
oh, just one last point after a re-read - a great deal of what is required
to implement generics, in go, does not need to change the syntax of the
language, except where it concerns that CCR - (as replacing the builtin
numeric types especially would lead to massive overhead in dereferencing),
I am in the middle of implementing a generic tree type as part of a CLI
flags/configuration package, and a key goal in my design is to make the
declarations it parses as easy to read as possible, and as far as possible,
avoiding too much boilerplate.
Yes, nothing new there, but in the
I may be one of the most obsessive about the subject of source code
layouts, partly because of the impact that especially large and
disorganised source files (at least to the extent of the individual files,
but packages can get really nasty too).
It took me some time to navigate to find the
I believe that very notification has a button that triggers it to be
automatically installed. Otherwise just exactly do what it says and it'll
stop coming up and you'll get more juicy information from vscode about your
go things.
On Wednesday, 20 February 2019 15:14:21 UTC+1, Rich wrote:
>
> I
I know what it is. The closure is implicitly receiving the variable by
value, so its state when the goroutine spawns is fixed into its local scope.
If you moved that variable outside of the function you would not have this
problem, as another alternative solution.
Incidentally, the issue of
In my opinion, the many options suggested for the new error handling scheme
are bloated and unnecessary.
The defer statement is nice for placing closers next to openers, but I
think if simply a partition of a function block was segregated to contain
the handler code, probably nobody would be
all the comments were preceded by a blank line too, that it
should have that in it as well, I did intend it but it dragged on so long
...
On Friday, 15 February 2019 23:08:11 UTC+1, Louki Sumirniy wrote:
>
> ok never mind the combining files thing... doesn't work yet :) and I'm
> sure t
ok never mind the combining files thing... doesn't work yet :) and I'm sure
the manual cleanup will be super messy
On Friday, 15 February 2019 22:34:19 UTC+1, Louki Sumirniy wrote:
>
> oh, I really didn't introduce that so well...
>
> I fixed the issue about multiple init/ma
and speeding up the process of logically dividing
into files, and potentially, it may make it easier to see that a package
should be split or merged (if the circular imports don't get you first).
On Friday, 15 February 2019 22:08:04 UTC+1, Louki Sumirniy wrote:
>
> I have written a small
I have written a small source code processing tool which does something
that I personally think that gofmt should do. It's called tidy, and it's
hiding inside the embryonic attempt at a 'deal with all those irritating
application setup startup stuff' project here:
time.Duration is nanoseconds. You can easily get any other unit by dividing
by the time.Timeunit by another time unit.(time.Minute time.Second,
time.Millisecond, time.Microsecond)
If that 1 in your formula means time.Second then you could just replace it
with that, and 5.671ms would be equal
I would expect at minimum there is a field in the type in the AssignTo
field (it is a struct, I am guessing) that you could use. In VSCode you can
control-click on type names and it opens up the declaration of the type
(same for functions and variables too)
On Monday, 10 December 2018 09:10:16
I would be guessing that's because the response is actually thus an array
(square brackets around anything mean a list of same-typed fields without
keys) and you need to thus use response[0] to get it if there is only one,
or process it in a for loop iterating using range. Probably you could
I have done this many times. Some repositories are more of a pain than
others to move. I was amused to learn after having done this with
github.com/btcsuite/btcd, that the btcjson, btcec, btcutil and btclog repos
all were separate but quite tightly bound both to each other and it took me
about
on
nonlocal types. I think for that you need type aliases.
Like many aspects of Go, you have to think like the computer to express
your intent correctly.
On Thursday, 6 December 2018 04:05:36 UTC+1, Louki Sumirniy wrote:
>
> The main reason for the prohibition against circular imports is th
The main reason for the prohibition against circular imports is that you
have to add overhead in the processing to determine when to stop. From an
architectural perspective it also makes sense - most often if you stop for
a moment and think about what you are building, usually if you are
m!
Yes, using pure integer values for currency is generally the best way to
deal with it. The Bitcoin standard is that 1 BTC = 10,000,000 'satoshis'.
Many rightly point out that this is a stupidly small precision, but for the
time being is ok. I personally would expand this, and just use
I agree about the stutter naming. The name should at least specify the
bitwidth of the integral and fractional parts, to follow the pattern of the
fixed width types already existing. Fixed is easy enough to infer that it
is a fixed point type, by the package. You could name the types based on
C/C++ way of working with these things requires specifying the start and
end point using pointer arithmetic, which is pretty cumbersome considering
how often it is needed. I think what Ian said is probably the most complete
way to deal with it.
But probably you can also do it using the unsafe
The implicit type inferred from an integer is always 'int'. This is a 64
bit signed integer and thus has a maximum width of 63 bits. In Go, you
should not assume sign or width of an untyped implicit conversion, as the
'int' and 'uint' types default to the size of processor registers, which
are
A map[string]interface{} can hold an arbitrary, string labeled collection
of any types. You just need to have a type switch and cover all the
possible inputs for it.
The concurrency is safe as long as only one process is writing to variables
at once. If you need multiple concurrent processes
If you don't mind it involving a small background processing overhead, you
could use a goroutine running a hashcash style iterative hash chain
generation searching for a specified number of zero bits at one (or both)
ends of the resultant hash before you run out of bits. This is extremely
Goto isn't used often in Go because it has to be invoked on its own line
inside a conditional statement block, which often can perform the same
decision if you think it through, as well as moving shared elements into
functions that share the receiver or have common interfaces, outside of the
Using named return values and this construction you can drop all those
returns in each case block to outside the block. You only need to spend an
extra line if you have to break out of it by return or break.
On Monday, 24 September 2018 16:01:23 UTC+2, Lucio wrote:
>
> You never used:
>
>
Ah, I wasn't quite clear on that. That does make them a lot even more
useful.
On Monday, 24 September 2018 11:12:38 UTC+2, ohir wrote:
>
> On Mon, 24 Sep 2018 01:37:56 -0700 (PDT)
> Louki Sumirniy > wrote:
>
> > I am quite a fan of switch statements, they can mak
I am quite a fan of switch statements, they can make a list of responses to
a change in state very readable and orderly. But you have to remember a few
things about them. They don't evaluate in any definite order, so any
conditions that need more than one response need to use a fallthrough,
; On 9/23/18, Robert Engels > wrote:
>> >> Issues like these highlight the deficiencies of Go compared to Java.
>> The
>> >> Java designers understood languages far better, and from the start
>> realized
>> >> that identity and reference equ
1 - 100 of 179 matches
Mail list logo
