Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 DWITE io allotted time
Index -> CompSci.ca, Contests -> DWITE
Goto page Previous  1, 2, 3  Next
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
Tony




PostPosted: Sat Dec 03, 2011 5:18 pm   Post subject: RE:DWITE io allotted time

2. doesn't make much sense to grab an arbitrary point in dev and call it v1.0.0. Is it stable and tested and feature complete?
3. if dev is more stable than master, you are doing it backwards.
4. doesn't matter. Test new code.


I know that it's fun to hack on new features, and ignore testing, documentation, bug fixes, all of this "software project maintenance" stuff... but it's required for the project to be taken seriously.
Latest from compsci.ca/blog: Tony's programming blog. DWITE - a programming contest.
Sponsor
Sponsor
Sponsor
sponsor
Dan




PostPosted: Sat Dec 03, 2011 5:51 pm   Post subject: Re: DWITE io allotted time

trishume @ 3rd December 2011, 4:41 pm wrote:

1. What problem does it have with the judge? I know it is a hack. The interpreter is deeply integrated with the editor, so real command line would be difficult.


For one it seems to run it more like a daemon or background task then a noraml interpreter. This means that to the judge the program exits right away tricking it into thinking the program is done when it is just starting. For now i am getting around this issue by using the testsuite mode which exits appropriately.

Another large issue (tho this has allways been the case with Turing) is that it is hard to get stdio from it. I know the debug menu has some options realting to stdio redirection but i have not had time to fully explore it. Also the testsuite mode seems to dump the IO to a file which might be a good place to start looking for an easy way to dump it to the console.

Finaly, Turing is in desperate need of having the IDE, complier and interpreter separated. A stand alone interpertater and complier would also make testing much easier. It's proably one of the first features i would recomend working on.

trishume @ 3rd December 2011, 4:41 pm wrote:

2. Versioning is coming once I merge the current development.


You realy should only be mergering development to main as a release of some kind in my opinion (tho that could be what you mean).

trishume wrote:

I just need someone to test the current dev branch, as I have not compiled it and do not want to boot up my VM and test it. If some native windows person (ttm?) compiles and tests it I can merge the dev branch and tag it v1.0.0. Then I will start versioning.


This is why automated testing is needed. Also commiting code with out testing it is normaly looked down upon in most open source projects (even if it is the devlopment branch). Once you get more developers, having broken code in the repo is a masive pain in the ass.

trishume wrote:

3. We do use a dev branch. Look at the github network.


I was going by all the "opps" commits in the master branch.

trishume wrote:

The current package.zip is the packaged release (often more stable than master.)


This is proably not the best way to do releases. You realy should try to not have binary builds in your source controll and having a more stable binary only releases as a zip in your less stable master branch is a bit odd.

trishume wrote:

4. I also have little free time. No one has time, or will possibly ever have time to write the thousands of required unit tests.


Thats no reason to not include tests for your new code. Also you could make some general tests that at least let you know some of the basics work. It may be a good idea to start looking into possible framework for testing VC++ code.

Quote:

Even the current Turing 4.1.1 is not unit tested.


May be not unit tested but their was some primitive testing, private betas and a release system. Besides the idea (i assume) is to improve Turing, and better testing would be such an improvment.

Quote:

5. Right. Only basic looking at all changes and running a limited test suite. But then again, no big changes that could cause huge problems have been made.


Since Turing 4.1.2 was not even ready for public release, it may be hard to say just how buggy it is to start with out more testing. Also adding 3D and hashmaps are not exactly minor changes.

Quote:

6. Yup. No one (myself included) wants to write documentation.


This is proably the bigest issue of all. Other types of programs can get by with poor documentation, however for a programming language the documentation is almost more important then the code. If a feature of the language is undocumented it might as well not exist.

Quote:

7. Basic plan: current -> new editor in Qt -> JIT compiler in LLVM -> cross-platform std lib -> fully cross-platform and compilable to executable.


Why the editor? If you are going to scrap the Turing IDE (proably a good idea) why try to rereinvent the wheel when many IDEs allready exist which would only need a new plugin/file for the syntax?

