From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-04-26 14:16:18
|
OK, and Takeshi flagged another error of mine in this change. Perhapse the two are related? Unfortunately I don't have the original patch at my fingertips so I can't do the comparison right away. John F. Fay 850-729-6330 joh...@eg... -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Sunday, April 24, 2005 4:50 PM To: fre...@li... Subject: Re: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) John F.Fay wrote: > CVSROOT: /cvsroot/freeglut > Module name: freeglut > Repository: freeglut/freeglut/src/ > Changes by: fa...@sc....(none) 05/04/22 13:29:55 > > Log message: > Yuri D\'Elia\'s changes to the game mode window > > Modified files: > freeglut/freeglut/src/: > freeglut_gamemode.c > > Revision Changes Path > 1.29 +12 -12 freeglut/freeglut/src/freeglut_gamemode.c Hmmm, I'm not sure what the effect of this change should actually be, but game mode is still not working (x86 Linux SuSE 9.2, KDE 3.3.2): The resolution changes, but there are still window decorations visible and the virtual screen is slightly bigger than the physical screen (probably by the amount of the decorations), so one can scroll over the virtual screen when the mouse hits the physical screen's borders. In a nutshell: To me the behavious hasn't improved. :-( I tried to get fullscreen/game mode working a few months ago, but was frustrated by the differing behaviours of all the window managers... :-( Doing this portably still seems to be a black art with X11. Cheers, S. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-11 14:27:33
|
Gentlemen, In hot pursuit of another bug, I find this change from four months ago in which a simple call to "vfprintf" was changed into a macro "VFPRINTF" and a check added to "autoconf" for the existence of "vfprintf". Unfortunately, this has broken the Windows side which has "vfprintf" but does not define "HAVE_VFPRINTF". I propose to add something that will define "VFPRINTF" as "vfprintf" for Windows and let the rest be strictly non-Windows. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Monday, January 03, 2005 6:03 AM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/src/ Changes by: sp...@sc....(none) 05/01/03 04:02:43 Log message: autoconf'd vfprintf Modified files: freeglut/freeglut/: configure.ac freeglut/freeglut/src/: freeglut_internal.h freeglut_main.c Revision Changes Path 1.7 +1 -0 freeglut/freeglut/configure.ac 1.60 +0 -1 freeglut/freeglut/src/freeglut_internal.h 1.118 +11 -3 freeglut/freeglut/src/freeglut_main.c ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Sven P. <Sve...@ae...> - 2005-05-12 07:41:33
|
Fay John F Contr AAC/WMG wrote: > In hot pursuit of another bug, I find this change from four > months ago in which a simple call to "vfprintf" was changed into a macro > "VFPRINTF" and a check added to "autoconf" for the existence of > "vfprintf". Unfortunately, this has broken the Windows side which has > "vfprintf" but does not define "HAVE_VFPRINTF". I propose to add > something that will define "VFPRINTF" as "vfprintf" for Windows and let > the rest be strictly non-Windows. I am not sure how freeglut is supposed to be built on WinDoze. If it is via the usual automake/autoconf/libtool route (i.e. "configure && make install"), then this might be a buglet in the configure magic. To fix that, I would need a log of the configuration phase plus the generated config.h and config.log. If it is built differently, then it is probably an omission in a VS project file or something like that. I can't fix the latter, because I only test on Linux currently. Cheers, S. |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-12 13:12:06
|
Gentlemen, I have just put Takeshi Nishimura's menu fixes into CVS (thank you, Takeshi for the fixes, and thank you, JC Jones, for the pCVSc upgrades). I'm not doing very well this morning and I solicit your collective help in making sure that I have put the fixes in properly. Please take a little time to get the latest CVS version and check out the menus (and other things!) before JC cuts Release Candidate 2 tomorrow. If there are any game mode fixes, now would be a good time to get them in. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of John F.Fay Sent: Thursday, May 12, 2005 8:01 AM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/src/ Changes by: fa...@sc....(none) 05/05/12 06:00:50 Log message: Takeshi Nishimura\'s menu changes--menus should now work properly. Use the GLUT \"GLUTmech\" and \"walker\" demos to test them. Modified files: freeglut/freeglut/src/: freeglut_internal.h freeglut_main.c freeglut_menu.c Revision Changes Path 1.69 +3 -0 freeglut/freeglut/src/freeglut_internal.h 1.128 +22 -6 freeglut/freeglut/src/freeglut_main.c 1.41 +71 -44 freeglut/freeglut/src/freeglut_menu.c ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Takeshi N. <tak...@us...> - 2005-05-13 10:10:40
|
John, > I have just put Takeshi Nishimura's menu fixes into CVS (thank you, > Takeshi for the fixes, and thank you, JC Jones, for the pCVSc upgrades). > I'm not doing very well this morning and I solicit your collective help in > making sure that I have put the fixes in properly. Please take a little > time to get the latest CVS version and check out the menus (and other > things!) before JC cuts Release Candidate 2 tomorrow. I cannot compile current CVS on Linux because of a compile option -Werror ("Treat warnings as errors") and unused variables. -- Takeshi Nishimura Index: src/freeglut_menu.c =================================================================== RCS file: /cvsroot/freeglut/freeglut/freeglut/src/freeglut_menu.c,v retrieving revision 1.41 diff -5 -c -p -r1.41 freeglut_menu.c *** src/freeglut_menu.c 12 May 2005 13:00:49 -0000 1.41 --- src/freeglut_menu.c 13 May 2005 09:46:48 -0000 *************** static SFG_MenuEntry *fghFindMenuEntry( *** 108,118 **** /* * Deactivates a menu pointed by the function argument. */ static void fghDeactivateSubMenu( SFG_MenuEntry *menuEntry ) { - SFG_Window *current_window = fgStructure.CurrentWindow; SFG_MenuEntry *subMenuIter; /* Hide the present menu's window */ fgSetWindow( menuEntry->SubMenu->Window ); glutHideWindow( ); --- 108,117 ---- *************** GLboolean fgCheckActiveMenu ( SFG_Window *** 673,683 **** /* * Deactivates a menu pointed by the function argument. */ void fgDeactivateMenu( SFG_Window *window ) { - SFG_Window *current_window = fgStructure.CurrentWindow; SFG_Window *parent_window = NULL; /* Check if there is an active menu attached to this window... */ SFG_Menu* menu = window->ActiveMenu; SFG_MenuEntry *menuEntry; --- 672,681 ---- |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-23 12:52:15
|
Sven, This is an excellent idea and a positive change, but unless the Windows GCC problem was preventing a release I don't think it is the right thing to do right now. Now we must either remove the change or issue another release candidate so people can test it. At the moment I am trying to get something out the door that is better than "freeglut" 2.2.0. Unless the Windows GCC problem was quite severe or somebody has found another show-stopping bug that I haven't heard about, I would ask you please to back out the changes until we have released 2.4.0. At that point by all means put them in. To let you know a couple of other things that are going on, over the weekend I modified the "demos" workspace under Windows to make two copies of each demo program, one using the DLL and the other using the static library. At the moment all the demos use the static library. I also added text to the "README.Win32" describing how to use "freeglut" if you couldn't or didn't want to install it. But these changes, positive as they are, are not going to be in 2.4.0. I also found that in the CallbackMaker demo, the joystick info is not updated in the windows until the user moves the mouse or presses a key. The shapes demo terminates if the user specifies fewer than zero levels in the Sierpinski sponge. The fixes for these problems are also not going to be in 2.4.0. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Sunday, May 22, 2005 4:46 AM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/src/ Changes by: sp...@sc....(none) 05/05/22 02:45:53 Log message: Guarantee consistency of names/addresses in glutGetProcAddress by using a macro. In addition, this avoids any non-constant initializer issues which might be raised when using WinDoze GCCs. The additional code overhead is negligible, at least for x86 (a few instructions per name). Modified files: freeglut/freeglut/: ChangeLog freeglut/freeglut/src/: freeglut_ext.c Revision Changes Path 1.75 +5 -0 freeglut/freeglut/ChangeLog 1.16 +152 -150 freeglut/freeglut/src/freeglut_ext.c ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Sven P. <Sve...@ae...> - 2005-05-24 15:39:47
|
Fay John F Contr AAC/WMG wrote: > This is an excellent idea and a positive change, but unless the > Windows GCC problem was preventing a release I don't think it is the > right thing to do right now. Now we must either remove the change or > issue another release candidate so people can test it. [...] We can leave it in, because I think we will need another release candidate anyway: Game mode under X11 is still broken, but I think I have a fix which I will commit now... :-] Cheers, S. |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-26 12:24:54
|
Gentlemen, Please doublecheck this, but I don't think these changes made it into RC4. I had to put them into my RC4 copy of "freeglut_main.c" manually before committing Takeshi's changes to CVS. The ChangeLog changes are in, though. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of James Jones Sent: Wednesday, May 25, 2005 9:07 PM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/src/ Changes by: pu...@sc....(none) 05/05/25 19:07:15 Log message: Fix joysticks so they are polled by their timer correctly. (Dan Torop) Modified files: freeglut/freeglut/src/: freeglut_main.c Revision Changes Path 1.130 +1 -1 freeglut/freeglut/src/freeglut_main.c ------------------------------------------------------- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-05 14:51:26
|
Sven, Please don't be in a hurry to kill the menu context. Windows doesn't support more than a specific number of rendering contexts, and letting each menu have its own context was killing my application. It was a very subtle bug, too. John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Tuesday, July 05, 2005 6:32 AM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/src/ Changes by: sp...@sc....(none) 05/07/05 04:31:58 Log message: Tiny change to make grep's life easier: Rename the fields of the menu context. Not really worth a ChangeLog entry... IMHO it looks like we could kill the whole MenuContext stuff, it is of no use currently and some things look strange, like e.g. having a context per menu. The latter is not OK when a menu is attached to multiple windows. Modified files: freeglut/freeglut/src/: freeglut_internal.h freeglut_window.c Revision Changes Path 1.75 +2 -2 freeglut/freeglut/src/freeglut_internal.h 1.73 +4 -4 freeglut/freeglut/src/freeglut_window.c ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Sven P. <Sve...@ae...> - 2005-07-06 07:48:39
|
Am Dienstag, 5. Juli 2005 16:50 schrieb Fay John F Contr AAC/WMG: > Please don't be in a hurry to kill the menu context. Windows > doesn't support more than a specific number of rendering contexts, and > letting each menu have its own context was killing my application. It was > a very subtle bug, too. Rest assured, I won't kill it right now, mainly because I find the whole menu code a bit confusing so I can't see akk the consequences... :-( What e.g. I don't understand currently is: Do we *want* to have multiple menus visible in different windows at the same time? (I guess: No.) Do we *have* to support having a single menu attached to different windows? (I guess: Yes). I'm currently just doing a bit of valgrind-ing, cleaning up a few things... Cheers, S. |
From: Stephen J B. <sj...@li...> - 2005-07-06 11:09:47
|
Sven Panne wrote: > Rest assured, I won't kill it right now, mainly because I find the whole menu > code a bit confusing so I can't see akk the consequences... :-( What e.g. I > don't understand currently is: Do we *want* to have multiple menus visible in > different windows at the same time? (I guess: No.) Do we *have* to support > having a single menu attached to different windows? (I guess: Yes). In both cases, I recommend loading up GLUT-classic and seeing what it does and does not allow. It's not about what we want. We're shooting for GLUT compatibility here. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Richard R. <sf...@ol...> - 2005-07-06 12:24:49
|
On Wed, Jul 06, 2005 at 09:48:19AM +0200, Sven Panne wrote: > Am Dienstag, 5. Juli 2005 16:50 schrieb Fay John F Contr AAC/WMG: > > Please don't be in a hurry to kill the menu context. Windows > > doesn't support more than a specific number of rendering contexts, and > > letting each menu have its own context was killing my application. It = was > > a very subtle bug, too. >=20 > Rest assured, I won't kill it right now, mainly because I find the whole = menu=20 > code a bit confusing so I can't see akk the consequences... :-( What e.g.= I=20 > don't understand currently is: Do we *want* to have multiple menus visibl= e in=20 > different windows at the same time? (I guess: No.) Do we *have* to suppor= t=20 > having a single menu attached to different windows? (I guess: Yes). The latter definitely works in old GLUT in at least my current X environment. This has been explicitly documented somewhere, though perhaps not in the freeglut project. For the former, I think that that's more to your discretion. In old GLUT on my current X environment, it is impossible to have more than one menu up at a time. When I suggested changing the menu logic in the past, I recall being told that the freeglut behavior currently is a match for GLUT on WIN32, so...you can do it either way and claim backwards compatibility. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Stephen J B. <sj...@li...> - 2005-07-06 12:48:08
|
Richard Rauch wrote: > For the former, I think that that's more to your discretion. In > old GLUT on my current X environment, it is impossible to have > more than one menu up at a time. When I suggested changing the > menu logic in the past, I recall being told that the freeglut > behavior currently is a match for GLUT on WIN32, so...you can > do it either way and claim backwards compatibility. Given a free choice, it makes sense to only allow one menu to be up at a time so that applications behave the same under both OS's. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Richard R. <sf...@ol...> - 2005-07-07 05:39:31
|
On Wed, Jul 06, 2005 at 07:39:58AM -0500, Stephen J Baker wrote: > Richard Rauch wrote: > > >For the former, I think that that's more to your discretion. In > >old GLUT on my current X environment, it is impossible to have > >more than one menu up at a time. When I suggested changing the > >menu logic in the past, I recall being told that the freeglut > >behavior currently is a match for GLUT on WIN32, so...you can > >do it either way and claim backwards compatibility. > > Given a free choice, it makes sense to only allow one menu to be up > at a time so that applications behave the same under both OS's. Perhaps I wasn't writing very clearly. freeglut menus behave self-consistently on both systems. I'm not sure how closely that that single behavior matches GLUT on WIN32; it is quite distant from GLUT on X. If you "fixed" the freeglut menus to behave as old GLUT did on X ("fix" for *ALL* target platforms), I think that the freeglut menu logic would be simpler and less buggy. And would remain as self-consistent across systems. But, whatever. Though I was not suggesting splitting the freeglut menu logic via #ifdef's, it is in any case not my concern. I'm just offering commentary as someone who's been through most of the freeglut code at least once (most of it several times, actually) and who's spent a little while thinking about the menu problems. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-14 13:26:30
|
Sven, I looked at your change and I see where you fixed a bug of mine--I had left out an "else" in front of the second "if". And your logic is definitely nicer. I do have a request, though, regarding coding style: it is a personal quirk of mine, but I feel very strongly that curly braces belong on a line by themselves. It helps me follow the indentation. Would you be so kind as to reformat the change you put in please? John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Thursday, July 14, 2005 4:39 AM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/src/ Changes by: sp...@sc....(none) 05/07/14 02:39:27 Log message: Fixed the GLUT_CURSOR_INHERIT logic once again... Note that this commit is untested, but at least it looks better than before. We really a need a cursor test program. Modified files: freeglut/freeglut/: ChangeLog freeglut/freeglut/src/: freeglut_cursor.c Revision Changes Path 1.103 +2 -0 freeglut/freeglut/ChangeLog 1.32 +5 -5 freeglut/freeglut/src/freeglut_cursor.c ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Sven P. <Sve...@ae...> - 2005-07-14 18:09:09
|
Am Donnerstag, 14. Juli 2005 15:25 schrieb Fay John F Contr AAC/WMG: > I looked at your change and I see where you fixed a bug of mine--I > had left out an "else" in front of the second "if". And your logic is > definitely nicer. > > I do have a request, though, regarding coding style: it is a > personal quirk of mine, but I feel very strongly that curly braces belong > on a line by themselves. It helps me follow the indentation. Would you be > so kind as to reformat the change you put in please? Well, that's the style that *I* strongly prefer, so the answer is: "No"... ;-) More seriously: I don't think that we have a common style in the sources and the only way to guarantee it is to do indentation automatically. Perhaps we can agree on some common style by specifying the arguments to GNU indent? Probably one of the 3 common styles (GNU/K&R/BSD) plus a few additional flags perhaps? I stopped arguing about the "better" indentation long ago (apart from the bad habit of being too minimalistic about braces), but nevertheless I think it is important to have a consistent style for a project... Cheers, S. |
From: Richard R. <sf...@ol...> - 2005-07-14 23:54:47
|
On Thu, Jul 14, 2005 at 08:08:38PM +0200, Sven Panne wrote: > Am Donnerstag, 14. Juli 2005 15:25 schrieb Fay John F Contr AAC/WMG: > > I looked at your change and I see where you fixed a bug of mine--I > > had left out an "else" in front of the second "if". And your logic is > > definitely nicer. > > > > I do have a request, though, regarding coding style: it is a > > personal quirk of mine, but I feel very strongly that curly braces belo= ng > > on a line by themselves. It helps me follow the indentation. Would yo= u be > > so kind as to reformat the change you put in please? >=20 > Well, that's the style that *I* strongly prefer, so the answer is: "No"..= . ;-)=20 > More seriously: I don't think that we have a common style in the sources = and=20 Actually, the style is very close to uniform (or was when I last worked on it). Certainly compared to when I started, when indentation was wildy different...I don't think you could go more than 5 or 10 lines without seeing a sudden change in indentation. I worked some months on the codebase to normalize around what looked like the most common conventions. When I was done, it looked a lot like the style of some fairly pristine code from Pawel (freeglut's original author). I think that braces on lines by themselves is part of Pawel's style. When I've checked over changes that have appeared since I last worked on the code, I've noticed a divergence to each author's personal preferences. > the only way to guarantee it is to do indentation automatically. Perhaps = we=20 > can agree on some common style by specifying the arguments to GNU indent?= =20 Some of your developers are using WIN32 and may not easily be able to use GNU indent, or may forget. Also, the programs aren't guaranteed to always work reliably; once in a while, I've seen indenters with bugs cause sick formatting...(^& I think that thigns like BSD indent or GNU indent are best for mass conversions of code, not for routine application. > Probably one of the 3 common styles (GNU/K&R/BSD) plus a few additional f= lags=20 > perhaps? I stopped arguing about the "better" indentation long ago (apart= =20 > from the bad habit of being too minimalistic about braces), but neverthel= ess=20 "Bad" and "too", here, are no more objective than the "right" size of an indent, etc. Other than consistency, the only thing I can say objectively is that TABs are bad in code unless you *know* that everyone reading the code has the same tab-size (not a practical assumption at all here). > I think it is important to have a consistent style for a project... Consistency is the only other absolute. It's a pity that the code has diverged from that consistency, a little, but it's not too bad right now. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-10-12 13:14:03
|
Sven, Pardon me, but I thought the "INSTALL" file gave human-readable instructions on how to install the libraries. Are the instructions repeated somewhere else? John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Sven Panne Sent: Wednesday, October 12, 2005 8:05 AM To: fre...@li... Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) CVSROOT: /cvsroot/freeglut Module name: freeglut Repository: freeglut/freeglut/ Changes by: sp...@sc....(none) 05/10/12 06:04:46 Log message: Simply use autoreconf in autogen.sh, it is much simpler and the recommended way in the autotools documentation. Removed INSTALL, install-sh and mkinstalldirs, they are either unused or automatically generated by autogen.sh. Modified files: freeglut/freeglut/: .cvsignore ChangeLog autogen.sh Removed files: freeglut/freeglut/: INSTALL install-sh mkinstalldirs Revision Changes Path 1.5 +3 -0 freeglut/freeglut/.cvsignore 1.109 +18 -0 freeglut/freeglut/ChangeLog 1.5 +1 -6 freeglut/freeglut/autogen.sh ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Freeglut-cvs mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-cvs |
From: Sven P. <Sve...@ae...> - 2005-10-14 15:13:05
|
Am Mittwoch, 12. Oktober 2005 15:10 schrieb Fay John F Contr AAC/WMG: > Pardon me, but I thought the "INSTALL" file gave human-readable > instructions on how to install the libraries. Are the instructions > repeated somewhere else? Well, "human-readable" does not imply that it is written by hand (at least not in our project): Our INSTALL file was an old version of the standard GNU installation guide from autotools. autogen.sh automagically copies an up-to-date version of that file into our tree, so it will be in any distribution. It makes sense for several reasons: Automatically generated files should never be under version control. Furthermore, the instructions should fit to the autotools versions used to generate the distribution. This was not the case before. And a final note: People intending to build things right from SF's CVS are really supposed to know the GNU INSTALL file by heart, so there is no need to keep it. Cheers, S. |
From: f. h. <ha...@ti...> - 2005-10-15 10:37:31
|
unsubscribe -----Original Message----- From: fre...@li... [mailto:fre...@li...]On Behalf Of Sven Panne Sent: 14 October 2005 15:10 To: fre...@li... Subject: Re: [Freeglut-developer] FW: [Freeglut-cvs] CVS Update: freeglut (branch: trunk) Am Mittwoch, 12. Oktober 2005 15:10 schrieb Fay John F Contr AAC/WMG: > Pardon me, but I thought the "INSTALL" file gave human-readable > instructions on how to install the libraries. Are the instructions > repeated somewhere else? Well, "human-readable" does not imply that it is written by hand (at = least not=20 in our project): Our INSTALL file was an old version of the standard GNU = installation guide from autotools. autogen.sh automagically copies an=20 up-to-date version of that file into our tree, so it will be in any=20 distribution. It makes sense for several reasons: Automatically = generated=20 files should never be under version control. Furthermore, the = instructions=20 should fit to the autotools versions used to generate the distribution. = This=20 was not the case before. And a final note: People intending to build = things=20 right from SF's CVS are really supposed to know the GNU INSTALL file by=20 heart, so there is no need to keep it. Cheers, S. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, = discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: steve <sjb...@ai...> - 2005-10-15 13:40:23
|
felicity hankey wrote: > unsubscribe You can't unsubscribe that way, use the web link that the system handily appends to the bottom of every message: > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Stephen J B. <sj...@li...> - 2005-10-17 11:16:32
|
felicity hankey wrote: > unsubscribe Felicity: Repeatedly sending the word 'unsubscribe' to this mailing list will *NEVER* get you unsubscribed. You absolutely, utterly **MUST** visit the web site below to unsubscribe. If you fail to do so, I will simply block posts from you from appearing on the list (to avoid all of these bogus 'unsubscribe' messages from clutting the list) - and you will continue to get unwanted posts from us. So *please* stop doing this - and visit this web page: > https://lists.sourceforge.net/lists/listinfo/freeglut-developer ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |