That's what the reflect package does,
https://play.golang.org/p/M7gNcKjOmMM
-- Marcin
On Tue, May 21, 2019 at 8:15 PM wrote:
> Hi,
>
> for a code generator I want to get a type of a string which is passed by
> an argument by go generate. So I have sth. like "[]int" and now I need to
> know if
I'm not sure if you are still interested in details or not.
Assuming you ask the question "why" it works differently, one of the
short answers, assuming some basic background knowledge on your part
about compilers and programming language implementation details:
similar, but different
Hi there,
Not sure someone reported this issue.
Recently I had my golang compiler upgraded from 1.10.3 to 1.12.5.
A binary tool was built by 1.10 reported following errors when I executed
it. Obviously it's trying to include both x86 & AIX arch code, which is
wrong.
I've checked my build
Would this work?
select {
case val := <-high:
continue
default:
}
select {
case val := <-high:
case val := <-high:
case val := <-high:
case val := <-low:
}
On Monday, July 23, 2012 at 2:16:16 PM UTC-7, Erwin wrote:
>
> Hello,
>
> i wonder how to implement channel priorities nicely. Say there
Hi,
for a code generator I want to get a type of a string which is passed by an
argument by go generate. So I have sth. like "[]int" and now I need to know
if it is a slice/rangeable, of type int etc. Is this somehow possible?
I cannot have a predefined map from strings to types because it is
On Tue, May 21, 2019 at 11:14 PM wrote:
>
> Not sure someone reported this issue.
>
> Recently I had my golang compiler upgraded from 1.10.3 to 1.12.5.
> A binary tool was built by 1.10 reported following errors when I executed it.
> Obviously it's trying to include both x86 & AIX arch code,
Could you please clarify which statement your example is meant to
confirm or refute?
On 5/20/19, Michael Jones wrote:
> ahem...
> https://play.golang.org/p/7gcb9Yv7c9e
>
> On Mon, May 20, 2019 at 2:45 AM wrote:
>
>> https://golang.org/ref/spec#Constants
>>
>> "A constant may be given a type
I had an issue where io.Copy did not copy the entire file contents.
My code was something like:
fReader := bufio.NewReader(sourcef)
fWriter := bufio.NewWriter(destf)
n, err := io.Copy(fWriter, fReader)
if err != nil {
fmt.Println("Error while copying:", err)
return
}
fmt.Println("Copied", n,
naah, thanks, that's ok.
As soon as I can acquire my own turing machine, I'll insist on 1 number type.
Until then I can live with different number types and some rules for
my finite machines.
On 5/21/19, Michael Jones wrote:
> Oh, Sorry. Have been away from email today. (Focused 100% in VS-code
Hello,
Indeed, you need to flush the bufio.Writer for the remaining data to be
sent accross.
Usually though, you do not need to buffer the input or output at all.
In which case, the code is straight forward:
https://play.golang.org/p/F1tMKdsapyX
If you do need to buffer though, I would do
On Tue, May 21, 2019 at 9:44 AM wrote:
> Usually though, you do not need to buffer the input or output at all.
If I/O is performed in chunks comparable in size to what
bufio.{Reader,Writer} uses then ok. When I/O is done in small chunks,
then using bufio should improve performance.
The
Using `context` is the recommended mechanism to pass timeouts and other
information to functions,
so it's probably already the "best" way, at least from the design point of
view.
I recommend benchmarking it before searching for other solutions:
if it turns out to cause excessive slowdown, there
Oh, Sorry. Have been away from email today. (Focused 100% in VS-code on a
cool feature for Go)
My statement was meant to convey an insight into a subtle aspect of Go's
constants and high-precision expression evaluation--that the "type" of
untyped constants/values, in the conversion rules sense,
Hi,
How to uncompress .zz file in Go?
Thanks,
Nitish
--
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
On Tue, May 21, 2019 at 5:08 PM Nitish Saboo
wrote:
> Hi,
>
> How to uncompress .zz file in Go?
>
use top? (sorry.)
I don't know of any Go package that handle directly Zzip archives.
but it seems ZZip archives somehow use LZMA2 compression.
and there's (at least) a package to do that:
-
You do not need to flush if you call close. Close will flush. There is some
other bug in your code I believe.
> On May 21, 2019, at 3:01 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Tue, May 21, 2019 at 9:44 AM wrote:
>>
>> Usually though, you do not need to buffer the input or output at
I don't think so.
Closing file without flushing:
package main
import (
"bufio"
"fmt"
"io"
"os"
)
func main() {
sourceFilename := "MozillaFirefox-66.0.5-741.4.x86_64.rpm"
sourcef, err := os.Open(sourceFilename)
if err != nil {
fmt.Println("Error while opening source
Sorry, per docs, the client should call the Flush method to guarantee all data
has been forwarded to the underlying io.Writer.
Not sure why the Write doesn’t implement Closer. That’s fairly non standard way
of doing buffered io...
> On May 21, 2019, at 8:42 AM, Subramanian Sridharan
> wrote:
Thanks all for comments,
for me confusion is that
int( some_float_var)
works, and surprisingly
int( some_float_constant)
does not.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
I don't think so.
When I close the file and don't explicitly flush:
package main
import (
"bufio"
"fmt"
"io"
"os"
)
func main() {
sourceFilename := "MozillaFirefox-66.0.5-741.4.x86_64.rpm"
sourcef, err := os.Open(sourceFilename)
if err != nil {
fmt.Println("Error while opening source file:",
Excuse me if I am misunderstanding something - but it certainly looks to me
like you are not at any point closing the bufio.Writer (because it is not a
WriteCloser and does not support Close function). That is why you need to
flush it! What you are closing is the underlying
Hi all,
I've tried running some of my Go code using CPU Profiling enabled as
described at
https://blog.golang.org/profiling-go-programs
and
https://golang.org/pkg/runtime/pprof/#StartCPUProfile
.. I'm on Funtoo Linux x86_64, and I ensured CONFIG_HIGH_RES_TIMERS=y;
however, it seems no matter
That’s what I was saying, I incorrectly thought that the Writer was a
WriterCloser.
Seems it should be with a noop if the contained Writer is not a WriterCloser.
This would be pretty much how every other platform does buffered IO.
> On May 21, 2019, at 11:19 AM, howardcs...@gmail.com wrote:
>
Probably it's not a Closer because that would imply that Close would close
its underlying writer too, but then it would need to take a WriteCloser
which would make it less general.
On Tue, 21 May 2019, 19:02 Robert Engels, wrote:
> That’s what I was saying, I incorrectly thought that the Writer
On Tuesday, May 21, 2019 at 12:54:32 PM UTC-4, Russtopia wrote:
>
> Hi all,
>
> I've tried running some of my Go code using CPU Profiling enabled as
> described at
>
> https://blog.golang.org/profiling-go-programs
>
> and
>
> https://golang.org/pkg/runtime/pprof/#StartCPUProfile
>
> .. I'm
That’s a good case of dynamic type checking and good documentation
> On May 21, 2019, at 5:20 PM, roger peppe wrote:
>
> Probably it's not a Closer because that would imply that Close would close
> its underlying writer too, but then it would need to take a WriteCloser which
> would make it
26 matches
Mail list logo
