Open Turing - 20-40% Faster Open Source Version of Turing With New Features

[Tony]

http://learn.github.com/p/tagging.html

[mirhagk]

Amarylis @ Wed Nov 30, 2011 8:41 pm wrote:

mirhagk @ Wed Nov 30, 2011 7:20 am wrote:

Good news everybody, I convinced my school to switch to Open Turing. Now all of the students will have an easier time doing final projects.

Any tips on how I could convince my school to do the same? Just getting Turing itself in my school was apparently heck >.< The IT took it off because he couldn't find any license for it a while ago....

I'd suggest starting out by saying that Turing 4.1 is what, 4 years old now, without any updates. Open Turing is an open sourced version of it. Then you can tell him about the speed difference, which can be up to 40% faster. (One of my students has a game that shows this well, in 4.1 he gets 30FPS and huge lag every time he places an item, in OpenTuring he gets 40FPS and pretty much no lag). If you want you can wait till the release of the editor, because that is a pretty major improvement as well.

[trishume]

Tony @ Wed Nov 30, 2011 9:44 pm wrote:

http://learn.github.com/p/tagging.html

I see, originally I was going to use tagging but I couldn't decide which commit should be 1.0. Then I forgot about it.

Once I merge ttm's bug fix into master I'll tag it 1.0.

But then I also have to decide which version number system to use

My thinking: increment version number when new features are added but not for bug fixes (too many 'o them.)

Major features get a big version jump (I.E 1.5 for the new editor, 2.0 if I ever finish my compiler.)

For the compiler, I have a parser that recognizes almost all constructs and checks syntax.

[Tony]

major.minor[.build[.revision]]
http://en.wikipedia.org/wiki/Software_versioning#Sequence-based_identifiers

[Amarylis]

Versioning makes so much more sense to me now O.O

[Dan]

You may also want to look into creating some unit tests for OpenTuring: https://en.wikipedia.org/wiki/Unit_testing

It's importatnt for an open source software to get the process for devlopers worked out before much coding begins or everything will quickly become a mess. You should work to create a document outlining the practices and rules devlopers will follow including style guides for code, how code reviews will be performed, what test cases must accompany code and when and were it is appropriate to commit code.

It may also be a good idea to come up with a clear set of short term goals for the project. Are you just about fixing the bugs and imporving the performece of Turing or do you plan to also make addtions? How important is backwords compatability? Will you also be updating the Turing documenation? What if any support will you provide the comunity and how will it be given?

Making changes to the syntax of Turing should not be taken lightly or done at a whim. Before adding new features you may want to have a discussion about were to take the langue, how best to implment the syntax of new features and if that syntax is consistent with the old goals and implmention of turing.

[mirhagk]

Like I mentioned before, it might be an idea to keep two branches going, one will be a totally 4.1 backwards compatible program, maybe with new features and additional speed, and the other will break backwards compatibility slightly to add new features/change the way old features work. Kind of like how languages keep developing the last major version after a new major version is made.

[trishume]

Sure I will use standard version numbers.

I will not update all version numbers in the executable though (unless someone implements a version auto-update script to change the version in the .res files.
Find-replacing every time I fix a bug would take a lot of work.

The thing about Unit Tests is that the codebase is 200,000 lines of largely incomprehensible code. The code coverage of any unit tests that we could write would be so terrible it would not be worth doing.

Coding style guidelines would take a lot of effort. Which I don't have time to do. Simple Rule: Make it look like the code in the MIO module.

Don't worry about syntax and language feature changes for now. The parser, coder, etc.. are huge, ugly and hard to modify. Currently, my compiler (what I have) uses a parser generator (easy syntax mods) and a clean C++ AST. So language mods will be fairly easy with my compiler.

[Dan]

trishume @ 2nd December 2011, 8:17 am wrote:

The thing about Unit Tests is that the codebase is 200,000 lines of largely incomprehensible code. The code coverage of any unit tests that we could write would be so terrible it would not be worth doing.

Which is why the first task should be cleaning up the code base.


Edit:

Quote:

Don't worry about syntax and language feature changes for now. The parser, coder, etc.. are huge, ugly and hard to modify. Currently, my compiler (what I have) uses a parser generator (easy syntax mods) and a clean C++ AST. So language mods will be fairly easy with my compiler.

I have not had a chance to look to closely at the repo. Which parser generator is being used and were are the language grammar file for it in the repo?

[Tony]

trishume @ Fri Dec 02, 2011 8:17 am wrote:

Find-replacing every time I fix a bug would take a lot of work.

- a minor bug fix does not necessary warrants a new release
- version number should be defined in a single place

trishume @ Fri Dec 02, 2011 8:17 am wrote:

The thing about Unit Tests is that the codebase is 200,000 lines of largely incomprehensible code.

You can start by unit-testing any new code.

[trishume]

Dan, Cleaning the codebase would quite possibly be harder than rewriting it. That's why I'm working on the compiler. And no, I don't have the grammar files. They are probably with the turing plus code that originally generated the C.

Also, I noticed on the DWITE site it says there is a bug in the command line execution. Care to tell me what it is so I can fix it?

Tony, I will see what I can do about centralized version numbers (you could always do it yourself.) And if I add any major new features I will consider unit testing them. Most of my additions have been library interfaces, like OpenGL so not much to unit test.

I apologize for my non-enterprizey programming practices. I currently have a develop as fast as possible mentality. Brought about partially by my having many different things to do (iPad apps, application essays, Google Code-In, programming contests, maintaining our school's website, etc.) and by my ruby (do it fast and with little effort) backround.

I'm sure other people have things to as well or I would be getting a lot more pull requests on github.

[ProgrammingFun]

I think that along with github, this project deserves its own website (I would be willing to host a subdomain on my site but I think that CompSci.ca would be more appropriate, if not just openturing.org).

I would be willing to create the site provided that it is developed on WordPress (so that I won't need FTP access for most setup). What do you think?

[trishume]

Personally I think the github page with the read me is fine.

If someone wants to make it I can also host it. Or we could use github pages. (I.E openturing.github.com)
My domain is http://tristan.hume.ca/

Also I made a short url for the github page: http://git.io/opent
Yes, I know OpenT was something completely different.

[Amarylis]

Okay, so I'm trying to make it so .t files open with Open Turing as a default (as opposed to opening with Turing 4.1). Apparently my computer fails to recognize Open Turing's .exe as an actual program to open things with. Can anyone please help me? I really rather do enjoy Open Turing a lot more

[trishume]

I believe there is an option in preferences. If the option to associate .t files doesn't work I can try and if it.