alephmodular-devel Mailing List for AlephModular (Page 3)
Status: Pre-Alpha
Brought to you by:
brefin
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(193) |
Feb
(61) |
Mar
(55) |
Apr
(5) |
May
(3) |
Jun
(1) |
Jul
(3) |
Aug
(14) |
Sep
(19) |
Oct
(48) |
Nov
(6) |
Dec
(25) |
2004 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(20) |
Jul
(13) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jeremy P. <jer...@ve...> - 2005-05-03 18:32:15
|
On May 3, 2005, at 1:52 PM, Timothy Collett wrote: > On May 3, 2005, at 12:49 PM, Br'fin wrote: > > >> Having gotten my machine mostly stable under MacOS X 10.4 Tiger I >> figured it was time to do a little housecleaning and updating on >> AlephModular. At the very least make sure it still compiles and >> deal with any new warnings that come up. >> > > Good to see some work being done on it, anyway :-) > > You planning on getting back into actually improving it, or is it > to remain on hiatus for the time being? > > Timothy Collett I have it, but I honestly don't know what to do with it. A mix of technical morasses in key spots, like the main event loop, and lack of impetus and know-how to do anything about it. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
From: Timothy C. <da...@ma...> - 2005-05-03 17:52:33
|
On May 3, 2005, at 12:49 PM, Br'fin wrote: > Having gotten my machine mostly stable under MacOS X 10.4 Tiger I > figured it was time to do a little housecleaning and updating on > AlephModular. At the very least make sure it still compiles and > deal with any new warnings that come up. Good to see some work being done on it, anyway :-) You planning on getting back into actually improving it, or is it to remain on hiatus for the time being? Timothy Collett -- A 'proof' is whatever it takes to convince your audience. --Unknown |
From: Br'fin <br...@ma...> - 2005-05-03 16:49:12
|
Having gotten my machine mostly stable under MacOS X 10.4 Tiger I figured it was time to do a little housecleaning and updating on AlephModular. At the very least make sure it still compiles and deal with any new warnings that come up. Most of it came down to adding parenthesis to assert that I did indeed want to be making assignments during a number of low level if statements in low_level_textures.h. Though there were a few other tweaks as well. Such as places where a pointer was being cast to another pointer and then modified that GCC was warning would be labeled hard errors in the future. Most of the latter cases involved either the RLE Encoding of shapes or adjusting pointers by the slop space around a bitmap for the quadruple screen effect. I imagine some assumptions could be further made around the quadruple screen code, in terms of alignment of things. But I decided to just keep the code as is, with a local inline function to cover the casts without using any cast as an l-value. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
From: Matt L. <ze...@ze...> - 2004-10-14 23:20:58
|
I noticed the Web site hadn't been updated in a while, which is no surprise since last time I checked, I was the one who offered to take care of that. I went ahead and added the tidbits for the past year or so, garnered from the mailing list. I also added some links in the FAQ and mentioned in the answer to development tools that we now use Xcode. If there's anything else that should get added, let me know. I'd be happy to do so. /zebe -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
From: Br'fin <br...@ma...> - 2004-07-08 07:26:04
|
I finally got around to doing something to the code base. It's not much, but it should help in the long run as well. Marathon2 had the ability to play a Quicktime movie file named 'Movie' before beginning the first level of the game. I ended up sinking this capability into a CMovies set of classes. It wasn't quite display and it wasn't quite sound. The implementation looks fairly similar to the CMusic setup, especially at the CMovie_Carbon level, but has different functionality higher up, and even lower you specify a buffer and display box when you tell the movie to start. In addition to abstracting movie playing, I tweaked it so that via clipping regions, it would respect the clipping area of the buffer specified. Admittedly this may not mesh perfectly with perhaps a pixel-doubled buffer, but ah well. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
From: Br'fin <br...@ma...> - 2004-06-25 15:39:55
|
Some of you may have encountered this on Slashdot or the like.=20 Certainly seems an interesting list with a number of valid points. Such=20= as shared focus. 21 Rules of Thumb =96 How Microsoft develops its Software http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx -Jeremy Parsons http://alephmodular.sourceforge.net/= |
From: Br'fin <br...@ma...> - 2004-05-06 00:10:49
|
I am available frequently on the AIM/iChat IM network under br...@ma... -Jeremy Parsons http://alephmodular.sourceforge.net/ |
From: Br'fin <br...@ma...> - 2004-04-27 16:51:28
|
This is true. And I already did some work in this vein for A1, mostly to support 'don't auto recenter' and 'don't switch weapons' See: https://sourceforge.net/tracker/index.php? func=detail&aid=768414&group_id=1997&atid=101997 Shards, at this point I forget what I need to do for movies to get the values saved. D'oh :) It's been too long since I fixed up the groundwork. -Jeremy Parsons http://alephmodular.sourceforge.net/ On Apr 27, 2004, at 11:51 AM, Paul Bucher wrote: > I haven't looked very closely at the film structure of A1/AM but I > believe they are similar to Myth's. The Myth team has worked around the > problem of breaking old film support by starting to store a version # > in > the film and when the film is played back we set a flag in a global > variable so through out the game play code we check the flag. If the > film file doesn't contain a version # then we just set the > "old_version_flag". > > In pseudo code: > if (game_play_flag & old_version_flag) > {old code} > else > {new code} > |
From: Br'fin <br...@ma...> - 2004-04-27 16:17:45
|
I already nixed it. (It's still in CVS, but no longer the head of the trunk, alas not in the nightly.) I think we don't typically see it in M2 because of what I mentioned in an earlier message. Slow _look_center only occurs with mousing enabled. And it does look like M2 had this problem. M2 had the option to play with mouse turned off. But it looks like at least two of the demo movies in M2 (The ones where the guy doesn't get killed... a replay of waterloo waterpark, and they're everywhere) appear to have been played with strictly the keyboard while the mouse was enabled. ... the problem is there, but worked around or not evident much. That it did show up at all in those films surprised me. But that they did is the biggest reason for me to revert the patch. Especially in AM. Due to personal preferences, you might not have noticed the problem. For instance, it shouldn't occur when you have mousing turned off. And you're not going to notice it if you've turned the mouse on and are actually using it. Also, related keyboard input can override mouse directions where function overlaps. (ie an explicit _look_up will override mouse position moving up or down) A1 adds to the issue because it changed its options to: keyboard + mouse, keyboard + inputsprocket mouse, inputsprocket only. The problem may not have occurred under the input sprocket version as that code was pickier about when it instantiated pitch commands. It's unclear if that is 'correct', though it does occur in platform specific code and before the commands are packed into action flags. (I wonder if Input Sprockets mouse drifted a little after you stopped the mouse? Since it wouldn't necessarily get the last little ping that the mouse stopped moving... I'm a little unclear.) Code that affects this issue: vbl_macintosh.cpp (and other vbl type files) affect when mask_in_absolute_positioning_information() is used and called. physics.cpp mask_in_absolute_positioning_information() merges the mouse position into the action flags and sets the _absolute_pitch_mode_bit Also has code to only add this if the delta_yaw has changed or if there's angular velocity (this is why when you hit _look_center and don't touch the mouse, the view staggers... no velocity, no absolute info... recentering occurs... oops, now there's velocity but no mouse movement... so sending in a absolute pitch mode directive... killing the velocity, and skipping the recentering for a frame...lather, rinse, repeat.) physics_update() Where the actual recentering is done, as are choices for using absolute position mode or keyboard input. The patch was initially applied to this file. -Jeremy Parsons http://alephmodular.sourceforge.net/ On Apr 27, 2004, at 3:43 AM, em...@ex... wrote: > I would prefer to see the change stay in long enough for me to grab a > copy. I don't want to see film playback broken, but I cannot help > but wonder why this would break the films when the original Marathon > as well as Infinity did not have this stagger behavior. If returning > the keyboard only option to the preferences is the best solution, then > I'm for that. The stagger problem is killing us keyboard players. > > My 2 1/2 cents. > |
From: Paul B. <pb...@mj...> - 2004-04-27 15:51:58
|
I haven't looked very closely at the film structure of A1/AM but I believe they are similar to Myth's. The Myth team has worked around the problem of breaking old film support by starting to store a version # in the film and when the film is played back we set a flag in a global variable so through out the game play code we check the flag. If the film file doesn't contain a version # then we just set the "old_version_flag". In pseudo code: if (game_play_flag & old_version_flag) {old code} else {new code} This as allowed us to keep support for old films while improving the end user experience and adding features. One does need to be careful about how the flags are used in the code and such. We have taken the approach that we support a old films of a certain version(which makes up the bulk of the films people have around) and then we support films made by the current version. If done right one could support several different versions films, we had some other issues which drove us to only support 2 versions. - Paul Bucher |
From: Br'fin <br...@ma...> - 2004-04-27 04:16:13
|
Seems I spoke too soon. Under AM the case does come up within two of M2's own demo films. As a result I had to regress the change there. Breaking M2 era vidfilms is simply unacceptable for the AM project. The problem of slow centering does show up in the debugger, but the person is moving enough that it isn't as noticeable. Also, as a workaround, as long as you explicitly hold down the _look_center key, then it moves at normal speed. As for A1... well, ancient vidmaster films were broken long ago I believe. AND the option of keyboard only play was removed from the Mac GUI. So the whole situation of whether or not I pop this change out is a lot more open to discussion. :/ -Jeremy Parsons http://alephmodular.sourceforge.net/ On Apr 26, 2004, at 10:51 PM, Br'fin wrote: > Valid question. > > I should check my vidmaster films for AM as it is a player behavior > change. > > On the flipside, this is an unusual case. It's a glitch that occurs > when trying to play keyboard only when the game has the mouse turned > on. > > In the original M2 code and AM, you're either going to be playing > keyboard only, or keyboard and mouse. If you're playing keyboard and > mouse, you probably don't have fingers anywhere near the Look Center > key. > > In the case of A1, keyboard only isn't an option in the GUI anymore. > It's always keyboard and mouse. Now most of you guys who are mousing > probably aren't going to run into this. But the existing behavior is > terrible for the non-mousers. > > I don't believe my fix will add to netsync or film playback problems. > > I certainly welcome auditing/double checking of the fix. > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ > > > On Apr 26, 2004, at 9:26 PM, Gregory Smith wrote: > >> Is this going to affect netgame sync? Film playback? >> >> Gregory |
From: Br'fin <br...@ma...> - 2004-04-27 03:11:15
|
Erk. I see I may need to double check something. The AM version of the patch broke at least the vidmaster demo of waterloo waterpark that came with M2. That won't do at all. Hmm. D'oh. -Jeremy On Apr 26, 2004, at 10:51 PM, Br'fin wrote: > Valid question. > > I should check my vidmaster films for AM as it is a player behavior > change. > > On the flipside, this is an unusual case. It's a glitch that occurs > when trying to play keyboard only when the game has the mouse turned > on. > > In the original M2 code and AM, you're either going to be playing > keyboard only, or keyboard and mouse. If you're playing keyboard and > mouse, you probably don't have fingers anywhere near the Look Center > key. > > In the case of A1, keyboard only isn't an option in the GUI anymore. > It's always keyboard and mouse. Now most of you guys who are mousing > probably aren't going to run into this. But the existing behavior is > terrible for the non-mousers. > > I don't believe my fix will add to netsync or film playback problems. > > I certainly welcome auditing/double checking of the fix. > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ > > > On Apr 26, 2004, at 9:26 PM, Gregory Smith wrote: > >> Is this going to affect netgame sync? Film playback? >> >> Gregory >> >> On Apr 26, 2004, at 6:14 PM, Br'fin wrote: >> >>>> Update of /cvs3/aleph/Source_Files/GameWorld >>>> >>>> Modified Files: >>>> physics.cpp >>>> Log Message: >>>> _absolute_pitch_mode is ignored if the _RECENTERING_BIT has been >>>> set (From someone hitting the _look_center key) >>>> This lets the _look_center_key work normally (It used to function >>>> fine in keyboard only mode, which A1 currently doesn't have) -Jeremy Parsons http://alephmodular.sourceforge.net/ |
From: Timothy C. <da...@ma...> - 2004-04-27 02:34:39
|
On Apr 26, 2004, at 6:06 PM, Jeremy Parsons wrote: > Modified Files: > physics.cpp > Log Message: > _absolute_pitch_mode is ignored if the _RECENTERING_BIT has been set > (From someone hitting the _look_center key) > This lets the _look_center_key work normally when keyboard and mouse > are active. > Good to see you're still working on it, Br'fin! The list has gone pretty dark lately...I'm glad it's not gone dead entirely. Timothy Collett "Time goes, you say? Ah, no! Time stays, _we_ go." --Austin Dobson |
From: Br'fin <br...@ma...> - 2004-03-25 10:13:26
|
Some further thoughts on this matter. A different approach perhaps. I came to the realization that the dependency of certain sets of classes should be a little more straightforward. For instance, it is typical in older Mac programs to do all of the Mac initialization in one place (All of the calls to init certain APIs, setting up more master pointers for handles and so forth.) And to some extent, AM had been leaning away from even something like that. So I figured I was missing something there. After some mulling when I was trying to get to sleep, I had thoughts of an arrangement like I was thinking of for the GUI hierarchies. CApplicationServices would contain all the low level stuff common to applications, such as platform specific initialization. At which point, the other class hierarchies could then refer to it in their own initialization with CApplicationServices::get_instance(); to ensure that the right dependencies occur. This would probably be important to some of the existing classes, such as the CDisplay and CFile ones. CApplicationServices could also manage everything CGUIBasic might have done anyways. At a higher level, you have CApplication as the underlying classes for AlephApplication. (AlephApplication would probably take the place of the existing AlephModular class and I think is better named.) AlephApplication would then be the owner of the event loops, and the top level modes the game enters (intro screens, main menu, chapter screens, playing) However, AlephApplication would then need to rely on CApplicationServices and the other classes for anything platform specific. It might be a bit much to have something like CApplication::instance = new AlephApplication_Carbon(). It certainly seems inappropriate to me. At the very least, having a nice generic class for dependancy purposes also helps cleanup a niggling issue with CFiles. Namely the existing CFile has to panic and issue a call to an application specific class (AlephModular) to report errors that occur when performing Safe Save File Swapping during the closing of a file stream when it must panic. The GUI of things like the preferences dialog and the other setup dialogs is probably still interesting and unique enough to be put into its own framework of AlephGUI classes. -Jeremy Parsons On Mar 14, 2004, at 8:09 AM, Br'fin wrote: > Expanding on the GUI stuff I mentioned before. I think it might be > better to have two class trees. > > One would be CGUIBasic. And the other would be AlephGUI. > > CGUIBasic would be responsible for low level GUI things and their > platform specific implementations. For instance, this is the class > that would handle alerts and simple OK/Cancel dialogs. It would also > initialize the platform specific GUI managers that aren't covered by > CDisplay. (As such it should be dependent on CDisplay) > > AlephGUI would be akin to the GUI class I mentioned previously. This > would be Application aware, and so it's probably better to have it in > its own class as a result. > > On Jan 8, 2004, at 10:35 AM, Br'fin wrote: > >> I've got a couple different threads winding their way through my mind >> currently. One being walling off the GUI from the base code. And the >> other being separating out main event loop, and input especially, >> from the game specific code. >> >> Now I know I need to actually inspect both issues to form a better >> plan. And I also need to decide on a focus. But I thought I'd lay out >> my thoughts now. >> >> >> GUI scenario: >> >> { setup options for gui element. This has in/out elements } >> GUIOptions{subclass} options(...) >> >> if(GUI::get_instance().{call appropriate gui element}(options)) >> { >> { do stuff on successful call } >> } >> >> Now a few notes. The GUI *is* Application aware. So we're going to >> see methods like: >> show_marathon_preferences >> show_save_game_dialog >> show_save_replay_dialog >> show_do_you_want_to_quit >> >> They key thing that the GUI class would be doing is putting a hard >> wall between the basic Marathon code and the dialogs. I admit this >> doesn't make it easy to share code between different platforms ways >> of handling dialogs, but this isn't meant to do that. It's not meant >> to be wxwindows or anything. It is simply to isolate where Marathon >> asks for GUI elements and keeps them clear and defined. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
From: Br'fin <br...@ma...> - 2004-03-14 13:09:00
|
Expanding on the GUI stuff I mentioned before. I think it might be better to have two class trees. One would be CGUIBasic. And the other would be AlephGUI. CGUIBasic would be responsible for low level GUI things and their platform specific implementations. For instance, this is the class that would handle alerts and simple OK/Cancel dialogs. It would also initialize the platform specific GUI managers that aren't covered by CDisplay. (As such it should be dependent on CDisplay) AlephGUI would be akin to the GUI class I mentioned previously. This would be Application aware, and so it's probably better to have it in its own class as a result. On Jan 8, 2004, at 10:35 AM, Br'fin wrote: > I've got a couple different threads winding their way through my mind > currently. One being walling off the GUI from the base code. And the > other being separating out main event loop, and input especially, from > the game specific code. > > Now I know I need to actually inspect both issues to form a better > plan. And I also need to decide on a focus. But I thought I'd lay out > my thoughts now. > > > GUI scenario: > > { setup options for gui element. This has in/out elements } > GUIOptions{subclass} options(...) > > if(GUI::get_instance().{call appropriate gui element}(options)) > { > { do stuff on successful call } > } > > Now a few notes. The GUI *is* Application aware. So we're going to see > methods like: > show_marathon_preferences > show_save_game_dialog > show_save_replay_dialog > show_do_you_want_to_quit > > They key thing that the GUI class would be doing is putting a hard > wall between the basic Marathon code and the dialogs. I admit this > doesn't make it easy to share code between different platforms ways of > handling dialogs, but this isn't meant to do that. It's not meant to > be wxwindows or anything. It is simply to isolate where Marathon asks > for GUI elements and keeps them clear and defined. |
From: Br'fin <br...@ma...> - 2004-01-08 15:35:08
|
I've got a couple different threads winding their way through my mind currently. One being walling off the GUI from the base code. And the other being separating out main event loop, and input especially, from the game specific code. Now I know I need to actually inspect both issues to form a better plan. And I also need to decide on a focus. But I thought I'd lay out my thoughts now. GUI scenario: { setup options for gui element. This has in/out elements } GUIOptions{subclass} options(...) if(GUI::get_instance().{call appropriate gui element}(options)) { { do stuff on successful call } } Now a few notes. The GUI *is* Application aware. So we're going to see methods like: show_marathon_preferences show_save_game_dialog show_save_replay_dialog show_do_you_want_to_quit They key thing that the GUI class would be doing is putting a hard wall between the basic Marathon code and the dialogs. I admit this doesn't make it easy to share code between different platforms ways of handling dialogs, but this isn't meant to do that. It's not meant to be wxwindows or anything. It is simply to isolate where Marathon asks for GUI elements and keeps them clear and defined. The other area of contention is handling the main event loop and input. This is tricky, for a number of reasons. * Much reliance on a MacOS Classic style WaitNextEvent loop (with extensions) * VBL Input thread that polls and processes input and stores in replays * Unclear view of networking and how they interact with input polling * AppleEvent instigated file selections * command key equivalents handled through menu code * MacOSX Input polling doesn't like the VBL thread at times (faulty mouse tracking, sometimes not watching keyboard) * New System should be tight, concise, and lightweight This will probably also require some new threads and some new interactions. For instance, trying to push updates and especially screen rendering away from the main event thread. (Thus letting event processing go fast, with only world and viewport updates taking typically longer) I need to do some more thinking and planning on this, but I believe there's going to be a thread added and denoted as 'main input and gui thread.' And I guess the GUI is going to have to be aware of it, so it can halt a thread, ask the main input thread to process the gui, and then pass the results back to the appropriate thread. Mmm, I definitely need to sit down and do some more planning/thinking here. I have trouble wrapping my head around threads at times :) -Jeremy Parsons |
From: Br'fin <br...@ma...> - 2003-12-26 17:21:05
|
OoooooKay.... I go to look specifically at this problem of pref-development compiles failing under under the PB Compatible target and what happens? Everything works just fine. *grumble*grumble* No real rhyme or reason to me, but now I can't duplicate it. Go figure. I'm relaxing today, and busy this weekend. I'll probably see about merging the pref-development branch into the trunk next week. -Jeremy Parsons On Dec 26, 2003, at 11:19 AM, Br'fin wrote: > There are two gotchas in the Preferences right now (Three if you count > the new requirement of installing expat before compiling, but that's a > necessity.) > > The plist parser is simple and maybe not as robust as I want it to be. > However it works and this could slide. > > The templated get_value method on CPreferencesValue with variable > specific instantiations causes an odd error under GCC 3.1 (The default > compiler for use with PB 2.0.) It compiles and runs fine under XCode > (and GCC 3.3.) This concerns me, though I'm not sure just how much I > should be concerned. If it's tricky for an earlier version of GCC > might this be tricky for other compiler families? Do we still wish to > support PB 2.0? I am currently inclined to look into fixing this. > > -Jeremy Parsons |
From: Br'fin <br...@ma...> - 2003-12-26 16:19:36
|
There are two gotchas in the Preferences right now (Three if you count the new requirement of installing expat before compiling, but that's a necessity.) The plist parser is simple and maybe not as robust as I want it to be. However it works and this could slide. The templated get_value method on CPreferencesValue with variable specific instantiations causes an odd error under GCC 3.1 (The default compiler for use with PB 2.0.) It compiles and runs fine under XCode (and GCC 3.3.) This concerns me, though I'm not sure just how much I should be concerned. If it's tricky for an earlier version of GCC might this be tricky for other compiler families? Do we still wish to support PB 2.0? I am currently inclined to look into fixing this. -Jeremy Parsons |
From: Br'fin <br...@ma...> - 2003-12-25 03:29:50
|
I've just committed on the prefs-development branch a new Reader/Writer pair for Plist based preferences. The Reader uses expat to handle the xml, and uses code derived from A1's XML_Configure by Loren to glue expat to C++. In order to compile this branch, one must install expat. Instructions for doing so are found in alephModular/documents/technical/README_MacOSX.txt. The preference changes are not yet landed in the main trunk just yet. There's some cleanup to be done in the form of removing the wad writer, and making sure I can round-trip between the preferences file and Apple's PList editor. (I think my base64 decoder needs work so that it properly handles/ignores whitespace in the encoded string.) Also, while the plist reader works, it is verrry simple minded. (It's a very simple state based machine. On one hand it's not going to handle all the complexities a plist file could have, on the other hand, AM is pretty simple minded in the use of the format. Using a subset of the features to begin with.) I'm not sure I'm happy with it beyond saying that it works in a well defined case. In other words, the reader is probably as quick and dirty as things come :/ At any rate, happy holidays to all, and I'll try to get this tidied up and merged back into the trunk soon. -Jeremy Parsons |
From: Br'fin <br...@ma...> - 2003-12-20 04:27:06
|
For some reason, after this message I had a certain amount of epiphany. Maybe I am just waving my hands about too much when I should simply make/make install. Sigh :) -Jeremy Parsons On Dec 18, 2003, at 12:19 PM, Br'fin wrote: > I woudn't mind a brief repetition. I do lose track of these and it > adds to my clarity. > > I *think* I recall you, Aaron, preferring the notion of > > ./configure > make > make install > > Which defaults typically to /usr/lib. > > Whereas my current thinking is: > ./configure --prefix=/Library/Development/<Package>/<package>-<package > version> > make > make install > > I think /usr/lib is not Macish, a soup, and prone to complete toasting > in the case of Archive and Install. Yes it's the Unix way. Yes it > seems good for some of your A1 cross-compile too. (I do wish people > would give more feedback on this issue under A1 too, alas.) On another > note, some unix-side things do prefer/recommend versioned directories. > For instance, large applications such as Oracle recommend installing > different versions in different directories and not just a new one > atop of an old one. > > I admit my choices in the /Library directory do not feel perfect. But > they do put things in a stable location that would be commonly usable. > A bit more visible. And less prone to mixing up different library > versions. |
From: Br'fin <br...@ma...> - 2003-12-18 17:19:21
|
I woudn't mind a brief repetition. I do lose track of these and it adds to my clarity. I *think* I recall you, Aaron, preferring the notion of ./configure make make install Which defaults typically to /usr/lib. Whereas my current thinking is: ./configure --prefix=/Library/Development/<Package>/<package>-<package version> make make install I think /usr/lib is not Macish, a soup, and prone to complete toasting in the case of Archive and Install. Yes it's the Unix way. Yes it seems good for some of your A1 cross-compile too. (I do wish people would give more feedback on this issue under A1 too, alas.) On another note, some unix-side things do prefer/recommend versioned directories. For instance, large applications such as Oracle recommend installing different versions in different directories and not just a new one atop of an old one. I admit my choices in the /Library directory do not feel perfect. But they do put things in a stable location that would be commonly usable. A bit more visible. And less prone to mixing up different library versions. -Jeremy Parsons On Dec 18, 2003, at 10:43 AM, Aaron Davies wrote: > Well, you already know my thoughts on the subject, so I won't bother > repeating them. > > On Wednesday, December 17, 2003, at 01:09 PM, Br'fin wrote: > >> I await other people's thoughts and comments on where the recommended >> place to setup libraries for usage should be. In the meantime, I will >> probably begin work on CPreferencesWriter_Plist which wouldn't need >> the library. >> >> -Jeremy Parsons >> |
From: Aaron D. <ag...@co...> - 2003-12-18 15:43:40
|
Well, you already know my thoughts on the subject, so I won't bother repeating them. On Wednesday, December 17, 2003, at 01:09 PM, Br'fin wrote: > I await other people's thoughts and comments on where the recommended > place to setup libraries for usage should be. In the meantime, I will > probably begin work on CPreferencesWriter_Plist which wouldn't need > the library. > > -Jeremy Parsons > > On Dec 16, 2003, at 1:16 PM, Br'fin wrote: > >> >> On Dec 16, 2003, at 9:33 AM, Timothy Collett wrote: >> >>> On Dec 16, 2003, at 7:15 AM, Br'fin wrote: >>> >>>> *mutter mutter grumble* >>>> >>>> It would figure that autoconf's tools don't like Application >>>> Support. Even when you do something like: >>>> ./configure --prefix='"/Library/Application >>>> Support/Expat/expat-1.95.7/"' >>>> >>>> On the other hand, I do agree that Application Support itself was >>>> never quite right. /Library/Libraries seems a little redundant. So >>>> how about /Library/Development? >>>> >>> >>> #1: did you try ./configure --prefix=/Library/Application\ >>> Support/Expat/expat-1.95.7/ ? >> >> That only gets the prefix past the initial command line. It then gets >> dropped into scripts relatively unescaped and certainly unquoted. So >> you get past the initial step to have the setup still falter and >> miswork. >> >>> #2: Since expat's so small, why not just make it part of AM? That >>> means 1 less thing that people have to have installed to run it, >>> which makes people more likely to want to install it--less hassle >>> for those who don't understand libraries and Unixland and such. >> >> My plan with expat is to link it in statically. Thus there's nothing >> for the end-user to install. I whole heartedly agree that the user >> shouldn't have to look for other libraris to install first before >> they run the application >> >> All this business with /Library/Development or /Library/Application >> Support is specifically for the AM developers. Specifically, I'm >> applying what I did to standardize the location of Lua and Speex >> libraries under OSX for AlephOne to what I'm doing here for >> AlephModular. I'm also trying to get consensus, and smooth out >> wrinkles. >> >> -Jeremy Parsons >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IBM Linux Tutorials. >> Become an expert in LINUX or just sharpen your skills. Sign up for >> IBM's >> Free Linux Tutorials. Learn everything from the bash shell to sys >> admin. >> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >> _______________________________________________ >> Alephmodular-devel mailing list >> Ale...@li... >> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for > IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys > admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > > -- __ __ / ) / ) /--/ __. __ ________ / / __. , __o _ _ / (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_ |
From: Br'fin <br...@ma...> - 2003-12-17 18:09:23
|
I await other people's thoughts and comments on where the recommended place to setup libraries for usage should be. In the meantime, I will probably begin work on CPreferencesWriter_Plist which wouldn't need the library. -Jeremy Parsons On Dec 16, 2003, at 1:16 PM, Br'fin wrote: > > On Dec 16, 2003, at 9:33 AM, Timothy Collett wrote: > >> On Dec 16, 2003, at 7:15 AM, Br'fin wrote: >> >>> *mutter mutter grumble* >>> >>> It would figure that autoconf's tools don't like Application >>> Support. Even when you do something like: >>> ./configure --prefix='"/Library/Application >>> Support/Expat/expat-1.95.7/"' >>> >>> On the other hand, I do agree that Application Support itself was >>> never quite right. /Library/Libraries seems a little redundant. So >>> how about /Library/Development? >>> >> >> #1: did you try ./configure --prefix=/Library/Application\ >> Support/Expat/expat-1.95.7/ ? > > That only gets the prefix past the initial command line. It then gets > dropped into scripts relatively unescaped and certainly unquoted. So > you get past the initial step to have the setup still falter and > miswork. > >> #2: Since expat's so small, why not just make it part of AM? That >> means 1 less thing that people have to have installed to run it, >> which makes people more likely to want to install it--less hassle for >> those who don't understand libraries and Unixland and such. > > My plan with expat is to link it in statically. Thus there's nothing > for the end-user to install. I whole heartedly agree that the user > shouldn't have to look for other libraris to install first before they > run the application > > All this business with /Library/Development or /Library/Application > Support is specifically for the AM developers. Specifically, I'm > applying what I did to standardize the location of Lua and Speex > libraries under OSX for AlephOne to what I'm doing here for > AlephModular. I'm also trying to get consensus, and smooth out > wrinkles. > > -Jeremy Parsons > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for > IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys > admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
From: Br'fin <br...@ma...> - 2003-12-16 18:16:02
|
On Dec 16, 2003, at 9:33 AM, Timothy Collett wrote: > On Dec 16, 2003, at 7:15 AM, Br'fin wrote: > >> *mutter mutter grumble* >> >> It would figure that autoconf's tools don't like Application Support. >> Even when you do something like: >> ./configure --prefix='"/Library/Application >> Support/Expat/expat-1.95.7/"' >> >> On the other hand, I do agree that Application Support itself was >> never quite right. /Library/Libraries seems a little redundant. So >> how about /Library/Development? >> > > #1: did you try ./configure --prefix=/Library/Application\ > Support/Expat/expat-1.95.7/ ? That only gets the prefix past the initial command line. It then gets dropped into scripts relatively unescaped and certainly unquoted. So you get past the initial step to have the setup still falter and miswork. > #2: Since expat's so small, why not just make it part of AM? That > means 1 less thing that people have to have installed to run it, which > makes people more likely to want to install it--less hassle for those > who don't understand libraries and Unixland and such. My plan with expat is to link it in statically. Thus there's nothing for the end-user to install. I whole heartedly agree that the user shouldn't have to look for other libraris to install first before they run the application All this business with /Library/Development or /Library/Application Support is specifically for the AM developers. Specifically, I'm applying what I did to standardize the location of Lua and Speex libraries under OSX for AlephOne to what I'm doing here for AlephModular. I'm also trying to get consensus, and smooth out wrinkles. -Jeremy Parsons |
From: Timothy C. <da...@ma...> - 2003-12-16 14:34:13
|
On Dec 16, 2003, at 7:15 AM, Br'fin wrote: > *mutter mutter grumble* > > It would figure that autoconf's tools don't like Application Support. > Even when you do something like: > ./configure --prefix='"/Library/Application > Support/Expat/expat-1.95.7/"' > > On the other hand, I do agree that Application Support itself was > never quite right. /Library/Libraries seems a little redundant. So how > about /Library/Development? > #1: did you try ./configure --prefix=/Library/Application\ Support/Expat/expat-1.95.7/ ? #2: Since expat's so small, why not just make it part of AM? That means 1 less thing that people have to have installed to run it, which makes people more likely to want to install it--less hassle for those who don't understand libraries and Unixland and such. Just some thoughts. Timothy Collett "You must be the change you wish to see in the world" --Mahatma Gandhi |