|
From: Bernard B. <be...@lp...> - 2006-11-21 09:57:58
|
Anthony Kozar <ant...@sb...> wrote:
>1. Make sure all code is PPC-native
Probably it is because I remember carefully following the guidelines when
I ported from 6800x to PPC. In those days there were a few crashing bugs
and I checked the PPC compatibility again and again hoping that it would
solve them. (Bugs were elsewhere as expected...)
> It is easiest to do the porting on OS 9 so that changes can be made
> slowly and the application will still compile and run. (I also want
> to conditionalize all changes so that a non-Carbon build can be
> maintained for now -- that way we will not leave behind anyone who
> is still using BP2 on OS 7-9 until it is absolutely necessary). Once
> the application can be built linking only to CarbonLib, then we can
> begin testing on OS X.
It is a good strategy.
> WindowPtr, GrafPtr, and DialogPtr can no longer be used interchangably
> in Carbon and every occurrence of code that assumes they can be must
> instead call a function to convert between pointer types.
Normally I had done it (when chasing interface bugs) but it needs to be
checked again.
>5. Remove direct access to Low-Memory Globals
>
> The Carbon Report did not find any instances of this. Hopefully, it is
> correct.
Right.
>I don't think BP2 writes to its
> resource fork
It does not.
> but it does try to create files in its own folder.
It is the case with the default settings file. This one should indeed be
moved to the proper location.
Another file that was created in the same folder is an invisible file
used for registering, but I believe you have already removed that part.
The general philosophy was that whenever you open a grammar file the
machine remembers the location of the folder in which that grammar file
was located, and it will try to load all related files (settings,
alphabet, orchestra etc.) from that same folder. It will also propose the
same folder, by default, for saving files of the same "project".
At one point I was tempted to define a specific "project file" that would
contain the links/paths to grammar, data etc. but I found it easier to
maintain the explicit links in grammar and data files.
It gets a bit more complicating when running scripts: every "open file"
script instruction contains the ID of the folder in which the file was
located, but this ID will change if files are moved to another disk. When
it does not reach the file at the specific location, it tries other
strategies such as the "current folder", or the last folder in which
another file of the same type was opened, etc. I am not sure these
strategies will still work in MacOS X, but redefining them should be done
only in the next phase (after the release of the beta version) because
scripting is not a vital feature of BP.
>9. BP2's "message" windows at the bottom of the screen will have to be
> relocated when the OS X Dock is in their way=3F
Since we have larger monitors now they could be flashed on any
relocatable window. At least we do it with the first version of the
port. They could even disappear because the program is too fast now to
enable reading those messages, and we still can use the option "Display
last messages" to trace the recent actions.
>> Memory management may also be simplified. In "BP2main.c" I had created a
>> procedure "GiveSpace()" to replace "NewHandle()", in which we first check
>> whether enough space is available in the heap, and if it not we
>> temporarily use the stack of the system. This is indeed obsolete.
>
>Yes, this will likely need to be redone as allocating system memory is no
>longer an option. (I think it will compile and run OK under Carbon, it is
>just pointless).
Then simply use "Newhandle()" in replacement of "GiveSpace()"
>This is an issue that I may even address for the final pre-Carbon release
>(2.9.5 final). As it is, the prefix files will not get the correct file
>types on OS 9 or OS X when checked out from CVS. And BP2 will not open a
>file with type 'TEXT' as a grammar, etc. I think an immediate improvement
>would be to allow opening any file with type 'TEXT' on OS 9.
The option was already there: if you push the 'option' ("alt") key when
typing "command-O" you get access to all text files whatever their
prefix/file type.
>As for OS X, I think we should adopt some file extension suffixes as
>"standard" for each of BP's file types, and continue to set file and =
creator
>types when saving files from BP (this is acceptable in OS X if frowned upon
>by Apple). When opening a file, a popup menu could be provided for =
choosing
>the type. For example, when opening a grammar, the choices would be "BP
>grammar", "Any text file", "Any file". The filter for "BP grammar" could
>include any file with the correct OS 9 type, the prefix "-gr", or the new
>suffix (maybe .bpgr =3F).
This is a nice way to do it. Keeping file creator/type is also a good
strategy even though we know that it won't make any sense when porting to
Linux and other systems.
>The user can then decide how they wish to name files (using prefixes,
>suffixes, or any scheme of their own) and it will still be possible to open
>them with BP.
This option is fine because at this point we cannot decide what is more
practical for users. It partly depends on the availability of navigation
services.
>What I would like to do is investigate three different options for the =
first
>round of porting: 1) carbonizing WASTE, 2) using MLTE if it is simple
>enough to wrap the code so that we can stick with ASCII text throughout the
>rest of BP, or 3) "downgrading" to TextEdit temporarily until the text
>editing can be completely reworked.
>
>I would give preference to either 1 or 2 and my choice would depend on =
which
>option is simpler. Option 3 would be a last resort since limiting text
>files to 32K is very annoying.
>
>My goal is to get to a mostly functional Carbon port of BP2 as fast as
>possible. This means that in the first round of changes, I will be =
focusing
>only on those parts of the code that HAVE to be changed and I would like to
>give priority to solutions that are simpler to code when there is more than
>one choice. Certainly, once we have a version of BP that can actually run
>on OS X, we can go back and implement more ideal solutions for the long
>term.
I agree that the priority is to run the program in MacOSX, even if it is
at the cost of limiting window sizes to 32,000 characters in the first
version. We never see grammars of that size. The only cases would be
the display of very large BP2 scores or the tracing of large Csound
scores, both of which are quite useless. Csound scores are directly
stored as text files with no limit on the length, and they can later be
opened with a more suitable text editor.
Unicode sounds great but in my opinion it should be targetted in the next
phase, after the porting.
>MLTE is supposed to make it very easy to print text windows as well. I
>honestly do not consider printing to be essential to the first round port
>though. Since all of BP's data files are plain text, they can be opened in
>any text editor (such as BBEdit) and printed from there. Therefore, I will
>likely focus on getting the rest of BP2 ported before working on printing
>and I think we could release a version of Carbon BP without printing if it
>will take significantly longer to add.
I agree totally.
At a later stage some users might even wish to use an external editor for
all Bol Processor files.
Bernard Bel <be...@up...>
Laboratoire Parole et Langage
http://www.lpl.univ-aix.fr
UMR 6057 CNRS - Universit=E9 de Provence / salle A464
29 av. R. Schuman
13621 Aix-en-Provence cedex 1 (France)
Sec'y, Special Interest Group on Speech Prosody (SProSIG)
http://www.lpl.univ-aix.fr/projects/sprosig/
Centre de Ressources pour la Description de l'Oral (CRDO)
http://crdo.fr
Bol Processor project
http://sourceforge.net/projects/bolprocessor/
Blog perso :
http://bernard-bel.over-blog.com/
|
