Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Thomas Treichl wrote:

| They suggest to always use both macros with an && combination on modern systems
| (that's also the same that I somewhere read in the GNU GCC documentation but
| currently cannot find it anymore).

OK, I can add "&& defined (__MACH__)" to the test.

| John, you were asking for CGDirectDisplay.h and CGDisplayConfiguration.h on all
| systems? Generally yes, since MacOSX 10.3.9 and until at least 10.4.11 which is
| my system (Ben can you please verify on your 10.5.x system). Here is my output
| from a quick search:
|
| bash /Developer/SDKs $ find MacOSX10.3.9.sdk -iname CGDirectDisplay.h
|    MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/CGDirectDisplay.h
|    MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/CoreGraphics/CGDirectDisplay.h

OK.

| The other thing is that, John, you've written Carbon, not Cocoa. Cocoa is the
| ObjC way for accessing the Apple user interface, whereas Carbon is the C-API. In
| the changeset earlier you wrote
|
|    #elif defined (OCTAVE_USE_COCOA_API)  // FIXME -- what should this be called?
|
| which better should be changed to
|
|    #elif defined (OCTAVE_USE_CARBON_API)

I changed it to OCTAVE_USE_OS_X_API.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by Thomas Treichl
On Thursday, January 22, 2009, at 03:07PM, "Thomas Treichl" <[hidden email]> wrote:

>John, you were asking for CGDirectDisplay.h and CGDisplayConfiguration.h on all
>systems? Generally yes, since MacOSX 10.3.9 and until at least 10.4.11 which is
>my system (Ben can you please verify on your 10.5.x system).

Yes they also exist for Leopard. I wrote the short script below to do the job.

#!/bin/sh -ev
export INC="/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Headers"
g++ try.cc -Wl,-framework,ApplicationServices -I$INC -o try

Ben
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton

I assume the code snippet below was not intended to remain?

       std::cerr << depth << " bit depth" << std::endl;

Ben





