Everypony is welcome to contribute to the code. Just download GitHub for desktop and you'll be able to pull/push the changes to the code.

This thread is primarily meant for coordination in project development.

Okay, so, I have to admit that I'm not very versed on GitHub yet.

I see there's a master code:
https://github.com/BadDragor/TextSeparatorSpellChecker

And a branched code:
https://github.com/sweetaibelle/TextSeparatorSpellChecker

I don't seem to have permission to push to the branched code, just to the master. For ease of development, since this is a community project, I suggest that the contributions are pushed to master. You can have branches, of course, but you won't get new updates since the community will be pushing to master and not your branch. At least I think that's the easiest way for everypony. Too many branches are a pain to support.

7758917
A pretty common way to do things on github is that you fork whatever project you are contributing to, keep the master branch the same as the main project, and then create new branches on the fork and when they are ready, create pr's from the branch on your fork.

That basically makes it so you don't have one person accidentally breaking the master branch of the main project, and usually contributors don't have permission to commit to the project directly anyways, unless the person whose project it is gives them rights to it.

The cleanup branch on the fork is the only one different from master at the moment.

--Sweetie Belle

7758918 You've done quite a cleanup, indeed. I guess I won't be able to be such a sloppy programmer with you around.

I've pushed cleanup changes to master as well.

Do you also have permission to push to master? Let me know if you're missing any permissions.

Anyways, we can talk about the next steps. What would you like to do? Do you have any questions/suggestions? Ideas for features? Proposals for project workflow?

I have a feeling this might be the start of something awesome.

7758919

You've done quite a cleanup, indeed. I guess I won't be able to be such a sloppy programmer with you around.

I've pushed cleanup changes to master as well.

Well, I may not be very familiar with VB.Net, but I'm familiar with cleaning up code and old codebases, and some of that's the same no matter what language it is. And VB.Net is pretty similar to VBA.

One thing that helped is I opened it up in Visual Studio Code as well as Visual Studio, and Code is great at searches. I started copying and pasting variable names into the search.

Also, cleaning up code gives me a better idea of how it works, and makes it easier to make changes later.

Though it should be noted that since the bin and obj folder aren't in git, that link at the beginning of this thread won't work. You usually don't actually want the executable in the git repository anyways, though. You just periodically do a release on github and attach a zip file with the executable and anything that should come with it in it.

Do you also have permission to push to master? Let me know if you're missing any permissions.

Not at the moment. If I tell it I want to edit a file, it tells me I don't have write access. I think "Settings->Collaboration and Teams" is where you'd change that.

Anyways, we can talk about the next steps. What would you like to do? Do you have any questions/suggestions? Ideas for features? Proposals for project workflow?

I have a feeling this might be the start of something awesome.

Right now, I wouldn't say I have any definite plans. Probably a bit more cleanup and refactoring. Partially just making sure I understand how everything works on my part.

Otherwise, there's an issue for adding a word counter, which, well, it probably wouldn't be too hard to add a basic one, anyways, though I suspect it wouldn't catch all cases.

I might mess around with the path fields a little.

It also seems to be like adding a basic editor into the program might be useful. Maybe add the ability to have it do spellchecking, and give us more statistics.

Mostly just brainstorming, though...

--Sweetie Belle

7758920

cleaning up code

You've done a fine job.

I always knew that declaring variables on top isn't the 'right' way to do it. It can even lead to bugs. However, debugging can be a bit easier when you don't lose information. When a catch exception occurs, you lose all the data about the variables declared in the try segment.

If you saw the code for my professional project, you'd lose your breath. Every second line is a global integer variable increased so that I can always know the exact line where the exception occurred even without having a million try catch-es.

I started copying and pasting variable names into the search.

You don't even have to do that. You just double-click the variable anywhere in the code and it highlights all the instances of this variable.

Though it should be noted that since the bin and obj folder aren't in git, that link at the beginning of this thread won't work.

I noticed and deleted the broken link in OP.

You usually don't actually want the executable in the git repository anyways, though. You just periodically do a release on github and attach a zip file with the executable and anything that should come with it in it.

I tried, but I failed.
https://github.com/BadDragor/TextSeparatorSpellChecker/releases/tag/release

Do you have to manually attach an executable file or can you set it up so that it's automatic?

Not at the moment. If I tell it I want to edit a file, it tells me I don't have write access. I think "Settings->Collaboration and Teams" is where you'd change that.

Done.

Probably a bit more cleanup and refactoring. Partially just making sure I understand how everything works on my part.

Let me know if you have any issues whatsoever.

Otherwise, there's an issue for adding a word counter, which, well, it probably wouldn't be too hard to add a basic one, anyways, though I suspect it wouldn't catch all cases.

We think so much alike.
https://github.com/BadDragor/TextSeparatorSpellChecker/issues/6

I might mess around with the path fields a little.

I'm thinking the default path could point to the executable directory (where exe is).
https://github.com/BadDragor/TextSeparatorSpellChecker/issues/9

There is an issue with the proposal though. If a user downloads the program to the Program Files folder then the story and grammar files might not have permission for access by the program.

Perhaps a better folder would be the Temporary folder that Windows uses. That folder has full control permissions. However, it might be a bit harder to navigate for a user. It also spreads the program to different locations. You can't just copy-paste the program to a different location that way because you're not copying all the needed files.

Pluses and minuses. I'm not sure which default directory would be the best choice.

It also seems to be like adding a basic editor into the program might be useful.

https://github.com/BadDragor/TextSeparatorSpellChecker/issues/10

Maybe add the ability to have it do spellchecking

https://github.com/BadDragor/TextSeparatorSpellChecker/issues/11

give us more statistics.

https://github.com/BadDragor/TextSeparatorSpellChecker/issues/12

Mostly just brainstorming, though...

Those are some good suggestions.