If you are going to scrap all of the Turing code and start over why commit time to maintaing and extending the Turing 4.1.2 code? It seems a better place to start would be getting a full description of the Turing grammar down that is backwords comptable with 4.1.2. Some other projects (e.g. OpenT) have attempted this but most come to the realization that it will take as much work as creating any other programming language and Turing does not have a big enough comunity to make recreating it worth while rather then making a new eductional language that may have a broader interest.

Personally I think starting from scratch with the proper tools is desperately needed, but it's not going to be easy to convice peoleop to work on a dead language.

Quote:

8. Github issues. I check them and fix anything pressing.


It's not a bad start, tho most projects move on to their own tracker, wiki, site, etc.



I realy don't mean to be overly negative, i just don't want to see the project die out like the others. To attract new devlopers to Turing you are going to need a strong project. Right now it may be hard to have more then one or two devlopers working on OpenTuring with out running into large software engineering issues.
Computer Science Canada Help with programming in C, C++, Java, PHP, Ruby, Turing, VB and more!
crossley7




PostPosted: Sat Dec 03, 2011 8:46 pm   Post subject: RE:DWITE io allotted time

I'm fairly busy right now, but if I find at some point that I have a large amount of free time, I could start helping with some documentation (don't trust myself to help develop too much fresh code without any proper learning for efficient algorithms). However, this could be months down the road and I would test out those features at the same time as writing the documentation for them.

But then again, this would be only if you feel comfortable with a high school student helping out with the project.
Tony




PostPosted: Sat Dec 03, 2011 8:56 pm   Post subject: Re: RE:DWITE io allotted time

crossley7 @ Sat Dec 03, 2011 8:46 pm wrote:
don't trust myself to help develop too much fresh code without any proper learning for efficient algorithms

ideally a project maintainer would review and comment on changes before granting a pull request.
Latest from compsci.ca/blog: Tony's programming blog. DWITE - a programming contest.
crossley7




PostPosted: Sat Dec 03, 2011 8:59 pm   Post subject: RE:DWITE io allotted time

Even if they would, my code is incredibly ugly and can be a nightmare to read. (if you have seen my dwite solutions you would know) I wouldn't want to force anyone to try to read it at this point. I'm trying to improve it but will go with my compsci class in school to do that.
ttm




PostPosted: Sat Dec 03, 2011 10:33 pm   Post subject: Re: DWITE io allotted time

A few things.

-Hi crossley7, we'd love to have you help; we're still in high school too.
-I don't think anyone's being too negative. The project is kinda at a sucky baby state right now.
-Another issue, our current planning system relies heavily on that evil tool called Facebook Chat >.<
-Having compsci.ca host a project page would be much appreciated, but we don't have a website yet
-We can make do with git's built-in bug tracker for now.
-I'll get started fixing up the documentation soon (this weekend busy as hell Neutral seems like the world is due Monday)
-How do you propose we get started with unit testing?
-Your guidance is appreciated.
Tony




PostPosted: Sat Dec 03, 2011 11:15 pm   Post subject: Re: DWITE io allotted time

ttm @ Sat Dec 03, 2011 10:33 pm wrote:

-Having compsci.ca host a project page would be much appreciated, but we don't have a website yet

what kind of a website are you thinking of

ttm @ Sat Dec 03, 2011 10:33 pm wrote:

-How do you propose we get started with unit testing?

research your options and find a decent unit testing framework that will be compatible with this project.
Latest from compsci.ca/blog: Tony's programming blog. DWITE - a programming contest.
trishume




PostPosted: Sun Dec 04, 2011 9:26 am   Post subject: Re: DWITE io allotted time

What I meant by minor changes was no changes that are good targets for unit testing. OpenGL is a library interface with no computation.

I have actually done testing (not huge industry-level testing but some) I have test suite files for both hash maps and OpenGL that I used to find bugs. I am now fairly confident in those features. For language testing I run my Turing in turing interpreter, which uses almost all turing language features (OO,exceptions,casting,pointers, etc...)

Thus I am fairly confident in those features. The master as dev thing was when I was learning github and developing on my own machine. That stopped as soon as I pushed to github. And the dev branch is always less stable than master.

