alephmodular-devel Mailing List for AlephModular (Page 5)
Status: Pre-Alpha
Brought to you by:
brefin
Menu
▾
▴
alephmodular-devel — AlephModular Developers Mailing List
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: Gregory S. <wo...@tr...> - 2003-10-23 23:27:56
|
Heheh, wow that was inflammatory. Teaches me to post from work. I'll roll a 1d20 for my compile penalty On Thursday, October 23, 2003, at 05:29 PM, Br'fin wrote: > My own suspicion is that if we branch the project file in CVS. Then we > can do cvs joins from trunk (XCode) to branch (PB-2_0) to copy over > file additions/minor compiler tweaks while leaving the majority of the > file intact for each build system. > > Look on the bright side, as convoluted as it is, the file is still a > mergable text file and not something woefully binary which would > require by hand tweaks for each IDE. > > And I give you a 1 compile penalty for inflammatory comments :) (I > suppose I'd not mind chatting about it in IM, just doesn't seem the > place here on the lists.) > > -Jeremy Parsons > > On Thursday, October 23, 2003, at 10:24 AM, wo...@tr... wrote: > >> Ugh. Would it be possible to make a script that takes a file >> containing the locations of sources, headers, libraries, and creates >> the >> correct respective PBProject file for? This is twice now Apple has >> capriciously changed the project file format so that old versions >> can't >> build new projects. I guess it's too much to ask for a little >> forethought >> when designing a file format that is essentially a glorified >> makefile, so >> instead the developers have to deal with it each year. >> /me crawls back to his cozy GNU cave where they figured out how to >> do it right long ago >> >> Gregory > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Marathon-devel mailing list > Mar...@li... > https://lists.sourceforge.net/lists/listinfo/marathon-devel |
|
From: Alexander S. <ast...@it...> - 2003-10-23 23:23:59
|
On Oct 23, 2003, at 10:24 AM, wo...@tr... wrote: > Ugh. Would it be possible to make a script that takes a file > containing the locations of sources, headers, libraries, and creates > the > correct respective PBProject file for? This is twice now Apple has > capriciously changed the project file format so that old versions can't > build new projects. I guess it's too much to ask for a little > forethought > when designing a file format that is essentially a glorified makefile, > so > instead the developers have to deal with it each year. > /me crawls back to his cozy GNU cave where they figured out how to > do it right long ago > > Gregory You can open newer projects with an old PB, it just spits up errors and causes unnecessary commit noise. |
|
From: Br'fin <br...@ma...> - 2003-10-23 21:36:46
|
My own suspicion is that if we branch the project file in CVS. Then we can do cvs joins from trunk (XCode) to branch (PB-2_0) to copy over file additions/minor compiler tweaks while leaving the majority of the file intact for each build system. Look on the bright side, as convoluted as it is, the file is still a mergable text file and not something woefully binary which would require by hand tweaks for each IDE. And I give you a 1 compile penalty for inflammatory comments :) (I suppose I'd not mind chatting about it in IM, just doesn't seem the place here on the lists.) -Jeremy Parsons On Thursday, October 23, 2003, at 10:24 AM, wo...@tr... wrote: > Ugh. Would it be possible to make a script that takes a file > containing the locations of sources, headers, libraries, and creates > the > correct respective PBProject file for? This is twice now Apple has > capriciously changed the project file format so that old versions can't > build new projects. I guess it's too much to ask for a little > forethought > when designing a file format that is essentially a glorified makefile, > so > instead the developers have to deal with it each year. > /me crawls back to his cozy GNU cave where they figured out how to > do it right long ago > > Gregory |
|
From: <wo...@tr...> - 2003-10-23 18:57:55
|
Ugh. Would it be possible to make a script that takes a file containing the locations of sources, headers, libraries, and creates the correct respective PBProject file for? This is twice now Apple has capriciously changed the project file format so that old versions can't build new projects. I guess it's too much to ask for a little forethought when designing a file format that is essentially a glorified makefile, so instead the developers have to deal with it each year. /me crawls back to his cozy GNU cave where they figured out how to do it right long ago Gregory On Thu, 23 Oct 2003, Alexander Strange wrote: > > On Oct 22, 2003, at 2:50 AM, Br'fin wrote: > > > With the release of Panther real soon now, I expect myself and those > > developers who haven't already upgraded to pick up the new OS and use > > new development tools. > > > > At this point we will be updating our compiler tools from > > ProjectBuilder to XCode. Alexander can correct me, but I presume it > > uses an updated version of the .pbproj's that we use. If so, the most > > likely outcome is that the PBProject files will be branched with a > > PB-2_0 tag on the last version of the project file that supports > > ProjectBuilder and then the file will be updated for XCode along the > > main trunk. > > > > Yes, XCode upgrades the Project Builder project; I've been holding off > on commiting it so as not to break all of yours. > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > Marathon-devel mailing list > Mar...@li... > https://lists.sourceforge.net/lists/listinfo/marathon-devel > |
|
From: Alexander S. <ast...@it...> - 2003-10-23 13:54:28
|
On Oct 22, 2003, at 2:50 AM, Br'fin wrote: > With the release of Panther real soon now, I expect myself and those > developers who haven't already upgraded to pick up the new OS and use > new development tools. > > At this point we will be updating our compiler tools from > ProjectBuilder to XCode. Alexander can correct me, but I presume it > uses an updated version of the .pbproj's that we use. If so, the most > likely outcome is that the PBProject files will be branched with a > PB-2_0 tag on the last version of the project file that supports > ProjectBuilder and then the file will be updated for XCode along the > main trunk. > Yes, XCode upgrades the Project Builder project; I've been holding off on commiting it so as not to break all of yours. |
|
From: Br'fin <br...@ma...> - 2003-10-23 04:17:38
|
With the release of Panther real soon now, I expect myself and those developers who haven't already upgraded to pick up the new OS and use new development tools. At this point we will be updating our compiler tools from ProjectBuilder to XCode. Alexander can correct me, but I presume it uses an updated version of the .pbproj's that we use. If so, the most likely outcome is that the PBProject files will be branched with a PB-2_0 tag on the last version of the project file that supports ProjectBuilder and then the file will be updated for XCode along the main trunk. I admit I'm still marshaling my funds so may not update immediately. But I'd like to make sure we're all on the same page on this issue. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2003-10-22 22:37:09
|
I've begun trying to work up a CSoundManager to abstract sound handling. All it does right now is remember the original volume at program start and then restore it at exit. One nicety is that it is trying to use some of the CoreAudio stuff to do it without the issues I was having with Get/SetDefaultOutputVolume in the Carbon APIs. So I tried to play with a variant of this CoreAudio stuff under A1 to fix the problem there. Worked well, except that right at the end, where it restores the volume just fine in AM... A1 ends up unable to find the default output device anymore and fails to reset the volume at all. Bwah. I have no idea what in A1 might be getting shutdown earlier and this makes me worried about why it works in AM and if/when it might stop working in the same. Sigh. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-10-18 22:12:17
|
On Saturday, October 18, 2003, at 04:26 AM, Br'fin wrote: > I've been trying to re sort out finding files so that it too works > with an external view of CFileDescs. And I just bumped up against one > of my other earlier partial treatments. I've made progress, installed a CFileTypeLookup facility... give it a file and it will try out what it knows to link a filetype with an existing file. I'm sure there's some improvements that could be made around how CFileTypes are passed around internally... ah well... Anyhow, once I clean this up and check it in, there will be a few less uses of FSSpec. I should be getting down to the point where the remaining usages tie to unmodified systems... for instance the preferences file format or gui dialogs. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-10-18 08:33:02
|
I've been trying to re sort out finding files so that it too works with an external view of CFileDescs. And I just bumped up against one of my other earlier partial treatments. There's this big setup of CFileType classes. Things like: CMarathon2MapFileType, CMarathon2ReplayFileType, and CAlephModularPreferencesFileType. And this lets you specify a file is one type or another. But no facility has been setup to go the other way... from a known file, jump to the right kind of filetype. I had setup provisions for testing types versus files, but never got around to setting up the host system, the one that would let you say ... uh I have this file, what type is it? D'oh. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-10-16 06:27:53
|
On Thursday, October 16, 2003, at 01:46 AM, Aaron Davies wrote: >> However, for basic usage, I don't think you need to configure >> anything? (Or else configuring isn't fully hooked up to everything >> either) > > I believe autoconf is called during autogen.sh. > >> What's in CVS includes a few .in files and then has the expanded >> versions of those files. For instance >> AlephModular.pbproj/project.pbxproj and >> AlephModular.pbproj/project.pbxproj.in > > Yes, PB compilation works fine, but I was trying to get unix-style > compilation going. I guess it doesn't really matter at this point, but > once the cross-platform support appears, AM will need to be able to be > able to be compiled on Linux or Windows/cygwin. > >> For better or for worse, command line compilation of AM has never >> been setup or really explored. >> >> Alexander should have a better answer, I'm just trying to figure out >> what's going on :) I agree with that. I admit I have no clue how to use autogen and kin to actually setup the situation though. (My only impression of what's currently been setup is 'ewww, too many excess files dumped into the directory tree.' And that certainly doesn't consider how many may or may not be necessary. Sigh.) :/ -Jeremy Parsons |
|
From: Aaron D. <ag...@co...> - 2003-10-16 05:49:21
|
On Wednesday, October 15, 2003, at 09:33 PM, Br'fin wrote:
> Hrm, my own luck with doing:
> cd alephModular
> sh build/unix/autogen.sh
>
> Was fine. Then again I never touched any of my autoconf stuff... it's
> still the stock tools from whatever Apple Developer release it was
>
>> [delirious:~/Source/AM/alephModular] brefin% autoconf --version
>> autoconf (GNU Autoconf) 2.52
>
> However, for basic usage, I don't think you need to configure
> anything? (Or else configuring isn't fully hooked up to everything
> either)
I believe autoconf is called during autogen.sh.
> What's in CVS includes a few .in files and then has the expanded
> versions of those files. For instance
> AlephModular.pbproj/project.pbxproj and
> AlephModular.pbproj/project.pbxproj.in
Yes, PB compilation works fine, but I was trying to get unix-style
compilation going. I guess it doesn't really matter at this point, but
once the cross-platform support appears, AM will need to be able to be
able to be compiled on Linux or Windows/cygwin.
> For better or for worse, command line compilation of AM has never been
> setup or really explored.
>
> Alexander should have a better answer, I'm just trying to figure out
> what's going on :)
--
__ __
/ ) / )
/--/ __. __ ________ / / __. , __o _ _
/ (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_
|
|
From: Alexander S. <ast...@it...> - 2003-10-16 03:58:27
|
On Oct 15, 2003, at 9:21 PM, Br'fin wrote: > > On Wednesday, October 15, 2003, at 04:53 PM, Alexander Strange wrote: > >> >> On Oct 15, 2003, at 10:21 AM, Br'fin wrote: >> >>> I found this link over on MacOS X Hints. So I poked into it, tried >>> running it over AlephModular and also over AlephOne. I could still >>> do with touching up the relevant defines, but it seems to grok their >>> structure well. >>> >>> Would/Could something like this be useful and would anyone ever >>> getting around to updating the documenting tags to make such a thing >>> even more useful? >>> >>> -Jeremy Parsons >>> http://alephmodular.sourceforge.net/ >> >> I would prefer to use Apple's HeaderDoc. I really don't know why >> anyone would write an OS X Hint about doxygen when Apple has a >> solution that comes with the system. > > I honestly have/had no idea myself. So to me doxygen appeared 'cool'. > The other detail with doxygen is that it doesn't seem to be MacOS > X/Apple only. In a documenting tool I don't know how crucial being > able to generate them on multiple platforms is. > > -Jeremy HeaderDoc is also opensource and written entirely in Perl. |
|
From: Br'fin <br...@ma...> - 2003-10-16 01:35:18
|
Hrm, my own luck with doing: cd alephModular sh build/unix/autogen.sh Was fine. Then again I never touched any of my autoconf stuff... it's still the stock tools from whatever Apple Developer release it was > [delirious:~/Source/AM/alephModular] brefin% autoconf --version > autoconf (GNU Autoconf) 2.52 However, for basic usage, I don't think you need to configure anything? (Or else configuring isn't fully hooked up to everything either) What's in CVS includes a few .in files and then has the expanded versions of those files. For instance AlephModular.pbproj/project.pbxproj and AlephModular.pbproj/project.pbxproj.in For better or for worse, command line compilation of AM has never been setup or really explored. Alexander should have a better answer, I'm just trying to figure out what's going on :) -Jeremy |
|
From: Br'fin <br...@ma...> - 2003-10-16 01:20:57
|
On Wednesday, October 15, 2003, at 04:53 PM, Alexander Strange wrote: > > On Oct 15, 2003, at 10:21 AM, Br'fin wrote: > >> I found this link over on MacOS X Hints. So I poked into it, tried >> running it over AlephModular and also over AlephOne. I could still do >> with touching up the relevant defines, but it seems to grok their >> structure well. >> >> Would/Could something like this be useful and would anyone ever >> getting around to updating the documenting tags to make such a thing >> even more useful? >> >> -Jeremy Parsons >> http://alephmodular.sourceforge.net/ > > I would prefer to use Apple's HeaderDoc. I really don't know why > anyone would write an OS X Hint about doxygen when Apple has a > solution that comes with the system. I honestly have/had no idea myself. So to me doxygen appeared 'cool'. The other detail with doxygen is that it doesn't seem to be MacOS X/Apple only. In a documenting tool I don't know how crucial being able to generate them on multiple platforms is. -Jeremy |
|
From: Alexander S. <ast...@it...> - 2003-10-15 20:53:56
|
On Oct 15, 2003, at 10:21 AM, Br'fin wrote: > I found this link over on MacOS X Hints. So I poked into it, tried > running it over AlephModular and also over AlephOne. I could still do > with touching up the relevant defines, but it seems to grok their > structure well. > > Would/Could something like this be useful and would anyone ever > getting around to updating the documenting tags to make such a thing > even more useful? > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ I would prefer to use Apple's HeaderDoc. I really don't know why anyone would write an OS X Hint about doxygen when Apple has a solution that comes with the system. |
|
From: Aaron D. <ag...@co...> - 2003-10-15 19:33:59
|
I'm trying to build AM from a fresh CVS checkout, but I'm getting a lot
of errors when I run build/unix/autogen.sh. First of all, autogen.sh
comes out of CVS with mode 644, and it should be 755, but that's
trivial. More importantly, the output below occurs when I run it. When
I got these errors working on A1/SDL, it was generally an issue with my
auto* versions, but I have the latest fink versions installed: automake
1.6.3, autoconf 2.5.7, and autogen 5.4.2. Anybody know what's wrong
here?
cp: omitting directory `build/unix/CVS'
+ Running aclocal: aclocal: configure.ac: 79: macro `AM_PROG_LIBTOOL'
not found in library
done.
+ Running libtoolize: done.
+ Running autoheader: autoheader: error: AC_CONFIG_HEADERS not found
in configure.ac
done.
+ Running automake: configure.ac:31: no proper implementation of
AM_INIT_AUTOMAKE was found,
configure.ac:31: probably because aclocal.m4 is missing...
configure.ac:31: You should run aclocal to create this file, then
configure.ac:31: run automake again.
configure.ac: installing `./install-sh'
configure.ac: installing `./mkinstalldirs'
configure.ac: installing `./missing'
configure.ac:5: required file `./config.h.in' not found
marathon2/CSeries/Makefile.am: installing `./depcomp'
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/depend2.am: AMDEP does not appear in
AM_CONDITIONAL
/sw/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in
AM_CONDITIONAL
done.
+ Running autoconf: configure.ac:5: error: possibly undefined macro:
AM_CONFIG_HEADER
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.ac:31: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.ac:79: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:105: error: possibly undefined macro: AC_TRY_CFLAGS
configure.ac:127: error: possibly undefined macro: AM_WITH_CARBON
done.
--
__ __
/ ) / )
/--/ __. __ ________ / / __. , __o _ _
/ (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_
|
|
From: Br'fin <br...@ma...> - 2003-10-15 16:21:34
|
On Wednesday, October 15, 2003, at 12:08 PM, Timothy Collett wrote: > Well, I don't know if it's because of anything you did, Br'fin, but I > just ran cvs update -AdP on my AM folder, and it got the new files. I > built it with PB, and it runs great. Restoring from save after dying > works, now, too! ;-) That's great to hear. I guess we'll just have to live with it for now that the public cvs may be delayed. Though I admit I didn't expect any kind of delay like this, ah well. > So, as before, is there anything you want me to test about it? > > Timothy Collett I can't think of anything beyond putting it through it's paces, or just as you've been doing, playing it and seeing if/where anything breaks down. Thank you for the bug report as it was and it really was a d'oh on my part :) -Jeremy Parsons |
|
From: Timothy C. <da...@ma...> - 2003-10-15 16:08:24
|
Well, I don't know if it's because of anything you did, Br'fin, but I just ran cvs update -AdP on my AM folder, and it got the new files. I built it with PB, and it runs great. Restoring from save after dying works, now, too! ;-) So, as before, is there anything you want me to test about it? Timothy Collett With searching comes loss and the presence of absence: "My Program" not found. ~haiku~ |
|
From: Br'fin <br...@ma...> - 2003-10-15 14:21:06
|
I found this link over on MacOS X Hints. So I poked into it, tried running it over AlephModular and also over AlephOne. I could still do with touching up the relevant defines, but it seems to grok their structure well. Would/Could something like this be useful and would anyone ever getting around to updating the documenting tags to make such a thing even more useful? -Jeremy Parsons http://alephmodular.sourceforge.net/ Begin forwarded message: > Automatically document code (C++, PHP,...) with Doxygen > Tue, Oct 14 '03 at 10:16AM > from: Nimitz > > As a php coder, I'm sometimes overwhelmed by the sheer volume of code > I'm writing. Then I stumbled on Doxygen, a documentation generator > which reads your code and generates standard documentation pages about > it. Aside from HTML, you can also generate LaTex, RTF, Postscript, > Hyperlinked PDF's and Unix man pages. There's a Mac OS X version > available if you don't like to compile it yourself. > How does it work? Doxygen runs from the prompt and reads a > configuration file you have to prepare (once). The generated ouput is > then ready to use. Of course, if you extend your comments in your > code with the doxygen tags (like: author, version, to-do, etc.), your > output will become more useful, as doxygen does cross-referencing and > the works! > > ------------------------------------------------------------ > Comment on this story at > http://www.macosxhints.com/article.php?story=20031011120515689#comments > |
|
From: Br'fin <br...@ma...> - 2003-10-14 19:55:05
|
I've been trying to beat back the use of FSSpecs in AM in all the
places which used them instead of M2's original filedesc.
Right now my biggest tussle is the mechanism used to find files. This
consists of a find_file_pb structure with input and output arguments.
While it can have a buffer of FSSpec returned to the caller of the
associated find_files, the most typical usage skips the buffer, skips
the option for alphabetical sorting, and instead goes with a callback.
The callback takes in a found FSSpec and either a user provided data
structure (rare/never), or a pointer to the associated MacOS specific
catinfo param block of found info. I believe we can get around the
catinfo information with the other info that one can request off of a
CFileDesc.
I'm thinking of making the find_file_pb into a CFindFileParam, though,
for the find operation itself, I'm thinking of pushing that through the
CFileDescFactory (Even if it's an inner-system thing... like
CFindFileParam->find() { CFileDesc_Factory::get_instance.find(*this); }
I'm probably ditching the buffer of answers options (and related flags)
as well as the catinfo option (items that should be known by the
CFileDesc... less optimal perhaps, ah well)
And I'm debating on keeping the callbacks or going with an iterator...
that the calling function can use to call appropriate functions (same
functions, but no longer handled as callbacks...)
-Jeremy Parsons
|
|
From: Jamie W. <jam...@bl...> - 2003-10-12 19:12:06
|
On Sunday, Oct 12, 2003, at 17:31 Europe/London, Br'fin wrote: > (It isn't according to this: > http://developer.apple.com/documentation/Performance/Conceptual/ > Performance/VirtualMemory/Allocating__eing_Memory.html) > Which should read: > (It isn't according to this: > http://developer.apple.com/documentation/Performance/Conceptual/ > Performance/VirtualMemory/Allocating__eing_Memory.html ) > Note the space between the close bracket and the link... Mail.app mangled it for me! :-( . Hope this helps! Jamie |
|
From: Br'fin <br...@ma...> - 2003-10-12 16:31:34
|
I was working through shapes_macintosh.cpp, driving the eeevil FSSpec from it when I ended up debating a tangent. Shapes (And sounds) use variants of a function that essentially allocate a Handle and read a section of data into it. (It's almost a wonder to me that there wasn't a short entry in something like the CSeries for such a function and let it be used multiple places...) At any rate, I got into poking through some resources online to see if it was worth holding onto the Handles at all on the MacOS X side of things. (It isn't according to this: http://developer.apple.com/documentation/Performance/Conceptual/ Performance/VirtualMemory/Allocating__eing_Memory.html) And as a further sidetrack I got into wondering if we wanted to support memory mapping for large files. (shapes, sounds, maps) Where OSX/BSD and presumably linux have mmap and Windows (later versions) has its own method. Though I realize that the memory mapping variation may need to support a fallback method. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-10-11 06:29:25
|
D'oh Noticed that file handling is a bit far from complete. I dealt with the areas covered by portable_files.h and file_desc... but that still leaves a lot of areas tossing around mac style FSSpec's.... D'oh! -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-10-09 20:50:12
|
On Wednesday, October 8, 2003, at 04:21 PM, Matt Lee wrote: >> It looks like CVS is responding again; I ran cvs update -AdP and it >> didn't hang like it's been doing for a few days. However, while it >> said "cvs server: Updating marathon2/Display", I still don't have a >> Display folder in my marathon2 folder. Am I doing something wrong, >> or is CVS? > > I had this exact problem as well last night. I think it has to do with > them switching over to new servers. I tried all sorts of things to get > it to update. > > Finally after pestering Br'fin a few times on AIM, he asked me if I'd > done all those things, and when I did them again, it simply worked, > and I got the latest AM to build. > > I have no explanation to give you. :\ I think I do. Aside from, me doing stupid things and hence failing to log into the public CVS site correctly... it appears that the public CVS server is behind the development one in terms of content. I'm unclear of the reason for the delay or for why different checkouts may get different content sets (Then again Matt may use access to the development CVS servers which are more up to date and in sync.) After lots of poking I did find mention of the public cvs servers having delayed content. But poking around. a cvs log in the public cvs results in: Working file: CDisplay.h head: 1.1 branch: locks: strict access list: symbolic names: devel-display-abstraction: 1.1.0.2 keyword substitution: kv total revisions: 10; selected revisions: 10 And a cvs log in the development cvs reveals: Working file: CDisplay.h head: 1.2 branch: locks: strict access list: symbolic names: devel-display-abstraction: 1.1.0.2 keyword substitution: kv total revisions: 13; selected revisions: 13 I don't know if we ourselves really warrant nightly tarballs. But if Alexander is willing to set them up... :) -Jeremy Parsons |
|
From: Matt L. <ze...@ze...> - 2003-10-08 20:21:21
|
>It looks like CVS is responding again; I ran cvs update -AdP and it >didn't hang like it's been doing for a few days. However, while it >said "cvs server: Updating marathon2/Display", I still don't have a >Display folder in my marathon2 folder. Am I doing something wrong, >or is CVS? I had this exact problem as well last night. I think it has to do with them switching over to new servers. I tried all sorts of things to get it to update. Finally after pestering Br'fin a few times on AIM, he asked me if I'd done all those things, and when I did them again, it simply worked, and I got the latest AM to build. I have no explanation to give you. :\ -Zebe -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