How do you propose we implement them
a) I implement them
b) You implement them
c) We share the load and each solves some of the issues
d) We do them together
e) We brainstorm first and then set priorities for each issue
?

7758925

You've done a fine job.

I always knew that declaring variables on top isn't the 'right' way to do it. It can even lead to bugs. However, debugging can be a bit easier when you don't lose information. When a catch exception occurs, you lose all the data about the variables declared in the try segment.

If you saw the code for my professional project, you'd lose your breath. Every second line is a global integer variable increased so that I can always know the exact line where the exception occurred even without having a million try catch-es.

Thanks!

Yeah, if you forgot to set i to 0, it could start at whatever it was last set to, for example. Having i as a global, and then the list of 9 or 10 temp variable, only two of which were used were really the first two things that got me looking at that.

Makes me wonder if there's a function with the current line number in it you could call or something...

You don't even have to do that. You just double-click the variable anywhere in the code and it highlights all the instances of this variable.

I did know about that one, since VBA does the same thing. When I search in VS Code, it comes up with a list of all the lines the search was used on, and goes to that line when you click on any item, though. It's nice for getting an overview, as you can just sorta look down the list and get a quick idea if there are any issues, like every instance of the variable being commented out, or writing to it but not reading from it, that sort of thing.

In Linux, I tend to use Visual Studio Code when programming a fair amount...

I tried, but I failed.
https://github.com/BadDragor/TextSeparatorSpellChecker/releases/tag/release

Do you have to manually attach an executable file or can you set it up so that it's automatic?

I think for a release, you'd manually attach them. I mostly know what it says here, and it shows an area you can attach binaries:
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

I know there are ways with C++ to set up a robot to automatically compile binaries every commit and such, but I've never tried to do that, and I don't know if they'd work for VB.net anyways.

We think so much alike.
https://github.com/BadDragor/TextSeparatorSpellChecker/issues/6

I did kinda see that issue. I actually saw a simple way to count words over here:
https://www.dotnetperls.com/word-count-vbnet

So we could just run that after loading the file, then save the number of words and display it someplace.

I'm thinking the default path could point to the executable directory (where exe is).
https://github.com/BadDragor/TextSeparatorSpellChecker/issues/9

There is an issue with the proposal though. If a user downloads the program to the Program Files folder then the story and grammar files might not have permission for access by the program.

Perhaps a better folder would be the Temporary folder that Windows uses. That folder has full control permissions. However, it might be a bit harder to navigate for a user. It also spreads the program to different locations. You can't just copy-paste the program to a different location that way because you're not copying all the needed files.

Pluses and minuses. I'm not sure which default directory would be the best choice.

Same directory as the executable is what I'd tend towards, or maybe the Documents folder for the current user. Maybe test to see if the directory is writeable, and have it try a few paths.

I was actually thinking of the actual path controls on the dialog, though. Haven't committed it anywhere yet, but I did this:

(The Browse buttons work, btw...)

One thing on the editor idea. What we could do is have a new window that shows the whole story in a textbox, and lets you make changes and save and load and such from there, have that be the main window, then you launch running the grammar check from that window, and it opens the current window as a second window and shows all the grammar checking information.

That's one of these things that would probably be a major release, and definitely farther future, though. (Make the text field a rich text field and you could set words to red or yellow that were issues?)

Those are some good suggestions.

How do you propose we implement them
a) I implement them
b) You implement them
c) We share the load and each solves some of the issues
d) We do them together
e) We brainstorm first and then set priorities for each issue
?

Well, if we've got them as issues in the project, I'd pretty much say whomever gets inspired to work on them, works on them. Generally, I'd say whenever one of us is working on a new feature, do it in a new branch, and if one of us runs into trouble, the other can always pick up where they left off in that branch.

Immediate statistics that come to mind are number of chars, words, and paragraphs, btw. But you could always throw in things like most commonly used words, or even grade level of the vocabulary in the story, if you can figure out how to calculate it.

We could throw in being able to generate a markov chain from the current file, but that's more along the line of fun things to program than things we actually need...

--Sweetie Belle

7758925
I went ahead and added a zip file to that release you did with a Release version of the executable in it, btw...

--Sweetie Belle

7758931

Yeah, if you forgot to set i to 0, it could start at whatever it was last set to, for example.

That's the bad part. However, the good part is that wherever you stop the code, you can know how many times a code cycled last.

We can stick to the 'correct' way if you want. Your way is the correct way.

Having i as a global, and then the list of 9 or 10 temp variable, only two of which were used were really the first two things that got me looking at that.

I usually do that for all my classes for debugging purposes or temp variables.

Makes me wonder if there's a function with the current line number in it you could call or something...

I doubt it. The release version doesn't contain comment lines. So, even if there was such a function, the release version would throw out a number that wouldn't be much helpful in debugging purposes.

In one of my programs, I have a function with 50k lines. The function cannot be shortened. If only one line fails, the whole function fails. I've been able to resolve many client issues just by seeing the 'line number' variable in the msgBox. I currently don't have an alternative to this very bad programming practice.

I think for a release, you'd manually attach them.

Sounds like extra work.
How about we just un-hide the bin\debug\TextSeperator.exe for now? It only gets generated if the project compiles. Sure, it may be buggy, but it will always be the latest version.

If the project becomes bigger, we can do it the right way. What say you?

I know there are ways with C++ to set up a robot to automatically compile binaries every commit and such, but I've never tried to do that, and I don't know if they'd work for VB.net anyways.

I'm not sure if this problem is even solvable. Maybe future us can deal with this?

I did kinda see that issue. I actually saw a simple way to count words over here:
https://www.dotnetperls.com/word-count-vbnet

We should definitely use this.

So we could just run that after loading the file, then save the number of words and display it someplace.

I'll throw tabControl on the form today (edit: done). That way we can mostly keep the program in just one window and have plenty of space to throw stuff at the same time.