Also, that time was the first time I had committed uncompiled code? Why? Ttm had made those changes and tested them but totally f'd up the git repo in his learning process. So I rolled back his changes and redid the good changes myself. I just needed them compiled to test for typos in the 10 characters I changed. The oops was me forgetting to add one of the changes ttm made.

I'm tagging this version 1.0 because:
- It is fairly stable and tested (80+ people and the only bug found is your -run one.) I know this isn't as good as unit testing, but it is pretty good.
- I have to make something 1.0 or else not have version numbers. Which people seem to want.
Sponsor
Sponsor
Sponsor
sponsor
ttm




PostPosted: Sun Dec 04, 2011 2:22 pm   Post subject: Re: DWITE io allotted time

Ah-hem.

-What about the 9000+ places where it says Turing when it should say OpenTuring
-What about the bug where if you copy OpenTuring to another folder the splash and icons revert
-The editor crash bug still happens if you're holding down a letter and double click
-Structure complete doesn't completing functions marked as pervasive or body
-Lack of documentation of new features, etc etc.
-New features don't have syntax highlighting
-The drawpic function doesn't actually work
-etc

Not that these are going to be solved immediately, but there's more than 1 bug.

Anyways. I think 1.0 should have been just the exact original 4.1.12 with only a splash and name change, with hashmaps and whatever in 1.1, but seeing as 1.0 has already been done, there's not much we can do about that.

Quote:

what kind of a website are you thinking of

Like this maybe? Will need additional planning.

Quote:

research your options and find a decent unit testing framework that will be compatible with this project.

Doesn't really help but ok. VS has built-in unit testing features that may work.
Tony




PostPosted: Sun Dec 04, 2011 2:40 pm   Post subject: RE:DWITE io allotted time

bugtracker -- github's or otherwise. It's unreasonable to keep track of bugs in forum posts.

versioning -- could very well start at v0.1.x. If, for whatever reason, it must be 1.x, then maybe 1.0.0_RC1 ?

Website -- Project Pages at github http://pages.github.com/ is likely your best bet. That could even be hooked up with a custom domain.

I'm not going to tell you what specific testing framework to use, just nudge you in the right direction. Open this up as an issue, propose choices, invite discussion. This might seem mundane at the surface, but it will (well, should) become an integral part of the project.

This is absolutely amazing -- http://www.sqlite.org/testing.html
Quote:

By comparison, the project has 1177 times as much test code and test scripts

Quote:

extensive testing also plays a vital role in maintaining and improving the quality of SQLite. This document has summarized the testing procedures that every release of SQLite undergoes with the hopes of inspiring the reader to understand that SQLite is suitable for use in mission-critical applications.


Sure, OpenTuring might not have a goal of "production use". Fine. But you'd have a much easier time convincing people (teachers, school boards?) to switch from Turing, if you can show a reasonable level of stability. (A solid test suite also makes it incredibly easier to develop new features in the long run. This is from years of industry experience.)
Latest from compsci.ca/blog: Tony's programming blog. DWITE - a programming contest.
trishume




PostPosted: Sun Dec 04, 2011 4:19 pm   Post subject: Re: DWITE io allotted time

ttm @ Sun Dec 04, 2011 2:22 pm wrote:
Ah-hem.

-What about the 9000+ places where it says Turing when it should say OpenTuring
-What about the bug where if you copy OpenTuring to another folder the splash and icons revert
-The editor crash bug still happens if you're holding down a letter and double click
-Structure complete doesn't completing functions marked as pervasive or body
-Lack of documentation of new features, etc etc.
-New features don't have syntax highlighting
-The drawpic function doesn't actually work
-etc

Not that these are going to be solved immediately, but there's more than 1 bug.

Anyways. I think 1.0 should have been just the exact original 4.1.12 with only a splash and name change, with hashmaps and whatever in 1.1, but seeing as 1.0 has already been done, there's not much we can do about that.

Quote:

what kind of a website are you thinking of

Like this maybe? Will need additional planning.

Quote:

research your options and find a decent unit testing framework that will be compatible with this project.

Doesn't really help but ok. VS has built-in unit testing features that may work.


