- 1 28-29 July 2012
- 2 21 July 2012
- 3 20 July 2012
- 4 17-18 July 2012
- 5 11-12 July 2012
- 6 9-10 July 2012
- 7 5 July 2012
- 8 3 July 2012
- 9 1 July 2012
- 10 30 Jun 2012
- 11 29 Jun 2012
- 12 28 Jun 2012
- 13 24 Jun 2012
- 14 22 Jun 2012
- 15 20 Jun 2012
- 16 17 Jun 2012
- 17 15 Jun 2012
- 18 14 Jun 2012
- 19 12 Jun 2012
- 20 11 Jun 2012
- 21 10 Jun 2012
- 22 8 Jun 2012
- 23 5 Jun 2012
- 24 4 Jun 2012
- 25 1 Jun 2012
- 26 30 May 2012
- 27 28 May 2012
- 28 27 May 2012
- 29 24 May 2012
- 30 22 May 2012
- 31 21 May 2012
- 32 18 May 2012
- 33 17 May 2012
- 34 15 May 2012
- 35 14 May 2012
- 36 13 May 2012
- 37 12 May 2012
- 38 9 May 2012
- 39 8 May 2012
- 40 7 May 2012
- 41 4 May 2012
28-29 July 2012
- Implemented a custom form renderer.
- Results to be integrated.
21 July 2012
- Realized that simpleforms do not help much and have begun writing the forms natively in PHP.
20 July 2012
- Still figuring out the forms and the implementation of the actions
17-18 July 2012
- Playing around with the Simple forms extension. Naive html forms wouldn't help as the action can't be hard coded.
- It has some issues with mediawiki 1.20(alpha) due to some deprecations in the mediawiki codebase but figured out a few of them.
11-12 July 2012
- Upload form on the special page.
- Read up on Google charts embedding. Thoughts on the features required for the frontend.
9-10 July 2012
- Documentation and fixing the flow. logging cleanup.
5 July 2012
- Read up the forms implementation for the frontend of mediawiki extension
3 July 2012
- Web API set up. Mail has been sent to the mailing list asking folks to submit the logs through the API and mail.
- Documentation, implement logging through out.
- Read up about frontend forms for upload and data request.
- The frontend is being setup through a special page which is the view part of the mediawiki extension.
1 July 2012
- Setting the demo server up. It is hosted at http://18.104.22.168 and that is being configured now for the demo purposes.
- Documentation of the work
30 Jun 2012
- Integrating all the things worked on. Testing the process.
29 Jun 2012
- The API request takes the following POST parameters.
'filename' => 'the name of the file', 'content' => 'File contents'
- Uses the config.ini file to read the queue folder's position.
- Returns the xml as
- ERROR_DESC : ERROR_FILE_ALREADY_EXISTS, FILE_HAS_BEEN_SUBMITTED, ERROR_OTHER
28 Jun 2012
- Worked on the API, shall put up a server and send in the script to use the API tomorrow so that people can submit their benchmark logs.
24 Jun 2012
- Added the patch which includes all the IMAP related files.
- API: Can post the entire benchmark data at once. (Chunk upload : ? )
22 Jun 2012
- Completed the mentioned scripts(1. IMAP retriever 2. IMAP Verifier 3. Move to db and archive), posting them as a patch shortly. Cleaning them up
- Started work on API again.
20 Jun 2012
- Cleaned up the IMAP script.
- Started working on the IMAP verifier script, a script to move the data from the queue folder to the db and the archive.
- Files in the archive are stored as run-[0-9]+-benchmark.log.<md5_digest> just to avoid filename clashes due to the numeric part of the filename which is the process id.
17 Jun 2012
- Worked on the IMAP script. Posted the WIP patch
15 Jun 2012
- Still stuck, taking help from mediawiki team but that is not solving the issue.
- Started working on the IMAP sync script.
- Realized, there should be a log of the emails that have been synced. Read or unread is too naive to handle such a thing. Thus adding a column in the db for the emailid obtained from the IMAP listing so as to check if the file has been archived or entered into the database or not.
14 Jun 2012
- It still could not be done. Still stuck with the API.
12 Jun 2012
- Finally have the base code for upload ready. Using the ApiUpload as a base, implementing the feature. Should have it ready by tomorrow.
- Silly feature but it has taken a lot of time. But I've learnt enough to work on the frontend right away.
- The loading of the Api is hardcoded for now(the paths and the indexes for the API modules is hardcoded into the mediawiki/includes/api/ApiMain.php and mediawiki/includes/Autoloader.php), still it is not fixed.
11 Jun 2012
- Initially figured out that Localsettings.php was not being loaded by the api.php. Using reflectionclasses found out why class instantiation was failing. 1. The file was not loadable and 2. methods were not properly defined.
10 Jun 2012
- Spent some time checking the pipeline of the calls of the api. Figured out what was going wrong. Class instantiation of the API was failing. Now fixing it.
8 Jun 2012
- Failed attempts with respect to getting the API working.
5 Jun 2012
- Understood the extensions framework of mediawiki and API framework and interfaces via the special pages.
- API file upload still did not work locally. Still figuring it out because of some authentication token related issues
- Laid out the skeletal structure for the extension
4 Jun 2012
- Started writing the mediawiki extension. Mediawiki extension tutorials are extremely vague and it is taking me some time to sink in the necessary details.
1 Jun 2012
- Wrote a logger for the existing code plus a bit of sanity check and cleanup for the already existing code.
- Was reading up the API documentation of mediawiki, its file upload via API and calling API from an extension
30 May 2012
- Rewrote the parser as the old was monolithic scraper. Implemented the Parser class and some sub routines. Submitted two patches. Patch1 Patch2
- Results of the scraping are as follows.
- Code layout has been changed:
svnroot/brlcad/web/trunk/benchmark |- config |_ libs |_ parser.py |_ util.py |_ scripts |_ parse.py |_ sql |_ benchmark_db.sql
- config file layout is as follows :
[database] host = localhost username = <user> password = <pass> database = benchmark_db
[locations] archive = ./archive benchmark_root = path/to/trunk/htdocs/benchmark/
28 May 2012
- The data is now pushed into the db. Takes the settings from a config file situated in the root of the benchmark source.
- Cleaning the script and testing with the data. I shall send in a formal mail discussing the script execution and usage which presents the work I've done.
27 May 2012
- Made the code completely based on the regexes as per the syntax in the bench/run.sh file.
24 May 2012
- Crude script for the parser and to transfer the data to the db.
22 May 2012
- Made progress with the parser.
- Code layout in terms of the folders was decided upon and is as follows:
svnroot/brlcad/web/trunk/benchmark |_ scripts |_ parser.py |_ sql |_ benchmark_db.sql
21 May 2012
- Completed the patch for the bench/pixcmp.c. Preliminary testing done. Benchmark script executes without fail. Waiting for Sean to approve and say if that is what is really wanted.
brlcad-build → bin/pixcmp -d4 ../brlcad/pix/moss.pix ../brlcad/pix/moss_new.pix pixcmp pixels: 262140 matching, 4 off by 4, 0 off by many
brlcad-build → bin/pixcmp -d2 ../brlcad/pix/moss.pix ../brlcad/pix/moss.pix pixcmp pixels: 262144 matching, 0 off by 2, 0 off by many
brlcad-build → bin/pixcmp -d2 ../brlcad/pix/moss.pix ../brlcad/pix/moss_new.pix pixcmp pixels: 262140 matching, 4 off by 2, 0 off by many
brlcad-build → bin/pixcmp -d1 ../brlcad/pix/moss.pix ../brlcad/pix/moss_new.pix pixcmp pixels: 262140 matching, 2 off by 1, 2 off by many
brlcad-build → bin/pixcmp ../brlcad/pix/moss.pix ../brlcad/pix/moss_new.pix pixcmp pixels: 262140 matching, 2 off by 1, 2 off by many
- Started writing the log parser.
18 May 2012
- Started looking into the issue which Sean mentioned which is related to pixcmp and found nothing there. Sean later found out that the bug was in the pixdiff utilty.
- Amidst this, I found that after the recent (svn) update of the code the benchmark test for sphflake was failing. I then spent time on figuring out(using binary search) the bug and found that r50582 was responsible for the same.
17 May 2012
- Working on a patch for the bench/pixcmp.c functionality.
15 May 2012
- Set up a dummy database without much changes to the schema mentioned as a part of the proposal and then started writing crude parser scripts in python.
- Setup thrift on my machine. Had faced few difficulties setting it up with php 5.4.3 and Python 3.2 The issues with php 5.4.3 were resolved but the ones with Python 3.2 were quite a few specially related to the syntactic changes during the transition from 2.x to 3.x. Downgraded python to 2.7.3 and completed the setup. Yet to test the interlanguage communication. Shall do it tomorrow.
14 May 2012
- Experimenting with regexes for the benchmark log parsing.
13 May 2012
- Moved from ubuntu 12.04 which I did not really like to Archlinux and setup the work environment.
12 May 2012
- Set up mediawiki on the local machine and then was experimenting with the api.php of mediawiki.
9 May 2012
- Continued experimentation with the benchmark script and finally understood what each part of the code does.
- Working on a back-end design (Sent in a mail to the developer mailing list). Shall start working on the db design.
8 May 2012
- Continued experimentation with benchmark script and attempting to create the first patch by fixing the following block in the run.sh script.
# FIXME: should really iterate one file at a time so we don't # just zero-pad at the end perf_VGRREF=`grep RTFM $perf_ref_files | sed -n -e 's/^.*= *//' -e 's/ rays.*//p' | tr '\012' '\011' ` perf_CURVALS=`grep RTFM $perf_cur_files | sed -n -e 's/^.*= *//' -e 's/ rays.*//p' | tr '\012' '\011' `
- Working on a set of questions for design discussions.
7 May 2012
- Still looking into benchmark script and experimenting with that.
4 May 2012
- Compiled the brlcad(r50443) on my new setup of Ubuntu 12.04. Installation went on smoothly when librtserver JDK support was disabled.(I was trying various options during compilation.) When turned on, there were the error of it not being able to find jni.h even though the paths were fine. Looking into it at the moment.
- Could not understand why cmake was looking for STDCXX libs.
- Ran the benchmark on the machine and sent the report to firstname.lastname@example.org
- Started looking into the run.sh script to figure out how it really works.