Menu
▾
▴
vrjuggler-devel — List for VR Juggler developers to discuss new features and bugs in current code.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(23) |
Nov
(2) |
Dec
(26) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(18) |
Feb
(19) |
Mar
(16) |
Apr
(28) |
May
(23) |
Jun
(13) |
Jul
(10) |
Aug
(24) |
Sep
(23) |
Oct
(61) |
Nov
(76) |
Dec
(203) |
| 2002 |
Jan
(103) |
Feb
(35) |
Mar
(23) |
Apr
(49) |
May
(22) |
Jun
(78) |
Jul
(21) |
Aug
(60) |
Sep
(65) |
Oct
(68) |
Nov
(25) |
Dec
(17) |
| 2003 |
Jan
(58) |
Feb
(65) |
Mar
(60) |
Apr
(58) |
May
(34) |
Jun
(62) |
Jul
(85) |
Aug
(43) |
Sep
(66) |
Oct
(32) |
Nov
(56) |
Dec
(28) |
| 2004 |
Jan
(21) |
Feb
(11) |
Mar
(18) |
Apr
(18) |
May
(36) |
Jun
(24) |
Jul
(34) |
Aug
(28) |
Sep
(51) |
Oct
(91) |
Nov
(68) |
Dec
(43) |
| 2005 |
Jan
(39) |
Feb
(42) |
Mar
(40) |
Apr
(37) |
May
(21) |
Jun
(58) |
Jul
(36) |
Aug
(30) |
Sep
(7) |
Oct
(2) |
Nov
(41) |
Dec
(5) |
| 2006 |
Jan
|
Feb
(37) |
Mar
(6) |
Apr
(21) |
May
(64) |
Jun
(18) |
Jul
(32) |
Aug
(23) |
Sep
(33) |
Oct
(33) |
Nov
(115) |
Dec
(47) |
| 2007 |
Jan
(14) |
Feb
(37) |
Mar
(74) |
Apr
(57) |
May
(62) |
Jun
(38) |
Jul
(86) |
Aug
(21) |
Sep
(62) |
Oct
(16) |
Nov
(24) |
Dec
(26) |
| 2008 |
Jan
(29) |
Feb
(33) |
Mar
(1) |
Apr
(6) |
May
(1) |
Jun
(6) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(17) |
Dec
(7) |
| 2009 |
Jan
(4) |
Feb
(12) |
Mar
(22) |
Apr
(19) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(10) |
Sep
(7) |
Oct
(19) |
Nov
(3) |
Dec
|
|
From: Patrick H. <pa...@pr...> - 2009-11-13 23:32:31
|
The VR Juggler Subversion repository is now hosted on Google Code. This is a new repository, and that means that you cannot move an existing checkout over to it using 'svn switch'. If you have local changes in a repository, I suggest using 'svn diff' to create a patch file, checking out from the new repository, and then applying your patch. Something like this would get the job done: cd /path/to/juggler/root svn diff > ../old-repos.patch cd .. svn co http://vrjuggler.googlecode.com/svn/... juggler-new cd juggler-new patch -p0 < ../old-repos.patch For more information on the new repository, see these pages: https://developer.vrjuggler.org/wiki/BuildingFromSvn http://code.google.com/p/vrjuggler/source/checkout Getting subscriptions to this list moved over to the new Google Groups list is about halfway complete. At the moment, Google is not allowing me to add more subscribers, but I expect to be able to complete the list transition sometime this weekend. You should be receiving notifications about being subscribed to the new list, and then you will get a notification about being unsubscribed from this list. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Patrick H. <pa...@pr...> - 2009-11-13 01:07:03
|
The migration of subscriptions from this SourceForge list to the new Google Groups list will start soon. The process of migrating vrjuggler-info subscriptions ended up being more complicated than I expected. As a result of that, I am going to populate the vrjuggler-devel Google Groups list before removing the SourceForge subscriptions. With any luck, that will help the process go more smoothly without necessarily resulting in the forum being unavailable during the migration. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Patrick H. <pa...@pr...> - 2009-11-06 22:26:18
|
We are in the process of moving VR Juggler to Google Code in order to
improve availability of the site and the code. The new project page
can be found here:
http://code.google.com/p/vrjuggler/
The Subversion repository is in the process of being uploaded as I
type this. The main website will remain at www.vrjuggler.org until
such time as we find the most suitable way to move it to Google Code.
The Trac wiki will transition over to the Google Code wiki once the
repository sync completes.
To complete the consolidation under the Google Code umbrella, the
SourceForge mailing lists will change to Google Groups. This weekend,
I will be converting everyone's subscription over to the new lists,
and you should receive a welcome message when your subscription
changes. The SourceForge project will continue to exist since it has
the full list archives, but the SourceForge lists will no longer be
available for posting. Beyond that, the SourceForge project will be
defunct.
The list changes are as follows:
vrj...@li... -> vrj...@go...
vrj...@li... -> vrj...@go...
vrj...@li... -> vrj...@go...
There will also be a new (low-traffic) list *only* for announcements
named vrj...@go....
-Patrick
--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/
The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.
|
|
From: Patrick H. <pa...@pr...> - 2009-10-29 16:18:25
|
On Oct 29, 2009, at 11:10 AM, Doug McCorkle wrote: >> On Oct 29, 2009, at 10:48 AM, Doug McCorkle wrote: >> >>>> On Oct 29, 2009, at 10:32 AM, Doug McCorkle wrote: >>>> >>>>> Hello, >>>>> >>>>> I am getting this failure on Mac OS 10.6 x64: >>>>> >>>>> g++ -DHAVE_CONFIG_H >>>>> -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" > -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ >>>>> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal >>>>> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config >>>>> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common >>>>> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common > -fno-common -pipe >>>>> -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/ >>>>> flagpoll/../../include/vpr-2.1.15 >>>>> -I/opt/local/include >>>>> -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/ >>>>> flagpoll/../../ > include/cppdom-1.1.0 >>>>> -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict- >>>>> aliasing >>>>> -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign- >>>>> promo > -Wnon-virtual-dtor -c -o >>>>> /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/ >>>>> Darwin/ > Mach-O/x86_64/opt/libjccl/jcclmain.o >>>>> /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/ > jcclmain.cpp >>>>> g++-4.2: Invalid arch name : -pthread >>>>> >>>>> It looks like -pthread is not being placed properly with the - >>>>> arch link >>>>> option. Is there an easy fix? >>>> >>>> Are you using the latest source? I made build system changes over >>>> the > weekend that got everything to build and run correctly for me. >>>> >>> >>> Yes. We updated this morning and got the updated docbook file. >> >> Updated docbook file? That doesn't have anything to do with the >> build, > and those files haven't changed in nearly two years. Are you building > from the trunk or the 2.2 branch? > > I am on trunk. I am just pointing out that we got the updated file > that > you committed last night. I know it has nothing to do with the build. > >> >>> We then >>> made a new build directory and configured with the x86_64 abi >>> option flag. >> >> Don't pass an ABI flag in; the default detection will get it right. >> When > trying to choose an ABI on OS X, I think that there is a bug > associated > with something or other, but I haven't had time to track it down. That > probably means that building a universal binary won't work, too. > > We were going off of your previous email on the info list which said > to > pass in the abi flag to get 64 bit on snow leopard to work. Yeah, I was wrong about doing that. The result at the time was the same as what you saw. It took me a while to get it fixed because I was gone for two weeks right after posting that bad information. > We had to change all of these files: > > ./gadgeteer/common.defs.mk > ./gadgeteer/drivers/common.defs.mk > ./gadgeteer/plugins/common.defs.mk > ./jackal/common.defs.mk > ./jackal/plugins/common.defs.mk > ./sonix/common.defs.mk > ./sonix/plugins/common.defs.mk > ./tweek/common.defs.mk > ./vapor/common.defs.mk > ./vrjuggler/common.defs.mk All of which are generated by the respective module's configure script. Since they all required the fix, the bug related to ABI selection on OS X pretty much has to be in Doozer++. I don't know what the problem is, mainly because it wasn't immediately obvious to me. It's probably something subtle that broke a long time ago, but no one noticed because people don't generally use --with-abi. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-10-29 16:10:38
|
> On Oct 29, 2009, at 10:48 AM, Doug McCorkle wrote: > >>> On Oct 29, 2009, at 10:32 AM, Doug McCorkle wrote: >>> >>>> Hello, >>>> >>>> I am getting this failure on Mac OS 10.6 x64: >>>> >>>> g++ -DHAVE_CONFIG_H >>>> -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ >>>> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal >>>> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config >>>> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common >>>> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common -fno-common -pipe >>>> -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/ >>>> flagpoll/../../include/vpr-2.1.15 >>>> -I/opt/local/include >>>> -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/flagpoll/../../ include/cppdom-1.1.0 >>>> -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict- aliasing >>>> -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign-promo -Wnon-virtual-dtor -c -o >>>> /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/Darwin/ Mach-O/x86_64/opt/libjccl/jcclmain.o >>>> /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/ jcclmain.cpp >>>> g++-4.2: Invalid arch name : -pthread >>>> >>>> It looks like -pthread is not being placed properly with the -arch link >>>> option. Is there an easy fix? >>> >>> Are you using the latest source? I made build system changes over the weekend that got everything to build and run correctly for me. >>> >> >> Yes. We updated this morning and got the updated docbook file. > > Updated docbook file? That doesn't have anything to do with the build, and those files haven't changed in nearly two years. Are you building from the trunk or the 2.2 branch? I am on trunk. I am just pointing out that we got the updated file that you committed last night. I know it has nothing to do with the build. > >> We then >> made a new build directory and configured with the x86_64 abi option flag. > > Don't pass an ABI flag in; the default detection will get it right. When trying to choose an ABI on OS X, I think that there is a bug associated with something or other, but I haven't had time to track it down. That probably means that building a universal binary won't work, too. We were going off of your previous email on the info list which said to pass in the abi flag to get 64 bit on snow leopard to work. We had to change all of these files: ./gadgeteer/common.defs.mk ./gadgeteer/drivers/common.defs.mk ./gadgeteer/plugins/common.defs.mk ./jackal/common.defs.mk ./jackal/plugins/common.defs.mk ./sonix/common.defs.mk ./sonix/plugins/common.defs.mk ./tweek/common.defs.mk ./vapor/common.defs.mk ./vrjuggler/common.defs.mk Doug |
|
From: Patrick H. <pa...@pr...> - 2009-10-29 15:58:37
|
On Oct 29, 2009, at 10:48 AM, Doug McCorkle wrote: >> On Oct 29, 2009, at 10:32 AM, Doug McCorkle wrote: >> >>> Hello, >>> >>> I am getting this failure on Mac OS 10.6 x64: >>> >>> g++ -DHAVE_CONFIG_H >>> -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" >>> -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ >>> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal >>> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config >>> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common >>> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common >>> -fno-common -pipe >>> -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/ >>> flagpoll/../../include/vpr-2.1.15 >>> -I/opt/local/include >>> -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/flagpoll/../../ >>> include/cppdom-1.1.0 >>> -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict- >>> aliasing >>> -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign-promo >>> -Wnon-virtual-dtor -c -o >>> /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/Darwin/ >>> Mach-O/x86_64/opt/libjccl/jcclmain.o >>> /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/ >>> jcclmain.cpp >>> g++-4.2: Invalid arch name : -pthread >>> >>> It looks like -pthread is not being placed properly with the -arch >>> link >>> option. Is there an easy fix? >> >> Are you using the latest source? I made build system changes over the >> weekend that got everything to build and run correctly for me. >> > > Yes. We updated this morning and got the updated docbook file. Updated docbook file? That doesn't have anything to do with the build, and those files haven't changed in nearly two years. Are you building from the trunk or the 2.2 branch? > We then > made a new build directory and configured with the x86_64 abi option > flag. Don't pass an ABI flag in; the default detection will get it right. When trying to choose an ABI on OS X, I think that there is a bug associated with something or other, but I haven't had time to track it down. That probably means that building a universal binary won't work, too. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-10-29 15:48:34
|
> On Oct 29, 2009, at 10:32 AM, Doug McCorkle wrote: > >> Hello, >> >> I am getting this failure on Mac OS 10.6 x64: >> >> g++ -DHAVE_CONFIG_H >> -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" >> -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ >> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal >> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config >> -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common >> -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common >> -fno-common -pipe >> -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/ >> flagpoll/../../include/vpr-2.1.15 >> -I/opt/local/include >> -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/flagpoll/../../ >> include/cppdom-1.1.0 >> -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict-aliasing >> -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign-promo >> -Wnon-virtual-dtor -c -o >> /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/Darwin/ >> Mach-O/x86_64/opt/libjccl/jcclmain.o >> /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/ >> jcclmain.cpp >> g++-4.2: Invalid arch name : -pthread >> >> It looks like -pthread is not being placed properly with the -arch >> link >> option. Is there an easy fix? > > Are you using the latest source? I made build system changes over the > weekend that got everything to build and run correctly for me. > Yes. We updated this morning and got the updated docbook file. We then made a new build directory and configured with the x86_64 abi option flag. It also appears this (bad flag order problem) is a problem in the sonix and gadgeteer modules as well. Doug |
|
From: Doug M. <mc...@ia...> - 2009-10-29 15:39:50
|
I fixed this by manually changing the modules/jackal/common.defs.mk file lines 179 and 188 to not place -pthread between the -arch flag and its value. I am not sure what the permanent fix would be. Doug > Hello, > > I am getting this failure on Mac OS 10.6 x64: > > g++ -DHAVE_CONFIG_H > -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" > -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ > -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal > -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config > -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common > -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common > -fno-common -pipe > -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/flagpoll/../../include/vpr-2.1.15 > -I/opt/local/include > -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/flagpoll/../../include/cppdom-1.1.0 > -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict-aliasing > -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign-promo > -Wnon-virtual-dtor -c -o > /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/Darwin/Mach-O/x86_64/opt/libjccl/jcclmain.o > /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/jcclmain.cpp > g++-4.2: Invalid arch name : -pthread > > It looks like -pthread is not being placed properly with the -arch link > option. Is there an easy fix? > > Doug |
|
From: Patrick H. <pa...@pr...> - 2009-10-29 15:39:41
|
On Oct 29, 2009, at 10:32 AM, Doug McCorkle wrote: > Hello, > > I am getting this failure on Mac OS 10.6 x64: > > g++ -DHAVE_CONFIG_H > -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" > -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ > -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal > -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config > -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common > -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common > -fno-common -pipe > -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/ > flagpoll/../../include/vpr-2.1.15 > -I/opt/local/include > -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/flagpoll/../../ > include/cppdom-1.1.0 > -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict-aliasing > -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign-promo > -Wnon-virtual-dtor -c -o > /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/Darwin/ > Mach-O/x86_64/opt/libjccl/jcclmain.o > /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/ > jcclmain.cpp > g++-4.2: Invalid arch name : -pthread > > It looks like -pthread is not being placed properly with the -arch > link > option. Is there an easy fix? Are you using the latest source? I made build system changes over the weekend that got everything to build and run correctly for me. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-10-29 15:32:58
|
Hello, I am getting this failure on Mac OS 10.6 x64: g++ -DHAVE_CONFIG_H -DJCCL_ROOT_DIR="\"/Users/kochjb/devel/deps/vrjuggler_install/\"" -DJCCL_SHARE_DIR="\"share/jccl-1.3.5\"" -D_JCCL_BUILD_ -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/config -I/Users/kochjb/devel/deps/vrjuggler/modules/jackal/common -I/Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/common -fno-common -pipe -I/Users/kochjb/devel/deps/vrjuggler_build/instlinks/share/flagpoll/../../include/vpr-2.1.15 -I/opt/local/include -I/Users/kochjb/devel/deps/xml-cppdom_install/lib64/flagpoll/../../include/cppdom-1.1.0 -arch -pthread x86_64 -DJUGGLER_OPT -DNDEBUG -O2 -fno-strict-aliasing -fPIC -DPIC -arch x86_64 -Wall -W -Woverloaded-virtual -Wsign-promo -Wnon-virtual-dtor -c -o /Users/kochjb/devel/deps/vrjuggler_build/modules/jackal/obj/Darwin/Mach-O/x86_64/opt/libjccl/jcclmain.o /Users/kochjb/devel/deps/vrjuggler/modules/jackal/common/jccl/jcclmain.cpp g++-4.2: Invalid arch name : -pthread It looks like -pthread is not being placed properly with the -arch link option. Is there an easy fix? Doug |
|
From: Patrick H. <pa...@pr...> - 2009-10-29 13:07:30
|
Yes, I haven't had time to figure out how update the build for new Autotools versions. On Mac OS X, just be sure that /usr/bin is in your path before /opt/local/bin when building. -Patrick On Oct 28, 2009, at 11:12 PM, Doug McCorkle wrote: > I resolved this issue by using the aclocal in /usr/bin instead of / > opt/ > local/bin. Here is the version info: > > mccdo-2:~ mccdo$ /opt/local/bin/aclocal --version > aclocal (GNU automake) 1.11 > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html >> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by Tom Tromey <tr...@re...> > and Alexandre Duret-Lutz <ad...@gn...>. > mccdo-2:~ mccdo$ > mccdo-2:~ mccdo$ > mccdo-2:~ mccdo$ > mccdo-2:~ mccdo$ /usr/bin/aclocal --version > aclocal (GNU automake) 1.10 > Written by Tom Tromey <tr...@re...> > and Alexandre Duret-Lutz <ad...@gn...>. > > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > mccdo-2:~ mccdo$ > > > On Oct 28, 2009, at 8:03 PM, Doug McCorkle wrote: > >> Hello, >> >> I am getting this build error on Mac OS 10.5: >> >> cd /stuff/data/VE_Suite_Deps/vrjuggler-svn/modules/gadgeteer && ./ >> autogen.sh >> Running aclocal -I ../../external/macros -I ../../macros -I ../../ >> Doozer++/config -I ../../Doozer++/config/pkgs -I /opt/local/share/ >> aclocal ... >> configure.ac:136: error: AC_LANG_CONFTEST: unknown language: >> Objective-C >> ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... >> ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded >> from... >> ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... >> ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... >> ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded >> from... >> ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded >> from... >> configure.ac:136: the top level >> autom4te: /opt/local/bin/gm4 failed with exit status: 1 >> aclocal: autom4te failed with exit status: 1 >> Running autoheader... >> configure.ac:136: error: AC_LANG_CONFTEST: unknown language: >> Objective-C >> ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... >> ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded >> from... >> ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... >> ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... >> ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded >> from... >> ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded >> from... >> configure.ac:136: the top level >> autom4te: /opt/local/bin/gm4 failed with exit status: 1 >> autoheader: '/opt/local/bin/autom4te' failed with exit status: 1 >> Running autoconf ... >> configure.ac:136: error: AC_LANG_CONFTEST: unknown language: >> Objective-C >> ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... >> ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded >> from... >> ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... >> ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... >> ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded >> from... >> ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded >> from... >> configure.ac:136: the top level >> autom4te: /opt/local/bin/gm4 failed with exit status: 1 >> make[2]: *** [configure] Error 1 >> make[1]: *** [recursive] Error 1 >> make: *** [debug] Error 2 >> >> >> Any ideas? >> >> Doug >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> vrjuggler-devel mailing list >> vrj...@li... >> https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > vrjuggler-devel mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-10-29 04:13:07
|
I resolved this issue by using the aclocal in /usr/bin instead of /opt/ local/bin. Here is the version info: mccdo-2:~ mccdo$ /opt/local/bin/aclocal --version aclocal (GNU automake) 1.11 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tr...@re...> and Alexandre Duret-Lutz <ad...@gn...>. mccdo-2:~ mccdo$ mccdo-2:~ mccdo$ mccdo-2:~ mccdo$ mccdo-2:~ mccdo$ /usr/bin/aclocal --version aclocal (GNU automake) 1.10 Written by Tom Tromey <tr...@re...> and Alexandre Duret-Lutz <ad...@gn...>. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mccdo-2:~ mccdo$ On Oct 28, 2009, at 8:03 PM, Doug McCorkle wrote: > Hello, > > I am getting this build error on Mac OS 10.5: > > cd /stuff/data/VE_Suite_Deps/vrjuggler-svn/modules/gadgeteer && ./ > autogen.sh > Running aclocal -I ../../external/macros -I ../../macros -I ../../ > Doozer++/config -I ../../Doozer++/config/pkgs -I /opt/local/share/ > aclocal ... > configure.ac:136: error: AC_LANG_CONFTEST: unknown language: > Objective-C > ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded > from... > ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... > ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... > ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... > ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded > from... > configure.ac:136: the top level > autom4te: /opt/local/bin/gm4 failed with exit status: 1 > aclocal: autom4te failed with exit status: 1 > Running autoheader... > configure.ac:136: error: AC_LANG_CONFTEST: unknown language: > Objective-C > ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded > from... > ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... > ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... > ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... > ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded > from... > configure.ac:136: the top level > autom4te: /opt/local/bin/gm4 failed with exit status: 1 > autoheader: '/opt/local/bin/autom4te' failed with exit status: 1 > Running autoconf ... > configure.ac:136: error: AC_LANG_CONFTEST: unknown language: > Objective-C > ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded > from... > ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... > ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... > ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... > ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded > from... > configure.ac:136: the top level > autom4te: /opt/local/bin/gm4 failed with exit status: 1 > make[2]: *** [configure] Error 1 > make[1]: *** [recursive] Error 1 > make: *** [debug] Error 2 > > > Any ideas? > > Doug > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > vrjuggler-devel mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel |
|
From: Doug M. <mc...@ia...> - 2009-10-29 01:03:20
|
Hello, I am getting this build error on Mac OS 10.5: cd /stuff/data/VE_Suite_Deps/vrjuggler-svn/modules/gadgeteer && ./ autogen.sh Running aclocal -I ../../external/macros -I ../../macros -I ../../ Doozer++/config -I ../../Doozer++/config/pkgs -I /opt/local/share/ aclocal ... configure.ac:136: error: AC_LANG_CONFTEST: unknown language: Objective-C ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded from... configure.ac:136: the top level autom4te: /opt/local/bin/gm4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 Running autoheader... configure.ac:136: error: AC_LANG_CONFTEST: unknown language: Objective-C ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded from... configure.ac:136: the top level autom4te: /opt/local/bin/gm4 failed with exit status: 1 autoheader: '/opt/local/bin/autom4te' failed with exit status: 1 Running autoconf ... configure.ac:136: error: AC_LANG_CONFTEST: unknown language: Objective-C ../../lib/autoconf/lang.m4:214: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2577: _AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... ../../Doozer++/config/compiler.m4:1105: DPP_PROG_OBJC is expanded from... configure.ac:136: the top level autom4te: /opt/local/bin/gm4 failed with exit status: 1 make[2]: *** [configure] Error 1 make[1]: *** [recursive] Error 1 make: *** [debug] Error 2 Any ideas? Doug |
|
From: Patrick H. <pa...@pr...> - 2009-10-25 15:59:04
|
On Oct 20, 2009, at 10:10 AM, Ryan Pavlik wrote: > Hello all, > > Brief introduction: I'm Ryan Pavlik, a first-year graduate (Ph.D) > student in HCI at ISU. > > I imagine the 2.2 branch on SVN hasn't seen much love recently (one > year since the last commit), but I thought you might like this > contributed patch. I wrote a script that unpacks, configures, > compiles, packages (as deb files!), and installs VR Juggler 2.2.x > and all its dependencies (including system-wide environment variable > VJ_BASE_DIR) from source on Ubuntu Linux 9.04 (Jaunty). In order to > get it to compile correctly, I had to make a few little changes: I > used the latest 2.2 SVN and created and applied effectively two > changes: > - add missing <cstring> includes > - fix ifdefs in the openal code to actually test for the constant > they use, rather than make assumptions based on platform. > > I have attached the patch to this email. If there's interest, I > will check with the right people and publicize the build scripts as > well, since I think they'd find use. Thanks, I committed your changes to the trunk and to the 2.2 branch. As for .deb build scripts, I am not sure where those should go. They could be checked in next to the RPM .spec files if that is a sensible way of handling things. Otherwise, they could be posted as a separate, per-release download from the website. I am open to other suggestions. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Ryan P. <rp...@ia...> - 2009-10-20 17:02:27
|
Hello all, Brief introduction: I'm Ryan Pavlik, a first-year graduate (Ph.D) student in HCI at ISU. I imagine the 2.2 branch on SVN hasn't seen much love recently (one year since the last commit), but I thought you might like this contributed patch. I wrote a script that unpacks, configures, compiles, packages (as deb files!), and installs VR Juggler 2.2.x and all its dependencies (including system-wide environment variable VJ_BASE_DIR) from source on Ubuntu Linux 9.04 (Jaunty). In order to get it to compile correctly, I had to make a few little changes: I used the latest 2.2 SVN and created and applied effectively two changes: - add missing <cstring> includes - fix ifdefs in the openal code to actually test for the constant they use, rather than make assumptions based on platform. I have attached the patch to this email. If there's interest, I will check with the right people and publicize the build scripts as well, since I think they'd find use. Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rp...@ia... http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik |
|
From: Doug M. <mc...@ia...> - 2009-10-20 00:01:19
|
Good deal (I guess not for the requesting user). Doug On Oct 19, 2009, at 9:45 AM, Patrick Hartling wrote: > No, it was done at the request of a user who wanted access to the raw, > non-normalized analog device data: > > http://developer.vrjuggler.org/changeset/20970 > > It has nothing to do with the rewrite of cluster support. > > -Patrick > > Doug McCorkle wrote: >> I am assuming that this change was done during the cluster >> refactoring? Will backing out the change have a negative impact on >> the >> rest of that work? >> >> Doug >> >> On Oct 19, 2009, at 8:10 AM, Patrick Hartling wrote: >> >>> See this thread: >>> >>> http://sourceforge.net/mailarchive/message.php?msg_id=E94E345B-D56D-40A3-B0C5-4A09ACA9219C%40gmail.com >>> >>> In my opinion, it doesn't have to be dealt with. We can go back to >>> the old >>> way of normalizing analog data to [0.0,1.0] and wait until a later >>> time to >>> improve things. >>> >>> -Patrick >>> >>> Doug McCorkle wrote: >>>> What is required to fix this bug? Is this the only thing that is >>>> really out there that has to be dealt with for 3.0? >>>> >>>> Doug >>>> >>>> On Oct 18, 2009, at 8:23 AM, Patrick Hartling wrote: >>>> >>>>> I've been meaning to make a 3.0 release branch and back out the >>>>> change >>>>> that broke analog devices in a cluster configuration. It is clear >>>>> that >>>>> no one has time to work on the proxy refactoring that would >>>>> (potentially) fix the bug. It will probably have to wait for the >>>>> next >>>>> release (3.2, 4.0, whichever is appropriate). >>>>> >>>>> -Patrick >>>>> >>>>> >>>>> -- >>>>> Patrick L. Hartling >>>>> Senior Software Engineer >>>>> Priority 5 >>>>> >>>>> On Oct 17, 2009, at 9:12 PM, Doug McCorkle <mc...@ia...> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I am interested to know what the schedule is or what is left to >>>>>> be >>>>>> done before VR Juggler 3.0 can be released? I know we are working >>>>>> on a >>>>>> few things that we hope to contribute over the next few months >>>>>> but we >>>>>> would like to know what has to be done before 3.0 can be >>>>>> released. >>>>>> Thanks. >>>>>> >>>>>> Doug >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market >> and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> vrjuggler-devel mailing list >> vrj...@li... >> https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel > > > -- > Patrick L. Hartling > Senior Software Engineer, Priority 5 > http://www.priority5.com/ > > The information transmitted in this communication is intended only for > the person or entity to which it is addressed and contains proprietary > material. Any review, retransmission, dissemination or other use of, > or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you > received this in error, please destroy any copies, contact the sender > and delete the material from any computer. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference_______________________________________________ > vrjuggler-devel mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel |
|
From: Patrick H. <pa...@pr...> - 2009-10-19 14:45:34
|
No, it was done at the request of a user who wanted access to the raw, non-normalized analog device data: http://developer.vrjuggler.org/changeset/20970 It has nothing to do with the rewrite of cluster support. -Patrick Doug McCorkle wrote: > I am assuming that this change was done during the cluster > refactoring? Will backing out the change have a negative impact on the > rest of that work? > > Doug > > On Oct 19, 2009, at 8:10 AM, Patrick Hartling wrote: > >> See this thread: >> >> http://sourceforge.net/mailarchive/message.php?msg_id=E94E345B-D56D-40A3-B0C5-4A09ACA9219C%40gmail.com >> >> In my opinion, it doesn't have to be dealt with. We can go back to >> the old >> way of normalizing analog data to [0.0,1.0] and wait until a later >> time to >> improve things. >> >> -Patrick >> >> Doug McCorkle wrote: >>> What is required to fix this bug? Is this the only thing that is >>> really out there that has to be dealt with for 3.0? >>> >>> Doug >>> >>> On Oct 18, 2009, at 8:23 AM, Patrick Hartling wrote: >>> >>>> I've been meaning to make a 3.0 release branch and back out the >>>> change >>>> that broke analog devices in a cluster configuration. It is clear >>>> that >>>> no one has time to work on the proxy refactoring that would >>>> (potentially) fix the bug. It will probably have to wait for the >>>> next >>>> release (3.2, 4.0, whichever is appropriate). >>>> >>>> -Patrick >>>> >>>> >>>> -- >>>> Patrick L. Hartling >>>> Senior Software Engineer >>>> Priority 5 >>>> >>>> On Oct 17, 2009, at 9:12 PM, Doug McCorkle <mc...@ia...> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I am interested to know what the schedule is or what is left to be >>>>> done before VR Juggler 3.0 can be released? I know we are working >>>>> on a >>>>> few things that we hope to contribute over the next few months >>>>> but we >>>>> would like to know what has to be done before 3.0 can be released. >>>>> Thanks. >>>>> >>>>> Doug > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > vrjuggler-devel mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-10-19 14:39:37
|
I am assuming that this change was done during the cluster refactoring? Will backing out the change have a negative impact on the rest of that work? Doug On Oct 19, 2009, at 8:10 AM, Patrick Hartling wrote: > See this thread: > > http://sourceforge.net/mailarchive/message.php?msg_id=E94E345B-D56D-40A3-B0C5-4A09ACA9219C%40gmail.com > > In my opinion, it doesn't have to be dealt with. We can go back to > the old > way of normalizing analog data to [0.0,1.0] and wait until a later > time to > improve things. > > -Patrick > > Doug McCorkle wrote: >> What is required to fix this bug? Is this the only thing that is >> really out there that has to be dealt with for 3.0? >> >> Doug >> >> On Oct 18, 2009, at 8:23 AM, Patrick Hartling wrote: >> >>> I've been meaning to make a 3.0 release branch and back out the >>> change >>> that broke analog devices in a cluster configuration. It is clear >>> that >>> no one has time to work on the proxy refactoring that would >>> (potentially) fix the bug. It will probably have to wait for the >>> next >>> release (3.2, 4.0, whichever is appropriate). >>> >>> -Patrick >>> >>> >>> -- >>> Patrick L. Hartling >>> Senior Software Engineer >>> Priority 5 >>> >>> On Oct 17, 2009, at 9:12 PM, Doug McCorkle <mc...@ia...> >>> wrote: >>> >>>> Hello, >>>> >>>> I am interested to know what the schedule is or what is left to be >>>> done before VR Juggler 3.0 can be released? I know we are working >>>> on a >>>> few things that we hope to contribute over the next few months >>>> but we >>>> would like to know what has to be done before 3.0 can be released. >>>> Thanks. >>>> >>>> Doug |
|
From: Patrick H. <pa...@pr...> - 2009-10-19 13:11:11
|
See this thread: http://sourceforge.net/mailarchive/message.php?msg_id=E94E345B-D56D-40A3-B0C5-4A09ACA9219C%40gmail.com In my opinion, it doesn't have to be dealt with. We can go back to the old way of normalizing analog data to [0.0,1.0] and wait until a later time to improve things. -Patrick Doug McCorkle wrote: > What is required to fix this bug? Is this the only thing that is > really out there that has to be dealt with for 3.0? > > Doug > > On Oct 18, 2009, at 8:23 AM, Patrick Hartling wrote: > >> I've been meaning to make a 3.0 release branch and back out the change >> that broke analog devices in a cluster configuration. It is clear that >> no one has time to work on the proxy refactoring that would >> (potentially) fix the bug. It will probably have to wait for the next >> release (3.2, 4.0, whichever is appropriate). >> >> -Patrick >> >> >> -- >> Patrick L. Hartling >> Senior Software Engineer >> Priority 5 >> >> On Oct 17, 2009, at 9:12 PM, Doug McCorkle <mc...@ia...> wrote: >> >>> Hello, >>> >>> I am interested to know what the schedule is or what is left to be >>> done before VR Juggler 3.0 can be released? I know we are working >>> on a >>> few things that we hope to contribute over the next few months but we >>> would like to know what has to be done before 3.0 can be released. >>> Thanks. >>> >>> Doug > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > vrjuggler-devel mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-10-18 14:59:29
|
What is required to fix this bug? Is this the only thing that is really out there that has to be dealt with for 3.0? Doug On Oct 18, 2009, at 8:23 AM, Patrick Hartling wrote: > I've been meaning to make a 3.0 release branch and back out the change > that broke analog devices in a cluster configuration. It is clear that > no one has time to work on the proxy refactoring that would > (potentially) fix the bug. It will probably have to wait for the next > release (3.2, 4.0, whichever is appropriate). > > -Patrick > > > -- > Patrick L. Hartling > Senior Software Engineer > Priority 5 > > On Oct 17, 2009, at 9:12 PM, Doug McCorkle <mc...@ia...> wrote: > >> Hello, >> >> I am interested to know what the schedule is or what is left to be >> done before VR Juggler 3.0 can be released? I know we are working >> on a >> few things that we hope to contribute over the next few months but we >> would like to know what has to be done before 3.0 can be released. >> Thanks. >> >> Doug |
|
From: Patrick H. <pa...@pr...> - 2009-10-18 14:30:43
|
I've been meaning to make a 3.0 release branch and back out the change that broke analog devices in a cluster configuration. It is clear that no one has time to work on the proxy refactoring that would (potentially) fix the bug. It will probably have to wait for the next release (3.2, 4.0, whichever is appropriate). -Patrick -- Patrick L. Hartling Senior Software Engineer Priority 5 On Oct 17, 2009, at 9:12 PM, Doug McCorkle <mc...@ia...> wrote: > Hello, > > I am interested to know what the schedule is or what is left to be > done before VR Juggler 3.0 can be released? I know we are working on a > few things that we hope to contribute over the next few months but we > would like to know what has to be done before 3.0 can be released. > Thanks. > > Doug > > > --- > --- > --- > --------------------------------------------------------------------- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > vrjuggler-devel mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel |
|
From: Doug M. <mc...@ia...> - 2009-10-18 02:13:14
|
Hello, I am interested to know what the schedule is or what is left to be done before VR Juggler 3.0 can be released? I know we are working on a few things that we hope to contribute over the next few months but we would like to know what has to be done before 3.0 can be released. Thanks. Doug |
|
From: Doug M. <mc...@ia...> - 2009-09-15 03:11:29
|
On Sep 14, 2009, at 10:44 AM, Patrick Hartling wrote: > Doug McCorkle wrote: >> Patrick Hartling wrote: >>> Doug McCorkle wrote: >>> >>>> Patrick Hartling wrote: >>>> >>>>> Doug McCorkle wrote: >>>>> >>>>> >>>>>> Hello Patrick, >>>>>> >>>>>> On Aug 9, 2009, at 8:35 PM, Doug McCorkle wrote: >>>>>> >>>>>> [snip] >>>>>> >>>>>> >>>>>> >>>>>>>>> Try r21120. It ended up being pretty easy to add. >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks Patrick! You beat me to the punch. We will give this a >>>>>>>> try >>>>>>>> with >>>>>>>> what we are trying to do and report back. We should have >>>>>>>> results from >>>>>>>> our testing on various hardware platforms by the end of next >>>>>>>> week. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> This is working for our various hardware configurations. >>>>>>> Thanks for >>>>>>> adding this support. >>>>>>> >>>>>>> >>>>>> I am using this code and am trying to determine if a window >>>>>> that is >>>>>> receiving input is an InputWindow or a display Window and I am >>>>>> unable >>>>>> to use a dynamic cast to do this. I am getting this compile >>>>>> error on >>>>>> Mac OS 10.5: >>>>>> >>>>>> error: cannot dynamic_cast ‘inputArea’ (of type ‘class >>>>>> gadget::InputArea*’) to type ‘class >>>>>> gadget::InputWindowCocoa*’ (source >>>>>> type is not polymorphic) >>>>>> error: cannot dynamic_cast ‘inputAreaCocoa’ (of type ‘class >>>>>> gadget::InputAreaCocoa*’) to type ‘class >>>>>> vrj::opengl::WindowCocoa*’ (source type is not polymor >>>>>> >>>>>> Do you know why this would be the case? I am not understanding >>>>>> why I >>>>>> cannot dynamic cast to different Input Areas. Thanks for the >>>>>> help. >>>>>> >>>>>> >>>>> vrj::opengl::WindowCocoa and gadget::InputWindowCocoa do not >>>>> have a >>>>> derived/base relationship; they are sibling types. Both derive >>>>> from >>>>> gadget::InputAreaCocoa, which in turn derives from >>>>> gadget::InputArea. >>>>> >>>>> >>>>> >>>> Right, so it seems I should be able to dynamic cast an InputArea >>>> to an >>>> InputAreaCocoa and/or an InputWindowCocoa correct? >>>> >>> If you have included gadget/Devices/KeyboardMouseDevice/ >>> InputAreaCocoa.h >>> and/or gadget/Devices/KeyboardMouseDevice/InputWindowCocoa.h, then >>> yes. >>> >> I have but I still get the above error. > > Update to r21121. gadget::InputArea had no virtual methods and thus > was not > a polymorphic base type. That was a pretty serious oversight. Ahh. Things are working now. Doug |
|
From: Patrick H. <pa...@pr...> - 2009-09-14 15:45:03
|
Doug McCorkle wrote: > Patrick Hartling wrote: >> Doug McCorkle wrote: >> >>> Patrick Hartling wrote: >>> >>>> Doug McCorkle wrote: >>>> >>>> >>>>> Hello Patrick, >>>>> >>>>> On Aug 9, 2009, at 8:35 PM, Doug McCorkle wrote: >>>>> >>>>> [snip] >>>>> >>>>> >>>>> >>>>>>>> Try r21120. It ended up being pretty easy to add. >>>>>>>> >>>>>>>> >>>>>>> Thanks Patrick! You beat me to the punch. We will give this a try >>>>>>> with >>>>>>> what we are trying to do and report back. We should have results from >>>>>>> our testing on various hardware platforms by the end of next week. >>>>>>> >>>>>>> >>>>>>> >>>>>> This is working for our various hardware configurations. Thanks for >>>>>> adding this support. >>>>>> >>>>>> >>>>> I am using this code and am trying to determine if a window that is >>>>> receiving input is an InputWindow or a display Window and I am unable >>>>> to use a dynamic cast to do this. I am getting this compile error on >>>>> Mac OS 10.5: >>>>> >>>>> error: cannot dynamic_cast ‘inputArea’ (of type ‘class >>>>> gadget::InputArea*’) to type ‘class gadget::InputWindowCocoa*’ (source >>>>> type is not polymorphic) >>>>> error: cannot dynamic_cast ‘inputAreaCocoa’ (of type ‘class >>>>> gadget::InputAreaCocoa*’) to type ‘class >>>>> vrj::opengl::WindowCocoa*’ (source type is not polymor >>>>> >>>>> Do you know why this would be the case? I am not understanding why I >>>>> cannot dynamic cast to different Input Areas. Thanks for the help. >>>>> >>>>> >>>> vrj::opengl::WindowCocoa and gadget::InputWindowCocoa do not have a >>>> derived/base relationship; they are sibling types. Both derive from >>>> gadget::InputAreaCocoa, which in turn derives from gadget::InputArea. >>>> >>>> >>>> >>> Right, so it seems I should be able to dynamic cast an InputArea to an >>> InputAreaCocoa and/or an InputWindowCocoa correct? >>> >> If you have included gadget/Devices/KeyboardMouseDevice/InputAreaCocoa.h >> and/or gadget/Devices/KeyboardMouseDevice/InputWindowCocoa.h, then yes. >> > I have but I still get the above error. Update to r21121. gadget::InputArea had no virtual methods and thus was not a polymorphic base type. That was a pretty serious oversight. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. |
|
From: Doug M. <mc...@ia...> - 2009-09-14 14:54:53
|
Patrick Hartling wrote: > Doug McCorkle wrote: > >> Patrick Hartling wrote: >> >>> Doug McCorkle wrote: >>> >>> >>>> Hello Patrick, >>>> >>>> On Aug 9, 2009, at 8:35 PM, Doug McCorkle wrote: >>>> >>>> [snip] >>>> >>>> >>>> >>>>>>> Try r21120. It ended up being pretty easy to add. >>>>>>> >>>>>>> >>>>>> Thanks Patrick! You beat me to the punch. We will give this a try >>>>>> with >>>>>> what we are trying to do and report back. We should have results from >>>>>> our testing on various hardware platforms by the end of next week. >>>>>> >>>>>> >>>>>> >>>>> This is working for our various hardware configurations. Thanks for >>>>> adding this support. >>>>> >>>>> >>>> I am using this code and am trying to determine if a window that is >>>> receiving input is an InputWindow or a display Window and I am unable >>>> to use a dynamic cast to do this. I am getting this compile error on >>>> Mac OS 10.5: >>>> >>>> error: cannot dynamic_cast ‘inputArea’ (of type ‘class >>>> gadget::InputArea*’) to type ‘class gadget::InputWindowCocoa*’ (source >>>> type is not polymorphic) >>>> error: cannot dynamic_cast ‘inputAreaCocoa’ (of type ‘class >>>> gadget::InputAreaCocoa*’) to type ‘class >>>> vrj::opengl::WindowCocoa*’ (source type is not polymor >>>> >>>> Do you know why this would be the case? I am not understanding why I >>>> cannot dynamic cast to different Input Areas. Thanks for the help. >>>> >>>> >>> vrj::opengl::WindowCocoa and gadget::InputWindowCocoa do not have a >>> derived/base relationship; they are sibling types. Both derive from >>> gadget::InputAreaCocoa, which in turn derives from gadget::InputArea. >>> >>> >>> >> Right, so it seems I should be able to dynamic cast an InputArea to an >> InputAreaCocoa and/or an InputWindowCocoa correct? >> > > If you have included gadget/Devices/KeyboardMouseDevice/InputAreaCocoa.h > and/or gadget/Devices/KeyboardMouseDevice/InputWindowCocoa.h, then yes. > I have but I still get the above error. Doug |
34 messages has been excluded from this view by a project administrator.