LyX class assignment
Hi, The discussion on this has been quite useful to us. I have contacted other academics at UNSW CSE and have shown them this thread to see what they think. BTW, there may be university regulations about whether we can require students to submit patches in a public forum. Some students -- particularly weaker ones -- may not want the world to see their code submissions. The separate student list idea is good but it may be better to keep the list archives off the web to encourage students to post questions. I suppose intelligent questions would propagate to the main development list, which is publicly available in any case. The actual class starts March 1, 2004. If we shall attempt this experiment, I will contact you again a bit before then. (How early should I contact you before class start?) Amir
LyX class assignment
Hi, The discussion on this has been quite useful to us. I have contacted other academics at UNSW CSE and have shown them this thread to see what they think. BTW, there may be university regulations about whether we can require students to submit patches in a public forum. Some students -- particularly weaker ones -- may not want the world to see their code submissions. The separate student list idea is good but it may be better to keep the list archives off the web to encourage students to post questions. I suppose intelligent questions would propagate to the main development list, which is publicly available in any case. The actual class starts March 1, 2004. If we shall attempt this experiment, I will contact you again a bit before then. (How early should I contact you before class start?) Amir
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003 12:28 am, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | We are always interested. One thing that I would note is that we're a | small collection of programmers and are very wary of enormous | patches, prefering a 'little and often' approach. Moreover, because | we are trying to clean the code base up (and have been doing so for | several years) we have found it useful to have preliminary and | informal discussions about the best way to implement some suggestion. | Often the design becomes far more generic as a result. Getting your | students to participate in such discussions would be an excellent | thing for them to do anyway. Yes, and this would be required for them to get a patch into Lyx anyway, and should absolutely be part of the assignment. I do not know how formal you are going to do this assignment, but for bugs not much are needed..., for new features it would be really nice if a formal design were present (we have been bad at those). Hi, It's great to see interest in this. However note that we are talking about 200 students. Even if they work in pairs, having design discussions with 100 pairs may be too much. I think we might need a filtering scheme so that only meaningful questions make it to this list. As I mentioned, student ability varies widely and you probably don't want to hear about lots of trivial stuff. How long period is this assignment ment to take? Probably at least 1 month and at most 3 months. I'm not sure yet. Amir Would be fun to get 200 developers for a short while :-) I promises, as long as it does not conflict with RL, I'll du my best to encourage and help. -- Lgb
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003 12:28 am, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | We are always interested. One thing that I would note is that we're a > | small collection of programmers and are very wary of enormous > | patches, prefering a 'little and often' approach. Moreover, because > | we are trying to clean the code base up (and have been doing so for > | several years) we have found it useful to have preliminary and > | informal discussions about the best way to implement some suggestion. > | Often the design becomes far more generic as a result. Getting your > | students to participate in such discussions would be an excellent > | thing for them to do anyway. > > Yes, and this would be required for them to get a patch into Lyx > anyway, and should absolutely be part of the assignment. > I do not know how formal you are going to do this assignment, but for > bugs not much are needed..., for new features it would be really nice > if a formal design were present (we have been bad at those). Hi, It's great to see interest in this. However note that we are talking about 200 students. Even if they work in pairs, having design discussions with 100 pairs may be too much. I think we might need a filtering scheme so that only meaningful questions make it to this list. As I mentioned, student ability varies widely and you probably don't want to hear about lots of trivial stuff. > > How long period is this assignment ment to take? > Probably at least 1 month and at most 3 months. I'm not sure yet. Amir > Would be fun to get 200 developers for a short while :-) > I promises, as long as it does not conflict with RL, I'll du my best > to encourage and help. > > -- > Lgb >
LyX programming assignment in class of 200 3rd year SE students
Hi, I'm thinking of giving a LyX programming assignment to a class of 200 3rd year software engineering students. This is for COMP3141 at UNSW: http://www.cse.unsw.edu.au/~cs3141 The students vary considerably in ability from some who are quite weak to superstar programmers. Consequently, if I were to give a LyX programming assignment, I would let the students choose their own topics. In this way, weaker students can work on something simple like a bug fix (which may involve non-trivial debugging) or minor feature request while stronger students can work on more ambitious additions to LyX. I was wondering if you have any interest in this experiment. In particular, would any LyX developers be able to suggest bug fixes, minor feature requests, major features, etc? Also, if students get stuck, would they be able to get any help? I am personally not knowledgeable of the LyX design (yet), though I have worked with students on the DRT design recovery tool to help people recover the design of interactive graphical applications such as LyX. Maybe DRT would be helpful to students in this assignment :) http://www.cse.unsw.edu.au/~amichail/seqdiag.png http://www.cse.unsw.edu.au/~amichail/combined.png http://www.cse.unsw.edu.au/~drt Please let me know if there is any interest in this. A class of 200 students may be able to make some valuable contributions to the LyX project. Amir
LyX programming assignment in class of 200 3rd year SE students
Hi, I'm thinking of giving a LyX programming assignment to a class of 200 3rd year software engineering students. This is for COMP3141 at UNSW: http://www.cse.unsw.edu.au/~cs3141 The students vary considerably in ability from some who are quite weak to superstar programmers. Consequently, if I were to give a LyX programming assignment, I would let the students choose their own topics. In this way, weaker students can work on something simple like a bug fix (which may involve non-trivial debugging) or minor feature request while stronger students can work on more ambitious additions to LyX. I was wondering if you have any interest in this experiment. In particular, would any LyX developers be able to suggest bug fixes, minor feature requests, major features, etc? Also, if students get stuck, would they be able to get any help? I am personally not knowledgeable of the LyX design (yet), though I have worked with students on the DRT design recovery tool to help people recover the design of interactive graphical applications such as LyX. Maybe DRT would be helpful to students in this assignment :) http://www.cse.unsw.edu.au/~amichail/seqdiag.png http://www.cse.unsw.edu.au/~amichail/combined.png http://www.cse.unsw.edu.au/~drt Please let me know if there is any interest in this. A class of 200 students may be able to make some valuable contributions to the LyX project. Amir
LyX 1.3.0 compile problems with -finstrument-functions
Hi, We tried to write a LyX 1.3.0 template for DRT, but found that the source no longer compiles with CXXFLAGS=-finstrument-functions. This used to work with LyX 1.2.1. Here is the error (with Qt frontend): g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include - finstrument-functions -c dimension.C -MT dimension.lo -MD -MP -MF .deps/dimension.TPlo In file included from /usr/include/g++-3/cstring:7, from /usr/include/g++-3/std/straits.h:106, from /usr/include/g++-3/std/bastring.h:36, from /usr/include/g++-3/string:6, from ../../src/LString.h:23, from math_support.h:10, from dimension.C:17: /usr/include/string.h:229: declaration of `char *strerror (int) throw ()' throws different exceptions ../../src/config.h:428: than previous declaration `char *strerror (int)' make[3]: *** [dimension.lo] Error 1 make[3]: Leaving directory `/root/lyx-1.3.0/src/mathed' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/lyx-1.3.0/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/lyx-1.3.0/src' make: *** [all-recursive] Error 1 Amir
LyX 1.3.0 compile problems with -finstrument-functions
Hi, We tried to write a LyX 1.3.0 template for DRT, but found that the source no longer compiles with CXXFLAGS=-finstrument-functions. This used to work with LyX 1.2.1. Here is the error (with Qt frontend): g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include - finstrument-functions -c dimension.C -MT dimension.lo -MD -MP -MF .deps/dimension.TPlo In file included from /usr/include/g++-3/cstring:7, from /usr/include/g++-3/std/straits.h:106, from /usr/include/g++-3/std/bastring.h:36, from /usr/include/g++-3/string:6, from ../../src/LString.h:23, from math_support.h:10, from dimension.C:17: /usr/include/string.h:229: declaration of `char *strerror (int) throw ()' throws different exceptions ../../src/config.h:428: than previous declaration `char *strerror (int)' make[3]: *** [dimension.lo] Error 1 make[3]: Leaving directory `/root/lyx-1.3.0/src/mathed' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/lyx-1.3.0/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/lyx-1.3.0/src' make: *** [all-recursive] Error 1 Amir
DRT 0.1.0 available w/ LyX instructions
Hi, You can download a preliminary version of DRT with LyX 1.2.1 instructions here: http://www.cse.unsw.edu.au/~amichail/DRT-0.1.0.tar.gz Let us know if you encounter problems. Amir
DRT 0.1.0 available w/ LyX instructions
Hi, You can download a preliminary version of DRT with LyX 1.2.1 instructions here: http://www.cse.unsw.edu.au/~amichail/DRT-0.1.0.tar.gz Let us know if you encounter problems. Amir
solution for LyX problems under DRT + LyX demo in paper
Hi, I believe we can address the polling and cursor problems in LyX under DRT by identifying a user action as follows: * an X input determines the start of an action (e.g., key press) * a burst of X outputs (e.g., screen draw requests) determine the end of the action (e.g., show the corresponding letter on the screen) This way, frequent polling that doesn't update the screen will not extend an action indefinitely. Of course, if certain actions do not result in the screen being updated for long periods of times, then we will not identify their ends. Is this an issue in LyX? Do all actions result in some screen output relatively quickly? BTW, we have written a paper on DRT that uses LyX as a running example. See: http://www.cse.unsw.edu.au/~amichail/drt.pdf Feedback would be appreciated! We should be able to release a preliminary version of this tool + full instructions for getting LyX to work later this week. Amir
solution for LyX problems under DRT + LyX demo in paper
Hi, I believe we can address the polling and cursor problems in LyX under DRT by identifying a user action as follows: * an X input determines the start of an action (e.g., key press) * a burst of X outputs (e.g., screen draw requests) determine the end of the action (e.g., show the corresponding letter on the screen) This way, frequent polling that doesn't update the screen will not extend an action indefinitely. Of course, if certain actions do not result in the screen being updated for long periods of times, then we will not identify their ends. Is this an issue in LyX? Do all actions result in some screen output relatively quickly? BTW, we have written a paper on DRT that uses LyX as a running example. See: http://www.cse.unsw.edu.au/~amichail/drt.pdf Feedback would be appreciated! We should be able to release a preliminary version of this tool + full instructions for getting LyX to work later this week. Amir
Re: frequent polling in LyX (plus LyX under DRT screenshots)
Hi, Perhaps a configure flag could be used to build LyX in a way that works well under DRT? Although the polling change I mentioned (and others) may not be bug free, they do seem to get LyX working under DRT. You can see some preliminary results here in the following screenshots: http://www.cse.unsw.edu.au/~amichail/lyx8.png From the function sequence in the picture above, we see that the user probably moved the cursor up. However, that's not the whole story as made obvious by the before/after screenshots. In fact, the cursor moved out from math mode as well. This shows the importance of before/after pictures in explaining past actions (possibly performed by others). BTW, could someone tell me if the functions shown in the pictures are particularly relevant to the action? The darker the action label, the more relevant it is perceived to be to the action shown in the before/after pictures. To see how we arrived at the previous screenshot, see the following: http://www.cse.unsw.edu.au/~amichail/lyx1.png http://www.cse.unsw.edu.au/~amichail/lyx2.png http://www.cse.unsw.edu.au/~amichail/lyx3.png http://www.cse.unsw.edu.au/~amichail/lyx4.png http://www.cse.unsw.edu.au/~amichail/lyx5.png http://www.cse.unsw.edu.au/~amichail/lyx6.png http://www.cse.unsw.edu.au/~amichail/lyx7.png http://www.cse.unsw.edu.au/~amichail/lyx8.png I also found another problem with getting rid of cursor blinking. If you type a sentence and press return, the cursor will not appear for a while until it is told to blink on. By then, the after picture has already been taken, so cursor tracking is broken. So it's not sufficient to disable blinking. We also need to make cursors appear immediately when they are moved in various contexts. Amir
Re: frequent polling in LyX (plus LyX under DRT screenshots)
Hi, Perhaps a configure flag could be used to build LyX in a way that works well under DRT? Although the polling change I mentioned (and others) may not be bug free, they do seem to get LyX working under DRT. You can see some preliminary results here in the following screenshots: http://www.cse.unsw.edu.au/~amichail/lyx8.png >From the function sequence in the picture above, we see that the user probably moved the cursor up. However, that's not the whole story as made obvious by the before/after screenshots. In fact, the cursor moved out from math mode as well. This shows the importance of before/after pictures in explaining past actions (possibly performed by others). BTW, could someone tell me if the functions shown in the pictures are particularly relevant to the action? The darker the action label, the more relevant it is perceived to be to the action shown in the before/after pictures. To see how we arrived at the previous screenshot, see the following: http://www.cse.unsw.edu.au/~amichail/lyx1.png http://www.cse.unsw.edu.au/~amichail/lyx2.png http://www.cse.unsw.edu.au/~amichail/lyx3.png http://www.cse.unsw.edu.au/~amichail/lyx4.png http://www.cse.unsw.edu.au/~amichail/lyx5.png http://www.cse.unsw.edu.au/~amichail/lyx6.png http://www.cse.unsw.edu.au/~amichail/lyx7.png http://www.cse.unsw.edu.au/~amichail/lyx8.png I also found another problem with getting rid of cursor blinking. If you type a sentence and press return, the cursor will not appear for a while until it is told to blink on. By then, the after picture has already been taken, so cursor tracking is broken. So it's not sufficient to disable blinking. We also need to make cursors appear immediately when they are moved in various contexts. Amir
Re: frequent polling in LyX
Hi, The problem is not that the polling is slowing other programs down, but rather that it is presenting problems for our design recovery tool. I tried getting rid of this frequent polling by changing the code in WorkArea::WorkArea as follows: ...fl_add_free(FL_ALL_FREE, ...)... to ..fl_add_free(FL_INPUT_FREE,...)... This seems to have fixed the problem and LyX still seems to be working ok. Amir Amir Michail [EMAIL PROTECTED] writes: | Hi, | We have noticed that LyX performs frequent | polling. In particuar, C_WorkArea_work_area_handler | is called multiple times per second. | Is this frequent polling necessary for updating the display? | Or is the display updated immediately when changes | are made to the document? What os is this? And frequent (as in 50 times a second) does not harm anyting as long as now actual work is done. -- Lgb
Re: frequent polling in LyX
Hi, The problem is not that the polling is slowing other programs down, but rather that it is presenting problems for our design recovery tool. I tried getting rid of this frequent polling by changing the code in WorkArea::WorkArea as follows: ...fl_add_free(FL_ALL_FREE, ...)... to ..fl_add_free(FL_INPUT_FREE,...)... This seems to have fixed the problem and LyX still seems to be working ok. Amir Amir Michail <[EMAIL PROTECTED]> writes: | Hi, > | We have noticed that LyX performs frequent | polling. In particuar, C_WorkArea_work_area_handler | is called multiple times per second. > | Is this frequent polling necessary for updating the display? | Or is the display updated immediately when changes | are made to the document? What os is this? And frequent (as in 50 times a second) does not harm anyting as long as now actual work is done. -- Lgb
frequent polling in LyX
Hi, We have noticed that LyX performs frequent polling. In particuar, C_WorkArea_work_area_handler is called multiple times per second. Is this frequent polling necessary for updating the display? Or is the display updated immediately when changes are made to the document? Amir P.S. We are asking these questions so that we can properly support LyX in our design recovery tool, DRT. You can see progress we have made on DRT here: http://www.cse.unsw.edu.au/~drt/screenshot/index.html. You will need to click on the screenshot links to see the entire screenshot.
frequent polling in LyX
Hi, We have noticed that LyX performs frequent polling. In particuar, C_WorkArea_work_area_handler is called multiple times per second. Is this frequent polling necessary for updating the display? Or is the display updated immediately when changes are made to the document? Amir P.S. We are asking these questions so that we can properly support LyX in our design recovery tool, DRT. You can see progress we have made on DRT here: http://www.cse.unsw.edu.au/~drt/screenshot/index.html. You will need to click on the screenshot links to see the entire screenshot.
Re: Support for LyX in design recovery tool?
On Thu, 8 Aug 2002 11:05, you wrote:
If you get round to making a detailed step-by-step of what needs doing
(a preliminary patch ?) I'll be glad to look further
Hi,
I looked into getting rid of cursor blinking for the design recovery tool.
(This makes it easier to track the cursor from screenshots.) Apparently,
it's not easy to do since every inset has its own cursor blinking code, some
of which is not trivial (e.g., tabular inset).
I tried making the following change in BufferView_pimpl.C at the end of
of the void BufferView::Pimpl::cursorToggle() method:
// change toggle calls to show calls
if (!bv_-theLockingInset()) {
bv_-showCursor(); // instead of toggle
} else {
bv_-theLockingInset()-showInsetCursor(bv_); // instead of toggle
}
cursor_timeout.restart(); // as before
}
This works for the normal cursor and most but not all inset cursors. In
particular, it doesn't work for the tabular inset. Apparently, some
non-trivial work is being done in its toggle method.
BTW, getting rid of the cursor timeout doesn't work since in some cases the
cursor is not shown at all unless it is toggled from a timeout.
Also, I tried changing the cursor color using the dialog in the GUI. (Again,
a unique cursor color makes it easier to track the cursor from screenshots.)
For some reason, the cursor color changes were always ignored (lyx 1.2).
The color sliders also had some problems. For example, I couldn't pick
254 for red; it only gave me 253 or 255. Perhaps there is a way to explicitly
specify RGB values from the startup file?
Amir
regards
john
--
It is unbecoming for young men to utter maxims.
- Aristotle
Re: Support for LyX in design recovery tool?
On Thu, 8 Aug 2002 11:05, you wrote:
> If you get round to making a detailed step-by-step of what needs doing
> (a preliminary patch ?) I'll be glad to look further
>
Hi,
I looked into getting rid of cursor blinking for the design recovery tool.
(This makes it easier to track the cursor from screenshots.) Apparently,
it's not easy to do since every inset has its own cursor blinking code, some
of which is not trivial (e.g., tabular inset).
I tried making the following change in BufferView_pimpl.C at the end of
of the void BufferView::Pimpl::cursorToggle() method:
// change toggle calls to show calls
if (!bv_->theLockingInset()) {
bv_->showCursor(); // instead of toggle
} else {
bv_->theLockingInset()->showInsetCursor(bv_); // instead of toggle
}
cursor_timeout.restart(); // as before
}
This works for the normal cursor and most but not all inset cursors. In
particular, it doesn't work for the tabular inset. Apparently, some
non-trivial work is being done in its toggle method.
BTW, getting rid of the cursor timeout doesn't work since in some cases the
cursor is not shown at all unless it is toggled from a timeout.
Also, I tried changing the cursor color using the dialog in the GUI. (Again,
a unique cursor color makes it easier to track the cursor from screenshots.)
For some reason, the cursor color changes were always ignored (lyx 1.2).
The color sliders also had some problems. For example, I couldn't pick
254 for red; it only gave me 253 or 255. Perhaps there is a way to explicitly
specify RGB values from the startup file?
Amir
> regards
> john
> --
> "It is unbecoming for young men to utter maxims."
> - Aristotle
>
>
Re: Support for LyX in design recovery tool?
On Sun, Jul 28, 2002 at 02:24:46PM +1000, Amir Michail wrote: We are working on a design recovery tool for interactive graphical applications. Hey, cool project. I had much a similar idea to help me learn lyx internals a while ago, but it was of a much smaller scope, and I never had time to take it anywhere useful (http://functrace.sf.net/) Hi, Yes, your idea takes a similar dynamic approach. Do you plan to do method-repression for hiding commonly called functions that aren't very interesting ? e.g. when I move the mouse, after a while I don't want to see that workAreaMotionNotify() got called, because I've learnt that part of the code. This would make a more interactive mode usable, which is where I was planning to take functrace ... We only label interesting function calls so after a while the boring ones will not be labeled. (See http://www.cse.unsw.edu.au/~drt/screenshot/index.html.) To determine whether a function is boring or not, we use a somewhat complicated technique to compute function prevalence that is not sensitive to repeated actions or even similar actions. See the description here: http://www.cse.unsw.edu.au/~drt/idea/action_spectra.txt * compiling with -g -finstrument-functions * linking with an additional object file for the tracer code This bit would be easy to do. Yes. * non-blinking cursors having color 254,1,1 (we can track the cursor that way in the screenshots to identify the user's focus; 255,0,0 is likely to clash with other aspects of the display such as icons) Dunno about the colour, but the cursor management code is in screen.C, and it'd be easy to make it stop blinking. Check out the cursor_timeout variable as well: this is the timer that blinks the cursor. Ok, thanks. Is it possible to provide this support in the configure scripts? I don't see why not. I might even be co-erced into making a patch That would be great. I don't have a good understanding of the GNU build system. ... (I don't see any license though ?) Probably GPL. We just need to make sure it doesn't conflict with the licenses of code that we are reusing (e.g., xmon). Amir regards john
Re: Support for LyX in design recovery tool?
> On Sun, Jul 28, 2002 at 02:24:46PM +1000, Amir Michail wrote: > > We are working on a design recovery tool for > > interactive graphical applications. > > Hey, cool project. I had much a similar idea to help me learn lyx > internals a while ago, but it was of a much smaller scope, and I > never had time to take it anywhere useful (http://functrace.sf.net/) Hi, Yes, your idea takes a similar dynamic approach. > > Do you plan to do method-repression for hiding commonly called functions > that aren't very interesting ? e.g. when I move the mouse, after a while > I don't want to see that workAreaMotionNotify() got called, because I've > learnt that part of the code. This would make a more "interactive" mode > usable, which is where I was planning to take functrace ... We only label interesting function calls so after a while the boring ones will not be labeled. (See http://www.cse.unsw.edu.au/~drt/screenshot/index.html.) To determine whether a function is boring or not, we use a somewhat complicated technique to compute function prevalence that is not sensitive to repeated actions or even similar actions. See the description here: http://www.cse.unsw.edu.au/~drt/idea/action_spectra.txt > > > * compiling with -g -finstrument-functions > > > > * linking with an additional object file for the tracer code > > This bit would be easy to do. > Yes. > > * non-blinking cursors having color 254,1,1 (we can track the cursor > >that way in the screenshots to identify the user's focus; > >255,0,0 is likely to clash with other aspects of the display such > >as icons) > > Dunno about the colour, but the cursor management code is in screen.C, > and it'd be easy to make it stop blinking. > > Check out the "cursor_timeout" variable as well: this is the timer that > blinks the cursor. Ok, thanks. > > > Is it possible to provide this support in the configure scripts? > > I don't see why not. I might even be co-erced into making a patch That would be great. I don't have a good understanding of the GNU build system. > ... > > (I don't see any license though ?) Probably GPL. We just need to make sure it doesn't conflict with the licenses of code that we are reusing (e.g., xmon). Amir > > regards > john
Support for LyX in design recovery tool?
Hi, We are working on a design recovery tool for interactive graphical applications. See http://www.cse.unsw.edu.au/~drt Here are some screenshots of the prototype: http://www.cse.unsw.edu.au/~amichail/gui1.png http://www.cse.unsw.edu.au/~drt/screenshot/index.html We would like to support LyX. This requires a few things: * compiling with -g -finstrument-functions * linking with an additional object file for the tracer code * non-blinking cursors having color 254,1,1 (we can track the cursor that way in the screenshots to identify the user's focus; 255,0,0 is likely to clash with other aspects of the display such as icons) Is it possible to provide this support in the configure scripts? Amir P.S. These additions would probably also be helpful for accessibility tools.
Support for LyX in design recovery tool?
Hi, We are working on a design recovery tool for interactive graphical applications. See http://www.cse.unsw.edu.au/~drt Here are some screenshots of the prototype: http://www.cse.unsw.edu.au/~amichail/gui1.png http://www.cse.unsw.edu.au/~drt/screenshot/index.html We would like to support LyX. This requires a few things: * compiling with -g -finstrument-functions * linking with an additional object file for the tracer code * non-blinking cursors having color 254,1,1 (we can track the cursor that way in the screenshots to identify the user's focus; 255,0,0 is likely to clash with other aspects of the display such as icons) Is it possible to provide this support in the configure scripts? Amir P.S. These additions would probably also be helpful for accessibility tools.
CVSSearch improved; useful for LyX?
Hi, Our CVSSearch tool has improved recently with new features -- commit-based search and library component search -- as well as much improved speed accuracy. (File-based search remains slow for searches involving multiple apps however.) Moreover, the tool also lets you browse files, commits, and library usage patterns. Would anyone be interested in using it to search the LyX CVS repository? We can help you set it up if you are interested. You can see a demo with over 200 KDE apps here: http://horn.cse.unsw.edu.au/~cvssearch/Query.cgi The home page is here: http://cvssearch.sourceforge.net Amir P.S. The code in the demo has not been released in a beta yet. We hope to do that in a month after some testing in large open source projects such as LyX.
CVSSearch improved; useful for LyX?
Hi, Our CVSSearch tool has improved recently with new features -- commit-based search and library component search -- as well as much improved speed & accuracy. (File-based search remains slow for searches involving multiple apps however.) Moreover, the tool also lets you browse files, commits, and library usage patterns. Would anyone be interested in using it to search the LyX CVS repository? We can help you set it up if you are interested. You can see a demo with over 200 KDE apps here: http://horn.cse.unsw.edu.au/~cvssearch/Query.cgi The home page is here: http://cvssearch.sourceforge.net Amir P.S. The code in the demo has not been released in a beta yet. We hope to do that in a month after some testing in large open source projects such as LyX.
LyX CVS Depository
i, I would like to download the entire CVS depository for LyX. However, webcvs gives a depository that has been cut off at some point in the past. I can no longer go to the very first versions of the files. Do you know where I can get such a fuller CVS depository for LyX? While I need versions from the very beginning (or as early as possible), I do not need the very latest versions. Amir P.S. This is to test a new kind of search tool for code. It would only work well if I have access to early commits to the code. --- FYI, tool description follows CVSSearch: A New Way to Search through Source Code CVSSearch searches for code fragments using CVS comments. Specifically, it takes advantage of the fact that a CVS comment typically describes the lines of code involved in the commit and that this description will typically hold for many future versions. In other words, CVSSearch allows you to better search the most recent version of the code by looking at previous versions to better understand the current version. It works as follows: * typically, each comment in a CVS commit not only describes the change made but also indirectly describes the purpose of the lines of code involved in that change (e.g., "added footnote feature" indirectly tells you that the lines involved in the commit have something to do with footnotes) * each line in the code accumulates a "profile" that contains all words in commits that involved that line, and each word has an associated frequency, which is the number of commits that involved that line with a comment containing that word. The idea is to let you search the code base based on the profiles extracted from the CVS comments. This has several advantages: * if a line is affected by many commits, then you get multiple summaries/aspects of the purpose of that line, as described by multiple authors in multiple commits (in contrast, a comment in the code itself can be viewed as just one summary) * you can search for something like "editing window" and get a match even if the code does not contain these words but at least one author decided to use those terms to describe his modifications to the code. (That is, this allows us to address the vocabulary mismatch problem.) * you can search for "bug" to find lines in the code that are especially bug prone (since you have many commits with "bug fixed" or something similar) * you get very precise information about the exact lines in the code that relate to your query (which need not appear in a contiguous region of code) Intuitively speaking, a comment on a particular version of an application will probably continue to hold for a lot of versions that follow, so it makes sense to combine commit comments in this way. The method I described can be viewed as computing a *vertical* profile for each line from previous changes to the code. It is also possible to compute a *horizontal* profile for lines by looking at CVS comments in other projects with similar code. Thus, to get a meaningful profile for a line/group of lines, it is only necessary that a CVS comment has applied to those lines in the past of the current application or in some other application with similar code. (You can use local similarity, as is done with DNA, to identify similar code fragments in different contexts.) Of course, you can combine vertical and horizontal profiles. In this way, we can get around the great variation in CVS comment quality.
LyX CVS Depository
i, I would like to download the entire CVS depository for LyX. However, webcvs gives a depository that has been cut off at some point in the past. I can no longer go to the very first versions of the files. Do you know where I can get such a fuller CVS depository for LyX? While I need versions from the very beginning (or as early as possible), I do not need the very latest versions. Amir P.S. This is to test a new kind of search tool for code. It would only work well if I have access to early commits to the code. --- FYI, tool description follows CVSSearch: A New Way to Search through Source Code CVSSearch searches for code fragments using CVS comments. Specifically, it takes advantage of the fact that a CVS comment typically describes the lines of code involved in the commit and that this description will typically hold for many future versions. In other words, CVSSearch allows you to better search the most recent version of the code by looking at previous versions to better understand the current version. It works as follows: * typically, each comment in a CVS commit not only describes the change made but also indirectly describes the purpose of the lines of code involved in that change (e.g., "added footnote feature" indirectly tells you that the lines involved in the commit have something to do with footnotes) * each line in the code accumulates a "profile" that contains all words in commits that involved that line, and each word has an associated frequency, which is the number of commits that involved that line with a comment containing that word. The idea is to let you search the code base based on the profiles extracted from the CVS comments. This has several advantages: * if a line is affected by many commits, then you get multiple summaries/aspects of the purpose of that line, as described by multiple authors in multiple commits (in contrast, a comment in the code itself can be viewed as just one summary) * you can search for something like "editing window" and get a match even if the code does not contain these words but at least one author decided to use those terms to describe his modifications to the code. (That is, this allows us to address the vocabulary mismatch problem.) * you can search for "bug" to find lines in the code that are especially bug prone (since you have many commits with "bug fixed" or something similar) * you get very precise information about the exact lines in the code that relate to your query (which need not appear in a contiguous region of code) Intuitively speaking, a comment on a particular version of an application will probably continue to hold for a lot of versions that follow, so it makes sense to combine commit comments in this way. The method I described can be viewed as computing a *vertical* profile for each line from previous changes to the code. It is also possible to compute a *horizontal* profile for lines by looking at CVS comments in other projects with similar code. Thus, to get a meaningful profile for a line/group of lines, it is only necessary that a CVS comment has applied to those lines in the past of the current application or in some other application with similar code. (You can use local similarity, as is done with DNA, to identify similar code fragments in different contexts.) Of course, you can combine vertical and horizontal profiles. In this way, we can get around the great variation in CVS comment quality.
