quesa-develop — Mailing list for Quesa development

Re: Other Quesa concerns/suggestions

[Jose' C. <cru...@ce...>]

Il giorno 24/apr/09, alle ore 17:56, Sean McBride ha scritto:

>
> I agree 'fast' sounds like a recommendation, they probably should have
> called it GCC_BROKEN_MATH. :)

better call it GCC_DIFFERENTLY_INEXACT_BUT_MAYBE_A_LITTLE_FASTER :-)


Pax et Bonum

# Dott. José Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602
http://www.linkedin.com/in/jcruanyes

Re: Other Quesa concerns/suggestions

[Sean M. <se...@ro...>]

On 4/24/09 8:47 AM, James W. Walker said:

>> 1) In Quesa-common.xcconfig we have:
>>  GCC_FAST_MATH = YES
>>
>> From my understanding, this option is not generally recommended.  Is  
>> it
>> really needed?
>
>Can you give me any references?  I googled it, and couldn't find any  
>recommendations one way or another.  But to me, the word "fast" is a  
>recommendation.

Xcode's 'Research Assistant' has this to say: 

"Enables some floating point optimizations that are not IEEE754-
compliant, but which usually work. Programs which require strict IEEE
compliance may not work with this option. [GCC_FAST_MATH, -ffast-math]"

gcc's man page says:

"-ffast-math
Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -
ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-
limited-range.
This option causes the preprocessor macro "__FAST_MATH__" to be defined.

This option should never be turned on by any -O option since it can
result in incorrect output for programs which depend on an exact
implementation of IEEE or ISO rules/specifications for math functions."

I agree 'fast' sounds like a recommendation, they probably should have
called it GCC_BROKEN_MATH. :)

>> 2) In Quesa.h we have:
>>  #pragma options align=power
>>
>> Is this really needed?  Can we wrap it in #if TARGET_RT_MAC_CFM so  
>> that
>> it only applies to Mac OS 9?
>
>It probably is a relic of QD3D.  I expect that as long as the  
>alignment of the header agrees with the alignment used to build Quesa,  
>then it shouldn't matter.  So I think we can wrap it as you suggest.

Great.

>> 3) In Debug, the static library is named libQuesaD.a and in Release it
>> is libQuesa.a.  Why is this?  For CodeWarrior this would be handy, but
>> for Xcode it is annoying because Xcode does not allow different
>> libraries to be used in different configurations.  The only way to do
>> that with Xcode is to pass -libQuesa as a linker flag and change  
>> library
>> search paths between Debug and Release.  This requires the libs to  
>> have
>> the same name.
>
>
>I don't know why, and wouldn't object to changing it.  (I always use  
>Quesa as a framework.)  However, I don't think it's exactly true that  
>Xcode doesn't allow different libraries to be used in different  
>configurations.  You can use a trick of putting symbolic links in the  
>build product Release and Debug folders, and then putting one of those  
>links in the project with a Build Product-relative path.

Up to you of course, it's not a big bother for my version to be 1
character off the standard version. :)

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Trying to get XCode to work with CVS

[Jose' C. <cru...@ce...>]

Il giorno 24/apr/09, alle ore 17:34, Roger Holmes ha scritto:

> I have set up XCode's CVS setting like this:
>
> Name: quesa
> Method: SSH
> Host: cvs.sf.net
I've
  quesa.cvs.sourceforge.net


> Path: /cvsroot/quesa
> Port: <currently blank, I dont know what this is for>
> User: <my sourceforge user name>
> Password: <my sourceforge password>
> Tool: /usr/bin/cvs <this was the default setting in the sheet already>
> Use RSH instead of SSH: off
>
> XCode has set the Root to:
> :SSH:rog...@cv...:/cvsroot/quesa
>
>
>
> Anyone spot where I have gone wrong? All my other projects are on an
> internal server and are CVS so I don't really know what I'm doing.

try ssh rog...@qu... on a terminal to see  
if you can connect without problems

I'm using keys to connect to sourceforge... I think that passwords  
are disabled in sourceforge


Pax et Bonum

# Dott. José Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602
http://www.linkedin.com/in/jcruanyes

Re: Trying to get XCode to work with CVS

[James W. W. <os...@jw...>]

On Apr 24, 2009, at 8:34 AM, Roger Holmes wrote:

> I have set up XCode's CVS setting like this:
>
> Name: quesa
> Method: SSH
> Host: cvs.sf.net
> Path: /cvsroot/quesa
> Port: <currently blank, I dont know what this is for>

I haven't tried this, but I can tell you that SSH normally uses port 22.

Re: Other Quesa concerns/suggestions

[James W. W. <os...@jw...>]

On Apr 22, 2009, at 9:58 AM, Sean McBride wrote:

> 1) In Quesa-common.xcconfig we have:
>  GCC_FAST_MATH = YES
>
> From my understanding, this option is not generally recommended.  Is  
> it
> really needed?


