|
Linear Zoetrope posted:Sounds like something you'd need to ask an IP lawyer. This is the safest of answers. There is not necessarily much of a case to be made that using the same magic numbers in the same sequence creates a derivative work if it's reimplemented from scratch. That said, for maximal rear end-coverage and if you have a helpful friend and are willing to document, you can white-box reverse engineer it--exhaustively document the protocol, hand the document to that friend, have that friend implement it. By doing so you will probably be, at minimum, too much of a pain in the rear end to sue, but I am not a lawyer (just somebody who deals with software IP a lot) and you should consult one if you're that worried.
|
#
?
Aug 24, 2018 07:42
|
|
|
|
| # ? Jun 7, 2024 23:17 |
|
|
Of course IANAL however the general rule is supposed to be that a programmatic operation that doesn't have the possibility of individual expression (can in practice only be done correctly one way) is not copyrightable. Still check with a lawyer.
|
|
#
?
Aug 24, 2018 08:09
|
|
|
My intuition is that if these are a bunch of magic numbers you need to initialize the hardware, I can't imagine implementing it in any way short of linking/copy+pasting the offending code would screw you, but it's also a really weird situation hence the IP lawyer safety advice.
|
|
#
?
Aug 24, 2018 08:28
|
|
|
Are the magic numbers themselves copyrighted?
|
|
#
?
Aug 24, 2018 14:43
|
|
|
ultrafilter posted:Are the magic numbers themselves copyrighted? I don't believe so. The datasheet I found has them. Although the funny thing is the source I was looking at is marginally different. It seems to omit a few steps. The datasheet is pretty abysmal. I've been putting together a list of register and bit names in a header from where they have been mentioned in init steps. I think everything should be good if I work from the datasheet. What I'm doing isn't secret or anything. I am however being intentionally vague to cover my behind. I'm not going to make a cent from what I'm writing and I doubt anyone anywhere will ever. The source will be available to download when it's working just like the rest is. It's just the license is different. Seriously, gently caress license incompatibility bullshit. e: I wrote my own based off the datasheet. No idea if it works yet. I can't test it until I implement, or at least port some driver software from another platform. That's a work in progress. I'm in the mysteriously breaking included files stage. General_Failure fucked around with this message at 05:21 on Aug 26, 2018 |
|
#
?
Aug 25, 2018 03:19
|
|
|
Can anyone recommend any books on (about) the PDF format and print documents in general?
|
|
#
?
Aug 27, 2018 14:41
|
|
|
Plank Walker posted:Can anyone recommend any books on (about) the PDF format and print documents in general? i think this qualifies as a book?
|
|
#
?
Aug 27, 2018 22:38
|
|
|
It certainly would if you printed it out.
|
|
#
?
Aug 28, 2018 00:23
|
|
|
Are any of the books in this machine learning humble bundle good enough to justify buying the bundle?
|
|
#
?
Aug 29, 2018 21:55
|
|
|
Thermopyle posted:Are any of the books in this machine learning humble bundle good enough to justify buying the bundle? While I do not know the books themselves how good or bad they are, the subjects though are definitely worth $15. For this money I wouldn't even blink given what information is offered.
|
|
#
?
Aug 29, 2018 22:10
|
|
|
No idea about any of the books, but gently caress it, it's $15.
|
|
#
?
Aug 30, 2018 01:10
|
|
|
Thermopyle posted:Are any of the books in this machine learning humble bundle good enough to justify buying the bundle? Its a bunch of O'Reily books, can't really go wrong. They may not be the best possible books on those subjects but they'll be decent and good references if nothing else.
|
|
#
?
Aug 30, 2018 02:49
|
|
|
Thermopyle posted:Are any of the books in this machine learning humble bundle good enough to justify buying the bundle? i've been doing machine learning stuff at work and the subject is changing so fast that the books are mostly out of date. i got further along just by grabbing machine learning examples off of github.
|
|
#
?
Aug 30, 2018 14:02
|
|
|
Thermopyle posted:Are any of the books in this machine learning humble bundle good enough to justify buying the bundle? The deep learning book was recommended as an intro text by a researcher who presented a thing at GDC? You’re going to need to read white papers a/o random github code for cutting edge stuff though.
|
|
#
?
Aug 30, 2018 17:58
|
|
|
This is sort of silly to ask, but I'm genuinely curious about what the general consensus thinks about this after a discussion today at work. Is Hungarian notation in C#/VIsual Studio worth doing? All the devs hate it and the bosses demand it.
|
|
#
?
Aug 31, 2018 01:15
|
|
|
Magnetic North posted:This is sort of silly to ask, but I'm genuinely curious about what the general consensus thinks about this after a discussion today at work. Is Hungarian notation in C#/VIsual Studio worth doing? All the devs hate it and the bosses demand it. Like sUsername and dPrice and xXmlInput? Totally loving useless, and deeply offensive to all with a modicum of taste
|
|
#
?
Aug 31, 2018 01:33
|
|
|
If you need the type hints, then you need either a better IDE or a faster compiler.
|
|
#
?
Aug 31, 2018 02:03
|
|
|
Magnetic North posted:Hungarian notation NO
|
|
#
?
Aug 31, 2018 02:16
|
|
|
Hungarian notation is actually pretty different from what the guy who invented it intended, and what he proposed actually would be useful. The prefix is meant to be an informal descriptor of how the variable is used, not its type. The example he gave was (I think) something like this:code:Unfortunately somewhere along the way it got mutated to represent the type, and now it's a complete travesty.
|
|
#
?
Aug 31, 2018 02:21
|
|
|
Rookie question: Reading random programming articles, the impression that I get is Rust is so much safer than C. Lots of blogs keep reinforcing this. As someone who has never really delved in to low-level programming, is it that hard to write safe C? Do modern C books, tutorials etc... promote safe C coding or is it really that easy to shoot yourself in the foot?
|
|
#
?
Aug 31, 2018 03:17
|
|
|
what does this mean Hughmoris posted:Do modern C books, tutorials etc... promote safe C coding or is it really that easy to shoot yourself in the foot? Short answer, yes. I guess with the addition of all the bounds-checked functions that they added in C11 (such as gets_s), you could argue that "modern C" is trying to be more safe. But C still lets you do a lot of crazy things that you shouldn't do and that you didn't intend to do. Also, I don't think anyone uses all those functions that end in _s.
|
|
#
?
Aug 31, 2018 04:03
|
|
|
You can write safe C code, but you have to work at it. You can write unsafe Rust code, but you have to work at it.
|
|
#
?
Aug 31, 2018 04:07
|
|
|
qsvui posted:what does this mean and/or
|
|
#
?
Aug 31, 2018 04:16
|
|
|
ultrafilter posted:Even though that's legal code as far as the compiler is concerned, it doesn't make sense, and the prefix system is supposed to clue you in to that fact. OP, when you're making your case to management, is it "we hate it" or "we hate it and it's useless for what you want"?
|
|
#
?
Aug 31, 2018 18:04
|
|
|
Magnetic North posted:This is sort of silly to ask, but I'm genuinely curious about what the general consensus thinks about this after a discussion today at work. Is Hungarian notation in C#/VIsual Studio worth doing? All the devs hate it and the bosses demand it. quoting Bjarne Stroustrup, who is talking about C++, but it applies to C# as well http://www.stroustrup.com/bs_faq2.html#Hungarian quote:No I don't recommend "Hungarian". I regard "Hungarian" (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming - both of which emphasize selection of operations based on the type an arguments (known to the language or to the run-time support). In this case, "building the type of an object into names" simply complicates and minimizes abstraction. To various extent, I have similar problems with every scheme that embeds information about language-technical details (e.g., scope, storage class, syntactic category) into names. I agree that in some cases, building type hints into variable names can be helpful, but in general, and especially as software evolves, this becomes a maintenance hazard and a serious detriment to good code. Avoid it as the plague.
|
|
#
?
Aug 31, 2018 19:39
|
|
|
JawnV6 posted:Why not make them actual types and have a hard failure instead of a "hint" though? I've never understood this reliance on someone's eyeballs to catch these cases, it seems strictly worse. TBF, there's only so much you can do with most type systems, even really good ones. For instance, type systems for unit analysis doesn't tend to work well at compile time because you end up having to implement things like unit cancelling, specially named units, and compound units by hand for each unit you want to add to the program. Fine in many cases, less fine if you're dealing with even basic physics. I'm sure somebody has invented some macro or template explosion way of making this easier, but it's probably more prudent in most cases to just write foo_kg_m or kg_mFoo or whatever and get it over with.
|
|
#
?
Aug 31, 2018 20:41
|
|
|
Magnetic North posted:This is sort of silly to ask, but I'm genuinely curious about what the general consensus thinks about this after a discussion today at work. Is Hungarian notation in C#/VIsual Studio worth doing? All the devs hate it and the bosses demand it. do the bosses actually read the code? if not then gently caress 'em.
|
|
#
?
Aug 31, 2018 21:18
|
|
|
Uncle Bob in "Clean Code" says that you should avoid gratuitous information in variable names, and that modern IDEs reduce any usefulness of something like Hungarian Notation. He's not wrong. Read the chapter on naming things and push back on management if you feel comfortable. If you don't feel comfortable, or they shoot you down: your bosses dictating technology decisions, let alone bad ones that don't really provide any value, is a sign that you may want to get your experience and look for something better when the timing is right. Hungarian Notation itself isn't the end of the world, but this type of behavior can lead to bad things. It says something about the implied charter of the team, and shows that the developers don't have as much agency as they should.
|
|
#
?
Aug 31, 2018 22:06
|
|
|
Linear Zoetrope posted:TBF, there's only so much you can do with most type systems, even really good ones. For instance, type systems for unit analysis doesn't tend to work well at compile time because you end up having to implement things like unit cancelling, specially named units, and compound units by hand for each unit you want to add to the program. Fine in many cases, less fine if you're dealing with even basic physics. I'm sure somebody has invented some macro or template explosion way of making this easier, but it's probably more prudent in most cases to just write foo_kg_m or kg_mFoo or whatever and get it over with. F# has a unit system with all this stuff baked in and it’s incredibly useful in those few cases where you need it.
|
|
#
?
Aug 31, 2018 22:18
|
|
|
Thanks for all the replies. That was about what I expected to hear. Just making sure my coworkers were not being unreasonable when they said they'd had arguments in the past. This makes me realize why I hate it. Ints, doubles, whatever, I'll live and I might even help me from making a mistake with integer division as I am prone to do. But the idea that any object regardless of class/interface is always going to be preceded by obj is just bonkers to me.
|
|
#
?
Sep 1, 2018 00:32
|
|
|
I'd quit a job over Hungarian notation
|
|
#
?
Sep 1, 2018 02:09
|
|
|
Magnetic North posted:Thanks for all the replies. That was about what I expected to hear. Just making sure my coworkers were not being unreasonable when they said they'd had arguments in the past. What Linear Zoetrope said about types getting combinatoric when math is involved aside, I’m sort of deeply offended by hungarian notation in statically typed languages. Proper use of types combined with a half decent IDE together completely automate solving the problem that Hungarian notation aims to solve and have the advantage that they won’t ever desync with the real type information or make your variable names hideous looking.
|
|
#
?
Sep 1, 2018 02:29
|
|
|
I'll buck the trend here and suggest that practical considerations aside (Hungarian notation is not a good thing in C#) it's Not a Big Deal to prefix your variable with an extra character. If one lets go of the seething resentment at having their methods prescribed it may even be possible to enjoy the remaining real benefit of being saved the mouse / keyboard actions required to learn a type.
|
|
#
?
Sep 1, 2018 16:30
|
|
|
Magnetic North posted:Thanks for all the replies. That was about what I expected to hear. Just making sure my coworkers were not being unreasonable when they said they'd had arguments in the past. you can also say that it doesn't really follow best practice - microsoft itself says quote:Do not use Hungarian notation So it's somewhat incumbent on the person who wants hungarian notation to explain why you guys should deviate from the microsoft general naming conventions or industry standards.
|
|
#
?
Sep 1, 2018 16:33
|
|
|
Newf posted:I'll buck the trend here and suggest that practical considerations aside (Hungarian notation is not a good thing in C#) it's Not a Big Deal to prefix your variable with an extra character. If one lets go of the seething resentment at having their methods prescribed it may even be possible to enjoy the remaining real benefit of being saved the mouse / keyboard actions required to learn a type. The benefit of not having to use a mouse/keyboard action to learn a type comes at the expense of constant maintainance of the loosely coupled name and type. Said another way, there is no guarantee that an “iLatCoordinate” is an integer not a float and if you’re being thorough you should always go look at the type. So if you need to look at the type when you want to be thorough, what the heck is the point of doing the maintenance to keep the names correct? If you added a linter that enforced the hungarian names then my objection goes away but I’d still contend that Hungarian is wasted effort on the whole.
|
|
#
?
Sep 1, 2018 20:17
|
|
|
Bruegels Fuckbooks posted:for .NET in its naming convention. https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions quote:✓ DO choose easily readable identifier names. CanScrollHorizontally is reasonable and equally as clear as ScrollableX . However, it follows the same logical construct as AlignmentHorizontal which is something they say not to use. HorizontalAlignment is the equivalent of HorizontallyScrollCan or some other equally tedious variable name like CanHorizontallyScroll. I'd be annoyed as heck every time HorizontalAlignment appeared near another "HorizontalSomething" variable. Why put a sub-property before the supporting thing? It'd be like if language constructs had you call sin.Math, cos.Math to reference methods/functions associated with objects/namespaces. sin and cos are perhaps the worst example because Math is implied, but hopefully the intent shows through. I'm not a .NET developer so maybe I'm approaching this from the wrong perspective. Khorne fucked around with this message at 01:44 on Sep 2, 2018 |
|
#
?
Sep 2, 2018 01:26
|
|
|
They don't conflict though? It's just saying write in clear English, and HorizontalAlignment follows that because we usually put adjectives before the noun I mean yeah traditionally you'd put the noun first so all properties relating to the same thing look similar and end up grouped together, but this is their style. Maybe it's more readable for people new to programming, or people whose first language isn't English?
|
|
#
?
Sep 2, 2018 01:41
|
|
|
baka kaba posted:They don't conflict though? It's just saying write in clear English, and HorizontalAlignment follows that because we usually put adjectives before the noun We're checking if this is scrollable, in the x axis We're checking if this can do something, do what oh scroll, specifically horizontal We're dealing with horizontal, horizontal what *begins to panic*, oh alignment If we break out of English, you literally have: (subject) -> modifier for (Alignment) -> Horizontal, (Scrollable) -> X, (CanScroll) -> Horizontally modifier ?? (subject) for Horizontal ?? (Alignment) It's logically ambiguous and makes scanning code with multiple subjects tedious. If you're scanning over a block of code you literally don't have to read anything beyond A..n or Align or A..t to know what it deals with. You have to read the whole thing far more often when you put common and ambiguous words first. Especially when you have inconsistent logical ordering in variable names like the literal coding guide does there. Hungarian bothers me less than that because you can just read the first capital letter and ignore the often-junk prefix. It's advocating the Hungarian equivalent of just tossing variable type randomly within the variable name. Programming isn't reading and writing English, and the language most like English that's real popular (SQL) most people avoid. Anyhow, I probably have some weird outlier opinion because I tend not to think in a language. Even while doing things like writing or speaking. I'd never bother bringing anything like this up while working with others because it's minor pedantry, but it seems real weird to have a language style guide advocating something like that. Khorne fucked around with this message at 02:17 on Sep 2, 2018 |
|
#
?
Sep 2, 2018 01:52
|
|
|
Khorne posted:I'd never bother bringing anything like this up while working with others because it's minor pedantry, but it seems real weird to have a language style guide advocating something like that.  maybe the author of the conventions is trying to encourage pedantic fights during code reviews?
|
|
#
?
Sep 2, 2018 04:10
|
|
|
|
| # ? Jun 7, 2024 23:17 |
|
|
I'd argue that programming languages are becoming more like writing natural English - not entirely, obviously, and it obviously depends on the language, but compared to the stuff people wrote decades ago there's a hell of a lot more natural expression, like in Python for example. And conventions like breaking code out into well-named functions, so the main flow with the calls reads easily and you can follow it without having to dive into the details. People are encouraged to use syntactic sugar and use longer, meaningful variable names. Things change! And I agree it makes "more sense" to group properties by doing ThingAttribute, but that's because it's how I learned. I also know I don't do that consistently either - if you had some attibutes relating to a set of pages, would you call them CurrentPage and TotalPages? Or PageCurrent and PageTotal? The latter feels more awkward to me, and you see people mix and match the two styles a lot. And I'm not sure you lose much by having to read a full variable name, especially if it naturally expresses what a thing is without having to consider possible translations from programmer-speak ("ScrollableX" could mean anything until you've worked out what it does mean, and that's what takes time) Maybe the most annoying thing is stuff not being ordered reliably, so docs and autocomplete etc don't group all the properties together, but hell if you're ok with Hungarian notation - that messes up the ordering too, unless the properties all happen to be the same type so they all get lumped together (and you know which type to skip to). It doesn't seem like a big deal, and encouraging good, readable, consistent naming conventions is probably a bigger win (plus we have search so you can just type whatever part of the variable you like!) Also from a quick look around this isn't an unusual recommendation - a lot of style guides for various languages say to name things with nouns or noun phrases so they follow natural language rules, so they're more readable and semantically clear baka kaba fucked around with this message at 07:07 on Sep 2, 2018 |
|
#
?
Sep 2, 2018 07:05
|
|