Skip to content

Latest commit

 

History

History
executable file
·
232 lines (215 loc) · 9.27 KB

todo.org

File metadata and controls

executable file
·
232 lines (215 loc) · 9.27 KB

Org Merge Driver To-do List

Webpage

Add the original posting to the proposal page

  • State “DONE” from “NEXT” [2012-05-09 Wed 01:36]

Fix all references to the project to be the same name on the webpage

Fix the reference to the git repository after it has been created

Update the usage instructions

Add implementation notes

  • even though nothing is decided, there must be something I can add

Prototype

fix up documentation

  • State “DONE” from “TODO” [2012-05-09 Wed 01:34]

Write real manual

  • State “DONE” from “NEXT” [2012-05-09 Wed 01:34]
  • manual, how to use it
  • now in the root README

Finish the parser

  • State “DONE” from “NEXT” [2012-05-10 Thu 19:03]
  • make sure the new headings are being put in the right spot
    • means: compare level of new heading with old heading to add it in the right spot
    • possibly add the new heading to the propper spot right as the next one is started

Implement a heading tree printer

  • State “DONE” from “NEXT” [2012-05-09 Wed 23:24]
  • really a org_document_to_file function

Add a TAP for the program which demonstrates its use

  • test anything protocol

Write an introductory warning

  • State “DONE” from “NEXT” [2012-05-10 Thu 19:03]
  • this program assumes things about the structure and use of org-mode and org files. If the way you use org files does not match this, then it may corrupt your data! Please be very aware of what assumptions this program makes before using. I (nor anyone other than yourself) can be held accountable for the results of using this program.

Use Gnulib diffseq to merge

  • State “DONE” from “NEXT” [2012-05-16 Wed 22:26]

Fix memory usage

  • nothing is being unmalloced
  • write destroy functions
    • one for document, heading, look at ?gl_list_free? for list notes

Start working on the change detection

  • State “DONE” from “NEXT” [2012-05-16 Wed 22:25]

Create a heading mapping

Begin work on the change merging

Create text mapping

Allow headings to be ‘moved’ locally

Allow headings to be ‘moved’ globally

Print propper merges

Finish the prototype

Org Merge Driver

