User:Kanmuri/Notes/Java Runtime Port/Interchunk vs Transfer - Revision history

Kanmuri at 03:39, 27 July 2010

2010-07-27T03:39:22Z

Kanmuri: added applyRule() comparison

2010-07-27T00:57:20Z

added applyRule() comparison

Kanmuri: added applyWord() comparison

2010-07-27T00:18:07Z

added applyWord() comparison

Kanmuri: fixed formatting, added more to *_wrapper_null_flush

2010-07-26T18:54:00Z

fixed formatting, added more to *_wrapper_null_flush

Kanmuri: *_wrapper_null_flush notes

2010-07-26T18:40:18Z

*_wrapper_null_flush notes

Kanmuri: working on *_wrapper_null_flush comparison

2010-07-25T09:23:02Z

working on *_wrapper_null_flush comparison

Kanmuri: added transfer() vs interchunk()

2010-07-24T22:14:20Z

added transfer() vs interchunk()

Kanmuri: added transfer vs interchunk and read() sections

2010-07-24T10:08:37Z

added transfer vs interchunk and read() sections

Kanmuri: added apertium_transfer vs ApertiumTransfer

2010-07-24T09:51:07Z

added apertium_transfer vs ApertiumTransfer

Kanmuri: moved User:Kanmuri/Notes/Java Runtime Port/Interchunk vs Transfer/ to User:Kanmuri/Notes/Java Runtime Port/Interchunk vs Transfer: shouldn't have a slash at the end

2010-07-24T08:47:19Z

moved User:Kanmuri/Notes/Java Runtime Port/Interchunk vs Transfer/ to User:Kanmuri/Notes/Java Runtime Port/Interchunk vs Transfer: shouldn't have a slash at the end

@@ Line 49: / Line 49: @@
 ===<code>applyRule()</code>===
 Looks like Transfer has extra code for the bilingual dictionary. Also, Interchunk uses InterchunkWord and Transfer uses TransferWord.
+===<code>readToken()</code>===
+Interchunk has a bunch of extra if statements that look to be for jumping over chunks, and an "inword" flag.

@@ Line 46: / Line 46: @@
 ===<code>applyWord()</code>===
 An extra case in interchunk for skipping over "the unmodifiable part of the chunk" according to the comments.
+===<code>applyRule()</code>===
+Looks like Transfer has extra code for the bilingual dictionary. Also, Interchunk uses InterchunkWord and Transfer uses TransferWord.

@@ Line 43: / Line 43: @@
 One other significant thing is that it unsets the null_flush flag, so that we don't get the transfer/interchunk and the null flush functions infinitely calling each other. Instead it sets the <code>internal_null_flush</code> flag to indicate that null flush is actually enabled, but that we're already inside the wrapper.
+===<code>applyWord()</code>===
+An extra case in interchunk for skipping over "the unmodifiable part of the chunk" according to the comments.

@@ Line 21: / Line 21: @@
 ===<code>read()</code>===
 <code>void Transfer::read(string const &transferfile, string const &datafile, string const &fstfile)</code>
 <code>void Interchunk::read(string const &transferfile, string const &datafile)</code>
@@ Line 40: / Line 41: @@
 If flushing on nulls, then what the wrapper does is call the respective function, which returns on a null, re-output the null, flush the output, then call the function again, until end of file.
+One other significant thing is that it unsets the null_flush flag, so that we don't get the transfer/interchunk and the null flush functions infinitely calling each other. Instead it sets the <code>internal_null_flush</code> flag to indicate that null flush is actually enabled, but that we're already inside the wrapper.

@@ Line 37: / Line 37: @@
 ===<code>transfer_wrapper_null_flush()</code> vs <code>interchunk_wrapper_null_flush()</code>===
+The only difference between the two of these is that one calls <code>transfer()</code>, and the other one calls <code>interchunk()</code>.
+If flushing on nulls, then what the wrapper does is call the respective function, which returns on a null, re-output the null, flush the output, then call the function again, until end of file.

← Older revision		Revision as of 09:23, 25 July 2010
Line 35:		Line 35:

	They meet back up at <code>tmpword.clear()</code>, and continue the same up 'till the <code>tt_eof</code> case in a <code>switch(current.getType())</code> statement. In the else clause of an if-else statement there, interchunk adds a line <code>tmpblank.clear()</code>.		They meet back up at <code>tmpword.clear()</code>, and continue the same up 'till the <code>tt_eof</code> case in a <code>switch(current.getType())</code> statement. In the else clause of an if-else statement there, interchunk adds a line <code>tmpblank.clear()</code>.

			===<code>transfer_wrapper_null_flush()</code> vs <code>interchunk_wrapper_null_flush()</code>===

@@ Line 3: / Line 3: @@
 I wouldn't count on them being entirely correct, in fact they may be downright completely wrong in places, but hopefully not. ;) This is mainly just to have a place to organize my thoughts.
-==apertium_transfer vs apertium_interchunk==
+==apertium_transfer.cc vs apertium_interchunk.cc==
 We are only really concerned with one function in these two files at the moment, <code>main()</code>.
@@ Line 15: / Line 15: @@
 Transfer and interchunk then call their <code>transfer()</code> and <code>interchunk()</code> functions respectively.
-==apertium_transfer vs ApertiumTransfer==
+==apertium_transfer.cc vs ApertiumTransfer.java==
 Not a significant difference between these two. The basic premise is the same, parse command-line options and parameters, then call the <code>read()</code> and <code>transfer()</code> functions.
-==transfer vs interchunk==
+==transfer.cc vs interchunk.cc==
 ===<code>read()</code>===
 <code>void Transfer::read(string const &transferfile, string const &datafile, string const &fstfile)</code>
@@ Line 24: / Line 24: @@
 The <code>read()</code> functions first call <code>readTransfer()</code> and <code>readInterchunk()</code> respectively. They then both try and open the specified data file. After that, <code>Transfer::read()</code> also calls a function to read the fst file, called <code>readBil()</code>. <code>Interchunk::read()</code> does not have that call, and that function (<code>readBil()</code>) does not exist in interchunk.
+===<code>transfer()</code> vs <code>interchunk()</code>===
+Checks if null flush is set, then calls a null flush "wrapper" function (<code>*_wrapper_null_flush()</code>).
+Initializes the MorphoStream. Then enters an infinite (<code>while(true)</code>) loop.
+The code is the same up to the <code>if(tmpword.size() != 0)</code> line.
+After that, the interchunk code diverges. It just outputs a '^', the contents of <code>tmpword</code>, and a '$', whereas the transfer code has a whole bunch of stuff it does.
+They meet back up at <code>tmpword.clear()</code>, and continue the same up 'till the <code>tt_eof</code> case in a <code>switch(current.getType())</code> statement. In the else clause of an if-else statement there, interchunk adds a line <code>tmpblank.clear()</code>.

← Older revision	Revision as of 08:47, 24 July 2010
(No difference)