changeset-MacOSX-display_info.patch (966 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Ben Abbott wrote:

|
| I assume the code snippet below was not intended to remain?
|
|        std::cerr << depth << " bit depth" << std::endl;

I removed it.

Thanks,

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
One more detail.

The commercial vendor allows the property "screenpixelsperinch" to be  
modified. I don't know if this is intentional or not, and don't have a  
preference either way, but I thought I'd mention it.

Ben


On Jan 22, 2009, at 9:41 PM, John W. Eaton wrote:

> On 22-Jan-2009, Ben Abbott wrote:
>
> |
> | I assume the code snippet below was not intended to remain?
> |
> |        std::cerr << depth << " bit depth" << std::endl;
>
> I removed it.
>
> Thanks,
>
> jwe

Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Thomas Treichl
In reply to this post by bpabbott
Ben Abbott schrieb:

> On Thursday, January 22, 2009, at 03:07PM, "Thomas Treichl" <[hidden email]> wrote:
>
>> John, you were asking for CGDirectDisplay.h and CGDisplayConfiguration.h on all
>> systems? Generally yes, since MacOSX 10.3.9 and until at least 10.4.11 which is
>> my system (Ben can you please verify on your 10.5.x system).
>
> Yes they also exist for Leopard. I wrote the short script below to do the job.
>
> #!/bin/sh -ev
> export INC="/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Headers"
> g++ try.cc -Wl,-framework,ApplicationServices -I$INC -o try
Hi Ben,

I had some problems with the example program that John wrote for us (also means
that I cannot compile the current Octave src/display.cc file). Can you please
verify my modified version that I attached to this email if this also works on
your 10.5 system (comments about what has been changed and what should be done
are included)... Does it compile and produce the same output?

Another thing is that on Mac we might have Carbon && X11. If this is the case
then should we still use Carbon or should we use the traditional Unix way, cf.
src/display.cc line 31ff ?

   Thomas

#include <iostream>

// I changed the following two #include lines because it's much easier
// to include just the right one header of the Carbon framework so
// that this simple line compiles foo-osx.cc without another -I flag:
//
//    g++ foo-osx.cc -framework Carbon -o foo-osx
//
// #include <CGDirectDisplay.h>
// #include <CGDisplayConfiguration.h>
#include <Carbon/Carbon.h>

int
main (void)
{
  CGDirectDisplayID display = CGMainDisplayID ();

  if (display)
    {

      size_t ht = CGDisplayPixelsHigh (display);
      size_t wd = CGDisplayPixelsWide (display);

      std::cerr << wd << "x" << ht << " pixels" << std::endl;

      CGSize sz_mm = CGDisplayScreenSize (display);

// In the next two code lines I replaced CGFloat by float because
// on my 10.4.11 system and on 10.3.x system the CGSize struct is
// defined in Developer/Headers/CFMCarbon/CGGeometry.h as
//
// struct CGSize {
//     float width;
//     float height;
// };
// typedef struct CGSize CGSize;

      float ht_mm = sz_mm.height;
      float wd_mm = sz_mm.width;

      std::cerr << wd_mm << "x" << ht_mm << " mm" << std::endl;

      double resy = wd * 25.4 / wd_mm;
      double resx = ht * 25.4 / ht_mm;

      std::cerr << resx << " resx" << std::endl;
      std::cerr << resy << " resx" << std::endl;

      std::cerr << (resx + resy) / 2 << " avg dpi" << std::endl;

      size_t depth = CGDisplayBitsPerPixel (display);

      std::cerr << depth << " bit depth" << std::endl;
    }
  else
    std::cerr << "failed to find display" << std::endl;

  return 0;
}
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton

On Friday, January 23, 2009, at 04:29PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> On Thursday, January 22, 2009, at 03:07PM, "Thomas Treichl" <[hidden email]> wrote:
>>
>>> John, you were asking for CGDirectDisplay.h and CGDisplayConfiguration.h on all
>>> systems? Generally yes, since MacOSX 10.3.9 and until at least 10.4.11 which is
>>> my system (Ben can you please verify on your 10.5.x system).
>>
>> Yes they also exist for Leopard. I wrote the short script below to do the job.
>>
>> #!/bin/sh -ev
>> export INC="/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Headers"
>> g++ try.cc -Wl,-framework,ApplicationServices -I$INC -o try
>
>Hi Ben,
>
>I had some problems with the example program that John wrote for us (also means
>that I cannot compile the current Octave src/display.cc file). Can you please
>verify my modified version that I attached to this email if this also works on
>your 10.5 system (comments about what has been changed and what should be done
>are included)... Does it compile and produce the same output?
>
>Another thing is that on Mac we might have Carbon && X11. If this is the case
>then should we still use Carbon or should we use the traditional Unix way, cf.
>src/display.cc line 31ff ?
>
>   Thomas
>

Nicely done.

$ g++ foo-osx.cc -framework Carbon -o foo-osx
$ ./foo-osx
1280x1024 pixels
380x310 mm
83.9019 resx
85.5579 resx
84.7299 avg dpi
32 bit depth

I was thinking about the duality of the Mac as well. How are we to determine if X11 or Carbon is to be used?

Run time option?

Build time option?

I assume Carbon is the proper default?

Ben


Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Thomas Treichl
Ben Abbott schrieb:

> Nicely done.
>
> $ g++ foo-osx.cc -framework Carbon -o foo-osx
> $ ./foo-osx
> 1280x1024 pixels
> 380x310 mm
> 83.9019 resx
> 85.5579 resx
> 84.7299 avg dpi
> 32 bit depth
>
> I was thinking about the duality of the Mac as well. How are we to determine if X11 or Carbon is to be used?
>
> Run time option?

I think this would be cool, but unnecessary. I just thought about it but the
X11.app must be on top of Carbon/Cocoa because we can use the Desktop without
X11.app. This means that X11.app either uses Carbon/Cocoa interface functions or
works beside it. I think Carbon here is definitively the faster way to go...

Why I was asking this question is more meant by: will or must there be added
more Core Mac Graphics functionality in the future and if this is true then
might it be better to use the same code than the traditional *nix systems?

> Build time option?

Good question, and my last question to John here before I prepare a changeset
tomorrow: Do we need a configure test to check for the LDFLAGS '-framework
Carbon' or can I just add this to the '*-*-darwin*)' flags of the
canonical_host_system in configure.in?

   Thomas

Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Thomas Treichl
Thomas Treichl schrieb:
>> Build time option?
>
> Good question, and my last question to John here before I prepare a
> changeset tomorrow: Do we need a configure test to check for the LDFLAGS
> '-framework Carbon' or can I just add this to the '*-*-darwin*)' flags
> of the canonical_host_system in configure.in?