Can you give me any references?  I googled it, and couldn't find any  
recommendations one way or another.  But to me, the word "fast" is a  
recommendation.


> 2) In Quesa.h we have:
>  #pragma options align=power
>
> Is this really needed?  Can we wrap it in #if TARGET_RT_MAC_CFM so  
> that
> it only applies to Mac OS 9?


It probably is a relic of QD3D.  I expect that as long as the  
alignment of the header agrees with the alignment used to build Quesa,  
then it shouldn't matter.  So I think we can wrap it as you suggest.


> 3) In Debug, the static library is named libQuesaD.a and in Release it
> is libQuesa.a.  Why is this?  For CodeWarrior this would be handy, but
> for Xcode it is annoying because Xcode does not allow different
> libraries to be used in different configurations.  The only way to do
> that with Xcode is to pass -libQuesa as a linker flag and change  
> library
> search paths between Debug and Release.  This requires the libs to  
> have
> the same name.


I don't know why, and wouldn't object to changing it.  (I always use  
Quesa as a framework.)  However, I don't think it's exactly true that  
Xcode doesn't allow different libraries to be used in different  
configurations.  You can use a trick of putting symbolic links in the  
build product Release and Debug folders, and then putting one of those  
links in the project with a Build Product-relative path.

Trying to get XCode to work with CVS

[Roger H. <rog...@mi...>]

I have set up XCode's CVS setting like this:

Name: quesa
Method: SSH
Host: cvs.sf.net
Path: /cvsroot/quesa
Port: <currently blank, I dont know what this is for>
User: <my sourceforge user name>
Password: <my sourceforge password>
Tool: /usr/bin/cvs <this was the default setting in the sheet already>
Use RSH instead of SSH: off

XCode has set the Root to:
:SSH:rog...@cv...:/cvsroot/quesa



Anyone spot where I have gone wrong? All my other projects are on an  
internal server and are CVS so I don't really know what I'm doing.

Roger Holmes

Re: Should Quesa switch its version control system?

[Stefan H. <st...@to...>]

>I'd vote for svn because:
>- it has the most clients
>- its included in OS X by Apple
>- its supported by Xcode
>--
>Sean McBride, B. Eng

me too...


   Stefan
   http://www.topoi.ch

Re: Should Quesa switch its version control system?

[Lane R. <la...@if...>]

on Wed, Apr 22, 2009 Roger Holmes may have said:

>I have now switched from using svnX to XCode directly. It seems that  
>XCode can handle SNV, CVS and Perforce. I suppose if I could set up  
>XCode to handle CVS I could go back to using that without realising I  
>was not using SVN, apart from setting it up in the first place. I  
>wouldn't vote for anything which XCode doesn't handle.

That's actually a good point; there are add-ons to allow VS to handle
SVN directly as well (Ankh I believe is the open source offering). I'm
just starting to look into XCode's repo handling, but I use it in VS all
the time.

Lane Roathe
President      Ideas From the Deep   <http://www.ideasfromthedeep.com>
______________________________________________________________________
Since the Internet has no walls or fences, who needs Windows or Gates?

Re: Should Quesa switch its version control system?

[Roger H. <rog...@mi...>]

I have now switched from using svnX to XCode directly. It seems that  
XCode can handle SNV, CVS and Perforce. I suppose if I could set up  
XCode to handle CVS I could go back to using that without realising I  
was not using SVN, apart from setting it up in the first place. I  
wouldn't vote for anything which XCode doesn't handle.

Other Quesa concerns/suggestions

[Sean M. <se...@ro...>]

Hi again,

I have three more concerns/suggestions/questions:


1) In Quesa-common.xcconfig we have:
  GCC_FAST_MATH = YES

From my understanding, this option is not generally recommended.  Is it
really needed?


2) In Quesa.h we have:
  #pragma options align=power

Is this really needed?  Can we wrap it in #if TARGET_RT_MAC_CFM so that
it only applies to Mac OS 9?


