[Grace-core] Frustrations working on Minigrace

[Andrew P Black]

I've just wasted another evening trying to do some programming on the grace collections library.  For the tenth time, I've spent a couple of hours trying to get my environment into a state where I can START to look at the bug that I'm working on.  So far, I've still got nowhere.

I'm going to try to chronicle the whole fiasco, because it is getting to be really important that we fix the grace programming environment so that ordinary humans can contribute to the project.  I was at  Oswego last week, and some of Doug Lea's students were asking if this project was open source, and if they could contribute.  I said something along the lines of ... it's split over multiple source code repositories in multiple source code control systems, to which you get access in different ways.  I didn't say that there are no unit tests, that the acceptance tests are inadequate, and the make files are broken, but if I had, that would have been true.

One thing that I was able to do at Oswego was commit the merge that I had done a couple of weeks previously of my repo (mergeNZ branch).  I hadn't been able to commit this because of a bug in git commit that puts the command into an endless loop trying to open emacs.  My normal workaround for this bug is to use gitless, but gitless has a bug in it too (it says so).  

Suggested fix: get off of git as the UI for source control; switch to svn (which can also work with github, I believe).

The first thing that I did was to make minigrace, and then try running my failing test again, with some debugging prints added.  It wouldn't compile, because the ClassMethods pragma wasn't recognized:

collectionTests.grace[12:(19)]: Syntax error: A class must have a dot after the object name.
  11: def aRangeTest = object {
  12:   class forMethod( m) {

Apparently, the merge with NZ had deleted the test the ClassMethods extension.   I tried to find which commit had deleted the reference to this extension, but Xcode now refuses to let me compare versions of a file stored in git, and I have no idea how to answer the question "when did this chunk of code disappear" using the command-line git interface.

I don't know why this code was deleted, or why it's absence was not caught by tests.

Suggested fixes:  
	(1) A crib sheet on how to configure Xcode to show source code history.  In the past this "just worked".
	(2) Write unit tests so that if currently-used functionality is accidentally deleted (the ClassMethods pragma was disabled between 355c179 and f68491e),  we notice before the change is committed to master.

How did I find this out?  git log -S "ClassMethods" parser.grace will tell you the commits that add or remove lines containing "ClassMethods"; git log --abbrev-commit --pretty=oneline will give you a list of all of the commits, and then you can diff the most recent one that changed a line with ClassMethods with the one before.  There are probably better ways of doing this, but remember, I don't want to be doing this ... I want to be coding Grace. 

So I switched my minigrace back to the master branch, which restored the ClassMethods functionality, and did a make clean; make js.

I get:

cc   -lm  StandardPrelude.grace.c   -o StandardPrelude.grace
StandardPrelude.grace.c:1:10: error: 'gracelib.h' file not found with <angled> include;
      use "quotes" instead
#include <gracelib.h>
         ^~~~~~~~~~~~
         "gracelib.h"
StandardPrelude.grace.c:4:14: warning: weak identifier 'main' never declared
#pragma weak main
             ^
1 warning and 1 error generated.
make: *** [StandardPrelude.grace] Error 1
Pahoehoe: ~/Development/mg/apb/minigrace$ 

I spend about an hour tracking down why . is not on the c include path, put it there, get a bunch of other compilation errors, futz some more, puzzle over what the hell StandardPrelude.grace.c is anyway, and eventually conclude that the makefile is broken.
make clean doesn't.  I delete a bunch of generated files by hand, checkout a few source files again from git, and finally get a make to complete.

  522  ls StandardPrelude.*
  523  gl checkout StandardPrelude.grace
  524  rm StandardPrelude.{c,gcn,gct,grace.c}
  525  make StandardPrelude.o
  527  ls *.gcn *.c *.gct *.grace.c
  528  rm mirrors.c*
  529  gl checkout mirrors.c
  530  more stdin_minigrace*
  531  gl log stdin_minigrace.c
  532  gl history stdin_minigrace.c
  533  rm stdin_minigrace
  534  rm stdin_minigrace* 

After this, I was able to make minigrace,  run my tests, and get my debugging printout.  Unfortunately, its now 0:58, and I'm in no position to actually fix my bug.

I know that minigrace is research-quality software.  I don't expect everything to be perfect.  I expect there to be some bugs — but I also expect that it should be possible to contribute fixes to make it better, and that the majority of my time (not all, but the large majority) should be spent working on code, not working around the infrastructure.

I think that we need to seriously look at our processes.

	Andrew

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140521/0c964ec1/attachment.html>