Same directory as the executable is what I'd tend towards, or maybe the Documents folder for the current user. Maybe test to see if the directory is writeable, and have it try a few paths.

Best to just keep everything in the same place, I think. That way the program instantly works even if you copy it to somewhere else.

I was actually thinking of the actual path controls on the dialog, though. Haven't committed it anywhere yet, but I did this:
(The Browse buttons work, btw...)

Double-click also works, btw.

One thing on the editor idea. What we could do is have a new window that shows the whole story in a textbox, and lets you make changes and save and load and such from there, have that be the main window, then you launch running the grammar check from that window, and it opens the current window as a second window and shows all the grammar checking information.

That's one of these things that would probably be a major release, and definitely farther future, though.

I'll just make it into a new tab for now and load it together with dataGridView. After that we can upgrade or change it.

(Make the text field a rich text field and you could set words to red or yellow that were issues?)

I think that's doable.

Well, if we've got them as issues in the project, I'd pretty much say whomever gets inspired to work on them, works on them. Generally,

Sounds like a good idea.

I'd say whenever one of us is working on a new feature, do it in a new branch, and if one of us runs into trouble, the other can always pick up where they left off in that branch.

Yes, that's probably the right way to do it. It might take me some time to get a hang of managing the branches. I've had bad experiences with them before, but as long as they can be merged there shouldn't be an issue.

Immediate statistics that come to mind are number of chars, words, and paragraphs, btw. But you could always throw in things like most commonly used words

That's doable.

, or even grade level of the vocabulary in the story, if you can figure out how to calculate it.

That's high-level stuff. I don't think this project is at that stage yet.

The existing solutions don't work very well. Our solution would work even worse. I'm not sure if such information would be usable.

We could throw in being able to generate a markov chain from the current file, but that's more along the line of fun things to program than things we actually need...

Haven't done those before.

I think one of our goals should be that the program is usable for people.

(edit: done) Thanks for the added file. Which solution should we implement:
a) Leave the old tested version as release until we remember to update it to a new version manualy.
b) Unhide the exe file in the code project.
d) Do extra work every time we add something to the project.
?

What are your thoughts on the development team? Should we try to promote this project and get more people on board? Or should we let the project promote itself as it becomes better?

7758940

That's the bad part. However, the good part is that wherever you stop the code, you can know how many times a code cycled last.

We can stick to the 'correct' way if you want. Your way is the correct way.

If it's more convenient to use a global while initially programming something, I can always clean it up later, too...

I doubt it. The release version doesn't contain comment lines. So, even if there was such a function, the release version would throw out a number that wouldn't be much helpful in debugging purposes.

In one of my programs, I have a function with 50k lines. The function cannot be shortened. If only one line fails, the whole function fails. I've been able to resolve many client issues just by seeing the 'line number' variable in the msgBox. I currently don't have an alternative to this very bad programming practice.

Searching around, this looks useful...
https://stackoverflow.com/questions/13460656/how-to-use-stacktrace-to-return-error-line-number-in-vb-net

In one of my programs, I have a function with 50k lines. The function cannot be shortened. If only one line fails, the whole function fails. I've been able to resolve many client issues just by seeing the 'line number' variable in the msgBox. I currently don't have an alternative to this very bad programming practice.

Doesn't sound like fun...

Sounds like extra work.
How about we just un-hide the bin\debug\TextSeperator.exe for now? It only gets generated if the project compiles. Sure, it may be buggy, but it will always be the latest version.

If the project becomes bigger, we can do it the right way. What say you?

I already added the current exe to the release you did earlier. I can always do that again when we get to a point that we're ready for another release...

I'll throw tabControl on the form today. That way we can mostly keep the program in just one window and have plenty of space to throw stuff at the same time.

Alright.

Double-click also works, btw.

Yeah, I moved that code to a function and made both call it. Didn't realise that worked until I was already creating buttons, tho'.

Yes, that's probably the right way to do it. It might take me some time to get a hang of managing the branches. I've had bad experiences with them before, but as long as they can be merged there shouldn't be an issue.

The main time it gets to be an issue is if things change on the main branch that conflict with the one you are working on. I have had to do some ugly rebases before...

That's high-level stuff. I don't think this project is at that stage yet.

The existing solutions don't work very well. Our solution would work even worse. I'm not sure if such information would be usable.

Yeah, that can wait until a time when one of us is feeling ambitious.

Haven't done those before.

I think one of our goals should be that the program is usable for people.

It's a fun project for when learning a programming language or such, but would be a little out of scope here.

You make a list of all the words in the story, and what the word following them are. Then you start with one word, pick one of the words following it in the list at random, and do the same thing for that word in a loop. It generates nonsense text, but pretty fun nonsense text, especially if you combine two stories in the list, so the generated text wanders between them.

I think the technique is actually used in text analysis, too, but don't know the details on that.

(edit: done) Thanks for the added file. Which solution should we implement:
a) Leave the old tested version as release until we remember to update it to a new version manualy.
b) Unhide the exe file in the code project.
d) Do extra work every time we add something to the project.
?