Hi,

I've adjusted display.cc and I'd like to introduce the m4 macro
"OCTAVE_HAVE_FRAMEWORK". This script allows me to check for the compiler option
"-framework NAME" and take further arguments $2 and $3 as file prologue and file
body if some deeper tests should be performed. However, here is my output from
the ./configure run

   checking whether ld accepts -framework Carbon... yes
   configure: adding -Wl,-framework -Wl,Carbon to LDFLAGS

Compilation is successful and I also checked if the part HAVE_FRAMEWORK_CARBON
in display.cc is compiled (and not the X11 part). The output before was

   bash$ octave --quiet --eval 'get (0, "ScreenSize")'
   ans = 0   0   0   0

The correct new output is

   bash$ octave --quiet --eval 'get (0, "ScreenSize")'
   ans = 1      1   1680   1050

Ben can you please check if this works on your 10.5 system? If it works, can it
be included into the sources? Thanks,

   Thomas

# HG changeset patch
# User Thomas Treichl <[hidden email]>
# Date 1232912397 -3600
# Node ID 5ce72d54fb692fd8d8c2746020307f49725178bd
# Parent  79845b1793cf079861840b800a51b1b399b2dd63
Use Carbon framework to determine ScreenSize on Mac.

diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,7 +1,12 @@
+2009-01-25  John W. Eaton  <[hidden email]>
+
+ * aclocal.m4: Introduce new macro OCTAVE_HAVE_FRAMEWORK.
+        * configure.in: Include OCTAVE_HAVE_FRAMEWORK for Carbon.
+
 2009-01-22  John W. Eaton  <[hidden email]>
 
  * configure.in (AH_BOTTOM): Define OCTAVE_USE_OS_X_API if
- __APPLE__ and __MACK__ are defined.
+ __APPLE__ and __MACH__ are defined.
 
 2009-01-22  Jaroslav Hajek  <[hidden email]>
 
diff --git a/aclocal.m4 b/aclocal.m4
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -1270,4 +1270,29 @@
  AC_DEFINE(HAVE_FAST_INT_OPS,1,[Define if signed integers use two's complement])],
 [AC_MSG_RESULT([no])])
 AC_LANG_POP(C++)])
-
+dnl
+dnl Check to see if the compiler and the linker can handle the flags
+dnl "-framework $1" for the given prologue $2 and the given body $3
+dnl of a source file.  Arguments 2 and 3 optionally can also be empty.
+dnl If this test is dnl successful then perform $4, otherwise do $5.
+dnl
+dnl OCTAVE_HAVE_FRAMEWORK
+AC_DEFUN(OCTAVE_HAVE_FRAMEWORK, [
+  ac_safe=`echo "$1" | sed 'y%./+-:=%__p___%'`
+  AC_MSG_CHECKING(whether ${LD-ld} accepts -framework $1)
+  AC_CACHE_VAL(octave_cv_framework_$ac_safe, [
+    XLDFLAGS="$LDFLAGS"
+    LDFLAGS="$LDFLAGS -framework $1"
+    AC_LINK_IFELSE([AC_LANG_PROGRAM([$2], [$3])],
+      eval "octave_cv_framework_$ac_safe=yes",
+      eval "octave_cv_framework_$ac_safe=no")
+    LDFLAGS="$XLDFLAGS"
+  ])
+  if eval "test \"`echo '$octave_cv_framework_'$ac_safe`\" = yes"; then
+    AC_MSG_RESULT(yes)
+    [$4]
+  else
+    AC_MSG_RESULT(no)
+    [$5]
+  fi
+])
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -268,6 +268,15 @@
 
   AC_CHECK_LIB(X11, XrmInitialize, [X11_LIBS=-lX11], [X11_LIBS=])
   AC_SUBST(X11_LIBS)
