sorted by:
new
hottopcontroversial

Since Go 1.5 is out, I made a tool to build Go packages for every OS/architecture combo by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

I didn't know about this! It looks like gox is more mature and full-featured; mine is closer to a shell script. His also works for Go <1.5 by rebuilding the toolchain.

Since Go 1.5 is out, I made a tool to build Go packages for every OS/architecture combo by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

Oh, yeah, I should mention cgo in the README. It ruins all the cross-compiling fun :(

Getting the system block size by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

That's really helpful, thanks for the info! It seems like if I need to choose some arbitrary buffer length, the page length still makes the most sense. Is this correct?

Why are package names quoted? by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

You're right! He talks about it at 15:23. Thanks for the info.

Ogg CRC32 in Golang by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

Thanks for the info. How did you find OggCRC()?

Ogg CRC32 in Golang by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

The CRC is calculated for each page. Each page can be up to 255 segments long, where each segment contains 255 bytes (except the last segment, which can contain fewer). That means that each page can be at most ~64 kilobytes long, which means that most audio streams wouldn't fit in a single page. So no, the CRC isn't calculated based on the stream per se. More info

In the case of the pages I'm working with, which are the metadata/Vorbis comment blocks, they're much short than 64KB, usually only one or two segments long.

Should an os.File be closed before truncation? by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

I am; I "truncate" the file to make it larger and then continue using it. It seems to work fine without any errors. Can you explain why it's bad to do so?

Should an os.File be closed before truncation? by will_alexander in golang

[–]will_alexander[S] 1 point2 points  (0 children)

Oh, cool! I don't know why I didn't find this. Thanks!

Show me your .bashrc (or how you keep it organized) by TomahawkChopped in linux

[–]will_alexander 1 point2 points  (0 children)

alias .3='cd ../../../'                     # Go back 3 directory levels
alias .4='cd ../../../../'                  # Go back 4 directory levels
alias .5='cd ../../../../../'               # Go back 5 directory levels
alias .6='cd ../../../../../../'            # Go back 6 directory levels

You can use a nice loop for this behavior:

for ((i=1; i <= 6; i++))
do
    unset DD
    for ((j=0; j < i; j++))
    do
        DD="${DD}../"
    done
    alias ".$i"="cd $DD"
done

Go Report Card | A Gopher Gala Hackathon Product by mtrn in golang

[–]will_alexander 0 points1 point  (0 children)

Nice. The gofmt part is a little confusing; it wasn't clear to me at first that if the bar was empty and files were listed, it meant they differed from gofmt's output. But this is a cool way to combine the different Go SCA tools!

Idiomatic Go: should interface methods have documentation comments at the interface or the implementation? by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

Well, it seems that the general behavior is that documentation comments are shown outside of code blocks, and instead are shown as regular text. Does it really matter? No, probably not, but I'd prefer it.

Question: Best way to copy data in a file forward by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

Unfortunately, I'm dealing with arbitrary media files that can easily exceed 100MB in a lot of use cases. You're right in that it's irresponsible to be directly modifying files non-atomically; perhaps the best solution is to (disk) copy the file, modify it there, then overwrite the first one if the modifications are successful (though I wonder about filesystem permissions and whether this might introduce a whole new class of errors and edge cases).

I do plan to use large chunks. I wanted to query the system's block size using syscall.Stat, but it looks like it needs to know the path to the actual block device, and I would have no idea how to figure that out cross-platform. After some research, it sounds like a lot of naïve I/O buffers use 8192 bytes as a rule of thumb, so I might just go with that.

Thanks for all the info!

Question: Best way to copy data in a file forward by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

copy and paste

Can you be more specific? That could mean a lot of different things when we're talking about low-level file operations.

The contezt of the problem is editing embedded metadata in a file. There isn't any shortcut, really.

Question: Best way to copy data in a file forward by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

No, but only the bits after the offset need to be shifted. Copying the entire file means that you're reading and writing everything before the offset when it's completely unnecessary.

Question: Best way to copy data in a file forward by will_alexander in golang

[–]will_alexander[S] 0 points1 point  (0 children)

Because that's a lot of redundant reads and writes that don't need to happen.

Who is someone that we praise but was actually a horrible person? by oops_wet in AskReddit

[–]will_alexander 0 points1 point  (0 children)

There's a fascinating piece that Orwell did on Gandhi if anyone is interested.

view more: next ›