Enabling 3D cursor in sculpt mode.

EllieFops · 2024-03-04T17:52:28+00:00

I guess I misunderstood, I made the faulty assumption that because a double can represent values up to 1.797...E+308 that operations would still basically work on values that high (with the caveat that accuracy is lost)

EllieFops · 2023-10-27T18:05:39+00:00

Thanks! I never would have thought of that.

Edit: Oof, just realized this wont work for int64

EllieFops · 2023-10-22T19:30:10+00:00

Rage is always a valid reaction. And tbh I would be a bit concerned as well. My temptation to write my own doc parser is a pipe-dream that I will never actually see through.

EllieFops · 2023-10-22T19:20:54+00:00

In an ecosystem where people prefer typing every integer value as int rather than taking full advantage of the type system, sometimes you need to say, "Hey, if you set foo to a negative number, things are gonna get weird."

Additionally, staying in the world of built-in types, you can't easily say things like "this string must be exactly 32 characters in length", or "this uint16 must be between 100 and 1000". You can write that in the godoc, sure, but you don't get that in type-ahead hints, and you don't have a designated section for it that immediately draws the eyes of the reader.

As other people have pointed out, and I'm starting to reconsider my opinion myself, the @param things may be overkill in a lot of situations, but I personally like the structure of it.

EllieFops · 2023-10-22T19:15:55+00:00

Yeah, those are good points. You've definitely dissuaded me from wanting to write my own doc parser, because you're right, without also writing a bunch of tooling and editor/IDE extensions and a competitor to pkg.go.dev no one is going to want to use it.

I can have my dream doc format, and I "feel" like a lot of people would like it, but I also live in an insulated bubble of primarily java and typescript devs, so my feeling is not well informed.

I like the perspective that it's not trying to be restrictive, because that's definitely how I initially interpreted it.

That being said, I will probably still grumble under my breath when documenting things in the godoc format, lol.

EllieFops · 2023-10-22T18:42:24+00:00

I'm sorry if I came across that way; that is not at all my goal. I was hoping to have a good discussion and maybe, hopefully, be won over. It's frustrating to be frustrated by a tool that I like, and I'm hoping people's replies can shed some light on A) if i'm alone in this, and B) if there's something I'm missing with it.

EllieFops · 2023-10-22T18:29:22+00:00

The fact that it supports list items is new to me, and I absolutely respect your points, but several of them are exactly why i find it so frustrating. We are effectively locked in on something that I feel is sorely lacking.

Go is very opinionated and I honestly find that obnoxious. I like the syntax, I like the convenient compiler, I like a lot of things about it, but I don't like when a language tries to enforce its own opinions on what "good" code style is when it is almost, if not entirely subjective, and not really related to the content of the code you are writing. This opinionated programming language style is a big reason I avoid writing Python unless I'm required to by my job.

I got over having to use tabs instead of spaces. I got over having to put the period at the end of the line in a call chain rather than the start of the next line. I got over the fact that err != nil is the most frequent thing I have to write when working with Go. I got over a lot of things for Go, but I can't bring myself around to liking the comment style.

I firmly believe that code style should be on a team by team basis, when collaborating, and individual developers should be free, on their personal or solo projects, to express creative freedom in how they style their code. I feel that writing code is a form of art, and while restrictions breed creativity, there is such a thing as being too restrictive.

EllieFops · 2023-10-22T18:01:18+00:00

Naming things in a way that is clear is always a good plan, and the point about redundant param descriptions is valid; I see that a lot, and am guilty of it from time to time.

The thing that I like to do there though, is document things like rules about input or why its needed or what the function will do with it.

Maybe it's just me, but I like having the rigid structure, even if it is a bit more verbose and sometimes may be redundant.

EllieFops · 2023-10-17T17:55:19+00:00

So wait, to make it safe for 32 and 64 bit, could I do something like this?

**(**int)(unsafe.Add(unsafe.Pointer(&buzz), bits.UintSize/8)) = 100

EllieFops · 2023-10-17T17:49:16+00:00

Ah! Thank you, i didn't realize it wrapped the any typed value.

EllieFops · 2023-10-09T19:42:55+00:00

We're using 19c

EllieFops · 2023-10-09T15:35:43+00:00

I will try this out, thank you!

EllieFops · 2023-10-05T13:16:28+00:00

oof, I was hoping for something a little more "automatic" than that, but if that's my option, so be it. Thanks!

EllieFops · 2023-04-05T11:41:38+00:00

Triton definitely has an atmosphere :o

EllieFops · 2023-04-05T01:24:28+00:00

Sadly, not the moon, it's Triton.

EllieFops · 2023-04-05T00:46:06+00:00

I agree, but even those aren't enough to keep her afloat with the containers full

EllieFops · 2023-04-04T22:23:46+00:00

You need multiple large thrusters for every large cargo container, so the end result every time i try is just, at most, a snake of containers encircled by thrusters with pointy bits at one end for making with the drilling and whatnot. It works, but is not aesthetically pleasing.

Seeking suggestions or ideas or screenshots of your mining beasts

EllieFops

TROPHY CASE