+fi
+
+### On MacOSX system the Carbon framework is used to determine ScreenSize
+OCTAVE_HAVE_FRAMEWORK(Carbon, [#include <Carbon/Carbon.h>], [CGMainDisplayID ()],
+  [have_carbon="yes"], [have_carbon="no"])
+if test $have_carbon = "yes"; then
+  AC_DEFINE(HAVE_FRAMEWORK_CARBON, 1, [Define if framework CARBON is available.])
+  LDFLAGS="$LDFLAGS -Wl,-framework -Wl,Carbon"
+  AC_MSG_NOTICE([adding -Wl,-framework -Wl,Carbon to LDFLAGS])
 fi
 
 ### On Intel systems with gcc, we may need to compile with -mieee-fp
diff --git a/src/ChangeLog b/src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,7 @@
+2009-01-25  Thomas Treichl  <[hidden email]>
+
+ * display.cc: CGSize is a struct of 2 floats on older Macs.
+
 2009-01-24  Jaroslav Hajek  <[hidden email]>
 
  * pt-cell.cc (tree_cell::rvalue): Optimize the single row case.
diff --git a/src/display.cc b/src/display.cc
--- a/src/display.cc
+++ b/src/display.cc
@@ -28,9 +28,8 @@
 
 #if defined (OCTAVE_USE_WINDOWS_API)
 #include <Windows.h>
-#elif defined (OCTAVE_USE_OS_X_API)
-#include <CGDirectDisplay.h>
-#include <CGDisplayConfiguration.h>
+#elif defined (HAVE_FRAMEWORK_CARBON)
+#include <Carbon/Carbon.h>
 #elif defined (HAVE_X_WINDOWS)
 #include <X11/Xlib.h>
 #endif
@@ -65,7 +64,7 @@
   else
     warning ("no graphical display found");
 
-#elif defined (OCTAVE_USE_OS_X_API)
+#elif defined (HAVE_FRAMEWORK_CARBON)
 
   CGDirectDisplayID display = CGMainDisplayID ();
 
@@ -78,8 +77,11 @@
 
       CGSize sz_mm = CGDisplayScreenSize (display);
 
-      CGFloat ht_mm = sz_mm.height;
-      CGFloat wd_mm = sz_mm.width;
+      // On modern Mac systems (>= 10.5) CGSize is a struct keeping 2
+      // CGFloat values (typedef float CGFloat), on older systems (<=
+      // 10.4.11) it is a struct of two float values.
+      float ht_mm = sz_mm.height;
+      float wd_mm = sz_mm.width;
 
       rx = wd * 25.4 / wd_mm;
       ry = ht * 25.4 / ht_mm;
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator

On Jan 25, 2009, at 3:54 PM, Thomas Treichl wrote:

> Ben can you please check if this works on your 10.5 system? If it  
> works, can it be included into the sources? Thanks,

I'll give it a shot. Might OpenGL and vecLib also be handled in a  
similar way?

Ben


Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by Thomas Treichl

On Jan 25, 2009, at 3:54 PM, Thomas Treichl wrote:

> Ben can you please check if this works on your 10.5 system? If it  
> works, can it be included into the sources? Thanks,

Thomas,

The changeset did not apply for me.

hg import "$path2changesets/../changeset-framework.patch"
applying /Users/bpabbott/Development/mercurial/changesets/
uncommited/../changeset-framework.patch
patching file ChangeLog
Hunk #1 FAILED at 0
1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej
patching file aclocal.m4
Hunk #1 FAILED at 1269
1 out of 1 hunk FAILED -- saving rejects to file aclocal.m4.rej
patching file configure.in
Hunk #1 FAILED at 267
1 out of 1 hunk FAILED -- saving rejects to file configure.in.rej
patching file src/ChangeLog
Hunk #1 FAILED at 0
1 out of 1 hunk FAILED -- saving rejects to file src/ChangeLog.rej
patching file src/display.cc
Hunk #1 FAILED at 27
Hunk #2 FAILED at 64
Hunk #3 FAILED at 77
3 out of 3 hunks FAILED -- saving rejects to file src/display.cc.rej
abort: patch failed to apply

It is likely Mail.app has modified the EOL character(s). Please send  
the changeset as an attachment.

Ben
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Thomas Treichl
> On Jan 25, 2009, at 3:54 PM, Thomas Treichl wrote:
>
> > Ben can you please check if this works on your 10.5 system? If it  
> > works, can it be included into the sources? Thanks,
>
> Thomas,
>
> The changeset did not apply for me.
>
> hg import "$path2changesets/../changeset-framework.patch"
> applying /Users/bpabbott/Development/mercurial/changesets/
> uncommited/../changeset-framework.patch
> patching file ChangeLog
> Hunk #1 FAILED at 0
> 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej
> patching file aclocal.m4
> Hunk #1 FAILED at 1269
> 1 out of 1 hunk FAILED -- saving rejects to file aclocal.m4.rej
> patching file configure.in
> Hunk #1 FAILED at 267
> 1 out of 1 hunk FAILED -- saving rejects to file configure.in.rej
> patching file src/ChangeLog
> Hunk #1 FAILED at 0
> 1 out of 1 hunk FAILED -- saving rejects to file src/ChangeLog.rej
> patching file src/display.cc
> Hunk #1 FAILED at 27
> Hunk #2 FAILED at 64
> Hunk #3 FAILED at 77
> 3 out of 3 hunks FAILED -- saving rejects to file src/display.cc.rej
> abort: patch failed to apply
>
> It is likely Mail.app has modified the EOL character(s). Please send  
> the changeset as an attachment.
>
> Ben

Hi Ben,

I sent the changeset as an attachment as usual, I'm using Thunderbird as an Email client. Currently I don't have access to my Mac but I can try once again later. If it doesn't work the second time then we use that other trick ;)

About your other question (frameworks vecLib, OpenGL): I kept the OCTAVE_HAVE_FRAMEWORK general, ie. we can use this macro to check for both frameworks, too. However, I think we should not change the test for framwork vecLib - it works perfectly as is, but we're still missing the way to compile against framework OpenGL. I was planing to work on the implementation of framework OpenGL the following days, I'll start a new discussion about it...

Best regards,

  Thomas

--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator

On Jan 26, 2009, at 2:55 AM, Thomas Treichl wrote:

>> On Jan 25, 2009, at 3:54 PM, Thomas Treichl wrote:
>>
>>> Ben can you please check if this works on your 10.5 system? If it
>>> works, can it be included into the sources? Thanks,
>>
>> Thomas,
>>
>> The changeset did not apply for me.
>>
>> hg import "$path2changesets/../changeset-framework.patch"
>> applying /Users/bpabbott/Development/mercurial/changesets/
>> uncommited/../changeset-framework.patch
>> patching file ChangeLog
>> Hunk #1 FAILED at 0
>> 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej
>> patching file aclocal.m4
>> Hunk #1 FAILED at 1269
>> 1 out of 1 hunk FAILED -- saving rejects to file aclocal.m4.rej
>> patching file configure.in
>> Hunk #1 FAILED at 267
>> 1 out of 1 hunk FAILED -- saving rejects to file configure.in.rej
>> patching file src/ChangeLog
>> Hunk #1 FAILED at 0
>> 1 out of 1 hunk FAILED -- saving rejects to file src/ChangeLog.rej
>> patching file src/display.cc
>> Hunk #1 FAILED at 27
>> Hunk #2 FAILED at 64
>> Hunk #3 FAILED at 77
>> 3 out of 3 hunks FAILED -- saving rejects to file src/display.cc.rej
>> abort: patch failed to apply
>>
>> It is likely Mail.app has modified the EOL character(s). Please send
>> the changeset as an attachment.
>>
>> Ben
>
> Hi Ben,
>
> I sent the changeset as an attachment as usual, I'm using  
> Thunderbird as an Email client. Currently I don't have access to my  
> Mac but I can try once again later. If it doesn't work the second  
> time then we use that other trick ;)
>
> About your other question (frameworks vecLib, OpenGL): I kept the  
> OCTAVE_HAVE_FRAMEWORK general, ie. we can use this macro to check  
> for both frameworks, too. However, I think we should not change the  
> test for framwork vecLib - it works perfectly as is, but we're still  
> missing the way to compile against framework OpenGL. I was planing  
> to work on the implementation of framework OpenGL the following  
> days, I'll start a new discussion about it...
>
> Best regards,
>
>  Thomas