I'd say that old tested version is probably fine for now, and once we've made enough progress, I can go ahead and make another release. We don't really need a new version every time we do something. If someone really wants to try out every change, they can compile it.
(There'd also be no guarantee that both the Release and Debug executable would be up to date with every commit, as it might not have been built with both...)

What are your thoughts on the development team? Should we try to promote this project and get more people on board? Or should we let the project promote itself as it becomes better?

For now, I'd say we already have this thread going, so interested people can join in on the conversation here. We can wait on promoting it more until later, I think. This group does have 53 members...

--Sweetie Belle

7758944

If it's more convenient to use a global while initially programming something, I can always clean it up later, too...

Nah, maybe it's time for me to learn to program the right way.

Searching around, this looks useful...

That does look useful. I'll play around with it when I have some time.

Doesn't sound like fun...

I made a program just for inserting every second line with a variable and a number, so it doesn't take much time.

I already added the current exe to the release you did earlier. I can always do that again when we get to a point that we're ready for another release...

You always pick the right way to solve problems. I think I may stop calling myself a programmer in your presence.

Alright.

Done. With tabs, we now have infinite space to work with.

Yeah, I moved that code to a function and made both call it. Didn't realise that worked until I was already creating buttons, tho'.

I doubt anypony would think to double-click a textbox, so buttons might actually be a good idea. We can also leave the old feature for the advanced users.

The main time it gets to be an issue is if things change on the main branch that conflict with the one you are working on. I have had to do some ugly rebases before...

If I understand you correctly, you'll be angry with me. I just made changes directly on the master.

So, if I change the master, I create problems for your branch? But If I make my own branch and then merge my branch with the master, your branch can merge also? Am I understanding correctly?

I think one of our goals should be that the program is usable for people.

It's a fun project for when learning a programming language or such, but would be a little out of scope here.

You make a list of all the words in the story, and what the word following them are. Then you start with one word, pick one of the words following it in the list at random, and do the same thing for that word in a loop. It generates nonsense text, but pretty fun nonsense text, especially if you combine two stories in the list, so the generated text wanders between them.

I think the technique is actually used in text analysis, too, but don't know the details on that.

Now that we have tabs, you have plenty of space. You can just create a new tab for any project you imagine and want to play with. What you describe would give a feel for the writing. You could probably get a sense of the atmosphere from it.

I'd say that old tested version is probably fine for now, and once we've made enough progress, I can go ahead and make another release. We don't really need a new version every time we do something. If someone really wants to try out every change, they can compile it.

Deal.

For now, I'd say we already have this thread going, so interested people can join in on the conversation here. We can wait on promoting it more until later, I think. This group does have 53 members...

Indeed.

7758956

You always pick the right way to solve problems. I think I may stop calling myself a programmer in your presence.

Thanks!

Honestly, that tends to be one of the things I'm good at. That and finding things.

As far as git goes, under a different username, I contribute to a pretty large open source project (with ancient code in places as well). When I was originally contributing, it was on svn and kinda a free for all, with everyone committing straight to the main project directly. I went inactive on that project for a long while for reasons, and when I came back, things had switched to git and I had to learn the whole workflow there, so that's a large part of why I know how everything works on github.

I doubt anypony would think to double-click a textbox, so buttons might actually be a good idea. We can also leave the old feature for the advanced users.

That's basically what I was figuring.

If I understand you correctly, you'll be angry with me. I just made changes directly on the master.

So, if I change the master, I create problems for your branch? But If I make my own branch and then merge my branch with the master, your branch can merge also? Am I understanding correctly?

I think one of our goals should be that the program is usable for people.

Well, it's better to work in a branch to avoid conflict in code, but it isn't the end of the world. I can do a rebase, and if none of the same lines changed, it wouldn't be too difficult. And with this change, it's simple enough that I could easily just redo it if it gets complicated.

These things will happen from time to time anyways if you have multiple branches waiting to get in. In a large project, the way it would usually work is that one person would pr a change, and then another person would review it, possibly request changes, and then approve and commit it.

This is a smaller project, so we can get away with writing directly to master more. When there's only two people, there's going to be less review of things. But I'm used to working on a project where it's a major deal if the master branch is broken for any length of time...

Having the program be easy to use is definitely a big goal, though, and actually one of the things I tend to focus on.

Now that we have tabs, you have plenty of space. You can just create a new tab for any project you imagine and want to play with. What you describe would give a feel for the writing. You could probably get a sense of the atmosphere from it.

More space to add things in is always useful.

Apparently one of the actual uses for markov chains besides generating nonsense is that you can compare the tables of two stories, and it'll tell you how similar they are to each other. That's probably how those websites that tell you what author your story is most similar to work, actually...

--Sweetie Belle

7759088

As far as git goes, under a different username, I contribute to a pretty large open source project

I've never actually used GitHub in collaboration before, so I'm still trying to catch my bearings and clicking random buttons.

That's basically what I was figuring.

While it's just us and we're in the phase of throwing features on it, you can just implement your changes as often as you can. That way there'll be less conflicts. If we figure out that something doesn't work, we can still hide it after it's implemented. So if you get any idea you can just make it and push it to master. That would also make it easier for me to familiarize myself with it and work with it in mind.

I know that what I suggest isn't the 'right' way, but it would make it easier for us to develop this project. If we just push things to master, we never have to wait for each other and we spend less time reviewing, testing, approving, merging branches, solving conflicts; and more time actually programming.

Of course, if others join, we'd have to transition to the right way of doing it.

Well, it's better to work in a branch to avoid conflict in code, but it isn't the end of the world. I can do a rebase, and if none of the same lines changed, it wouldn't be too difficult. And with this change, it's simple enough that I could easily just redo it if it gets complicated.

These things will happen from time to time anyways if you have multiple branches waiting to get in. In a large project, the way it would usually work is that one person would pr a change, and then another person would review it, possibly request changes, and then approve and commit it.

This is a smaller project, so we can get away with writing directly to master more. When there's only two people, there's going to be less review of things. But I'm used to working on a project where it's a major deal if the master branch is broken for any length of time...

If I understand correctly any changes to the same code will result in a conflict weather we use branches or if we write to master. The project also has a working old version exe for anypony who wants to use it, so even if has issues it's not a big deal. And besides, we wouldn't push if we had errors in the code anyway, so the master should mostly be more or less stable (excluding all the bugs).

What I'm asking is, does it make your pushing any harder if I push directly to master? I think working of off my own branch would take me more time. If that would save time on your side (because of easier pushing) I'll do it, but if you gain no benefits from me using a branch, it might be easier for me to just push directly to the master. So, please just tell me whether you want me to use my own branch that I push to master or if I can push directly to master.

More space to add things in is always useful.

Even if you ran out of space on a tab, it has horizontal and vertical scrollbars (I think). In the worst-case scenario, we can strap an extra panel to the tap that has scrollbars 100%.

My point is, we will never run out of space. The design should probably be the very last thing we do when we know about all the features that we end up with.

Apparently one of the actual uses for markov chains besides generating nonsense is that you can compare the tables of two stories, and it'll tell you how similar they are to each other. That's probably how those websites that tell you what author your story is most similar to work, actually...

That does sound like fun. It wouldn't be the first thing on my mind if I were editing stories, but the more features, the merrier.

The only issue I see now is the problem of synchronization between different tabs. However, if we save data to the source file on tab.leave and initialize the tab on tab.enter, we can avoid the synchronization problem altogether. The only downside I see is that some features will be disconnected with each other even if there was a potential for interaction. Then again, this could also be a plus. We'd avoid loads of bugs. If you try to do the interaction between every feature then it becomes exponentially complex. Adding a feature is easy, but if you have to connect it to 100 other features, it's 100 times harder. And with every new feature, it only gets exponentially harder.

7759111

I've never actually used GitHub in collaboration before, so I'm still trying to catch my bearings and clicking random buttons.

Certainly been there.

If you want us to both be committing straight to master for the moment, we can do that. Just keep in mind that if the project gets larger, we'll want to start doing things on branches and prs.

Also, if you find yourself working on something that's going to break the program for a while, it might be best to do that on a branch.

The way conflicts and rebasing works is this:
If I'm working on a branch, and there have been commits to the master branch in the meantime, I make sure all my changes are committed locally, then checkout the master branch, and do a pull, to bring it back up to date. Then, I do "git rebase master <branch>". That command tries to take the commits I've done on the branch, and put that on top of current master, and make that the new branch. A lot of times that'll work.

Where it runs into trouble is if, say, I've edited line 170 of a file in the branch, and that line has also been edited in master. Then it tells me what files have conflicts, and I have to tell it how to resolve them. That's where things get tricky...

That does sound like fun. It wouldn't be the first thing on my mind if I were editing stories, but the more features, the merrier.

It's definitely a fun thing to play with,!

The only issue I see now is the problem of synchronization between different tabs. However, if we save data to the source file on tab.leave and initialize the tab on tab.enter, we can avoid the synchronization problem altogether. The only downside I see is that some features will be disconnected with each other even if there was a potential for interaction. Then again, this could also be a plus. We'd avoid loads of bugs. If you try to do the interaction between every feature then it becomes exponentially complex. Adding a feature is easy, but if you have to connect it to 100 other features, it's 100 times harder. And with every new feature, it only gets exponentially harder.

I was already thinking we'd probably want to compartmentalise things a bit, ultimately. What I'll likely be doing is creating new classes, and moving code to them from the form code, until the form code mostly has to do with the form itself.

Saving when going between tabs does work. As long as we don't make changes to the actual story file itself without letting the user know, we're likely fine...

--Sweetie Belle

7759185

If you want us to both be committing straight to master for the moment, we can do that.

Given that we're compartmentalizing things on different tabs and that the code will mostly run when you get to that tab, master shouldn't be broken too much in development.

I'll push my project that compiles to master. If we come across a situation where branching would cause fewer conflicts, I'll start using the branches.

Another reason why I think easy and regular pushes might be good is that vb.net uses autogenerated designer code. Whenever you add a button or any other element, the designer gets regenerated. It can be a pain to resolve conflicts in the designer.

You've probably already experienced this when you tried pulling my design changes over your added buttons. If you pushed your buttons right after you added them, this conflict could have been avoided.

Just keep in mind that if the project gets larger, we'll want to start doing things on branches and prs.

I will. The only reason why I'm suggesting the bad way is that I think it might save some time for both of us.

Also, if you find yourself working on something that's going to break the program for a while, it might be best to do that on a branch.

I'll keep that in mind.

The way conflicts and rebasing works is this:
If I'm working on a branch, and there have been commits to the master branch in the meantime, I make sure all my changes are committed locally, then checkout the master branch, and do a pull, to bring it back up to date. Then, I do "git rebase master <branch>". That command tries to take the commits I've done on the branch, and put that on top of current master, and make that the new branch. A lot of times that'll work.

So, the majority of conflict-solving happens on branches? And when conflicts are resolved the push to master is a cakewalk.

If I understand this correctly, the conflicts can only arise after master gets updated from a branch or directly and that happens when pulling from master (committing updated master to branch).

In my bad scenario, the conflicts can get resolved both when pulling from master to local master and when pushing to updated master.

Where it runs into trouble is if, say, I've edited line 170 of a file in the branch, and that line has also been edited in master. Then it tells me what files have conflicts, and I have to tell it how to resolve them. That's where things get tricky...

I think that scenario demands manual resolution in both methods anyway. However, with regular push/pull we might be able to decrease such scenarios.

It's definitely a fun thing to play with,!

I'm glad you're enjoying the journey.

I do have to admit that I came up with a sinister goal tonight. I say sinister because I'm not sure if knighty would approve.

The thing is, the majority of stories need help. This program already detects some mistakes that are 100% mistakes (and not just potential mistakes). It's not reasonable to assume that everypony will use this program, especially since Windows give a bunch of warnings when you download an .exe file from the internet.

The thing I was thinking about today was automation that could skip this step and deliver the results straight to users.

What can be technically done is this:
The program can access the internet and download html of URL-s. A feature could download stories one by one automatically. Parsing the story from html would be tricky, but I think it's doable.

After that, the program could only check for 100% mistakes.

When one is detected, a Fimfiction-compatible comment could be automatically generated.

And here comes the most diabolical last part of automation:

And even after that, an automation could be employed in one of two ways:
a) Fimfiction acceps some manipulation via scripts. Clicking a button on Fimfiction is basically a call to a Fimfiction function. Either that or the button could probably be clicked with a script. I'm werry weak on the web, so I'm not sure about all this.
b) A clicking script can be implemented on Windows itself. After the comment is generated, the application could call it and comment would automatically be posted on the appropriate story.

