You are using g 64 bit in Go and 32 bit in C
> On Feb 3, 2019, at 12:33 PM, Miki Tebeka wrote:
>
> A bit of profiling shows that the modulo operator takes most of the time:
>
> 1.77s 1.77s (flat, cum) 100% of Total
> . . 2:
> . . 3:import (
I’ll state again, it’s because these benchmarks have little to do with the
success of systems. Experienced designers know this. Take, architecture,
barring some large scale dynamics, everyone would build simple boxes. It
doesn’t mean the project will be a commercial success, most likely not.
T
sounds like a lot, as soon as you do any IO that
will fall to about .001 percent difference.
> On Feb 3, 2019, at 12:49 PM, Miki Tebeka wrote:
>
> Yup. Using int32 in Go reduces the difference to 1.5. Thanks
>
>> On Sunday, February 3, 2019 at 8:35:46 PM UTC+2, Robert Eng
b 3, 2019, at 12:59 PM, Milind Thombre wrote:
>
> Right! Just Listen to what ever the Architect's (or City Planner's) opinion
> is, implement it, and we in all certainty have a performant system. Numerical
> Evidence is for dummies
>
> Whatever!
>
> O
I am sure the Go purists are going to say that the version that returns nil for
the object with no error return are not idiomatic Go...
> On Feb 3, 2019, at 10:26 PM, Randall O'Reilly wrote:
>
> I’m trying to figure out the best convention for the basic function of
> accessing elements in a co
It is even more involved than that. A GC language in a highly concurrent
dynamic memory environment can be faster than a hand rolled C or assembly
implementation. The important consideration is memory allocation and
deallocation costs in the critical path. In a GC environment they are
essential
Reading and writing to a channel has locks behind the scenes. Locks are
implemented with futexes.
If your program is IO bound the simplest solution is often to use buffering in
the IO to perform more work per IO operation.
> On Feb 3, 2019, at 5:00 PM, Andrew Medvedev
> wrote:
>
> Hi every
k" version.
>
> Is this a necessary cost of synchronizing on over 400_000 values over a
> channel?
>
> On Monday, February 4, 2019 at 3:56:32 PM UTC+3, Robert Engels wrote:
> Reading and writing to a channel has locks behind the scenes. Locks are
> implemented with futexes.
d to no-channels
> "only fn-callback" version.
>
> Is this a necessary cost of synchronizing on over 400_000 values over a
> channel?
>
> On Monday, February 4, 2019 at 3:56:32 PM UTC+3, Robert Engels wrote:
> Reading and writing to a channel has locks behind the
And if that is the case, the most likely way to speed up you program would be
to send the route updates in a batch to the kernel - not sure that this is even
possible.
> On Feb 4, 2019, at 9:56 AM, robert engels wrote:
>
> Also, to clarify, in the absence of more details, I would
Yes?
> On Feb 3, 2019, at 12:33 AM, ghulaamshab...@gmail.com wrote:
>
>
>
> On Friday, September 28, 2018 at 1:51:53 AM UTC+5, robert engels wrote:
> I have ported LRMP (light weight reliable multicast protocol) to Go.
>
> It is available at lrmp <https://github.com
GetNested anything is a sign something is broken in the API. The whole point of
being nested is almost always encapsulation and then you are breaking it.
> On Feb 5, 2019, at 10:30 AM, Burak Serdar wrote:
>
>> On Tue, Feb 5, 2019 at 9:12 AM wrote:
>>
>> I've the following situation:
>> I prox
Then you want inheritance not encapsulation.
> On Feb 5, 2019, at 10:46 AM, Burak Serdar wrote:
>
>> On Tue, Feb 5, 2019 at 9:41 AM Robert Engels wrote:
>>
>> GetNested anything is a sign something is broken in the API. The whole point
>> of being nested is a
But even then, exposing internal details outward leads to lots of problems,
testability for certain. There’s almost always a better way then GetNested,
GetWrapped, or any of its derivatives.
> On Feb 5, 2019, at 12:20 PM, Robert Engels wrote:
>
> Then you want inheritance not enca
discussion.
> On Feb 5, 2019, at 12:33 PM, Burak Serdar wrote:
>
>> On Tue, Feb 5, 2019 at 11:27 AM Robert Engels wrote:
>>
>> But even then, exposing internal details outward leads to lots of problems,
>> testability for certain. There’s almost alwa
On Tue, Feb 5, 2019 at 12:22 PM Robert Engels wrote:
>>
>> As far as the error handling, this is kind of a limitation of the error
>> interface in Go and should be solved there. But I would start with asking,
>> why do you need the causation error? If it is increased logg
I think we’ll just agree to disagree.
> On Feb 5, 2019, at 2:52 PM, Burak Serdar wrote:
>
>> On Tue, Feb 5, 2019 at 1:46 PM Robert Engels wrote:
>>
>> If the error doesn’t know what it is wrapping but the caller needs to know
>> the wrapped error you have a
Shouldn’t you just be taking the content length from the header if forwarding
the same body. There is no need for the length of the body.
> On Feb 5, 2019, at 6:53 PM, Burak Serdar wrote:
>
>> On Tue, Feb 5, 2019 at 5:18 PM Dan Kortschak wrote:
>>
>> Personally, I think this is a bug in the
situations.
There is a reason the Body is a ReaderCloser and not a buffer. It is part of
the http specification.
> On Feb 5, 2019, at 9:00 PM, Burak Serdar wrote:
>
> On Tue, Feb 5, 2019 at 7:00 PM Robert Engels <mailto:reng...@ix.netcom.com>> wrote:
>>
>> Shouldn’t
planation
>
>
>
> Il giorno mercoledì 6 febbraio 2019 07:28:54 UTC+1, Burak Serdar ha scritto:
>>
>> On Tue, Feb 5, 2019 at 8:13 PM robert engels wrote:
>> >
>> > That’s what I was trying to point out. Your design is not correct. The
>> > Body is a
6, 2019 at 5:15 AM Robert Engels wrote:
>>
>> I see now, but if that can be the case, shouldn’t the Body be documented
>> that the Reader may be a ReaderWithLen, and the consumer is free to type
>> check/cast? If not, you are using internal details that you should not be
dar wrote:
>
>> On Wed, Feb 6, 2019 at 7:56 AM Robert Engels wrote:
>>
>> But is it really? If you read the description for Len() on bytes.Buffer it
>> is the length of unread portion. But that doesn’t mean the buffer isn’t just
>> a portion of the entire body - it
The issue with doing it that way is that you are going to encode to json,
decode to object, filter fields, then encode back to json - not very efficient.
You are better to write your own middleware that takes the object response, and
encodes the selected fields, then writes to the ResonseWriter
Just mo wasm is horrible on any platform. Unless you maybe have a large
game engine that you are attempting to integrate.
You have to ask yourself, what are you trying to do? If it is just to avoid the
garbage that is JS, then use an environment that transpiles to JS. You’ll have
better in
> for len(buf) != 0 {
> println(buf[0])
> buf = buf[1:]
> }
>
> On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
>> But is it really? If you read the description for Len() on
>> bytes.Buffer it is the length of unread portion. But that doesn’t
>>
I am also not sure about gopherjs performance if using lots of idiomatic Go
(i.e. go routines). It is very difficult to get good performance when the
underlying platform expects async callbacks, and Go is “blocking”. There is
going to be a lot of stack-unwinding… I am sure somebody has run perfo
maintainable designs.
> On Feb 6, 2019, at 5:05 PM, Burak Serdar wrote:
>
> On Wed, Feb 6, 2019 at 2:50 PM robert engels <mailto:reng...@ix.netcom.com>> wrote:
>>
>> I am not sure what that has to do with the discussion. My point was that for
>> it to be applic
No need to learn JS if you learn Typescript. Straight JS is pretty dead except
for older codebases or trivial applications.
> On Feb 6, 2019, at 5:54 PM, Manlio Perillo wrote:
>
> On Wednesday, February 6, 2019 at 9:07:16 PM UTC+1, Tharaneedharan
> Vilwanathan wrote:
>
> I have one more quest
rs are considered to have an unknown length.
>
> Whether it's wrong to use Len depends on whether there is a generally
> accepted and consistent set of semantics to Len() int. There is. This
> is strengthened if the use of an existing Len method is noted in the
> docs.
>
Is that really true though I am thinking the OP has pointers in global
variables, and the size of the objects pointed to are changing.
The question is not very clear though.
> On Feb 7, 2019, at 12:33 PM, Ian Lance Taylor wrote:
>
> On Thu, Feb 7, 2019 at 2:33 AM Thomas S wrote:
>>
>> But no
types - it would cast to an interface
declaring Len(), and use the interface, and then it would work with any type.
> On Feb 7, 2019, at 1:07 PM, Dan Kortschak wrote:
>
> Yeah, I'm not agreeing with you.
>
> On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
>> Y
ct.
>
> Please show me a Len method in the standard library that does not
> return the number of available-to-access elements in a collection.
>
>
> On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote:
>> I am not following. You stated that the usage of Len was internal and
019, at 2:55 PM, robert engels wrote:
>
> I see the documented use of the types in NewRequest - you are correct - I was
> wrong.
>
> But, it could of easily also declared that if the provided Reader is also a
> Lener, it uses it to determine the content length. Why have this b
gt; An example of this is here https://bitbucket.org/ausocean/iot/pull-requ
> ests/42
>
> On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote:
>> I see the documented use of the types in NewRequest - you are correct
>> - I was wrong.
>>
>> But, it could of easily a
33/
>
> On Thu, 2019-02-07 at 15:33 -0600, robert engels wrote:
>> I agree with you on the correct solution - vs. the OP’s request of
>> the GetWrapped method.
>>
>> I guess I still don’t understand the “zeroed” concern though. If you
>> adhere to the “don
Could be many things, but a few to think about:
If you run more Go routines than you have CPUs available, and the task is CPU
bound (which may be if the url points to a local resource), then you are going
to thrash, causing worse performance.
The service you are calling is not properly concurre
The way Go is designed a panic must terminate the application. Anything else is
so indeterminate to be unusable.
> On Feb 8, 2019, at 8:08 PM, Michael Jones wrote:
>
> Agree to that.
>
> From the original blog post:
>
> The convention in the Go libraries is that even when a package uses pa
; flight.
>
>> On Fri, Feb 8, 2019 at 10:47 PM Robert Engels wrote:
>> The way Go is designed a panic must terminate the application. Anything else
>> is so indeterminate to be unusable.
>>
>>> On Feb 8, 2019, at 8:08 PM, Michael Jones wrote:
>>
that it was a trivial problem with a trivial solution.
> On Feb 9, 2019, at 12:48 AM, Robert Engels wrote:
>
> Sorry, but I disagree, at least in the context of Go, and the difference
> between errors and panics. Imagine any financial service, if the code is
> encountering
It is slightly more advanced that that - since there are multiple OS threads
that the Go routines are multiplexed onto.
The easiest solution is to look at the ‘trace’ code as it records the context
switches.
> On Feb 9, 2019, at 3:34 PM, milis...@gmail.com wrote:
>
> I am looking at fine-grain
ng to service requests - which is far different
in my opinion.
> On Feb 9, 2019, at 4:08 PM, Ian Lance Taylor wrote:
>
> On Fri, Feb 8, 2019 at 7:48 PM Robert Engels wrote:
>>
>> The way Go is designed a panic must terminate the application. Anything else
>> is so inde
it procedure-level
> or call-back level interception?
> I am looking at machine instruction-level interception.
>
> -Milind
>
>
> On Sat, Feb 9, 2019 at 2:17 PM robert engels <mailto:reng...@ix.netcom.com>> wrote:
> It is slightly more advanced that that - since
You also need to look at internal/trace to see how the runtime logs the trace
events related to the Go routines - that will show you where you need to
intercept.
> On Feb 9, 2019, at 4:29 PM, robert engels wrote:
>
> It is runtime/trace/trace.go
>
> It is what is report
As in the blog post I
> excerpted:
>
> https://blog.golang.org/defer-panic-and-recover
> <https://blog.golang.org/defer-panic-and-recover>
>
> On Sat, Feb 9, 2019 at 2:22 PM robert engels <mailto:reng...@ix.netcom.com>> wrote:
> I agree, but in that case t
caller on the thread stack to jump to a
> > different context during a return from a procedure?
>
> Yes, that is the standard idiom for switching goroutines, as seen in
> the gosave, gogo, and mcall functions. Also systemstack arguably
> changes goroutines, though only to the g0
arch for S2_shadow in the metadata and switch to it (analogous to the
> restore sequence in the gogo routine).
>
> -Milind
>
>
>
>
>
>> On Sat, Feb 9, 2019 at 5:39 PM robert engels wrote:
>> Milind,
>>
>> Understood. A few things to think about:
What exactly do you think is wrong with the code? putBufioReader() is called in
several locations to place the reader into the Pool for later retrieval by
newBufioReader() ???
> On Feb 18, 2019, at 8:30 AM, Matija Martinić
> wrote:
>
> Poking around the golang's net/http I came across this th
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
>> wrot
I use VS Code with Go on a Mac at times - usually IntelliJ - and don’t have
that problem. Maybe uninstall, delete the preferences, and re-install. Just a
thought.
> On Feb 21, 2019, at 8:51 PM, Rich wrote:
>
> Just about every video on Go, I see people using VSC, and so was hoping to
> find a
By condition variable I mean sync.Cond
> On Feb 21, 2019, at 3:10 PM, Robert Engels wrote:
>
> 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.
I’m pretty sure this code is incorrect and there will only be a single routine
doing any “real work”, although the comment //do remaining jobs is unclear
because there is no code.
> On Feb 22, 2019, at 12:42 AM, Serhat Şevki Dinçer wrote:
>
> Another use case is wait groups with Max number of
m yourself
> }
>
> // do stuff, increment counter
> }
>
> // do remaining jobs
>
> // make way
> <- ch
> return
> }
>
> 22 Şub 2019 Cum 15:30 tarihinde Robert Engels şunu
> yazdı:
>> I’m pretty sure this code is incorrect and there will on
e counter is zero, Like a WaitGroup.
>
>
> 22 Şub 2019 Cum 15:53 tarihinde Robert Engels şunu
> yazdı:
>> But you can replace waitempty() and related with a simple atomic counter
>> variable and avoid channels for this. Far simpler.
>>
>>> On Feb 22,
With GC off the free will not be called, nor will destructors be executed in
response to finalizers, so many memory corruption errors will not be
experienced (nor detected).
Almost certainly the C memory is not being managed correctly - possibly copying
a pointer between structs and then freein
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 occasionall
I read the issue, and am unclear as to why a plug-in wouldn’t support your use
case?
> On Feb 26, 2019, at 6:19 PM, cos.pip...@gmail.com wrote:
>
> Has this been finally decided or is there still room to save this feature?
>
> We have invested all last year building an SDK (industrial automatio
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 ter
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 part
ase in 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.
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 th
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, mountain
Because the compiler/processor might reorder things, so the value must be
obtained while holding the lock.
This is actually a weakness due to the memory model of Go not being fully
specified IMO. If that were changed this code could probably be written as you
suggest.
> On Mar 1, 2019, at 1:
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, Marvin
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
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 de
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
Any use of sync.Pool is kind of a misuse in my opinion. If you review the code,
it requires unlock/lock to get/put an item - not very cheap, and not great for
highly concurrent situations - best to only use it for objects that are shared
that are very expensive to instantiate, or unshared pools
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 perform
Unclear… revise… “it requires a lock & unlock for every get and put of an item"
> On Mar 6, 2019, at 5:31 PM, robert engels wrote:
>
> Any use of sync.Pool is kind of a misuse in my opinion. If you review the
> code, it requires unlock/lock to get/put an item - not very ch
I wholeheartedly agree and would add an important point, that ease of
development/understanding leads to easier refactoring allowing for improvements
in the algorithm- which are usually far more important to performance - which
is exactly what you’ve demonstrated.
> On Mar 6, 2019, at 9:22 PM,
I reviewed the code and it is still pretty inefficient compared to a local free
list. I don’t think the single local element helps in the binary tree case
anyway, as you are probably releasing branches of the tree at a time. Also, in
the face of high cpu based concurrency/contention, the local
The reason it is hard to do is that Go correctly decided against this callback
type code - it creates callback hell. Concurrency is cheap in Go, it is
designed to use CSP or blocking procedural techniques - both far easier to
maintain than callback focused systems.
> On Mar 8, 2019, at 7:19 AM
losure where the thread of execution jumps out of the
> closure and out of the function that calls it. See this article that explains
> it well.
>
> Am Freitag, 8. März 2019 14:34:13 UTC+1 schrieb Robert Engels:
>>
>> The reason it is hard to do is that Go correctly de
I did. No good use for them. People that use them probably also think
exceptions for flow control is a good idea.
> On Mar 8, 2019, at 8:24 AM, Ian Lance Taylor wrote:
>
> On Fri, Mar 8, 2019 at 5:02 AM whitehexagon via golang-nuts
> wrote:
>>
>> I'm really liking in Go that I can easily pas
The other package is closing stdin
> On Mar 8, 2019, at 2:43 PM, Everton Marques wrote:
>
> I am debugging an issue that randomly makes the code below to hit io.EOF
> instead of reporting first byte 'u' from "ugh":
>
> $ echo "ugh" | eraseme ;# this randomly reports EOF instead of first by
True, that is probably more likely, but it is EOF because it consumed the
data...
> On Mar 8, 2019, at 3:17 PM, Kurtis Rader wrote:
>
>> On Fri, Mar 8, 2019 at 1:01 PM Robert Engels wrote:
>
>> The other package is closing stdin
>
> Or consuming the stdin data
I think you are confusing screenshots and copy and paste as html. The latter
works with screen readers and still gives colored text because most likely the
person is using an IDE.
> On Mar 11, 2019, at 7:21 AM, Wojciech S. Czarnecki wrote:
>
> On Mon, 11 Mar 2019 07:39:40 -0400
> Sameer Ajman
You need to reuse the client http transport or you will run out of connections
at the os level due to them being in a closed wait state.
> On Mar 11, 2019, at 4:56 AM, Javier wrote:
>
> Hi
>
> I am load testing a simple application that calls an echo service with a GET.
> My application is te
That’s not exactly what I meant. I meant that copy and pasting from an IDE will
often result in colored formatted text like looks like a screenshot but it is
not, and a screen reader should have no problem with it.
> On Mar 11, 2019, at 12:49 PM, Ian Denhardt wrote:
>
> Quoting Robe
There is also github.com/robaho/keydb which uses LSM and transactions and it is
very fast :)
> On Mar 12, 2019, at 1:10 AM, xujiajun wrote:
>
> Hi, guys. i share you a key/value store named NutsDB.
>
> NutsDB is a simple, fast, embeddable and persistent key/value store written
> in pure Go.
>
I did just encounter a case though where trying to copy and paste a table
wasn’t happening, and there is no way I am going to type it all in or get the
author to change it, so screen shot it is... I understand the problem, but
calling people lazy just isn’t correct in many cases.
> On Mar 12,
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 means that if one has started oth
Without reading too deeply, and only judging based on your statements, it seems
you are confusing implementation with specification. The things you cite are
subject to change. You need to reason based on the specification not the
observed behavior. Then use the observed behavior to argue that it
Then use a mutex or atomic spin lock (although that may have issues in the
current Go implementation)
> On Mar 17, 2019, at 3:56 PM, Louki Sumirniy
> wrote:
>
> I am pretty sure the main cause of deadlocks not having senders and receivers
> in pairs in the execution path such that senders pre
protobuf is not designed to match up to existing binary formats. It is a
specification that allows protobuf implementations to read/write messages in a
cross platform way. Things like “text” protobuf are human readable.
> On Mar 18, 2019, at 12:42 PM, Burak Serdar wrote:
>
>> On Mon, Mar 18,
I think nameof is a compile time operation (constant generation) not runtime.
I’ve never used it but the ops request seems reasonable.
Go 2.0 proposal I guess.
> On Mar 19, 2019, at 7:53 AM, Ian Lance Taylor wrote:
>
>> On Tue, Mar 19, 2019 at 5:19 AM saurabh singh wrote:
>>
>> Is there a
The update statement is fine as long as any data sources participate in an XA
transaction.
This is bar the simplest solution but may not meet performance constraints
which is why people use other techniques.
> On Mar 20, 2019, at 4:13 PM, David Collier-Brown wrote:
>
>
>
>
>
> 4:12 PM
Are you making any calls modifying the len that would allow GC to occur, or
change stack size? You might need to pin the Go routine so that the operation
you are performing is “atomic” with respect to those.
This also sounds very scary if the Go runtime every had a compacting collector.
> On
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: golang-nut
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
le.So my question 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
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).
>
> 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 built
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
> with
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
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 fl
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
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 source
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-nuts]
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 b
401 - 500 of 1767 matches
Mail list logo