3) In Debug, the static library is named libQuesaD.a and in Release it
is libQuesa.a.  Why is this?  For CodeWarrior this would be handy, but
for Xcode it is annoying because Xcode does not allow different
libraries to be used in different configurations.  The only way to do
that with Xcode is to pass -libQuesa as a linker flag and change library
search paths between Debug and Release.  This requires the libs to have
the same name.

Patch attached for consideration.

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Should Quesa switch its version control system?

[James W. W. <os...@jw...>]

On Apr 22, 2009, at 8:36 AM, Sean McBride wrote:

>> In the past, we were somewhat tied to the Mac CVS Pro client by its
>> special ability to handle Mac resource forks.  As far as I know, all
>> the necessary resource files in the Quesa tree have been converted
>> to .r text files or some other safe form.
>
> I think there is still one.  Although I build Quesa as a static lib,
> I've noticed that the framework does not build after a fresh checkout
> because of some .rsrc file being size 0.

That was an error in the setup of the Xcode project, which I just  
fixed.  The contents of Quesa.rsrc were copied into Quesa.r in Nov.  
2008.

Re: Should Quesa switch its version control system?

[Sean M. <se...@ro...>]

On 4/21/09 11:44 PM, James W. Walker said:

>Recently, in the thread "Buffer overrun in 64 bit build", some people  
>expressed interest in switching Quesa from CVS to some other version  
>control system.   I thought we should discuss it in a separate thread,  
>so that anyone who subscribes to the list but doesn't read every  
>message would have a fair chance to see it and offer an opinion.
>
>Besides CVS, SourceForge supports Subversion, Git, Mercurial, and  
>Bazaar.  All of these are newer, and at least in some ways better,  
>than CVS.

I agree they are all better than CVS.

>named TortoiseSVN and TortoiseHG.  On the Mac, I wrote a client for  
>Mercurial called MacMercurial.  I know there's a Subversion client  
>called svnX, but I don't know if that's the most popular.

The nicest svn client imho is Versions:
<http://versionsapp.com/>

I'd vote for svn because:
- it has the most clients
- its included in OS X by Apple
- its supported by Xcode
- there are very few Quesa developers meaning that merging and brancing
is not a big problem

>In the past, we were somewhat tied to the Mac CVS Pro client by its  
>special ability to handle Mac resource forks.  As far as I know, all  
>the necessary resource files in the Quesa tree have been converted  
>to .r text files or some other safe form.

I think there is still one.  Although I build Quesa as a static lib,
I've noticed that the framework does not build after a fresh checkout
because of some .rsrc file being size 0.

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Should Quesa switch its version control system?

[Lane R. <la...@if...>]

I'm partial to svn mainly based on it being what I know best, and using
it for a lot of different projects, including all of our company repos.
On Windows TortoiseSVN sets the standard (imho) for what good UI should
be in a client. On the Mac, unfortunately, there is not a good UI
client, although SvnX and RapidSVN both do decent jobs, and scplugin
attempts to get a bit toward TortoiseSVN.

I have checked out git and the main turn off was a repo per project and
lack of good UI clients.

Mercurial seems to be OK, I've shied away in the past due to speed
issues which seem to be resolved and python requirements which I could
get over. :) I wouldn't be apposed to going this direction.

Lane Roathe
President    Ideas From the Deep  <http://www.ideasfromthedeep.com>
___________________________________________________________________
I am Pentium of Borg. Precision is futile. You will be approximated.

on Tue, Apr 21, 2009 James W. Walker may have said:

>Recently, in the thread "Buffer overrun in 64 bit build", some people  
>expressed interest in switching Quesa from CVS to some other version  
>control system.   I thought we should discuss it in a separate thread,  
>so that anyone who subscribes to the list but doesn't read every  
>message would have a fair chance to see it and offer an opinion.
>
>Besides CVS, SourceForge supports Subversion, Git, Mercurial, and  
>Bazaar.  All of these are newer, and at least in some ways better,  
>than CVS.
>
>Git, Mercurial, and Bazaar are examples of "distributed revision  
>control systems".  This means that each repository contains the  
>complete history.  Therefore you can do many things, such as looking  
>at a log or comparing different versions of a file, without using a  
>network.  This also makes it easier to work on a big overhaul locally  
>without sending each change to the central server, but still having  
>the advantages of version control.
>
>Those who prefer not to live on the command line may want to  
>investigate GUI clients.  I don't have a complete list of these.  I  
>know that on Windows, Subversion and Mercurial have popular clients  
>named TortoiseSVN and TortoiseHG.  On the Mac, I wrote a client for  
>Mercurial called MacMercurial.  I know there's a Subversion client  
>called svnX, but I don't know if that's the most popular.
>
>In the past, we were somewhat tied to the Mac CVS Pro client by its  
>special ability to handle Mac resource forks.  As far as I know, all  
>the necessary resource files in the Quesa tree have been converted  
>to .r text files or some other safe form.

