Ah, my last post had a small mistake. A small modification to upper should
be all you need. The function should use >= instead of >. See below.
upper := sort.Search(len(haystack), func(i int) bool {
return haystack[i].name >= needle.name
})
On Tue, Oct 11, 2022, 7:38 AM K. A
sort.Search runs binary search. It's only guaranteed to work when you
provide it with a function which is monotonic -- true at index i implies
true at all indices greater than i.
Your loop style search does not provide a monotonic function, whereas your
"upper" function is monotonic. However,
The only alternatives that I see would each introduce an extra call to Add,
like the below. I'm not sure if this is much less "clunky", but it at least
avoids the reassignment to s.
func collectStringsetMap(m map[string]*stringset.Set, key string, value
...string) *stringset.Set {
if s, ok :=
and combine pipeline stages as pairs.
* Handle fatal and non-fatal errors from any pipeline stage.
* Sinks for draining the result of a pipeline computation.
Some future enhancements are planned. Please leave any suggestions or
issues in the issue tracker.
Thanks
K. Alex Mills
--
You received
Yes. Declaring i and j on the same line is certainly cleaner. We should all
do it like that.
Am I missing something?
On Thu, Aug 18, 2022, 9:25 PM Yasser Sinjab wrote:
> Thanks, I don't object it personally, but I had a debate about "grouping
> variables is considered a clean code".
>
> Let's
I would hesitate to call this a bug in gofmt. Go released new godoc
features as part of Go 1.19, along with reformatting of comments. Those
features were entirely intentional.
The decision made in the go-swagger project to place its comments alongside
godoc comment blocks was a risky one in case
Monitoring and observability are best practices regardless of what language
you use. We use a combination of Prometheus / Grafana and metrics exported
by runtime/metrics. We also include custom metrics tailored to our
application's use-case.
Prometheus is not a standard Linux tool, but it is open
thod like Map() on a stream instance can’t be
> written - because the stream is of type T, and the Map() produces a stream
> of type R.
>
> psuedo code:
>
> type Stream[T any] interface {
> ...
> Map[R any](func (T) R) Stream[R] // syntax not supported
> ...
>
Ah, my apologies, I was wrong. Panicking in the midst of a func passed to
one of these pipeline stages most certainly *will not* shut down the entire
pipeline and cannot be recovered like I had suggested. Sorry about that.
Sincerely,
K. Alex Mills
On Thu, Aug 11, 2022 at 4:56 PM K. Alex Mills
o with this library. Just use recover at the top
of the func that spins up the pipeline and use context.WithCancel to shut
the rest of the pipeline down in that case. Let me know if that's unclear
and I'll do my best to provide an example.
Sincerely,
K. Alex Mills
On Thu, Aug 11, 2022 at 4:18 PM
mpossible with error returns.
>
> A streams api with panic/recover is needed.
>
> On Aug 11, 2022, at 12:55 PM, K. Alex Mills
> wrote:
>
>
> Hello Gophers,
>
> I recently had an opportunity to try out Go generics on a small pipelines
> package <https://pkg.go.dev/
/kalexmills.com/journal/pipelines/>. I'm
open to any of your thoughts, suggestions, and issue reports.
Sincerely,
K. Alex Mills
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving e
I'm guessing here, but you probably do need the full type-checker for that,
depending on what you mean by "a native type".
In go we can alias types in two ways.
type A uint8
type B = uint8
There are subtle differences between the two which I don't claim to
understand... In any case, AFAIK both
FWIW: I'm not surprised that it's slower because it's handling
significantly more of the compilation. The parser is very fast. Adding in
type-checking is going to be less fast.
IIRC, the packages package also has to make network calls and do filesystem
I/O behind the scenes in some cases. The
It's been several months since I used these packages but IIRC, go/ast only
requires code to parse correctly, while go/types actually runs the
type-checker.
Running the type checker implies having a complete picture of all the types
used in a Go program, which, in my recollection, usually means
Partial responses inline, HTH.
On Thu, Apr 29, 2021, 6:09 AM Amit Saha wrote:
> Hi all, when an incoming request comes in, does the ListenAndServe()
> function read the first line (as explained in
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages) to figure
> out whether there is a
On Sun, Apr 11, 2021, 5:15 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:
> On Sun, Apr 11, 2021 at 5:11 AM Kurtis Rader wrote:
>
>>
>> It is nice that the specification allows for an efficient implementation.
>> But I agree with Dan that your documentation is opaque, obtuse,
This seems like a welcome change and leaves the door open for the future
inclusion of type unions. Nicely done!
Regarding this approximation operator, I have a question about the intended
meaning of:
~struct{
F int
A string
}
Would this match the following types?
type A struct{
F int
A
portant for some use-cases. For my purposes,
I want to avoid downloading / type-check module dependencies anyway.
Sincerely,
K. Alex Mills
On Wed, Jan 20, 2021 at 8:03 PM K. Alex Mills
wrote:
> Hi All,
>
> Right now, I can run the type-checker by writing the GitHub tarball
> conten
large part of what packages provides?
Thanks,
K. Alex Mills
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To
> I was thinking of potential issues if you rebalance the tree as an example.
>
> I’m not certain what issues could arise as I’ve never considered a
> concurrent data structure that lacks some kind of synchronisation for both
> read and writes unless it’s immutable copy-on-write or similar.
>
> Do
On Tue, Jan 5, 2021, 6:59 PM Nathan Fisher wrote:
> Does write only locking provide read correctness? I would’ve thought based
> on the memory model it could cause issues?
>
> https://golang.org/ref/mem#tmp_2
>
It depends on your notion of "read correctness", specifically when you
consider each
That is the simplest and most conservative way go about it, but ultimately
it depends on what you need out of your concurrency semantics.
If you're willing to settle for a linearizable execution, you can gain some
performance improvements by only checking the lock for write operations. So
long as
> Technically, I believe a range loop variable can be used in a goroutine
>> safely. A very contrived example: https://play.golang.org/p/jgZbGg_XP6S .
>> In practice I can not see much use for this kind of pattern, but it does
>> exist.
>>
>
> It is correct that the range loop variable can be used
At a glance, this feels to me like it is more complicated than the current
generics proposal. That said, it also seems very original so I have to give
credit there.
This proposal seems to put the responsibility for monomorphizing generic
code onto the programmer. I'm not sure why it would be
ing has just
pointed out a few other concerns like pointer comparison and finalizers for
which analyzers have yet to be written. My perception is that these two
features aren't very widely used, so I wouldn't expect to find a large
number of instances like these.
> On Sun, Dec 20, 2020 a
mentioning that there are issues which loopclosure misses
>> which VetBot is able to find, and the community's effort will still be
>> needed to help sift through false-positives once the project has stabilized.
>>
>>
>> On Sun, Dec 20, 2020 at 12:08 PM K. Alex Mills
>>
misses which
VetBot is able to find, and the community's effort will still be needed to
help sift through false-positives once the project has stabilized.
On Sun, Dec 20, 2020 at 12:08 PM K. Alex Mills
wrote:
> Hello Gophers!
>
> During a Q session at this year's GopherCon, some me
nt performance
> implications for low-level/tight-loop functions as it will avoid the
> indirection required for interface method dispatching (at the expensive of
> code explosion for common calls with lots of types).
>
> On Dec 27, 2020, at 11:31 AM, K. Alex Mills
> wrote:
>
hole thing as far as I am concerned.
>
> Cheers
>
> On Sun, 27 Dec 2020, 05:25 K. Alex Mills, wrote:
>
>> While it depends on the final generics implementation, my understanding
>> of how things stand now is that Print would compile down to a separate
>> chunk of binary
While it depends on the final generics implementation, my understanding of
how things stand now is that Print would compile down to a separate chunk
of binary for each type T that is used. For instance, if you used Print[A]
and Print[B] in your code, they would each refer to separate binary
For my part, I see some value in maintaining a source of example solutions
to problems that generics could solve. Since I was not aware of any
resource that attempts to gather together several example implementations
in one place (and couldn't find one after a couple minutes of searching), I
On Thu, Dec 24, 2020, 1:18 AM Martin Hanson
wrote:
> I'm sorry, but this is not real life problems. This is exactly the problem
> with this proposal. It's based on nothing but small theoretical examples.
>
Sorry, I don't understand.
Here are some of the example applications which Ian mentions
On Wed, Dec 23, 2020, 6:17 AM Martin Hanson
wrote:
>
> After generics gets added, it's going to be something else next time, and
> again and again. The list goes on and on about changes people want to
> make to Go. Not real life problems, just so-called "nice to have".
>
> No, the added and
On Sun, Dec 20, 2020, 2:01 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> I expressed my concerns at the issue tracker in 2017 when I still had
> a Github account. That's no more the case, so I'll take the
> opportunity to make a comment here. I still believe that the intent to
> change the behavior
your GitHub username and a
brief outline of your experience with Go.
It's my hope that this project can provide some data that can help to move
Go forward. To that end, I'm also interested in any and all feedback and
suggestions. Contributions are also welcome
<https://github.com/github-vet/bots/issue
But I tried compiling this program:
https://github.com/davecheney/junk/tree/master/id
and I cant get it to compile/run, the runtime.h file seems MIA
-alex
On Wed, Sep 23, 2020 at 6:02 PM Alex Mills wrote:
> Not a joke, in terms of performance, if you access the goroutine id via
>
Not a joke, in terms of performance, if you access the goroutine id via the
C library call?
My only concern would be if goroutine id's were reused, if not it would
work.
On Wed, Sep 23, 2020 at 5:54 PM Ian Lance Taylor wrote:
> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wr
ref=spike-organic-signature&_ts=p4aw3> [image:
> p4aw3]
>
> On September 24, 2020 at 0:17 GMT, Alex Mills
> wrote:
>
>
> Since by default all http requests coming to a go http server are on their
> own goroutine, I am wondering if there is a way to have some sort of
>
Since by default all http requests coming to a go http server are on their
own goroutine, I am wondering if there is a way to have some sort of
"global" variable that is *local* to a goroutine if that makes sense,
something like this, where "gork" is the namespace for variables available
It works temporarily, but then I have to manually update each file that
imports + exports the methods, it won't "just work" with new versions of
the library that gets imported, right?
On Wed, Sep 23, 2020 at 11:59 AM Jason Phillips
wrote:
> Did you try your own suggestion? It seems to work
languages.
On Wednesday, September 23, 2020 at 11:39:08 AM UTC-7 Alex Mills wrote:
> I have this date string:
>
> "2020-09-23 18:31:41.015852841 + UTC"
>
> the above is generated via:
>
>
> *time.Now().UTC().String()*
>
> my question is, how can I gener
I have this date string:
"2020-09-23 18:31:41.015852841 + UTC"
the above is generated via:
*time.Now().UTC().String()*
my question is, how can I generate a date string like this:
"2020-09-23 18:31:41.0158"
and how can I then parse it? I dont need to indicate that it's UTC, I can
Using node.js, we might have this:
const z = new Z();
exports.z = z
and then in another file we can import
import {z} from '../z'
with Golang, I am trying to do something similar:
package log
import Logger "github.com/foo/bar/logger"
// create an instance
var log = Logger.create()
//
i dont understand, is there a solution or just a proposal?
On Mon, Sep 21, 2020, 23:03 Paul Jolly wrote:
> I just replied. I think that https://github.com/golang/go/issues/26640
> covers this.
>
> On Tue, 22 Sep 2020 at 06:52, Alex Mills wrote:
> >
> > I put this ques
I put this question on the golang issue tracker on github:
https://github.com/golang/go/issues/41546
I am sure it's been answered before but hard to search for..anyone know
what the right approach is? I like how node.js / NPM solve it using
symlinks personally.
--
You received this message
anic-signature&_ts=owh4j> [image:
> owh4j]
>
> On September 19, 2020 at 18:44 GMT, Alex Mills
> wrote:
>
>
> Using Node.js with several projects I can use these:
>
> const rl = require('readline');
> process.stdout.write('current line')
> rl.
Using Node.js with several projects I can use these:
const rl = require('readline');
process.stdout.write('current line')
rl.clearLine(process.stdout);
rl.cursorTo(process.stdout, 0);
this will clear the current line in the terminal, so I can achieve
something like a status line, but I cannot
The explanations I find online arent very clear to me :(
On Thursday, September 10, 2020 at 6:40:34 PM UTC-7 Ian Lance Taylor wrote:
> On Thu, Sep 10, 2020 at 4:39 PM Alexander Mills
> wrote:
> >
> > I have this helper func to print memory usage (detect a memory leak?)
> >
> >
> > func
49 matches
Mail list logo