Github bug tracker!! Put them up!
trishume




PostPosted: Sun Dec 04, 2011 4:31 pm   Post subject: Re: RE:DWITE io allotted time

Tony @ Sun Dec 04, 2011 2:40 pm wrote:
bugtracker -- github's or otherwise. It's unreasonable to keep track of bugs in forum posts.

versioning -- could very well start at v0.1.x. If, for whatever reason, it must be 1.x, then maybe 1.0.0_RC1 ?

Website -- Project Pages at github http://pages.github.com/ is likely your best bet. That could even be hooked up with a custom domain.

I'm not going to tell you what specific testing framework to use, just nudge you in the right direction. Open this up as an issue, propose choices, invite discussion. This might seem mundane at the surface, but it will (well, should) become an integral part of the project.

This is absolutely amazing -- http://www.sqlite.org/testing.html
Quote:

By comparison, the project has 1177 times as much test code and test scripts

Quote:

extensive testing also plays a vital role in maintaining and improving the quality of SQLite. This document has summarized the testing procedures that every release of SQLite undergoes with the hopes of inspiring the reader to understand that SQLite is suitable for use in mission-critical applications.


Sure, OpenTuring might not have a goal of "production use". Fine. But you'd have a much easier time convincing people (teachers, school boards?) to switch from Turing, if you can show a reasonable level of stability. (A solid test suite also makes it incredibly easier to develop new features in the long run. This is from years of industry experience.)


I know of the benefits of unit testing and am a firm believer in them. I am writing unit tests for the new editor and my compiler.
From now on any new features I write I will write tests for.


Unfortunately, unit tests are only effective if they have reasonable code coverage. It would be damn near impossible for the meagre amount of unit tests we could write even if we had time to properly check all of the Turing interpreter. Also, it isn't easy to test code you didn't write. You end up looking at the code and thinking, "This is what it's meant to do" and coding buggy behaviour into the tests. Yes, you can figure out proper behaviour but this is hard in large confusing code bases.

Even an efficient 11:1 code-test ratio would take 2+ million lines of code.
Tony




PostPosted: Sun Dec 04, 2011 4:42 pm   Post subject: Re: RE:DWITE io allotted time

trishume @ Sun Dec 04, 2011 4:31 pm wrote:
Unfortunately, unit tests are only effective if they have reasonable code coverage.

You would be right, if we were talking about regression testing only.

Edit: you are right that unit testing the existing code base comes with too high of a benefit per effort ratio. It could be covered with functional tests though. I think you've mentioned feeding a complicated source file to see if it compiles, which is basically the idea. Perhaps a more fine grained suite of functional tests, with validated outputs, could be put together with reasonable amount of effort.
Latest from compsci.ca/blog: Tony's programming blog. DWITE - a programming contest.
Dan




PostPosted: Sun Dec 04, 2011 5:09 pm   Post subject: Re: DWITE io allotted time

trishume @ 4th December 2011, 4:19 pm wrote:

Github bug tracker!! Put them up!


Better then nothing, but personaly i think you should try to keep the barrier to users reporting bugs as small as possible. Requireing them to sing up for a GitHub account may deter people from reporting bugs.

I think the best method might be setting up public mailing lists for devloper discussion and one for user support/bug reporting (which devlopers could then create issues for).


Another current issue is your licensing. Right now you have GPL, confidential and copyrighted code in the repo with the OpenTuring code. As it stands you could proably be sued or get a DMCA take down from sun microsystems, microsoft, and others. You also have a copy of the SciFi novel writer, Michelle Sagara's home page in there which is really crazy.
Computer Science Canada Help with programming in C, C++, Java, PHP, Ruby, Turing, VB and more!
Tony




PostPosted: Sun Dec 04, 2011 5:32 pm   Post subject: Re: DWITE io allotted time

sun microsystems Oracle.
Latest from compsci.ca/blog: Tony's programming blog. DWITE - a programming contest.
Display posts from previous:   
   Index -> CompSci.ca, Contests -> DWITE
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 2 of 3  [ 36 Posts ]
Goto page Previous  1, 2, 3  Next
Jump to:   


Style:  
Search: