Re: Child processes in LyX
Well, it seems you have already implemented most of this stuff. I think it looks great. Did you try to shove any of it into LyX? Regarding determining exiting on Windows: In addition to the thread, it is also common to just add a timer and poll check once in a while. That helps avoid threads, which are notoriously difficult to debug. So, I propose to go for the polling solution, potentially in addition to the signal handler on Unix. You need to associate a timer to a window on Windows. You can associate with the top-level LyX window. So, in order to do that, a process manager should probably expose some polling interface, which will poll all the live spawned processes. The LyX core would use the timer to call this polling interface once in a while. In other words, add a process manager to expose one single point for polling. Regarding the call-back: How common is it to copy process_data? Can't you just make that class uncopiable, and use the signals? Regards, Asger
Re: Windows build problem
Rob Bearman wrote: I've applied Asger's MSVC patch (http://thread.gmane.org/gmane.editors.lyx.devel/41102) but I'm having problems with the Windows build under Visual Studio.NET 2003. I get a bunch of failures trying to find certain *_moc.c files that didn't seem to have been generated: Try to build a release build, and see if that helps. If not, you can manually inspect the files in the moc_files folders to see if their custom build step is correct. Unfortunately, I do not have time to investigate myself now. As I'm new to this, is there a time I should expect Asger's work to be committed to the source base and is there any heads up short of my updating my CVS tree and watching for it? The concensus is that the patch is too messy as it is now, so some janitorial stuff is required before it goes in: 1) Angus is working on handling the process stuff 2) The lyxserver should be disabled in a nice way, rather than with lots of #ifdefs 3) Lars is working on introducing boost::filesystem to handle the FileInfo mess 4) When all that is done, the patch dwindles to a minimum, and I think it will be applied then. Any work to help this process, will speed it up. Until then, the best is to update the CVS and keep applied the patch. Unfortunately, my paternity leave ends on 1st of February, so my available time is reduced somewhat. Personally, I prefer to work on fixing bugs in the core, and Angus has generously volunteers to do some of the janitorial stuff. Regards, Asger
Re: LyX on Windows
Andre Poenitz wrote: Since we are at it: I had a look at the .vcproj and a more recent (and therefore possibly incompatible) version of LyX sources. Patch applied nicely, however I was not able get anywhere near a full compile. Compilation succeed for individual files, but there seemed to be files missing from boost (something with while.hpp and soemthing with msvc somewhere in the path). I believe I did add all necessary boost files to the CVS. Please try again with a fresh update. Are you building from a clean check out with only your patch applied? Do you have the boost path in your VS settings? Just '../../boost' is certainly not enough when you access the I do not have time to do a clean check out and apply the patch, but I think everything should be set up correctly in the project file. It is enough with a bunch of include directives to the boost files here. Regards, Asger
Re: Clean URI for wiki (Was: Questioning Why I Bother.)
On Sat, 29 Jan 2005, Georg Baum wrote: Am Samstag, 29. Januar 2005 05:50 schrieb [EMAIL PROTECTED]: Perhaps an alternative could be for you to temporarily increase the rights of .htaccess, and when I've verified that the settings are correct you can place them in the configuration file? Unfortunately rewrite rules in .htaccess and httpd.conf are not always equivalent :-( Great, and here I was hoping I could save Lars som work... Any ideas for how to fix this then? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [rework docs] default figure placement inside float
On Sat, 29 Jan 2005, Juergen Spitzmueller wrote:
[EMAIL PROTECTED] wrote:
Anyway, I have a memory of the alignment of figures being discussed by
Herbert among others. I think this was related to how to get correct
vertical spacing around the figure. Maybe we should ask for Herbert's
opinion here?
That was \begin{center}...\end{center} vs. \centering.
This issue has been fixed months ago (in 1.3.5 AFAIR).
Oh, that's nice. My mistake then.
/C
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Clean URI for wiki
[EMAIL PROTECTED] writes: | As for solutions, some are described here | http://www.pmwiki.org/wiki/Cookbook/CleanUrls | The solution I wrote about uses the 'RewriteEngine' to remap URIs by | adding the following to .htaccess | RewriteEngine on | RewriteBase / | RewriteRule ^([A-Z].*) /home/lyx/www/pmwiki/pmwiki.php?pagename=$1 [L,qsappend] | RedirectMatch 301 ^/$ http://wiki.lyx.org/pmwiki.php These just didn't work... What I did: Added two aliases: Alias /pub/ /home/lyx/www/pmwiki/pub/ Alias / /home/lyx/www/pmwiki/pmwiki.php/ And modified the $PubDirUrl in pmwiki.php from: $PubDirUrl = preg_replace(#/[^/]*\$#,/pub,$ScriptUrl,1); to $PubDirUrl = $ScriptUrl . /pub; Is it now working as you want it to? -- Lgb
Re: Child processes in LyX
Andre Poenitz wrote: On Fri, Jan 28, 2005 at 06:33:44PM +, Angus Leeming wrote: I thought I'd post where I've got to with OS-independent child processes. Wouldn't it possible to have a look at the QProcess implementation? Of course it is possible. I did. Much of it is unwritten (I'm talking about Qt/Win Free). I have also looked at the Gtk gspawn stuff and at ACE. I have even convinced myself that I understand some of it ;-) Angus
Re: Child processes in LyX
Asger Ottar Alstrup wrote: Well, it seems you have already implemented most of this stuff. I think it looks great. Did you try to shove any of it into LyX? Regarding determining exiting on Windows: In addition to the thread, it is also common to just add a timer and poll check once in a while. That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush(); That helps avoid threads, which are notoriously difficult to debug. Granted. I was trying to document the possible strategies. So, I propose to go for the polling solution, potentially in addition to the signal handler on Unix. I think that this is the best option. You need to associate a timer to a window on Windows. You can associate with the top-level LyX window. So, in order to do that, a process manager should probably expose some polling interface, which will poll all the live spawned processes. Oh, we have timers already. Calling the 'flush()' is trivial. The LyX core would use the timer to call this polling interface once in a while. In other words, add a process manager to expose one single point for polling. Regarding the call-back: How common is it to copy process_data? I can imagine creating a process_data variable when the converter stuff is parsed, no? \converter xyz png my_converter arg1 arg2 $$i $$o It might make sense to split the conversion string into an argv array only once. Remember, I'm still in the business of thinking through this stuff. Can't you just make that class uncopiable, and use the signals? Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message. Regards, Asger Thanks for taking the time to look at this. Angus
Re: Child processes in LyX
Angus Leeming wrote: That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush(); process_demultiplexor and flush are strange names, which I do not understand. Can you come up with something better than that? Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message. Split the process_data into two classes. One with the copiable stuff, and another with the call-back stuff. I assume that the process_data, in addition to the executable and command line parameters and pipe redirections, also can contain stuff like the used environment variables, the directory which the process should start in, platform specific stuff like whether the process starts minimized, maximised, etc., the process priority and so on. With such stuff in there, you almost have a boost::process candidate. In other words, to have that, I believe you have to make a system which can almost replace the platform specific APIs with little overhead, so that there is no reason for ever going to the native API. Regards, Asger
Re: [Patch] Rewrite of FormsFileDialog
Lars Gullik Bjønnes wrote: This is what it looks like simplifed and rewritten to use boost.filesystem. I have not changed the visual apparence of the dialog, so there are one widget too many on it currently (unused). Please comment. What's to comment? Fantastic! The existing code is a pile of ancient, fossilized poo. Of interest to paleoentologists but crap to the rest of us. Anything you do to simplify the code is a good think. IMO. Angus
Re: LyX WWW
Michael Schmitt wrote: Hello, www.lyx.org states that LyX runs on many Unix platforms, OS/2, and under Windows/Cygwin (this port requires an X server). I think we should change this text because we no longer require an X server on Windows. Yes we do. LyX/Win isn't ours, it's Ruurd's. No version of LyX, either released or built direct from CVS will compile out of the box on Windows. Sure that is about to change, but it hasn't changed yet. Angus
Re: Child processes in LyX
Asger Ottar Alstrup wrote: Angus Leeming wrote: That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush(); process_demultiplexor and flush are strange names, which I do not understand. Can you come up with something better than that? demultiplexor: I was using the language of Hugo Duncan (author of the giallo.sf.net OS-independent sockets/named pipes project) and of Aaron LaFramboise. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing/AaronsMultiplexingIdeas Equivalent URL: http://tinyurl.com/7ydyf Lots of different child processes are launched and all are monitored in only one place. That's the many inputs one output definition of a demultiplexor. flush: there's a separation here between monitoring the child processes to see when they exit (reaping the zombies in unix parlance) and actually calling the registered slots. Sure these can be done at the same time. That's an explicit polling strategy. However, a unix signal handler or a one thread watching each child process would update only an array of completed processes. In such an approach, flush() would simply loop over the slots associated with these completed processes and flush them from its store. Make sense now? Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message. Split the process_data into two classes. One with the copiable stuff, and another with the call-back stuff. Or, in the language of Alexandrescu, use Policies to parameterise the process_data class. I assume that the process_data, in addition to the executable and command line parameters and pipe redirections, also can contain stuff like the used environment variables, the directory which the process should start in, platform specific stuff like whether the process starts minimized, maximised, etc., the process priority and so on. In general, yes. For example, you might imaginge a command line parser that creates a process_data variable out of this little lot: foo bar outfile 21 input (Have I mentioned that I've written such a beast ;-) With such stuff in there, you almost have a boost::process candidate. I'll have a candidate for initial discussion, yes. I probably don't have enough breath in my body to see it through. In other words, to have that, I believe you have to make a system which can almost replace the platform specific APIs with little overhead, so that there is no reason for ever going to the native API. I think that the trick to writing such a flexible beast is to get the basic framework right. The stuff I posted feels right to me. All the flexibility will be needed only in process_data and in the spawn_process function. Once the thing is spawned, then interaction with it is relatively constrained. Regards, Asger I read elsewhere that paternity leave is now at an end. It's been fun having you around so much. Angus
Re: Child processes in LyX
Angus Leeming wrote: Asger Ottar Alstrup wrote: Angus Leeming wrote: child::process_demultiplexor::instance().flush(); process_demultiplexor and flush are strange names, which I do not [...complicated explanations for complicated names...] Make sense now? Those are terrible names, still. child::process_monitor::instance().poll(); is better, but you are so bright, you must be able to come up with something better than that. Use a word which people know, rather than cook up some fancy word which you have to google for and read pages to understand. If necessary, use a couple of words, rather than one complicated. Or, in the language of Alexandrescu, use Policies to parameterise the process_data class. Yeah, you can do that, but while that is very flexible, that is also complicated. YAGNI and KISS applies. In general, yes. For example, you might imaginge a command line parser that creates a process_data variable out of this little lot: foo bar outfile 21 input (Have I mentioned that I've written such a beast ;-) As we say in Denmark right now: Top nice. I read elsewhere that paternity leave is now at an end. It's been fun having you around so much. So sure. With a VS.NET setup, it is much easier for me to dip in from time to time, so expect the odd patch from time to time. Regards, Asger
Re: [Patch] Rewrite of FormsFileDialog
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: This is what it looks like simplifed and rewritten to use boost.filesystem. I have not changed the visual apparence of the dialog, so there are one widget too many on it currently (unused). Please comment. | What's to comment? Fantastic! The existing code is a pile of ancient, | fossilized poo. Of interest to paleoentologists but crap to the rest | of us. Anything you do to simplify the code is a good think. IMO. I have another patch as well now... one that removes FileInfo completely. I'll post that after making a test compile and lookint it over. btw. We have lots and lots of filesystem-race conditions. Most often these does not matter much, but we should plan to get rid of them... fs::exists(foo) fs::is_directory(foo) is actually racy and can result in an unwanted exeption since foo can have been deleted between the call to exists and the call to is_directory. -- Lgb
[Patch] SnippetConversion for previews and DocBook
Hi Angus, Hi José!
-- I guess this is for you! :-)
I implemented a basic version for generating bitmap files for equations
in DocBook output. You can now export to Docbook or Docbook-xml and
dozens of eqn-XYZ.png files will appear.
Here is what I changed:
* refactored PreviewLoader to use a new class SnippetConversion
* added functions generateBitmaps() and bitmaps() in sgml.[hC]
* changed Buffer::makeDocbookFile() to call createBitmaps()
* changed math_hullsinset::docbook() to look up a bitmap file for the
equation
and create a graphics element to an external file, which is also
added to
runparams.exportdata
* changed lyxpreview2bitmap.py and legacy_lyxpreview2ppm to happily
create
PNG files even without dvipng
So it works, but there are some details about filehandling,
architecture and the
Right Way of Docbooking where I would appreciate some feedback (see
below)
Patch attached.
Ciao
/Andreas
TODO:
- find out about sporadic child timeout errors
- test other bitmap formats (eps)
- improve naming of bitmap files
- create bitmaps in extra directory, not at the same level as the
master file
- some DocBook bells and whistles
- move the SnippetConversion* from sgml.C to exportdata
- Ask for overwrite of bitmap files (appears that eporter doesn't do
that yet)
snippetconversion.diff
Description: Binary data
/**
* \file PreviewLoader.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Angus Leeming
*
* Full author contact details are available in file CREDITS.
*/
#include config.h
#include GraphicsCache.h
#include SnippetConversion.h
#include PreviewLoader.h
#include PreviewImage.h
#include buffer.h
#include converter.h
#include debug.h
#include format.h
#include LColor.h
#include lyxrc.h
#include outputparams.h
#include frontends/lyx_gui.h // hexname
#include support/filetools.h
#include support/lstrings.h
#include support/lyxlib.h
#include support/convert.h
#include boost/bind.hpp
#include sstream
#include fstream
#include iomanip
namespace support = lyx::support;
using std::endl;
using std::find;
using std::fill;
using std::find_if;
using std::make_pair;
using boost::bind;
using std::ifstream;
using std::list;
using std::map;
using std::ofstream;
using std::ostream;
using std::ostringstream;
using std::pair;
using std::vector;
using std::string;
namespace {
typedef lyx::graphics::SnippetConversion::SnippetList SnippetList;
string const unique_filename(string const bufferpath);
Converter const * setConverter();
typedef mappid_t, lyx::graphics::SnippetConversion InProgressProcesses;
typedef InProgressProcesses::value_type InProgressProcess;
} // namespace anon
namespace lyx {
namespace graphics {
class PreviewLoader::Impl : public boost::signals::trackable {
public:
///
Impl(PreviewLoader p, Buffer const b);
/// Stop any SnippetConversion items still executing.
~Impl();
///
PreviewImage const * preview(string const latex_snippet) const;
///
PreviewLoader::Status status(string const latex_snippet) const;
///
void add(string const latex_snippet);
///
void remove(string const latex_snippet);
///
void startLoading();
/// Emit this signal when an image is ready for display.
boost::signalvoid(PreviewImage const ) imageReady;
Buffer const buffer() const { return buffer_; }
private:
/// Called by the Forkedcall process that generated the bitmap files.
void finishedGenerating(pid_t, int);
/** cache_ allows easy retrieval of already-generated images
* using the LaTeX snippet as the identifier.
*/
typedef boost::shared_ptrPreviewImage PreviewImagePtr;
///
typedef mapstring, PreviewImagePtr Cache;
///
Cache cache_;
/** pending_ stores the LaTeX snippets in anticipation of them being
* sent to the converter.
*/
SnippetList pending_;
/** in_progress_ stores all forked processes so that we can proceed
* thereafter.
The map uses the conversion commands as its identifiers.
*/
InProgressProcesses in_progress_;
///
PreviewLoader parent_;
///
Buffer const buffer_;
///
double font_scaling_factor_;
/// We don't own this
static Converter const * pconverter_;
};
Converter const * PreviewLoader::Impl::pconverter_;
// The public interface, defined in PreviewLoader.h
//
PreviewLoader::PreviewLoader(Buffer const b)
: pimpl_(new Impl(*this, b))
{}
PreviewLoader::~PreviewLoader()
{}
PreviewImage const * PreviewLoader::preview(string const latex_snippet) const
{
return pimpl_-preview(latex_snippet);
}
PreviewLoader::Status PreviewLoader::status(string const latex_snippet)
Re: Child processes in LyX
Angus Leeming [EMAIL PROTECTED] writes: In general, yes. For example, you might imaginge a command line parser ... (Have I mentioned that I've written such a beast I think it's the frst time, this year. /Andreas
Re: [Patch] Rewrite of FormsFileDialog
On Sun, Jan 30, 2005 at 03:26:12PM +, Angus Leeming wrote: Please comment. What's to comment? Fantastic! The existing code is a pile of ancient, fossilized poo. Just what I thought, reading this as a complete non-expert. Of interest to paleoentologists but crap to the rest of us. Surely you mean palaeoentomologists? As in old bugs? Anything you do to simplify the code is a good think. IMO. Angus - Hear hear, Martin
Re: Child processes in LyX
Andreas Vox wrote: In general, yes. For example, you might imaginge a command line parser (Have I mentioned that I've written such a beast I think it's the frst time, this year. ;-) Angus (cooking golden pork with ginger and garlic and soy sauce and currently crying lots from the vapours from the pureed onions.)
Re: [Patch] Rewrite of FormsFileDialog
Lars Gullik Bjønnes wrote: btw. We have lots and lots of filesystem-race conditions. Most often these does not matter much, but we should plan to get rid of them... fs::exists(foo) fs::is_directory(foo) is actually racy and can result in an unwanted exeption since foo can have been deleted between the call to exists and the call to is_directory. I'm sure that you're the man for this |-P Angus
Re: [Patch] Rewrite of FormsFileDialog
Martin Vermeer wrote: What's to comment? Fantastic! The existing code is a pile of ancient, fossilized poo. Just what I thought, reading this as a complete non-expert. Of interest to paleoentologists but crap to the rest of us. Surely you mean palaeoentomologists? As in old bugs? Maybe. But I don't think it's buggy. I think it's ancient and crap. The latin term for a fossilised turd is coprolith, so let's call the file coprolithic and bury it properly. Angus
Re: [Patch] Rewrite of FormsFileDialog
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: btw. We have lots and lots of filesystem-race conditions. Most often these does not matter much, but we should plan to get rid of them... fs::exists(foo) fs::is_directory(foo) is actually racy and can result in an unwanted exeption since foo can have been deleted between the call to exists and the call to is_directory. | I'm sure that you're the man for this |-P Hmm da mm... I have no idea what I-P is... are you goading me? -- Lgb
Bug in os_win32.C
Dear Angus, there is a small bug in os_win32.C (tested with LyX 1.3.6cvs): Function cygwin_path_fix(bool) must be part of namespace os. Please change the signature to os::cygwin_path_fix(bool). Thanks, Michael
Re: Bug in os_win32.C
Michael Schmitt wrote: Dear Angus, there is a small bug in os_win32.C (tested with LyX 1.3.6cvs): Function cygwin_path_fix(bool) must be part of namespace os. Please change the signature to os::cygwin_path_fix(bool). Thanks, Michael. I've just spotted this myself. Incidentally, apart from the fact that the graphics conversion (for the screen) blocks the execution of LyX, I think that LyX 1.3.x/Win should now be a fully-functioning equivalent of LyX/*nix. If you really are using it in anger, then I'm sure that you'll discover bugs. Please report 'em all. Thanks, Michael Angus
Re: [Patch] Rewrite of FormsFileDialog
Lars Gullik Bjønnes wrote: Hmm da mm... I have no idea what I-P is... are you goading me? I never goad. I'm the diplomat around here, apparently. Angus
Re: [Patch] SnippetConversion for previews and DocBook
Am Sonntag, 30. Januar 2005 17:20 schrieb Andreas Vox: - Ask for overwrite of bitmap files (appears that eporter doesn't do that yet) It should do. See copyFile() in exporter.C. Are you really sure that it does not ask if a file exists already? Maybe this is related to the following: + string const bitmapfile = sgml::bitmaps()-findSnippet(ls.str()); + string const ext = . + GetExtension(bitmapfile); You should not create references to temporaries, but rather use something like string const bitmapfile = sgml::bitmaps()-findSnippet(ls.str()); efs '.' GetExtension(bitmapfile); and then use runparams.exportdata-addExternalFile(docbook-xml, bitmapfile, efs.str()); Georg
Re: [Patch] SnippetConversion for previews and DocBook
Georg Baum [EMAIL PROTECTED] writes: Am Sonntag, 30. Januar 2005 17:20 schrieb Andreas Vox: - Ask for overwrite of bitmap files (appears that eporter doesn't do that yet) It should do. See copyFile() in exporter.C. Are you really sure that it does not ask if a file exists already? Maybe this is related to the following: Indeed. I changed the code to: string const bitmapfile = sgml::bitmaps()-findSnippet(ls.str()); string const ext = . + GetExtension(bitmapfile); and now LyX asks before overwriting any *.png files (and we are lucky to have a yes to all option :-) ) Ciao /Andreas
Branch vs. Box
It seems to me that Box is going to be used more often than Branch is. Shouldn't Box acquire the menu shortcut? regards, john
Re: [Patch] Rewrite of FormsFileDialog
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: Hmm da mm... I have no idea what I-P is... are you goading me? | I never goad. I'm the diplomat around here, apparently. Hey... you left me just as clue-less. What is I-P? Here! Have one for the toad. -- Lgb
Re: [Patch] Kill FileInfo
On Sun, Jan 30, 2005 at 10:48:56PM +0100, Lars Gullik Bj?nnes wrote:
This patch kills all uses and replace it with calls to
boost.filesystem (+ a couple of new functions).
int IsFileWriteable(string const path)
{
- FileInfo fi(path);
-
- if (fi.access(FileInfo::wperm|FileInfo::rperm)) // read-write
- return 1;
- if (fi.readable()) // read-only
- return 0;
- return -1; // everything else.
+ int ret = -1;
+ if (fs::is_readable(path))
+ ++ret;
+ if (fs::is_writable(path))
+ ++ret;
+ return ret;
Hmm, this doesn't look equivalent?
john
Re: [Patch] Kill FileInfo
John Levon [EMAIL PROTECTED] writes:
| On Sun, Jan 30, 2005 at 10:48:56PM +0100, Lars Gullik Bj?nnes wrote:
This patch kills all uses and replace it with calls to
boost.filesystem (+ a couple of new functions).
| int IsFileWriteable(string const path)
| {
| - FileInfo fi(path);
| -
| - if (fi.access(FileInfo::wperm|FileInfo::rperm)) // read-write
| - return 1;
| - if (fi.readable()) // read-only
| - return 0;
| - return -1; // everything else.
| + int ret = -1;
| + if (fs::is_readable(path))
| + ++ret;
| + if (fs::is_writable(path))
| + ++ret;
| + return ret;
| Hmm, this doesn't look equivalent?
Hmm... you are right... wronly will also return 1 .. and it should
return -1
--
Lgb
Re: [Patch] Kill FileInfo
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Hmm... you are right... wronly will also return 1 .. and it should | return -1 I rewrote all callers of IsFileWriteable and removed the function completely. Besides I found a place where it was used wrong as well... -- Lgb
RE: Windows build problem
Try to build a release build, and see if that helps. If not, you can manually inspect the files in the moc_files folders to see if their custom build step is correct. No difference with the release build. Looking at the mocinput folder of the vcproj file, it's clear there's a bunch of missing files. This is where the custom build directives are, in case anyone's confused. This looks easily corrected assuming there's no magic I'm unaware of. The other build errors on this fresh release build: lyx fatal error C1083: Cannot open source file: '\lyx\lyx-devel\src\support\atoi.C': No such file or directory -- is this file supposed to be checked in and is not? C:\lyx\lyx-devel\src\insets\insetgraphicsParams.C(278): fatal error C1021: invalid preprocessor command 'warning' -- should be #pragma warning ... ? C:\lyx\lyx-devel\src\frontends\qt2\moc\QGraphics_moc.C(54): error C2947: expecting '' to terminate template-argument-list, found '' -- several of these in this file. The compiler wants a space before the trailing ''. But, yikes, this is generated code. I'm attaching the build log for anyone's convenience. Question: I'm curious about the history behind the vcproj build - was there no objection that this would have to be maintained separately from the other makefile(s) whenever a file is added/removed from the build. Or am I missing something? Thanks Rob buildlog.htm.bz2 Description: buildlog.htm.bz2
Re: Windows build problem
Rob Bearman [EMAIL PROTECTED] writes: | Question: I'm curious about the history behind the vcproj build - was | there | no objection that this would have to be maintained separately from the | other | makefile(s) whenever a file is added/removed from the build. Or am I | missing | something? This isn't really supported. If it is broken you get to keep all pieces. But you are free to glue them together as well. -- Lgb
Re: Child processes in LyX
Well, it seems you have already implemented most of this stuff. I think it looks great. Did you try to shove any of it into LyX? Regarding determining exiting on Windows: In addition to the thread, it is also common to just add a timer and poll check once in a while. That helps avoid threads, which are notoriously difficult to debug. So, I propose to go for the polling solution, potentially in addition to the signal handler on Unix. You need to associate a timer to a window on Windows. You can associate with the top-level LyX window. So, in order to do that, a process manager should probably expose some polling interface, which will poll all the live spawned processes. The LyX core would use the timer to call this polling interface once in a while. In other words, add a process manager to expose one single point for polling. Regarding the call-back: How common is it to copy process_data? Can't you just make that class uncopiable, and use the signals? Regards, Asger
Re: Windows build problem
Rob Bearman wrote: > I've applied Asger's MSVC patch > (http://thread.gmane.org/gmane.editors.lyx.devel/41102) but I'm having > problems with the Windows build under Visual Studio.NET 2003. I get a > bunch of failures trying to find certain *_moc.c files that didn't seem > to have been generated: Try to build a release build, and see if that helps. If not, you can manually inspect the files in the moc_files folders to see if their custom build step is correct. Unfortunately, I do not have time to investigate myself now. > As I'm new to this, is there a time I should expect Asger's work to be > committed to the source base and is there any heads up short of my > updating my CVS tree and watching for it? The concensus is that the patch is too messy as it is now, so some janitorial stuff is required before it goes in: 1) Angus is working on handling the process stuff 2) The lyxserver should be disabled in a nice way, rather than with lots of #ifdefs 3) Lars is working on introducing boost::filesystem to handle the FileInfo mess 4) When all that is done, the patch dwindles to a minimum, and I think it will be applied then. Any work to help this process, will speed it up. Until then, the best is to update the CVS and keep applied the patch. Unfortunately, my paternity leave ends on 1st of February, so my available time is reduced somewhat. Personally, I prefer to work on fixing bugs in the core, and Angus has generously volunteers to do some of the janitorial stuff. Regards, Asger
Re: LyX on Windows
Andre Poenitz wrote: Since we are at it: I had a look at the .vcproj and a more recent (and therefore possibly incompatible) version of LyX sources. Patch applied nicely, however I was not able get anywhere near a full compile. Compilation succeed for individual files, but there seemed to be files missing from boost (something with while.hpp and soemthing with msvc somewhere in the path). I believe I did add all necessary boost files to the CVS. Please try again with a fresh update. Are you building from a clean check out with only your patch applied? Do you have the boost path in your VS settings? Just '../../boost' is certainly not enough when you access the I do not have time to do a clean check out and apply the patch, but I think everything should be set up correctly in the project file. It is enough with a bunch of include directives to the boost files here. Regards, Asger
Re: Clean URI for wiki (Was: Questioning Why I Bother.)
On Sat, 29 Jan 2005, Georg Baum wrote: > Am Samstag, 29. Januar 2005 05:50 schrieb [EMAIL PROTECTED]: > > Perhaps an alternative could be for you to temporarily increase the > rights > > of .htaccess, and when I've verified that the settings are correct you > can > > place them in the configuration file? > > Unfortunately rewrite rules in .htaccess and httpd.conf are not always > equivalent :-( "Great", and here I was hoping I could save Lars som work... Any ideas for how to fix this then? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [rework docs] default figure placement inside float
On Sat, 29 Jan 2005, Juergen Spitzmueller wrote:
> [EMAIL PROTECTED] wrote:
> > Anyway, I have a memory of the alignment of figures being discussed by
> > Herbert among others. I think this was related to how to get "correct"
> > vertical spacing around the figure. Maybe we should ask for Herbert's
> > opinion here?
>
> That was \begin{center}...\end{center} vs. \centering.
> This issue has been fixed months ago (in 1.3.5 AFAIR).
Oh, that's nice. My mistake then.
/C
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Clean URI for wiki
[EMAIL PROTECTED] writes:
| As for solutions, some are described here
>
| http://www.pmwiki.org/wiki/Cookbook/CleanUrls
>
| The solution I wrote about uses the 'RewriteEngine' to remap URIs by
| adding the following to .htaccess
>
| RewriteEngine on
| RewriteBase /
| RewriteRule ^([A-Z].*) /home/lyx/www/pmwiki/pmwiki.php?pagename=$1
[L,qsappend]
| RedirectMatch 301 ^/$ http://wiki.lyx.org/pmwiki.php
These just didn't work...
What I did:
Added two aliases:
Alias /pub/ /home/lyx/www/pmwiki/pub/
Alias / /home/lyx/www/pmwiki/pmwiki.php/
And modified the $PubDirUrl in pmwiki.php from:
$PubDirUrl = preg_replace("#/[^/]*\$#","/pub",$ScriptUrl,1);
to
$PubDirUrl = $ScriptUrl . "/pub";
Is it now working as you want it to?
--
Lgb
Re: Child processes in LyX
Andre Poenitz wrote: On Fri, Jan 28, 2005 at 06:33:44PM +, Angus Leeming wrote: I thought I'd post where I've got to with OS-independent child processes. Wouldn't it possible to have a look at the QProcess implementation? Of course it is possible. I did. Much of it is unwritten (I'm talking about Qt/Win Free). I have also looked at the Gtk gspawn stuff and at ACE. I have even convinced myself that I understand some of it ;-) Angus
Re: Child processes in LyX
Asger Ottar Alstrup wrote: Well, it seems you have already implemented most of this stuff. I think it looks great. Did you try to shove any of it into LyX? Regarding determining exiting on Windows: In addition to the thread, it is also common to just add a timer and poll check once in a while. That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush(); That helps avoid threads, which are notoriously difficult to debug. Granted. I was trying to document the possible strategies. So, I propose to go for the polling solution, potentially in addition to the signal handler on Unix. I think that this is the best option. You need to associate a timer to a window on Windows. You can associate with the top-level LyX window. So, in order to do that, a process manager should probably expose some polling interface, which will poll all the live spawned processes. Oh, we have timers already. Calling the 'flush()' is trivial. The LyX core would use the timer to call this polling interface once in a while. In other words, add a process manager to expose one single point for polling. Regarding the call-back: How common is it to copy process_data? I can imagine creating a process_data variable when the converter stuff is parsed, no? \converter xyz png "my_converter arg1 arg2 $$i $$o" It might make sense to split the conversion string into an argv array only once. Remember, I'm still in the business of thinking through this stuff. Can't you just make that class uncopiable, and use the signals? Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message. Regards, Asger Thanks for taking the time to look at this. Angus
Re: Child processes in LyX
Angus Leeming wrote: That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush(); process_demultiplexor and flush are strange names, which I do not understand. Can you come up with something better than that? Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message. Split the process_data into two classes. One with the copiable stuff, and another with the call-back stuff. I assume that the process_data, in addition to the executable and command line parameters and pipe redirections, also can contain stuff like the used environment variables, the directory which the process should start in, platform specific stuff like whether the process starts minimized, maximised, etc., the process priority and so on. With such stuff in there, you almost have a boost::process candidate. In other words, to have that, I believe you have to make a system which can almost replace the platform specific APIs with little overhead, so that there is no reason for ever going to the native API. Regards, Asger
Re: [Patch] Rewrite of FormsFileDialog
Lars Gullik Bjønnes wrote: This is what it looks like simplifed and rewritten to use boost.filesystem. I have not changed the visual apparence of the dialog, so there are one widget too many on it currently (unused). Please comment. What's to comment? Fantastic! The existing code is a pile of ancient, fossilized poo. Of interest to paleoentologists but crap to the rest of us. Anything you do to simplify the code is a good think. IMO. Angus
Re: LyX WWW
Michael Schmitt wrote: Hello, www.lyx.org states that "LyX runs on many Unix platforms, OS/2, and under Windows/Cygwin (this port requires an X server). " I think we should change this text because we no longer require an X server on Windows. Yes "we" do. LyX/Win isn't ours, it's Ruurd's. No version of LyX, either released or built direct from CVS will compile out of the box on Windows. Sure that is about to change, but it hasn't changed yet. Angus
Re: Child processes in LyX
Asger Ottar Alstrup wrote: Angus Leeming wrote: That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush(); process_demultiplexor and flush are strange names, which I do not understand. Can you come up with something better than that? demultiplexor: I was using the language of Hugo Duncan (author of the giallo.sf.net OS-independent sockets/named pipes project) and of Aaron LaFramboise. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing/AaronsMultiplexingIdeas Equivalent URL: http://tinyurl.com/7ydyf Lots of different child processes are launched and all are monitored in only one place. That's the "many inputs one output" definition of a demultiplexor. flush: there's a separation here between monitoring the child processes to see when they exit (reaping the zombies in unix parlance) and actually calling the registered slots. Sure these can be done at the same time. That's an explicit polling strategy. However, a unix signal handler or a "one thread watching each child process" would update only an array of "completed processes". In such an approach, flush() would simply loop over the slots associated with these completed processes and "flush" them from its store. Make sense now? Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message. Split the process_data into two classes. One with the copiable stuff, and another with the call-back stuff. Or, in the language of Alexandrescu, use Policies to parameterise the process_data class. I assume that the process_data, in addition to the executable and command line parameters and pipe redirections, also can contain stuff like the used environment variables, the directory which the process should start in, platform specific stuff like whether the process starts minimized, maximised, etc., the process priority and so on. In general, yes. For example, you might imaginge a "command line parser" that creates a process_data variable out of this little lot: "foo bar > outfile 2>&1 < input" (Have I mentioned that I've written such a beast ;-) With such stuff in there, you almost have a boost::process candidate. I'll have a candidate for "initial discussion", yes. I probably don't have enough breath in my body to see it through. In other words, to have that, I believe you have to make a system which can almost replace the platform specific APIs with little overhead, so that there is no reason for ever going to the native API. I think that the trick to writing such a flexible beast is to get the basic framework right. The stuff I posted feels right to me. All the flexibility will be needed only in process_data and in the spawn_process function. Once the thing is spawned, then interaction with it is relatively constrained. Regards, Asger I read elsewhere that paternity leave is now at an end. It's been fun having you around so much. Angus
Re: Child processes in LyX
Angus Leeming wrote: Asger Ottar Alstrup wrote: Angus Leeming wrote: child::process_demultiplexor::instance().flush(); process_demultiplexor and flush are strange names, which I do not [...complicated explanations for complicated names...] > Make sense now? Those are terrible names, still. child::process_monitor::instance().poll(); is better, but you are so bright, you must be able to come up with something better than that. Use a word which people know, rather than cook up some fancy word which you have to google for and read pages to understand. If necessary, use a couple of words, rather than one complicated. Or, in the language of Alexandrescu, use Policies to parameterise the process_data class. Yeah, you can do that, but while that is very flexible, that is also complicated. YAGNI and KISS applies. In general, yes. For example, you might imaginge a "command line parser" that creates a process_data variable out of this little lot: "foo bar > outfile 2>&1 < input" (Have I mentioned that I've written such a beast ;-) As we say in Denmark right now: Top nice. I read elsewhere that paternity leave is now at an end. It's been fun having you around so much. So sure. With a VS.NET setup, it is much easier for me to dip in from time to time, so expect the odd patch from time to time. Regards, Asger
Re: [Patch] Rewrite of FormsFileDialog
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> This is what it looks like simplifed and rewritten to use >> boost.filesystem. >> I have not changed the visual apparence of the dialog, so there are >> one widget too many on it currently (unused). >> Please comment. > | What's to comment? Fantastic! The existing code is a pile of ancient, | fossilized poo. Of interest to paleoentologists but crap to the rest | of us. Anything you do to simplify the code is a good think. IMO. I have another patch as well now... one that removes FileInfo completely. I'll post that after making a test compile and lookint it over. btw. We have lots and lots of filesystem-race conditions. Most often these does not matter much, but we should plan to get rid of them... fs::exists(foo) && fs::is_directory(foo) is actually racy and can result in an unwanted exeption since foo can have been deleted between the call to exists and the call to is_directory. -- Lgb
[Patch] SnippetConversion for previews and DocBook
Hi Angus, Hi José!
-- I guess this is for you! :-)
I implemented a basic version for generating bitmap files for equations
in DocBook output. You can now export to Docbook or Docbook-xml and
dozens of "eqn-XYZ.png" files will appear.
Here is what I changed:
* refactored PreviewLoader to use a new class SnippetConversion
* added functions generateBitmaps() and bitmaps() in sgml.[hC]
* changed Buffer::makeDocbookFile() to call createBitmaps()
* changed math_hullsinset::docbook() to look up a bitmap file for the
equation
and create a element to an external file, which is also
added to
runparams.exportdata
* changed lyxpreview2bitmap.py and legacy_lyxpreview2ppm to happily
create
PNG files even without dvipng
So it works, but there are some details about filehandling,
architecture and the
"Right Way of Docbooking" where I would appreciate some feedback (see
below)
Patch attached.
Ciao
/Andreas
TODO:
- find out about sporadic "child timeout" errors
- test other bitmap formats (eps)
- improve naming of bitmap files
- create bitmaps in extra directory, not at the same level as the
master file
- some DocBook bells and whistles
- move the SnippetConversion* from sgml.C to exportdata
- Ask for overwrite of bitmap files (appears that eporter doesn't do
that yet)
snippetconversion.diff
Description: Binary data
/**
* \file PreviewLoader.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Angus Leeming
*
* Full author contact details are available in file CREDITS.
*/
#include
#include "GraphicsCache.h"
#include "SnippetConversion.h"
#include "PreviewLoader.h"
#include "PreviewImage.h"
#include "buffer.h"
#include "converter.h"
#include "debug.h"
#include "format.h"
#include "LColor.h"
#include "lyxrc.h"
#include "outputparams.h"
#include "frontends/lyx_gui.h" // hexname
#include "support/filetools.h"
#include "support/lstrings.h"
#include "support/lyxlib.h"
#include "support/convert.h"
#include
#include
#include
#include
namespace support = lyx::support;
using std::endl;
using std::find;
using std::fill;
using std::find_if;
using std::make_pair;
using boost::bind;
using std::ifstream;
using std::list;
using std::map;
using std::ofstream;
using std::ostream;
using std::ostringstream;
using std::pair;
using std::vector;
using std::string;
namespace {
typedef lyx::graphics::SnippetConversion::SnippetList SnippetList;
string const unique_filename(string const bufferpath);
Converter const * setConverter();
typedef map InProgressProcesses;
typedef InProgressProcesses::value_type InProgressProcess;
} // namespace anon
namespace lyx {
namespace graphics {
class PreviewLoader::Impl : public boost::signals::trackable {
public:
///
Impl(PreviewLoader & p, Buffer const & b);
/// Stop any SnippetConversion items still executing.
~Impl();
///
PreviewImage const * preview(string const & latex_snippet) const;
///
PreviewLoader::Status status(string const & latex_snippet) const;
///
void add(string const & latex_snippet);
///
void remove(string const & latex_snippet);
///
void startLoading();
/// Emit this signal when an image is ready for display.
boost::signal imageReady;
Buffer const & buffer() const { return buffer_; }
private:
/// Called by the Forkedcall process that generated the bitmap files.
void finishedGenerating(pid_t, int);
/** cache_ allows easy retrieval of already-generated images
* using the LaTeX snippet as the identifier.
*/
typedef boost::shared_ptr PreviewImagePtr;
///
typedef map Cache;
///
Cache cache_;
/** pending_ stores the LaTeX snippets in anticipation of them being
* sent to the converter.
*/
SnippetList pending_;
/** in_progress_ stores all forked processes so that we can proceed
* thereafter.
The map uses the conversion commands as its identifiers.
*/
InProgressProcesses in_progress_;
///
PreviewLoader & parent_;
///
Buffer const & buffer_;
///
double font_scaling_factor_;
/// We don't own this
static Converter const * pconverter_;
};
Converter const * PreviewLoader::Impl::pconverter_;
// The public interface, defined in PreviewLoader.h
//
PreviewLoader::PreviewLoader(Buffer const & b)
: pimpl_(new Impl(*this, b))
{}
PreviewLoader::~PreviewLoader()
{}
PreviewImage const * PreviewLoader::preview(string const & latex_snippet) const
{
return pimpl_->preview(latex_snippet);
}
PreviewLoader::Status PreviewLoader::status(string const & latex_snippet) const
{
Re: Child processes in LyX
Angus Leeming <[EMAIL PROTECTED]> writes: > In general, yes. For example, you might imaginge a "command line parser" ... > (Have I mentioned that I've written such a beast I think it's the frst time, this year. /Andreas
Re: [Patch] Rewrite of FormsFileDialog
On Sun, Jan 30, 2005 at 03:26:12PM +, Angus Leeming wrote: > >Please comment. > > What's to comment? Fantastic! The existing code is a pile of ancient, > fossilized poo. Just what I thought, reading this as a complete non-expert. > Of interest to paleoentologists but crap to the rest of us. Surely you mean "palaeoentomologists"? As in old bugs? > Anything you do to simplify the code is a good think. IMO. > > Angus - Hear hear, Martin
Re: Child processes in LyX
Andreas Vox wrote: In general, yes. For example, you might imaginge a "command line parser" (Have I mentioned that I've written such a beast I think it's the frst time, this year. ;-) Angus (cooking golden pork with ginger and garlic and soy sauce and currently crying lots from the vapours from the pureed onions.)
Re: [Patch] Rewrite of FormsFileDialog
Lars Gullik Bjønnes wrote: btw. We have lots and lots of filesystem-race conditions. Most often these does not matter much, but we should plan to get rid of them... fs::exists(foo) && fs::is_directory(foo) is actually racy and can result in an unwanted exeption since foo can have been deleted between the call to exists and the call to is_directory. I'm sure that you're the man for this |-P Angus
Re: [Patch] Rewrite of FormsFileDialog
Martin Vermeer wrote: What's to comment? Fantastic! The existing code is a pile of ancient, fossilized poo. Just what I thought, reading this as a complete non-expert. Of interest to paleoentologists but crap to the rest of us. Surely you mean "palaeoentomologists"? As in old bugs? Maybe. But I don't think it's buggy. I think it's ancient and crap. The latin term for a fossilised turd is "coprolith", so let's call the file "coprolithic" and bury it properly. Angus
Re: [Patch] Rewrite of FormsFileDialog
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> btw. We have lots and lots of filesystem-race conditions. Most often >> these does not matter much, but we should plan to get rid of them... >> fs::exists(foo) && fs::is_directory(foo) is actually racy and can >> result in an unwanted exeption since foo can have been deleted between >> the call to exists and the call to is_directory. > | I'm sure that you're the man for this |-P Hmm da mm... I have no idea what "I-P" is... are you goading me? -- Lgb
Bug in os_win32.C
Dear Angus, there is a small bug in os_win32.C (tested with LyX 1.3.6cvs): Function "cygwin_path_fix(bool)" must be part of namespace "os". Please change the signature to "os::cygwin_path_fix(bool)". Thanks, Michael
Re: Bug in os_win32.C
Michael Schmitt wrote: Dear Angus, there is a small bug in os_win32.C (tested with LyX 1.3.6cvs): Function "cygwin_path_fix(bool)" must be part of namespace "os". Please change the signature to "os::cygwin_path_fix(bool)". Thanks, Michael. I've just spotted this myself. Incidentally, apart from the fact that the graphics conversion (for the screen) blocks the execution of LyX, I think that LyX 1.3.x/Win should now be a fully-functioning equivalent of LyX/*nix. If you really are using it in anger, then I'm sure that you'll discover bugs. Please report 'em all. Thanks, Michael Angus
Re: [Patch] Rewrite of FormsFileDialog
Lars Gullik Bjønnes wrote: Hmm da mm... I have no idea what "I-P" is... are you goading me? I never goad. I'm the diplomat around here, apparently. Angus
Re: [Patch] SnippetConversion for previews and DocBook
Am Sonntag, 30. Januar 2005 17:20 schrieb Andreas Vox:
> - Ask for overwrite of bitmap files (appears that eporter doesn't do
> that yet)
It should do. See copyFile() in exporter.C. Are you really sure that it
does not ask if a file exists already? Maybe this is related to the
following:
+ string const & bitmapfile = sgml::bitmaps()->findSnippet(ls.str());
+ string const & ext = "." + GetExtension(bitmapfile);
You should not create references to temporaries, but rather use something
like
string const bitmapfile = sgml::bitmaps()->findSnippet(ls.str());
efs << '.' << GetExtension(bitmapfile);
and then use
runparams.exportdata->addExternalFile("docbook-xml",
bitmapfile, efs.str());
Georg
Re: [Patch] SnippetConversion for previews and DocBook
Georg Baum <[EMAIL PROTECTED]> writes: > > Am Sonntag, 30. Januar 2005 17:20 schrieb Andreas Vox: > > > - Ask for overwrite of bitmap files (appears that eporter doesn't do > > that yet) > > It should do. See copyFile() in exporter.C. Are you really sure that it > does not ask if a file exists already? Maybe this is related to the > following: Indeed. I changed the code to: string const bitmapfile = sgml::bitmaps()->findSnippet(ls.str()); string const ext = "." + GetExtension(bitmapfile); and now LyX asks before overwriting any *.png files (and we are lucky to have a "yes to all" option :-) ) Ciao /Andreas
Branch vs. Box
It seems to me that "Box" is going to be used more often than "Branch" is. Shouldn't "Box" acquire the menu shortcut? regards, john
Re: [Patch] Rewrite of FormsFileDialog
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> Hmm da mm... I have no idea what "I-P" is... are you goading me? > | I never goad. I'm the diplomat around here, apparently. Hey... you left me just as clue-less. What is "I-P"? "Here! Have one for the toad." -- Lgb
Re: [Patch] Kill FileInfo
On Sun, Jan 30, 2005 at 10:48:56PM +0100, Lars Gullik Bj?nnes wrote:
> This patch kills all uses and replace it with calls to
> boost.filesystem (+ a couple of new functions).
int IsFileWriteable(string const & path)
{
- FileInfo fi(path);
-
- if (fi.access(FileInfo::wperm|FileInfo::rperm)) // read-write
- return 1;
- if (fi.readable()) // read-only
- return 0;
- return -1; // everything else.
+ int ret = -1;
+ if (fs::is_readable(path))
+ ++ret;
+ if (fs::is_writable(path))
+ ++ret;
+ return ret;
Hmm, this doesn't look equivalent?
john
Re: [Patch] Kill FileInfo
John Levon <[EMAIL PROTECTED]> writes:
| On Sun, Jan 30, 2005 at 10:48:56PM +0100, Lars Gullik Bj?nnes wrote:
>
>> This patch kills all uses and replace it with calls to
>> boost.filesystem (+ a couple of new functions).
>
| int IsFileWriteable(string const & path)
| {
| - FileInfo fi(path);
| -
| - if (fi.access(FileInfo::wperm|FileInfo::rperm)) // read-write
| - return 1;
| - if (fi.readable()) // read-only
| - return 0;
| - return -1; // everything else.
| + int ret = -1;
| + if (fs::is_readable(path))
| + ++ret;
| + if (fs::is_writable(path))
| + ++ret;
| + return ret;
>
| Hmm, this doesn't look equivalent?
Hmm... you are right... wronly will also return 1 .. and it should
return -1
--
Lgb
Re: [Patch] Kill FileInfo
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Hmm... you are right... wronly will also return 1 .. and it should | return -1 I rewrote all callers of IsFileWriteable and removed the function completely. Besides I found a place where it was used wrong as well... -- Lgb
RE: Windows build problem
> Try to build a release build, and see if that helps. If not, you can > manually inspect the files in the moc_files folders to see if their > custom build step is correct. No difference with the release build. Looking at the "mocinput" folder of the vcproj file, it's clear there's a bunch of missing files. This is where the custom build directives are, in case anyone's confused. This looks easily corrected assuming there's no magic I'm unaware of. The other build errors on this fresh release build: lyx fatal error C1083: Cannot open source file: '\lyx\lyx-devel\src\support\atoi.C': No such file or directory -- is this file supposed to be checked in and is not? C:\lyx\lyx-devel\src\insets\insetgraphicsParams.C(278): fatal error C1021: invalid preprocessor command 'warning' -- should be "#pragma warning ..." ? C:\lyx\lyx-devel\src\frontends\qt2\moc\QGraphics_moc.C(54): error C2947: expecting '>' to terminate template-argument-list, found '>>' -- several of these in this file. The compiler wants a space before the trailing '>'. But, yikes, this is generated code. I'm attaching the build log for anyone's convenience. Question: I'm curious about the history behind the vcproj build - was there no objection that this would have to be maintained separately from the other makefile(s) whenever a file is added/removed from the build. Or am I missing something? Thanks Rob buildlog.htm.bz2 Description: buildlog.htm.bz2
Re: Windows build problem
"Rob Bearman" <[EMAIL PROTECTED]> writes: | Question: I'm curious about the history behind the vcproj build - was | there | no objection that this would have to be maintained separately from the | other | makefile(s) whenever a file is added/removed from the build. Or am I | missing | something? This isn't really supported. If it is broken you get to keep all pieces. But you are free to glue them together as well. -- Lgb
