Ask General Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ask General Programming Questions Not Worth Their Own Thread

«‹›671 »

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Peristalsis posted:

Committing locally just hasn't had much impact on my life.

You shut your mouth. Local commits are the best.

# ? Mar 6, 2017 15:32

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 23:56

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Code editor question: In the VS Code's release notes it goes into describing a file that is "dirty" when saving. What is a dirty file?

# ? Mar 6, 2017 18:10

nielsm: Jun 1, 2009

LP0 ON FIRE posted:

Code editor question: In the VS Code's release notes it goes into describing a file that is "dirty" when saving. What is a dirty file?

Dirty = has unsaved changes (usually)

# ? Mar 6, 2017 18:12

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

nielsm posted:

Dirty = has unsaved changes (usually)

Thank you!

# ? Mar 6, 2017 18:17

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

Also, the circle that replaces the X on tabs in VSCode is an example of what's called a "dirty flag"

# ? Mar 6, 2017 18:43

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Peristalsis posted:

I'm glad it's been revolutionary for you, but it hasn't made as big a difference in my work. Committing locally just hasn't had much impact on my life. If my hard drive crashes, I still lose my changes, even though I've "committed" them locally. I can certainly push my feature branches to remote servers, but then that's not really fundamentally different than if I had just created a new branch to work on in, say, SVN. Maybe git makes this easier than SVN, but that seems more evolutionary than revolutionary. And again, that benefit comes with drawbacks that seldom get mentioned.

The problem is you're confusing "source control" with "backup". The problems git solves aren't related to backup or data stability (though it does have a cool way to do that!), it's about tracking changes and revisions. If you're working on something and commit often, and something breaks, you can now have a better understanding of which change did it.

# ? Mar 6, 2017 19:13

JawnV6: Jul 4, 2004; So hot ...

Peristalsis posted:

In the particular post that started this discussion, a developer was complaining that merge conflicts were getting out of hand for their team, and file checkout is one way to prevent a lot of them.

My nightmare merge stories came from SVN with file checkout, I'm not sure why you think that one feature obviates All Merging Workflows. I'd much prefer dealing with the occasional tricky merge (after having a change set checked out for weeks and knowing it's coming) over trying to schedule every whitespace change with 4 people.

# ? Mar 6, 2017 19:42

Peristalsis: Apr 5, 2004; Move along.

Jewel posted:

Another upside: you can work entirely offline if your internet dies or you're on a laptop on a train or etc and still commit things. Hard drive dying isn't really an issue at all since you shouldn't have more than a day or two of commits around locally, but you should probably have more than one commit per day. I make a habit to push and pull at the end of each day, and if my changes are longform and need multiple days work, start a new branch for them.

Okay, so here's my (genuine, non-rhetorical) question: What's the difference between an uncommitted change, and one that is committed locally, but not pushed to origin? That is, what does committing locally buy you beyond just saving your work? Maybe there's some value there that I just don't appreciate.

Munkeymon posted:

You're right: something about their process is broken. I just assume that using locking source control will just lead to a time being wasted as people wait on each other.

It certainly might. The questions are:
1) Is it less wasted time than the current situation?
2) Aside from the amount of time wasted, is the end result (i.e. code quality) affected by switching between the approaches?

Normally, I've had enough work piled up that if I can't work on some project because someone else is modifying a file (which can happen even if team communication is the way you avoid complex merges), I can work on something else while I wait. At the end of a dev cycle, if everyone is waiting on one or two clowns to finish up some work on popular files, then yeah, you can lose a lot of time there. But I think it's uncommon to be in a situation where anyone on the team just has to sit around twiddling his thumbs in the middle of a dev cycle, while waiting for files to become available.

Munkeymon posted:

No, people can't just hand off single files. If you're not committing fully-functional features to the main branch at a time, you're not going to be able to do CI or automated testing - just because you picked a bad source control tool to try to work around deeper problems. I would spend all my time updating my resume and job hunting if I found myself on that sort of team.