Nice idea with regards to pulling the patch from the mail list.

The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see  
below).

To my surprise configure had no trouble with vecLib either. It wasn't  
working for me the last time I looked, and had been opting for the  
blas that comes with Octave.

Ben

configure: defining UGLY_DEFS to be -DPACKAGE_NAME=\\\\\"\\\\\" -
DPACKAGE_TARNAME=\\\\\"\\\\\" -DPACKAGE_VERSION=\\\\\"\\\\\" -
DPACKAGE_STRING=\\\\\"\\\\\" -DPACKAGE_BUGREPORT=\\\\\"\\\\\" -
DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -
D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -
D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -
D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -
D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -
D_TANDEM_SOURCE=1 -DSEPCHAR=\':\' -DSEPCHAR_STR=\\\\\":\\\\\" -
D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -
DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -
DHAVE_FRAMEWORK_CARBON=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -
DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -
DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -
DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -
DHAVE_OPENGL_GL_H=1 -DHAVE_OPENGL_GLU_H=1 -DHAVE_OPENGL=1 -
DHAVE_FTGL_FTGL_H=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -
DF77_FUNC\(name,NAME\)=name\ \#\#\ _ -DF77_FUNC_\(name,NAME\)=name\ \#
\#\ __ -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -
DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -
DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -
DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -
DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -
DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -
DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -
DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1  
-DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -
DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -
DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -
DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -
DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -
DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -
DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -
DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -
DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -
DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -
DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -
DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -
DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -
DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_SGTTY_H=1 -
DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -
DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -
DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -
DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -
DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -
DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -
DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -
DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -
DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -
DHAVE_LGAMMAF=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -
DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -
DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -
DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -
DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -
DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -
DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -
DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -
DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1  
-DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -
DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -
DHAVE_TGAMMA=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -
DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -
DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1  
-DHAVE_STRFTIME=1 -DHAVE_DYLD_API=1 -DENABLE_DYNAMIC_LINKING=1 -
DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -
DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -
DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -
DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2=1 -
DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -
DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -
DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -
DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -
DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -
DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -
DYYTEXT_POINTER=1


Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Thomas Treichl
Ben Abbott schrieb:
> Nice idea with regards to pulling the patch from the mail list.
>
> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
> below).

