Re: [go-nuts] Re: is it possible to speed up type assertion?

Why are you putting the ResetTimer() and StopTimer() calls in there ? Unnecessary AFAIK. Also, all this test is benchmarking is the time it takes to construct a Field struct. What is the point ? > On Nov 26, 2018, at 1:47 PM, lary...@gmail.com wrote: > > Talking about loggers and ZAP

Re: [go-nuts] The most performant deque of all time?

e_test package as they are not supposed to access (or know of) > any of the deque internal variables. I'll move these tests to a different > file in the dequeue_test package. > > Really appreciate the suggestion (correction, really). > > Thanks, > Christian > > &

Re: [go-nuts] The most performant deque of all time?

Just an FYI, IMO your testing is incorrect. Your tests should be in a package dequeue_test so that they cannot access the internal details. This makes them brittle and hard to follow. For reference, look at the Go stdlib sync/map.go and sync/map_test.go. All of the tests are in sync_test for

Re: [go-nuts] The most performant deque of all time?

arguably non-idiomatic stdlib package does indeed > contain this kind of test). It also does not have in code asserts, > which are something that I've found to be very rare in Go code. > > On Mon, 2018-11-26 at 12:09 -0600, robert engels wrote: >> I am just offering, and many w

Re: [go-nuts] The most performant deque of all time?

ueue was performing correctly, but not efficiently. > > In any case, my point is a well validated implementation should have tests at > all levels (unit, integration, API, e2e) as some bugs can only be discovered > with some types of tests. > > On Mon, Nov 26, 2018 at 10:09 AM rob

Re: [go-nuts] The most performant deque of all time?

what should happen… And then some public methods like Do()/Move() are not tested at all. > On Nov 26, 2018, at 3:43 PM, robert engels wrote: > > My “none” looks to have been a little strong… Clearly whoever wrote the > container package believes in testing as the OP. A more in-

Re: [go-nuts] Re: Temporarily allow unused variables

I’m pretty sure that is rose colored glasses… It is a pain, but at the same time, the lack of dynamic code modification is more of a pain, coupled with no private methods in file scope (because with those you could decompose the larger functions without polluting the namespace). But in many

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

Again, what is wrong with the bounds checking/memory protection library/technique for C I referred you to? Even a decrease in performance will probably still be on par or better than the equivalent Go program. Much simpler and efficient. > On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen >

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

.pdf> > > On Thu, Jan 10, 2019 at 6:22 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > Again, what is wrong with the bounds checking/memory protection > library/technique for C I referred you to? Even a decrease in performance > will probably still be on par or b

Re: [go-nuts] Re: How to make the first character in a string lowercase?

Huh? Isn’t your code calling the exact same method ? > On Jan 7, 2019, at 12:22 PM, peterGo wrote: > > Nikolai, > > "What is the easiest way to make a string "LikeThis" --> "likeThis"?" > > Te easiest is not always the best. > > The code should be correct and reasonably efficient. For

Re: [go-nuts] Re: How to make the first character in a string lowercase?

yes, my bad, too cursory of a read of the code > On Jan 7, 2019, at 3:14 PM, jake6...@gmail.com wrote: > > I believe he is demostrating an optimization for strings that are already in > the correct form. > > On Monday, January 7, 2019 at 1:45:50 PM UTC-5, robert engels wrote:

Re: [go-nuts] C++ 11 to Golang convertor

I am pretty sure the other task is impossible, unless the generated code used CGo for all of its work. It gets really difficult for multithreaded apps, pthread does not translate to Go routines, no TLS, etc. I think correcting the converted Go would be more daunting that just rewriting it in

Re: [go-nuts] Re: C++ 11 to Golang convertor

Isn’t an easier and better source of resource utilization just to farm out each program under consideration to “the crowd” and say, rewrite dnsd in Go. For security verification purposes, you’d be going through each line of the converted program anyway. I still think it would be a nearly

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