If you believe this might be morally bad, we could skip the last step of automation.

Then again, you probably know the joke about good programmers:
Only a bad programmer would be willing to develop a function that drops a nuke on New York.
A good programmer would never do such a thing. Instead, a good programmer would develop a function that accepts the name of a city as a parameter. You know, because hardcoding a city name into code is bad practice.

Anyways, let me know if you think that we're threading too much on the dark side with this idea.

I was already thinking we'd probably want to compartmentalise things a bit, ultimately. What I'll likely be doing is creating new classes, and moving code to them from the form code, until the form code mostly has to do with the form itself.

One thing we could do first is create a class for functions. In the form class itself, we would then only have functions for events. But the unbound functions within the event functions would be called from a separate global module. That way the functions can be called even without specifying the class name first.

Saving when going between tabs does work.

The first tab might be a bit tricky, though, because the same paragraph can be stated multiple times if it has more than one 'mistake' in it. One thing that could be done is to save it every time a user exits the cell and a change is detected. Upon that, a save would occur then a reinitialization. It would result in a bad user experience, but that's not even the primary feature. The way the program was meant to be used thus far is that the user clicks at a cell and then ctrl+F on Gdoc for a manual fix. I'm not sure if many users will be willing to replace the GDoc content with the notepad file content.

What user process do you imagine? How would a user get from a GDoc with mistakes to fixed GDoc with the use of this program in between?

