Page 1 of 2

Recent OS X cvs commits

Posted: 29.05.2005, 04:50
by dirkpitt
I've completed several sets of CVS commits to the macosx Celestia code.

Changes:
- Celestia now compiles, including on Panther (gcc 3.3.x) and Tiger (gcc 4.0)
- Separate settings for galaxies, nebulae, and open clusters
- Added Help > OpenGL Info
- Improved Browser (100 objects, resizable columns)
- Modifier keys now handled by charEntered, so shortcuts like "Ctrl+Shift+U" will be possible in the future
- Non-threaded startup, up to 2x faster on single-processor machines
- Experimental fix for frame stuttering when rotating (some users report jerk back when zooming, but I cannot reproduce - to use old code, define PERIODIC_EVENTS)
- Helpful message displayed when unsupported render path is selected in preferences
- Full screen mode (Display > Options > Toggle Full Screen, or Cmd+F)
- Readme is now rich text by popular demand

I've split up the commits by each major change.

Posted: 29.05.2005, 08:46
by BlindedByTheLight
On behalf of...well, I guess just me (since that's all I feel comfortable speaking for), thanks for all that work! Now... is this something that someone who has essentially no idea what you're talking about (but would like to) learn how to access? Or will those of us without the know-how have to wait for someone else to make this workable?

As far as I can tell, there are various... tidbits (for lack of a better term) of code that need to be run through a... compiler?... to create a workable, runnable Celestia? Is that just a set series of steps a monkey like me could learn? Or does it require a lot of intervention from an experienced user?

ADDED LATER: I've found these two links that are answering a lot of my questions for those interested...

http://sourceforge.net/docman/display_d ... group_id=1

http://cvsbook.red-bean.com/cvsbook.html

I guess what I'm asking for is a step-by-step tutorial on how to... "check-out" and build the latest version of Celestia? I mean, I THINK that's what I'm asking....

Thanks,
Steve
:)

