Comments, dummies, etc. Was: Re: SpaceLess() function is dead :) [Arnd and SMiyata, please read]
Hi,
the following is more general and is not only related to the small
patch:
On Fri, 10 Dec 1999 22:02:38 +0100 (MET), Asger K. Alstrup Nielsen
wrote:
>> >> +/** AHanses: Eliminate unneeded parameter for Unix: 'fork(void)'
>> >> + Unix will just ignore the spawnFlag parameter
>> >> +*/
>> >
>> >This comment should go. The remark that Unix should ignore the
>> >spawnFlag should go as a comment near the Fork-method.
>>
>> No problem. This was mostly for me. Nevertheless one personal note
>> here:
>> When reading sources originally written for OS/2 and compare them with
>> the usual hacks from bsd or GNU I see one important difference:
>>
>> The comments / code ratio is normally 2 / 1 or even 3 / 1 with broad
>> coverage of design, implementation, security, preconditions,
>> postconditions, restrictions, etc. It seems the usual Unix hacker
>> thinks he does not need to extensively comment out the source to avoid
>> design and implementation bugs. Why?
>
>The comment you wrote is placed the wrong place.
Yes, of course this a nice example how not to do comment. :)
>Also, please read the SystemCalls header file in cvs. It's richly
>commented.
No doubt. I was not aiming at this one. Other headers and implementions
are not so well commented (I'm currently thinking of figinst.h/C). My
points are:
1) In open source with a large number of rapidly changing contributors
comments are crucial to attract new collaborators and to assure project
survival when core contributors change. I think everybody knows
examples of failures.
2) LyX has the specific problem of complexity: Contributors like me,
who will never become really skilled programmers (but who may
contribute a huge number of small bits and pieces which, summed up, are
crucial) are likely to become frightened. So comments should become a
kind of short tutorial. And:
3) People tend never to read abstract documents. They read sources. So
there you should find the actual design documents. And doc++ is a good
thing to distill them.
So my idea was something similar to this:
Setup each source file with a comment form just at the beginning,
something like the following and ask developers to fill them by and by
(I think this will work better than abstract recommendations):
/*** xy.C: For usage and design info please refer to xy.h. Please add
here only comments describing the specific implementation. Those
comments should ease maintenance and bug tracing. So please be careful.
Please add a test of your implementation as a comment at the end of
this module.
**/
/*** xy.h: THE XY INTERFACES AND HOW TO USE THEM
SYNOPSIS and DESIGN PRINCIPLES:
DESCRIPTION OF WHAT THEY SHOULD DO:
PRECONDITIONS AND ASSUMPTIONS:
POSTCONDITIONS AND LIMITATIONS:
>
>> >Finally, the patch should be remade against the latest cvs version.
>>
>> I think I better let you do this, otherwise I might introduce more
>> bugs.
>
>If you do it, I'll review the patch before we apply it. I don't have
>time to redo the patch, and I can't possibly test it on OS/2.
Another somewhat more general point here: cvs is rapidly changing. Once
having setup some working patch the update is likely to break it. When
I've understood 50% of what's going on in the new version and have even
managed to understand the cvs manual there will have appeared the next
revision breaking everything again. So all in all it might be simpler
and faster for everybody if the core developer who is responsible for
this branch and doing most of the changes is somehow 'patronizing' a
patch, so as not to break it, etc. Or to wait for a 'frozen' design.
>
>> Please note that signals often are a portability headache, especially
>> when sending them to other processes. Did you investigate how this
>> works, e.g. in cygwin?
>
>No I did not. As with all other system code in LyX: We write it first,
>and then we learn about the problems with it when it is deployed on
>different platforms. This is the most cost effective way to go, and
>is the best way to take advantage of the open source development model
>where we have many testers.
Is it really? Bug tracing is AFAIK all in all by far the most costly
part of software development (some 10:1 or 20:1 depending on
complexity). Some kind of 'quality management' might be painful at
first but most cost effective on the long run.
>> >Would it be possible to use the alternative that waitForChild is
>> >different on EMX?
>>
>> Possible, yes! But why?
>
>Because waitForChild might be used several places, and then we will
>only need one #ifdef guard.
>
>> >> // Wait for child process to finish. Returns returncode from child.
>> >> +#ifndef __EMX__
>> >> void Systemcalls::waitForChild()
>> >> {
>> >
>> >> }
>> >> +#endif
>> >
>> >See above: Instead of dropping this function, please just make
>> >the waitForChild operation a dummy operation.
>>
>> No problem, but why bloat classes with dummy members? (IMHO the LyX
>> classes are bloated, I guess you really need some 60% o
Re: Internalization II
> "Soeren" == <" <[EMAIL PROTECTED]>> writes: Soeren> The export Menu is in the german version still showing english Soeren> names. I thing it's because of same shortcoming in de.po Hello, Thanks for the report. I updated de.po. JMarc
Re: lyx-1.1.3 view ps/dvi bug (?)
> "Jörg" == Jörg Ziefle <[EMAIL PROTECTED]> writes: Jörg> On 3 Dec 1999, Jean-Marc Lasgouttes wrote: >> > "Jörg" == Jörg Ziefle <[EMAIL PROTECTED]> >> writes: >> >> Jörg> Hi there, I just tried the new lyx-1.1.3 and encountered >> Jörg> problems viewing my old lyx files, especially the big ones, >> Jörg> while the smaller ones do well (the files are all in the same >> Jörg> directory, so there is no permission problem): >> >> Jörg> This error message is shown after the invocation of >> File->View Jörg> dvi >> >> Jörg> file:praktikantenbericht.dvi: No such file or directory >> >> Jörg> and this one after File->View PostScript >> >> Jörg> This is dvips(k) 5.86 Copyright 1999 Radical Eye Software >> Jörg> (www.radicaleye.com) dvips: ! DVI file can't be opened. Hello again, What does happen if you do File->Update_DVI? Are there errors? What does Edit->View LaTeX Log say? JMarc
figure-floats broken inside {multicols}
Hello,
Figure floats go missing from my postscript output whenever I add them
to text inside of the latex multicols \begin..\end region.
Non-floating figures are OK within multicols text.
Alternatively, when I comment out the latex \begin and \end directives
for multicols, the floating figure comes back when I:
file->view_postscript.
I browsed the Help-BUGS section but did not see this problem listed.
Details of my system, and the file I tested this with, are attached
below.
Thanks guys for your efforts.
--
Phil
I have this debian package:
Package: lyx
Maintainer: Michael Meskes <[EMAIL PROTECTED]>
Version: 1.1.2-2
Depends: libc6 (>= 2.1), libforms0.89, libstdc++2.10, libxpm4, xlib6g (>= 3.3.5-1)
on this system:
Linux toby 2.2.13 #6 Tue Nov 30 20:33:02 CST 1999 i586 unknown
#This file was created by Mon Dec 13 22:27:09 1999
#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
\lyxformat 2.15
\textclass report
\begin_preamble
\usepackage{multicol}
\end_preamble
\language default
\inputencoding latin1
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 2
\tocdepth 2
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\line_top \line_bottom
some component text or other.
\layout LaTeX
\backslash
begin{multicols}{2}
\layout Standard
and some more text follows here.
OK, now I insert a figure float.
\begin_float fig
\layout Standard
\align center
\begin_inset Figure size 148 209
file /usr/doc/gdb/refcard.ps
width 4 50
flags 9
\end_inset
\layout Caption
Now a caption
\end_float
And finally some more text.
Any figure-float inside of multicols seems to disappear.
A standard figure (without embedding the figure before the float caption)
works just fine.
\layout LaTeX
\backslash
end{multicols}
\the_end
Re: Blank removal after word deletion
> "Dieter" == Ing Dieter Jurzitza <[EMAIL PROTECTED]> writes: Dieter> Dear listmembers, another question that keeps me busy is the Dieter> insertion of empty lines. I can insert a hard return at the Dieter> end of the previous line but not at the end of the following Dieter> one. The same happens for the insertion of a blank line to Dieter> write any text as usual: I have to move to the end of the Dieter> previous line, cannot do that at the beginning of the Dieter> following line. Is that due to some misconfiguration of mine Dieter> or is that meant to be so? Many thanks for your efforts, best Dieter> regards Obvious question: are you sure you need to add empty lines? It is often better to add vertical space directly. There is also a function to do that when you press return at the beginning of a paragraph (I don't remember the name right now...) JMarc
Re: LyX 1.1.3 trace log - reproducible
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Why not try to do a diff on trans.h? Lars> I was just going to, but am currently on the wrong end of a Lars> 9.6Kb connection... Good reason. Lars> IMO the right fix is to change to Lars> char * Trans::Match(int c)... Looks like a bad fix. It just dies when I try to input an accented character now. Lars> Chars of any kind should not be used or this. I do not see how you will magically turn a signed char into an unsigned int without some kind of cast. JMarc
Re: LyX 1.1.3 trace log - reproducible
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | | Lars> Why not try to do a diff on trans.h? | | Lars> I was just going to, but am currently on the wrong end of a | Lars> 9.6Kb connection... | | Good reason. | | Lars> IMO the right fix is to change to | | Lars> char * Trans::Match(int c)... | | Looks like a bad fix. It just dies when I try to input an accented | character now. I will fix that. | Lars> Chars of any kind should not be used or this. | | I do not see how you will magically turn a signed char into an | unsigned int without some kind of cast. What I meant was that char of any kind should not ever be used for indexing arrays. Sure a cast will be needed. Lgb
Re: Internalization II
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Soeren" == <" <[EMAIL PROTECTED]>> writes: | | Soeren> The export Menu is in the german version still showing english | Soeren> names. I thing it's because of same shortcoming in de.po | | Hello, | | Thanks for the report. I updated de.po. Note that we cannot live with that way of updating po files, most of the po files miss a lot to work ok with the current lyx sources. Lgb
Re: Comments, dummies, etc. Was: Re: SpaceLess() function is dead :) [Arnd and SMiyata, please read]
"Arnd Hanses" <[EMAIL PROTECTED]> writes: | >Also, please read the SystemCalls header file in cvs. It's richly | >commented. | No doubt. I was not aiming at this one. Other headers and implementions | are not so well commented (I'm currently thinking of figinst.h/C). My | points are: figinset is a bad example. | 1) In open source with a large number of rapidly changing contributors | comments are crucial to attract new collaborators and to assure project | survival when core contributors change. I think everybody knows | examples of failures. The largest problem with contributors or larger pieces are when they leave the project, and that code written by part time contributors often is very convoluted. Witht that I mean that code often is overly complex and insted of doing the coding strait forward it is overly complex. | there you should find the actual design documents. And doc++ is a good | thing to distill them. One thing that is a lot beter than comments is code written in an obvilous way, easy to understand. Ad. problems using cvs. You are allowed to ask how to use it. When I am working on something that I don't want to commit right away I just make the changes to the checked out sources, when someone else commits to the repository I just do an update, in 90% of the cases the merge is done with out complict and the conflicts that happens is usually very easy to solve. (and then you make the patch) | /*** xy.C: For usage and design info please refer to xy.h. Please add | here only comments describing the specific implementation. Those | comments should ease maintenance and bug tracing. So please be careful. | Please add a test of your implementation as a comment at the end of | this module. | **/ | This is only true if thecomments are correct, you always have to check the sources anyway to see what the code really does. Lgb
Re: Internalization II
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> > "Soeren" == <" <[EMAIL PROTECTED]>> writes: | | Soeren> The Lars> export Menu is in the german version still showing english | Lars> Soeren> names. I thing it's because of same shortcoming in de.po Lars> | | Hello, | | Thanks for the report. I updated de.po. Lars> Note that we cannot live with that way of updating po files, Lars> most of the po files miss a lot to work ok with the current lyx Lars> sources. If we had the lyx.pot file available somewhere (it is not in cvs anymore), translators could maybe grab it an update the po files. Also, when we have the new menu code, we will no longer lose an entire menu because an entry is not translated. JMarc PS (somewhat unrelated): shouldn't the cvsweb interface be accessible directly from www.devel.lyx.org?
Re: LyX 1.1.3 trace log - reproducible
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I will fix that. That's what I figured out. Lars> | Lars> Chars of any kind should not be used or this. | | I do Lars> not see how you will magically turn a signed char into an | Lars> unsigned int without some kind of cast. Lars> What I meant was that char of any kind should not ever be used Lars> for indexing arrays. Sure a cast will be needed. Right. I let you handle that in the way you prefer. BTW, I thought I could release an _unsupported_ 1.1.3.1 patch fixing that and spaces in math equation, so that people are happy and we have time to work on 1.1.4. I think that, since every version has its own glitches (since we do so many changes, some problems have to appear), and we would maybe get more people to try out 1.1.x. I think that this 1.1.3.1 would be at least as stable as 1.0.4. How would you feel about that? JMarc
Re: Internalization II
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | | Lars> > "Soeren" == <" <[EMAIL PROTECTED]>> writes: | | Soeren> The | Lars> export Menu is in the german version still showing english | | Lars> Soeren> names. I thing it's because of same shortcoming in de.po | Lars> | | Hello, | | Thanks for the report. I updated de.po. | | Lars> Note that we cannot live with that way of updating po files, | Lars> most of the po files miss a lot to work ok with the current lyx | Lars> sources. | | If we had the lyx.pot file available somewhere (it is not in cvs | anymore), translators could maybe grab it an update the po files. This is a good reason to put it back into cvs. | Also, when we have the new menu code, we will no longer lose an entire | menu because an entry is not translated. True but this is not for menucode only. po file translators seems to thing that their work is over after the first submission. | JMarc | | PS (somewhat unrelated): shouldn't the cvsweb interface be accessible | directly from www.devel.lyx.org? Why? You can access it from www.lyx.org? (ok only in the news section) Lgb
Re: Internalization II
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | Also, when we have the new menu code, we will no longer lose Lars> an entire | menu because an entry is not translated. Lars> True but this is not for menucode only. po file translators Lars> seems to thing that their work is over after the first Lars> submission. We should maybe put them on a mailing list, and send a message when we need their attention... Lars> | JMarc | | PS (somewhat unrelated): shouldn't the cvsweb Lars> interface be accessible | directly from www.devel.lyx.org? Lars> Why? You can access it from www.lyx.org? (ok only in the news Lars> section) Ah, I missed the news section. But why is it on the regular www site, and not the devel one? JMarc
Re: LyX 1.1.3 trace log - reproducible
On 13 Dec 1999, Jean-Marc Lasgouttes wrote: > > BTW, I thought I could release an _unsupported_ 1.1.3.1 patch fixing > that and spaces in math equation, so that people are happy and we have > time to work on 1.1.4. I think that, since every version has its own > glitches (since we do so many changes, some problems have to appear), > and we would maybe get more people to try out 1.1.x. I think that this > 1.1.3.1 would be at least as stable as 1.0.4. Well, in debian our lyx maintainer has uploaded 1.1.2 to potato, since the consensus here was that it was reasonably stable, so that gives you quite a few people trying out the 1.1.x series. I'd be upset if he uploaded 1.1.3 with the math space bug, since that would seriously impact my use of LyX ;) but with that fixed Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: LyX 1.1.3 trace log - reproducible
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | BTW, I thought I could release an _unsupported_ 1.1.3.1 patch fixing | that and spaces in math equation, so that people are happy and we have | time to work on 1.1.4. I think that, since every version has its own | glitches (since we do so many changes, some problems have to appear), | and we would maybe get more people to try out 1.1.x. I think that this | 1.1.3.1 would be at least as stable as 1.0.4. | | How would you feel about that? Why not a prerelease of 1.1.4 instead? Anyway I am going to put out a 1.1.4pre1 today anyway, I think it is time, and I'd like to have 1.1.4 out before christmas. If you still want to make a 1.1.3.1 do that. Lgb
Re: Intuitive views of nesting -- conglomerate
(Duncan tried to get me to claim responsibility for my answer by addressing a mail privately to me. I won't fall for it! People with a clue are invited to respond.) On Mon, Dec 13, 1999 at 09:54:38PM +, Duncan Simpson wrote: > [re changes in the LyX file format] > > Are the changes drastic enough that I would need to rewrite the output stage > from stratch or would it be just twiddling a few strings? Rough how soon is > soon? (I really have plenty of other items on the wish list that I could do > while the .lyx format is unstable). > If you look at the Roadmap at devel.lyx.org, you'll see that the file format change isn't listed as a goal for either 1.4 or 1.5. This puts a lower limit of, let's say, a month on the change, with an upper limit somewhere around infinity. I suspect it will be somewhere in the middle :) It's basically a question of whether the people clamoring for GUI independence will win over those clamoring for XML or whatever. In any case, I think the changes wouldn't be too drastic. For example, the Tasks page says: - Enhance the LyX fileformat. Make it reflect the buffer structure a bit better, get rid of unneeded blank lines and spaces. That doesn't sound too bad, does it? The last time I remember lars talking about it, he wanted to make it a bit more like html (xml?) where you'd have begins and ends, not just begins, and perhaps better structuring for nesting. But that was months, perhaps a year ago. It's obviously not a very high priority, although as I mentioned there are some people clamoring for XML now, and I don't know if that would change matters. The other issue is that the change in file format might reflect the change in buffer structure, which I don't know when that's planned for. To sum up, word2lyx is probably one of the most common FAQ/requests we get, since new users are almost always coming from the Word universe (and will be for the foreseeable future). So I think a lot of people would be happy with word2lyx, and if the lyxers do change their format, it'll be up to them to let you know about the changes. (In any case, I have to imagine they'll keep the file format backward compatible, so it would be OK though not optimal if word2lyx were still writing the old format.) -Amir
Re: Intuitive views of nesting -- conglomerate
On Mon, 13 Dec 1999, Amir Karger wrote: > > That doesn't sound too bad, does it? The last time I remember lars talking > about it, he wanted to make it a bit more like html (xml?) where you'd have > begins and ends, not just begins, and perhaps better structuring for > nesting. But that was months, perhaps a year ago. It's obviously not a very > high priority, although as I mentioned there are some people clamoring for > XML now, and I don't know if that would change matters. The other issue is > that the change in file format might reflect the change in buffer structure, > which I don't know when that's planned for. I'm such a clamorer. But I don't think clamoring will make any difference. Code will :-). Next chance I get to spend on free software projects (after I sort out my debian projects) will be to grok the LyX kernel and think about XML. But that's no small task :-) Unless someone beats me to it... Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Comments, dummies, etc. Was: Re: SpaceLess() function is dead :) [Arnd and SMiyata, please read]
On 13 Dec 1999 18:28:14 +0100, Lars Gullik Bj°nnes wrote: > >| 1) In open source with a large number of rapidly changing contributors >| comments are crucial to attract new collaborators and to assure project >| survival when core contributors change. I think everybody knows >| examples of failures. > >The largest problem with contributors or larger pieces are when they >leave the project, and that code written by part time contributors >often is very convoluted. Witht that I mean that code often is overly >complex and insted of doing the coding strait forward it is overly >complex. If you write down some keywords about (or paint) your design, it automagically becomes lean and straightforward. An example: A friend of mine, as a programmer only an amteur like me, converted from closed source to open source fanatic (now he does lectures about open source). The reason was, the opening up made him comment his code. After doing this, he became aware of formerly hidden bugs and how to simplify the design. >| there you should find the actual design documents. And doc++ is a good >| thing to distill them. > >One thing that is a lot beter than comments is code written in an >obvilous way, easy to understand. There is actually a close relationship, IMHO. > >Ad. problems using cvs. You are allowed to ask how to use it. >When I am working on something that I don't want to commit right away >I just make the changes to the checked out sources, when someone else >commits to the repository I just do an update, in 90% of the cases the >merge is done with out complict and the conflicts that happens is >usually very easy to solve. >(and then you make the patch) Yes, but I expect myself to try out the doc's etc. and to search for some kind of tutorial, first. (This is to say, it might take some time, 'frozen' versions are therefore handy.) >| /*** xy.C: For usage and design info please refer to xy.h. Please add >| here only comments describing the specific implementation. Those >| comments should ease maintenance and bug tracing. So please be careful. >| Please add a test of your implementation as a comment at the end of >| this module. >| **/ >| > >This is only true if the comments are correct, you always have to check >the sources anyway to see what the code really does. If the comments are buggy the code... (see above ;-) Greets, Arnd
Re: Hebrew support for LyX
On Sat, 11 Dec 1999, Dekel Tsur wrote: > The following patch add basic Hebrew support for LyX: > When changing the document language to Hebrew (in Document Layout popup), > the text will be rendered from right-to-left > (except when entering TeX-mode) Cool! At last someone has done this! I've only read through the patch I haven't tried it however that's not going to stop me... > The patch is against the cvs source (Dec 11). > I should note that this patch is very incomplete (but still usable). > Furthermore, there may be better ways to add right-to-left support > for LyX (e.g., in the patch the text rendering is still done from left > to right. It may be better to do the rendering from right to left). The rendering method isn't a problem that could be altered later. It's the restriction on document language (ie. all or nothing) that is a problem IMO. What we really need is an inset or text mode that allows Hebrew or other RTL languages to be included in a LTR document and vice-versa. Actually, we need to be able to define the language of individual characters (or a phrase) and that should be a property of a text chunk. This idea is an extension of some of the generalised text insets that were done in the old development branch -- IIRC they were eventually renamed Elements. Anyway, don't let this put you off. We've needed someone to step forward and do this for ages now. Most of what you've done should be able to be reused/adopted I think. Maybe we could incorporate it and then modify the insets/Elements to work better with it although I'd be inclined to do the reverse and reintroduce the text elements and then adapt your work. > If the LyX developers choose to use this patch, then I would like to > become a developer to make additional changes. You are certainly most welcome. Allan. (ARRae)
