| 00:20.02 | zero_level | brlcad, ``Erik i am stuck at changing the existing usage of libicv |
| 00:24.47 | zero_level | as discussed the new structure icv_image doesnt have information regarding filename , fd and has a double* data . |
| 00:25.51 | zero_level | the current usage of libicv in rt usage them heavily. |
| 03:22.06 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 05:33.02 | Notify | 03BRL-CAD:phoenixyjll * 55866 brlcad/trunk/src/libbrep/intersect.cpp: Merge the overlap events that are continuous, and eliminate the intersection points that are inside the overlap events. |
| 06:26.57 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 07:04.43 | Notify | 03BRL-CAD:phoenixyjll * 55867 brlcad/trunk/src/libbrep/test_curve_intersect.cpp: Add another test for overlaps. |
| 07:30.14 | *** join/#brlcad papna (~papna@li590-168.members.linode.com) |
| 07:35.28 | *** join/#brlcad papna (~papna@python/site-packages/papna) |
| 07:37.17 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 07:37.17 | *** join/#brlcad harman (~harman@202.164.53.122) |
| 07:37.17 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 07:47.18 | *** join/#brlcad caen23 (~caen23@92.81.190.86) |
| 08:00.01 | *** join/#brlcad kesha__ (~kesha@49.249.1.41) |
| 08:35.30 | Notify | 03BRL-CAD:phoenixyjll * 55868 brlcad/trunk/src/libbrep/test_curve_intersect.cpp: Remove the debug message. |
| 09:31.15 | Notify | 03BRL-CAD:phoenixyjll * 55869 brlcad/trunk/src/libbrep/intersect.cpp: Some special handling for linear curves. |
| 09:37.29 | *** join/#brlcad vladbogo (~vlad@86.121.100.162) |
| 09:39.38 | Notify | 03BRL-CAD:phoenixyjll * 55870 brlcad/trunk/src/libbrep/intersect.cpp: remove trailing ws. |
| 09:45.29 | Notify | 03BRL-CAD:phoenixyjll * 55871 brlcad/trunk/src/libbrep/intersect.cpp: gcc doesn't support using ON_X_EVENT::TYPE::xxx, so we use ON_X_EVENT::xxx directly. |
| 09:57.55 | vladbogo | hi all |
| 09:59.04 | vladbogo | it is not very clear what framebuffer the new display manager should use |
| 10:01.38 | vladbogo | I saw that there are already specific framebuffers for X11 and openGl but I don't know if any is appropriate for the new display manager. I would be really grateful if you could give e a hint about this issue. |
| 10:32.02 | Notify | 03BRL-CAD Wiki:Phoenix * 5527 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 2 */ |
| 10:40.32 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b10b:bbdd:0:15:e010:9501) |
| 10:52.34 | d_rossberg | vladbogo: i recommend to start with a null or text framebuffer, in the final state a Qt framebuffer would be desirable |
| 10:53.14 | vladbogo | d_rossberg: thanks for your reply |
| 10:54.19 | vladbogo | also i assume that it is ok if the qt dm source it's a c++ one but just wanted to be sure? |
| 10:57.40 | d_rossberg | yes, it's necessarily so, and qt-dm interface functions have to be extern "C" |
| 10:59.06 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 11:00.43 | vladbogo | d_rossberg: I've successfully integrated Qt in the cmake build but there are some warnings in the Qt files. |
| 11:02.11 | vladbogo | how can I allow warnings for those files so that it can successfully compile without strict compilation being turned off? |
| 11:10.05 | d_rossberg | did you commited your changes? |
| 11:11.07 | vladbogo | d_rossberg: not yet. I did't want to commit changes that are not complete |
| 11:13.02 | d_rossberg | but you could commit the search and integration of the Qt libraries into the CMake build? |
| 11:14.14 | vladbogo | ok. I will. Also the search for Qt only works at the moment by specifying the path to Qt installation in the CMAKE_PREFIX_PATH |
| 11:14.32 | d_rossberg | remember to "commit very frequently" ;) |
| 11:20.39 | Notify | 03BRL-CAD:vladbogo * 55872 brlcad/trunk/CMakeLists.txt: Additional test for Qt installation. Only works if CMAKE_PREFIX_PATH is set to Qt installation path. |
| 11:24.58 | starseeker | vladbogo: is find Qt5Widgets a new module? are they getting rid of the "find_package(Qt5 ...." approach? |
| 11:27.02 | starseeker | ah, I see it is |
| 11:27.40 | vladbogo | starseeker: find_package(Qt ...) I saw it only works for Qt 4. For Qt 5 as I researched there should be a find_package for every module. And Qt5Widgets is a new module that groups Qt5GUI and Qt5Core and probably more. |
| 11:29.34 | starseeker | vladbogo: does your work need Qt5, or would 4 work as well? (OK if it needs 5, but if it can use 4 it changes the search logic) |
| 11:31.56 | vladbogo | starseeker: brlcad told me to use the latest Qt version but I guess Qt4 would work too |
| 11:33.28 | starseeker | vladbogo: no, that's fine |
| 11:33.44 | starseeker | Qt5 has some nice features that will be of considerable interest down the road |
| 11:34.04 | starseeker | Hmm... looks like you're taking the right approach: http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html |
| 11:36.16 | vladbogo | starseeker: that's the page I used. Still there are some things that need to be clarified regarding the cmake version |
| 11:36.48 | starseeker | vladbogo: stick with the newer/modern approach |
| 11:37.22 | starseeker | if we have to support older CMake versions we can address that later |
| 11:37.42 | starseeker | pwd |
| 11:37.45 | d_rossberg | requirering Qt4 could be a big obstacle for many systems |
| 11:37.45 | starseeker | whoops |
| 11:37.59 | starseeker | yeah, Qt5 is fine |
| 11:38.09 | starseeker | requiring that actually *simplifies* the CMake logic |
| 11:38.16 | d_rossberg | sorry, i mean requirering Qt5 |
| 11:38.37 | vladbogo | I've tried the cmake 2.8.11 approach and even though theoretically the fPIC flag shouldn't be required(from the example on the link you provided) it still does not work |
| 11:38.42 | starseeker | well, if we end up *requiring* Qt we'll have to get it working as a subbuild |
| 11:39.47 | Notify | 03BRL-CAD:starseeker * 55873 brlcad/trunk/CMakeLists.txt: Don't print the verbose warning if Qt5 isn't found. |
| 11:40.21 | d_rossberg | starseeker: that's not the whole story: Qt4 is shipped with many Linux etc. but for Qt5 there isn't even a FreeBSD port |
| 11:41.01 | starseeker | d_rossberg: that's what I mean - we'd have to make Qt5 a viable src/other subbuild, like we've done for Tcl/Tk |
| 11:41.24 | d_rossberg | starseeker: please don't do this! |
| 11:41.38 | starseeker | d_rossberg: we can keep the repository separate |
| 11:42.21 | starseeker | there are a couple viable approaches for that |
| 11:42.31 | d_rossberg | squeezing all the "other"s into our CMake build is a mess |
| 11:42.54 | starseeker | in what sense? I thought we actually manage that quite well now |
| 11:45.26 | d_rossberg | at least the MSVC build is horrible slow, too many projects i don't need |
| 11:45.55 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 11:46.15 | starseeker | d_rossberg: there should be specific targets you can invoke to get just what you need |
| 11:46.54 | starseeker | d_rossberg: if you have system versions of src/other pieces you want to use on MSVC, you can try that - you just have to set the BRLCAD_BUNDLED_LIBRARIES variable to AUTO |
| 11:47.03 | d_rossberg | this works for the gcc makefiles but not for ms |
| 11:47.30 | d_rossberg | (selecting the target) |
| 11:47.32 | starseeker | we default to "ON" for bundling on MSVC because it's rare for such systems to have much of anything that we need, and the configure process is inherently slow on Windows |
| 11:48.03 | starseeker | really? if you select libbu as the build target from the MSVC list it builds the whole thing? |
| 11:48.13 | Notify | 03BRL-CAD:vladbogo * 55874 (brlcad/trunk/include/dm.h brlcad/trunk/src/libdm/CMakeLists.txt): Changed dm-qt source to C++ file. Integrated Qt in the cmake build. Modified dm.h so that there are no warnings in the dm-qt.cpp. |
| 11:48.44 | d_rossberg | for gcc you can write "make libbu" but in MSVC you have to open the solution file with althe targets first |
| 11:49.15 | vladbogo | d_rossberg: I've finished committing the changes |
| 11:49.30 | starseeker | d_rossberg: ah, sure. But if you set the appropriate flags up front, most of those targets won't be there |
| 11:51.14 | starseeker | (cmake flags) |
| 11:53.08 | d_rossberg | starseeker: then after starting the build of libbu it needs 40s to see that there is nothing to do |
| 11:53.10 | starseeker | d_rossberg: in the CMake gui, use the "Add Entry" button before running configure to define "BRLCAD_BUNDLED_LIBS" as a STRING with value "AUTO" and BRLCAD_EXTRADOCS as a BOOL with default value unchecked (OFF) |
| 11:53.40 | starseeker | d_rossberg: that's inherent to the dependency managing done by the CMake/MSVC combination |
| 11:54.15 | starseeker | d_rossberg: that's why the Ninja build tool is gaining a lot of fans, in fact - it gives CMake builds blazing fast incremental rebuilding |
| 11:54.25 | starseeker | I believe it even runs on Windows |
| 11:55.25 | d_rossberg | but then why i don't have these problems on linux? (cmake with gcc makefiles) |
| 11:55.59 | starseeker | because MSVC is a *lot* slower than gcc and make |
| 11:56.28 | starseeker | Ninja is faster than Make too, even on Linux, it's just less noticable |
| 11:58.01 | *** join/#brlcad vladbogo_ (~vlad@86.124.248.118) |
| 11:58.42 | starseeker | If you want to *really* build a minimal subset of BRL-CAD, there is the BRLCAD_ENABLE_TARGETS variable |
| 11:59.10 | starseeker | Setting it to "1" (i.e. build level 1 targets) will build only what is needed for librt |
| 11:59.53 | starseeker | level "2" will build the libraries but not most of the tools |
| 12:01.45 | starseeker | looking at the BrlcadCore library link list I'd guess a level 2 build is probably what you'd need |
| 12:02.52 | *** join/#brlcad mpictor_ (~mpictor_@179.sub-174-241-194.myvzw.com) |
| 12:03.30 | d_rossberg | probable, needs some tests |
| 12:03.31 | starseeker | as far as I know we've never tried the more minimal BRLCAD_ENABLE_TARGETS settings on MSVC, so you may find a problem or two - if so we can straighten them out |
| 12:03.54 | starseeker | d_rossberg: but that'll most likely be the best way to make the MSVC build more tolerable |
| 12:04.20 | d_rossberg | because i can't fix msvc at the moment - back to Qt: i would still consider Qt5 as exotic and Qt4 as well established |
| 12:04.49 | d_rossberg | and if i remember correctly Qt4 code should run with Qt5 too |
| 12:05.47 | vladbogo | d_rossberg: I think so. I've only see that there are differences in the cmake procedure |
| 12:06.38 | starseeker | possibly. FWIW, I do know Meshlab had to do some work to get running on Qt5 |
| 12:07.20 | starseeker | d_rossberg: remember, we aren't going to be ditching our other systems for an exclusively Qt solution anytime soon |
| 12:08.22 | starseeker | Qt will represent the "cutting edge" of development, but people operating on that edge should be up to getting Qt5 installed and working |
| 12:09.57 | starseeker | once vladbogo has a working solution in Qt5 we can look at how much (if anything) is needed to also make it work with Qt4 - if it's minimal (and hopefully it would be) then I agree supporting both is a good idea |
| 12:10.10 | starseeker | but for the initial development efforts I would say don't worry about it |
| 12:12.08 | starseeker | (Qt5 has some features that are extremely interesting for long term CAD gui development - take a look at http://advancingusability.wordpress.com/2013/03/30/how-to-integrate-ogre3d-into-a-qt5-qml-scene/ |
| 12:19.20 | vladbogo | when I try to use the ogl display manager I get a completely transparent window which seems quite weird. I did not have time to see why this behavior so I want to ask you if it's the desired result or something is wrong? |
| 12:20.37 | starseeker | that's not typical - I've seen it now and then, I think it has something to do with opengl settings or drivers on the system? |
| 12:22.00 | Notify | 03BRL-CAD:starseeker * 55875 (brlcad/trunk/CMakeLists.txt brlcad/trunk/src/other/CMakeLists.txt): Mark a few variables as advanced so they don't clutter the default CMake GUI display |
| 12:27.20 | vladbogo | starseeker: I don't have any opengl custom settings but it might be the problem. |
| 12:29.15 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 12:30.21 | d_rossberg | vladbogo: starseeker: it's not about ditching the other systems then rather the other way round: i've only an "experimental" Qt5 on one machine which doesn't run smoothly |
| 12:31.43 | d_rossberg | vladbogo: do you want to use opengl in qt? |
| 12:36.09 | vladbogo | d_rossberg: yes |
| 12:40.42 | d_rossberg | why? you don't need ogl for simple graphics, is there something what requires a special ogl feature? i personally only remember having trouble with ogl, especially on linux, system crashes included |
| 12:45.21 | starseeker | opengl will be faster, but it *would* be nice to be able to fall back on non-openGL based canvas/drawing if opengl isn't available or working |
| 12:47.05 | vladbogo | well the reason is that I have worked with opengl before and being new Qt seemed to be best choice. |
| 12:47.19 | d_rossberg | opengl *could* be useful if it's for handling shaded geometries, but wireframes ... |
| 12:49.03 | vladbogo | in this case I will not use it |
| 12:50.23 | d_rossberg | vladbogo: the intention i have with Qt is that this is a GUI library for a very wide variety of platforms, i wouldn't recommend to water it down for no reason |
| 12:59.32 | vladbogo | I understand so I will keep that in mind |
| 13:06.43 | d_rossberg | vladbogo: next question: what is Qt5Widgets? don't you need an include and a librariy directory? |
| 13:12.25 | *** join/#brlcad vladbogo (~vlad@86.124.248.118) |
| 13:12.38 | *** join/#brlcad mpictor_ (~mpictor_@57.sub-174-225-65.myvzw.com) |
| 13:12.44 | vladbogo | d_rossberg: sorry about that, internet problems |
| 13:12.55 | d_rossberg | no problem |
| 13:14.00 | d_rossberg | btw, you should have a look at the __BEGIN_DECLS, __END_DECLS macros; they are used in almost every header file |
| 13:14.43 | vladbogo | Qt5Widgets is a new module that groups all the Qt widgets and also includes the dependencies for QtCore and QtGui |
| 13:15.42 | vladbogo | the necessary files are in Qt5Widgets_INCLUDE_DIRS |
| 13:17.33 | vladbogo | found the __BEGIN_DECLS and __END_DECLS macros and I will use them. Thanks for the tip |
| 13:18.27 | d_rossberg | because of the DECLS: i was a little bit confused, but the "#ifdef __cplusplus" should be redundant in a .cpp file and the extern "C" shouldn't be necessary there because it's already in the declaration in the .h file |
| 13:19.39 | vladbogo | d_rossberg: open function is declared and used in dm-generic.c so it has to have extern "C" |
| 13:20.54 | vladbogo | about the ifdef __cplusplus I've read that there is a good practice to use it even in cpp files so that's why I used it |
| 13:24.52 | d_rossberg | so what's your value for Qt5Widgets_INCLUDE_DIRS? |
| 13:28.22 | vladbogo | the Qt5Widgets dir which includes a .h for all widgets, Qt5Core dir ad Qt5Gui dir - that's what I read about |
| 13:29.42 | vladbogo | it may be too much but I don't know exactly what I will use and for the test application I made was necessary |
| 13:30.04 | d_rossberg | i.e. /usr/include/Qt5 ? |
| 13:31.36 | vladbogo | I have installed Qt5in the home dir but it should be path_to_qt/include/QtWidgets,path_to_qt/include/QtCore and path_to_qt/include/QtGui |
| 13:34.31 | d_rossberg | ok, on Linux you don't need the libs for the build |
| 13:36.03 | vladbogo | ok so should I omit the libs? |
| 13:37.00 | d_rossberg | for the moment ;) |
| 13:37.10 | vladbogo | also the set(CMAKE_POSITION_INDEPENDENT_CODE ON) I've read that only works on cmake 2.8.9 and higher |
| 13:37.53 | vladbogo | should I set the CMAKE_CXX_FLAGS instead? |
| 13:39.57 | d_rossberg | that's something different, you shouldn't need it when working with .so libraries, do you have .a (i.e. static) libraries? |
| 13:40.57 | vladbogo | well Qt5 needs the -fPIC flag |
| 13:42.24 | d_rossberg | but you build Qt5 independently of BRL-CAD? and you got some libqt5core.so files? |
| 13:42.33 | Notify | 03BRL-CAD:starseeker * 55876 brlcad/trunk/src/other/step/CMakeLists.txt: have SCL avoid stomping the CMAKE_BUILD_TYPE cash when acting as a subbuild. |
| 13:43.29 | vladbogo | I haven't build Qt5 independently |
| 13:44.28 | vladbogo | after installing Qt I got also some .so files |
| 13:45.03 | d_rossberg | ? didn't you used their configure and than make? |
| 13:46.48 | vladbogo | no. I've downloaded an executable file that installed Qt |
| 13:47.18 | d_rossberg | (btw, there is really an -fPIC issue in the BRL-CAD build but it shouldn't influence the use of other libraries) |
| 13:48.05 | vladbogo | without the fPIC flag I couldn't successfully compile |
| 13:48.49 | vladbogo | I've read that in cmake 2.8.11 specifying the fPIC flag is not necessary so I've installed cmake 2.8.11 to test it and it does not work |
| 13:49.38 | Notify | 03BRL-CAD:starseeker * 55877 (brlcad/trunk/CMakeLists.txt brlcad/trunk/src/other/CMakeLists.txt): More tweaks for CMake GUI manipulation of values |
| 13:51.54 | d_rossberg | ok, this is something from my to-do list: add BRLCAD_CHECK_C_FLAG(fPIC) and BRLCAD_CHECK_CXX_FLAG(fPIC) to misc/CMake/CompilerFlags.cmake |
| 13:53.34 | d_rossberg | nevertheless it's strange ... |
| 13:54.47 | vladbogo | http://www.kdab.com/using-cmake-with-qt-5./ here it's a slight explanation about the fPIC and fPIE flags |
| 13:55.46 | vladbogo | it says that this happens because in Qt5 "-reduce-relocations" configure option is the default |
| 14:01.10 | d_rossberg | does adding BRLCAD_CHECK_C_FLAG/BRLCAD_CHECK_CXX_FLAG work? |
| 14:04.45 | vladbogo | now testing: it seems to take a while to compile |
| 14:10.00 | vladbogo | d_rossberg: it seems to work |
| 14:12.34 | d_rossberg | then, can you commit the changed CompilerFlags.cmake? (i.e. after adding a nice comment etc.) |
| 14:12.44 | vladbogo | yes it works |
| 14:12.54 | vladbogo | ok I will immediately |
| 14:17.09 | vladbogo | ready:) |
| 14:17.13 | Notify | 03BRL-CAD:vladbogo * 55878 (brlcad/trunk/misc/CMake/CompilerFlags.cmake brlcad/trunk/src/libdm/CMakeLists.txt): Enable position independent code in misc/CMake/CompilerFlags.cmake instead of in src/libdm/CmakeLists.txt. Position independent code is required for Qt5. |
| 14:19.39 | d_rossberg | you should add a comment in CompilerFlags.cmake too, look at all the other BRLCAD_CHECK_C_FLAG/BRLCAD_CHECK_CXX_FLAG entries |
| 14:19.44 | Notify | 03BRL-CAD:starseeker * 55879 brlcad/trunk/src/libbrep/opennurbs_ext.cpp: more tweaks to make the knot and non-knot code look similar. |
| 14:20.30 | vladbogo | d_rossberg: ok, I will immediately |
| 14:27.26 | Notify | 03BRL-CAD:vladbogo * 55880 brlcad/trunk/misc/CMake/CompilerFlags.cmake: Added a comment to highlight the need of the position independent code flag. |
| 14:33.40 | *** join/#brlcad vladbogo_ (~vlad@86.124.248.162) |
| 14:44.39 | *** join/#brlcad cstirk (~quassel@96.255.19.39) |
| 14:46.38 | *** join/#brlcad mpictor (~mpictor_@135.sub-174-241-112.myvzw.com) |
| 14:55.29 | brlcad | zero_level: available to discuss if needed, but you have to approach this VERY incrementally working with the initial structure first |
| 15:00.47 | Notify | 03BRL-CAD:vladbogo * 55881 brlcad/trunk/src/libdm/dm-qt.cpp: Use __BEGIN_DECL and __END_DECL macros instead of extern "C". |
| 15:02.43 | Notify | 03BRL-CAD:starseeker * 55882 brlcad/trunk/src/libbrep/opennurbs_ext.cpp: Don't define things we aren't using... |
| 15:02.45 | Notify | 03BRL-CAD:carlmoore * 55883 brlcad/trunk/doc/docbook/lessons/es/mged02_opciones_vistas.xml: fix spelling of Spanish word 'acimut'; trailing 'h' was removed |
| 15:02.53 | vladbogo | d_rossberg: I've tried to remove the libs from the build but it does not compile successfully anymore. |
| 15:03.49 | d_rossberg | which libs? |
| 15:05.31 | vladbogo | Qt libs: you said that are not required for Linux |
| 15:08.27 | d_rossberg | i was just wondering why CMake asks for the headers but not for the libs, but there is a "find_package" functionality behind which apparently looks for the libs |
| 15:10.18 | d_rossberg | and the libs are definitely required to run the program |
| 15:10.26 | brlcad | so just blindly adding -fPIC is going to be a problem |
| 15:10.51 | brlcad | that make is only possible to make shared library object files |
| 15:11.10 | brlcad | if someone requests a static build, it's going to fail |
| 15:11.49 | brlcad | (this is one of the reasons why libtool compiles everything twice, once with -fPIC and once without) |
| 15:11.57 | d_rossberg | brlcad: the other way round: static build needs this -fPIC, i tried it with the libbrlcad.so |
| 15:13.36 | d_rossberg | when you combine two static libs in one binary it's very likely that you have to shift positions |
| 15:13.41 | brlcad | hm? libbrlcad.so is a shared lib |
| 15:14.10 | d_rossberg | as a proto type on my computer: yes |
| 15:14.37 | d_rossberg | needs only some minor changes, -fPIC was one of them |
| 15:14.38 | zero_level | brlcad: today last day i wrote new functions for creating image. writing pixel and saving. |
| 15:15.33 | d_rossberg | ah: libbrlcad.so contains librt.a, libbu.a ... |
| 15:18.24 | vladbogo | brlcad: there is also the qt5_use_modules macro that encapsulates all of the variable usage required to use a Qt module using with I've made a successful cmake without setting the -fPIC flag but I don't know yet how to integrate it in the brlcad cmake procedure. Should I give it a try? |
| 15:24.58 | brlcad | vladbogo: if it means getting rid of -fPIC, sure |
| 15:25.55 | brlcad | my original suggestion remains to do the bare minimum for the build (or to be comprehensive and do it properly) |
| 15:26.16 | brlcad | somewhere in between those two options is a dangerous valley to be in |
| 15:26.51 | vladbogo | brlcad: I know but without setting the "-fPIC" I cannot compile |
| 15:27.17 | brlcad | so when you can't compile, you have to say what and why and understand why |
| 15:27.44 | brlcad | otherwise saying you cannot compile could simply be because you don't have a compure or lack fingers or it was raining inside or ... I shouldn't have to guess |
| 15:28.04 | brlcad | uninformative to ever just say a compile failed |
| 15:28.15 | brlcad | :) |
| 15:29.13 | brlcad | vladbogo: so my response then is "why?" |
| 15:29.21 | vladbogo | as I read the problem is that Qt5 has the "-reduce-locations" configure option by default which means that the compilation is run with the "-Bsymbolic-function" which makes function pointer comparison ineffective |
| 15:29.35 | vladbogo | unless the -fPIC flag is provided |
| 15:29.59 | brlcad | compilation of qt5 itself or things using qt5? |
| 15:30.44 | vladbogo | things using Qt5 |
| 15:31.49 | brlcad | we're a "thing using Qt5" right? |
| 15:31.59 | vladbogo | yes |
| 15:32.00 | brlcad | we do not add -Bsymbolic-function or do we know somehow? |
| 15:32.05 | brlcad | s/know/now/ |
| 15:33.50 | vladbogo | explicitly not but I guess that it is already added in the Qt which has to be used |
| 15:34.17 | brlcad | guessing won't do, we need to understand what's going on to address this |
| 15:34.28 | brlcad | so lets take a step back and look at what's actually going on when whatever fails |
| 15:34.36 | brlcad | first, what fails? |
| 15:35.10 | brlcad | and is it a compilation failure or a linker failure (you'll need to learn the difference if you do not) |
| 15:51.04 | *** join/#brlcad vladbogo (~vlad@86.121.99.104) |
| 15:51.32 | zero_level | the issue now is .. in the rt/view.c , viewedge.c viewxray.c and do.c these data are written in uchar* format. |
| 15:51.56 | zero_level | so i will have to conver this in the following way |
| 15:52.13 | zero_level | convert to double in rt/.. (files) |
| 15:53.04 | zero_level | create image. (by calling icv_create)[allocates memory for structure and data and zeros the image] |
| 15:53.15 | zero_level | store the double values. |
| 15:53.21 | zero_level | save the image |
| 15:53.59 | zero_level | Now in save if it is ppm, bw, pix the data is again covnerted to uchar. from double. |
| 15:54.51 | zero_level | brlcad, ``Erik I find this redundant here. converting uchar->double and double->uchar |
| 16:02.09 | *** join/#brlcad vladbogo_ (~vlad@86.121.99.173) |
| 16:06.49 | vladbogo_ | brlcad: tested with cmake 2.8.11 and there is no problem which is quite weird because I am 100% sure I've tested it before and did not work. So I will remove the fPIC flag and will try to solve this issue later for other versions of cmake if necessary |
| 16:07.42 | brlcad | vladbogo_: I completely believe that you ran into a failure, that's easy :) |
| 16:08.05 | brlcad | but need to know exactly what that error was and under what conditions, and understand the problem |
| 16:08.21 | *** join/#brlcad vladbogo__ (~vlad@86.121.102.228) |
| 16:08.22 | brlcad | in order to do something about it |
| 16:08.36 | brlcad | vladbogo_: are you having connection issues or something? |
| 16:08.49 | vladbogo__ | brlcad: unfortunately yes |
| 16:08.50 | brlcad | what is it with connection problems this year, it's insane... |
| 16:09.12 | vladbogo__ | so I think I've received just part of your answer |
| 16:09.54 | vladbogo__ | saturday I will be moving so there won't be any connection problems from saturday on |
| 16:10.13 | brlcad | zero_level: that sounds perfectly reasonable, but you might want to address the file pointer first |
| 16:10.26 | brlcad | vladbogo__: okay that's good to hear |
| 16:10.52 | brlcad | vladbogo__: I just basically said that we need more information to do anything about the problem, and I don't doubt there is a problem |
| 16:10.57 | brlcad | that's why -fPIC is dangerous |
| 16:11.13 | brlcad | it will work in some places and will outright fail under other platform conditions |
| 16:11.26 | brlcad | and is dependent on several other compiler flag settings and library settings |
| 16:11.53 | brlcad | you can't just turn it on everywhere |
| 16:12.05 | vladbogo__ | brlcad: I know that's why I haven't committed the changes earlier |
| 16:12.45 | brlcad | vladbogo__: you should be committing .. and doing so very frequently |
| 16:12.54 | brlcad | just a matter of committing in a way that keeps us moving forward |
| 16:13.33 | vladbogo__ | brlcad: I know but I've just wanted to discuss with you the issue |
| 16:13.33 | brlcad | it takes some thought and planning while you code |
| 16:14.12 | brlcad | okay, and?? :) |
| 16:14.28 | vladbogo__ | I mean I knew that could be a problem so I did not want to put it there before talking to you |
| 16:14.28 | brlcad | of course you should discuss issues.... not sure what that has to do with how one commits ;) |
| 16:14.44 | brlcad | well, that's my point |
| 16:15.15 | brlcad | say you determined that it was 100% necessary but knew it also might be a problem |
| 16:15.21 | brlcad | so what do you do |
| 16:15.29 | brlcad | you don't need to wait on me to move forward |
| 16:15.37 | brlcad | you CERTAINLY don't need to wait to commit something |
| 16:15.46 | brlcad | that something just shouldn't be turning it on |
| 16:16.02 | brlcad | that's what I mean about you have to think it through and plan |
| 16:16.20 | *** join/#brlcad vladbogo_ (~vlad@86.121.99.145) |
| 16:17.00 | vladbogo_ | well cmake 2.8.11 solves the problem(no fPIC) so as you initially suggested I will leave it like this |
| 16:17.05 | brlcad | you could commit the flag check commented out or protected by an if () test, for example and then write the mailing list asking for help testing |
| 16:17.34 | brlcad | do you know why cmake 2.8.11 seems to solve the problem? |
| 16:17.47 | vladbogo_ | brlcad: that's good to know |
| 16:18.12 | vladbogo_ | not yet. I was planning to do a little research tonight |
| 16:18.18 | brlcad | then you cannot say that :) |
| 16:18.41 | brlcad | all you can say is that the problem is not observed |
| 16:18.55 | brlcad | claiming that cmake did anything isn't necessarily true |
| 16:19.46 | vladbogo_ | I saw on the qt-project.org that this is solved by cmake but it didn't say why |
| 16:20.12 | brlcad | simply, you don't know why it's working now ... and that's okay, but don't jump to conclusions until you understand the failure (and the reason it works) |
| 16:20.25 | vladbogo_ | brlcad: ok :) |
| 16:20.31 | brlcad | are you familiar with the verbose flag? |
| 16:20.43 | vladbogo_ | not really |
| 16:20.57 | brlcad | so by default, cmake hides everything |
| 16:21.09 | brlcad | which isn't at all helpful when you're dealing with low-level compilation issues like this one |
| 16:21.35 | brlcad | you need to know exactly what preprocessor, compilation, and linker flags are being used |
| 16:21.55 | brlcad | and know whether an error you're reading is a preprocessor failure, compilation failure, or linker failure |
| 16:22.12 | vladbogo_ | that would be useful |
| 16:22.21 | brlcad | it's not going to tell you which |
| 16:22.26 | brlcad | that's your job to figure out :) |
| 16:22.37 | brlcad | and it takes time to learn |
| 16:22.47 | brlcad | but to get that information from cmake, you have to compile verbose |
| 16:22.50 | brlcad | make VERBOSE=1 |
| 16:22.59 | vladbogo_ | yes but it would be easier to find |
| 16:23.01 | vladbogo_ | thanks:) |
| 16:23.33 | brlcad | you just have to get comfortable finding and reading a compile/linker line and understanding the messages that come back |
| 16:25.21 | vladbogo_ | thanks a lot for your help |
| 16:25.24 | Notify | 03BRL-CAD:vladbogo * 55884 brlcad/trunk/misc/CMake/CompilerFlags.cmake: Removed position independent code flag. |
| 16:26.13 | vladbogo_ | finally done with the cmake integration and I can start working on embedding Qt in Tk window |
| 16:29.03 | brlcad | excellent |
| 16:29.56 | vladbogo_ | thanks again for your help and clarifications |
| 16:54.58 | Notify | 03BRL-CAD:carlmoore * 55885 brlcad/trunk/include/icv.h: remove trailing blanks/tabs; fix spellings |
| 17:11.54 | zero_level | brlcad to handle file issues.. i am doing it this way. icv_create_image (instead of icv_save_open) and then do all the processing then icv_save (instead of icv_save_close) |
| 17:18.52 | brlcad | any way to shorten those function names consistently would be good |
| 17:19.06 | brlcad | this is the time to be thinking about API usability |
| 17:19.10 | brlcad | cleanliness of the names |
| 17:19.51 | brlcad | e.g., having icv_create_image() implies you might have the ability to icv_create_somethingelse() later ... is that true? |
| 17:20.13 | zero_level | no plans as such |
| 17:20.28 | brlcad | otherwise, maybe icv_create() or icv_image() becomes more appropriate and more API-friendly |
| 17:20.30 | zero_level | i guess that cld be trimmed to icv_create |
| 17:20.36 | zero_level | yes |
| 17:20.38 | brlcad | should think about that for every public symbol name |
| 17:21.50 | brlcad | and if you have a create or construction function, it should pair with another destroy/delete/close/whatever function unambiguously |
| 17:22.16 | zero_level | i have done this icv_free_image |
| 17:33.27 | brlcad | which again implies there's something other than images to free |
| 17:36.20 | *** join/#brlcad vladbogo__ (~vlad@86.121.103.35) |
| 18:07.06 | *** join/#brlcad Mahi (~Mahi@ec2-54-226-39-211.compute-1.amazonaws.com) |
| 18:14.20 | brlcad | zero_level: what's the status of patch 171? |
| 18:16.48 | *** join/#brlcad vladbogo__ (~vlad@86.124.248.147) |
| 18:21.02 | brlcad | zero_level: looks like 176 has the same issue and is ... basically the same patch?? |
| 18:21.31 | brlcad | you're not making this easy to review |
| 18:30.10 | *** join/#brlcad vladbogo_ (~vlad@86.121.96.174) |
| 18:56.56 | Notify | 03BRL-CAD Wiki:41.202.192.81 * 5528 /wiki/User:Izak/GSOC_2013_logs: /* From June 24th to June 28th */ |
| 19:10.17 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5529 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 19:47.56 | zero_level | brlcad: for all the patch informatio please see this http://brlcad.org/wiki/User:Level_zero/patches |
| 19:48.11 | zero_level | the convert patch is now at 197 and 198 |
| 19:48.23 | zero_level | it has the split versions |
| 19:50.26 | *** join/#brlcad vladbogo (~vlad@86.121.103.160) |
| 19:57.28 | Notify | 03BRL-CAD:carlmoore * 55886 brlcad/trunk/src/librt/primitives/bot/bot_wireframe.cpp: remove trailing blanks/tabs; fix a spelling |
| 20:01.42 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5530 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 21:39.41 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 22:05.57 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 22:12.16 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 22:52.38 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 22:53.38 | ``Erik | zero_level: if you dig into rt/view.c just a tiny bit more, you'll see that it gets the rgb data from ap->a_color which just happens to be 3 doubles. |
| 23:03.21 | zero_level | ok. |
| 23:04.16 | zero_level | ``Erik currently i have written image create, image load, image save functions |
| 23:04.29 | zero_level | for pix,bw,ppm formats |
| 23:05.22 | zero_level | what do u suggest should i attemppt for png format or refactor the old usage as per the new functions? |