On Fri, Jan 11, 2019 at 4:22 AM robert engels wrote: >>> Again, what is wrong with the bounds checking/memory protection >>> library/technique for C I referred you to? Even a decrease in performance >>> will probably still be on par or better than the equivalent Go progr

Re: [go-nuts] Re: I can assign a value to a handmade type "name" without methods and it's runnable. Why?

Yes. You can use fmt.Println(name(“john”).upper()) if you uncomment the code. > On Jan 11, 2019, at 3:17 PM, 伊藤和也 wrote: > > Sorry I misunderstand it. What I did is a conversion to "name". > > 2019年1月12日土曜日 5時54分12秒 UTC+9 伊藤和也: > type name string > > /*func (n name) upper() string { >

Re: [go-nuts] Re: I can assign a value to a handmade type "name" without methods and it's runnable. Why?

All of the code provided runs as expected for me - what’s the issue ? > On Jan 11, 2019, at 3:07 PM, T L wrote: > > The reason is the name value is not assigned to string (the built-in type). > It is assigned to interace{}. Please read the docs of fmt.Println for details. > > On Friday,

Re: [go-nuts] Can I say that a pointer is a memory address where a variable is?

I think this show move to r/programming > On Jan 9, 2019, at 12:55 PM, Justin Israel wrote: > > > > On Thu, Jan 10, 2019, 7:53 AM Justin Israel > wrote: > > > On Thu, Jan 10, 2019, 7:43 AM 伊藤和也 > wrote: > Can I say that a

Re: [go-nuts] golang gRPC question

The streaming mechanism seems to be the solution. Appears to be how cockroachdb does it. Sent from my iPhone > On Sep 12, 2018, at 2:47 PM, Josh Humphries wrote: > > >> On Wed, Sep 12, 2018 at 9:05 AM robert engels wrote: >> Hi, I am adding a remote component to my gi

Re: [go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

I think the idea of ‘field accessors’ is kind of scary. It is used all of the time in Java, but it happens there because Java has classes , so the generic can use a base class as a type - although most people do not do this for obvious reasons. Go interfaces only have methods. If generics are

Re: [go-nuts] Go memory usage inside containers

This may be of interest. https://lists.linuxfoundation.org/pipermail/containers/2012-May/029798.html https://www.spinics.net/lists/cgroups/msg16842.html

Re: [go-nuts] Golang equivalent of Python's context manager

I think it would be problematic, as the callee signature is limited - func() error - and with lack of method overloading you will need a lot of With methods… > On Sep 12, 2018, at 6:58 AM, Mirko Friedenhagen wrote: > > Hello, > > in Python I may define context managers which do stuff

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

I, and suggest others, look at real world applications to see how the proposal would work/benefit. I appreciate the feedback. > On Sep 11, 2018, at 10:50 AM, 'Axel Wagner' via golang-nuts > wrote: > >> On Tue, Sep 11, 2018 at 5:28 PM robert engels wrote: >> Thi

Re: [go-nuts] Generics - Why contracts?

As I’ve said elsewhere, a SIMPLE to use and understand solution that covers 90% is better than a complex one to cover 100% IMO, and fits in well with the rest of Go design. Go leaves out a lot - intentionally - and it’s a good choice. > On Sep 11, 2018, at 11:22 AM, alan.f...@gmail.com wrote:

Re: [go-nuts] A simplified generics constraint system.

> On Sep 14, 2018, at 12:16 PM, Ian Lance Taylor wrote: > > On Fri, Sep 14, 2018 at 3:32 AM, alanfo wrote: >> >> I was then brought back to reality by this post by Robert Engels in the >> 'Generics - Why contracts?' thread: >> >> "As I’ve said elsewh

Re: [go-nuts] [ANN] goey - Declarative, cross-platform GUIs

rk. > > - Robert > > > On Monday, 10 September 2018 14:25:05 UTC-4, Robert Engels wrote: > I wonder about the design, and how it will work. Since it uses the native > components behind the scene, you will get great fidelity but the layout can > be very difficult to acco

Re: [go-nuts] Contracts and fused multiply add

> On Sep 15, 2018, at 7:31 AM, Wojciech S. Czarnecki wrote: > > On Sat, 15 Sep 2018 06:36:35 -0500 > Robert Engels wrote: > >> Why do you need the for... > > Because 'for type' means 'contract' > Because CGG contracts are for each typeholder > and expre

Re: [go-nuts] Contracts and fused multiply add

Why do you need the for... Keywords with dual meaning is never a good idea. Sent from my iPhone > On Sep 15, 2018, at 4:53 AM, Wojciech S. Czarnecki wrote: > > On Wed, 12 Sep 2018 10:54:15 -0700 > jimmy frasche wrote: > >> because that misses cases like >> type Float float64 > > I am

Re: [go-nuts] Why is go starting multiple child process?

It appears (on OSX at least) the minimum number of threads a Go process will be 5. You need to understand that there are multiple threads for usually the following reasons: signal handling, GC collection, monitoring, OS events, timers, and others. The number of threads is going to vary based

Re: [go-nuts] Periodic task when time.Ticker and time.Sleep are pretty expensive

For reference, similar code under Java consumes 2.5 % CPU. I tested the Go code under OSX, and it is roughly 10%, which seems to be very high. Might be because the “context switching” is performed/attributed to the process (since it is internal), where for other systems it is the system call

Re: [go-nuts] Why is go starting multiple child process?

You can use ‘top’ and use H to show threads. > On Sep 16, 2018, at 11:27 PM, the.warl0ck.1...@gmail.com wrote: > > There's no -T in Ubuntu 16.04, am I wrong? > > On Monday, September 17, 2018 at 11:54:05 AM UTC+8, Patrick Smith wrote: > Probably those are threads, not processes. Try 'pstree

Re: [go-nuts] Long time blocking CGO call affect and CGO/Go.syscall/Go.net/C IO performance

You can run my tests at github.com/robaho/go-network-test You will see that both Java and Go are 10% slower than pure C. In Java’s case it is mostly due to the ‘security checks’ that are run. In Go’s case I believe it is just the barrier from Go to C overhead as there are many more function

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

Then it should be fairly trivial to call cgo to raise the priority of the ‘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

Re: [go-nuts] Go memory usage inside containers

rote: > > On Wed, Sep 12, 2018 at 7:07 AM, robert engels wrote: >> With the Azul VM (and I believe the G1 collector in Java), the VM is >> definitely aware of memory pressure as it approaches the maximum limit - >> then it will increase the concurrent GC activity t

Re: [go-nuts] Go 2 error-handling: choose requirements!

Until Go has typed errors and a throws clause (I.e exceptions) it’s pointless. You need to be able to be certain errors are handled or passed up at compile time. The throws clause facilitates this. It allows refactoring without breakage. Until then just live with the boilerplate and keep your

Re: [go-nuts] Re: I am not in favor of generics.

I’ve said many time, the CGG example you cite here is not generic code. If I want to pass a different user type and use that method I can’t, I need to change the source of Sum(). That is not generic programming... > On Sep 18, 2018, at 10:58 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep

Re: [go-nuts] Re: I am not in favor of generics.

> On Sep 18, 2018, at 9:51 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep 2018 08:19:13 -0500 > Robert Engels wrote: > >> So even when using generics you still need to be able to write >> understandable code. > > **need to be able to write underst

Re: [go-nuts] Go memory usage inside containers

With the Azul VM (and I believe the G1 collector in Java), the VM is definitely aware of memory pressure as it approaches the maximum limit - then it will increase the concurrent GC activity trying to avoid a potential huge pause if the limit was reached - so throughput is lowered. I would

Re: [go-nuts] [golang-dev] go doesn't need generics, but if they do...

ut it needs to match the platform. You can trust the JIT to perform better code optimization than most developers... > On Sep 12, 2018, at 8:34 AM, robert engels wrote: > > While I always appreciate a good presentation, a little color might be in > order to get me to watch a 1.5 hr

Re: [go-nuts] Go memory usage inside containers

You would need to refer me to those articles. We used Java in containers all of the time. You need to set a proper -Xmx though. > On Sep 12, 2018, at 9:07 AM, robert engels wrote: > > With the Azul VM (and I believe the G1 collector in Java), the VM is > definitely aware of mem

Re: [go-nuts] Golang equivalent of Python's context manager

of function f. See the main method… I am assuming this is attempting to be a general facility - and thus the signature of f will vary. > On Sep 12, 2018, at 7:18 AM, Sebastien Binet wrote: > > > > On Wed, Sep 12, 2018 at 2:10 PM robert engels <mailto:reng...@ix.netco

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

> On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote: > >> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > <>googlegroups.com <http://googlegroups.com/>> wrote: >> >> [golang-nuts to CC, golang-dev to BCC] >> >> On

Re: [go-nuts] Golang equivalent of Python's context manager

Too early, and the coffee had not kicked in... > On Sep 12, 2018, at 7:49 AM, robert engels wrote: > > Yes, you are correct. My bad :) > >> On Sep 12, 2018, at 7:34 AM, Sebastien Binet > <mailto:bi...@cern.ch>> wrote: >> >> >> >> On Wed

Re: [go-nuts] Golang equivalent of Python's context manager

(and probably error prone) to use IMO, especially with Go’s multiple return values. > On Sep 12, 2018, at 7:50 AM, robert engels wrote: > > Too early, and the coffee had not kicked in... > >> On Sep 12, 2018, at 7:49 AM, robert engels > <mailto:reng...@ix.netcom.com&

Re: [go-nuts] Golang equivalent of Python's context manager

Yes, you are correct. My bad :) > On Sep 12, 2018, at 7:34 AM, Sebastien Binet wrote: > > > > On Wed, Sep 12, 2018 at 2:23 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > I am pretty sure that is not correct, I am referring to: > >> func WithCon

Re: [go-nuts] Golang equivalent of Python's context manager

ien Binet wrote: > > > > On Wed, Sep 12, 2018 at 2:55 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > Ok, now the coffee has kicked in, and it still has problems, because you > cannot call a method and use a return value other than error without multiple

[go-nuts] golang gRPC question

Hi, I am adding a remote component to my github.com/robaho/keydb project and decided to use gRPC. I’ve reviewed the docs, and it appears to want to be stateless - which given the nature of Google makes sense. But for something like a database connection, where

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

as well as Java memory, or native memory. Go doesn’t need this, since the byte[] in Go is already a native pointer. > On Sep 12, 2018, at 8:15 AM, Egon wrote: > > On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote: > I am well aware of mechanical sympathy and th

Re: [go-nuts] Re: I am not in favor of generics.

If you have type checking / casting / type select, whatever you want to call it in the “generic code”, it is not generic, and not re-usable. You can’t possibly know all the possible types, there may even be more additional primitive types, so the code is not resilient - Go 2.1 and all of your

Re: [go-nuts] Re: I am not in favor of generics.

I am going to refer everyone involved in this discussion on generics to this once again. I know it is long, read the summary... but it’s important: https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics > On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki wrote: >

Re: [go-nuts] Re: I am not in favor of generics.

Here is a very common problem with generics... Everyone understands the concept of a tuple/pair. Pretty easy, you have getElement0 and getElement1 methods. Now a piece of code needs a KeyValue pair used in a map. So, with generics someone says, oh, I already have this pair class, I’ll just

Re: [go-nuts] Re: pass interface

lem()) > } > > Output: > is interface, with value: test > reflect.Type is interface {} > > > > > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert Engels > написал: >> >> I mean reflect.Type not a type that is an interface.

Re: [go-nuts] Re: navigating through interface calls

When using IntelliJ, did you restrict the search to “project files”? Otherwise you will get implantations anywhere in the standard library or other projects. > On Dec 10, 2018, at 6:21 AM, David Wahlstedt > wrote: > > Hi, and thanks for your answers! > Yes, I realize that the possible

Re: [go-nuts] Http server, async tasks and gracefully shutdown.

>From the docs: Note that calls with a positive delta that occur when the counter is zero must happen before a Wait. Calls with a negative delta, or calls with a positive delta that start when the counter is greater than zero, may happen at any time. Typically this means the calls to Add

Re: [go-nuts] Is there a good approach to abstraction of DB access including transactions and forupdate?

Distributed transactions are difficult in cloud computing. See GCP Spanner. Also read up on “saga” pattern. If you have multiple sources participating in the transaction, saga seems to be the preferred method for highly scalable solutions. > On Dec 10, 2018, at 8:55 AM, bonpi bonpi wrote: >

Re: [go-nuts] pointer dereference optimization in loops

According to Dobb’s, http://www.drdobbs.com/cpp/type-based-alias-analysis/184404273 <http://www.drdobbs.com/cpp/type-based-alias-analysis/184404273>, many compilers do this today to some degree. > On Nov 30, 2018, at 2:51 PM, robert engels wrote: > > I’m not so sure

Re: [go-nuts] Package Stutter

l function wrappers (mid-stack > inlining should make that zero-cost at some point). > > FYI I have created a Go proposal related to this that you might wish to give > feedback on: > https://github.com/golang/go/issues/29036#issuecomment-443311975 > <https://github.com/gol

Re: [go-nuts] Channels: selecting the last element

of such side effects like my > initial problem of forgotten results in their channels. I would love to > hear/read/see more on the unbuffered vs. buffered tradeoff to get rid of this > gut feeling I am currently based on :-). Any good article you can point me to? > Thanks > > Rob

Re: [go-nuts] Channels: selecting the last element

What he is saying is that a closed channel is always ready to be received, so in your code, you could achieve closed++ twice on the same channel... > On Dec 18, 2018, at 1:38 PM, Chris Burkert wrote: > > Justin, > I don‘t understand that. Maybe I am wrong but I think this is not an issue >

Re: [go-nuts] Channels: selecting the last element

This may be a helpful read: https://dave.cheney.net/2013/04/30/curious-channels > On Dec 18, 2018, at 2:02 PM, robert engels wrote: > > To clarify the semantics aspects: > > If A cannot proceed until B performs it’s work, because there is a > dependency, then using a

Re: [go-nuts] Channels: selecting the last element

PM, robert engels wrote: > > Whether to use buffered or unbuffered comes down to two things: > > 1) the semantics of the communication. because using unbuffered channels > simplifies a lot - knowing the send will not complete until the read > completes - it provides a sync

Re: [go-nuts] Re: performance optimization

I don’t think the analysis is correct in the issue cited. No one mentions just using usleep() as the system call like a C program would, at least for time.Sleep(), and block the calling thread. For the timer based select, it is more difficult, and it seems the timerfd is the best solution -

Re: [go-nuts] Re: performance optimization

Then something is broken on the implementation. 10x overhead does not seem realistic. > On Dec 19, 2018, at 9:50 PM, Ian Lance Taylor wrote: > >> On Wed, Dec 19, 2018 at 6:52 PM robert engels wrote: >> >> I don’t think the analysis is correct in the issue cited.

Re: [go-nuts] Re: why map the key type must not be a function, map, or slice

Yes, and you can do that. > On Jan 26, 2019, at 3:36 PM, Victor Giordano wrote: > > Probably i need to reveal the underlying problem i was trying to solve > > At a glande: an appoinment subsystem for a health organization, considering > practitioners that work on services offering practices

Re: [go-nuts] Golang net/http server returning empty packets

Sounds a lot like a concurrency issue - possibly not flushing the request, or the request is being processed / timing out from another go routine. I would start by adding some lifecycle request traces and processing these in an automated fashion - almost the only way to debug highly concurrent

Re: [go-nuts] Writing an Excel add-in using Go?

, and efficient (the one plugin process can serve data for multiple Excel processes or sheets. > On Jan 22, 2019, at 9:53 AM, mrech...@gmail.com wrote: > > Thanks! That's what I thought/feared.. > > On Tuesday, January 22, 2019 at 4:47:33 PM UTC+1, robert engels wrote: > But it also d

Re: [go-nuts] Writing an Excel add-in using Go?

t 9:45 AM, robert engels wrote: > > What is wrong with using COM from Go ? > >> On Jan 22, 2019, at 9:35 AM, mrech...@gmail.com <mailto:mrech...@gmail.com> >> wrote: >> >> Hi, >> >> I was wondering if there is a library supporting writi

Re: [go-nuts] Re: Existing code for order-preserving concurrent work queue?

at 3:51 AM Tom Payne <mailto:twpa...@gmail.com>> wrote: > Yes, I did, thank you! My reply was to the previous message (robert engels' > post about it being "straightforward" but not providing code) and I think we > just both hit send at about the same time. > >

Re: [go-nuts] Re: Existing code for order-preserving concurrent work queue?

s well. Looking forward > to AMD’s 2x64 Rome. > > On Sun, Jan 27, 2019 at 12:38 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > Even with 64 cores your process takes 3hrs… unless they are all external > requests - so essentially unlimited cores. > >

Re: [go-nuts] Urgent Need - Interview and OFFER tomorrow!

To clarify, the interview effort is the same regardless of whether or not they get hired, and getting hired has a lot more factors that how well the interviewer did - in fact, if they do a really great job the outcome might be that they do t get hired... > On Mar 27, 2019, at 12:39 PM, Rob

Re: [go-nuts] Urgent Need - Interview and OFFER tomorrow!

And if they don’t get hired? Seems pretty low on the risk/reward scale, and because of that somewhat ripe for abuse/low performance. > On Mar 27, 2019, at 10:38 AM, judyros...@gmail.com wrote: > > Hi Guys, > > I am hoping ya'll can help me out… I have an interview slot tomorrow at 1pm >

Re: [go-nuts] Question regarding gob

This is not really true. In Java everything is a pointer (reference) and has no problem with the semantics of passing a reference, it is built into the serialization. They may be in fact passed as a pointer (local rpc) or passed as a copy of the object graph, or something in between (custom).

Re: [go-nuts] Question regarding gob

I think the big difference is that gob is most often for Go to Go serialization (at least easily), where as gRPC is cross-platform RPC mechanism using a cross platform serialization (protobufs).-Original Message- From: Sameer Ajmani Sent: Mar 25, 2019 9:53 AM To: Glen Huang Cc:

Re: [go-nuts] source for scheduler and gc?

The issue I linked to goes pretty in-depth on the reasons. > On Apr 3, 2019, at 12:30 PM, Jason E. Aten wrote: > > Thanks Ian. > >> On Wednesday, April 3, 2019 at 6:57:32 PM UTC+2, Ian Lance Taylor wrote: >> On Wed, Apr 3, 2019 at 8:34 AM Jason E. Aten wrote: >> > >> > Where does the

Re: [go-nuts] source for scheduler and gc?

Sorry, that made no sense, since the original message was not sent to the group. Here is the link:see https://github.com/golang/go/issues/11100-Original Message- From: Robert Engels Sent: Apr 3, 2019 12:36 PM To: "Jason E. Aten" Cc: golang-nuts Subject: Re: [go-nu

Re: [go-nuts] Persistent memory support for Go

, just curious, maybe the use cases have changed. > On Apr 3, 2019, at 5:47 PM, Robert Engels wrote: > > I think the project needs to be distributed as a patch to the Go codebase - > too much to review/maintain for security controls. > > Also, I’m curious about the

Re: [go-nuts] Persistent memory support for Go

n the past few years, > including efforts to change C and Java, and adhoc libraries for C/C++, Java > and Python. These changes are our efforts to make persistent memory > accessible to Go developers. > > Thanks! > Mohit > > From: Robert Engels > Date: Wednesday, Apr

Re: [go-nuts] Persistent memory support for Go

t; There has been a lot of work around this technology in the past few years, > including efforts to change C and Java, and adhoc libraries for C/C++, Java > and Python. These changes are our efforts to make persistent memory > accessible to Go developers. > > Thanks! > Mohit

Re: [go-nuts] Persistent memory support for Go

I think the project needs to be distributed as a patch to the Go codebase - too much to review/maintain for security controls. Also, I’m curious about the Api. In reviewing the example, it looks no different than any ORM - just flatter -and these don’t need a customized runtime. What would

Re: [go-nuts] Persistent memory support for Go

of pmem I don’t see why it shouldn’t be treated like any other external resource. > On Apr 3, 2019, at 5:47 PM, Robert Engels wrote: > > I think the project needs to be distributed as a patch to the Go codebase - > too much to review/maintain for security controls. > > Also,

Re: [go-nuts] What happens when you call another method within a method set at the end of a method

But yes, similar to how all recursive functions can be rewritten using loops, which are more efficient, that is essentially what tail call optimization does - just that the process it automatic. > On Apr 6, 2019, at 5:21 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Sat, Apr 6, 2019 at 9:34

Re: [go-nuts] Re: Decimal survey

You can contact me, and review github.com/robaho/fixed it is more designed for performance over flexibility the decimal.Decimal being more suited for the latter. > On Mar 28, 2019, at 5:53 PM, Marcin Romaszewicz wrote: > > A huge +1 on that last comment. You never want to store currency in

Re: [go-nuts] How to pass http.ResponseWriter while writing test case in Go

I wouldn’t test that, test what is producing the response and that it is the correct format. The testing of the encoding if the response is all that is warranted - the other is tested in an integration test. > On Apr 1, 2019, at 8:07 AM, aniruddha.dwiv...@nytimes.com wrote: > > Hi, > > I am

Re: [go-nuts] Modifying the Runtime Scheduler

I think it would be helpful to if you providee a summary of the issue/idea before the detailed information - it makes it nearly impossible to understand - at least for me. > On Apr 7, 2019, at 1:41 PM, robert engels wrote: > > The link to the repo does not allow not credential

Re: [go-nuts] Re: Some issues with UDP and Go

I am not sure that is the case. It is “known” that UDP doesn’t support OOB, mainly since it is not a stream - it is packet oriented, but also because it is not part of the specification - it would have to be an application level transport that adds that as far I understand. That being said, I

Re: [go-nuts] Modifying the Runtime Scheduler

The link to the repo does not allow not credentialed access... > On Apr 7, 2019, at 5:58 AM, Tharen Abela wrote: > > I'll preface this by saying this is for academic purposes. > > I am working in the following repository > , but the following files are

Re: [go-nuts] net.Conn types: File vs SyscallConn method

File is cross-platform. I am pretty sure no syscall. is guaranteed to be available on any given platform.-Original Message- From: Matt Layher Sent: Mar 25, 2019 1:03 PM To: golang-nuts Subject: [go-nuts] net.Conn types: File vs SyscallConn method I've been doing low-level networking

Re: [go-nuts] Question regarding gob

> > I mean, everything except the things that are not pointers. > >> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels wrote: >> This is not really true. In Java everything is a pointer (reference) and has >> no problem with the semantics of passing a reference, it is

Re: [go-nuts] net.Conn types: File vs SyscallConn method

uestion still stands, as far as I know.On Monday, March 25, 2019 at 2:36:29 PM UTC-4, Robert Engels wrote:File is cross-platform. I am pretty sure no syscall. is guaranteed to be available on any given platform.-Original Message- From: Matt Layher Sent: Mar 25, 2019 1:03 PM To: golan

Re: [go-nuts] Does gc hate me?

Are you sure the lib 32/64 matches your Go environment. Also, the previous posters told you what was wrong with the original code. Did you change that? > On Feb 25, 2019, at 9:36 PM, yangwu...@gmail.com wrote: > > Hi all, > > The following unexpected fault address errors are occured

Re: [go-nuts] distribution of go executables

You are not correct. There are current cases where apis are being claimed to be copyrighted. It is under active litigation. > On Feb 27, 2019, at 8:19 AM, Space A. wrote: > > You have very poor understanding of the subject, messing everything up. > There is no "derivatives" in Go's license

Re: [go-nuts] distribution of go executables

n a court. Otherwise, if > it ever will, I mean, compiling own program and distributing a binary which > used stdlib e.g. without kissing someone's ass - language is dead. > > > > ср, 27 февр. 2019 г. в 21:39, Robert Engels : >> That is incorrect thinking. And again

Re: [go-nuts] distribution of go executables

That is incorrect thinking. And again, it is all subject to litigation. Whether you are right or wrong is up to the courts to decide. > On Feb 27, 2019, at 8:55 AM, Space A. wrote: > > Regarding runtime - it's interesting (and separate question maybe), and I > would argue that runtime IS

Re: [go-nuts] Re: I found a very strange code that would cause deadlocks and blocking，why???

It does not. > On Feb 28, 2019, at 9:13 PM, mountain...@gmail.com wrote: > > First of all, I am very grateful for your reply. I still want to know if it > has anything to do with STW？ > > 在 2019年3月1日星期五 UTC+8上午3:55:57，Louki Sumirniy写道： >> >> Channels require goroutines. `<-variable` blocks

Re: [go-nuts] I found a very strange code that would cause deadlocks and blocking，why???

I think it would be helpful if you learned more about concurrent programming. It is 10x harder, even with the simplifications that Go offers. If you don’t understand the concepts you are going to struggle. Start with some tutorials and work your way up. > On Feb 28, 2019, at 10:14 PM,

Re: [go-nuts] cancelCtx: why does not return c.done directly?

for the author to write it the way they did since no other code can set the done to nil... > On Mar 1, 2019, at 3:38 PM, Marvin Renich wrote: > > * Robert Engels [190301 15:07]: >> I am pretty sure it is the memory model unless there is other code in >> the stdlib that sets

Re: [go-nuts] cancelCtx: why does not return c.done directly?

I am pretty sure it is the memory model unless there is other code in the stdlib that sets the dove back to nil - which wouldn’t make sense since the channel should be unique to the context instance and that would allow multiple done channels to be created. > On Mar 1, 2019, at 1:35 PM,

Re: [go-nuts] Channel Feature Suggestion

The proper solution is using a condition variable. You can handle the proposed use case easily. There is no need for it to be specific to channels, but you need another layer. > On Feb 21, 2019, at 2:49 PM, Burak Serdar wrote: > >> On Thu, Feb 21, 2019 at 1:44 PM Serhat Şevki Dinçer >>

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

As I pointed out long ago on stackoverflow the benchmark games are seriously flawed and should not be used for language performance comparisons. As a simple example, look at binary trees. In all of the “fast” implementations, they resort to specialized memory pools that wouldn’t be useable in

Re: [go-nuts] Re: Can Go 2.x (or later) adopt some concurrency safety paradigms from Rust?

I agree wholeheartedly. Use the race detector, and well designed code - much easier to understand and maintain than the equivalent Rust IMO. > On Mar 4, 2019, at 1:49 PM, Manlio Perillo wrote: > > On Monday, March 4, 2019 at 8:06:16 PM UTC+1, Jeff Kayser wrote: > Paradigms of Rust for the Go

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

Mar 6, 2019, at 5:29 PM, 'Isaac Gouy' via golang-nuts > wrote: > > On Wednesday, March 6, 2019 at 5:44:21 AM UTC-8, Robert Engels wrote: > As I pointed out long ago on stackoverflow the benchmark games are seriously > flawed and should not be used for language perfo

<    1   2   3   4   5   6   7   8   9   10   >