Re: [go-nuts] Re: Go’s runtime vs virtual machine
This is awesome, thank you all very much for the background information and great examples that you've provided. I think it is quite clear now what the difference is between these two runtimes. Cheers, Pablo On Thursday, September 6, 2018 at 3:16:59 AM UTC+10, Michael Jones wrote: > > These are all great! If Pablo gets these points across to students, they > will be well-informed. > > There is an interesting parallel to human languages. When I was a boy my > father told me "you don't know a word if you can't define it." Sometimes > people are comfortable with words they understand generally but could not > define precisely; that's a false comfort. This thread gives all of us the > chance to think how to define terms, how to be clear so as to avoid > confusion on the part of others. It is a rewarding exercise for ourselves > too. > > On Wed, Sep 5, 2018 at 7:55 AM K Davidson > > wrote: > >> Please give my seemingly redundant post. I got stiffled by the moderation >> process, and by the time my post was approved, others had said pretty much >> everything I had. >> >> -- >> 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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > > *Michael T. jonesmichae...@gmail.com * > -- 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 https://groups.google.com/d/optout.
[go-nuts] Re: Go’s runtime vs virtual machine
Thanks for the answers. I asked this question because I'm preparing some tutorials to explain Go to students and I'm thinking about potential questions and discussions. If I understand it correctly we could say then that Go's runtime has things in common with a VM's runtime (I'm thinking mostly in Java's) such as GC, goroutine (thread) scheduling, etc. However, Go's runtime cannot be considered a VM because it does not compile code to an intermediate language, it executes compiled native code instead. Cheers, Pablo On Wednesday, September 5, 2018 at 3:01:52 AM UTC+10, Jake Montgomery wrote: > > There are a lot of differences, and for the answer to be complete, you > would need to specify which language you wanted to compare it to. But on a > really simple level, thwd's answer is more or less correct. A VM language > is usually compiled into an instruction set for that VM. The VM then > provides a lot of "special sauce." Go is (usually) compiled directly into > machine code to be executed directly on the target system. > > One consequence of this is that the executable can be run without having > any other software installed on the machine. It also means that the code > for the stuff you inquired about such as the garbage collector, goroutine > scheduling and stack management, is all present in the single executable > compiled by go. > > As for learning more, it depends somewhat on what your experience level > is, and why you want to know. If you are relatively new to programming, I > would recommend just using go for a while, without worrying too much about > the "magic." If you have a strong background already, you could start > learning about the stuff you mentioned. Garbage collection would be an > interesting place to start. I don't know of any one resource, but there are > a number of interesting videos (gophercon, ect) by principal architects on > the subject. Keep in mind that all these things are constantly evolving, so > any information you get may not apply to the latest version of the > language. > > Good luck. > > > > On Tuesday, September 4, 2018 at 10:50:03 AM UTC-4, thwd wrote: >> >> A virtual machine has its own instruction set. Go compiles to machine >> code for a given target (which could be a virtual machine). >> >> On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas Larraondo >> wrote: >>> >>> The Go documentation provides some explanation about the difference >>> between Go’s runtime and a virtual machine here: >>> >>> https://golang.org/doc/faq#runtime >>> >>> Does anyone can recommend a good place to learn more about this? I’d >>> like to better understand how Go’s garbage collector, goroutine scheduling >>> and stack management are handled by the runtime and how it is different >>> from a virtual machine. >>> >>> Thanks, >>> Pablo >>> >>> -- 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 https://groups.google.com/d/optout.
[go-nuts] Re: Licensing terms when using Go code
Thanks Ian, that is very helpful. I've also googled for reusing BSD software and, as you said, there is plenty of information. On Wednesday, May 2, 2018 at 7:04:34 PM UTC+10, Pablo Rozas Larraondo wrote: > > Hi gophers, > > I have created a new library reusing some code from the Go standard > library. I want to make this project open source and I would like to know > if there are requirements in terms of the license for this software. > > Should I use the same Go BSD license, use BSD without mentioning the Go > team or could I change license to something such as Apache 2? > > Thank you very much for your help, > Pablo > -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] Licensing terms when using Go code
Thank you Lutz, then, if I understand this right, new projects containing
parts of Go code have to include the original Go BSD license.
There are a couple of aspects that remain unclear to me:
- The copyright notice, list of conditions and disclaimer have to be
included in every file of the project, or just the ones that contain
snippets of Go code?
- How the new authors are acknowledged? Would something like "Copyright (c)
2009 The Go and project X Authors." be appropriate? Or is it
better/possible to add a second Copyright notice?
We want to release a new open source project but licensing aspects are
totally new for us. Any help or references to similar cases that we can
learn from, would be really helpful.
Thanks,
Pablo
On Wednesday, May 2, 2018 at 7:10:44 PM UTC+10, Lutz Horn wrote:
>
> Go is BSD licensed (https://golang.org/LICENSE). This is an easy license:
>
> > Copyright (c) 2009 The Go Authors. All rights reserved.
> >
> > Redistribution and use in source and binary forms, with or
> withoutmodification, are permitted provided that the following
> conditions are met:
> >
> > * Redistributions of source code must retain the above copyright notice,
> this list of conditions and the following disclaimer.
>
> So you must retain the copyright notice ("Copyright (c) 2009 The Go
> Authors.") and the disclaimer. You can then license your code any way you
> like.
>
> Lutz
>
>
--
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 https://groups.google.com/d/optout.
[go-nuts] Licensing terms when using Go code
Hi gophers, I have created a new library reusing some code from the Go standard library. I want to make this project open source and I would like to know if there are requirements in terms of the license for this software. Should I use the same Go BSD license, use BSD without mentioning the Go team or could I change license to something such as Apache 2? Thank you very much for your help, Pablo -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] NOSPLIT on Go assembler defined functions
Thank you very much Ian, I didn't notice the imported headers file in the examples I was looking at. My code is compiling perfectly fine after I added that line. Cheers, Pablo On Tue, Feb 27, 2018 at 8:46 AM, Ian Lance Taylor <i...@golang.org> wrote: > On Sun, Feb 25, 2018 at 11:27 PM, Pablo Rozas Larraondo > <p.rozas.larrao...@gmail.com> wrote: > > > > I started learning about Go assembler and I'm having problems with the > > NOSPLIT symbol, which makes the compilation fail with error message: > > "illegal or missing addressing mode for symbol NOSPLIT" > > > > I've found a blog post which describes the same problem and proposes > > removing the symbol in order to compile it: > > https://www.manniwood.com/2016_07_03/fun_with_go_assembler.html > > > > Apart from this reference, I cannot find more information on this problem > > and I would like to understand when NOSPLIT has to be used. > > What, precisely, did you do? > > In order to use NOSPLIT, you must #include "textflag.h". Then you can > use NOSPLIT as a function flag to indicate that the function should > not have a stack split preamble. There are many examples in > runtime/*.s in the standard library. > > Ian > -- 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 https://groups.google.com/d/optout.
[go-nuts] NOSPLIT on Go assembler defined functions
Hi, I started learning about Go assembler and I'm having problems with the NOSPLIT symbol, which makes the compilation fail with error message: "illegal or missing addressing mode for symbol NOSPLIT" I've found a blog post which describes the same problem and proposes removing the symbol in order to compile it: https://www.manniwood.com/2016_07_03/fun_with_go_assembler.html Apart from this reference, I cannot find more information on this problem and I would like to understand when NOSPLIT has to be used. Thank you, Pablo -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] Re: [ANN] A blog post series on serving big satellite imagery with Go
This new part of the series focuses on the use of fast compressors such as Snappy to improve access speed to image data: https://medium.com/@p.rozas.larraondo/divide-compress-and-conquer-building-an-earth-data-server-in-go-part-2-88670cafc167 IMO fast compressors will play a very important role in the design of high performance systems - as a method to overcome RAM speed limitations on CPUs. Feedback, comments and experiences from the community are highly appreciated! Pablo On Thu, Dec 21, 2017 at 2:04 AM, Michael Jones <michael.jo...@gmail.com> wrote: > Certainly as you say, individual user patterns are not generally > predictable. Sometimes aggregate patterns can be. The "sea of tiles" is the > natural design and works great in normal cases. It seems the way to teach > it in any case. > > Where the filesystem issue comes in would be, for example, the nominal 1 > meter per pixel Google Earth, which in plate carrée or like form with > 400x400 pixel tiles consists of 253,701,184 tiles at that one ground sample > distance. That is a lot for "ls" and a lot for most file systems to enjoy > quickly accessing in a single directory. A pyramidal reduced resolution > dataset hierarchy will require 4/3rds of this in total, or 338,268,246 > tiles. Finer details, such as 50cm advanced satellite and 10cm aerial/drone > images scale the portions covered by 4x to 100x. So in the limit one will > find the edge of what any OS designer expects "sane" developers to expect. > :-) > > On Wed, Dec 20, 2017 at 3:33 PM, Pablo Rozas Larraondo < > p.rozas.larrao...@gmail.com> wrote: > >> Hi Michael, >> >> Thanks for your comments, I totally agree with them. File systems will >> struggle with the explosion of files resulting from the tile operation. As >> you point out, other formats, such as geoTIFF, HDF5 or NetCDF define the >> tiling or chunking process internally at the file level. >> >> The reason for creating the tiles as individual files in the article was >> because this is ultimately intended to be stored on the cloud as objects >> (this will be covered in the 3rd article). As far as I know, cloud object >> stores (ie AWS S3, Google Cloud Storage) do not have a limitation in the >> number of objects stored in a bucket (If someone has more information about >> this, please share). That is why I proposed to split the tiles as separate >> files in the article. >> >> I also find the caching considerations quite amusing. It is a complex >> matter and, in my experience, cache optimisations are quite dependent on >> the user access patterns, which are normally hard to predict. >> >> Cheers, >> Pablo >> >> >> >> On Wednesday, December 20, 2017 at 2:24:01 AM UTC+1, Michael Jones wrote: >>> >>> Thank you, Pablo. Very helpful to have this kind of step by step example >>> for Go developers. >>> >>> I have some familiarity in this area and I'd say the practical issues in >>> large-scale, high-throughput operation tend to relate to the native >>> filesystem. Too many small files overwhelm them and can make directory >>> lookups slow. Too many directory levels leads to slow filesystem traversal. >>> Sometimes it can help to dice the big image into small independent tiles >>> and store those tiles as a mosaic in one's own file type. This is the >>> nature of TILED vs ROW storage in the TIFF format. The next level of tuning >>> is about leverage the operating system's cache of data read from disk in a >>> productive way. You can have our own cache in RAM, of course, but the OS >>> likely has that same data cached. There are cases where memory mapping the >>> small tile files does what you would want. >>> >>> There are also dynamic considerations. It may well be that a client >>> accessing tile [i][j] will soon want one of the eight surrounding tiles. >>> over time, it may be that a direction of browsing through tile-space can be >>> established and this can encourage read-ahead, though the benefit is not >>> always assured; maybe the accesses are structured and maybe they are not. >>> >>> Some high-throughput servers in the era of smart web clients (aka Google >>> Maps / leaflet ./ etc.) refuse to build custom images and only supply tiles >>> in response to a request--leaving tile assembly to the client. >>> >>> Just some thoughts. None of them would help make what you've done any >>> clearer or more helpful to the reader. >>> >>> Best, >>> Michael >>> >>> >>> On Tue, Dec 19, 2017 at 3:37
Re: [go-nuts] Re: [ANN] A blog post series on serving big satellite imagery with Go
Hi Michael, Thanks for your comments, I totally agree with them. File systems will struggle with the explosion of files resulting from the tile operation. As you point out, other formats, such as geoTIFF, HDF5 or NetCDF define the tiling or chunking process internally at the file level. The reason for creating the tiles as individual files in the article was because this is ultimately intended to be stored on the cloud as objects (this will be covered in the 3rd article). As far as I know, cloud object stores (ie AWS S3, Google Cloud Storage) do not have a limitation in the number of objects stored in a bucket (If someone has more information about this, please share). That is why I proposed to split the tiles as separate files in the article. I also find the caching considerations quite amusing. It is a complex matter and, in my experience, cache optimisations are quite dependent on the user access patterns, which are normally hard to predict. Cheers, Pablo On Wednesday, December 20, 2017 at 2:24:01 AM UTC+1, Michael Jones wrote: > > Thank you, Pablo. Very helpful to have this kind of step by step example > for Go developers. > > I have some familiarity in this area and I'd say the practical issues in > large-scale, high-throughput operation tend to relate to the native > filesystem. Too many small files overwhelm them and can make directory > lookups slow. Too many directory levels leads to slow filesystem traversal. > Sometimes it can help to dice the big image into small independent tiles > and store those tiles as a mosaic in one's own file type. This is the > nature of TILED vs ROW storage in the TIFF format. The next level of tuning > is about leverage the operating system's cache of data read from disk in a > productive way. You can have our own cache in RAM, of course, but the OS > likely has that same data cached. There are cases where memory mapping the > small tile files does what you would want. > > There are also dynamic considerations. It may well be that a client > accessing tile [i][j] will soon want one of the eight surrounding tiles. > over time, it may be that a direction of browsing through tile-space can be > established and this can encourage read-ahead, though the benefit is not > always assured; maybe the accesses are structured and maybe they are not. > > Some high-throughput servers in the era of smart web clients (aka Google > Maps / leaflet ./ etc.) refuse to build custom images and only supply tiles > in response to a request--leaving tile assembly to the client. > > Just some thoughts. None of them would help make what you've done any > clearer or more helpful to the reader. > > Best, > Michael > > > On Tue, Dec 19, 2017 at 3:37 PM, Pablo Rozas Larraondo < > p.rozas@gmail.com > wrote: > >> Thank you Thomas for the link to the vips library. I didn't know about it >> and now I want to read more about its design and internals. >> >> The objective of the article was to set a baseline using the Go image >> library and play with several factors to see how it affects performance. In >> this first article, I wasn't really trying to come up with the fastest >> possible image server but to point a few basic techniques that can improve >> access speed and reduce memory consumption. These techniques should be >> applicable to any image library, so similar relative performance gains can >> be achieved with any language or library. >> >> The next part, which I'm currently writing, proposes the snappy >> compression as a way of improving access speed to the data. >> >> Cheers, >> Pablo >> >> On Tuesday, December 19, 2017 at 10:28:48 AM UTC+1, Thomas Bruyelle wrote: >>> >>> Interesting and nice pieces of code. I wonder if the performances can be >>> compared to something like `vips` (https://jcupitt.github.io/libvips). >>> >>> Le lundi 18 décembre 2017 22:51:49 UTC+1, Pablo Rozas Larraondo a écrit : >>>> >>>> Hi, >>>> >>>> For those interested on serving or using satellite imagery, I've just >>>> published the first of a three part series on this subject using Go: >>>> >>>> >>>> https://medium.com/@p.rozas.larraondo/divide-compress-and-conquer-building-an-earth-data-server-in-go-part-1-d82eee2eceb1 >>>> >>>> Any feedback or comment that you might have would be greatly >>>> appreciated! >>>> >>>> Thanks, >>>> Pablo >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe
[go-nuts] Re: [ANN] A blog post series on serving big satellite imagery with Go
Thank you Thomas for the link to the vips library. I didn't know about it and now I want to read more about its design and internals. The objective of the article was to set a baseline using the Go image library and play with several factors to see how it affects performance. In this first article, I wasn't really trying to come up with the fastest possible image server but to point a few basic techniques that can improve access speed and reduce memory consumption. These techniques should be applicable to any image library, so similar relative performance gains can be achieved with any language or library. The next part, which I'm currently writing, proposes the snappy compression as a way of improving access speed to the data. Cheers, Pablo On Tuesday, December 19, 2017 at 10:28:48 AM UTC+1, Thomas Bruyelle wrote: > > Interesting and nice pieces of code. I wonder if the performances can be > compared to something like `vips` (https://jcupitt.github.io/libvips). > > Le lundi 18 décembre 2017 22:51:49 UTC+1, Pablo Rozas Larraondo a écrit : >> >> Hi, >> >> For those interested on serving or using satellite imagery, I've just >> published the first of a three part series on this subject using Go: >> >> >> https://medium.com/@p.rozas.larraondo/divide-compress-and-conquer-building-an-earth-data-server-in-go-part-1-d82eee2eceb1 >> >> Any feedback or comment that you might have would be greatly appreciated! >> >> Thanks, >> Pablo >> > -- 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 https://groups.google.com/d/optout.
[go-nuts] [ANN] A blog post series on serving big satellite imagery with Go
Hi, For those interested on serving or using satellite imagery, I've just published the first of a three part series on this subject using Go: https://medium.com/@p.rozas.larraondo/divide-compress-and-conquer-building-an-earth-data-server-in-go-part-1-d82eee2eceb1 Any feedback or comment that you might have would be greatly appreciated! Thanks, Pablo -- 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 https://groups.google.com/d/optout.
[go-nuts] Inconsistency in gofmt
Hello, I'm curious to know if this is intended: https://play.golang.org/p/t353t8ZvL1 Line 9 is formatted with spaces but line 10 has no spaces. It seems like adding +1 to the expression changes the behaviour of "gofmt". Wouldn't it be simpler for "gofmt" to always add spaces between the operators? Maybe someone knows the reason for this. Cheers, Pablo -- 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 https://groups.google.com/d/optout.
[go-nuts] Re: [ANN] gopig
Thanks for sharing. You might be interested in this nice implementation of the same game implemented by the Go team a few years ago. It contains a great demonstration of hoe to solve this problem elegantly using functions as returned values: https://golang.org/doc%2Fcodewalk%2Fpig.go Cheers, Pablo On Monday, October 16, 2017 at 8:37:20 AM UTC+11, bnix...@gmail.com wrote: > > Here's an implementation of the "pig" dice game that I wrote in go to > learn the language. Nothing exciting, but I thought others who are just > starting might be interested. > > https://github.com/bnixon67/gopig > > > -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] Understanding least significant byte operation
Thanks Matt. That's a very good explanation about the internal bit
representation of integers and answers perfectly my question. I really
appreciate your help in understanding these operations.
Cheers,
Pablo
On Wed, Jul 26, 2017 at 2:07 PM, Pablo Rozas Larraondo <
p.rozas.larrao...@gmail.com> wrote:
> Thanks Bakul, I also understand now what Matt Harden was referring to with
> his comment. At a bit level both operations cause the same effect on the
> underlying bits of the variable but it's meaning changes depending on the
> type. All clear!
>
> Cheers,
> Pablo
>
> On Wed, Jul 26, 2017 at 1:51 PM, Bakul Shah <ba...@bitblocks.com> wrote:
>
>> [Sorry, didn't see your original response]
>>
>> In the Go *language* (not just the compiler), when x is an unsigned int,
>> -x is treated as a "shorthand" for ^x+1. Another interpretation is that for
>> finite ints all arithmetic operations are modulo the word size. Thus -1
>> modulo 2^64 is 0x. You might even say that a 2's complement
>> machine's native int type is an unsigned int! It is just that most
>> arithmetic operations set relevant condition codes (or equivalent) that
>> allows you (and the compiler) to interpret an int as a signed int or an
>> unsigned one.
>>
>> I would suggest reading up on how computers do arithmetic. Programming
>> languages are merely syntactic sugar on top of processor instruction sets
>> :-)
>>
>> On Jul 25, 2017, at 8:16 PM, Pablo Rozas Larraondo <
>> p.rozas.larrao...@gmail.com> wrote:
>>
>> Ok, I might be understanding this differently then:
>>
>> The -1 * x operation cannot be defined for unsigned integers as -1
>> overflows. Therefore, -x in the case of unsigned types is interpreted
>> differently by the compiler, resulting in a ^x + 1 operation. Is that a
>> correct assumption?
>>
>> By the way, yes, the title should say Bit instead of Byte, sorry about
>> the confusion.
>>
>> On Wed, Jul 26, 2017 at 11:35 AM, Matt Harden <matt.har...@gmail.com>
>> wrote:
>>
>>> Both statements are true for both signed and unsigned integers.
>>>
>>> On Mon, Jul 24, 2017, 04:11 Pablo Rozas Larraondo <
>>> p.rozas.larrao...@gmail.com> wrote:
>>>
>>>> Thanks Bakul, I think I have a better understanding of what's going on
>>>> after reading your response.
>>>>
>>>> Is it correct to say that the Go compiler treats the prepended minus
>>>> sign differently depending on the variable being a signed or an unsigned
>>>> integer?
>>>>
>>>> By looking at this example: https://play.golang.org/p/feqQsuPkqk
>>>>
>>>> It seems to me that in the case of an unsigned integer it's treated as
>>>> a bitwise operation : -x == ^x + 1
>>>> But for signed integers -x == -1 * x
>>>>
>>>> Cheers,
>>>> Pablo
>>>>
>>>>
>>>>
>>>> On Mon, Jul 24, 2017 at 5:36 AM, Bakul Shah <ba...@bitblocks.com>
>>>> wrote:
>>>>
>>>>> This is a standard trick to find the least significant set bit in a
>>>>> word. Only works for 2's complement numbers!
>>>>> -x == ~x+1
>>>>> For example: x = 0011b (24), ~x+1 = 1100+1 = 1101. Adding
>>>>> them yields 0001; thus only the least significant set bit remains set.
>>>>>
>>>>> Note that func LSB(x uint64) uint64 { return x&-x } works too. In
>>>>> your example you get an error because in Go literal constants are untyped.
>>>>> It is a pragmatic decision -- see https://blog.golang.org/constants
>>>>>
>>>>> On Jul 23, 2017, at 5:50 AM, Pablo Rozas Larraondo <
>>>>> p.rozas.larrao...@gmail.com> wrote:
>>>>>
>>>>> I have seen Go code using this function to find out the least
>>>>> significant byte of unsigned integers:
>>>>>
>>>>> func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
>>>>>
>>>>> This function works fine but I wonder why, if call the same AND
>>>>> operation, it results in an error: "constant -X overflows uint64"
>>>>>
>>>>> Here is a playground example to illustrate this:
>>>>> https://play.golang.org/p/_0EYtlLnmG
>>>>>
>>>>> Does anyone know what changes when -uint64() is called in a return
>>>>> statement? How a negative uint should be
Re: [go-nuts] Understanding least significant byte operation
Thanks Bakul, I also understand now what Matt Harden was referring to with
his comment. At a bit level both operations cause the same effect on the
underlying bits of the variable but it's meaning changes depending on the
type. All clear!
Cheers,
Pablo
On Wed, Jul 26, 2017 at 1:51 PM, Bakul Shah <ba...@bitblocks.com> wrote:
> [Sorry, didn't see your original response]
>
> In the Go *language* (not just the compiler), when x is an unsigned int,
> -x is treated as a "shorthand" for ^x+1. Another interpretation is that for
> finite ints all arithmetic operations are modulo the word size. Thus -1
> modulo 2^64 is 0x. You might even say that a 2's complement
> machine's native int type is an unsigned int! It is just that most
> arithmetic operations set relevant condition codes (or equivalent) that
> allows you (and the compiler) to interpret an int as a signed int or an
> unsigned one.
>
> I would suggest reading up on how computers do arithmetic. Programming
> languages are merely syntactic sugar on top of processor instruction sets
> :-)
>
> On Jul 25, 2017, at 8:16 PM, Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
> Ok, I might be understanding this differently then:
>
> The -1 * x operation cannot be defined for unsigned integers as -1
> overflows. Therefore, -x in the case of unsigned types is interpreted
> differently by the compiler, resulting in a ^x + 1 operation. Is that a
> correct assumption?
>
> By the way, yes, the title should say Bit instead of Byte, sorry about the
> confusion.
>
> On Wed, Jul 26, 2017 at 11:35 AM, Matt Harden <matt.har...@gmail.com>
> wrote:
>
>> Both statements are true for both signed and unsigned integers.
>>
>> On Mon, Jul 24, 2017, 04:11 Pablo Rozas Larraondo <
>> p.rozas.larrao...@gmail.com> wrote:
>>
>>> Thanks Bakul, I think I have a better understanding of what's going on
>>> after reading your response.
>>>
>>> Is it correct to say that the Go compiler treats the prepended minus
>>> sign differently depending on the variable being a signed or an unsigned
>>> integer?
>>>
>>> By looking at this example: https://play.golang.org/p/feqQsuPkqk
>>>
>>> It seems to me that in the case of an unsigned integer it's treated as a
>>> bitwise operation : -x == ^x + 1
>>> But for signed integers -x == -1 * x
>>>
>>> Cheers,
>>> Pablo
>>>
>>>
>>>
>>> On Mon, Jul 24, 2017 at 5:36 AM, Bakul Shah <ba...@bitblocks.com> wrote:
>>>
>>>> This is a standard trick to find the least significant set bit in a
>>>> word. Only works for 2's complement numbers!
>>>> -x == ~x+1
>>>> For example: x = 0011b (24), ~x+1 = 1100+1 = 1101. Adding
>>>> them yields 0001; thus only the least significant set bit remains set.
>>>>
>>>> Note that func LSB(x uint64) uint64 { return x&-x } works too. In your
>>>> example you get an error because in Go literal constants are untyped. It is
>>>> a pragmatic decision -- see https://blog.golang.org/constants
>>>>
>>>> On Jul 23, 2017, at 5:50 AM, Pablo Rozas Larraondo <
>>>> p.rozas.larrao...@gmail.com> wrote:
>>>>
>>>> I have seen Go code using this function to find out the least
>>>> significant byte of unsigned integers:
>>>>
>>>> func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
>>>>
>>>> This function works fine but I wonder why, if call the same AND
>>>> operation, it results in an error: "constant -X overflows uint64"
>>>>
>>>> Here is a playground example to illustrate this:
>>>> https://play.golang.org/p/_0EYtlLnmG
>>>>
>>>> Does anyone know what changes when -uint64() is called in a return
>>>> statement? How a negative uint should be interpreted?
>>>>
>>>> Thank you,
>>>> Pablo
>>>>
>>>> --
>>>> 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 https://groups.google.com/d/optout.
>>>>
>>>>
>>>
>>> --
>>> 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 https://groups.google.com/d/optout.
>>>
>>
>
> --
> 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 https://groups.google.com/d/optout.
>
>
>
--
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 https://groups.google.com/d/optout.
Re: [go-nuts] Understanding least significant byte operation
Ok, I might be understanding this differently then:
The -1 * x operation cannot be defined for unsigned integers as -1
overflows. Therefore, -x in the case of unsigned types is interpreted
differently by the compiler, resulting in a ^x + 1 operation. Is that a
correct assumption?
By the way, yes, the title should say Bit instead of Byte, sorry about the
confusion.
On Wed, Jul 26, 2017 at 11:35 AM, Matt Harden <matt.har...@gmail.com> wrote:
> Both statements are true for both signed and unsigned integers.
>
> On Mon, Jul 24, 2017, 04:11 Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
>> Thanks Bakul, I think I have a better understanding of what's going on
>> after reading your response.
>>
>> Is it correct to say that the Go compiler treats the prepended minus sign
>> differently depending on the variable being a signed or an unsigned
>> integer?
>>
>> By looking at this example: https://play.golang.org/p/feqQsuPkqk
>>
>> It seems to me that in the case of an unsigned integer it's treated as a
>> bitwise operation : -x == ^x + 1
>> But for signed integers -x == -1 * x
>>
>> Cheers,
>> Pablo
>>
>>
>>
>> On Mon, Jul 24, 2017 at 5:36 AM, Bakul Shah <ba...@bitblocks.com> wrote:
>>
>>> This is a standard trick to find the least significant set bit in a
>>> word. Only works for 2's complement numbers!
>>> -x == ~x+1
>>> For example: x = 0011b (24), ~x+1 = 1100+1 = 1101. Adding
>>> them yields 0001; thus only the least significant set bit remains set.
>>>
>>> Note that func LSB(x uint64) uint64 { return x&-x } works too. In your
>>> example you get an error because in Go literal constants are untyped. It is
>>> a pragmatic decision -- see https://blog.golang.org/constants
>>>
>>> On Jul 23, 2017, at 5:50 AM, Pablo Rozas Larraondo <
>>> p.rozas.larrao...@gmail.com> wrote:
>>>
>>> I have seen Go code using this function to find out the least
>>> significant byte of unsigned integers:
>>>
>>> func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
>>>
>>> This function works fine but I wonder why, if call the same AND
>>> operation, it results in an error: "constant -X overflows uint64"
>>>
>>> Here is a playground example to illustrate this:
>>> https://play.golang.org/p/_0EYtlLnmG
>>>
>>> Does anyone know what changes when -uint64() is called in a return
>>> statement? How a negative uint should be interpreted?
>>>
>>> Thank you,
>>> Pablo
>>>
>>> --
>>> 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 https://groups.google.com/d/optout.
>>>
>>>
>> --
>> 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 https://groups.google.com/d/optout.
>>
>
--
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 https://groups.google.com/d/optout.
Re: [go-nuts] Understanding least significant byte operation
Thanks Bakul, I think I have a better understanding of what's going on
after reading your response.
Is it correct to say that the Go compiler treats the prepended minus sign
differently depending on the variable being a signed or an unsigned
integer?
By looking at this example: https://play.golang.org/p/feqQsuPkqk
It seems to me that in the case of an unsigned integer it's treated as a
bitwise operation : -x == ^x + 1
But for signed integers -x == -1 * x
Cheers,
Pablo
On Mon, Jul 24, 2017 at 5:36 AM, Bakul Shah <ba...@bitblocks.com> wrote:
> This is a standard trick to find the least significant set bit in a word.
> Only works for 2's complement numbers!
> -x == ~x+1
> For example: x = 0011b (24), ~x+1 = 1100+1 = 1101. Adding them
> yields 0001; thus only the least significant set bit remains set.
>
> Note that func LSB(x uint64) uint64 { return x&-x } works too. In your
> example you get an error because in Go literal constants are untyped. It is
> a pragmatic decision -- see https://blog.golang.org/constants
>
> On Jul 23, 2017, at 5:50 AM, Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
> I have seen Go code using this function to find out the least significant
> byte of unsigned integers:
>
> func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
>
> This function works fine but I wonder why, if call the same AND operation,
> it results in an error: "constant -X overflows uint64"
>
> Here is a playground example to illustrate this:
> https://play.golang.org/p/_0EYtlLnmG
>
> Does anyone know what changes when -uint64() is called in a return
> statement? How a negative uint should be interpreted?
>
> Thank you,
> Pablo
>
> --
> 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 https://groups.google.com/d/optout.
>
>
--
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 https://groups.google.com/d/optout.
[go-nuts] Understanding least significant byte operation
I have seen Go code using this function to find out the least significant
byte of unsigned integers:
func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
This function works fine but I wonder why, if call the same AND operation,
it results in an error: "constant -X overflows uint64"
Here is a playground example to illustrate this:
https://play.golang.org/p/_0EYtlLnmG
Does anyone know what changes when -uint64() is called in a return
statement? How a negative uint should be interpreted?
Thank you,
Pablo
--
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 https://groups.google.com/d/optout.
Re: [go-nuts] netutil.LimitListener(lis, n) limits to n-2 requests
Hi Kevin,
That's been a very good guess. Disabling the keep alive on the server has
made it to serve exactly the number of concurrent requests specified on the
LimitListener. Thank you very much for your help. Now I have to do some
work to better understand how all these concepts play together.
Cheers,
Pablo
On Wed, May 24, 2017 at 12:59 PM, Kevin Conway <kevinjacobcon...@gmail.com>
wrote:
> I'm speculating a bit here until I can dig back into the listener stack,
> but at least one variable you can tweak is the connection keep alive. On
> the surface, limit listener appears to gate on the socket accept call. I
> feel it is an important distinction because it limits the listener and not
> the request handler so we're ready taking about concurrent connections
> rather than requests.
>
> The default client will reuse established connections as available. It's
> possible you've found a poor interaction beetween connection pooling and
> connection limiting. You might try running your experiment again with keep
> alive disabled on your HTTP client.
>
> On Tue, May 23, 2017, 05:57 Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
>> Hi gophers,
>>
>> I'm using netutil.LimitListener to limit the number of concurrent
>> requests that can be handled in a server to limit the memory usage of the
>> service. I've noticed that when I send a bunch of requests it serves the
>> number passed to the LimitListerner but after that it serves n-2 requests.
>> I wonder what the problem might be, not a big deal but maybe there is some
>> kind of problem in the library.
>>
>> Here is the code that I've created to test this problem:
>>
>> Server (waits 5 seconds before replying with concurrency limited to 10):
>> package main
>>
>> import (
>> "golang.org/x/net/netutil"
>> "log"
>> "net"
>> "net/http"
>> "time"
>> )
>>
>> type fooHandler struct {
>> }
>>
>> func (fh *fooHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
>> time.Sleep(5 * time.Second)
>> w.Write([]byte("Done"))
>> }
>>
>> func main() {
>> lis, err := net.Listen("tcp", ":8080")
>> if err != nil {
>> log.Fatalf("failed to listen: %v", err)
>> }
>> lis = netutil.LimitListener(lis, 10)
>> fH := {}
>>
>> s := {
>> Handler:fH,
>> ReadTimeout:60 * time.Second,
>> WriteTimeout: 60 * time.Second,
>> MaxHeaderBytes: 1 << 20,
>> }
>>
>> if err := s.Serve(lis); err != nil {
>> log.Fatalf("failed to serve: %v", err)
>> }
>> }
>>
>>
>> Client (Sends 40 concurrent requests to the server):
>> package main
>>
>> import (
>> "fmt"
>> "io/ioutil"
>> "net/http"
>> "sync"
>> )
>>
>> func Ask(wg *sync.WaitGroup, n int) {
>> resp, err := http.Get("http://localhost:8080;)
>> if err != nil {
>> return
>> }
>> defer resp.Body.Close()
>> body, err := ioutil.ReadAll(resp.Body)
>> fmt.Println(err, string(body), n)
>> wg.Done()
>> }
>> func main() {
>> wg := {}
>> for i := 0; i < 40; i++ {
>> wg.Add(1)
>> go Ask(wg, i)
>> }
>> wg.Wait()
>> }
>>
>> In this example I see 10 responses after the first 5 seconds and then 8
>> responses every five seconds.
>>
>> go version go1.8 darwin/amd64
>>
>> Thanks,
>> Pablo
>>
>> --
>> 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 https://groups.google.com/d/optout.
>>
>
--
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 https://groups.google.com/d/optout.
[go-nuts] Re: How to point to pointer struct
I'm thinking about the possibility of having something like [][]Volume in
Go. Do you know the size or number of Volumes in your struct?
There's an example of converting **char into []string that might be useful:
https://stackoverflow.com/questions/36188649/cgo-char-to-slice-string
On Tuesday, May 23, 2017 at 8:39:12 PM UTC+10, alex martin wrote:
>
> Hi
> I have this structure in C created by rsl libray
>
> typedef struct {
> Radar_header h;
> Volume **v;
> } Radar;
>
>
> Using cgo i read the structure with
>
>
> Radar *readRad(char *fname) {
> return RSL_anyformat_to_radar(fname, NULL);
> }
>
>
> and call this function in go
>
> RPointer := C.readRad(C.CString(os.Args[1]))
>
>
> and i see the structure
>
> with fmt.Printf("%T",RPointer)=> *main._Ctype_struct___0
>
> with fmt.Printf("%+v",RPointer) => &{h:{} _:[0 0 0 0] *v:0xe59b60*}
>
>
> The field is a **C.Volume pointer.
>
> The question is: it's possible with Golang list all C.Volume's struct
> pointed ?
>
>
> like this
>
>
> for i := 0; i < int(RPointer.h.nvolumes); i++ {
>
> pv := *RPointer.v[i]
> fmt.Printf("\nVOLUME Sweep %+v\n", *pv.sweep)
> }
>
>
> the exit is type **C.struct___2 does not support indexing
>
>
> I tried with unsafe.Pointer using
>
>
>
> *puint1 := unsafe.Pointer(RPointer.v)*
>
>
> *sizep := unsafe.Sizeof(RPointer.v)fmt.Printf("\npuint [%+v] -> + sizeoff
> [%+v]\n", puint1, unsafe.Pointer(uintptr(puint1)+sizep))*
>
>
> and printf is puint [0xe59b60] -> + sizeoff [0xe59b68]
>
>
> there is a casting like this
>
>
> volume2 := (*C.Volume)(*unsafe.Pointer(uintptr(puint1) + sizep))
>
>
> Thanks
>
> Alex
>
>
>
>
>
--
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 https://groups.google.com/d/optout.
[go-nuts] netutil.LimitListener(lis, n) limits to n-2 requests
Hi gophers,
I'm using netutil.LimitListener to limit the number of concurrent requests
that can be handled in a server to limit the memory usage of the service.
I've noticed that when I send a bunch of requests it serves the number
passed to the LimitListerner but after that it serves n-2 requests. I
wonder what the problem might be, not a big deal but maybe there is some
kind of problem in the library.
Here is the code that I've created to test this problem:
Server (waits 5 seconds before replying with concurrency limited to 10):
package main
import (
"golang.org/x/net/netutil"
"log"
"net"
"net/http"
"time"
)
type fooHandler struct {
}
func (fh *fooHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
time.Sleep(5 * time.Second)
w.Write([]byte("Done"))
}
func main() {
lis, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatalf("failed to listen: %v", err)
}
lis = netutil.LimitListener(lis, 10)
fH := {}
s := {
Handler:fH,
ReadTimeout:60 * time.Second,
WriteTimeout: 60 * time.Second,
MaxHeaderBytes: 1 << 20,
}
if err := s.Serve(lis); err != nil {
log.Fatalf("failed to serve: %v", err)
}
}
Client (Sends 40 concurrent requests to the server):
package main
import (
"fmt"
"io/ioutil"
"net/http"
"sync"
)
func Ask(wg *sync.WaitGroup, n int) {
resp, err := http.Get("http://localhost:8080;)
if err != nil {
return
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
fmt.Println(err, string(body), n)
wg.Done()
}
func main() {
wg := {}
for i := 0; i < 40; i++ {
wg.Add(1)
go Ask(wg, i)
}
wg.Wait()
}
In this example I see 10 responses after the first 5 seconds and then 8
responses every five seconds.
go version go1.8 darwin/amd64
Thanks,
Pablo
--
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 https://groups.google.com/d/optout.
[go-nuts] net/rpc result types
Hi, The rpc documentation says that a remote rpc method can be registered if the second argument (response) is a pointer. https://golang.org/pkg/net/rpc/#Server.Register Does anyone know if there is a way of having an interface declared as this response type and then assign pointers to it that satisfy that interface? When I try to do it the compiler complains asking for a pointer type, but considering an interface is already "kind" of a pointer* it seems to me it can be possible. I guess it would be very useful to have generic remote functions that are able to return any type that implements an interface, the same way local functions do. Thanks, Pablo * http://stackoverflow.com/questions/13511203/why-cant-i-assign-a-struct-to-an-interface -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] [ANN] Gleam now supports distributed pure Go Map Reduce
Thanks Chris!
I'll go through the documentation to understand this new approach.
Pablo
On Mon, Jan 23, 2017 at 12:19 PM, Chris Lu <chris...@gmail.com> wrote:
> Thanks! This page has a little more details.
>
> https://github.com/chrislusf/gleam/wiki/Write-Mapper-Reducer-in-Go
>
> LuaJIT is fast. But Go code is more manageable and can have more
> complicated logic with libraries. Sacrificing the readability with extra
> type casting from interface{} seems a small cost to pay.
>
> Chris
>
>
> On Sat, Jan 21, 2017 at 11:36 PM, Pablo Rozas-Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
>> That's great news Chris! Is it documented anywhere with some more detail
>> this pure Go implementation? I'd love to know more about how you overcame
>> the initial problems such as external code execution that lead you to
>> choose LuaJit in the first place.
>>
>> Thanks,
>> Pablo
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/MDx44mMa7jE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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 https://groups.google.com/d/optout.
Re: [go-nuts] image Gray16 endianness
Thanks again Dan, I enjoyed reading Rob Pike's blog post. I think you are right with your point, it has to be one way and not every machine use the same representation anyway. Cheers, Pablo On Wed, Jan 11, 2017 at 7:32 PM, Dan Kortschak < dan.kortsc...@adelaide.edu.au> wrote: > On Wed, 2017-01-11 at 16:46 +1100, Pablo Rozas Larraondo wrote: > > Thanks Dan. I'm just surprised that Gray16 uses big endian when, for > > example, Go's uint16 type uses the little endian convention. > > On *most* supported architectures. > > > I guess I find this weird and I want to know if there is a reason for > > implementing Gray16 this way. > > It has to be one way. > > You might like to see this article for thinking about it. > https://commandcenter.blogspot.com.au/2012/04/byte-order-fallacy.html > -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] image Gray16 endianness
Thanks Dan. I'm just surprised that Gray16 uses big endian when, for example, Go's uint16 type uses the little endian convention. I guess I find this weird and I want to know if there is a reason for implementing Gray16 this way. On Wed, Jan 11, 2017 at 4:40 PM, Dan Kortschak < dan.kortsc...@adelaide.edu.au> wrote: > On Wed, 2017-01-11 at 16:21 +1100, Pablo Rozas Larraondo wrote: > > I'm confused with image.Gray16 having pixel values represented in the > > wrong order. It seems to me that image.Gray16 considers numbers to be > > big endian instead of little endian. > > Why do you think that is the wrong order? > > Here is where the order is defined (yes, big endian): > > https://golang.org/src/image/image.go?s=21077:21277#L756 > > > > I've created a small playground example to illustrate this: > > https://play.golang.org/p/bhYbuIkkOz > > > > Is there something that I'm not doing right? > > > Why do you need to know the byte ordering? > > -- 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 https://groups.google.com/d/optout.
[go-nuts] image Gray16 endianness
Hi, I'm confused with image.Gray16 having pixel values represented in the wrong order. It seems to me that image.Gray16 considers numbers to be big endian instead of little endian. I've created a small playground example to illustrate this: https://play.golang.org/p/bhYbuIkkOz Is there something that I'm not doing right? Thanks for your help, Pablo -- 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 https://groups.google.com/d/optout.
Re: [go-nuts] Debug memory leaks in cgo calls
Thanks Ian, So if I understand it well, this involves using clang compiler instead of the default gcc when building Go code that uses cgo. I'll do some research on how to do this. Cheers, Pablo On Wed, Dec 14, 2016 at 5:36 PM, Ian Lance Taylor <i...@golang.org> wrote: > On Wed, Dec 14, 2016 at 4:57 PM, Pablo Rozas Larraondo > <p.rozas.larrao...@gmail.com> wrote: > > > > I've seen this question asked before in the mail list but with no clear > > answers. I'm just asking it again in case someone has come up with a new > way > > of doing this: > > > > Does anyone know about a good tool or method to detect memory leaks > > happening on C code being called by cgo? > > clang's address sanitizer can do memory leak detection. I have not > tried that with Go myself, but I suggest starting with that to see if > you can make it work. > > Ian > -- 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 https://groups.google.com/d/optout.
[go-nuts] Debug memory leaks in cgo calls
I've seen this question asked before in the mail list but with no clear answers. I'm just asking it again in case someone has come up with a new way of doing this: Does anyone know about a good tool or method to detect memory leaks happening on C code being called by cgo? Cheers, Pablo -- 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 https://groups.google.com/d/optout.
[go-nuts] Re: Idiomatic way of handling http requests in separate goroutines
In case someone arrives here with the same question I'm going to post a
simple example that does what Tamás suggested a few days ago. Use context
to block on .Done() and pass the responseWriter as a context Value. Please
comment if passing the responseWriter as a context value is not considered
a good practice.
package main
import (
"context"
"net/http"
"time"
)
var reqChan chan context.Context
func ConcPrinter(reqChan chan context.Context) {
for c := range reqChan {
w := c.Value("reqW").(http.ResponseWriter)
f := c.Value("cancel").(context.CancelFunc)
// Expensive operation
time.Sleep(time.Second)
w.Write([]byte("Done!"))
f()
}
}
func rootHandler(w http.ResponseWriter, r *http.Request) {
cont, f := context.WithCancel(context.WithValue(r.Context(), "reqW", w))
contC := context.WithValue(cont, "cancel", f)
reqChan <- contC
<-contC.Done()
}
func main() {
http.HandleFunc("/", rootHandler)
reqChan = make(chan context.Context)
go ConcPrinter(reqChan)
http.ListenAndServe(":8080", nil)
}
Cheers,
Pablo
On Wednesday, December 7, 2016 at 4:01:18 PM UTC-8, Pablo Rozas-Larraondo
wrote:
>
> Hi gophers,
>
> I'm designing a service exposed through a http server which uses a pool of
> workers to process requests. At the moment my handlerFunc look similar to
> this:
>
> func aHandler(w http.ResponseWriter, r *http.Request) {
> var wg sync.WaitGroup
> wg.Add(1)
> reqQueue <- {, r, w}
> wg.Wait()
> }
>
> When a worker is done, it writes on the w and calls wg.Done(). This
> approach works fine but I'm not sure if passing the WaitGroup around is the
> best approach. Has anyone encountered a similar situation or can suggest
> alternative approaches? Could the new context package and its Done()
> channel be of any help in this case?
>
> Thank you very much for your help,
> Pablo
>
--
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 https://groups.google.com/d/optout.
[go-nuts] Re: Idiomatic way of handling http requests in separate goroutines
Thank you Tamás, I like the concept of blocking on select in the handler until a worker closes the channel. I don't know why but every time I use a WaitGroup I have the impression that the same thing can be done better. I'll try to implement it with the context library first as I'm very intrigued about it. Cheers, Pablo On Friday, December 9, 2016 at 1:33:14 AM UTC+11, Tamás Gulácsi wrote: > > I think this is not bad. > But you can try context.Context, or simply pass in a new chan, which will > be closed by the worker - so you can select, timeout on it. -- 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 https://groups.google.com/d/optout.
[go-nuts] Idiomatic way of handling http requests in separate goroutines
Hi gophers,
I'm designing a service exposed through a http server which uses a pool of
workers to process requests. At the moment my handlerFunc look similar to
this:
func aHandler(w http.ResponseWriter, r *http.Request) {
var wg sync.WaitGroup
wg.Add(1)
reqQueue <- {, r, w}
wg.Wait()
}
When a worker is done, it writes on the w and calls wg.Done(). This
approach works fine but I'm not sure if passing the WaitGroup around is the
best approach. Has anyone encountered a similar situation or can suggest
alternative approaches? Could the new context package and its Done()
channel be of any help in this case?
Thank you very much for your help,
Pablo
--
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 https://groups.google.com/d/optout.
[go-nuts] Videos from DotGo 2016
Does anyone know when videos from the DotGo 2016 conference are going to be made available? if they are... I can only find 3 of the talks at their news site. http://www.thedotpost.com/conference/dotgo-2016 I'm looking forward to watch Robert Griesemer's talk on prototyping multidimensional slices. Cheers, Pablo -- 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 https://groups.google.com/d/optout.
[go-nuts] Re: What 'select' is doing here?
Right! Ok, I understand it now, there's no concurrent evaluation happening. And I understand what you meant when evaluating the functions before the select statement in your code. Thank you very much for your help in understanding this Dave. Pablo On Wednesday, September 7, 2016 at 11:51:59 AM UTC+10, Dave Cheney wrote: > > The best description i've found comes from the spec, see the "execution of > select statement" section. > > https://golang.org/ref/spec#Select_statements > > The program I rewrote for you is identical to the one you wrote, all the > work to evaluate the RHS of the select cases happens "before" the select > statement, so if A() sleeps for 100ms, then B() sleeps for 1000ms, the > select statement is not executed until both operations have happened. > > > On Wednesday, 7 September 2016 11:48:02 UTC+10, Pablo Rozas-Larraondo > wrote: >> >> Thanks Dave. It seems though that whatever select chooses to run (A or B) >> the program takes 1000 ms to complete. I would expect the program to finish >> in 100 ms if A is chosen or 1000 ms in the case of B. I wonder if both >> functions are evaluated concurrently no matter which case select chooses. >> If this is true, does anyone know what kind of concurrency is the select >> statement using underneath? >> >> Cheers, >> Pablo >> >> On Wednesday, September 7, 2016 at 8:35:11 AM UTC+10, Dave Cheney wrote: >>> >>> Here's the same program rewritten. >>> >>> https://play.golang.org/p/ANHNUcPjR2 >>> >>> If ch is writable, then select pseudo randomly chooses the first or >>> second case. The default case is never taken unless ch is blocked, in which >>> case the goroutine will block sending to ch indefinitely. >>> >>> -- 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 https://groups.google.com/d/optout.
[go-nuts] Re: What 'select' is doing here?
Thanks Dave. It seems though that whatever select chooses to run (A or B) the program takes 1000 ms to complete. I would expect the program to finish in 100 ms if A is chosen or 1000 ms in the case of B. I wonder if both functions are evaluated concurrently no matter which case select chooses. If this is true, does anyone know what kind of concurrency is the select statement using underneath? Cheers, Pablo On Wednesday, September 7, 2016 at 8:35:11 AM UTC+10, Dave Cheney wrote: > > Here's the same program rewritten. > > https://play.golang.org/p/ANHNUcPjR2 > > If ch is writable, then select pseudo randomly chooses the first or second > case. The default case is never taken unless ch is blocked, in which case > the goroutine will block sending to ch indefinitely. > > -- 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 https://groups.google.com/d/optout.
[go-nuts] What 'select' is doing here?
I'm trying to understand how the 'select' statement works internally. The execution process of select as described in https://golang.org/ref/spec#Select_statements says on number 2: "If one or more of the communications can proceed, a single one that can proceed is chosen via a uniform pseudo-random selection." However, in this example: https://play.golang.org/p/1GKsbhES8s I've defined two cases each calling a different function: A() and B(). When I execute this code it seems to evaluate both functions (it waits till the longest sleep in A and B finishes but returns a random 1 or 2). Does this means that select choses a random case (as stated in the docs) but evaluates both cases? Does anyone know what kind of concurrency 'select' uses internally to evaluate both functions? Thanks for your help, Pablo Note: The Go Playground doesn't seem to return random responses as the ones I see when I run the same code on my local computer. It might be related to internal caching effects. -- 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 https://groups.google.com/d/optout.