Posted: 29.05.2005, 10:00
by dirkpitt
BlindedByTheLight wrote:On behalf of...well, I guess just me (since that's all I feel comfortable speaking for), thanks for all that work! Now... is this something that someone who has essentially no idea what you're talking about (but would like to) learn how to access? Or will those of us without the know-how have to wait for someone else to make this workable?


I guess something like Toti's "A Primer for new C++ developer volunteers on Win XP" is long overdue for OS X.
Writing docs is not my forte, but I'll see what I can do.

In the mean time, try these abbreviated instructions (Updated 2007-06-17):
(0. If not already done so, install Xcode 2.4.x from the OS X CD/DVD, or download it from Apple. Make sure that you choose options and install the Universal SDK)
1. Open Terminal
2. type, or paste in: cvs -d:pserver:anonymous@celestia.cvs.sourceforge.net:/cvsroot/celestia login
3. As the Password: prompt, hit return
4. Type:
cvs -z3 -d:pserver:anonymous@celestia.cvs.sourceforge.net:/cvsroot/celestia co -P celestia
(the "co" indeed means "check out")
5. Wait for a while, until the download is complete
6. Navigate to the new "celestia" folder inside your home folder, look for the celestia.xcodeproj file inside the "macosx" folder and double click it
7. Choose Build > Build and Debug, or Build and Run

HTH.

Posted: 29.05.2005, 10:08
by BlindedByTheLight
Thanks! I'll give it a try. Maybe if I can get it working, I can help write some kind of more formal tutorial (writing actually is supposedly something I can do - or so they tell me...). Anyhoo, one clarification... do I just open Terminal and start typing or do I have to get Terminal to some kind of special "starting place"? I only b/c, when I open Terminal and immediately put in the first line, I get back:

"-bash: cvs: command not found"

...which makes me think I'm not "starting" from the right spot.

UPDATE: Doh! Looks like I had X11 installed not XCode. Got that downloding now... methinks that error is a likely culprit for the bash error.

Posted: 29.05.2005, 10:33
by julesstoop
You probably don't have the developer tools installed.
Once you have, you might want to run the two terminal commands with sudo, for me that was necessary.

Posted: 29.05.2005, 10:38
by BlindedByTheLight
Thanks julesstoop - and looks like we crossed e-mails (as I was updating my earlier post). Anyhoo, when you say "with sudo" does that mean I put the words "sudo" at the beginning? For example, as in:

sudo cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/celestia login

or somethin' else?

P.S. A second question... what, in actuality, will I have created with this process? Obviously not Celestia 1.32. I'm guessing some form closer to Celestia 1.4pre6? So... my question in other words, will this version be more advanced? In between the two? A weird, non-linear temp off-shoot version?

P.P.S. And now I'm thinking three's a charm in the question department... just out of curiousity, what's to stop someone from uploading malicious code up to such access points?

Posted: 29.05.2005, 10:51
by julesstoop
Yes. You'll have to put sudo exactly where you supposed it would have to go. It means act(do) as superuser(root) It will ask for your admin-password by the way.

I don't have a clue what will be built... I'm trying it right now (it's a first for me as well, using these tools)

Posted: 29.05.2005, 11:01
by selden
BlindedByTheLight wrote:P.S. A second question... what, in actuality, will I have created with this process? Obviously not Celestia 1.32. I'm guessing some form closer to Celestia 1.4pre6? So... my question in other words, will this version be more advanced? In between the two? A weird, non-linear temp off-shoot version?

You'll get the current development version of Celestia, with a few new features that were added after Chris built pre6 for Windows, a few bugfixes and a bunch of new bugs. Most of them you won't notice.
P.P.S. And now I'm thinking three's a charm in the question department... just out of curiousity, what's to stop someone from uploading malicious code up to such access points?
The "pserver" is a readonly CVS server. You have to be a member of the development team with an SSH password to upload code to Celestia's writable CVS repository on SourceForge.

Posted: 29.05.2005, 16:23
by dirkpitt
julesstoop wrote:Once you have, you might want to run the two terminal commands with sudo, for me that was necessary.


That's weird, what are the permissions on your cvs command? (ls -l `which cvs`) For me, they are 0755 (-rwx-r-x-r-x).

Posted: 29.05.2005, 16:35
by julesstoop
Do you mean the permissions on the CVS-folder inside the downloaded celestia source folder?
They are: drwxr-xr-x

Posted: 29.05.2005, 16:59
by Toti
dirkpitt wrote:I guess something like Toti's "A Primer for new C++ developer volunteers on Win XP" is long overdue for OS X.

Just a small clarification: Paolo is the author of that very useful thread.

Bye

Posted: 29.05.2005, 23:12
by BlindedByTheLight
Question... I did the build & run and all Xcode spit out was the program app... is there a separate resources folder for this version or do I use the old one?

I used the old one (from 1.4pre6 and it SEEMS to work... which leads me to say VERY cool... and thank you VERY much Dirkpitt for showing me how to do this) :)

Posted: 30.05.2005, 01:24
by dirkpitt
Toti wrote:
dirkpitt wrote:I guess something like Toti's "A Primer for new C++ developer volunteers on Win XP" is long overdue for OS X.

Just a small clarification: Paolo is the author of that very useful thread.


Do'h, you're right! Thanks for pointing that out.

Posted: 30.05.2005, 01:29
by dirkpitt
BlindedByTheLight wrote:Question... I did the build & run and all Xcode spit out was the program app... is there a separate resources folder for this version or do I use the old one?


To easily get a CelestiaResources folder, try Cleaning (the broom icon), then switching to the "Deployment" build style in Xcode, then building again. A "Celestia" folder will be created inside your build folder, containing a CelestiaResources folder neatly trussed up. You'll have to rename your old CelestiaResources folder and move the new one into its place.

Deployment builds are optimized, and should be preferred over Development builds for regular use.

Re: Recent OS X cvs commits

Posted: 30.05.2005, 11:45
by perdalum
[quote="dirkpitt"]I've completed several sets of CVS commits to the macosx Celestia code.

Changes:
- Celestia now compiles, including on Panther (gcc 3.3.x) and Tiger (gcc 4.0)
- Separate settings for galaxies, nebulae, and open clusters
- Added Help > OpenGL Info
- Improved Browser (100 objects, resizable columns)
- Modifier keys now handled by charEntered, so shortcuts like "Ctrl+Shift+U" will be possible in the future
- Non-threaded startup, up to 2x faster on single-processor machines
- Experimental fix for frame stuttering when rotating (some users report jerk back when zooming, but I cannot reproduce - to use old code, define PERIODIC_EVENTS)
- Helpful message displayed when unsupported render path is selected in preferences
- Full screen mode (Display > Options > Toggle Full Screen, or Cmd+F)
- Readme is now rich text by popular demand

I've split up the commits by each major change.[/quote]

I've just checked out Celestia and build it and tried the full screen function. On my machine (latest iBook videocard: ATI Mobility Radeon 9200) the strange bug that results in a image of the desktop being rendered ontop of the Earth is in the full screen display (with medium and high res), but not the windowed. Is this a known bug? Is it fixable?

Other that that, everything runs fine, thanks for the effort!

Posted: 31.05.2005, 07:41
by BlindedByTheLight
To easily get a CelestiaResources folder, try Cleaning (the broom icon), then switching to the "Deployment" build style in Xcode, then building again. A "Celestia" folder will be created inside your build folder, containing a CelestiaResources folder neatly trussed up. You'll have to rename your old CelestiaResources folder and move the new one into its place.

Thanks for the reply. Just curious... what does "cleaning" do - and is it un-doable? Meaning, for example, if for some reason (I can't think of) and I wanted to go back and do a "development" build after I did a cleaning and deployment build, would I have to re-download all the Celestia files again?

And by optimized... I take it to mean it runs quicker? Or is lacking certain things that someone poking around inside the code would need but that a casual user would not?

I did follow your instructions and actually ended up with several items in my build folder - a orphaned new Celestia app, a celestia folder containing the whole shebang... and a disk image of the whole-shebang as well. Again... worked like a charm. Thank you. I shall, if it is needed, report back anything unusual.

You have to be a member of the development team with an SSH password to upload code to Celestia's writable CVS repository on SourceForge.


Thanks, Selden... the process is becoming a little clearer now. But, still curious... what's to stop some budding hacker from becoming a member of a development team and uploading dangerous code then? Not that I'm doubting anyone here in the slightest (or anyone at all) - just trying to figure out how this fascinating process works. And I guess my brain keeps defaulting to a... supervisor? (for lack of a better term) who is overseeing things and making sure the pieces fit. But I'm getting the feeling opensource doesn't quote work that way...

Posted: 31.05.2005, 08:43
by dirkpitt
BlindedByTheLight wrote:Thanks for the reply. Just curious... what does "cleaning" do - and is it un-doable? Meaning, for example, if for some reason (I can't think of) and I wanted to go back and do a "development" build after I did a cleaning and deployment build, would I have to re-download all the Celestia files again?

Cleaning removes the intermediate (and hence disposable) files generated after a compile. It does not touch the source files, so you can "clean" as many times you want -- although after doing a clean all the files have to be compiled again, which is a slow process.

And by optimized... I take it to mean it runs quicker? Or is lacking certain things that someone poking around inside the code would need but that a casual user would not?

Both. The Development build generates debugging symbols, which are helpful when single-stepping through the code when debugging. Also the generated machine code is unoptimized to facilitate such debugging.

But, still curious... what's to stop some budding hacker from becoming a member of a development team and uploading dangerous code then? ... I guess my brain keeps defaulting to a... supervisor? (for lack of a better term) who is overseeing things


It's my understanding of open source that since anyone can see what anyone is committing to the repository, it is safer in the long run. However, since this is pretty idealistic many open source projects, including this one, also rely on project manager roles to keep things under control.

Posted: 31.05.2005, 10:50
by selden
As the owner of the project on SourceForge, Chris Laurel has to approve applications before people are added to the list of developers.

Posted: 01.06.2005, 01:47
by BlindedByTheLight
Thanks Selden...

Dirkpitt:

To easily get a CelestiaResources folder, try Cleaning (the broom icon), then switching to the "Deployment" build style in Xcode, then building again.


Just so I'm clear... the cleaning process is something you do BEFORE a first build (say, if I followed all your prior instructions to set up Xode). Or do I do a build, then "clean" it... then build again?

Posted: 01.06.2005, 14:32
by dirkpitt
BlindedByTheLight wrote:
To easily get a CelestiaResources folder, try Cleaning (the broom icon), then switching to the "Deployment" build style in Xcode, then building again.

Just so I'm clear... the cleaning process is something you do BEFORE a first build (say, if I followed all your prior instructions to set up Xode). Or do I do a build, then "clean" it... then build again?


Whenever I switch build styles, I always do a clean, followed by the actual build. This makes sure that unoptimized code generated by the compiler for a Development build isn't used when building a Deployment build (and vice versa).

You never build so you can clean, but rather you clean if you think the next build could be tainted by unsuitable machine code (e.g., code generated using a different, incompatible build style) and/or you're just trying to force a compile.