Re: Should Quesa switch its version control system?

[Jose' C. <cru...@ce...>]

I'm used to CVS, I've used SVN, I've read wonders about Mercurial...
but frankly I don't see any reason to change... this is no a NAY  
vote, just a 'I don't care', you are the mai contributor, if you feel  
accostumed with Mercurial, I think we should change to that.

Il giorno 22/apr/09, alle ore 08:44, James W. Walker ha scritto:

> Recently, in the thread "Buffer overrun in 64 bit build", some  
> people expressed interest in switching Quesa from CVS to some other  
> version control system.   I thought we should discuss it in a  
> separate thread, so that anyone who subscribes to the list but  
> doesn't read every message would have a fair chance to see it and  
> offer an opinion.
>
> Besides CVS, SourceForge supports Subversion, Git, Mercurial, and  
> Bazaar.  All of these are newer, and at least in some ways better,  
> than CVS.
>
> Git, Mercurial, and Bazaar are examples of "distributed revision  
> control systems".  This means that each repository contains the  
> complete history.  Therefore you can do many things, such as  
> looking at a log or comparing different versions of a file, without  
> using a network.  This also makes it easier to work on a big  
> overhaul locally without sending each change to the central server,  
> but still having the advantages of version control.
>
> Those who prefer not to live on the command line may want to  
> investigate GUI clients.  I don't have a complete list of these.  I  
> know that on Windows, Subversion and Mercurial have popular clients  
> named TortoiseSVN and TortoiseHG.  On the Mac, I wrote a client for  
> Mercurial called MacMercurial.  I know there's a Subversion client  
> called svnX, but I don't know if that's the most popular.
>
> In the past, we were somewhat tied to the Mac CVS Pro client by its  
> special ability to handle Mac resource forks.  As far as I know,  
> all the necessary resource files in the Quesa tree have been  
> converted to .r text files or some other safe  
> form.----------------------------------------------------------------- 
> -------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/ 
> p_______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Pax et Bonum

# Dott. José Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602
http://www.linkedin.com/in/jcruanyes

Should Quesa switch its version control system?

[James W. W. <os...@jw...>]

Recently, in the thread "Buffer overrun in 64 bit build", some people  
expressed interest in switching Quesa from CVS to some other version  
control system.   I thought we should discuss it in a separate thread,  
so that anyone who subscribes to the list but doesn't read every  
message would have a fair chance to see it and offer an opinion.

Besides CVS, SourceForge supports Subversion, Git, Mercurial, and  
Bazaar.  All of these are newer, and at least in some ways better,  
than CVS.

Git, Mercurial, and Bazaar are examples of "distributed revision  
control systems".  This means that each repository contains the  
complete history.  Therefore you can do many things, such as looking  
at a log or comparing different versions of a file, without using a  
network.  This also makes it easier to work on a big overhaul locally  
without sending each change to the central server, but still having  
the advantages of version control.

Those who prefer not to live on the command line may want to  
investigate GUI clients.  I don't have a complete list of these.  I  
know that on Windows, Subversion and Mercurial have popular clients  
named TortoiseSVN and TortoiseHG.  On the Mac, I wrote a client for  
Mercurial called MacMercurial.  I know there's a Subversion client  
called svnX, but I don't know if that's the most popular.

In the past, we were somewhat tied to the Mac CVS Pro client by its  
special ability to handle Mac resource forks.  As far as I know, all  
the necessary resource files in the Quesa tree have been converted  
to .r text files or some other safe form.

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[Sean M. <se...@ro...>]

On 4/21/09 9:23 AM, James W. Walker said:

>Thanks for reviewing it.  It has been checked in.

Great, thanks.  Did you also commit that small unrelated patch I emailed
you offlist the other day?

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[James W. W. <os...@jw...>]

On Apr 21, 2009, at 8:45 AM, Sean McBride wrote:

> On 4/19/09 4:46 PM, James W. Walker said:
>
>> I've done the instance data revision, and posted the changed files  
>> here:
>>
>> <ftp://ftp.jwwalker.com/misc/instance_data_fix.zip>
>
> Thanks James!
>
> I've reviewed it and it looks ok to me.  It's working great, both in  
> our
> new 64 bit app (which uses Quesa only to open 3dmf) and in our old 32
> bit app (which uses Quesa a lot).
>
> Will you be checking it into CVS?


Thanks for reviewing it.  It has been checked in.

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[Sean M. <se...@ro...>]

On 4/19/09 4:46 PM, James W. Walker said:

>I've done the instance data revision, and posted the changed files here:
>
><ftp://ftp.jwwalker.com/misc/instance_data_fix.zip>

Thanks James!

I've reviewed it and it looks ok to me.  It's working great, both in our
new 64 bit app (which uses Quesa only to open 3dmf) and in our old 32
bit app (which uses Quesa a lot).

Will you be checking it into CVS?

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[James W. W. <os...@jw...>]

I've done the instance data revision, and posted the changed files here:

<ftp://ftp.jwwalker.com/misc/instance_data_fix.zip>

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[James W. W. <os...@jw...>]

On Apr 17, 2009, at 4:16 AM, Roger Holmes wrote:

> I have forgotten how to use CVS (and never was very confident with it)
> and don't really want to re-learn it, sorry.

That's pretty much how I feel about Subversion, though it sounds like  
I'm in a minority of one.

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[James W. W. <os...@jw...>]

I'm working on the update.  Roger's plan seems sound, except for one  
thing...


On Apr 15, 2009, at 2:29 PM, Roger Holmes wrote:

> When called for a class which adds more than one object to its
> base class it would have to be the sum of the sizeof ()s of those
> objects, however I don't think this will matter as such a class would
> probably not call GetInstanceSize.


I don' t trust the idea of adding up sizeof()s, so in cases where  
there is more than one instance member, I will wrap them up in a  
structure.

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[James W. <ja...@fr...>]

Sean McBride wrote:


> BTW, who else has commit privileges, besides James?

Joe Strout

Jose Cruanyes

Roger Holmes

Kevin Matthews
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[Sean M. <se...@ro...>]

On 4/17/09 12:16 PM, Roger Holmes said:

>> This sounds reasonable.  I don't know Quesa well enough to attempt
>> this... Roger or James, do one of you have the time/inclination?  I  
>> can
>> certainly do a code review and testing.
>
>I have forgotten how to use CVS (and never was very confident with it)  
>and don't really want to re-learn it, sorry. I am interested in doing  
>a 64 bit version of our application and and happy to advise. I guess  
>its a lot of work to convert the project to SVN. I could modify my  
>local files (some of which have now diverged quite a bit because I  
>have none of James' recent changes, but I think this area should be  
>safe) and give the changes but thats almost what I've done already. I  
>can't really test on 64 bit until we do the rest of the application,  
>and we are about a week away from release of a new version, so a bad  
>time.

Well, if after your impending release, you want to give it a go, I can
help with the CVS troubles.  I can zip up the complete Quesa source tree
and put it on our server, you can then download it over http, make your
changes, and send the changes back to me.  I can then review, test, and
generate a patch file for James.  

BTW, who else has commit privileges, besides James?

As for CVS, I'm no fan either.  Switching to svn would be great imho.

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[Lane R. <la...@if...>]

on Fri, Apr 17, 2009 Roger Holmes may have said:

>I have forgotten how to use CVS (and never was very confident with it)  
>and don't really want to re-learn it, sorry. I am interested in doing  
>a 64 bit version of our application and and happy to advise. I guess  
>its a lot of work to convert the project to SVN.

Actually any admin on the SF project can setup the svn quite easily, and
then it is a simple matter to import the latest checkout from CVS.

I would also like to see Quesa in svn, I've stopped checking out updates
due to this.

Lane Roathe
President    Ideas From the Deep  <http://www.ideasfromthedeep.com>
___________________________________________________________________
If we aren't supposed to eat animals, why are they made with meat?

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[James W. W. <os...@jw...>]

On Apr 17, 2009, at 4:16 AM, Roger Holmes wrote:

> I have forgotten how to use CVS (and never was very confident with it)
> and don't really want to re-learn it, sorry. I am interested in doing
> a 64 bit version of our application and and happy to advise. I guess
> its a lot of work to convert the project to SVN.

If we were going to switch version control systems, I'd prefer to go  
to Mercurial, which I'm now using at work and which is also available  
at SourceForge.  I wrote a Mac GUI for Mercurial.