Menu
▾
▴
lightbringer-devel — General discussion on Bringer of Light: The Quest
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(32) |
May
(55) |
Jun
(54) |
Jul
(51) |
Aug
(28) |
Sep
(20) |
Oct
(15) |
Nov
(16) |
Dec
(22) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(15) |
Feb
(11) |
Mar
(33) |
Apr
(35) |
May
(9) |
Jun
|
Jul
(2) |
Aug
|
Sep
(13) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(26) |
Aug
(41) |
Sep
(14) |
Oct
(5) |
Nov
(10) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2007 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Seth Y. <sya...@us...> - 2005-09-30 05:47:46
|
Hi all, Good news! I just committed the new code to the "bringer" CVS module. After I imported the code, I added saving/loading support, which works perfectly. This brings us to step 6 of the plan! Now, get the CEL CVS, CS CVS, and CEGUI 0.4.0, and go give it a try! :) (Be sure you have python installed also) Some notes: The binary data files were not committed to the CVS. We should keep the CVS repository clean of binary data to avoid slowing down the server and exceeding disk usage requirements for old revisions (which are stored as full copies, not diffs like text data). We need a place to put these files so that users know where to get them. A good place is the project web space. I have uploaded them in a .zip file, but perhaps we can come up with a better idea about where to store content (original art files in particular). I'd like to hear some opinions on this. Regards, Seth |
|
From: Seth Y. <sya...@us...> - 2005-09-28 19:56:57
|
Simon wrote: > Heyya, > > this is about how the game engine will draw the entity. My initial idea > was this. Each displayable entity has a class that derives from > Top_Representation. Each entity, when asked to show itself, would call > a draw routine of the Top_Representation clss and the entity would be > drawn by the Top_Representation(using existing sprite drawing class). > CEL has a property class that represents a CS mesh called iPcMesh. Every entity that has a mesh representation will have that property class attached. This is added by default by the blender2crystal exporter if you set the mesh as an entity. CEL and CS will handle the drawing for you, but should you want to make any changes before drawing, there is a callback mechanism in iMeshWrapper (returned by iPcMesh::GetMesh()) that is called before drawing (see iMeshWrapper::SetDrawCallback() at http://crystalspace3d.org/docs/online/api/structiMeshWrapper.php#a46 ). In short, I don't think this class is necessary if the provided CEL and CS functions are used. -Seth |
|
From: Simon M. <sim...@em...> - 2005-09-28 19:33:11
|
> On 28/09/05, Simon <sim...@em...> wrote: > >> Heyya, >> >> this is about how the game engine will draw the entity. My initial idea >> was this. Each displayable entity has a class that derives from >> Top_Representation. Each entity, when asked to show itself, would call >> a draw routine of the Top_Representation clss and the entity would be >> drawn by the Top_Representation(using existing sprite drawing class). >> > > seems complex > >> Comments:? >> >> Cheers, Simon. >> :) my bad, too many mailing lists Cheers, Simon.=20 ____________________ http://www.email.si/ |
|
From: <oza...@gm...> - 2005-09-28 18:38:27
|
On 28/09/05, Simon <sim...@em...> wrote: > Heyya, > > this is about how the game engine will draw the entity. My initial idea > was this. Each displayable entity has a class that derives from > Top_Representation. Each entity, when asked to show itself, would call > a draw routine of the Top_Representation clss and the entity would be > drawn by the Top_Representation(using existing sprite drawing class). > seems complex > Comments:? > > Cheers, Simon. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Lightbringer-devel mailing list > Lig...@li... > https://lists.sourceforge.net/lists/listinfo/lightbringer-devel > -- Ozan |
|
From: Simon <sim...@em...> - 2005-09-28 17:50:53
|
Heyya, this is about how the game engine will draw the entity. My initial idea was this. Each displayable entity has a class that derives from Top_Representation. Each entity, when asked to show itself, would call a draw routine of the Top_Representation clss and the entity would be drawn by the Top_Representation(using existing sprite drawing class). Comments:? Cheers, Simon. |
|
From: <oza...@gm...> - 2005-09-27 04:45:06
|
On 27/09/05, Seth Yastrov <sya...@us...> wrote: > Hi, > > I have just completed up to step 4 of the Code Development Plan. > > The menu screens are there but have no functionality except the New Game = and > Quit buttons. > > Clicking New Game and creating a character loads the starting zone using = a > Python script and adds the player entity to it. The player can then walk = around > the zone and exit the game by hitting Esc. > > The world file was exported from Blender using blender2crystal and some > modifications were made to the scripts provided by this exporter. The scr= ipts > packed into the world.zip file are not used. > > Since CEL does not yet add its path to VFS, it was necessary to copy blce= l.py > into the bringer scripts/ directory for CEL Python scripting to work. Als= o, the > cally model from Cal3d was copied into data/models/. It is licensed GPL s= o it > should be okay. > > The Bringer project website says that the code is licensed LGPL. This lic= ense is > misused. LGPL states that the code under license can be linked to > non-GPL-compatible programs (proprietary code). There is no need for a ga= me like > Bringer to make this exception. The code in Bringer is not in a format su= ch that > it would be of any use to someone linking against it. Therefore, it can b= e > justified that the license should be changed to GPL and updated on the pr= oject > website. The old code will remain LGPL, but the project website should re= flect > the current code. > > After the site is updated, I will add the GPL header to the code and comm= it it > to the new "bringer" module. > okey seth i am dying to see the code :P > Thanks, > Seth > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Downl= oad > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Lightbringer-devel mailing list > Lig...@li... > https://lists.sourceforge.net/lists/listinfo/lightbringer-devel > -- Ozan |
|
From: Seth Y. <sya...@us...> - 2005-09-26 21:07:24
|
Hi, I have just completed up to step 4 of the Code Development Plan. The menu screens are there but have no functionality except the New Game and Quit buttons. Clicking New Game and creating a character loads the starting zone using a Python script and adds the player entity to it. The player can then walk around the zone and exit the game by hitting Esc. The world file was exported from Blender using blender2crystal and some modifications were made to the scripts provided by this exporter. The scripts packed into the world.zip file are not used. Since CEL does not yet add its path to VFS, it was necessary to copy blcel.py into the bringer scripts/ directory for CEL Python scripting to work. Also, the cally model from Cal3d was copied into data/models/. It is licensed GPL so it should be okay. The Bringer project website says that the code is licensed LGPL. This license is misused. LGPL states that the code under license can be linked to non-GPL-compatible programs (proprietary code). There is no need for a game like Bringer to make this exception. The code in Bringer is not in a format such that it would be of any use to someone linking against it. Therefore, it can be justified that the license should be changed to GPL and updated on the project website. The old code will remain LGPL, but the project website should reflect the current code. After the site is updated, I will add the GPL header to the code and commit it to the new "bringer" module. Thanks, Seth |
|
From: <oza...@gm...> - 2005-09-24 21:18:51
|
i like to configure cvs for that -- Ozan |
|
From: Team D. <tea...@gm...> - 2005-09-10 06:30:29
|
Hi All,
I'm almost finished with the revised guidelines, with respect
to the Inteface naming convention, could an official vote be conducted
or further debate continue,I personally vote for the prefix
bolInterfaceItem though i think the namespace mechanism deserves some
thought.Thanks.
Regards,
Kenneth
|
|
From: Pascal K. <kir...@us...> - 2005-09-01 20:51:17
|
> > I would name BOL interfaces differently than CS interfaces for clarity > > purposes. Maybe prefix them with boliInterface/biInterface. > > Browsing a bit through the CS I find the CamelCase is used for classes > > and functions, however for variables it's the_long_one. Variables also > > don't seem to use any notation so we probably won't to. > > > > I agree about naming BoL interfaces differently. Another idea is iBolInterface. > This is the way CEL does it for many things (e.g. iCelEntity). The > implementation could be named like bolClass. > Or just to say something totally crazy, what about just using namespaces instead of prefixes? :-O :-) |
|
From: Seth Y. <se...@ya...> - 2005-09-01 18:40:29
|
Simon wrote: > I would name BOL interfaces differently than CS interfaces for clarity > purposes. Maybe prefix them with boliInterface/biInterface. > Browsing a bit through the CS I find the CamelCase is used for classes > and functions, however for variables it's the_long_one. Variables also > don't seem to use any notation so we probably won't to. > I agree about naming BoL interfaces differently. Another idea is iBolInterface. This is the way CEL does it for many things (e.g. iCelEntity). The implementation could be named like bolClass. Seth |
|
From: Pascal K. <kir...@us...> - 2005-09-01 08:25:44
|
> I would name BOL interfaces differently than CS interfaces for clarity > purposes. Maybe prefix them with boliInterface/biInterface. > Browsing a bit through the CS I find the CamelCase is used for classes > and functions, however for variables it's the_long_one. Variables also > don't seem to use any notation so we probably won't to. as long as you don't want me to write m_ prefixes for class member variables, I'm happy :) btw, functions are often written in pascalCase in the verb style, like takeAxe(); openDoor(); killDragon(); However, CS does not! I don't know why and I'm happy with both styles as long as you don't mix both styles :) |
|
From: Simon <sim...@em...> - 2005-09-01 06:30:07
|
> On 8/30/05, Pascal Kirchdorfer <kir...@us...> wrote: > >>>1. Coding Style >>>coding styles >> >>If we're going to use CS and CEL we might as well take their code style? >>That would be: >>- 2 space indent, >>- 1 tab = 8 space, >>- no line longer 78 characters (tab=8), >>- CamelCase function names, >>- Class names go csClass (or in our case bolClass), >>- Interfaces go iInterface >> >>Just a suggestion, love it or hate it :) > > > Ok, let's see what everyone has to say, then we can decide which to use. > I would name BOL interfaces differently than CS interfaces for clarity purposes. Maybe prefix them with boliInterface/biInterface. Browsing a bit through the CS I find the CamelCase is used for classes and functions, however for variables it's the_long_one. Variables also don't seem to use any notation so we probably won't to. >>>iv. File Creation >>>> > Any new files created should be followed by an announcment via the mailing list. >> >>> >>> I would say this is a bit tedious to do, especially at the start of development. >>> Those with CVS access should be trusted not to make too much clutter and think >>> about what they are committing. > > > This wouldn't be on a per file basis :) , but i agree with you that it > is tedious. We could ignore this if we decide to rewrite sources, but > in later development (when we start adding bits and pieces) this could > be helpful. > Maybe a weekly report on the beginning, later on a per file report. |
|
From: Team D. <tea...@gm...> - 2005-08-31 22:24:26
|
Ok...If no one has any objections,we can officially adopt the CS coding style for the project.This will be added to the final Guidelines :). Regards, Kenneth On 8/31/05, Pascal Kirchdorfer <kir...@us...> wrote: > > >>I agree with Pascal that we should adopt the Crystal Space coding sty= le, > since > > >>we use that SDK and it makes it more readable. > > > > > > > > > Two votes for CS like coding styles :). > > > > Since I am "priority coder", and will be working more often with the co= de, > my > > vote counts a little more :) > > > > Really, most projects using CS adopt this style, and we were using it > before, so > > I see no reason to change it. >=20 > It makes things nicer for me too, so I don't have to change the IDE setti= ngs > all the time :-) > but then again, I don't think I will code that much.... I'll do more for > opentree which uses the same style btw :-) >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Lightbringer-devel mailing list > Lig...@li... > https://lists.sourceforge.net/lists/listinfo/lightbringer-devel > |
|
From: Pascal K. <kir...@us...> - 2005-08-31 22:14:17
|
> >>I agree with Pascal that we should adopt the Crystal Space coding style, since > >>we use that SDK and it makes it more readable. > > > > > > Two votes for CS like coding styles :). > > Since I am "priority coder", and will be working more often with the code, my > vote counts a little more :) > > Really, most projects using CS adopt this style, and we were using it before, so > I see no reason to change it. It makes things nicer for me too, so I don't have to change the IDE settings all the time :-) but then again, I don't think I will code that much.... I'll do more for opentree which uses the same style btw :-) |
|
From: Team D. <tea...@gm...> - 2005-08-31 22:08:47
|
On 8/31/05, Seth Yastrov <se...@ya...> wrote: > Team Digital wrote: > >>I agree with Pascal that we should adopt the Crystal Space coding style= , since > >>we use that SDK and it makes it more readable. > > > > > > Two votes for CS like coding styles :). >=20 > Since I am "priority coder", and will be working more often with the code= , my > vote counts a little more :) >=20 > Really, most projects using CS adopt this style, and we were using it bef= ore, so > I see no reason to change it. >=20 > Seth >=20 Sorry,my use of the term "votes" was used loosely,we've not tallied up the official count on this yet, and i was just giving everyone time to have their comments in before we standardized anything. Regards, Kenneth |
|
From: Seth Y. <se...@ya...> - 2005-08-31 22:01:00
|
Team Digital wrote: >>I agree with Pascal that we should adopt the Crystal Space coding style, since >>we use that SDK and it makes it more readable. > > > Two votes for CS like coding styles :). Since I am "priority coder", and will be working more often with the code, my vote counts a little more :) Really, most projects using CS adopt this style, and we were using it before, so I see no reason to change it. Seth |
|
From: Team D. <tea...@gm...> - 2005-08-31 21:25:19
|
> > 3. Documentation > > To help us down the road in maintenance, certain information must be > > contained in the source files.Every file must contain a section that > > deal with the files > > purpose,functions contained and any relavent notes. e.g. > > > > ******************************* > > FILENAME: > > PURPOSE: > > NOTES: > > EXPORTED FUNCTIONS: > > ****************************** > > > > Also before every function a section must be created that should > > contain the following information: > > > > /* > > function name > > function parameters > > function comments > > */ > > > return info should be there, too. yeah,return info should be here :). Regards, Kenneth |
|
From: Team D. <tea...@gm...> - 2005-08-31 21:23:20
|
On 8/30/05, Simon <sim...@em...> wrote: >=20 > > On 30/08/05, Team Digital <tea...@gm...> wrote: > >>1. Coding Style > >> As we all have our own diverse coding styles, a single agreed upon > >>style (e.g. K & R ) with a corresponding indentation ( 4 spaces tab > >>width?) would give > >>all the sourcefiles a uniform and intuitive appearance. There is also > >>the issue of the various platforms that the developers might use and > >>the different > >>CR/LF characters that they use, using the gnu indent program may > >>eliminate this problem.This, most likely, will be a topic that may > >>need some voting as it may > >>require the change of many of our ingrown habits (guilty :) ). You can > >>vote by simply replying to this thread with your votes/comments and > >>your suggested Styles, Naming Conventions and Indentation formats. > >> > > > > my vote goes to K&R because it gives smaller source files and easier re= ading. > > about tab space, we should put tab not spaces then everybody can use > > their prefered tab width with their prefered editor. i always put tab, > > not spaces. > > Naming Convention; i have no idea. i don't use one. > > > K&R is nice since theres lots of code already using it. Two votes for K&R, i haven't voted on this yet as i was waiting on suggestions for an approiate style.Still waiting on anyone who has any other suggestion/comments. > >>3. Documentation > >>To help us down the road in maintenance, certain information must be > >>contained in the source files.Every file must contain a section that > >>deal with the files > >>purpose,functions contained and any relavent notes. e.g. > >> > >>******************************* > >>FILENAME: > >>PURPOSE: > >>NOTES: > >>EXPORTED FUNCTIONS: > >>****************************** >=20 > I suggest we use doxygen for the documentation of files, functions, ... Doxygen is has been added to the Guidelines for Documentation. Regards, Kenneth |
|
From: Team D. <tea...@gm...> - 2005-08-31 21:16:17
|
On 8/31/05, Seth Yastrov <se...@ya...> wrote: > Team Digital wrote: > > Hello All, > > I'm now getting on track with the development, sorry for > > my absense :( but it was home related issue.Below is a sample set of > > Guidelines that we would > > like to implement,with respect to development.These were conceived to > > streamline development and provide a starting point to new > > developers.Any and all input would be welcomed and we can vote on any > > aspects that may be disputed :). > > > > 1. Coding Style >=20 > I agree with Pascal that we should adopt the Crystal Space coding style, = since > we use that SDK and it makes it more readable. Two votes for CS like coding styles :). > > ii. A Changes File could be created that will contain information > > about contributions.Here is the suggested format of this file. >=20 > Again, I think we should follow CS convention and have a history.txt file= like > Pascal said. I agree on this format, so if no one has any objections we could adopt this instead. > > iv. File Creation > > Any new files created should be followed by an announcment via the mail= ing list. >=20 > I would say this is a bit tedious to do, especially at the start of devel= opment. > Those with CVS access should be trusted not to make too much clutter and = think > about what they are committing. This wouldn't be on a per file basis :), but i agree with you that it is tedious. We could ignore this if we decide to rewrite sources, but in later development (when we start adding bits and pieces) this could be helpful. > > 3. Documentation >=20 > I also agree that we should use Doxygen comments here. > Still, in addition to source documentation, I think we should consider ma= king > separate developer's documentation (about the various game systems), and > additionally, a user's manual. I fully agree with you here but this will come up a bit later in development so we don't have to worry about this now ;). Regards, Kenneth |
|
From: Team D. <tea...@gm...> - 2005-08-31 21:01:48
|
On 8/30/05, Pascal Kirchdorfer <kir...@us...> wrote: > > 1. Coding Style > > coding styles > If we're going to use CS and CEL we might as well take their code style? > That would be: > - 2 space indent, > - 1 tab =3D 8 space, > - no line longer 78 characters (tab=3D8), > - CamelCase function names, > - Class names go csClass (or in our case bolClass), > - Interfaces go iInterface > > Just a suggestion, love it or hate it :) Ok, let's see what everyone has to say, then we can decide which to use. > > 2. Updating > you mean commiting? > cvs update is something else, just to avoid confusion. Sorry if this wasn't clear, but i meant to encompass all the aspects of Modifing the project (creating, deleting,updating). > > ii. A Changes File could be created that will contain information > > about contributions.Here is the suggested format of this file. > > What about this format? > http://cvs.sourceforge.net/viewcvs.py/crystal/crystalcore/docs/history.tx= t?view=3Dmarkup This is a great format, i know some of my suggestions might be tedious, they're a side affect of the fact that i normally code by myself and i've been focusing on web designing for the past year :). > 3. Documentation > > To help us down the road in maintenance, certain information must be > > contained in the source files.Every file must contain a section that > > deal with the files purpose,functions contained and any relavent notes. > > I suggest doxygen style comments. > > >Also before every function a section must be created that ... > > doxygen comment should do fine here too > > Using doxygen allows us go generate nice and easy to read websites or eve= n > pdf files (via LaTeX). > > I also recommend the use of \todo, \depreciated, \bug and \test which all= ows > the > generation of todo lists, bug lists, etc. I had originally included doxygen in my first guidelines but i misplaced the file (seriously!) and when i had to rewrite it i didn't include it with the rest because of time( it was long overdue ) and forgetfullness on my part. > > 4. Tools > > A development platform thread will be created to facilitate > I don't know exactly what you mean, but I just disagree :-) > CS provied a great buildsystem that works on windows and linux just great > and allows also platform independant code. This is possible thanks to CS'= s > virtual filesystem, thread wrappers and many more. > > That means, with the CS jamtemplate you can generate MSVC project > files from the command line, maybe even by a cronjob? A side-effect of my haste as stated above :). But my thoughts on this were centered on compilers,libraries and misc. tools that we might use to compile the sources now or in the future, just so we could have everything documented. > Furthermore, projects using that buildsystem are known to work on > Windows using MSVC, mingw(gnu for windows) as well as Linux using > GCC/Jam and MacOsX using.... whatever, I don't use macosx, but it work :) > > Well, those are my 2 cents... > > - PK Thanks for the feedback :). |
|
From: Seth Y. <se...@ya...> - 2005-08-31 19:52:45
|
Team Digital wrote: > Hello All, > I'm now getting on track with the development, sorry for > my absense :( but it was home related issue.Below is a sample set of > Guidelines that we would > like to implement,with respect to development.These were conceived to > streamline development and provide a starting point to new > developers.Any and all input would be welcomed and we can vote on any > aspects that may be disputed :). > > 1. Coding Style I agree with Pascal that we should adopt the Crystal Space coding style, since we use that SDK and it makes it more readable. > 2. Updating > i. After all updates, a cvs comment must be added, this comment must > include the authors name and the changes made. A simple commit message is fine, the username who committed is recorded automatically. > ii. A Changes File could be created that will contain information > about contributions.Here is the suggested format of this file. Again, I think we should follow CS convention and have a history.txt file like Pascal said. > iii. Module Creation > Before any new modules are created a request must be sent to the > project leaders and the other developers notified via the mailing > list.This is merely a way > of avoiding too many structural changes to the cvs directory > (especially module removal,which takes a lot of time on sourceforge). I agree. I should also send be sending a request to start on the development module as soon as I get settled with school :) > iv. File Creation > Any new files created should be followed by an announcment via the mailing list. I would say this is a bit tedious to do, especially at the start of development. Those with CVS access should be trusted not to make too much clutter and think about what they are committing. > v. File Deletion > As above, any removal of files (whether created by you or not).Should > be preceded be a request to the project leaders and a notification to > the developers > via the mailing list. I agree. Since some people don't always know the purpose of the file, it can be asked about on the mailing list and for whatever reason, removed. > 3. Documentation I also agree that we should use Doxygen comments here. Still, in addition to source documentation, I think we should consider making separate developer's documentation (about the various game systems), and additionally, a user's manual. > 4. Tools > Since there are two development platforms currently in use, this is > even more important.It is the sole responsibility of the developer to > maintain the versions that are currently supported. We will try ,as a > team, to choose the most generic tools that can be used to create the > sources, A development platform thread will be created to facilitate > this, It will contain all the software and their versions used to > create the program.As such all new and current members will be asked > to maintain a certain development environment depending on platform. > This is another topic that may/may not require voting. If you are talking about build system, we will use the Crystal Space Jam-based build system, which supports many development platforms, and is relatively painless to use. Seth |
|
From: Pascal K. <kir...@us...> - 2005-08-30 16:58:10
|
> 1. Coding Style > coding styles If we're going to use CS and CEL we might as well take their code style? That would be: - 2 space indent, - 1 tab = 8 space, - no line longer 78 characters (tab=8), - CamelCase function names, - Class names go csClass (or in our case bolClass), - Interfaces go iInterface Just a suggestion, love it or hate it :) > the different CR/LF characters that they use. CVS should handle that, wincvs is a little bitchy, it assumes that everything is in Unix format and therefore change CR/LF to CR/CR/LF :/ So in the cvs repository, everything should be LF, then cvs or wincvs can convert it to your local platform and back nicely. > 2. Updating you mean commiting? cvs update is something else, just to avoid confusion. > i. After all updates, a cvs comment must be added, this comment must > include the authors name and the changes made. Agreed. > ii. A Changes File could be created that will contain information > about contributions.Here is the suggested format of this file. What about this format? http://cvs.sourceforge.net/viewcvs.py/crystal/crystalcore/docs/history.txt?view=markup You should be able to find a file in lightbringer/bringeroflight/docs/history.txt already. > iii. Module Creation > Before any new modules are created a request must be sent to the > project leaders and the other developers notified via the mailing > list.This is merely a way > of avoiding too many structural changes to the cvs directory > (especially module removal,which takes a lot of time on sourceforge). Agreed > iv. File Creation > Any new files created should be followed by an announcment via the mailing > list. Since you can't really delete them, the should be discussed and confirmed by an admin as well to avoid trash in the repository. > v. File Deletion On sourceforge you can (fortunately) not permanently delete a file. This has to be requested by the SF staff. 3. Documentation > To help us down the road in maintenance, certain information must be > contained in the source files.Every file must contain a section that > deal with the files purpose,functions contained and any relavent notes. I suggest doxygen style comments. >Also before every function a section must be created that ... doxygen comment should do fine here too Using doxygen allows us go generate nice and easy to read websites or even pdf files (via LaTeX). I also recommend the use of \todo, \depreciated, \bug and \test which allows the generation of todo lists, bug lists, etc. > 4. Tools > A development platform thread will be created to facilitate I don't know exactly what you mean, but I just disagree :-) CS provied a great buildsystem that works on windows and linux just great and allows also platform independant code. This is possible thanks to CS's virtual filesystem, thread wrappers and many more. That means, with the CS jamtemplate you can generate MSVC project files from the command line, maybe even by a cronjob? Furthermore, projects using that buildsystem are known to work on Windows using MSVC, mingw(gnu for windows) as well as Linux using GCC/Jam and MacOsX using.... whatever, I don't use macosx, but it work :) Well, those are my 2 cents... - PK |
|
From: Simon <sim...@em...> - 2005-08-30 14:35:18
|
> On 30/08/05, Team Digital <tea...@gm...> wrote: > >>Hello All, >> I'm now getting on track with the development, sorry for >>my absense :( but it was home related issue.Below is a sample set of >>Guidelines that we would >>like to implement,with respect to development.These were conceived to >>streamline development and provide a starting point to new >>developers.Any and all input would be welcomed and we can vote on any >>aspects that may be disputed :). >> >>1. Coding Style >> As we all have our own diverse coding styles, a single agreed upon >>style (e.g. K & R ) with a corresponding indentation ( 4 spaces tab >>width?) would give >>all the sourcefiles a uniform and intuitive appearance. There is also >>the issue of the various platforms that the developers might use and >>the different >>CR/LF characters that they use, using the gnu indent program may >>eliminate this problem.This, most likely, will be a topic that may >>need some voting as it may >>require the change of many of our ingrown habits (guilty :) ). You can >>vote by simply replying to this thread with your votes/comments and >>your suggested Styles, Naming Conventions and Indentation formats. >> > > my vote goes to K&R because it gives smaller source files and easier reading. > about tab space, we should put tab not spaces then everybody can use > their prefered tab width with their prefered editor. i always put tab, > not spaces. > Naming Convention; i have no idea. i don't use one. > K&R is nice since theres lots of code already using it. >>2. Updating >> With respect to updating the cvs directory,two notification >>approaches were concieved. >> >>i. After all updates, a cvs comment must be added, this comment must >>include the authors name and the changes made. >> >>ii. A Changes File could be created that will contain information >>about contributions.Here is the suggested format of this file. >> >>***************************** >>DATE >>AUTHOR >>COMMENTS >>FILES-UPDATED >>***************************** >> >>The Changes File is merely for archival and troubleshooting >>purposes,one should be created per module,we can use either one of >>these schemes or a mix of both, we're open to any other suggestions. >> > > makes sence a lot > >>iii. Module Creation >>Before any new modules are created a request must be sent to the >>project leaders and the other developers notified via the mailing >>list.This is merely a way >>of avoiding too many structural changes to the cvs directory >>(especially module removal,which takes a lot of time on sourceforge). >> > > makes sence > >>iv. File Creation >>Any new files created should be followed by an announcment via the mailing list. >> > > yep > >>v. File Deletion >>Ads above, any removal of files (whether created by you or not).Should >>be preceded be a request to the project leaders and a notification to >>the developers >>via the mailing list. >> > > nice > >>3. Documentation >>To help us down the road in maintenance, certain information must be >>contained in the source files.Every file must contain a section that >>deal with the files >>purpose,functions contained and any relavent notes. e.g. >> >>******************************* >>FILENAME: >>PURPOSE: >>NOTES: >>EXPORTED FUNCTIONS: >>****************************** I suggest we use doxygen for the documentation of files, functions, ... >>Also before every function a section must be created that should >>contain the following information: >> >>/* >>function name >>function parameters >>function comments >>*/ >> > > return info should be there, too. As I said above. >>These may be painful initially but they may be (hopefully)rarely updated. >> >>4. Tools >>Since there are two development platforms currently in use, this is >>even more important.It is the sole responsibility of the developer to >>maintain the versions that are currently supported. We will try ,as a >>team, to choose the most generic tools that can be used to create the >>sources, A development platform thread will be created to facilitate >>this, It will contain all the software and their versions used to >>create the program.As such all new and current members will be asked >>to maintain a certain development environment depending on platform. >>This is another topic that may/may not require voting. >> >>This is all that I have for now,as I expect that we will need to >>formalize and standardise on these practices, since it was suggested >>in a recent post that a >>complete code rewrite be done,this may end up being relatively >>painless.I'm looking forward to your correspondence on this topic and >>your votes :). >> > |
|
From: <oza...@gm...> - 2005-08-30 14:21:47
|
On 30/08/05, Team Digital <tea...@gm...> wrote: > Hello All, > I'm now getting on track with the development, sorry for > my absense :( but it was home related issue.Below is a sample set of > Guidelines that we would > like to implement,with respect to development.These were conceived to > streamline development and provide a starting point to new > developers.Any and all input would be welcomed and we can vote on any > aspects that may be disputed :). >=20 > 1. Coding Style > As we all have our own diverse coding styles, a single agreed upon > style (e.g. K & R ) with a corresponding indentation ( 4 spaces tab > width?) would give > all the sourcefiles a uniform and intuitive appearance. There is also > the issue of the various platforms that the developers might use and > the different > CR/LF characters that they use, using the gnu indent program may > eliminate this problem.This, most likely, will be a topic that may > need some voting as it may > require the change of many of our ingrown habits (guilty :) ). You can > vote by simply replying to this thread with your votes/comments and > your suggested Styles, Naming Conventions and Indentation formats. >=20 my vote goes to K&R because it gives smaller source files and easier readin= g. about tab space, we should put tab not spaces then everybody can use their prefered tab width with their prefered editor. i always put tab, not spaces. Naming Convention; i have no idea. i don't use one. > 2. Updating > With respect to updating the cvs directory,two notification > approaches were concieved. >=20 > i. After all updates, a cvs comment must be added, this comment must > include the authors name and the changes made. >=20 > ii. A Changes File could be created that will contain information > about contributions.Here is the suggested format of this file. >=20 > ***************************** > DATE > AUTHOR > COMMENTS > FILES-UPDATED > ***************************** >=20 > The Changes File is merely for archival and troubleshooting > purposes,one should be created per module,we can use either one of > these schemes or a mix of both, we're open to any other suggestions. >=20 makes sence a lot > iii. Module Creation > Before any new modules are created a request must be sent to the > project leaders and the other developers notified via the mailing > list.This is merely a way > of avoiding too many structural changes to the cvs directory > (especially module removal,which takes a lot of time on sourceforge). >=20 makes sence > iv. File Creation > Any new files created should be followed by an announcment via the mailin= g list. >=20 yep > v. File Deletion > Ads above, any removal of files (whether created by you or not).Should > be preceded be a request to the project leaders and a notification to > the developers > via the mailing list. >=20 nice > 3. Documentation > To help us down the road in maintenance, certain information must be > contained in the source files.Every file must contain a section that > deal with the files > purpose,functions contained and any relavent notes. e.g. >=20 > ******************************* > FILENAME: > PURPOSE: > NOTES: > EXPORTED FUNCTIONS: > ****************************** >=20 > Also before every function a section must be created that should > contain the following information: >=20 > /* > function name > function parameters > function comments > */ >=20 return info should be there, too. > These may be painful initially but they may be (hopefully)rarely updated. >=20 > 4. Tools > Since there are two development platforms currently in use, this is > even more important.It is the sole responsibility of the developer to > maintain the versions that are currently supported. We will try ,as a > team, to choose the most generic tools that can be used to create the > sources, A development platform thread will be created to facilitate > this, It will contain all the software and their versions used to > create the program.As such all new and current members will be asked > to maintain a certain development environment depending on platform. > This is another topic that may/may not require voting. >=20 > This is all that I have for now,as I expect that we will need to > formalize and standardise on these practices, since it was suggested > in a recent post that a > complete code rewrite be done,this may end up being relatively > painless.I'm looking forward to your correspondence on this topic and > your votes :). >=20 --=20 Ozan |
4 messages has been excluded from this view by a project administrator.