[#B] Argp on main

[#A] Create doc_stream sdio wrapper

  • write a stdio wrapper
  • make sure that we can encode

[#B] Make the parser construct the doc trees

[#B] Merge tree

  • implement the prototypes
  • ??

[#C] Memory allocator for document

[#A] Support global elt matching

Allow elements to deal with global matching

  • Add callbacks so elements can choose if and how they match.

[#A] Update autotool files

[#C] Add support for multiple encodings

  • [ ]
  • [ ]

Devise a doc_elt data allocation scheme

  • Currently:
    • There is no standard scheme for setting up data in an element
    • org_heading accepts a pointer to an outside allocated buffer, while org_text actually copies and appends strings passed to it.
  • Ideas:
    • Outside allocation, pass buffer to const data.
      • who deallocates?

Fix printmerge context

Fix org_lexer context

  • Currently using a mishmash of global vars in a reentrant parser.
  • Make a lexer userdata struct to use

[#B] Make doc_stream macros safe

[#B] Check and handle memory allocation errors

  • Currently, datastructures malloc without returning error.
  • not detected, checked, etc.
  • See how gl_list does it
    • Most of our interfaces are modelled slightly afer gl_list

[#B] Make doc_merge work with null ltree_lists

  • merge_node and doc_nodes currently always have allocated child lists.
  • They should only have one if they have children

[#A] Implement org_heading

[#A] Fix the merge_delta/doc_merge interface

  • Currently uses status??
  • Make a real enum & field, don’t overload something else.

[#B] Fix Parser / Lexer

  • currently:
    • parser is implemented inside the lexer
    • lexer logic is more complicated than it should be
    • parser is almost empty
  • To fix:
    • Make lexer return smaller symbols
    • Build doc_elt’s inside the parser
  • Why bother:
    • Adding rules to the lexer is error prone & hard.
    • May make the parser more flexible.

[#B] Move phony_elt to it’s own header

  • phony_elt is a dummy elt used for testing.
  • moving it to it’s own header file will let us use it in multiple tests.

[#A] Create a debug print macro

  • support different modules enable/disable
    • eg disable printing in document elements, enable in test functions.
  • fail message macro?
    • disapears like assert?

[#C] Create a verbosity-controlled print function

[#A] Make doc_elt_compare find updates

  • doc_elt_compare returns a simple boolean
  • make doc_elt_compare decide if something matches
    • if they do, let it decide whats newest / if something has been updated
  • If compare has to compare every field of a doc_elt, it only makes sense to cache that data for printing.

Code cleanup

Ideas

(andrew) add and implement functions to create the mapping and dnode tree

implement org_text.h,r org_document.h, org_phony.h

make the parser work for those elements

Long Run

Log

[2012-05-07 Mon]

  • modify gl_list.h to not inline functions
  • write parser, reads the files but does not create a proper list

[2012-05-08 Tues]

split source files

  • the files should really be split up by their use

split commits

  • branch for the prototype
  • add documentation
  • add gnu_lib list
  • add read file
  • add main program
    • with only org_ structs
  • add parser

finally started uploading code

[2012-05-09 Wed]

  • tried to add some testing code
    • went with TAP at first, but decided it wasn’t what I wanted
    • went with heavier duty unit testing (called ‘check’), but it was too heavy duty
    • trying to go back to TAP
  • tried to compile the parser into a library instead of statically linking into the program
    • got it working but reverted; this is more useful for the final project (and with the unit testing removed there was no point)
  • wrote a manual for using the program (for when it is eventually done)
  • tried to make all the random bits of (evidently pointless) work presentable

[2012-05-10 Thu]

  • looked into anonymous functions in C, definitely not portable
  • wrote a function to recursively call other functions on a tree
  • wrote a function to print a org_doc back into a file
  • finally finished the parser, i probably made it more correct than necessary to show how it would work
  • fixed a lot of the documentation in the code I have written, adding GPL warnings at the top of all my source files
  • finally fixed the problem with gl_list not compiling inline functions. I needed to include autoconf’s config.h before it to define the HAVE_INLINE macro.
  • starting to think about the best way to finish off the prototype
    • this involves the ‘tricky’ part of the program: finding changes and merging them.
  • looking into different parser generators for the final program. I am worried about both speed and robustness when it comes to creating a parser

[2012-05-11]

  • looking into more robust parser generators, specifically ones that will be extensible, easy to use, and most importantly fast
  • typically Bison and yacc look very good

[2012-05-12]

  • reading about compilers, trying to see if the traditional structure will lead to hints as to how to set up my code
  • reading a book known as ‘the dragon book’
  • found out that you can collapse a heading which is inside a #+begin_src: block
    • is this a bug?

[2012-05-13]

  • spending some time going through the manual again to figure out what

[2012-05-14]

  • thinking about the best way to set up a difference detector.
  • I am finding that a lot of ideas I have about what rules to use to merge might not be desirable for people
  • how can I set it up, so that the rules can be customized?

[2012-05-15]

  • After reading papers about ‘sequence difference seeking algorithms’, I decided that it would be too much work to implement on from scratch for the prototype
  • Found an implementation in Gnulib (should have checked there sooner!)
  • spending my day attempting to include it into the project

[2012-05-16 Wed]

  • deciding that for the prototype, I will only do change detection on a heading level
    • this makes for kind of a bad prototype
    • I will have to really make sure I consider how having a larger amount of elements will affect the project
  • it is really confusing trying to match headings when one is not unique
  • it will be necessary to create a mapping of headings in from one file to another, where the mapping says which headings are the same, which are non-unique non-distinguishable, and which have no matches

[2012-05-19 Sat]

  • starting the change detection
  • must finish the fucntion to create an empty tree of mappings from the origin file
    • this will involve copying the code from thre recursive function and manipulating it to create the treec