In my experience (and with the config files and the tests I've written), adding a couple of new lines to a config file won't break any tests. Changing existing lines certainly might, but that wasn't the proposed scenario. That said, a bit of planning and communication can alleviate a lot of problems like this, too.

Munkeymon posted:

One quibble: you establish a workflow external to source control to do that, so having a flexible source control system is important or else you can't handle some scenarios that might be important for your team/situation.

Other than that, yeah, it can be hard to avoid stepping on each others' toes, but the way to fix that is with communication because, as I said above, throwing out feature-complete commits to get around restrictive source control means going without other, very important tools.

I'm not advocating for file checkout, I just mentioned it as an approach that can reduce the number of painful merges. The team I'm on now doesn't check out files. So far, I haven't had any really horrible merges, but it's just a matter of time.

I'm sure there are ways to get around the feature-complete commit issues, as well. They may or may not be more difficult or error-prone than not checking out files at all.

It's fine to talk about processes and team communication, but some teams will always have a flake or an rear end in a top hat on them who makes things harder for others. If firing them isn't an option (they may be quite talented, have seniority, or be the boss's brother-in-law), an enforced checkout system may help rein them in so others can work more easily.

But yes, file checkout can have significant drawbacks, especially if you don't work to mitigate them.

Thermopyle posted:

You shut your mouth. Local commits are the best.

No, you are. Wait, that's not quite right....

Suspicious Dish posted:

The problem is you're confusing "source control" with "backup". The problems git solves aren't related to backup or data stability (though it does have a cool way to do that!), it's about tracking changes and revisions. If you're working on something and commit often, and something breaks, you can now have a better understanding of which change did it.

So the value here is that committing locally triggers runs of the test suite that you might not otherwise make? (Again, I'm genuinely curious.)

At least two of my 5 programming jobs (including my current one) haven't automatically backed up individual developers' workstations. One definitely did, and the other two I just don't remember. In any case, source control does act as a backup for some of us.

JawnV6 posted:

My nightmare merge stories came from SVN with file checkout, I'm not sure why you think that one feature obviates All Merging Workflows. I'd much prefer dealing with the occasional tricky merge (after having a change set checked out for weeks and knowing it's coming) over trying to schedule every whitespace change with 4 people.

I don't think I said that, and I'm sure file checkout isn't appropriate for the scenario you just made up. That doesn't mean there aren't other situations where there are lots of tricky merges, and where the cost of coordinating file use is low, relative to the cost of those merges.

# ? Mar 6, 2017 21:07

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Peristalsis posted:

Okay, so here's my (genuine, non-rhetorical) question: What's the difference between an uncommitted change, and one that is committed locally, but not pushed to origin? That is, what does committing locally buy you beyond just saving your work? Maybe there's some value there that I just don't appreciate.

It certainly might. The questions are:
1) Is it less wasted time than the current situation?
2) Aside from the amount of time wasted, is the end result (i.e. code quality) affected by switching between the approaches?

Normally, I've had enough work piled up that if I can't work on some project because someone else is modifying a file (which can happen even if team communication is the way you avoid complex merges), I can work on something else while I wait. At the end of a dev cycle, if everyone is waiting on one or two clowns to finish up some work on popular files, then yeah, you can lose a lot of time there. But I think it's uncommon to be in a situation where anyone on the team just has to sit around twiddling his thumbs in the middle of a dev cycle, while waiting for files to become available.

In my experience (and with the config files and the tests I've written), adding a couple of new lines to a config file won't break any tests. Changing existing lines certainly might, but that wasn't the proposed scenario. That said, a bit of planning and communication can alleviate a lot of problems like this, too.

I'm not advocating for file checkout, I just mentioned it as an approach that can reduce the number of painful merges. The team I'm on now doesn't check out files. So far, I haven't had any really horrible merges, but it's just a matter of time.

I'm sure there are ways to get around the feature-complete commit issues, as well. They may or may not be more difficult or error-prone than not checking out files at all.

It's fine to talk about processes and team communication, but some teams will always have a flake or an rear end in a top hat on them who makes things harder for others. If firing them isn't an option (they may be quite talented, have seniority, or be the boss's brother-in-law), an enforced checkout system may help rein them in so others can work more easily.

But yes, file checkout can have significant drawbacks, especially if you don't work to mitigate them.

No, you are. Wait, that's not quite right....

So the value here is that committing locally triggers runs of the test suite that you might not otherwise make? (Again, I'm genuinely curious.)

At least two of my 5 programming jobs (including my current one) haven't automatically backed up individual developers' workstations. One definitely did, and the other two I just don't remember. In any case, source control does act as a backup for some of us.

I don't think I said that, and I'm sure file checkout isn't appropriate for the scenario you just made up. That doesn't mean there aren't other situations where there are lots of tricky merges, and where the cost of coordinating file use is low, relative to the cost of those merges.

Local commits let you stage work you're not ready to merge into the mainline in a way that lets you go back to a knowable state after you muck everything up. It's generally best to rebase all your dumb 'is this ok/well half this poo poo works' commits into a single commit before pushing upstream.

# ? Mar 6, 2017 21:24

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Peristalsis posted:

It certainly might. The questions are:
1) Is it less wasted time than the current situation?
2) Aside from the amount of time wasted, is the end result (i.e. code quality) affected by switching between the approaches?

Probably, considering most merges are still pretty quick or automatic and I assume that incentivizing people to work around source control limitations is going to make the codebase worse.

quote:

Normally, I've had enough work piled up that if I can't work on some project because someone else is modifying a file (which can happen even if team communication is the way you avoid complex merges), I can work on something else while I wait. At the end of a dev cycle, if everyone is waiting on one or two clowns to finish up some work on popular files, then yeah, you can lose a lot of time there. But I think it's uncommon to be in a situation where anyone on the team just has to sit around twiddling his thumbs in the middle of a dev cycle, while waiting for files to become available.

In my experience (and with the config files and the tests I've written), adding a couple of new lines to a config file won't break any tests. Changing existing lines certainly might, but that wasn't the proposed scenario. That said, a bit of planning and communication can alleviate a lot of problems like this, too.

For context, I'm thinking about 'configuration files' like the project and solution files that VS uses. If I want to add a file to the project, I have to check out the controlling file, so, in a locking system, I have to have exclusive access to that shared resource for some amount of time during which nobody else can add a file to that project or change certain settings. Then I have to check in the change and the files I added at the same time or the build will fail and there goes CI. Obviously, non-VS workflows are more flexible in this regard, but making junk committed just to get around source control 'features' is exactly the kind of annoying ceremony I want to avoid.

quote:

I'm sure there are ways to get around the feature-complete commit issues, as well. They may or may not be more difficult or error-prone than not checking out files at all.

I see it as a requirement anymore. If any particular commit (on the blessed master or central repo or whatever) doesn't Just Work (bugs aside) then it shouldn't have been made.

# ? Mar 6, 2017 21:32

JawnV6: Jul 4, 2004; So hot ...

Peristalsis posted:

I don't think I said that, and I'm sure file checkout isn't appropriate for the scenario you just made up. That doesn't mean there aren't other situations where there are lots of tricky merges, and where the cost of coordinating file use is low, relative to the cost of those merges.

I mean, in response to my merge story you posted this pithy bullshit:

Peristalsis posted:

The other option is to have a file checkout system that only allows one person at a time to modify any given file.

Which sounds a lot like "I don't think merges happen with file checkout."

# ? Mar 6, 2017 21:34

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Peristalsis posted:

Okay, so here's my (genuine, non-rhetorical) question: What's the difference between an uncommitted change, and one that is committed locally, but not pushed to origin? That is, what does committing locally buy you beyond just saving your work? Maybe there's some value there that I just don't appreciate.

Hack hack hack...okay, this looks good. *commit*
Repeat a few times
Hack hack hack...wait, poo poo, I just realized this thing over here is broken. When did I break it?
Check out older version of the codebase, see if it's broken as of that commit.
Repeat until you know what commit introduced the bug. Now you know within a fairly small window what possible changes could be the culprit.

This is a common enough use case that Git has built-in support for it via the "git bisect" command, which lets you do a binary search through your history, checking out commits, building/testing, and marking as good or bad, until you've narrowed in on the commit that broke your program. It is almost always faster than trying to debug from a clean slate.

(stealth edit: of course, ideally you have unit/integration tests that you can run locally which will tell you that you broke things, and in fact the first thing you should do after running git bisect is add a commit that adds said tests...but we don't always live in such ideal worlds)

# ? Mar 6, 2017 21:34

nielsm: Jun 1, 2009

The idea of local commits is that you can checkpoint your work without inconveniencing others with half-done things.

In more advanced use, it also lets you compartmentalize unrelated changes after the fact with history rewriting.

# ? Mar 6, 2017 22:01

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

Peristalsis posted:

So the value here is that committing locally triggers runs of the test suite that you might not otherwise make? (Again, I'm genuinely curious.)

No, it means you get a more granular history to bisect on when trying to identify the source of a bug.

e: A pretty big deal with local history is that you can branch locally. Make some experimental changes to your feature, abandon them, and maybe come back to them later. No need to add a new feature branch to the main repository for your little 10 minute digression.

Dr. Stab fucked around with this message at 22:51 on Mar 6, 2017

# ? Mar 6, 2017 22:44

nielsm: Jun 1, 2009

Another thing is, if you take advantage of frequently checkpointing with local commits, when you do have to merge it usually becomes smaller, easier merges you have to deal with.

# ? Mar 6, 2017 22:53

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

nielsm posted:

Another thing is, if you take advantage of frequently checkpointing with local commits, when you do have to merge it usually becomes smaller, easier merges you have to deal with.

This does depend on the granularity of the commits made to the master repo, which is part of why people should be encouraged to submit the smallest possible non-breaking changes in their commits, rather than doing the entire feature in a single commit.

# ? Mar 6, 2017 22:57

tricksnake: Nov 16, 2012

What is there to do/what should I do once I learn a programming language fully?

Make a freeware program? Try to freelance? I just don't know what the gently caress I'm doing.

# ? Mar 7, 2017 22:50

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

tricksnake posted:

What is there to do/what should I do once I learn a programming language fully?

Make a freeware program? Try to freelance? I just don't know what the gently caress I'm doing.

What do you want to do? Go do that. Find a project you like and contribute to it. Start your own project. Make a game. Make a website.

# ? Mar 7, 2017 23:00

tricksnake: Nov 16, 2012

TooMuchAbstraction posted:

What do you want to do? Go do that. Find a project you like and contribute to it. Start your own project. Make a game. Make a website.

So, where do I find cool projects? Where can I find serious problems that need to be fixed/improved? And, if you dont mind, forums where I can get along with other programmers... maybe even hackers. Even though that second one sounds kind of risky.

# ? Mar 7, 2017 23:05

nielsm: Jun 1, 2009

tricksnake posted:

So, where do I find cool projects? Where can I find serious problems that need to be fixed/improved? And, if you dont mind, forums where I can get along with other programmers... maybe even hackers. Even though that second one sounds kind of risky.

There's thousands of successful open source projects, chance is you're using at least some software developed by volunteers already. You can try looking out for that and see if it's something for you. Any project has a huge list of bugs that need investigation and fixing, and features waiting to be implemented.

# ? Mar 7, 2017 23:07

csammis: Aug 26, 2003; Mental Institution

How did you fully* learn a programming language without knowing its target audience and the problems it's used to solve?

Github is a start, but your definition of "cool" and "serious" may vary from what you can find in the open source world.

* no one ever learns a programming language fully, and even if you did that language and its libraries are going to keep changing.

e:

quote:

maybe even hackers. Even though that second one sounds kind of risky.

Are you saying you might have to visit the Dark Web? :aaa:

# ? Mar 7, 2017 23:08

tricksnake: Nov 16, 2012

csammis posted:

How did you fully* learn a programming language without knowing its target audience and the problems it's used to solve?

Github is a start, but your definition of "cool" and "serious" may vary from what you can find in the open source world.

* no one ever learns a programming language fully, and even if you did that language and its libraries are going to keep changing.

e:

Are you saying you might have to visit the Dark Web?

To me most languages look the same. I did the codecademy course on python to 100% completion. So basically I'm out of examples to solve and just kind of wondering what I'm supposed to do now...

edit: especially in terms of how to make money with this now

tricksnake fucked around with this message at 23:13 on Mar 7, 2017

# ? Mar 7, 2017 23:11

tricksnake: Nov 16, 2012

csammis posted:

e:

Are you saying you might have to visit the Dark Web?

No, hell no. That's so juvenile :colbert:

# ? Mar 7, 2017 23:12

csammis: Aug 26, 2003; Mental Institution

tricksnake posted:

To me most languages look the same.

You should disabuse yourself of that notion. Python in particular looks very little like the C-syntax based languages, which look very different from the Forth-like languages, which look very different from Haskell, which looks different from Scheme and Lisp, and so on and so on.

quote:

So basically I'm out of examples to solve and just kind of wondering what I'm supposed to do now...

I think it would be a good idea to do what TooMuchAbstraction, nielsm, and I suggested: go to Github, find a Python project that interests you, and start looking through the issues list.

# ? Mar 7, 2017 23:14

tricksnake: Nov 16, 2012

csammis posted:

You should disabuse yourself of that notion. Python in particular looks very little like the C-syntax based languages, which look very different from the Forth-like languages, which look very different from Haskell, which looks different from Scheme and Lisp, and so on and so on.

I think it would be a good idea to do what TooMuchAbstraction, nielsm, and I suggested: go to Github, find a Python project that interests you, and start looking through the issues list.

I mean I know they're different but I have yet to see an explanation of what the different langauges are used for other than operating systems specifically. (Reread: I just dont know what the gently caress I'm doing)

and

thanks for the github thing

# ? Mar 7, 2017 23:17

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

tricksnake posted:

To me most languages look the same. I did the codecademy course on python to 100% completion. So basically I'm out of examples to solve and just kind of wondering what I'm supposed to do now...

edit: especially in terms of how to make money with this now

If you don't have formal schooling (i.e. a college degree) then your options for making money are somewhat more limited. You can, however:

Build up a bunch of contributions to open-source projects, which you can list on a resume in lieu of a formal degree. Demonstrated experience can substitute for formal schooling at least some of the time.
Do programming-to-spec jobs (where someone solicits bids to build, e.g. a comments system, and programmers compete to provide the lowest bid). There's several websites for this kind of thing. My understanding for these systems is that they tend to be dominated by developers from low-cost-of-living countries, especially eastern Europe, so depending on your circumstances you may have trouble competing with their bids.
Tell your boss at your current job "Hey, I have this cool idea for something that would really help us out, can I spend some of my workdays working on it?"

If you're nervous about contributing to a project but still want to build experience, there's a ton of "write a program to solve this puzzle" sites out there. Probably the most famous is Project Euler, which will exercise your algorithm and math skills. Another one that comes to mind is Advent of Code 2016, which was an Advent calendar where each day was a separate programming challenge. They all basically take the format of presenting you with a problem statement, and then requiring you to submit the answer to the problem, where the answer can only reasonably be determined by writing a computer program. I wouldn't list this kind of stuff on a resume -- the answers can be googled and they're still "toy" problems (small scope and limited complexity, even if they're hard to solve).

EDIT: what languages are used for what is mostly just a matter of historical coincidence. C is used for a lot of "low-level" programming because historically it was your best option short of writing assembly code if you needed to get high performance, and nowadays it has a lot of libraries to help you out if you're doing that kind of low-level programming.

# ? Mar 7, 2017 23:20

csammis: Aug 26, 2003; Mental Institution

tricksnake posted:

I mean I know they're different but I have yet to see an explanation of what the different langauges are used for other than operating systems specifically.

Wikipedia has a quick overview: https://en.wikipedia.org/wiki/Comparison_of_programming_languages

It sounds like you're sort of going at this backwards. Let's say for example your idea of a cool and serious problem to solve involves writing the firmware that controls pacemakers. Usually someone with that as a goal wouldn't learn a random language and then try to apply it to the problem, they would learn what language is suited for that domain - C, arguably C++ or Rust - and go from there. You're doing the programming language equivalent of learning how to use a table saw and only then seeing what fancy woodworking can be accomplished with it.

What is your idea of a cool or serious problem?

# ? Mar 7, 2017 23:28

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

With the caveat that it's very common for people to prototype a solution to a problem in a language they're already familiar with, and Python is actually super-common for this "rapid prototyping". Programming languages are not as specialized as carpentry tools are.

# ? Mar 7, 2017 23:33

csammis: Aug 26, 2003; Mental Institution

Yeah you're right, I was oversimplifying a bit. I was just concentrating on not making a car analogy :saddowns:

# ? Mar 7, 2017 23:34

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

If you DO NOT have a technology-related degree, then you likely have two real options to become a professional developer:
The 'obvious' route is what has been advised: build a public portfolio on github, by either adding your own projects or contributing to others. It is still likely to be difficult.
The 'backdoor' route is to aim for a QA Automation Engineer role. GENERALLY speaking, you will still want some experience with an automation framework like Selenium, but also generally speaking people who are super talented at QA Automation seem to end up 'promoted' to developers as well, and so it's a bit of a meatgrinder of 'find someone who can automate tests, lose them to development, repeat'.'

# ? Mar 8, 2017 01:19

Paul MaudDib: May 3, 2006; TEAM NVIDIA:
FORUM POLICE

(Java here)

We have an absolutely crazy stew of code formatting styles going on in a project. I think we have at least 4 distinct combinations of indentation and bracing and we are only like a 6-person team, plus there's leftovers going back almost a decade. We even have mixed line endings everywhere.

At some point we're looking to fix a bunch of this (especially the line endings) - probably once the other team working on an earlier release gets their build out the door. But it'll be an indefinite period of time until then, and we're also not super thrilled about nuking all the git-blame information by normalizing everything, plus I worry the problem will only recur over time.

I really think we need something like checkstyle to keep us all mostly on the same page. Is this a viable way to standardize (and ideally enforce) indentation/etc? Most of the team is on Netbeans, I use a mix of IntelliJ and Netbeans, and another guy is all Eclipse. Is Checkstyle standard enough that we can get all those platforms to play along?

As for line endings - I personally think the proper fix here is "core.autocrlf=input" or "=true". Autocrlf-true has worked perfectly for me so far, I've actually re-done other people's commits to fix where Netbeans flipped out and renormalized the whole file (showed as 100% changed). I think Netbeans looks through the first 20 lines or so to decide what endings to use for a file - and if the wrong person adds something to the top of the file then it suddenly decides the file has the opposite format and changes all the line endings. When I soft-reset the commit to basically do a squash, suddenly my copy of git locks onto the actual changed lines instead of seeing everything as changed.

The one Eclipse guy runs Linux and he wanted to try a gitattributes approach - but that actually seemed to cause everything to normalize in a way that autocrlf didn't... is there anything we can do here to unfuck some of the formatting without totally screwing up our git-blame log? I personally find it really helpful to look back and see who wrote the code, what it was for, and how stale it might be, and we would instanuke that by reformatting line endings.

Personally I love the way IntelliJ does its code folding. I feel like a good fix until then might be for IntelliJ to just automatically reflow all the indent-soup back to some standard norm, but just in memory, without actually changing the files on the disk (unless I edit a particular block by myself). Is this possible with IntelliJ and/or with something else? Some combination of code reflow and a smarter diff that is less sensitive to whitespace/noise somehow?

I am also using Patience Diff right now and that's a big step forward in a lot of ways but it's still not perfect. Basically it tries to lock onto "high-content" lines that occur one time only in both versions of the file (things like function declarations), and then uses those as guideposts to subdivide the file into "zones", and then recurses on down. The idea being that it latches onto actual content instead of brackets and stuff. Much better than standard diff IMO but I would need something even finer, pretty much on a token-by-token level, which I think inherently limits me to something like IntelliJ that is content-aware...

Paul MaudDib fucked around with this message at 03:18 on Mar 8, 2017

# ? Mar 8, 2017 03:06

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

You can use git blame -w to ignore changes that only affected whitespace and instead get the patch that made the last real change to a line.

# ? Mar 8, 2017 03:20

redleader: Aug 18, 2005; Engage according to operational parameters

Maybe EditorConfig would be needs-suiting? I'm going to give it a shot with VS since VS2017 comes with out of the box support. Your big-name IDEs should have plug-ins or similar.

# ? Mar 8, 2017 05:50

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

redleader posted:

Maybe EditorConfig would be needs-suiting? I'm going to give it a shot with VS since VS2017 comes with out of the box support. Your big-name IDEs should have plug-ins or similar.

Yep, every project should use this now, it's great for enforcing basic standards and pretty much every editor has a plugin for it.

# ? Mar 8, 2017 06:01

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

tricksnake posted:

To me most languages look the same. I did the codecademy course on python to 100% completion. So basically I'm out of examples to solve and just kind of wondering what I'm supposed to do now...

edit: especially in terms of how to make money with this now

I really like CheckIO or however they write it, the puzzles usually have a narrative around the problem so it's like trying to solve a task, rather than the Euler-style 'go learn this mathematical theorem, and make a super-efficient solution to it because n = a kabillion'. Which is still a good skill to have, but I feel like it gets a bit samey

But those are still toy programs, you can collect them on a github or whatever to show people examples of your code, but you probably want to start learning how to work with other tools and how to structure an application. If you want to use Python, look at some of the areas people use it - scientific computing and working with data, making webservers with an API, creating a desktop application with a GUI...

When you get into those areas, you'll start learning new stuff, seeing what's possible and what other people have built for you to use. And you'll run into other toy problems to solve, like making a to-do list app with a webserver, or creating charts from World Bank data. Learning to approach a new paradigm and make use of available tools is an important skill, and you'll learn a lot from jumping in and playing around

And as well as giving you some experience to show off, hopefully that will give you an idea of what you want to pursue for work or even just for a project. The thing about different languages is that you can often pick and choose which you want to use for a certain thing, but usually there's one or two established as a standard, with an ecosystem of tools that are popular/required in that field. So knowing where you want to go and what you want to do will help you decide what to study next

Like if you want to do webdev? You'll have to learn JavaScript. Android apps? Java. Games? C++ and C# I think. Helping science? Python is definitely big there. There are definitely alternatives (and people will argue those are better too) but the usual suspects will make you more generally employable

Basically you're just getting started, chief :clint:

# ? Mar 8, 2017 07:06

Xerophyte: Mar 17, 2008; This space intentionally left blank

Paul MaudDib posted:

The one Eclipse guy runs Linux and he wanted to try a gitattributes approach - but that actually seemed to cause everything to normalize in a way that autocrlf didn't... is there anything we can do here to unfuck some of the formatting without totally screwing up our git-blame log? I personally find it really helpful to look back and see who wrote the code, what it was for, and how stale it might be, and we would instanuke that by reformatting line endings.

There are advantages to using .gitattributes to specify something other than auto for at least some types. For instance, we have .sh set to both checkout and commit as LF, since if they're checked out as CRLF they can't be run in a docker for windows container either. You can apparently use git filter-branch to retroactively change the line endings to be consistent for every commit since the dawn of time, but that's got a decent likelihood of causing worse issues than it solves. Also, git filter-branch scares me. Probably better to just make a fix commit and use blame -w as mentioned.

As for how to nbe consistent in the future, there is a lot of really good automation for most languages and it really helps. I'm not that familiar with tooling for Java, but I will gladly second EditorConfig as pretty great, we use it for visual studio, sublime text and xcode on various machine. On the automatic formatting front there's apparently Jindent and Jacobe for Java, in addition to the various IDE ones. I don't know how good they are but if you can create a config that matches what you want then they will make converging on a style much, much easier, especially for new devs.

Beyond that it's okay to roll your own enforcement scripts for simple things like line endings, even if you can't use a real linter for whatever reason. I took a couple of hours to write a 40 line python script that scans the code files in a directory for things we disallow like tabs and non-native line endings, then made it run as part of the build automation and fail any builds and block any PRs that don't pass. That and clang-format has helped to stop a decent bit of recidivism after we merged teams and style guides, since we can't use cpplint (which I'd much rather use, but oh well...), as well as help make sure our new devs do fewer obviously wrong things.

# ? Mar 8, 2017 07:58

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Paul MaudDib posted:

(Java here)

We have an absolutely crazy stew of code formatting styles going on in a project. I think we have at least 4 distinct combinations of indentation and bracing and we are only like a 6-person team, plus there's leftovers going back almost a decade. We even have mixed line endings everywhere.

At some point we're looking to fix a bunch of this (especially the line endings) - probably once the other team working on an earlier release gets their build out the door. But it'll be an indefinite period of time until then, and we're also not super thrilled about nuking all the git-blame information by normalizing everything, plus I worry the problem will only recur over time.

I really think we need something like checkstyle to keep us all mostly on the same page. Is this a viable way to standardize (and ideally enforce) indentation/etc? Most of the team is on Netbeans, I use a mix of IntelliJ and Netbeans, and another guy is all Eclipse. Is Checkstyle standard enough that we can get all those platforms to play along?

As for line endings - I personally think the proper fix here is "core.autocrlf=input" or "=true". Autocrlf-true has worked perfectly for me so far, I've actually re-done other people's commits to fix where Netbeans flipped out and renormalized the whole file (showed as 100% changed). I think Netbeans looks through the first 20 lines or so to decide what endings to use for a file - and if the wrong person adds something to the top of the file then it suddenly decides the file has the opposite format and changes all the line endings. When I soft-reset the commit to basically do a squash, suddenly my copy of git locks onto the actual changed lines instead of seeing everything as changed.

The one Eclipse guy runs Linux and he wanted to try a gitattributes approach - but that actually seemed to cause everything to normalize in a way that autocrlf didn't... is there anything we can do here to unfuck some of the formatting without totally screwing up our git-blame log? I personally find it really helpful to look back and see who wrote the code, what it was for, and how stale it might be, and we would instanuke that by reformatting line endings.

Personally I love the way IntelliJ does its code folding. I feel like a good fix until then might be for IntelliJ to just automatically reflow all the indent-soup back to some standard norm, but just in memory, without actually changing the files on the disk (unless I edit a particular block by myself). Is this possible with IntelliJ and/or with something else? Some combination of code reflow and a smarter diff that is less sensitive to whitespace/noise somehow?

I am also using Patience Diff right now and that's a big step forward in a lot of ways but it's still not perfect. Basically it tries to lock onto "high-content" lines that occur one time only in both versions of the file (things like function declarations), and then uses those as guideposts to subdivide the file into "zones", and then recurses on down. The idea being that it latches onto actual content instead of brackets and stuff. Much better than standard diff IMO but I would need something even finer, pretty much on a token-by-token level, which I think inherently limits me to something like IntelliJ that is content-aware...

You should be using a three pronged solution. First, to enforce local sanity, use an Editorconfig file and .gitattributes file.

To enforce team consistency you should be using the Maven checkstyle plugin or Gradle equivalent to enforce style on builds. All modern Java IDEs will do checkstyle-based linting while you're writing code so you shouldn't need to do anything else.

# ? Mar 8, 2017 14:11

9-Volt Assault: Jan 27, 2007; Beter twee tetten in de hand dan tien op de vlucht.

tricksnake posted:

To me most languages look the same. I did the codecademy course on python to 100% completion. So basically I'm out of examples to solve and just kind of wondering what I'm supposed to do now...

edit: especially in terms of how to make money with this now

If you only did codecademy you only know some syntax. You lack any CS fundamentals which you do need. Do something like the Harvard CS50 mooc at Edx, that uses C and python, to get some basic knowledge of memory management and algorithms and data structures and sql and flask and such. Or if you dont want to do C, MIT has a good intro to CS course that is pure Python, also at Edx.

This is also a good site with a lot of tutorials to give you some more ideas.

# ? Mar 8, 2017 14:43

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

carry on then posted:

Also, the circle that replaces the X on tabs in VSCode is an example of what's called a "dirty flag"

Good to know. It was apparent that it indicated unsaved changes, but I didn't know it was called that.

# ? Mar 8, 2017 17:54

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 23:56

dead gay comedy forums: Oct 21, 2011

Hey thread, beginner as well here. I am learning how to computers through Python 3 (more specifically John Zelle's Introduction to Computer Science, 2nd edition) besides other resources from the course I have started this year. So far, so good.

I am having a problem, though. John Zelle and others are big on using eval() to teach concepts, but after researching and learning a bit about it, there is a strong discouragement to rely on it for serious purposes because of the vulnerabilities it causes when it comes to Real and Proper projects.

So, I am trying to do the exercises in the book using either int() or float(), which is causing me a bit of a grief: basically, simple math exercises where it requires input from the user clunk the poo poo out of it, whereas using eval() make them work. For example,

Python code:

print("This is a program that calculates the slope a line in the cartesian plane.")
print()

def main():

    x1, y1 = input("Please insert the coordinates of the first point (format is x, y): ")
    x2, y2 = input("Please insert the coordinates of the second point (format is x, y): ")
    slope = ((y2 - y1) / (x2 - x1))
    print("The slope of the line is", slope, ".")
main()

#Works with eval, but I am not sure why it is not working with int/float

From what I have gathered from the error it gives, input() gives me a string, but when I declare it to be a float/int, it doesn't convert.

Of course, this may be very well over my head. Should I not bother with these details and just solve them by eval() to understand the gist of the problems (since this chapter is all about using python's math library) or this approach is worth learning at the level I am currently at?

Many thanks in advance

p.s. - I understand that this problem can happen more or less the same in other languages, so I hope it is in the correct thread

edit: used "quote" instead of "code" tags

dead gay comedy forums fucked around with this message at 19:31 on Mar 8, 2017

# ? Mar 8, 2017 18:44

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ask General Programming Questions Not Worth Their Own Thread

«‹›671 »