Ok, fine. I hope it also compiles and produces the right output? Then I'll try
to implement two more improvements before I continue with "-framework OpenGL"
the next days - coming back to your idea about the build option:

(a) Allow the user to turn on/off support for Carbon when doing "./configure",
this might then look somehow like this

   ./configure --with-framework-carbon

which also is the default and "--with-framework-carbon" must not be given
explicitly. Or turn off this support with

   ./configure --without-framework-carbon

so that we have the fallback to use X11.app instead or at least if the user set
up his system correctly, ie. just use *nix traditional way.

Given the name "--with-framework-carbon" and not only "--with-carbon" looking
forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
a bit different in their implementation (details soon).

(b) Turn off empty output of configuration summary if Carbon is used, eg.

   X11 include flags:
   X11 libraries:

and turn on output about Carbon framework instead, eg.

   Carbon libraries: -Wl,-framework -Wl,Carbon

Should I send a combined changeset or an improvement of my first patch? Any
other objections?

Best regards,

   Thomas
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
 
On Monday, January 26, 2009, at 03:38PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> Nice idea with regards to pulling the patch from the mail list.
>>
>> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
>> below).
>
>Ok, fine. I hope it also compiles and produces the right output? Then I'll try
>to implement two more improvements before I continue with "-framework OpenGL"
>the next days - coming back to your idea about the build option:
>
>(a) Allow the user to turn on/off support for Carbon when doing "./configure",
>this might then look somehow like this
>
>   ./configure --with-framework-carbon
>
>which also is the default and "--with-framework-carbon" must not be given
>explicitly. Or turn off this support with
>
>   ./configure --without-framework-carbon
>
>so that we have the fallback to use X11.app instead or at least if the user set
>up his system correctly, ie. just use *nix traditional way.
>
>Given the name "--with-framework-carbon" and not only "--with-carbon" looking
>forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
>and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
>a bit different in their implementation (details soon).
>
>(b) Turn off empty output of configuration summary if Carbon is used, eg.
>
>   X11 include flags:
>   X11 libraries:
>
>and turn on output about Carbon framework instead, eg.
>
>   Carbon libraries: -Wl,-framework -Wl,Carbon
>
>Should I send a combined changeset or an improvement of my first patch? Any
>other objections?
>
>Best regards,
>
>   Thomas

