alephmodular-devel Mailing List for AlephModular (Page 18)
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: Chris B. <zzk...@uq...> - 2003-01-09 08:45:31
|
Codewarrior doesn't have most of the MSVC goodies, however it generally makes up for them in other ways, to the extent that it is still my favourite development environment (despite certain *big* drawbacks :-) Selecting a symbol and pressing cmd-' to activate the browser will show you the definition in context etc which is about as effective (if not quite so nifty) as the msvc context information. It doesn't have the scope awareness that MSVC provides. On the flipside, it does provide quite a few simpler but still nifty shortcuts that msvc lacks (pre .net anyway) including swap to header, open named file, etc. The compiler is also blindingly fast compared to apple's tools (some 1400% improvement when i last tested it against the pre-gcc-3 project builder.) it's a pity about the poor SCM support (MSVC's got it made, there, and i haven't used CVS with PB) chris |
|
From: Woody Z. I. <woo...@sb...> - 2003-01-09 08:21:00
|
On Thursday, January 9, 2003, at 12:16 AM, Joe Auricchio wrote:
> Hm. Is it just me, or does MSVC just suck in every way imaginable? Is
> there anything it's GOOD at?
There are certainly some technical drawbacks, but from a user's
standpoint (as a developer) the IDE has some really nice features:
1. It "reads over your shoulder" and tries to help. For example...
a. when you type "get_shape_descriptor(", it pops up a little ToolTip
with get_shape_descriptor's formal parameters, bolding each parameter as
you walk through them (in your typing). (If there are multiple
get_shape_descriptor functions, it says "1 of 3" or whatever next to it
and lets you cycle through the different prototypes.)
b. When you type "bitmap_definition->", it pops up a menu of all of
{whatever type bitmap_definition is}'s data members and methods.
(Actually, if you're not in a privileged scope, it may only pop up the
public ones; don't remember.) Each identifier in the menu is identified
by a tiny icon as to whether it's a data member, a method, public,
protected, etc. As you type the next few characters it refines its
guess as to which one you mean (or you can use the arrow keys or click
the mouse). Once it has it right, hit return or any other
non-identifier-character key, and it autocompletes.
c. at any time, hit control+space to attempt to complete the current
identifier. This is smarter than Project Builder's "complete:"
keybinding (if you set one up) since it knows about scoping and about
identifiers (and their properties) from other source files etc. Also,
it uses the pop-up list thing as discussed above, instead of just
guessing (and getting it wrong half the time) the way PB does.
2. It has instant "call graph" and "callers graph" support. So if
you're trying to learn your way around a big, unfamiliar code base
(like, say, A1), you can just ask it "What functions call
get_shape_descriptor?" (I mean, by like clicking on the identifier and
hitting Alt+F12 or choosing a menu option), and it will show you in a
new little window. And each of those functions can also be expanded in
the tree view to show _their_ callers. And you can double-click any of
them to jump to the code. It's clever enough that if
initialize_application() calles atexit(shutdown_application),
initialize_application() shows up in the callers-graph of
shutdown_application.
3. Incremental linking and Edit and Continue. Incremental linking lets
the linker only reprocess code that needs to be reprocessed, cutting
link time (after the first build) down substantially. Edit and Continue
is pretty cool. Suppose you're stepping through a function and see that
it's about to execute some code that does something really dumb. So you
just fix it, and Edit and Continue! The changed code is compiled,
linked, and patcthed into the currently-executing (but stopped)
program. So you keep on stepping through, no need to quit the app, make
the change, rebuild, rerun, and try to get back to where you were.
4. Miscellaneous niceties, like if you point at an identifier in the
code while debugging, it identifies the type and current value of that
identifier in a ToolTip. It's also good about, when you right-click an
identifier and ask to see its definition, actually taking you to the
right place, and doing it quickly. In my experience PB is less pleasant
on both counts (particularly if there are multiple candidates) when you
command-double-click. Also in general PB only knows about an identifier
once you've successfully compiled its file. MSVC must do some sort of
real-time online parsing while you're coding; it knows about identifiers
and their types etc. long before you actually compile your changes.
Also when you change a header file, MSVC analyzes which other source
files are actually affected, and will only rebuild those (it won't
necessarily rebuild every source file that #includes the header).
So yeah, not trying to start a war here... MSVC has problems
(especially in the compiler proper), but it has some pretty nice stuff
too (especially in the IDE). (You _did_ ask.) It probably sounds like
small potatoes, but once you code with the "smart completion" stuff
kicking in, it's hard to go back to having to constantly be manually
looking up function prototypes and names of methods and so forth. It
takes me well over 3x as long to write a (non-trivial) new function body
in Project Builder than in MSVC for exactly this reason - the constant
switching to Internet Explorer or another source file or whatever is
annoying and distracting and time-consuming. And maybe there's a way to
use six command-line tools in a row (probably with special build options
specified while compiling) to get a text dump of a callers-graph with
Apple's (GNU's) tools, but having it right at your fingertips in MSVC
gets you to the code you need to see in seconds.
If you haven't experienced writing and browsing code in MSVC, your life
is incomplete. :) Of course, I would make a similar claim about using
Apple's (NeXT's) Interface Builder (in Cocoa, anyway... I gather you
can't instantiate objects and make connections - which is the whole
point - with Carbon applications). [Apple's/NeXT's?] Sampler is pretty
cool too.
Maybe other environments (like CodeWarrior, Forte, etc.) are also doing
the things I mentioned as MSVC niceties. Maybe they were even doing
some of them first. I don't know.
Woody
|
|
From: Michael A. <mdm...@ya...> - 2003-01-09 03:33:33
|
--- Dietrich Epp <die...@zd...> wrote: > > On Wednesday, January 8, 2003, at 02:06 , Br'fin > wrote: > > > > > On Wednesday, January 8, 2003, at 04:58 PM, > Michael Adams wrote: > > > >> Just a question, what header is the deffinition > for > >> int16 and int32 comming from? Is it a standard > header > >> from the host environment or one we control? If > the > >> former, I'm wondering if all platforms have this > >> header. > >> > >> Michael D. Adams > >> mdm...@ya... > >> > > The definition of int16 and int32 and related > values are within the > > cstypes.h file that we picked up from AlephOne. We > control the file. > > Though it will need appropriate platform > definitions for each platform. > > Wouldn't it be easier, rather than make appropriate > definitions for each > platform, just include <stdint.h>? That file has > typedefs for > everything (portably), and #define could take care > of the rest (or > search & replace). > Unfortunately, stdint.h doesn't exist on all platforms, most notably MSVC++7. I would love it if something like this existed on all platforms (anyone on the ANSI committy listening), but I have yet to find it. You may want to look at the way SDL handles this problem. Basicly it includes stdint.h (or the equivalent) on platforms that have it, but also defines int16 et. al. on the platforms that don't. Longing for the day all platform live in peace and perfect harmony, I remain, Michael D. Adams mdm...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Timothy C. <tco...@ha...> - 2003-01-09 03:32:00
|
On Wednesday, January 8, 2003, at 07:18 PM, Br'fin wrote: > Is there anyone here on the list who has access to OSX 10.1 and is > willing to be a guinea pig? > Love to! I've ordered Jaguar, but it hasn't come yet. Also, I have access to computers at my college that have 10.1 on them, in case we still need to test after I (finally!) have Jaguar. Anyway, I am more than happy to help keep compatibility for folks like I was until yesterday, who haven't bitten the bullet yet, for whatever reason. Timothy Collett I just think it's rather odd that a nation that prides itself on its virility should feel compelled to strap on forty pounds of protective gear just in order to play rugby. --Giles, "Buffy" |
|
From: Dietrich E. <die...@zd...> - 2003-01-09 02:11:27
|
On Wednesday, January 8, 2003, at 02:06 , Br'fin wrote: > > On Wednesday, January 8, 2003, at 04:58 PM, Michael Adams wrote: > >> Just a question, what header is the deffinition for >> int16 and int32 comming from? Is it a standard header >> from the host environment or one we control? If the >> former, I'm wondering if all platforms have this >> header. >> >> Michael D. Adams >> mdm...@ya... >> > The definition of int16 and int32 and related values are within the > cstypes.h file that we picked up from AlephOne. We control the file. > Though it will need appropriate platform definitions for each platform. Wouldn't it be easier, rather than make appropriate definitions for each platform, just include <stdint.h>? That file has typedefs for everything (portably), and #define could take care of the rest (or search & replace). |
|
From: Br'fin <br...@ma...> - 2003-01-09 00:17:21
|
Is there anyone here on the list who has access to OSX 10.1 and is willing to be a guinea pig? I'd much rather be throwing out downloads that are OSX compatible instead of, OSX 10.2 compatible and who knows if it'll even run and exit gracefully under 10.1.... -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-01-08 22:05:46
|
On Wednesday, January 8, 2003, at 04:58 PM, Michael Adams wrote: > Just a question, what header is the deffinition for > int16 and int32 comming from? Is it a standard header > from the host environment or one we control? If the > former, I'm wondering if all platforms have this > header. > > Michael D. Adams > mdm...@ya... > The definition of int16 and int32 and related values are within the cstypes.h file that we picked up from AlephOne. We control the file. Though it will need appropriate platform definitions for each platform. -Jeremy Parsons |
|
From: Michael A. <mdm...@ya...> - 2003-01-08 21:58:09
|
Just a question, what header is the deffinition for int16 and int32 comming from? Is it a standard header from the host environment or one we control? If the former, I'm wondering if all platforms have this header. Michael D. Adams mdm...@ya... --- Br'fin <br...@ma...> wrote: > Ok, we are beginning to wrap up the various cleanup > and preparation > stages for 0.3 > > Here is the current changelog entry that I'm > assembling for this point. > > 0.3 Cleanup and Preparation > Shorts and Longs converted to int16 and int32 to > guaruntee bit size of > values > Quashed many many compilation warnings > Removed much in the way of obsolete code > Added autoconf support to make sure all elements of > AlephModular agree > on the current version > Added icons and other branding elements to > AlephModular (such as > referring to AlephModular instead of Marathon in > preference dialogs) > Fixed a crashing bug when trying to use ambient > sounds and jumping > under water > Fixed a bug when dying so your screen should cant > around more > > What other kinds of preparation do we need to sign > off on this? > Are there other basic principles that should also be > done now? > Am I forgetting anything? > > I welcome comments, either on the list or directly. > I can be > iChat'd/AIM'd vis my mac.com address below. > > -Jeremy Parsons > > --------------------- > +------------------------------------------------------ > Br'fin | TIMSter, MU*er, Web > Programmer, ... Insane? > The Denim Warrior | You be the > judge... > br...@ma... | > --------------------- > +------------------------------------------------------ > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = > Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Br'fin <br...@ma...> - 2003-01-08 18:26:44
|
Ok, we are beginning to wrap up the various cleanup and preparation stages for 0.3 Here is the current changelog entry that I'm assembling for this point. 0.3 Cleanup and Preparation Shorts and Longs converted to int16 and int32 to guaruntee bit size of values Quashed many many compilation warnings Removed much in the way of obsolete code Added autoconf support to make sure all elements of AlephModular agree on the current version Added icons and other branding elements to AlephModular (such as referring to AlephModular instead of Marathon in preference dialogs) Fixed a crashing bug when trying to use ambient sounds and jumping under water Fixed a bug when dying so your screen should cant around more What other kinds of preparation do we need to sign off on this? Are there other basic principles that should also be done now? Am I forgetting anything? I welcome comments, either on the list or directly. I can be iChat'd/AIM'd vis my mac.com address below. -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
|
From: Br'fin <br...@ma...> - 2003-01-08 05:23:59
|
I got a nice suggestion from Chris. I'm now removing all obsolete code. (Generally including calls to a function if the function body is completely obsolete) and if anything interesting looks like it is getting removed, then I am noting it in alepModular/documents/obsolete_gems.txt -Jeremy Parsons On Friday, January 3, 2003, at 11:28 AM, Br'fin wrote: > I just remembered one of the other things I meant to do for 0.3. > Removing the obsolete code. > > I already snipped out a code block in map_constructors.cpp that was > #ifdef'd as NEW_AND_BROKEN. However it occurred to me that while some > blocks are just going to be obsolete. Other blocks are going to be > obsolete but useful. For instance an obsolete block that specifically > refers to M1. > > I know all these things will remain in CVS. However, who's going to > know these blocks are there to look for at the time when we do start > adding M1 support? Leave them in the code? Remove them anyways but add > an extra note in the CVS log? > > And as should be expected, I do have my eyes on removing the Valkyrie > support code as part of obsolete code removal. > > -Jeremy Parsons > |
|
From: Br'fin <br...@ma...> - 2003-01-07 02:10:12
|
On Monday, January 6, 2003, at 08:46 PM, Alexander Strange wrote: > > On Monday, January 6, 2003, at 08:34 PM, Br'fin wrote: >> I am curious as to what you have in mind for cleanup within >> render.cpp though. >> >> -Jeremy Parsons > > There's large amounts of old #ifdefed out code, commented-out code (in > scottish_textures too), ugly and badly-formatted code, misspelled > comments, etc. And a few inefficiences where it calls memset() when an > inlined loop would do the same thing faster (cross-library calls are > extremely slow in OS X), although this really counts as an > optimization. On Render.cpp Most of the #ifdef'd code that I see is under the auspices of QUICKDRAW_DEBUG. As such, I am inclined to leave it in under the assumption that debugging code whether on or off is potentially useful, Especially if someone knows what they're doing in there and needs to know. I have not done a similar review of commented out code. But I'd be applying the same kind of decisions. Truly obsolete code? It's out of there. Disabled but useful in some fashion? for instance Debugging code or code that appears to relate directly to M1 behaviour, may stay. On memset: leave it alone for now. Right now we have most of the original memset's still in place. If we're going to do anything about them, then I would rather it be done uniformly and across the board. Loren's obj_clear and other template based calls at the end of csmacros,h hold a certain appeal to me in this regard. ( Even if they themselves are implemented in terms of memset and memcpy. :) ) scottish_textures.cpp: Yeah it does look like it has some nicely labeled obsolete code at the end. Mmm, I wonder what's so nicely unique about the one that's labeled obsolete and 'unnecessary, but do not delete' :) -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-01-07 01:46:24
|
On Monday, January 6, 2003, at 08:34 PM, Br'fin wrote: > I am curious as to what you have in mind for cleanup within render.cpp > though. > > -Jeremy Parsons There's large amounts of old #ifdefed out code, commented-out code (in scottish_textures too), ugly and badly-formatted code, misspelled comments, etc. And a few inefficiences where it calls memset() when an inlined loop would do the same thing faster (cross-library calls are extremely slow in OS X), although this really counts as an optimization. |
|
From: Br'fin <br...@ma...> - 2003-01-07 01:33:25
|
On Monday, January 6, 2003, at 07:46 PM, Alexander Strange wrote: > > On Monday, January 6, 2003, at 06:36 PM, br...@ma... wrote: > >> Alright, I just got Alexander's autoconf patch submitted. Remind me >> next time to use a SourceForge tracker page for stuff like that so I >> don't spam the list ;) >> >> Now, among the files committed as part of this are also >> pre-configured versions of the project builder file, the >> InfoPlist.strings files and the marathon2.r resource file. >> >> So for the time being those files don't strictly need to be >> configured. > > Except that a 'make distclean' will delete them. (Although, since you > need to run configure to get any Makefiles, it's really a moot point, > unless we use the automake support for making source tarballs for > distribution). > >> But the basics for configuring are in. Though I'd not mind a patch >> to flush out the instructions. INSTALL.cvs is correct, if terse. and >> by contrast INSTALL seems very verbose :) >> >> If you wish to run the autoconf stuff then do the following >> cd alephModular >> sh ./build/unix/autogen.sh > > You seem to have changed one instance of 'libtoolize' in that file to > 'glibtoolize', and left the other alone. > >> sh ./configure >> >> -Jeremy Parsons > > Can I be given CVS commit access? I see several things that could be > done (cleanup and optimization in render.cpp, fixing spelling problems > in comments, more general autoconf maintenance, etc.) that would > produce very large and unwieldy patches to send in. > I will give you access for the maintence of the autoconf, Alexander. I'd have to nix optimization at this point in time. It's not the current focus. (And at a time when AM thinks it's drawing 30 frames a second, but is getting throttled by the unintentional triple buffering of its windows under MacOS X, eeking out more rendering performance just doesn't strike me as that important) I am curious as to what you have in mind for cleanup within render.cpp though. -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-01-07 01:25:34
|
On Monday, January 6, 2003, at 07:46 PM, Alexander Strange wrote: > Can I be given CVS commit access? I see several things that could be > done (cleanup and optimization in render.cpp, fixing spelling problems > in comments, more general autoconf maintenance, etc.) that would > produce very large and unwieldy patches to send in. Oops, forgot my Sourceforge username. It's 'mrvacbob'. |
|
From: Alexander S. <ast...@it...> - 2003-01-07 00:47:25
|
On Monday, January 6, 2003, at 06:36 PM, br...@ma... wrote: > Alright, I just got Alexander's autoconf patch submitted. Remind me > next time to use a SourceForge tracker page for stuff like that so I > don't spam the list ;) > > Now, among the files committed as part of this are also pre-configured > versions of the project builder file, the InfoPlist.strings files and > the marathon2.r resource file. > > So for the time being those files don't strictly need to be configured. Except that a 'make distclean' will delete them. (Although, since you need to run configure to get any Makefiles, it's really a moot point, unless we use the automake support for making source tarballs for distribution). > But the basics for configuring are in. Though I'd not mind a patch to > flush out the instructions. INSTALL.cvs is correct, if terse. and by > contrast INSTALL seems very verbose :) > > If you wish to run the autoconf stuff then do the following > cd alephModular > sh ./build/unix/autogen.sh You seem to have changed one instance of 'libtoolize' in that file to 'glibtoolize', and left the other alone. > sh ./configure > > -Jeremy Parsons Can I be given CVS commit access? I see several things that could be done (cleanup and optimization in render.cpp, fixing spelling problems in comments, more general autoconf maintenance, etc.) that would produce very large and unwieldy patches to send in. |
|
From: <br...@ma...> - 2003-01-06 23:35:43
|
Alright, I just got Alexander's autoconf patch submitted. Remind me next time to use a SourceForge tracker page for stuff like that so I don't spam the list ;) Now, among the files committed as part of this are also pre-configured versions of the project builder file, the InfoPlist.strings files and the marathon2.r resource file. So for the time being those files don't strictly need to be configured. But the basics for configuring are in. Though I'd not mind a patch to flush out the instructions. INSTALL.cvs is correct, if terse. and by contrast INSTALL seems very verbose :) If you wish to run the autoconf stuff then do the following cd alephModular sh ./build/unix/autogen.sh sh ./configure -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-01-06 19:14:28
|
On Monday, January 6, 2003, at 02:01 PM, Michael Adams wrote: > I just took a look at CrystalSpace (crystal.sf.net), > and am very impressed by their modularity. Grate > graphics library too, but the physics and networking > seem to be a little lacking. You may want to take a > look at it for ideas about how to design the > modularity in AM. CS is so modular that as an > expriment I'm going to try to write a M2 map reader > for it (provided I can figure out the M2 map format). > > Michael D. Adams > mdm...@ya... I think Loren Petrich is already working on one. |
|
From: Michael A. <mdm...@ya...> - 2003-01-06 19:01:43
|
I just took a look at CrystalSpace (crystal.sf.net), and am very impressed by their modularity. Grate graphics library too, but the physics and networking seem to be a little lacking. You may want to take a look at it for ideas about how to design the modularity in AM. CS is so modular that as an expriment I'm going to try to write a M2 map reader for it (provided I can figure out the M2 map format). Michael D. Adams mdm...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Br'fin <br...@ma...> - 2003-01-06 12:51:49
|
On Monday, January 6, 2003, at 07:34 AM, Peter de Blanc wrote: > Hey, I've just joined the mailing list. > > I have a Mac running OS 9. I'm setting up MPW right now.... I own a > copy of CodeWarrior (5?) somewhere, too, but I'll have to find > it. I'll try compiling the source soon. > Welcome aboard. :) If you are trying to use MPW you may wish to perform a CVS checkout with a date of Jan 3rd, 2003. Around Jan 2004 I had removed the various MPW files thinking that MPW wasn't apt to be used but that Codewarrior would and because makefile (MPW's) was conflicting with Alexander's work on autoconf support (which seeks the unix style Makefile) Also, all the files are now compiled as C++ (.cpp) now instead of the C that the MPW makefile expects. -Jeremy Parsons |
|
From: Peter de B. <peter.d. verizon.net> - 2003-01-06 12:28:12
|
Hey, I've just joined the mailing list. I have a Mac running OS 9. I'm setting up MPW right now.... I own a copy of CodeWarrior (5?) somewhere, too, but I'll have to find it. I'll try compiling the source soon. |
|
From: Alexander S. <ale...@it...> - 2003-01-06 04:31:23
|
There is a sort-of problem with the current autoconf setup. I was planning to have the project.pbxproj generated before we make a dist release. Currently, it isn't. This just needs a documentation change in alephModular/INSTALL.cvs. Also, Br'fin removed the 'libtoolize' command from autogen.sh, which might cause problems. To be safe, it should be added in calling 'glibtoolize', which comes with the Developer Tools. |
|
From: Alexander S. <ast...@it...> - 2003-01-05 23:50:34
|
On Sunday, January 5, 2003, at 06:25 PM, Br'fin wrote: > Now you said this was a preliminary patch. Are you going to have a > cleaned up and/or improved version to try? > > -Jeremy Parsons Not until there's something wrong with the current patch that applies to what we're using this for at the moment. |
|
From: Br'fin <br...@ma...> - 2003-01-05 23:24:22
|
On Sunday, January 5, 2003, at 01:43 PM, Alexander Strange wrote: >> I finally figured out why it might be barfing on InfoPlist.strings. >> The file is encoded in unicode-16. >> >> So if I put the whole file properly into unicode-16, then ./configure >> can no longer substitute its values. >> >> On the other hand, Project Builder seems to be reasonably happy if I >> change the file's encoding to unicode-8. (And this makes ./configure >> happy too) >> >> Happen to know if there's anyway to tell configure and its tools to >> treat the file as unicode-16? I'm ok with changing the encoding to >> unicode-8 myself. But it possible I'd rather leave it in PB's >> originally suggested encoding. >> >> -Jeremy Parsons > > I don't think configure is very good at Unicode; the substituting is > probably done with sed, if you want to take a look at it. I can't quite seem to figure out if there's anything you can pass to sed to fix the problem. On the other hand it process all of the .in files at once. I'll shift InfoPlist.strings to utf-8. Now you said this was a preliminary patch. Are you going to have a cleaned up and/or improved version to try? -Jeremy Parsons |
|
From: Alexander S. <fe...@it...> - 2003-01-05 18:43:22
|
On Sunday, January 5, 2003, at 12:11 PM, Br'fin wrote:
>
> On Saturday, January 4, 2003, at 08:20 PM, Alexander Strange wrote:
>
>>
>> It also might barf on InfoPlist.strings, but the conflict stuff can
>> be fixed easily.
>>
> I finally figured out why it might be barfing on InfoPlist.strings.
> The file is encoded in unicode-16.
>
> So if I put the whole file properly into unicode-16, then ./configure
> can no longer substitute its values.
>
> On the other hand, Project Builder seems to be reasonably happy if I
> change the file's encoding to unicode-8. (And this makes ./configure
> happy too)
>
> Happen to know if there's anyway to tell configure and its tools to
> treat the file as unicode-16? I'm ok with changing the encoding to
> unicode-8 myself. But it possible I'd rather leave it in PB's
> originally suggested encoding.
>
> -Jeremy Parsons
I don't think configure is very good at Unicode; the substituting is
probably done with sed, if you want to take a look at it.
--
Alexander Strange
"Is God willing to prevent evil, but not able?
Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? When why call him god?"
-- anonymous, Boethius' Consolation of Philosophy
|
|
From: Br'fin <br...@ma...> - 2003-01-05 17:10:43
|
On Saturday, January 4, 2003, at 08:20 PM, Alexander Strange wrote: > > It also might barf on InfoPlist.strings, but the conflict stuff can be > fixed easily. > I finally figured out why it might be barfing on InfoPlist.strings. The file is encoded in unicode-16. So if I put the whole file properly into unicode-16, then ./configure can no longer substitute its values. On the other hand, Project Builder seems to be reasonably happy if I change the file's encoding to unicode-8. (And this makes ./configure happy too) Happen to know if there's anyway to tell configure and its tools to treat the file as unicode-16? I'm ok with changing the encoding to unicode-8 myself. But it possible I'd rather leave it in PB's originally suggested encoding. -Jeremy Parsons |
