Difference between revisions of "User:Kanmuri/Notes/Java Runtime Port/Interchunk vs Transfer"
(added transfer vs interchunk and read() sections) |
(added transfer() vs interchunk()) |
||
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. |
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>. |
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. |
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. |
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>read()</code>=== |
||
<code>void Transfer::read(string const &transferfile, string const &datafile, string const &fstfile)</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. |
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>. |
Revision as of 22:14, 24 July 2010
I created this page to hold my notes as I go along trying to figure this out.
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.
Contents
apertium_transfer.cc vs apertium_interchunk.cc
We are only really concerned with one function in these two files at the moment, main()
.
There's the obvious differences in the option parsing code, as interchunk doesn't have as many options as transfer does.
Transfer calls its read()
function differently depending on the command-line options and parameters.
Interchunk instead just assigns values to variables differently depending on the options and parameters, and then uses those to call its read()
function.
Transfer and interchunk take different parameters for their read functions. Transfer takes a transfer file, a data file, and an fst file. Interchunk takes just a transfer file and a data file.
Transfer and interchunk then call their transfer()
and interchunk()
functions respectively.
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 read()
and transfer()
functions.
transfer.cc vs interchunk.cc
read()
void Transfer::read(string const &transferfile, string const &datafile, string const &fstfile)
void Interchunk::read(string const &transferfile, string const &datafile)
The read()
functions first call readTransfer()
and readInterchunk()
respectively. They then both try and open the specified data file. After that, Transfer::read()
also calls a function to read the fst file, called readBil()
. Interchunk::read()
does not have that call, and that function (readBil()
) does not exist in interchunk.
transfer()
vs interchunk()
Checks if null flush is set, then calls a null flush "wrapper" function (*_wrapper_null_flush()
).
Initializes the MorphoStream. Then enters an infinite (while(true)
) loop.
The code is the same up to the if(tmpword.size() != 0)
line.
After that, the interchunk code diverges. It just outputs a '^', the contents of tmpword
, and a '$', whereas the transfer code has a whole bunch of stuff it does.
They meet back up at tmpword.clear()
, and continue the same up 'till the tt_eof
case in a switch(current.getType())
statement. In the else clause of an if-else statement there, interchunk adds a line tmpblank.clear()
.