Octave did build and then shortly after my Mac froze :-(

I've repaired disk permissions and am hoping for the best.

In any event, all tests except for dispatch.cc and data.cc passed. Those two failures have been with me prior to your patch, so all looks good to me.

I'm no expert of changelog protocol, but I think one changeset makes sense.

Let me know when you're ready and I'll test drive it on 10.5.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
 
On Monday, January 26, 2009, at 03:38PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> Nice idea with regards to pulling the patch from the mail list.
>>
>> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
>> below).
>
>Ok, fine. I hope it also compiles and produces the right output? Then I'll try
>to implement two more improvements before I continue with "-framework OpenGL"
>the next days - coming back to your idea about the build option:
>
>(a) Allow the user to turn on/off support for Carbon when doing "./configure",
>this might then look somehow like this
>
>   ./configure --with-framework-carbon
>
>which also is the default and "--with-framework-carbon" must not be given
>explicitly. Or turn off this support with
>
>   ./configure --without-framework-carbon
>
>so that we have the fallback to use X11.app instead or at least if the user set
>up his system correctly, ie. just use *nix traditional way.
>
>Given the name "--with-framework-carbon" and not only "--with-carbon" looking
>forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
>and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
>a bit different in their implementation (details soon).
>
>(b) Turn off empty output of configuration summary if Carbon is used, eg.
>
>   X11 include flags:
>   X11 libraries:
>
>and turn on output about Carbon framework instead, eg.
>
>   Carbon libraries: -Wl,-framework -Wl,Carbon
>
>Should I send a combined changeset or an improvement of my first patch? Any
>other objections?
>
>Best regards,
>
>   Thomas

Octave did build and then shortly after my Mac froze :-(

I've repaired disk permissions and am hoping for the best.

In any event, all tests except for dispatch.cc and data.cc passed. Those two failures have been with me prior to your patch, so all looks good to me.

I'm no expert of changelog protocol, but I think one changeset makes sense.

Let me know when you're ready and I'll test drive it on 10.5.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
 
On Monday, January 26, 2009, at 03:38PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> Nice idea with regards to pulling the patch from the mail list.
>>
>> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
>> below).
>
>Ok, fine. I hope it also compiles and produces the right output? Then I'll try
>to implement two more improvements before I continue with "-framework OpenGL"
>the next days - coming back to your idea about the build option:
>
>(a) Allow the user to turn on/off support for Carbon when doing "./configure",
>this might then look somehow like this
>
>   ./configure --with-framework-carbon
>
>which also is the default and "--with-framework-carbon" must not be given
>explicitly. Or turn off this support with
>
>   ./configure --without-framework-carbon
>
>so that we have the fallback to use X11.app instead or at least if the user set
>up his system correctly, ie. just use *nix traditional way.
>
>Given the name "--with-framework-carbon" and not only "--with-carbon" looking
>forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
>and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
>a bit different in their implementation (details soon).
>
>(b) Turn off empty output of configuration summary if Carbon is used, eg.
>
>   X11 include flags:
>   X11 libraries:
>
>and turn on output about Carbon framework instead, eg.
>
>   Carbon libraries: -Wl,-framework -Wl,Carbon
>
>Should I send a combined changeset or an improvement of my first patch? Any
>other objections?
>
>Best regards,
>
>   Thomas

Octave did build and then shortly after my Mac froze :-(

I've repaired disk permissions and am hoping for the best.

In any event, all tests except for dispatch.cc and data.cc passed. Those two failures have been with me prior to your patch, so all looks good to me.

I'm no expert of changelog protocol, but I think one changeset makes sense.

Let me know when you're ready and I'll test drive it on 10.5.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
 
On Monday, January 26, 2009, at 03:38PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> Nice idea with regards to pulling the patch from the mail list.
>>
>> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
>> below).
>
>Ok, fine. I hope it also compiles and produces the right output? Then I'll try
>to implement two more improvements before I continue with "-framework OpenGL"
>the next days - coming back to your idea about the build option:
>
>(a) Allow the user to turn on/off support for Carbon when doing "./configure",
>this might then look somehow like this
>
>   ./configure --with-framework-carbon
>
>which also is the default and "--with-framework-carbon" must not be given
>explicitly. Or turn off this support with
>
>   ./configure --without-framework-carbon
>
>so that we have the fallback to use X11.app instead or at least if the user set
>up his system correctly, ie. just use *nix traditional way.
>
>Given the name "--with-framework-carbon" and not only "--with-carbon" looking
>forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
>and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
>a bit different in their implementation (details soon).
>
>(b) Turn off empty output of configuration summary if Carbon is used, eg.
>
>   X11 include flags:
>   X11 libraries:
>
>and turn on output about Carbon framework instead, eg.
>
>   Carbon libraries: -Wl,-framework -Wl,Carbon
>
>Should I send a combined changeset or an improvement of my first patch? Any
>other objections?
>
>Best regards,
>
>   Thomas