As long as we don't make changes to the actual story file itself without letting the user know, we're likely fine...

If a user clicks a change or does the change itself, then that's a confirmation from the user that she wants to commit these changes.

7759243

Given that we're compartmentalizing things on different tabs and that the code will mostly run when you get to that tab, master shouldn't be broken too much in development.

I'll push my project that compiles to master. If we come across a situation where branching would cause fewer conflicts, I'll start using the branches.

Given I've committed a few things, hopefully you don't run into any trouble there...

Another reason why I think easy and regular pushes might be good is that vb.net uses autogenerated designer code. Whenever you add a button or any other element, the designer gets regenerated. It can be a pain to resolve conflicts in the designer.

You've probably already experienced this when you tried pulling my design changes over your added buttons. If you pushed your buttons right after you added them, this conflict could have been avoided.

Those changes were easy enough that I'm not too worried about doing them again.

So, the majority of conflict-solving happens on branches? And when conflicts are resolved the push to master is a cakewalk.

If I understand this correctly, the conflicts can only arise after master gets updated from a branch or directly and that happens when pulling from master (committing updated master to branch).

In my bad scenario, the conflicts can get resolved both when pulling from master to local master and when pushing to updated master.

It usually happens to me with branches. It's possible for it to happen when changes have happened on master since you last updated when you're trying to push a change to master. (And it's basically the same rebase except that you are doing it against the origin master, IIRC...)

The program can access the internet and download html of URL-s. A feature could download stories one by one automatically. Parsing the story from html would be tricky, but I think it's doable.

Not needed. There's an option to download as a text file.

Anyways, let me know if you think that we're threading too much on the dark side with this idea.

I wouldn't fully automate it. First, if the program glitches out, it might be obvious as an automated message. There'd also be a temptation to loop it and have it go through a bunch of fics, and that could potentially be caught by the fimfiction staff (basically seeing a bunch of comments faster then anyone could type them). And anything I post is something I'm responsible for, and I wouldn't really want to post anything I hadn't personally reviewed first.

(Also, if a bunch of people start using this program to post automatic comments, someone will notice that a bunch of stories have comments with the exact same format, and if they look into it, the programs right there and the people lasted as authors would be the most obvious people to go after.)

Having an option to automatically download a story and load it into the tool isn't in itself a bad thing. (and we could download it through fimfetch and not even touch the fimfiction servers, potentially.). BBCode tools might be nice, too.

One thing we could do first is create a class for functions. In the form class itself, we would then only have functions for events. But the unbound functions within the event functions would be called from a separate global module. That way the functions can be called even without specifying the class name first.

I was largely thinking we could add several classes. For example, you could have a story class that has a string with the actual text of the story, the arraylist for it, number of line and all the stats, and has most of the functions for reading it in and such.

I have already started moving some things to separate functions, and once you've factored the functions out, it's easier to move them.

What user process do you imagine? How would a user get from a GDoc with mistakes to fixed GDoc with the use of this program in between?

Not absolutely sure yet. Honestly, it might be nice if it saved a report with all the issues it found and stats on the document that you could go over at your leisure...

--Sweetie Belle

7759261

Given I've committed a few things, hopefully you don't run into any trouble there...

If you were able to push it from branch it means that you've already resolved all the conflicts. And since I keep myself more or less sinchronised with master, I should get zero conflicts.

Those changes were easy enough that I'm not too worried about doing them again.

The more often you push, the less conflicts you'll have. And don't worry about the bugs. The sooner you push them, the sooner they'll be detected on master. I know that's the bad way to do it, but we're not running a rocket software here. Bugs are just happy challenges.

It usually happens to me with branches. It's possible for it to happen when changes have happened on master since you last updated when you're trying to push a change to master. (And it's basically the same rebase except that you are doing it against the origin master, IIRC...)

I think it's best to just push often. So push your features first, talk about them later might be the way to go.

Not needed. There's an option to download as a text file.

I doubt it has an URL, though. You'd have to use webScripts to get to that file, I think.

I wouldn't fully automate it.

You're right. The last part of automation is too sinister. But we can still automate it up to then, right? Whenever people give a review, they can attach the auto-generated grammar comment as well.

First, if the program glitches out, it might be obvious as an automated message.

After a few messages, it would become obvious even if it didn't glitch out.

There'd also be a temptation to loop it and have it go through a bunch of fics

This feature would be every grammar nazi's wet dream. One could automatically criticize ALL stories on Fimfiction with this feature without even breaking a sweat.

We need to keep repeating this mantra to ourselves: With great power comes great responsibility!

, and that could potentially be caught by the fimfiction staff (basically seeing a bunch of comments faster then anyone could type them).

I'm pretty sure knighty wouldn't be happy about bots commenting on stories. I mean, it's for the greater good, but often the road to Hell is paved with good intentions.

And anything I post is something I'm responsible for, and I wouldn't really want to post anything I hadn't personally reviewed first.

Then again, if you're confident in your code...

(Also, if a bunch of people start using this program to post automatic comments, someone will notice that a bunch of stories have comments with the exact same format, and if they look into it, the programs right there and the people lasted as authors would be the most obvious people to go after.)

That is a very realistic scenario, you know? The more we develop this program, the likelier this scenario becomes. Eventually, we will have to face this. It's unavoidable.

Having an option to automatically download a story and load it into the tool isn't in itself a bad thing. (and we could download it through fimfetch and not even touch the fimfiction servers, potentially.).

We wouldn't be the first to automatically access Fimfiction URLs. I don't see too much harm in that, even if we access Fimfiction directly. I'm not sure how often Fimfech updates. It wouldn't be very useful to the reader.

Accessing GDoc directly would be useful, but it wouldn't be easy to parse text from it. Then again, there are probably tools for that.

The textBox that accepts the source could also accept URLs. The program itself could then try to parse Fimfiction or Gdoc or whatever else users use.

BBCode tools might be nice, too.

In worst case scenario, we could develop them ourselves. It shouldn't be too hard.

I was largely thinking we could add several classes. For example, you could have a story class that has a string with the actual text of the story, the arraylist for it, number of line and all the stats, and has most of the functions for reading it in and such.

What you say sounds like the right way to do it. In my professional project, however, I just have one global class with a million lines and hundreds of functions.

Sometimes, I forget the class and the exact function name. Lots of time can be wasted just searching and navigating. Would your classes be public in a way that you wouldn't even need to know the name of the class to use it's function? That would be useful because we could just use IntelliSense to find appropriate functions.

I feel like you're turning me into Good Dragon with all your best practices and the correct ways of programming. I don't know how I feel about that. You're uncorrupting me!

I have already started moving some things to separate functions, and once you've factored the functions out, it's easier to move them.

Order might not be my middle name, but it does seems to be yours. Keep up the good work and push often.

What user process do you imagine? How would a user get from a GDoc with mistakes to fixed GDoc with the use of this program in between?

Not absolutely sure yet. Honestly, it might be nice if it saved a report with all the issues it found and stats on the document that you could go over at your leisure...

I think this is something that we should figure out.

If nopony is willing to copy paste a notepad file over their Gdoc, all our saving changes and reinitialization might be a waste of effort if nopony will use that.

The way I used this program on all my stories is I used the paragraph to search on GDoc and fix directly at its source. If I pasted notepad over my Gdoc, I'd lose all the italics and titles.

How do you personally feel about the current feature that requires you to ctrl+F in GDoc?

Btw. if you click on a cell, it automatically copies the content to clipBoard (I think) for easier search in GDoc.

7759274

I doubt it has an URL, though. You'd have to use webScripts to get to that file, I think.

Try this url:
https://www.fimfiction.net/story/download/126539/txt

(Though it looks like smart quotes may be an issue...)

That is a very realistic scenario, you know? The more we develop this program, the likelier this scenario becomes. Eventually, we will have to face this. It's unavoidable.

It is, realistically, the part that would worry me the most.

We wouldn't be the first to automatically access Fimfiction URLs.

I actually had code written at one point (in Ruby) that would pull links to all the stories in all the folders in a group. I remember a site blog post afterwards against programs that access fimfiction, though, and decided to stop messing with it...

What you say sounds like the right way to do it. In my professional project, however, I just have one global class with a million lines and hundreds of functions.

Sometimes, I forget the class and the exact function name. Lots of time can be wasted just searching and navigating. Would your classes be public in a way that you wouldn't even need to know the name of the class to use it's function? That would be useful because we could just use IntelliSense to find appropriate functions.

It'd be in a file just like Class1.vb, and those are public. That's also part of why you try to make the class and function names pretty obvious, though.

I feel like you're turning me into Good Dragon with all your best practices and the correct ways of programming. I don't know how I feel about that. You're uncorrupting me!

Well, a lot of this is because good code is easier to read and understand and debug, especially if you haven't looked at it in a while or haven't gotten much sleep. And the larger a project, the more you want it to be easy to work with.

It sucks when no one is fixing up and improving the ui of a program because no one wants to touch that area of the code...

How do you personally feel about the current feature that requires you to ctrl+F in GDoc?

Not sure. It's one of these areas where we could really use feedback from people actively using it...

--Sweetie Belle

7759296

Try this url:
https://www.fimfiction.net/story/download/126539/txt

Wow, so every story already has a generated .txt file on Fimfiction server. I didn't know that. I sense dark potential in this.

(Though it looks like smart quotes may be an issue...)

What do you mean by 'smart quotes'? What issues do you predict?

It is, realistically, the part that would worry me the most.

The goal justifies the means, right? Our pursuit is noble, right? The results may turn out spammy, but it will be a good kind of spam, you know?

I actually had code written at one point (in Ruby) that would pull links to all the stories in all the folders in a group. I remember a site blog post afterwards against programs that access fimfiction, though, and decided to stop messing with it...

Technically, there's no way to know whether a program accessed the URL or the real person. So, everypony who use this program would always have deniability on their side.

It'd be in a file just like Class1.vb, and those are public. That's also part of why you try to make the class and function names pretty obvious, though.

I feel some functions may fall between classes because they'll perform multiple things. But if we make it so that you don't have to name the class to use the function, that won't be an issue in using functions anyway.

Well, a lot of this is because good code is easier to read and understand and debug, especially if you haven't looked at it in a while or haven't gotten much sleep. And the larger a project, the more you want it to be easy to work with.

The long term goal is for this project to grow big, so it might, indeed, be a good idea to start it the right way in its foundations.

It sucks when no one is fixing up and improving the ui of a program because no one wants to touch that area of the code...

The UI shouldn't be much of an issue, actually. You just throw elements on the form in the designer. Not much coding needed. And there's basically just one way to handle events.

It's basically just the functions that may be hard to read.

Not sure. It's one of these areas where we could really use feedback from people actively using it...

I'm not sure how many active users there are, actually. From my experiences, I always want to edit changes at the source which is GDoc. And since texts can have italic texts, imports from notepad are not viable.

I feel that if we pursue your route, we'll have to save things directly to GDoc. I'm not sure how viable that actually is. Also, if we read from Gdoc, the italics format might be hard to retain without breaking the phrase detection code.

One option would be to just postpone the saving feature to the future us and rely on ctrl+F use case instead in the first phase of the project. If it turns out that people actually delete their GDocs and replace them with Notepad content, we can develop that later.

I know this messes with your vision for the project a bit, but it would save us from a lot of headaches and it would shield us from developing features that nopony would use.

Oh, and if you have ideas for the features, just put them in the issues segment of GitHub. I do wonder though if it wouldn't be better to just create a thread for every feature here. I don't like the lack of notifications when somepony comments on GitHub. I feel like the forums here have more features.

Again, I know it's not the right way to do it. The right way is to have all issues neatly at the project site, but I feel it would be much more accessible to the first adopters if it was here. People would have an easier time forming threads here than registering for GitHub.

Then again, it will be threads galore. We'd also have to make up a tagging system so we could keep track of the statuses of the threads. What do you think?

7759299

What do you mean by 'smart quotes'? What issues do you predict?

Just a potential issue. Quotes that aren't smart look the same no matter where they are. Smart quote look different depending on whether they are on the left or right, curving or angled around whatever is inside them.

Another difference with smart quotes is neither symbol is the same as an actual quote. Some text editors may show them as garbage, and if your code is looking for a quote mark, it may not recognise them as such.

The goal justifies the means, right? Our pursuit is noble, right? The results may turn out spammy, but it will be a good kind of spam, you know?

In my experience, no type of spam is good spam, and I'm pretty sure if someone gets an automated comment with issues on every single story of theirs, they aren't going to be that appreciative.

Technically, there's no way to know whether a program accessed the URL or the real person. So, everypony who use this program would always have deniability on their side.

Speed between requests is the main thing. That, and depending on the behavior, they might not care if it's a program or a person.

No spam. This includes chain letters, referral links, posting the same thing many times in different places, and anything that involves, or encourages other users to, repost identical or similar content. This excludes posting information about your new story in groups that explicitly allow it.

One option would be to just postpone the saving feature to the future us and rely on ctrl+F use case instead in the first phase of the project. If it turns out that people actually delete their GDocs and replace them with Notepad content, we can develop that later.

The ability to save it as a report doesn't have to actually replace any of the existing functionality...

Then again, it will be threads galore. We'd also have to make up a tagging system so we could keep track of the statuses of the threads. What do you think?

I'd suggest having one thread that we discuss new feature ideas and suggestions, and posting all of them in that thread. I think people'd be more likely to comment in one general suggestion thread then in a whole bunch of specific ones...

--Sweetie Belle

7759307

Just a potential issue. Quotes that aren't smart look the same no matter where they are. Smart quote look different depending on whether they are on the left or right, curving or angled around whatever is inside them.

Another difference with smart quotes is neither symbol is the same as an actual quote. Some text editors may show them as garbage, and if your code is looking for a quote mark, it may not recognise them as such.

There's no reason for anypony to use them, right? If so, our code can just replace them for regular quotes.

In my experience, no type of spam is good spam, and I'm pretty sure if someone gets an automated comment with issues on every single story of theirs, they aren't going to be that appreciative.

I'd be appreciative if somepony did this to my stories.

Speed between requests is the main thing. That, and depending on the behavior, they might not care if it's a program or a person.

The program would just download one chapter at a time. It would be less stress on knighty's server than if a person manually downloaded .txt file.

No spam. This includes chain letters, referral links, posting the same thing many times in different places, and anything that involves, or encourages other users to, repost identical or similar content. This excludes posting information about your new story in groups that explicitly allow it.

No two comments would ever be similar, though. Every comment would be tailored specifically for that exact chapter.

The ability to save it as a report doesn't have to actually replace any of the existing functionality...

You mean the results of the program? Mistakes, suggestions, etc...?

My suggestion would be to have a 'Resutls' tab where all results would be posted and formatted for Fimfiction comment style.

We wouldn't be changing the source file, though. At least not in the first phase. Do you concur?

I'd suggest having one thread that we discuss new feature ideas and suggestions, and posting all of them in that thread.

I'm actually against this idea. Immagine 200 suggestions in just one thread with no indication of which one has already been resolved and which not.

I like how you can create a new issue for every feature in GitHub. I just miss notification to know if you commented on one. That's mostly the reason for my suggestion of 1 thread = 1 functionality.

I think people'd be more likely to comment in one general suggestion thread then in a whole bunch of specific ones...

How about we do both? One thread for suggestions which we then copy as threads that represent tasks?