Thanks for responding. I will dig deeper about kernel contention later.
在 2020年5月10日星期日 UTC+8上午6:54:30，Ian Lance Taylor写道：
>
> On Sat, May 9, 2020 at 8:32 AM Cholerae Hu > wrote:
> >
> > I'm maintaining a highly-loaded proxy-like service, which serves huge
> amount of small rpc requests every
Looks like a wonderful challenge,
--
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 view this discussion on the web vi
Using ("15 2 * * ?") this exp it works properly for me.
Thanks
On Sat, May 9, 2020 at 1:42 PM Vikram Ingawale wrote:
>
> Thanks for your help.
>
> I am using go 1.14.0
>
> Ok I’m updates it to 1.14.2 and then checking Tonight
>
> On Sat, 9 May 2020 at 1:01 PM, Brian Candler wrote:
>
>> I le
https://github.com/anthonynsimon/bild has parallel image ops of all sorts and
is widely used & well supported.
- Randy
> On May 10, 2020, at 9:52 PM, robert engels wrote:
>
> I don’t know and I doubt anyone else does off the top of their head, so why
> don’t you write a test and see?
>
> Ima
I don’t know and I doubt anyone else does off the top of their head, so why
don’t you write a test and see?
Image processing is highly image and usage dependent, e.g. acceptable quality
vs. speed vs. memory.
Using non-quantifiable terms like “huge” is not testable nor verifiable.
> On May 10,
If you want to get some experience with Go - please reimplement Geeknote
https://github.com/jeffkowalski/geeknote - currently written in Python 2.
Currently I have no time for that. I think that this is simple,
interesting, useful project. And I will use it :)
On Saturday, May 9, 2020 at 8:57:23
How does it compare to vipsthumbnail that utilize low memory usage which I
believe it use horizontal threading, does Go's image/draw package consume
large memory if the image source is huge?
On Monday, 11 May 2020 07:00:11 UTC+8, Nigel Tao wrote:
>
> On Mon, May 11, 2020 at 4:28 AM robert enge
On Wednesday, June 5, 2019 at 10:14:22 AM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Jun 5, 2019 at 12:10 AM Kurtis Rader > wrote:
> >
> > On Tue, Jun 4, 2019 at 11:53 PM Inada Naoki > wrote:
> >>
> >> conn.SetReadDeadline(time.Now())
> >
> >
> > Did you test that solution? Setting a dea
My bad, I didn’t read the API docs completely. Kind of a strange interface
declaration in the stdlib image package - that there is only a single rectangle
for Draw() and it is bounded by the two images.
> On May 10, 2020, at 5:57 PM, Nigel Tao wrote:
>
> On Mon, May 11, 2020 at 4:28 AM robert
On Mon, May 11, 2020 at 4:28 AM robert engels wrote:
> All of the code to do scaling and cropping in the ‘image’ package in the
> stdlib.
Cropping is in the stdlib but scaling is not. Various scaling
algorithms (e.g. nearest neighbor, Catmull-Rom) are in the
golang.org/x/image/draw package inste
All of the code to do scaling and cropping in the ‘image’ package in the
stdlib. You ‘draw’ into a new image to do scaling. You use SubImage() to
perform cropping. See https://blog.golang.org/image-draw
Alternatively, if you need more advanced scaling operations it would be fairly
trivial to po
I have an extremely elaborate resizing library, but it is so complex it
would not make sense as a standard tool for common uses. (Many convolution
kernels, separate windows, forward and backward mapping, separable
convolutions, upsampling first for Nyquist issues, strategy phase and then
concurrent
How do you advice to resize and crop JPEG and PNG or probably WebP images
without rely on 3rd parties dependencies?
It was hard to find a good snippet or could be useful to have basic API
function in Go standard library since it's a common feature.
--
You received this message because you are
It is fixed now!
On Sunday, May 10, 2020 at 2:59:16 PM UTC+5:30, Jan Mercl wrote:
>
> On Sun, May 10, 2020 at 11:22 AM Sebastien Binet > wrote:
>
> > It seems like gitlab is going through some maintenance work (I get a 503
> when trying to reach the files of the packages you labeled as working)
Hi,
is there a plan to be able to use ?import-graph on pkg.go.dev similar
to godoc.org in the future?
(Sorry if I missed any announcement about this.)
thanks,
Gergely Fodemesi
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from t
On Sun, May 10, 2020 at 11:22 AM Sebastien Binet wrote:
> It seems like gitlab is going through some maintenance work (I get a 503 when
> trying to reach the files of the packages you labeled as working).
> Perhaps it's just that (and some caching effect)?
Ah, you're right, now I'm getting a 50
It seems like gitlab is going through some maintenance work (I get a 503
when trying to reach the files of the packages you labeled as working).
Perhaps it's just that (and some caching effect)?
sent from my droid
On Sun, May 10, 2020, 11:11 Jan Mercl <0xj...@gmail.com> wrote:
> It came to my at
It came to my attention that some of my packages are not accessible at
godoc.org at the time of this writing (09:05 UTC).
A sample of URLs that report "Not Found":
https://godoc.org/modernc.org/strutil
https://godoc.org/modernc.org/mathutil
https://godoc.org/modernc.org/cc
https://godoc.org/moder
18 matches
Mail list logo