Octave did build and then shortly after my Mac froze :-(

I've repaired disk permissions and am hoping for the best.

In any event, all tests except for dispatch.cc and data.cc passed. Those two failures have been with me prior to your patch, so all looks good to me.

I'm no expert of changelog protocol, but I think one changeset makes sense.

Let me know when you're ready and I'll test drive it on 10.5.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
 
On Monday, January 26, 2009, at 03:38PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> Nice idea with regards to pulling the patch from the mail list.
>>
>> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
>> below).
>
>Ok, fine. I hope it also compiles and produces the right output? Then I'll try
>to implement two more improvements before I continue with "-framework OpenGL"
>the next days - coming back to your idea about the build option:
>
>(a) Allow the user to turn on/off support for Carbon when doing "./configure",
>this might then look somehow like this
>
>   ./configure --with-framework-carbon
>
>which also is the default and "--with-framework-carbon" must not be given
>explicitly. Or turn off this support with
>
>   ./configure --without-framework-carbon
>
>so that we have the fallback to use X11.app instead or at least if the user set
>up his system correctly, ie. just use *nix traditional way.
>
>Given the name "--with-framework-carbon" and not only "--with-carbon" looking
>forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
>and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
>a bit different in their implementation (details soon).
>
>(b) Turn off empty output of configuration summary if Carbon is used, eg.
>
>   X11 include flags:
>   X11 libraries:
>
>and turn on output about Carbon framework instead, eg.
>
>   Carbon libraries: -Wl,-framework -Wl,Carbon
>
>Should I send a combined changeset or an improvement of my first patch? Any
>other objections?
>
>Best regards,
>
>   Thomas

Octave did build and then shortly after my Mac froze :-(

I've repaired disk permissions and am hoping for the best.

In any event, all tests except for dispatch.cc and data.cc passed. Those two failures have been with me prior to your patch, so all looks good to me.

I'm no expert of changelog protocol, but I think one changeset makes sense.

Let me know when you're ready and I'll test drive it on 10.5.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by Thomas Treichl
On Monday, January 26, 2009, at 03:38PM, "Thomas Treichl" <[hidden email]> wrote:

>Ben Abbott schrieb:
>> Nice idea with regards to pulling the patch from the mail list.
>>
>> The configure process did respond with DHAVE_FRAMEWORK_CARBON=1 (see
>> below).
>
>Ok, fine. I hope it also compiles and produces the right output? Then I'll try
>to implement two more improvements before I continue with "-framework OpenGL"
>the next days - coming back to your idea about the build option:
>
>(a) Allow the user to turn on/off support for Carbon when doing "./configure",
>this might then look somehow like this
>
>   ./configure --with-framework-carbon
>
>which also is the default and "--with-framework-carbon" must not be given
>explicitly. Or turn off this support with
>
>   ./configure --without-framework-carbon
>
>so that we have the fallback to use X11.app instead or at least if the user set
>up his system correctly, ie. just use *nix traditional way.
>
>Given the name "--with-framework-carbon" and not only "--with-carbon" looking
>forward to also separate "--with-framework-opengl" from traditional X11/OpenGL
>and we have both "framework OpenGL" and "X11 OpenGL" on Macs that also are quite
>a bit different in their implementation (details soon).
>
>(b) Turn off empty output of configuration summary if Carbon is used, eg.
>
>   X11 include flags:
>   X11 libraries:
>
>and turn on output about Carbon framework instead, eg.
>
>   Carbon libraries: -Wl,-framework -Wl,Carbon
>
>Should I send a combined changeset or an improvement of my first patch? Any
>other objections?
>
>Best regards,
>
>   Thomas
>

Octave did build and then, shortly after, my Mac froze :-(

I've repaired disk permissions and am hoping for the best.

In any event, all tests except for dispatch.cc and data.cc passed. Those two failures have been with me prior to your patch, so all looks good to me.

I'm no expert of changelog protocol, but I think one changeset makes sense.

Let me know when you're ready and I'll test drive it on 10.5.

Ben
123