Thu Jul 21 08:41:19 2005: New ticket: 467.
Transaction: Ticket created by [EMAIL PROTECTED]
Queue: Darcs
Subject: pull/push problem
Owner: Nobody
Requestors: [EMAIL PROTECTED]
Status: new
Ticket <URL: http://bugs.darcs.net/.//Ticket/Display.html?id=467 >
Hej,
darcs fails to push some patches in my repository. Also pulling from the
other repository does not work.
Here is what darcs-1.0.4pre1 says (but 1.0.2 had the same problem):
[EMAIL PROTECTED]:~/Diplomarbeit/ausarbeitung_conflicts $ darcs pull
../ausarbeitung
Pulling from "../ausarbeitung"...
Wed Jul 20 16:15:20 CEST 2005 [EMAIL PROTECTED]
* weak section on No OO
Shall I pull this patch? (1/2) [ynWvpxqadjk], or ? for help: y
Wed Jul 20 16:54:53 CEST 2005 [EMAIL PROTECTED]
* section on character counting in XML
Shall I pull this patch? (2/2) [ynWvpxqadjk], or ? for help: n
Fail: bug in darcs!
in function reconcile_unwindings
Original patch:
merger 0.0 (
merger 0.0 (
merger 0.0 (
hunk ./ausarbeitung_da.tex 501
-\item non-helping names
-\item global variables
-\item implicit multi-threading
-\item everything static
hunk ./ausarbeitung_da.tex 501
-\item non-helping names
)
hunk ./ausarbeitung_da.tex 501
-\item no OO
)
merger 0.0 (
merger 0.0 (
merger 0.0 (
hunk ./ausarbeitung_da.tex 500
+\subsubsection{Names that were not very helpful}
+Local variables could have names like \JAVAc{j}, \JAVAc{j2}, \JAVAc{k},
\JAVAc{k}, \JAVAc{s} and so on and were defined at the beginning of the
respective method without any hint, which purpose these variables serve.
+The use of these variables depended very much on the input data from
GF, so just by looking at the code, it was not possible, to find their
use or what values were stored there.
+Only debugging the programs did help here.
+
+Also method names were sometimes misleading.
+That, for example, \JAVAc{outputAppend} does not append anything to the
output, but looks for a focus tag, stores an attribute of it, strips the
tag and then calls a method called \JAVAc{appendMarked} or itself
recursivly, is not derivable from the name of the method.
+A method named \JAVAc{recursion} also appeared in the code.
+This one takes a menu entry and sets the font of all its children.
+And is \emph{not} recursive.
+
+There were attributes of the main class \JAVAc{GFEditor2} with like
names \JAVAc{selStart}, \JAVAc{oldLength} or \JAVAc{stringToAppend},
that gave no clue about there purpose, since these names are quite general.
+Which leads to the next point:
+
+
+\subsubsection{Global variables}
+The old version of the editor uses 23 attributes as global variables,
of which the value does not need to be saved.
+They are used instead of return values and parameters for the purpose
of parsing the XML from GF and displaying tree and linearization.
+Mostly they have been used in several methods which interacted on them.
+The main methods for parsing and displaying, \JAVAc{readLin},
\JAVAc{readMessage}, \JAVAc{readTree}, \JAVAc{formNewMenu},
\JAVAc{formLin} and \JAVAc{formTree} (this one takes the tree panel as
its argument, but that one never changes) all interact purely with
side-effects, they take no parameters, return void, and several of them
also affect the GUI.
+Together with the lack of comments, this made it very hard to figure
out, which purpose those variables serve.
+Again, only debugging with real input from GF did help here.
+
+Changing the order of the method calls would also give unexpected
results, but would be needed when, for example, calling GF in the
background to check something.
+
+
+\subsubsection{Mostly static attributes}
+The editor was meant as a stand-alone application, and there it didn't
matter, if an attribute was static or not, since only one instance of
the main class was running at a time.
+So most of the attributes, that kept the state of the editor, or were
just global, although they could have been made local, were static
attributes.
+But in the context of TogetherCC where one might want to start the
editor more than once for several classes/methods at the same time, it
does matter.
+
+
+
hunk ./ausarbeitung_da.tex 500
+\subsubsection{Names that were not very helpful}
+Local variables could have names like \JAVAc{j}, \JAVAc{j2}, \JAVAc{k},
\JAVAc{k}, \JAVAc{s} and so on and were defined at the beginning of the
respective method without any hint, which purpose these variables serve.
+The use of these variables depended very much on the input data from
GF, so just by looking at the code, it was not possible, to find their
use or what values were stored there.
+Only debugging the programs did help here.
+
+Also method names were sometimes misleading.
+That, for example, \JAVAc{outputAppend} does not append anything to the
output, but looks for a focus tag, stores an attribute of it, strips the
tag and then calls a method called \JAVAc{appendMarked} or itself
recursivly, is not derivable from the name of the method.
+A method named \JAVAc{recursion} also appeared in the code.
+This one takes a menu entry and sets the font of all its children.
+And is \emph{not} recursive.
+
+There were attributes of the main class \JAVAc{GFEditor2} with like
names \JAVAc{selStart}, \JAVAc{oldLenght} or \JAVAc{stringToAppend},
that gave no clue about there purpose, since these names are quite general.
+Which leads to the next point:
+
)
hunk ./ausarbeitung_da.tex 532
+\subsubsection{Nearly no OO \comment{weak paragraph}}
+The editor consisted of 2 main classes, one for the general GUI
(\JAVAc{GFEditor2}), and one for the graphical representation of the AST
(\JAVAc{DynamicTree2}).
+2 other classes were used as records (\JAVAc{LinPosition} and
\JAVAc{MarkedArea}) to store connected data, but had no methods.
+Additionally 8 more or less anonymous classes were used as callbacks.
+But except for \JAVAc{DynamicTree2}, all functionality was gathered in
just one big class with no further encapsulation.
+
+Also \JAVAc{GFEditor2} implements the listener classes for all GUI
elements except for the AST.
+So the event handler methods consisted of huge case distinctions to
figure out, where the request comes from.
+This isn't necesarilly bad per se, but having 24 cases, from which only
1 is executed at a time, with handling code up till over 50 lines, this
gets hard to read.
)
hunk ./ausarbeitung_da.tex 500
-\begin{itemize}
-\item non-helping names
-\item global variables
-\item implicit multi-threading
-\item everything static
-\item no OO
-\item highlighting bound to character counting in the string from GF
-\item huge Listener methods
-\end{itemize}
+\subsubsection{Names that were not very helpful}
+Local variables could have names like \JAVAc{j}, \JAVAc{j2}, \JAVAc{k},
\JAVAc{k}, \JAVAc{s} and so on and were defined at the beginning of the
respective method without any hint, which purpose these variables serve.
+The use of these variables depended very much on the input data from
GF, so just by looking at the code, it was not possible, to find their
use or what values were stored there.
+Only debugging the programs did help here.
)
)
Please report this to [EMAIL PROTECTED]
If possible include the output of 'darcs --exact-version'.
Thank you and good luck,
Ha-Jo
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
