Profiling shows ~150_000 CS for channel version. For some reason I thought
scheduling should be done by Go runtime, but it is not.
Anyway you are right, I will look closer into syscall part, may be I will
get rid of netlink library, or something..
On Monday, February 4, 2019 at 6:59:33 PM UT
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 Reader, not a Buffer - the length of the request/body may be
> indeterminate - that is, a stream. Attempting to get the length of an
> underlying buffer is
FWIW, John Rohrlich came up with “ThingByNameTry” and we’re going with that —
seems perfect to me in terms of semantics, brevity, etc.. Also, having the
extra “Try” modifier at the end is good so both methods show up together in
alpha-sorted docs lists etc. Cheers,
- Randy
> On Feb 3, 2019, a
That's funny. I was kinda hoped that my idea kinda got added into Go2. I
can understand why they didn't got embedded but the idea was kinda novel.
And maybe it will bring people into minds.
On Wednesday, February 6, 2019 at 3:55:47 AM UTC+1, Bakul Shah wrote:
>
> I hope bignums will be added to
Hi, all.
LiteIDE x35.5 release, this is bug fix version.
* LiteIDE Home
http://liteide.org
* LiteIDE Source code
https://github.com/visualfc/liteide
* Release downloads
https://github.com/visualfc/liteide/releases/latest
https://sourceforge.net/projects/liteide/files
That’s what I was trying to point out. Your design is not correct. The Body is
a Reader, not a Buffer - the length of the request/body may be indeterminate -
that is, a stream. Attempting to get the length of an underlying buffer is not
only probably not possible, but not correct in many situati
On Tue, Feb 5, 2019 at 7:00 PM Robert Engels wrote:
>
> 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.
True. What I was suggesting is a fix for the general case.
>
> > On Feb 5, 2019, at 6:53 PM, Burak
I hope bignums will be added to Go2 as a builtin type!
--
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.
For more options,
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
cray was optimized for throughput, after all ;)
--
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.
For more options, visit
On Tue, Feb 5, 2019 at 5:18 PM Dan Kortschak wrote:
>
> Personally, I think this is a bug in the behaviour of NewRequest. See h
> ttps://github.com/golang/go/issues/18117 for some additional context.
Agreed. One solution could be to have:
type HasLen interface {
int Len()
}
Then have NopClos
% ivy
*/iota 1000
40238726007709377354370243392300398571937486421071463254379991042993851239862902059204420848696940480047998861019719605863166687299480855890132382966994459099742450408707375991882362772718873251977950595099527612087497546249704360141827809464649629105639388743788648733711918104582
The well known IPv4 addresses defined in ip.go do not include an entry for
the loopback address but the IPv6 addresses does have this entry. I propose
that IPv4loopback with a value of IPv4(127, 0, 0, 1) be added to ip.go.
This is not a big issue but it looks inconsistent as it stands.
--
You
Personally, I think this is a bug in the behaviour of NewRequest. See h
ttps://github.com/golang/go/issues/18117 for some additional context.
On Tue, 2019-02-05 at 05:18 -0800, matteo.biage...@gmail.com wrote:
> I've the following situation:
> I proxy a request to another server and when I made a
FYI, the last item in his thesis is computing multi-precision factorial on
the Cray.
All digits of 1000! can be computed in 28ms on the Cray Y_MP:
1000! = 40238726007709377354370243392300398571937486421071463254379991
04299385123986290205920442084869694048004799886101971960586316668729
9480855890
Oberon inspired a number of languages.
For instance, Limbo's GC also collects files, and modules are just objects
you assign to when importing them, and are collected when no longer
referenced.
-rob
On Wed, Feb 6, 2019 at 10:06 AM Michael Jones
wrote:
> ha ha! yes indeed. i was counting inter
ha ha! yes indeed. i was counting intermediaries, so off by one. wirth was
on robert's thesis committee. (A Programming Language for Vector Computers,
his auto vectorizing Oberon subset for the Cray-YMP.)
On Tue, Feb 5, 2019 at 10:55 AM Jan Mercl <0xj...@gmail.com> wrote:
> Just an of-by-one erro
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 design problem. It breaks all sort
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 design problem. It breaks all sorts of ‘isa’
> semantics.
This happens if you're using multiple layers of libraries that don't
know a
If the error doesn’t know what it is wrapping but the caller needs to know the
wrapped error you have a design problem. It breaks all sorts of ‘isa’
semantics.
If you need to know the internal buffer length, you have a design problem. What
if the wrapped buffer was unlimited or dynamic - there
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 logging, then the
> higher leve
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 logging, then the higher
level error should be able to represent the additional detail when i
Just an of-by-one error. After all, Michael is also a programmer ;-)
On Tue, Feb 5, 2019, 19:51 Dan Kortschak wrote:
> Robert Griesamer *is* Niklaus Wirth?
>
> On Tue, 2019-02-05 at 09:19 -0800, Michael Jones wrote:
> > Go learns from Oberon via Go and Oberon insider Robert Griesemer,
> > whose
Robert Griesamer *is* Niklaus Wirth?
On Tue, 2019-02-05 at 09:19 -0800, Michael Jones wrote:
> Go learns from Oberon via Go and Oberon insider Robert Griesemer,
> whose
> Wirth-number is zero.
>
> On Tue, Feb 5, 2019 at 3:47 AM Gerard wrote:
>
> >
> > Hello everyone. There has been one issue i
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 always a better way then GetNested,
> GetWrapped, or any of its derivatives.
How so? How would you deal with something l
On Tue, Feb 5, 2019 at 11:20 AM Robert Engels wrote:
>
> Then you want inheritance not encapsulation.
No, this is done at runtime, not at compile time.
>
> > On Feb 5, 2019, at 10:46 AM, Burak Serdar wrote:
> >
> >> On Tue, Feb 5, 2019 at 9:41 AM Robert Engels wrote:
> >>
> >> GetNested anythi
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 encapsulation.
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 almost always encapsulation and th
On Tue, Feb 5, 2019 at 8:12 AM Sadegh Nikaein wrote:
>
> Is it better add some option on online src to hide all document on source
> code ?
Why?
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop recei
Go learns from Oberon via Go and Oberon insider Robert Griesemer, whose
Wirth-number is zero.
On Tue, Feb 5, 2019 at 3:47 AM Gerard wrote:
> Hello everyone. There has been one issue in Go that has never gotten out
> of my head, so it went on and on. The problem is modules.
>
> In the beginning t
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 almost always encapsulation and then you are breaking it.
That's too much of a generalization in my opinion. This is more like
decoration, add
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
On Tue, Feb 5, 2019 at 9:12 AM wrote:
>
> I've the following situation:
> I proxy a request to another server and when I made a POST and create a new
> request, the contentLength is zero:
>
> req2, _ := http.NewRequest(req.Method, newApiUrl , req.Body)
> fmt.Println("New request f
Hello gophers .
Is it better add some option on online src to hide all document on source
code ?
--
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+u
I've the following situation:
I proxy a request to another server and when I made a POST and create a new
request, the contentLength is zero:
req2, _ := http.NewRequest(req.Method, newApiUrl , req.Body)
fmt.Println("New request from body:", req2.ContentLength) // print 0
Checkin
Hello everyone. There has been one issue in Go that has never gotten out of
my head, so it went on and on. The problem is modules.
In the beginning there was Oberon. Let's just face it. Oberon was a
brilliant designed piece of engineering. Oberon did have some marvelous
features that just don't
On Mon, 4 Feb 2019 00:13:39 +0530
Milind Thombre wrote:
> ask "Exactly how fast is golang vs say Python/JS?" or even C
It depends on domain, metrics and task at hand, but from personal experience
(Go vs C) Go is about four times faster than C at prototyping phase, two times
faster at doing main
On Mon, 4 Feb 2019 14:04:46 -0600
robert engels wrote:
> Yes?
Looks like a CATKE case (Cat AT KEyboard ;)
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
38 matches
Mail list logo
