Re: Pending patches for the 1.3.x tree
But you argue that is it not really a problem for what we are doing, right? What about spaces in paths? Angus Screws things up. Is that a problem in practice? (do we encounter this case in 1.3.x?) We have never had any official Windows users to date. What about filepaths with spaces on unices, then? IIRC they tend to break LaTeX runs anyway, so maybe we don't care either? Cheers, Kuba Ober
Re: Pending patches for the 1.3.x tree
What about filepaths with spaces on unices, then? IIRC they tend to break LaTeX runs anyway, so maybe we don't care either? Ahhh. But MikTeX on Windows definitely does support spaces in file names. Moreover, since everything is copied to a temp directory for compilation and the file names are mangled, there's no reason why a latex run shouldn't succeed anyway. That of course makes sense. Duh :) Cheers, Kuba
Re: Pending patches for the 1.3.x tree
> >>> But you argue that is it not really a problem for what we are > >>> doing, right? What about spaces in paths? > > > > Angus> Screws things up. > > > > Is that a problem in practice? (do we encounter this case in 1.3.x?) > > We have never had any official Windows users to date. What about filepaths with spaces on unices, then? IIRC they tend to break LaTeX runs anyway, so maybe we don't care either? Cheers, Kuba Ober
Re: Pending patches for the 1.3.x tree
> > What about filepaths with spaces on unices, then? IIRC they tend to break > > LaTeX runs anyway, so maybe we don't care either? > > Ahhh. But MikTeX on Windows definitely does support spaces in file names. > Moreover, since everything is copied to a temp directory for compilation > and the file names are mangled, there's no reason why a latex run > shouldn't succeed anyway. That of course makes sense. Duh :) Cheers, Kuba
Re: Missing stuff for Windows linking
On sobota 22 stycze 2005 08:45 am, Asger Ottar Alstrup wrote: Hi, I'm getting closer. 24 unresolved externals. One of them is the dll import issue with LyXLength. It seems I have to build a new static Qt to fix this, so that takes quite a while. Do you even want to use static Qt at all? This precludes any plugins etc. Is that what we really want? Most those errors are simple superfluous export/import definitions, removing them will cure the errors. Cheers, Kuba Ober
Re: Missing stuff for Windows linking
On sobota 22 styczeÅ 2005 08:45 am, Asger Ottar Alstrup wrote: > Hi, > > I'm getting closer. 24 unresolved externals. One of them is the dll > import issue with LyXLength. It seems I have to build a new static Qt to > fix this, so that takes quite a while. Do you even want to use static Qt at all? This precludes any plugins etc. Is that what we really want? Most those errors are simple superfluous export/import definitions, removing them will cure the errors. Cheers, Kuba Ober
Re: [wishlist] server-client-architecture for LyX
I rather think it is the user interface parts that need work in such a case. The core shouldn't really see the difference between two users updating one document, or one user moving rapidly back and forth doing modifications in two places. :-) Makes sense. Kuba
Re: [wishlist] server-client-architecture for LyX
On wtorek 18 stycze 2005 08:49 am, Andreas Vox wrote: Kuba Ober [EMAIL PROTECTED] writes: I rather think it is the user interface parts that need work in such a case. The core shouldn't really see the difference between two users updating one document, or one user moving rapidly back and forth doing modifications in two places. Makes sense. I still don't see how that will work if users hit the undo button. Will they undo their last own action or the last action any of them did? Without special provisions in the core, they would undo the globally most recent action. Methinks the core has to associate a couple of stately* things with each client. Undo history being one of them. Cheers, Kuba *) pun intended
Re: [wishlist] server-client-architecture for LyX
> I rather think it is the user interface parts that need work in > such a case. The core shouldn't really see the difference between > two users updating one document, or one user moving > rapidly back and forth doing modifications in two places. :-) Makes sense. Kuba
Re: [wishlist] server-client-architecture for LyX
On wtorek 18 styczeÅ 2005 08:49 am, Andreas Vox wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > > > I rather think it is the user interface parts that need work in > > > such a case. The core shouldn't really see the difference between > > > two users updating one document, or one user moving > > > rapidly back and forth doing modifications in two places. > > > > Makes sense. > > I still don't see how that will work if users hit the undo button. > Will they undo their last own action or the last action any of them > did? Without special provisions in the core, they would undo the globally most recent action. Methinks the core has to associate a couple of stately* things with each client. Undo history being one of them. Cheers, Kuba *) pun intended
Re: [wishlist] server-client-architecture for LyX
| I think we could have saved some time, if we were able to work both on a | single document at the same time. So I propose a | server-client-architecture for LyX that works in the same way as the | team modus of starcraft. One opens a server with the document to edit | and other people connect. This could also be usefull for visualisation if | you want to discuss with a remote person. Actaully this wouldn't be _that_ hard, it is all about having a nice protocol between the gui and the core. I guess I could do it in a week. This also fits quite well with some other cleanup that I'd really like to do, but there are problems as well... security is one. Man, if you can do it in a week and it works then I'm donating a case of good beer (or a monetary equivalent) to the cause (seriously). I didn't know LyX was that clean internally. For most other apps that would be close to a rewrite of the core parts. Cheers, Kuba
Re: [wishlist] server-client-architecture for LyX
> | I think we could have saved some time, if we were able to work both on a > | single document at the same time. So I propose a > | server-client-architecture for LyX that works in the same way as the > | "team modus" of starcraft. One opens a server with the document to edit > | and other people connect. This could also be usefull for visualisation if > | you want to discuss with a remote person. > > Actaully this wouldn't be _that_ hard, it is all about having a nice > protocol between the gui and the core. I guess I could do it in a > week. This also fits quite well with some other cleanup that I'd > really like to do, but there are problems as well... security is one. Man, if you can do it in a week and it works then I'm donating a case of good beer (or a monetary equivalent) to the cause (seriously). I didn't know LyX was that clean internally. For most other apps that would be close to a rewrite of the core parts. Cheers, Kuba
Re: PayPal account opened for donations
Have you looked at the page? http://www.lyx.org/donations.php Please tell if it is something in particular that needs to change. and meetings -- heh you should have just said out in the open that developers do need beer every once in a while :) Cheers, Kuba
Re: PayPal account opened for donations
We use it for more than beer. We use it for sleigh rides as well (and I have a scar to prove it.) Good and bad for you, then :) Anyway it is all about making developing LyX easier. Sure. btw. Did we make a hard decision on where to have the meeting this year? Uhoh. I forgot to tell everyone that it may be hard for me to make it in Poland. I'm going there in February, and while it might be imagineable for me to go there again in late 2005, I'd rather not to. I mean if people are worked up for going to Poland then sure I can stand by my word, but if there are other equally good places then I'd rather see the meeting take place in another equally good place :). Heck, if you are all very very worked up for going to Poland *and* are willing to find cheap online fares (that I could afford [TM] :) from Columbus, OH (CMH) to Poznan, PL (POZ) sometime late 2005, then why not. Will make my life easier, or rather my wife's. I bet she likes spending time with our now 6-month daughter rather than hunting fares online. I doubt there will be anything reasonable in the summer, and I want to have a vacation here in the U.S. this summer anyway. Maybe October would be good. Then I could go there for a say 7 days and make it happen. Anyway as soon as I have the tickets the decision will be final, given a blessing from my wife ;] Maybe i just need some cheerleading, I don't know. I'm lazy towards anything non-critical these days. That's what sleeping 5-6 hours a day everyday makes you :) Cheers, Kuba Ober
Re: PayPal account opened for donations
> Have you looked at the page? > > http://www.lyx.org/donations.php > > Please tell if it is something in particular that needs to change. "and meetings" -- heh you should have just said out in the open that developers do need beer every once in a while :) Cheers, Kuba
Re: PayPal account opened for donations
> We use it for more than beer. We use it for sleigh rides as well (and > I have a scar to prove it.) Good and bad for you, then :) > Anyway it is all about making developing LyX easier. Sure. > btw. Did we make a hard decision on where to have the meeting this > year? Uhoh. I forgot to tell everyone that it may be hard for me to make it in Poland. I'm going there in February, and while it might be imagineable for me to go there again in late 2005, I'd rather not to. I mean if people are worked up for going to Poland then sure I can stand by my word, but if there are other equally good places then I'd rather see the meeting take place in another equally good place :). Heck, if you are all very very worked up for going to Poland *and* are willing to find cheap online fares (that I could afford [TM] :) from Columbus, OH (CMH) to Poznan, PL (POZ) sometime late 2005, then why not. Will make my life easier, or rather my wife's. I bet she likes spending time with our now 6-month daughter rather than hunting fares online. I doubt there will be anything reasonable in the summer, and I want to have a vacation here in the U.S. this summer anyway. Maybe October would be good. Then I could go there for a say 7 days and make it happen. Anyway as soon as I have the tickets the decision will be final, given a blessing from my wife ;] Maybe i just need some cheerleading, I don't know. I'm lazy towards anything "non-critical" these days. That's what sleeping 5-6 hours a day everyday makes you :) Cheers, Kuba Ober
Re: symlinks, how about windows shortcuts?
I have no idea if Windows shortcuts can be accomodated easily, it would be great if at least the Qt file browser could handle them. Any ideas? IIRC if you don't get too fancy the Qt file browser simply launches a standard windows dialog box which IIRC handles shortcuts fine? As long as it returns the resolved path, not the one of the shortcut, of course. Kuba
Re: symlinks, how about windows shortcuts?
> I have no idea if Windows shortcuts can be accomodated easily, it would > be great if at least the Qt file browser could handle them. Any ideas? IIRC if you don't get too fancy the Qt file browser simply launches a standard windows dialog box which IIRC handles shortcuts fine? As long as it returns the resolved path, not the one of the shortcut, of course. Kuba
Re: [patch] Fix bug 1750
for more than 10 years the latex world is waiting for a parser, which works ... TeX? I presume that the safest, if not very lightweight way would be to use TeX itself. Reimplementing crux of TeX as far as macro processing goes isn't that hard if one has TeXbook handy, but if one could just use TeX itself that should get rid of any questions about whether there are bugs in implementation etc. I presume there's a way for TeX to output a canonical list of all macros defined so far. Kuba
Re: [patch] Fix bug 1750
On roda 22 grudzie 2004 05:45 pm, Herbert Voss wrote: Kuba Ober wrote: for more than 10 years the latex world is waiting for a parser, which works ... TeX? I presume that the safest, if not very lightweight way would be to use TeX itself. Reimplementing crux of TeX as far as macro processing goes isn't that hard if one has TeXbook handy, but if one could just use TeX itself that should get rid of any questions about whether there are bugs in implementation etc. I presume there's a way for TeX to output a canonical list of all macros defined so far. then go on, when it is easy ... ;-) So, you want to get a list of all macros defined in some TeX input? Or is there also something else that you want it to do? Seriously, I might be able to give you the TeX code to do it, just let me know exactly what you need. Kuba
Re: [patch] Fix bug 1750
> for more than 10 years the latex world is waiting for a > parser, which works ... TeX? I presume that the safest, if not very lightweight way would be to use TeX itself. Reimplementing crux of TeX as far as macro processing goes isn't that hard if one has TeXbook handy, but if one could just use TeX itself that should get rid of any questions about whether there are bugs in implementation etc. I presume there's a way for TeX to output a "canonical" list of all macros defined so far. Kuba
Re: [patch] Fix bug 1750
On Åroda 22 grudzieÅ 2004 05:45 pm, Herbert Voss wrote: > Kuba Ober wrote: > >>for more than 10 years the latex world is waiting for a > >>parser, which works ... > > > > TeX? I presume that the safest, if not very lightweight way would be to > > use TeX itself. > > > > Reimplementing crux of TeX as far as macro processing goes isn't that > > hard if one has TeXbook handy, but if one could just use TeX itself that > > should get rid of any questions about whether there are bugs in > > implementation etc. > > > > I presume there's a way for TeX to output a "canonical" list of all > > macros defined so far. > > then go on, when it is easy ... ;-) So, you want to get a list of all macros defined in some TeX input? Or is there also something else that you want it to do? Seriously, I might be able to give you the TeX code to do it, just let me know exactly what you need. Kuba
Re: [PATCH 13x, 14x] mangling temporary file names
On pitek 17 grudzie 2004 02:42 am, Georg Baum wrote: Kuba Ober wrote: I vaguely recall this idea being raised at one point or another, but can't the temporary file names be simply generated from some kind of a unique global counter, maybe merged with PID? We have a global counter, it is prepended to the mangled name. Otherwise it would not be unique. The reason for the additional mangling is that people get a clue where a file comes from when something goes wrong. OK, makes sense. Thanks! Kuba
Re: Questions about path conversions
Different idea: (almost) drop support for cygwin! Here is an idea I had while reading your message: we could also decide that the cygwin version of LyX is a posix-like one, and that it can only deal with unix-paths. This means that most special cygwin code will go away, and that LyX/Cygwin will be basically LyX/Unix. People who want to interact with native windows apps will then use the mingw (or msvc) version, which will always use windows paths. Does it look like an idea? I think it makes matters clearer. I think it makes sense. Kuba
Re: Questions about path conversions
I think we should probably use only internal_path and only work inside LyX with paths which use / as separator. Of course, a second problem is that win32 names will retain drive numbers, but stuff in filetools should take care of that. What about always using unix paths internally, and simply translating C:\dir\x into /C:/dir/x ? I.e. the os interface would always present unix paths to the application, and would always take unix paths from the application too? In the cross-platform projects that I work on that's what I always do. When paths are presented to the user, they are always presented in the OS form, so that all UI stuff uses something that looks native on given OS. But those OS-dependent paths are never stored anywhere, they exist only temporarily. As far as UNC paths go, I translate \\server\blublah into /server/blublah So, to translate those back to Windows paths, if the beginning matches /[a-zA-Z]: the first slash is dropped, and if the beginning matches /[^:/]+ then the first slash is replaced with \\ Cheers, Kuba Ober
Re: Questions about path conversions
On pitek 17 grudzie 2004 10:14 am, Kuba Ober wrote: I think we should probably use only internal_path and only work inside LyX with paths which use / as separator. Of course, a second problem is that win32 names will retain drive numbers, but stuff in filetools should take care of that. What about always using unix paths internally, and simply translating C:\dir\x into /C:/dir/x ? Alternatively, if you don't envision people having one-letter-named servers in UNC paths, you can drop the ':'. In my implementation I've left the ':' just in case. Kuba
Re: Questions about path conversions
On pitek 17 grudzie 2004 10:16 am, Jean-Marc Lasgouttes wrote: Kuba == Kuba Ober [EMAIL PROTECTED] writes: I think we should probably use only internal_path and only work inside LyX with paths which use / as separator. Of course, a second problem is that win32 names will retain drive numbers, but stuff in filetools should take care of that. Kuba What about always using unix paths internally, and simply Kuba translating C:\dir\x into /C:/dir/x ? And how does c:file.txt get translated? Windows has a strange notion of what an absolute path is. That is not an absolute path, but a relative path on a given drive :) I never explicitly supported relative path on gien drive, namely because in graphical windows environment it never makes any sense -- i.e. in the GUI you'd never type anything like that. For any other use, it's for input only anyway. So, for OS-to-unix translation, you simply always expand the OS path with full, absolute path. Only that makes any sense. In fact, I always convert any OS path to absolute path before unix-izing it, so I've never faced the problem directly. c:file.txt - c:\currentdir\file.txt - /c:/currentdir/file.txt Now, if you have stuff where relative paths are useful (e.g. project-relative), then those will never have a drive in them. If they do, they auomatically are treated like absolute paths and if e.g. the input box has a validator, it should reject such a path. Kuba
Re: [PATCH 13x, 14x] mangling temporary file names
On piÄtek 17 grudzieÅ 2004 02:42 am, Georg Baum wrote: > Kuba Ober wrote: > > I vaguely recall this idea being raised at one point or another, but > > can't the temporary file names be simply generated from some kind of a > > unique global counter, maybe merged with PID? > > We have a global counter, it is prepended to the mangled name. Otherwise it > would not be unique. The reason for the additional mangling is that people > get a clue where a file comes from when something goes wrong. OK, makes sense. Thanks! Kuba
Re: Questions about path conversions
> Different idea: (almost) drop support for cygwin! > > Here is an idea I had while reading your message: we could also decide > that the cygwin version of LyX is a posix-like one, and that it can > only deal with unix-paths. This means that most special cygwin code > will go away, and that LyX/Cygwin will be basically LyX/Unix. > > People who want to interact with native windows apps will then use the > mingw (or msvc) version, which will always use windows paths. > > Does it look like an idea? I think it makes matters clearer. I think it makes sense. Kuba
Re: Questions about path conversions
> I think we should probably use only internal_path and only work inside > LyX with paths which use / as separator. Of course, a second problem > is that win32 names will retain drive numbers, but stuff in filetools > should take care of that. What about always using unix paths internally, and simply translating C:\dir\x into /C:/dir/x ? I.e. the os interface would always present unix paths to the application, and would always take unix paths from the application too? In the cross-platform projects that I work on that's what I always do. When paths are presented to the user, they are always presented in the OS form, so that all UI stuff uses something that looks native on given OS. But those OS-dependent paths are never stored anywhere, they exist only temporarily. As far as UNC paths go, I translate \\server\blublah into /server/blublah So, to translate those back to Windows paths, if the beginning matches "/[a-zA-Z]:" the first slash is dropped, and if the beginning matches "/[^:/]+" then the first slash is replaced with \\ Cheers, Kuba Ober
Re: Questions about path conversions
On piÄtek 17 grudzieÅ 2004 10:14 am, Kuba Ober wrote: > > I think we should probably use only internal_path and only work inside > > LyX with paths which use / as separator. Of course, a second problem > > is that win32 names will retain drive numbers, but stuff in filetools > > should take care of that. > > What about always using unix paths internally, and simply translating > C:\dir\x into /C:/dir/x ? Alternatively, if you don't envision people having one-letter-named servers in UNC paths, you can drop the ':'. In my implementation I've left the ':' just in case. Kuba
Re: Questions about path conversions
On piÄtek 17 grudzieÅ 2004 10:16 am, Jean-Marc Lasgouttes wrote: > >>>>> "Kuba" == Kuba Ober <[EMAIL PROTECTED]> writes: > >> > >> I think we should probably use only internal_path and only work > >> inside LyX with paths which use / as separator. Of course, a second > >> problem is that win32 names will retain drive numbers, but stuff in > >> filetools should take care of that. > > Kuba> What about always using unix paths internally, and simply > Kuba> translating C:\dir\x into /C:/dir/x ? > > And how does c:file.txt get translated? Windows has a strange notion > of what an absolute path is. That is not an absolute path, but a relative path on a given drive :) I never explicitly supported "relative path on gien drive", namely because in graphical windows environment it never makes any sense -- i.e. in the GUI you'd never type anything like that. For any other use, it's for input only anyway. So, for OS-to-unix translation, you simply always expand the OS path with full, absolute path. Only that makes any sense. In fact, I always convert any OS path to absolute path before unix-izing it, so I've never faced the problem directly. c:file.txt -> c:\currentdir\file.txt -> /c:/currentdir/file.txt Now, if you have stuff where relative paths are useful (e.g. project-relative), then those will never have a drive in them. If they do, they auomatically are treated like absolute paths and if e.g. the input box has a validator, it should reject such a path. Kuba
Re: [PATCH 13x, 14x] mangling temporary file names
On czwartek 16 grudzie 2004 11:59 am, Angus Leeming wrote: Given a file name C:/foo/bar, I believe that the name of the temporary file should be C__foo_bar. Ie, the drive name should be included in the mangling. Ruurd was addressing this idea in his patch, but he simply removed the drive prefix from the mangled name. [...] I vaguely recall this idea being raised at one point or another, but can't the temporary file names be simply generated from some kind of a unique global counter, maybe merged with PID? Say if PID is 16940, you'd get 16940_.tmp, ..., 16940_000a.tmp and so on? That would preclude any need for mangling. But I presume there must be some other reason for mangling? I'm just trying to understand. Cheers, Kuba Ober
Re: [PATCH 13x, 14x] mangling temporary file names
On czwartek 16 grudzieÅ 2004 11:59 am, Angus Leeming wrote: > Given a file name "C:/foo/bar", I believe that the name of the temporary > file should be "C__foo_bar". Ie, the drive name should be included in the > mangling. Ruurd was addressing this idea in his patch, but he simply > removed the drive prefix from the mangled name. [...] I vaguely recall this idea being raised at one point or another, but can't the temporary file names be simply generated from some kind of a unique global counter, maybe merged with PID? Say if PID is 16940, you'd get 16940_.tmp, ..., 16940_000a.tmp and so on? That would preclude any need for mangling. But I presume there must be some other reason for mangling? I'm just trying to understand. Cheers, Kuba Ober
Re: [patch] cursor
On pitek 10 grudzie 2004 01:49 pm, Andre Poenitz wrote: On Mon, Dec 06, 2004 at 08:53:25PM +0100, Alfredo Braunstein wrote: Is this ok [self-explaining patch attached], or are there some kind of moral reasons for not showing half a cursor? I am not sure we are allowed to show the lower part of a cursor to minors at all. LOL
Re: [patch] cursor
On piÄtek 10 grudzieÅ 2004 01:49 pm, Andre Poenitz wrote: > On Mon, Dec 06, 2004 at 08:53:25PM +0100, Alfredo Braunstein wrote: > > Is this ok [self-explaining patch attached], or are there some kind of > > moral reasons for not showing half a cursor? > > I am not sure we are allowed to show the lower part of a cursor to > minors at all. LOL
Re: [patch] qt gluelength validator
And all those extra member functions could just as well be separate functions. It seems that even the std::string is now considered too fat. Most of what it does is possible to implement outside of the class. So I am not argueing against functions that operate on strings. I am argueing against the functions being part of the class. I guess it's mostly for convenience and that people got used to the paradigm. Although a flamewar ingitor topic, personally I consider QString fn; fopen(fn.local8Bit(), ...); to be more concise than class QStringUtils; ... fopen(QStringUtils::local8Bit(fn), ...); A winner would probably be the code below, since it's extensible -- you could add your own functions to the namespace. I guess you're right, then. But still, with Qt you already have it implemented, and whether it's part of QString or not, you still don't have to roll your own. using QStringUtilsNameSpace; ... fopen(local8Bit(fn), ...); Kuba
Re: [patch] qt gluelength validator
> And all those extra member functions could just as well be separate > functions. > > It seems that even the std::string is now considered too fat. Most of > what it does is possible to implement outside of the class. > > So I am not argueing against functions that operate on strings. I am > argueing against the functions being part of the class. I guess it's mostly for convenience and that people got used to the paradigm. Although a flamewar ingitor topic, personally I consider QString fn; fopen(fn.local8Bit(), ...); to be more concise than class QStringUtils; ... fopen(QStringUtils::local8Bit(fn), ...); A winner would probably be the code below, since it's extensible -- you could add your own functions to the namespace. I guess you're right, then. But still, with Qt you already have it implemented, and whether it's part of QString or not, you still don't have to roll your own. using QStringUtilsNameSpace; ... fopen(local8Bit(fn), ...); Kuba
Re: [patch] qt gluelength validator
Are you sure of this. I know that the std::string in libstdc++ has gotten quite a bit of performance tweaks lately. (gcc 3.4.x and 4.x) So they finally play catch up with Qt. Nice :) Even then, it's essentially just a dumb container. You'd expect something more of a useful string implementation. Afaik std::string doesn't have from8BitLocal(), fromUcs(), etc. Cheers, Kuba Ober
Re: [patch] qt gluelength validator
And I certainly don't think the Trolltech implementation will outperform either gcc's or VC++'s implementation. Performance is not exactly a highly visible target in Qt development... I don't think it will outperform, but it should be on par with. It's really not rocket science, at least that's what I gather by looking at libstdc++ 3.3.2 code. It's mainly about playing ball with that particular compiler version's optimizations (i.e. taking max advantage of them). Surely Qt probably won't be as version-specific as stdlibc++ is, but still we should expect reasonable performance out of it. And Tulip implements some concepts that stl does not (e.g. Java-style iterators) -- those concepts are easier to use for those who are not very comfortable with STL, and even people intimately familiar with STL might find them more to their liking. Which could be eaily implemented as add-on to standard containers. Completely non-intrusive. But hey, Trolls already did that. And the fact that it's for their containers shouldn't be of much difference unless someone does actual profiling and shows that it really performs badly. Whether it's STL or Tulip, it comes preassembled for you :) I.e. you, as the end user, does not have to reinvent the wheel. There's nothing great about STL apart from the fact that you don't have to code it. Most widely used implementations of STL are quite mediocre IIRC, performance-wise at least. That's five year old wisdom, I am afraid. Think about how many people still use VC6, don't have a clue that SP6 for it even exists, and who didn't hear of dinkumware's updates to VC6 STL either. [That's people who can't google either, but that's a side issue] There are many big software projects that are being maintained on VC6 out there. For some projects switching compilers is not a lighthearted decision -- in any nontrivial project, a new compiler version is very likely to expose bugs in the code, or even introduce bugs due to various creepy reasons that you'd rather not know about. I just think, most tulip work is a waste of resources. Do you remember how bad it was at one point in time when Lars started porting LyX to hardcore C++? All the compiler problems and STL mis/under-implementations, etc? Code bloat due to under-optimizations and compiler bugs? And so on? Now, think that Qt has to support some really odd/old compilers, and they use their own containers mainly to level the playing field across all systems. I.e. so that fix-that-compiler-bug code is limited to their containers, and not strewn across everywhere. And I actually wonder how Trolltech will meet its 4.0 deadline given the amount of meat that's missing in 4.0tp2 Did they even specify any hard deadlines? Cheers, Kuba Ober
Re: [patch] qt gluelength validator
On czwartek 09 grudzie 2004 10:42 am, Lars Gullik Bjnnes wrote: Kuba Ober [EMAIL PROTECTED] writes: Are you sure of this. I know that the std::string in libstdc++ has gotten quite a bit of performance tweaks lately. (gcc 3.4.x and 4.x) | | So they finally play catch up with Qt. Nice :) | | Even then, it's essentially just a dumb container. You'd expect something | more of a useful string implementation. Afaik std::string doesn't have | from8BitLocal(), fromUcs(), etc. Why should it? Because in real life applications you typically don't just look at a container of characters. You need conversion functions etc. just to interface with the real world out there, and in the best case you'll need to find, intall, test and use a 3rd party library. Which library might well not use std::string but char*, and so on. So you write some trivial wrappers. And waste some time to maintain them later. With Qt, you get the whole deal. I mean, the less work there's for you to do, the better, right? Especially if it's something as rudimentary as strings. You may argue that hey, it's not the job of STD to do such things. But then people just reimplement them everywhere. Just look around and see how many codec libraries (some of them buggy!) are there. Almost every major i18able project has one, or at least has some serious wrappers to other code. Heck, even pure-php projects have them (c.f. squirrelmail). One wishes there was one standard implementation. At least if you use Qt you don't have to look for it elsewhere, which I think is cool. Kuba
Re: [patch] qt gluelength validator
> Are you sure of this. I know that the std::string in libstdc++ has > gotten quite a bit of performance tweaks lately. > (gcc 3.4.x and 4.x) So they finally play catch up with Qt. Nice :) Even then, it's essentially just a dumb container. You'd expect something more of a useful string implementation. Afaik std::string doesn't have from8BitLocal(), fromUcs(), etc. Cheers, Kuba Ober
Re: [patch] qt gluelength validator
> And I certainly don't think the Trolltech implementation will outperform > either gcc's or VC++'s implementation. Performance is not exactly a > highly visible target in Qt development... I don't think it will outperform, but it should be on par with. It's really not rocket science, at least that's what I gather by looking at libstdc++ 3.3.2 code. It's mainly about playing ball with that particular compiler version's optimizations (i.e. taking max advantage of them). Surely Qt probably won't be as version-specific as stdlibc++ is, but still we should expect reasonable performance out of it. > > And Tulip implements some concepts that stl does not (e.g. Java-style > > iterators) -- those concepts are easier to use for those who are not very > > comfortable with STL, and even people intimately familiar with STL might > > find them more to their liking. > > Which could be eaily implemented as add-on to standard containers. > Completely non-intrusive. But hey, Trolls already did that. And the fact that it's for their containers shouldn't be of much difference unless someone does actual profiling and shows that it really performs badly. > > Whether it's STL or Tulip, it comes preassembled for you :) I.e. you, as > > the end user, does not have to reinvent the wheel. There's nothing great > > about STL apart from the fact that you don't have to code it. Most widely > > used implementations of STL are quite mediocre IIRC, performance-wise at > > least. > > That's five year old wisdom, I am afraid. Think about how many people still use VC6, don't have a clue that SP6 for it even exists, and who didn't hear of dinkumware's updates to VC6 STL either. [That's people who can't google either, but that's a side issue] There are many big software projects that are being maintained on VC6 out there. For some projects switching compilers is not a lighthearted decision -- in any nontrivial project, a new compiler version is very likely to expose bugs in the code, or even introduce bugs due to various creepy reasons that you'd rather not know about. > I just think, most tulip work is a waste of resources. Do you remember how bad it was at one point in time when Lars started "porting" LyX to hardcore C++? All the compiler problems and STL mis/under-implementations, etc? Code bloat due to under-optimizations and compiler bugs? And so on? Now, think that Qt has to support some really odd/old compilers, and they use their own containers mainly to level the playing field across all systems. I.e. so that fix-that-compiler-bug code is limited to their containers, and not strewn across everywhere. > And I actually > wonder how Trolltech will meet its 4.0 deadline given the amount of meat > that's missing in 4.0tp2 Did they even specify any hard deadlines? Cheers, Kuba Ober
Re: [patch] qt gluelength validator
On czwartek 09 grudzieÅ 2004 10:42 am, Lars Gullik BjÃnnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > >> Are you sure of this. I know that the std::string in libstdc++ has > >> gotten quite a bit of performance tweaks lately. > >> (gcc 3.4.x and 4.x) > | > | So they finally play catch up with Qt. Nice :) > | > | Even then, it's essentially just a dumb container. You'd expect something > | more of a useful string implementation. Afaik std::string doesn't have > | from8BitLocal(), fromUcs(), etc. > > Why should it? Because in real life applications you typically don't just look at a container of characters. You need conversion functions etc. just to interface with the real world out there, and in the best case you'll need to find, intall, test and use a 3rd party library. Which library might well not use std::string but char*, and so on. So you write some "trivial" wrappers. And waste some time to maintain them later. With Qt, you get the whole deal. I mean, the less work there's for you to do, the better, right? Especially if it's something as rudimentary as strings. You may argue that hey, it's not the job of STD to do such things. But then people just reimplement them everywhere. Just look around and see how many codec libraries (some of them buggy!) are there. Almost every major i18able project has one, or at least has some serious wrappers to other code. Heck, even pure-php projects have them (c.f. squirrelmail). One wishes there was one standard implementation. At least if you use Qt you don't have to look for it elsewhere, which I think is cool. Kuba
Re: autogen.sh and FC3
$ rpm -qf /usr/share/aclocal/libtool.m4 libtool-1.5.6-4 $ rpm -qf '*.m4' Either do rpm -qf *.m4 without quotes, or rpm -qf `locate .m4` rpm -qf always needs a real file to query, not a wildcard. Cheers, Kuba Ober
Re: autogen.sh and FC3
> $ rpm -qf /usr/share/aclocal/libtool.m4 > libtool-1.5.6-4 > > $ rpm -qf '*.m4' Either do rpm -qf *.m4 without quotes, or rpm -qf `locate .m4` rpm -qf always needs a real file to query, not a wildcard. Cheers, Kuba Ober
Re: Playing a bit with valgrind/massif
The last interesting thingy is the dark blue 'stack' entry. This memory grows when I press PageDown continuously and goes down when LyX has managed to keep up with the number of PageDown request I have issued. So there seems to be some recusrsivity going on when LyX cannot execute events fast enough. Is that normal? No, it's essentially bad design. Unfortunately, many big commercial apps suffer from it as well. Cheers, Kuba Ober
Re: Playing a bit with valgrind/massif
> The last interesting thingy is the dark blue 'stack' entry. This > memory grows when I press PageDown continuously and goes down when LyX > has managed to keep up with the number of PageDown request I have > issued. So there seems to be some recusrsivity going on when LyX > cannot execute events fast enough. Is that normal? No, it's essentially bad design. Unfortunately, many big commercial apps suffer from it as well. Cheers, Kuba Ober
Re: explicit destruction and placement new
On poniedziaek 22 listopad 2004 01:26 pm, Andre Poenitz wrote: On Mon, Nov 22, 2004 at 12:33:23PM +0100, Lars Gullik Bjnnes wrote: I am trying to make the inset hierarchy more immune to splicing and wrong usage. In mathed this construct is used *this = SomeClass(foo); Maybe operator= should destroy whatever resources should be destroyed, etc. The code with explicit destructor call and placement new is more efficient of course, but less intuitive. Cheers, Kuba Ober
Re: explicit destruction and placement new
On poniedziaÅek 22 listopad 2004 01:26 pm, Andre Poenitz wrote: > On Mon, Nov 22, 2004 at 12:33:23PM +0100, Lars Gullik BjÃnnes wrote: > > I am trying to make the inset hierarchy more immune to splicing and > > wrong usage. > > > > In mathed this construct is used > > > >*this = SomeClass(foo); Maybe operator= should destroy whatever resources should be destroyed, etc. The code with explicit destructor call and placement new is more efficient of course, but less intuitive. Cheers, Kuba Ober
Re: [PATCH/FYI] NVI for the masses.
For me a pure virtual method is an interface method and any other is an implentation. What's wrong with virtual interface methods? I prefer to think like Scott Meyers (of Effective C++/STL fame): 1. nonvirtual functions are invariants across specializations -- they should never be overriden because that's bug-prone and violates their real world meaning of being invariants 2. pure virtual functions specify interfaces; they lack reasonable default behaviour and should be implemented by specializations 3. impure virtual functions provide default behaviour that isn't against common sense in most cases, otherwise they are to be reimplemented in specializations I.e. there's nothing wrong with virtual interface methods, as long as they are used in the correct sense. Here derived class = specialization. Cheers, Kuba Ober
Re: [PATCH/FYI] NVI for the masses.
> For me a pure virtual method is an interface method and any other > is an implentation. What's wrong with virtual interface methods? I prefer to think like Scott Meyers (of Effective C++/STL fame): 1. nonvirtual functions are invariants across specializations -- they should never be overriden because that's bug-prone and violates their real world meaning of being invariants 2. pure virtual functions specify interfaces; they lack reasonable default behaviour and should be implemented by specializations 3. impure virtual functions provide default behaviour that isn't against common sense in most cases, otherwise they are to be reimplemented in specializations I.e. there's nothing wrong with virtual interface methods, as long as they are used in the correct sense. Here derived class = specialization. Cheers, Kuba Ober
Re: booktabs
La donna mobile Qual piuma al vento, Muto d'accento - e di pensiero. A woman is volatile [or variable or in flux] like a feather in the wind weak in words and in thoughts I think that it then goes on saying that still, they are worth to make love with... ROTFL :) I.e. what a male chauvinist am I :) Cheers, Kuba Ober
Re: booktabs
> >> La donna à mobile > >> Qual piuma al vento, > >> Muto d'accento - e di pensiero. A woman is volatile [or variable or in flux] like a feather in the wind weak in words and in thoughts > I think that it then goes on saying that still, they are worth to make love > with... ROTFL :) I.e. what a male chauvinist am I :) Cheers, Kuba Ober
Re: Is 1.3.x's README up to date?
On pitek 24 wrzesie 2004 06:20 am, Angus Leeming wrote: Specifically, the section: Does LyX have support for non-English speakers/writers/readers? At least Polish language support works :) Cheers, Kuba
Re: Is 1.3.x's README up to date?
On pitek 24 wrzesie 2004 09:04 am, Angus Leeming wrote: Kuba Ober wrote: On pi?tek 24 wrzesie? 2004 06:20 am, Angus Leeming wrote: Specifically, the section: Does LyX have support for non-English speakers/writers/readers? At least Polish language support works :) Which bits? (There are three different targets). Could you post a patch? Well, I can definitely set my document language to Polish, and it accepts polish characters, and encodes them correctly for latex's babel to understand. The polish localization seems to be outdated a bit, but it's present too IIRC. That's stock lyx 1.3.4, Qt frontent. IIRC that worked fine under xforms frontend as well for like 1.3.2 or so. So at least for Polish consider it working. Cheers, Kuba Ober
Re: Is 1.3.x's README up to date?
So to return to my original question, which bit of the following is incorrect? No bit is incorrect. Really. For a change :) Both passages seem to be correct. Why is it that people insist on assuming that things don't work (or are wrong), when in fact -- they are correct and do work :) Feel free to consider it as praise for lyx ;). $ cat README ... Menus and error messages have been translated to the following languages (* means there are language-specific keyboard menu bindings as well): ... Polish (pl) ... Keymaps can ease typing in one or more of the following languages: ... Polish ... I don't know about Polish keymaps, I just use whatever KDE's keyboard map utility provides for me, so I've never tested a Polish keymap -- assuming it's an X keymap you're talking about. Anyway, I've never had any need to change keymaps specifically in/for lyx, it just works out of the box. Maybe I'm too lucky :) Basically, if I do $ LANG=pl_PL lyx it starts up with polish menus, opens polish help files, etc. The only gotcha is that the default document language is still English, which may or may not make too much sense (said so in order to avoid a flame war :). Probably it could be made into a configuration option -- a simple checkbox Use user interface language as default document language. That's about all that I have to say on the subject, I admit. When things work, they... just work :) Cheers, Kuba Ober
Re: Is 1.3.x's README up to date?
On piÄtek 24 wrzesieÅ 2004 06:20 am, Angus Leeming wrote: > Specifically, the section: > > Does LyX have support for non-English speakers/writers/readers? At least Polish language support works :) Cheers, Kuba
Re: Is 1.3.x's README up to date?
On piÄtek 24 wrzesieÅ 2004 09:04 am, Angus Leeming wrote: > Kuba Ober wrote: > > On pi?tek 24 wrzesie? 2004 06:20 am, Angus Leeming wrote: > >> Specifically, the section: > >> > >> Does LyX have support for non-English speakers/writers/readers? > > > > At least Polish language support works :) > > Which bits? (There are three different targets). Could you post a patch? Well, I can definitely set my document language to Polish, and it accepts polish characters, and encodes them correctly for latex's babel to understand. The polish localization seems to be outdated a bit, but it's present too IIRC. That's stock lyx 1.3.4, Qt frontent. IIRC that worked fine under xforms frontend as well for like 1.3.2 or so. So at least for Polish consider it working. Cheers, Kuba Ober
Re: Is 1.3.x's README up to date?
> So to return to my original question, which bit of the following is > incorrect? No bit is incorrect. Really. For a change :) Both passages seem to be correct. Why is it that people insist on assuming that things don't work (or are wrong), when in fact -- they are correct and do work :) Feel free to consider it as praise for lyx ;). > $ cat README > ... > > Menus and error messages have been translated to the following > languages (* means there are language-specific keyboard menu > bindings as well): > > ... > Polish (pl) > ... > > Keymaps can ease typing in one or more of the following languages: > > ... > Polish > ... I don't know about Polish keymaps, I just use whatever KDE's keyboard map utility provides for me, so I've never tested a Polish keymap -- assuming it's an X keymap you're talking about. Anyway, I've never had any need to change keymaps specifically in/for lyx, it "just works" out of the box. Maybe I'm too lucky :) Basically, if I do $ LANG=pl_PL lyx it starts up with polish menus, opens polish help files, etc. The only gotcha is that the default document language is still English, which may or may not make too much sense (said so in order to avoid a flame war :). Probably it could be made into a configuration option -- a simple checkbox "Use user interface language as default document language". That's about all that I have to say on the subject, I admit. When things work, they... just work :) Cheers, Kuba Ober
Re: LyX compiles on Win32 with mingw gpl qt library
On czwartek 23 wrzesie 2004 05:17 am, Ruurd Reitsma wrote: Actually, someone already made an installer for Win32. Just havent had the time to do anything with it... I volunteer to make one with NSIS, if need be. Cheers, Kuba Ober
Re: LyX compiles on Win32 with mingw & gpl qt library
On czwartek 23 wrzesieÅ 2004 05:17 am, Ruurd Reitsma wrote: > Actually, someone already made an installer for Win32. Just havenÂt had the > time to do anything with it... I volunteer to make one with NSIS, if need be. Cheers, Kuba Ober
Re: Math font problems on Mac
It seems that OSX (or Qt/Mac) has problems to just use the fonts. I really do not know how to work around this. Bennett Well ... what works reliably for me is to place these fonts Bennett into one of the Mac font directories. That's interesting... [...] Not yet. Let's see if we can fix it correctly. It smells to me like some OSX problem, unless the application (in this case Qt/Mac) has to handle system-wide and application-bundle fonts somehow differently. Maybe it's something unusual about the fonts themselves that they expose a OSX bug that shows only in app-bunded fonts, for whatever buggy reason. Disclaimer: my experience with OSX is rather sparse at this point. Cheers, Kuba Ober
Re: Math font problems on Mac
> >> It seems that OSX (or Qt/Mac) has problems to just use the fonts. > >> > >> I really do not know how to work around this. > > Bennett> Well ... what works reliably for me is to place these fonts > Bennett> into one of the Mac font directories. > > That's interesting... [...] > Not yet. Let's see if we can fix it correctly. It smells to me like some OSX problem, unless the application (in this case Qt/Mac) has to handle system-wide and application-bundle fonts somehow differently. Maybe it's something unusual about the fonts themselves that they expose a OSX bug that shows only in app-bunded fonts, for whatever buggy reason. Disclaimer: my experience with OSX is rather sparse at this point. Cheers, Kuba Ober
Re: using tex2lyx and various added spaces
For example, the tex file has: $-$u user The tex file should have --, not $-$! But lyx shows it as: - u user And does so correctly, as math mode contents are surrounded by a small margin IIRC. Are you sure that there is really a space in lx and not just the usual margin of the math box? I don't know about math mode nor a math box. I never (knowingly) enabled it. $-$ is a minus operator in math mode. It's wrong to use it as a medium dash. Type -- instead. This tex file was created by running html2latex on the output from groff -Thtml. Then html2latex creates broken output, i.e. emits minus operators instead of medium dashes. Cheers, Kuba Ober
Re: using tex2lyx and various added spaces
> > > For example, the tex file has: > > > $-$u user The tex file should have "--", not "$-$"! > > > But lyx shows it as: > > > > > > - u user And does so correctly, as math mode contents are surrounded by a small margin IIRC. > > Are you sure that there is really a > > space in lx and not just the usual margin of the math box? > > I don't know about math mode nor a math box. I never (knowingly) enabled > it. $-$ is a minus operator in math mode. It's wrong to use it as a medium dash. Type -- instead. > This tex file was created by running html2latex on the output from "groff > -Thtml". Then html2latex creates broken output, i.e. emits minus operators instead of medium dashes. Cheers, Kuba Ober
Re: lyx file format ?
I came across Lyx, and I am very curios to know why the 'lyx' file format is not 'tex'. First of all, because LyX isn't meant to be bound to TeX in any special way. It's a general, high-level editor that supports some constructs that are not gracefully supported by the tex format, at least not natively or not in an obvious way. And LyX doesn't necessarily produce TeX output only. It also does docbook, for example. Secondly, because the TeX format is not a format but a programming language essentially and same document output can be obtained in many different ways. In order to do a generic TeX parser one would need to reimplement the core of TeX, essentially. In the unix world reimplementing existing tools that work fine is a big no-no ;) Generally speaking generating tex is easier than reading it back. Then one can argue that only some well-defined subset of 'tex' could be supported. That's what's already happening as far as equations are concerned: they are stored as raw tex/latex IIRC. I have looked over a 'lyx' file, and it seems to me closer to RTF than anything else. From my bystander point of view I guess the meandering path that led to current lyx format is that of: making the parser unmanageable, some poor soul untangling the parser, and then making the format easier to parse so that said sould wouldn't be so poor in the future, with such cycle repeated often over the years :) Cheers, Kuba Ober
Re: Asger :)
On poniedziaek 23 sierpie 2004 02:29 pm, Asger Kunuk Ottar Alstrup wrote: On Thu, 19 Aug 2004, Andre Poenitz wrote: PS: For some reason I sorely missed Asger this year. I have absolutely no clue why you would bring that up in such a discussion. Regards, Asger (who seems to try to make an impression that him and beer have nothing in common, and that being implied in anyone's blurred insights is essentially a slander :) Cheers, Kuba
Re: lyx file format ?
> I came across Lyx, and I am very curios to know why the 'lyx' file > format is not 'tex'. First of all, because LyX isn't meant to be bound to TeX in any special way. It's a general, high-level editor that supports some constructs that are not gracefully supported by the tex format, at least not natively or not in an obvious way. And LyX doesn't necessarily produce TeX output only. It also does docbook, for example. Secondly, because the TeX format is not a format but a programming language essentially and same document output can be obtained in many different ways. In order to do a generic TeX parser one would need to reimplement the core of TeX, essentially. In the unix world reimplementing existing tools that work fine is a big no-no ;) Generally speaking generating tex is easier than reading it back. Then one can argue that only some well-defined subset of 'tex' could be supported. That's what's already happening as far as equations are concerned: they are stored as raw tex/latex IIRC. > I have looked over a 'lyx' file, and it seems to > me closer to RTF than anything else. From my bystander point of view I guess the meandering path that led to current lyx format is that of: making the parser unmanageable, some poor soul untangling the parser, and then making the format easier to parse so that said sould wouldn't be so poor in the future, with such cycle repeated often over the years :) Cheers, Kuba Ober
Re: Asger :)
On poniedziaÅek 23 sierpieÅ 2004 02:29 pm, Asger Kunuk Ottar Alstrup wrote: > On Thu, 19 Aug 2004, Andre Poenitz wrote: > > PS: For some reason I sorely missed Asger this year. > > I have absolutely no clue why you would bring that up in such a > discussion. > > Regards, > Asger (who seems to try to make an impression that him and beer have nothing in common, and that being implied in anyone's blurred insights is essentially a slander :) Cheers, Kuba
Re: Compile times
| So am I right in assuming that the whole make machinery is responsible | for the additional 100s? Dependency tracking and suck can take some time I guess. Recursive make is partially to blame for that I would imagine as there's a lot of redundant work performed by each level of make. Cheers, Kuba Ober
Re: Compile times
> | So am I right in assuming that the whole make machinery is responsible > | for the additional 100s? > > Dependency tracking and suck can take some time I guess. Recursive make is partially to blame for that I would imagine as there's a lot of redundant work performed by each level of make. Cheers, Kuba Ober
Re: [experimental PATCH] try to get RPM dependency right for Qt
The current autogenerated lyx.spec for rpms suffers from an annoying bug: The dependency for Qt is hardcoded to 'qt = 2.3.0'. However, the package is named 'qt' only on redhat/fedora. On SUSE it is 'qt3' and on mandrake it is 'libqt3'. This proves to be an annoyance for our user-contributed rpms (mandrake users forced to use --force) and this patch tries to address this. The approach I took is to run 'rpm -qf' on $QTDIR, which seems to work well on my redhat9 machine. That makes sense. It will not work if one is using a self-compiled, non-packaged Qt, but that's not an issue here as we're looking for a package. It should work fine on any redhat version and sure does on both fedoras. As a fallback (if rpm -qf returns an error) I'd also do rpm -qa | grep ^[^-]*qt[^-]*-[0-9] Cheers, Kuba Ober
Re: Getting Lyx working
On poniedziaek 09 sierpie 2004 09:54 am, Angus Leeming wrote: I've just received this response from a user trying to extract the rpm for RH9. Is the rpm corrupt? Doesn't seem so. As an aside, why don't we also post .md5sum files containing the Because rpm does the hash checking already. It will complain if the package is corrupt. Tried that but it didn't work typed (as root) rpm -ivh lyx-1.3.4-1rh9_qt.i386.rpm which yielded Preparing... ### [100%] 1:lyx ### [100%] error: unpacking of archive failed on file /usr/bin/lyx;41178d7e: cpio: open failed - Permission denied Probably there's something else wrong. Cheers, Kuba Ober
Re: [experimental PATCH] try to get RPM dependency right for Qt
> The current autogenerated lyx.spec for rpms suffers from an annoying > bug: The dependency for Qt is hardcoded to 'qt >= 2.3.0'. However, the > package is named 'qt' only on redhat/fedora. On SUSE it is 'qt3' and > on mandrake it is 'libqt3'. This proves to be an annoyance for our > user-contributed rpms (mandrake users forced to use --force) and this > patch tries to address this. > > The approach I took is to run 'rpm -qf' on $QTDIR, which seems to work > well on my redhat9 machine. That makes sense. It will not work if one is using a self-compiled, non-packaged Qt, but that's not an issue here as we're looking for a package. It should work fine on any redhat version and sure does on both fedoras. As a fallback (if rpm -qf returns an error) I'd also do rpm -qa | grep "^[^-]*qt[^-]*-[0-9]" Cheers, Kuba Ober
Re: Getting Lyx working
On poniedziaÅek 09 sierpieÅ 2004 09:54 am, Angus Leeming wrote: > I've just received this response from a user trying to extract the rpm > for RH9. Is the rpm corrupt? Doesn't seem so. > As an aside, why don't we also post .md5sum files containing the Because rpm does the hash checking already. It will complain if the package is corrupt. > Tried that but it didn't work > > typed (as root) > > rpm -ivh lyx-1.3.4-1rh9_qt.i386.rpm > > which yielded > > Preparing... > ### [100%] >1:lyx > ### [100%] > error: unpacking of archive failed on file /usr/bin/lyx;41178d7e: > cpio: open > failed - Permission denied Probably there's something else wrong. Cheers, Kuba Ober
Re: Meeting 2004 - Chemnitz again, August 12-16
On poniedziaek 05 lipiec 2004 07:27 am, Andre Poenitz wrote: On Mon, Jul 05, 2004 at 12:09:10PM +0100, Jose' Matos wrote: On Monday 05 July 2004 11:00, Jean-Marc Lasgouttes wrote: I will probably be able to bring one if really needed, but I have no idea about german electric outlets... I will bring mine too. If you remember from last year the problem is not the german outlets as I think that they are the same in all the continental Europe... more or less... More or less... two holes in the wall and you'll get a bad experience once you plug your fingers in... :) Well, the German system is IIRC called Shuco, from the name of the company that probably sold the system outlets and plugs first. It has two standard prongs in the plug for the live/neutral, but grounding is handled by two rails on the opposite sides of the plug. IIRC you'll find the same thing in Austria. In France, Poland, Russia and probably other Slavic countries, there are no grounding rails but there's a hole in the plug for a grounding prong that sticks out from the outlet. Shuco and the French system are handled by a universal European plug that you'll find everywhere in western Europe save for Switzerland and maybe Italy. In Switzerland the grounding is achieved by a third prong in the plug, and the plug itself is flat instead of round. I don't remember how it's in Italy, but I fear they might have something special too for grounding. The Brits have their own 3-prong plug which is double the size of standard European one and is a nifty thing if you want to use it to hook up an arc welder. OTOH, if you happen to carry around a laptop instead of an arc welder, the plug might be bigger than the laptop in question. In any event, it's a good idea to get a laptop with a doubly-insulated power supply for which you only need two prongs in a flat plug. Those will work in any European country save for the countries located on British Isles where eveyone seems to expect everyone else to be proficient mainly in arc welding ;) Cheers, Kuba
Re: OT Re: Meeting 2004 - Chemnitz again, August 12-16
On czwartek 08 lipiec 2004 01:35 pm, Georg Baum wrote: Am Donnerstag, 8. Juli 2004 16:44 schrieb Kuba Ober: Well, the German system is IIRC called Shuco, from the name of the company that probably sold the system outlets and plugs first. It has two Sorry, but I can't resist to nitpick here: Schuko is the short from of Schutzkontaksteckdose and was introduced to distinguish the outlets with ground contact from the old ones that just had the two holes. Good call. Thanks for the clarification. But isn't there a company called Shuco as well (maybe just a coincidence)? In any event, my recollection is mostly based on folklore than research :) Caveat emptor Cheers, Kuba
Re: Meeting 2004 - Chemnitz again, August 12-16
On poniedziaÅek 05 lipiec 2004 07:27 am, Andre Poenitz wrote: > On Mon, Jul 05, 2004 at 12:09:10PM +0100, Jose' Matos wrote: > > On Monday 05 July 2004 11:00, Jean-Marc Lasgouttes wrote: > > > I will probably be able to bring one if really needed, but I have no > > > idea about german electric outlets... > > > > I will bring mine too. If you remember from last year the problem is > > not the german outlets as I think that they are the same in all the > > continental Europe... more or less... > > More or less... two holes in the wall and you'll get a bad experience > once you plug your fingers in... :) Well, the German system is IIRC called Shuco, from the name of the company that probably sold the "system" outlets and plugs first. It has two "standard" prongs in the plug for the live/neutral, but grounding is handled by two rails on the opposite sides of the plug. IIRC you'll find the same thing in Austria. In France, Poland, Russia and probably other Slavic countries, there are no grounding rails but there's a hole in the plug for a grounding prong that sticks out from the outlet. Shuco and the "French" system are handled by a "universal" European plug that you'll find everywhere in western Europe save for Switzerland and maybe Italy. In Switzerland the grounding is achieved by a third prong in the plug, and the plug itself is flat instead of round. I don't remember how it's in Italy, but I fear they might have something special too for grounding. The Brits have their own 3-prong plug which is double the size of "standard" European one and is a nifty thing if you want to use it to hook up an arc welder. OTOH, if you happen to carry around a laptop instead of an arc welder, the plug might be bigger than the laptop in question. In any event, it's a good idea to get a laptop with a doubly-insulated power supply for which you only need two prongs in a flat plug. Those will work in any European country save for the countries located on British Isles where eveyone seems to expect everyone else to be proficient mainly in arc welding ;) Cheers, Kuba
Re: OT Re: Meeting 2004 - Chemnitz again, August 12-16
On czwartek 08 lipiec 2004 01:35 pm, Georg Baum wrote: > Am Donnerstag, 8. Juli 2004 16:44 schrieb Kuba Ober: > > Well, the German system is IIRC called Shuco, from the name of the > > company that probably sold the "system" outlets and plugs first. It has > > two > > Sorry, but I can't resist to nitpick here: "Schuko" is the short from of > "Schutzkontaksteckdose" and was introduced to distinguish the outlets with > ground contact from the old ones that just had the two holes. Good call. Thanks for the clarification. But isn't there a company called Shuco as well (maybe just a coincidence)? In any event, my recollection is mostly based on folklore than research :) Caveat emptor Cheers, Kuba
Re: Maybe use distcc for faster compilations?
On poniedziaek 05 lipiec 2004 07:32 pm, Christian Ridderstrm wrote: Hi I came across this article: http://www-106.ibm.com/developerworks/linux/library/l-distcc.html?ca=dgr-l nxw01distccTips that discusses using somethign called 'distcc' to speed up compilations. Basically you run a small daemon on several machines and then use 'distcc' instead of 'gcc', which will distribute the compilation tasks to the different machines. I haven't tried it, but if you have access to several machines it ought to reduce compilation times substantially. It works fine, although recursive make decreases its potential (it's bad anyway, see http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html). I'm using it since about 2-2.5 years. Together with ccache it can really make things fly. If you want a premade package for fedora/redhat see http://www.ibib.waw.pl/~winnie Cheers, Kuba
Re: Maybe use distcc for faster compilations?
On poniedziaÅek 05 lipiec 2004 07:32 pm, Christian RidderstrÃm wrote: > Hi > > I came across this article: > > http://www-106.ibm.com/developerworks/linux/library/l-distcc.html?ca=dgr-l >nxw01distccTips > > that discusses using somethign called 'distcc' to speed up compilations. > > Basically you run a small daemon on several machines and then use 'distcc' > instead of 'gcc', which will distribute the compilation tasks to the > different machines. > > I haven't tried it, but if you have access to several machines it ought to > reduce compilation times substantially. It works fine, although recursive make decreases its potential (it's bad anyway, see http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html). I'm using it since about 2-2.5 years. Together with ccache it can really make things fly. If you want a premade package for fedora/redhat see http://www.ibib.waw.pl/~winnie Cheers, Kuba
Re: Problem with 1.3.0 / 1.3.4
On roda 30 czerwiec 2004 02:49 pm, Dieter Jurzitza wrote: As I readily mentioned, nothing wrong is occuring with normal typing. But if I try to view one of the docs - crash. This happens for my selfcompiled version (1.3.4) in the same way as for the precompiled (1.3.0) (= linked to the wrong QT version) I took from the lyx-Webside) Any suggestions / ideas to track down what is happening are greatly appreciated. Unfortunately not even gdb - work is possible - as I already said, the system freezes totally (not even ping to the machine is working any more) Many thanks for your efforts and you support in advance, take care I doubt this has much to do with lyx. If you're experiencing hard freeze like that, your kernel has died in one way or another. This might be for various reasons, I'd try first to switch your xserver into vesa mode and try if it helps. Maybe change network cards if you run off nfs. I'm afraid there's nothing that we can do to help you. If you're not running as root no such crashes should ever occur on a properly configured system, i.e. an application, no matter how buggy, should not freeze the whole system. Your hardware may be failing -- run some memtest86 and mersenne.org stress tests. If any errors are reported in 48 hours of continuoues applicaiton of either of those, fix the problem first. Cheers, Kuba
Re: Problem with 1.3.0 / 1.3.4
On Åroda 30 czerwiec 2004 02:49 pm, Dieter Jurzitza wrote: > As I readily mentioned, nothing wrong is occuring with "normal" typing. But > if I try to view one of the docs -> crash. > This happens for my selfcompiled version (1.3.4) in the same way as for the > precompiled (1.3.0) (= linked to the wrong QT version) I took from the > lyx-Webside) > > Any suggestions / ideas to track down what is happening are greatly > appreciated. Unfortunately not even gdb - work is possible - as I already > said, the system freezes totally (not even ping to the machine is working > any more) > Many thanks for your efforts and you support in advance, > take care I doubt this has much to do with lyx. If you're experiencing "hard" freeze like that, your kernel has died in one way or another. This might be for various reasons, I'd try first to switch your xserver into vesa mode and try if it helps. Maybe change network cards if you run off nfs. I'm afraid there's nothing that we can do to help you. If you're not running as root no such crashes should ever occur on a properly configured system, i.e. an application, no matter how buggy, should not freeze the whole system. Your hardware may be failing -- run some memtest86 and mersenne.org stress tests. If any errors are reported in 48 hours of continuoues applicaiton of either of those, fix the problem first. Cheers, Kuba
An idea to have lyx-wiki of sorts
Hi, An idea came to my mind so I feel compelled to share :) Wouldn't it be nifty to hack the wiki enough to allow it to work on lyx files? That way we could have wiki-ed lyx user's manual -- I don't think there are any projects out there that allow online updating of the manuals. Since lyx has quite a few users, and sometimes when referring to the manual the users come up with small but useful changes, the simplest way (from a user's standpoint) would be to have it in a wiki. It already does all the change and history tracking for us, essentially it would need to be taught some of lyx's ideas about paragraph environments and would need to get a TeX previewer which (hopefully) is already available for wiki elsewhere. In order not to hack the wiki too much, most of existing markup could be preserved and lyx-specific things added, necessitating some (hopefully non-perl :) wizardry to convert back and forth. I'm thinking of initially supporting only whatever the manual needs, i.e. not making it general so that it would work with arbitrary document classes. That could be added later if there's demand. Side note: I'm *not* volunteering to implement it (not now, at least), unless somebody has some marketable and transferable free time, and cheap at that, so that I could buy it. Deeds to free time, anyone? ;) Cheers, Kuba
An idea to have lyx-wiki of sorts
Hi, An idea came to my mind so I feel compelled to share :) Wouldn't it be nifty to hack the wiki enough to allow it to work on lyx files? That way we could have wiki-ed lyx user's manual -- I don't think there are any projects out there that allow online updating of the manuals. Since lyx has quite a few users, and sometimes when referring to the manual the users come up with small but useful changes, the simplest way (from a user's standpoint) would be to have it in a wiki. It already does all the change and history tracking for us, essentially it would need to be taught some of lyx's ideas about paragraph environments and would need to get a TeX previewer which (hopefully) is already available for wiki elsewhere. In order not to hack the wiki too much, most of existing markup could be preserved and lyx-specific things added, necessitating some (hopefully non-perl :) wizardry to convert back and forth. I'm thinking of initially supporting only whatever the manual needs, i.e. not making it general so that it would work with arbitrary document classes. That could be added later if there's demand. Side note: I'm *not* volunteering to implement it (not now, at least), unless somebody has some marketable and transferable free time, and cheap at that, so that I could buy it. Deeds to free time, anyone? ;) Cheers, Kuba
Re: LyX WikiWiki recent wiki posts (Wiki trashed)
On Friday 07 May 2004 09:46 am, John Levon wrote: On Fri, May 07, 2004 at 03:02:26PM +0200, Apache wrote: Recent wiki posts: (http://wiki.lyx.org/pmwiki.php/Main/AllRecentChanges) * http://wiki.lyx.org/pmwiki.php/LyX/Welcome - 14:07 7/05 by * http://wiki.lyx.org/pmwiki.php/LyX/LyX - 14:08 7/05 by * http://wiki.lyx.org/pmwiki.php/PmWiki/DocumentationIndex - 14:08 7/05 by * http://wiki.lyx.org/pmwiki.php/FAQ/Qt - 14:10 7/05 by Some kid thought it would be amusing to trash the Wiki. In process of restoring. Kuba
Re: LyX WikiWiki recent wiki posts (Wiki trashed)
Should be restored, unless this or another kid resumes his/her activity. Cheers, Kuba
Re: LyX WikiWiki recent wiki posts (Wiki trashed)
On Friday 07 May 2004 09:46 am, John Levon wrote: > On Fri, May 07, 2004 at 03:02:26PM +0200, Apache wrote: > > Recent wiki posts: > > (http://wiki.lyx.org/pmwiki.php/Main/AllRecentChanges) > > > > * http://wiki.lyx.org/pmwiki.php/LyX/Welcome - 14:07 7/05 by > > * http://wiki.lyx.org/pmwiki.php/LyX/LyX - 14:08 7/05 by > > * http://wiki.lyx.org/pmwiki.php/PmWiki/DocumentationIndex - 14:08 7/05 > > by * http://wiki.lyx.org/pmwiki.php/FAQ/Qt - 14:10 7/05 by > > Some kid thought it would be amusing to trash the Wiki. In process of restoring. Kuba
Re: LyX WikiWiki recent wiki posts (Wiki trashed)
Should be restored, unless this or another kid resumes his/her activity. Cheers, Kuba
Re: (just in case) How to reach me for chatting about the conference
On Wednesday 28 April 2004 06:00 pm, Lars Gullik Bjønnes wrote: Kuba Ober [EMAIL PROTECTED] writes: | My kadu user id is 3323343, you can download the client below | | http://kadu.net/index.php?page=downloadlang=en Kadu what the F*** is kadu? Like AIM, and has a nice english translation. It's very easy to use, actually. Works under KDE. I just don't like AIM and I'd better not use IRC as it's heavily addictive (BTDT and had to suffer from withdrawal syndrome). Cheers, Kuba
Re: This year's meeting
On Wednesday 28 April 2004 02:07 am, Asger Kunuk Ottar Alstrup wrote: I probably have to miss this year's meeting, now that Elias is in the picture. He will be older next year, and I've never been to Poland, so that sounds more realistic for me. There are direct flights from Copenhagen to Poznan, BTW :) Congrats, BTW, my daugter will be born (hopefully!) in July this year so that's why this year would neither work for me :) Cheers, Kuba
Re: (just in case) How to reach me for chatting about the conference
On Wednesday 28 April 2004 06:00 pm, Lars Gullik Bjønnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > | My kadu user id is 3323343, you can download the client below > | > | http://kadu.net/index.php?page=download=en > > Kadu what the F*** is kadu? Like AIM, and has a nice english translation. It's very easy to use, actually. Works under KDE. I just don't like AIM and I'd better not use IRC as it's heavily addictive (BTDT and had to suffer from withdrawal syndrome). Cheers, Kuba
Re: This year's meeting
On Wednesday 28 April 2004 02:07 am, Asger Kunuk Ottar Alstrup wrote: > I probably have to miss this year's meeting, now that Elias is in the > picture. He will be older next year, and I've never been to Poland, so > that sounds more realistic for me. There are direct flights from Copenhagen to Poznan, BTW :) Congrats, BTW, my daugter will be born (hopefully!) in July this year so that's why this year would neither work for me :) Cheers, Kuba
Re: LyX Developer Conference 2005 -- maybe in Poland?? (some input needed)
On Tuesday 27 April 2004 12:45 pm, Alfredo Braunstein wrote: Kuba Ober wrote: This is all highly unofficial and can be considered hearsay: It'd be doable in Pozna, Poland. What'd ya think? Cheers, Kuba Ober Cheers indeed! Super methinks. Okay, now the old and tiring bureaucracy: I need to make a nice letter to the head of the institute, describing what the conference is about and so on. Yada yada that it's opensource and so on. If those who have attended the previous conferences could give some input about what's the usual schedule, what's the presentation to hacking ratio to be expected, and the foreseeable number of participants, it'd be great. If you have any such letters to the top written for previous meetings, I'd appreciate them too! I have no clue how affordable the accommodations could be. The research unit itself has a guest room which accommodates one person, maybe two if a second bed could be arranged and one doesn't mind sharing the room. Use of that room could essentially be donated by the research unit. Other than that one has to depend on hotels. There are tons of hotels in Pozna, but methinks that they are not very affordable -- i.e. not like youth hostels. There are a couple youth hostels apparently, I'd need to actually have somebody pay them a visit to see if they are reasonable enough. So I will need to check on that, and heck - the rates *could* change in a year :) The conference room a.k.a. the library in the research unit can accommodate about 11 people + the speaker. Although they don't have the LCD projector, one could be rented from somewhere I'm sure. The library has one network drop, if more is needed one needs a hub/switch on the table :) As far as foreseeable hacking goes, there are non-mutually-exclusive options. The private option: There are 3 nice networked workrooms that easily accommodate 2 people. Each room has a PC running latest Fedora Core release. There are 4 PCs total, all of them reasonable enough (i.e. a 366+ Celeron, a 2x466 SMP PIII, an 600 PIII, a 2G PIV methinks). distcc is preinstalled :) A managed HP switch links all the 100mbit network drops. Each of the 3 rooms has 2 network drops. The communal option: The library/meeting room can be used if one wishes to bring PCs down there, it'd also be good for notebooks. I can bring a hub and two notebooks with me, the research unit has one more notebook, so that wouldn't be a terrible problem either. If one envisions more than say 12 people for hacking session (assuming pair hacking, i.e. 2 persons per machine), one would need to get PCs from somewhere. If any of you has a laptop, just bring it and make sure you have Ethernet connectivity. I know that all of that is still up in the air but I want to share what amenities we can provide w/o any special effort. If there are significantly more people for hacking session (say 15+), we may be better off with somehow getting a hold of someone else's facilities, like the university etc. That would need to be arranged *way* in advance, so let's keep that in mind as well. I don't particularly think that we can get businesses as sponsors here in Poland. Well, frankly said I'm 100% clueless here -- never had to look for such conference sponsorship. So, apart from the meeting place and a small guest room being possibly donated for the meeting by the research unit, everything else is pay as you go. Well, I'm volunteering to be the host, system admin and entertainter (if people find me entertaining that is) :) Cheers, Kuba Ober
(just in case) How to reach me for chatting about the conference
My kadu user id is 3323343, you can download the client below http://kadu.net/index.php?page=downloadlang=en (No, I'm not using AIM or anything of the sort) Cheers, Kuba Ober
Re: LyX Developer Conference 2005 -- maybe in Poland?? (some input needed)
Okay, now the old and tiring bureaucracy: I need to make a nice letter to the head of the institute, describing what the conference is about and so on. Yada yada that it's opensource and so on. If those who have attended the previous conferences could give some input about what's the usual schedule, what's the presentation to hacking ratio to be expected, and the foreseeable number of participants, it'd be great. If you have any such letters to the top written for previous meetings, I'd appreciate them too! Well, Lars is boss. However, I'd suggest to convince Angus to come up with a very detailed draft and let Lars sign it. I'd expect a much longer and ... 'flowery' (is there such a word in English?) letter this way ;-) It's even more bureaucratic than that. While it would be nice (didn't expect that) for the lead LyX developer to write something, there needs to be a letter from the head of the Research Unit where the meeting tentatively would be to the head of the Institute. I'm to write that letter :) Lars's letter as an attachment would be nice. Maybe then the letter from one head to another :) will just be a cover letter. Less work for me :) I have no clue how affordable the accommodations could be. The research unit itself has a guest room which accommodates one person, maybe two if a second bed could be arranged and one doesn't mind sharing the room. Use of that room could essentially be donated by the research unit. Other than that one has to depend on hotels. There are tons of hotels in Pozna??, but methinks that they are not very affordable -- i.e. not like youth hostels. There are a couple youth hostels apparently, I'd need to actually have somebody pay them a visit to see if they are reasonable enough. So I will need to check on that, and heck - the rates *could* change in a year :) Well, LyX meeting accomodation is usually sleeping in some corner of somebody's flat or bathroom or somebody's friend's flat or boat with a decent luxury bonus for couples (IIRC I've always got a real bed ;-)) Well, the guest room needs to be assigned to *somebody* I guess ;) able to spend a few more on accomodation. Five star hotels would probably a bit above the limit, but I would be surprised if there wasn't BedBreakfast-style accomodation for less than 20 EUR per night in Poland. I'll have one of my friends (I guess) research that for me. I haven't really had to find a place to sleep in Poznan yet (after moving into my wife's room :). LCD projector, one could be rented from somewhere I'm sure. The library has one network drop, if more is needed one needs a hub/switch on the table :) Switch is no problem. Projector is not needed. 11 people - does this mean just sitting or closer to work places, i.e. with tables to put a computer on? It's actually a set of 2 very nice tables that could be used for working and eating!! It's a rather informal room used for meetings, cookies and to hold books on the shelves. Thus the library thing :) There are 3 nice networked workrooms that easily accommodate 2 people. Each room has a PC running latest Fedora Core release. There are 4 PCs total, all of them reasonable enough (i.e. a 366+ Celeron, a 2x466 SMP PIII, an 600 PIII, a 2G PIV methinks). distcc is preinstalled :) A managed HP switch links all the 100mbit network drops. Each of the 3 rooms has 2 network drops. That's 6 real workplaces, which is about what we had in Chemnitz last year - i.e. sufficient. Perfect, then. Sounds good as well. Note, however, that people are used to eat and drink (quite a bit...) when hacking. Most libraries don't appreciate this habit ;-} This one is different :) There's the obviously no smoking thing in the whole building, but you're free to smoke outside. There's even a kitchen with a fridge to store beer, ekhm, soft drinks ;) It all sounds very well so far. I don't think there ever was a meeting with more than 12 people, so what you have is already fine without special effort. Perfect perfect :) Well, frankly said I'm 100% clueless here -- never had to look for such conference sponsorship. So, apart from the meeting place and a small guest room being possibly donated for the meeting by the research unit, everything else is pay as you go. This is Lars's playground. But I was under the impression that the project treasure would survive another meeting... :) Well, I'm volunteering to be the host, system admin and entertainter (if people find me entertaining that is) :) One can always try. Seriously, I don't think there was ever such a detailed plan for a LyX meeting one year in advance. I'm not a big planning freak either, I just wanted to provide an overview of what's available and to make sure that would be sufficient. Didn't want to have say 20 people come into that small meeting room :) Cheers, Kuba
Fwd: [LONG] LyX Developer Conference 2005 -- insane ramblings ;)
and everything ;) I'm thinking, to make it a social event as well as a LyXing event, that duration of 6 days would be something to aim for to make it a productive effort. If it's unreasonable I'm all ears -- as I've hopefully mentioned that'd be the first conference I'm organizing 100% myself. I did organize a small conference at the Institute, but my involvement was mostly with the website development so that people could sign themselves in and schedule their presentations etc (instead of me doing it for them :). As far as participant costs go, apart from the transportation in and out of Poznan methinks that things can be done quite affordably as far as accommodations are concerned. I would hate to bring made-up figures, but a very tentative cost breakdown with conservative figures would look like that: - transportation - using coaches and within western/central Europe you should be able to get to and from Poznan for about 250 euro (including snacks at the stops :) - room for 5 nights - about 300 euro for a very cheap hotel if one could find one (i.e. it might likely be more -- I'd have to find something first and negotiate a rate), a hostel will be less, and for the 2 people who'd fit into the guestroom that's effectively zero, - some conference fee to cover snacks - about 20 euro or less (unless we get a sponsor for that) - public transportation in Poznan - about 8-10 euro for a weekly pass that works on trams and buses, i.e. all you'll ever need :) - food - about 75 euro, that's 15 euro per day to satiate oneself unless one wants to get fancy :) - beer - about 30 euro (local stuff, Guiness other imports would be obviously more) :) - social events - from zero to a hero (no idea) Cheers, Kuba Ober
Fwd: (just in case) How to reach me for chatting about the conference
My kadu user id is 3323343, you can download the client below http://kadu.net/index.php?page=downloadlang=en (No, I'm not using AIM or anything of the sort) Cheers, Kuba Ober
Re: LyX Developer Conference 2005 -- maybe in Poland?? (some input needed)
On Tuesday 27 April 2004 12:45 pm, Alfredo Braunstein wrote: > Kuba Ober wrote: > > This is all highly unofficial and can be considered hearsay: > > > > It'd be doable in PoznaÅ, Poland. What'd ya think? > > > > Cheers, Kuba Ober > > Cheers indeed! > > Super methinks. Okay, now the old and tiring bureaucracy: I need to make a nice letter to the head of the institute, describing what the conference is about and so on. Yada yada that it's opensource and so on. If those who have attended the previous conferences could give some input about what's the usual schedule, what's the presentation to hacking ratio to be expected, and the foreseeable number of participants, it'd be great. If you have any such "letters to the top" written for previous meetings, I'd appreciate them too! I have no clue how affordable the accommodations could be. The research unit itself has a guest room which accommodates one person, maybe two if a second bed could be arranged and one doesn't mind sharing the room. Use of that room could essentially be donated by the research unit. Other than that one has to depend on hotels. There are tons of hotels in PoznaÅ, but methinks that they are not very affordable -- i.e. not like youth hostels. There are a couple youth hostels apparently, I'd need to actually have somebody pay them a visit to see if they are reasonable enough. So I will need to check on that, and heck - the rates *could* change in a year :) The "conference room" a.k.a. the library in the research unit can accommodate about 11 people + the speaker. Although they don't have the LCD projector, one could be rented from somewhere I'm sure. The library has one network drop, if more is needed one needs a hub/switch on the table :) As far as foreseeable hacking goes, there are non-mutually-exclusive options. The private option: There are 3 nice networked workrooms that easily accommodate 2 people. Each room has a PC running latest Fedora Core release. There are 4 PCs total, all of them "reasonable enough" (i.e. a 366+ Celeron, a 2x466 SMP PIII, an 600 PIII, a 2G PIV methinks). distcc is preinstalled :) A managed HP switch links all the 100mbit network drops. Each of the 3 rooms has 2 network drops. The communal option: The library/meeting room can be used if one wishes to bring PCs down there, it'd also be good for notebooks. I can bring a hub and two notebooks with me, the research unit has one more notebook, so that wouldn't be a terrible problem either. If one envisions more than say 12 people for hacking session (assuming pair hacking, i.e. 2 persons per machine), one would need to get PCs from somewhere. If any of you has a laptop, just bring it and make sure you have Ethernet connectivity. I know that all of that is still "up in the air" but I want to share what amenities we can provide w/o any special effort. If there are significantly more people for hacking session (say 15+), we may be better off with somehow getting a hold of someone else's facilities, like the university etc. That would need to be arranged *way* in advance, so let's keep that in mind as well. I don't particularly think that we can get businesses as sponsors here in Poland. Well, frankly said I'm 100% clueless here -- never had to look for such conference sponsorship. So, apart from the meeting place and a small guest room being possibly donated for the meeting by the research unit, everything else is pay as you go. Well, I'm volunteering to be the host, system admin and entertainter (if people find me entertaining that is) :) Cheers, Kuba Ober
