| 00:43.20 | *** join/#brlcad Tecan (~fasdf@unaffiliated/unit41) |
| 00:46.57 | Tecan | its installed how do i run ? |
| 00:47.13 | Tecan | brlman has little / no effect |
| 00:47.36 | Tecan | sets a small fire in a corner to keep warm while waiting |
| 00:50.06 | Tecan | mged |
| 00:53.28 | Tecan | neat stuff |
| 00:55.27 | Tecan | is there a book on this stuff ? |
| 01:05.12 | *** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:35a3:eb2d:dc1f:917b) |
| 01:44.25 | *** join/#brlcad zero_level (~zero_leve@117.205.27.20) |
| 02:47.08 | *** join/#brlcad zero_level (~zero_leve@117.205.19.181) |
| 03:19.01 | *** join/#brlcad Tecan (~fasdf@unaffiliated/unit41) |
| 03:40.48 | *** join/#brlcad zero_level (~zero_leve@117.212.24.35) |
| 03:52.51 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 03:52.52 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 03:53.44 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 03:55.42 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 03:55.43 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 04:45.14 | *** join/#brlcad zero_level (~zero_leve@117.220.12.178) |
| 05:02.58 | *** join/#brlcad zero_level (~zero_leve@117.220.12.187) |
| 05:46.25 | *** join/#brlcad zero_level (~zero_leve@117.205.30.60) |
| 05:52.15 | *** join/#brlcad Tecan (~fasdf@unaffiliated/unit41) |
| 06:04.24 | *** join/#brlcad zero_level (~zero_leve@117.205.18.113) |
| 07:03.29 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 07:16.54 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 07:32.22 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 07:37.28 | *** join/#brlcad zero_level (~zero_leve@117.212.27.99) |
| 07:59.24 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 08:08.36 | *** join/#brlcad kesha (~kesha@49.249.200.67) |
| 08:13.59 | *** join/#brlcad zero_level (~zero_leve@117.212.31.132) |
| 08:32.33 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 08:49.08 | harmanpreet | ? |
| 08:58.45 | *** join/#brlcad zero_level (~zero_leve@117.205.27.235) |
| 09:17.09 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5439 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 1 */ |
| 09:23.07 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5440 /wiki/User:KeshaSShah/GSoC13/Reports: /* June 18 */ |
| 09:25.54 | *** join/#brlcad zero_level (~zero_leve@117.205.29.19) |
| 10:06.44 | *** join/#brlcad zero_level (~zero_leve@117.212.28.39) |
| 10:18.53 | *** join/#brlcad zero_level (~zero_leve@117.212.28.39) |
| 10:22.06 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 10:43.15 | *** join/#brlcad zero_level (75d41c27@gateway/web/freenode/ip.117.212.28.39) |
| 10:43.50 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 10:44.12 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b113:4dff:0:f:2df:b101) |
| 11:06.44 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 11:10.14 | *** join/#brlcad zero_level (~zero_leve@117.205.30.171) |
| 11:35.33 | *** join/#brlcad harmanpreet (~chatzilla@202.164.53.117) |
| 11:49.59 | *** join/#brlcad zero_level (~zero_leve@117.220.14.195) |
| 12:01.51 | zero_level | hi brlcad: ``Erik: |
| 12:02.03 | zero_level | among the utilities in the /src/util folder |
| 12:02.16 | zero_level | i am creating a utility to test my conversion functions. |
| 12:02.49 | zero_level | i compiled the source code as i did previously as illustrated in INSTALL file |
| 12:03.20 | zero_level | but the new test utility didnt get compiled ! |
| 12:03.34 | zero_level | do i have to add the information in some file ? where ? |
| 12:28.00 | *** join/#brlcad zero_level (~zero_leve@117.212.26.179) |
| 12:38.03 | *** join/#brlcad mpictor (~mpictor_@2600:1015:b10f:860d:0:f:2e6:7301) |
| 12:47.56 | *** join/#brlcad zero_level (~zero_leve@117.205.24.226) |
| 13:16.49 | *** join/#brlcad harmanpreet (~chatzilla@124.253.78.126) |
| 13:43.15 | *** join/#brlcad zero_level (~zero_leve@117.205.24.192) |
| 14:10.14 | brlcad | zero_level: yes, see the CMakeLists.txt file |
| 14:10.31 | brlcad | there's one in pretty much every directory that describes how to compile things in that directory |
| 14:10.51 | zero_level | also i guess Makefile.am |
| 14:10.55 | brlcad | if you're creating test tools, you may want to mirror the testing infrastructure in src/libbu/tests |
| 14:11.03 | brlcad | there are no longer Makefile.am files |
| 14:11.10 | brlcad | if you have them, you're not up to date |
| 14:11.16 | zero_level | ok |
| 14:11.24 | zero_level | i have 7.23.1 |
| 14:11.31 | zero_level | do i download 7.24 ? |
| 14:11.40 | brlcad | er.... no |
| 14:12.11 | brlcad | you should be working from a subversion checkout |
| 14:12.20 | brlcad | ~cadsvn |
| 14:12.20 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://svn.code.sourceforge.net/p/brlcad/code/brlcad/trunk brlcad |
| 14:12.38 | brlcad | that's the slow but sure way |
| 14:12.55 | zero_level | ok. i did this .. but days(months_) back |
| 14:12.58 | brlcad | for the faster svn+ssh:// method, go to the sf.net project page |
| 14:13.00 | zero_level | updating now |
| 14:13.07 | brlcad | okay, so then you need to run "svn up" |
| 14:13.22 | brlcad | you should run svn up every day, several times throughout the day |
| 14:13.53 | brlcad | basically every time you Notify write a message in here, there's an update to be received |
| 14:14.17 | brlcad | that means someone commited a change |
| 14:15.44 | *** join/#brlcad harman (~harman@202.164.53.122) |
| 14:18.17 | Notify | 03BRL-CAD:brlcad * 55797 brlcad/trunk/src/libbn/tcl.c: like this, zero_level (ws) |
| 14:20.23 | zero_level | i saw libbu now. where are the test tools installed ? |
| 14:20.49 | zero_level | didnt find them among the binaries |
| 14:20.52 | zero_level | brlcad: |
| 14:37.59 | *** join/#brlcad zero_level (~zero_leve@117.205.30.149) |
| 14:43.35 | brlcad | zero_level: they're not installed, but they are available after compilation in the build directory |
| 14:43.41 | brlcad | bin directory |
| 14:56.31 | zero_level | brlcad: also about committing changes! do i have the access to ? |
| 14:57.01 | brlcad | zero_level: considering you just today learned about "svn up", I'm not sure you're ready for commit access :) |
| 14:57.28 | zero_level | i used to do svn update |
| 14:57.33 | zero_level | :-) |
| 14:57.35 | zero_level | svn status |
| 14:57.39 | brlcad | keep submitting your work (daily) as patches and get folks to review them |
| 14:57.45 | zero_level | ok |
| 14:57.58 | brlcad | we have a backlog because of release |
| 14:58.06 | zero_level | ok |
| 14:58.08 | brlcad | used to ... but didn't in months? :) |
| 14:58.22 | brlcad | or weeks at least |
| 14:59.25 | zero_level | brlcad: also can we disucss about this mail http://sourceforge.net/mailarchive/message.php?msg_id=31038788 |
| 15:05.10 | brlcad | zero_level: big e-mails provoke big responses |
| 15:05.18 | brlcad | big responses take considerable time |
| 15:05.33 | brlcad | see aforementioned comment about there being a backlog because of release :) |
| 15:19.11 | *** join/#brlcad zero_level (~zero_leve@117.205.17.127) |
| 15:20.08 | *** join/#brlcad vladbogo (~vlad@188.25.101.47) |
| 15:27.01 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5441 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 15:45.04 | brlcad | if you have questions, ask them here and get your answer ... don't wait |
| 15:45.34 | brlcad | zero_level: big e-mails provoke big responses, big responses take lots of time -- see aforementioned comment about there being a backlog |
| 15:45.50 | vladbogo | hi all |
| 15:46.15 | vladbogo | i was working on the integration of qt in the cmake build yesterday |
| 15:46.17 | brlcad | that's part what makes IRC much more effective if you stay logged in, because we can answer quick questions easily |
| 15:46.27 | brlcad | hi vladbogo how goes it? |
| 15:46.37 | vladbogo | as i saw there is a slight difference between qt4 and qt5 |
| 15:47.02 | vladbogo | i successfully built a small project using qt5 |
| 15:47.30 | vladbogo | i wanted to ask you what version of qt should I use? |
| 15:48.44 | vladbogo | i still have to find out a way to determine the path to the qt installation. Hopefully I will find out that today |
| 15:49.01 | brlcad | you should use the very latest |
| 15:49.22 | vladbogo | that's what I used but I wanted to be sure |
| 15:50.29 | brlcad | definitely 5 |
| 15:51.23 | brlcad | vladbogo: for your project, build system issues are secondary -- you can/should get by with as little effort as possible |
| 15:51.37 | brlcad | once you have things working, we can hook up the build system properly very quickly |
| 15:52.05 | brlcad | unless you really want to understand the build system |
| 15:52.08 | brlcad | become a cmake guru |
| 15:52.31 | brlcad | otherwise, you can get away with just adding some compile/linker flags in your specific directory |
| 15:53.09 | vladbogo | ok then I will leave other details for later (such as determining the fact that qt is installed) |
| 15:53.34 | brlcad | yep |
| 15:53.41 | brlcad | just assume it's installed, use it |
| 15:53.54 | brlcad | when it comes time to commit, we can sort out the build |
| 15:54.04 | brlcad | vladbogo: where are your patches? |
| 15:54.15 | brlcad | can you provide the links? |
| 15:54.29 | brlcad | I know you have them down in a few places |
| 15:54.40 | vladbogo | immediately |
| 15:55.09 | vladbogo | this one is the latest |
| 15:55.10 | vladbogo | http://sourceforge.net/p/brlcad/patches/189/ |
| 15:55.47 | vladbogo | and also the qt patch |
| 15:55.49 | vladbogo | http://sourceforge.net/p/brlcad/patches/185/ |
| 15:56.11 | vladbogo | which is an improved version of the txt display manager |
| 15:56.30 | vladbogo | should I also provide the link to the ones I have done in the application period? |
| 16:01.16 | Notify | 03BRL-CAD:brlcad * 55798 brlcad/trunk/src/conv/g-voxel.c: accept sf patch 189 (Optional arguments g-voxel.c) from Vlad Bogolin which provides the same optional arguments as libged's voxelize command. |
| 16:07.36 | Notify | 03BRL-CAD:brlcad * 55799 brlcad/trunk/AUTHORS: accepted patch from vlad bogolin to clean up g-voxel, other patches pending too. he's a gsoc 2013 participant. |
| 16:16.28 | brlcad | vladbogo: per your mailing list comment, who did you talk with? |
| 16:17.20 | brlcad | I don't want to step in the way of their plans if they want you spending time working on proper integration early rather than later |
| 16:18.16 | brlcad | I just tend to like reactive, not anticipatory |
| 16:18.22 | vladbogo | D. Rossberg |
| 16:19.09 | brlcad | and the build isn't technically strictly necessary until it comes time to enable that code, so it can happen now or later |
| 16:19.11 | brlcad | okay |
| 16:19.50 | brlcad | so keep on then, but just don't let yourself get stuck -- we have a lot of cmake expertise here |
| 16:19.58 | vladbogo | we haven't discussed in what degree the integration should be done |
| 16:20.04 | brlcad | there should be a find qt macro that you can run |
| 16:20.19 | brlcad | we're not bundling qt, it's too big |
| 16:20.37 | vladbogo | I found that but in order to work I have to specify the path in the CMAKE_PREFIX_PATH |
| 16:20.42 | brlcad | so the build system needs to simply test for it, similar to how it currently tests for X11, and if it's available, it builds your interface |
| 16:21.46 | brlcad | where is qt installed on your system |
| 16:21.59 | vladbogo | in the home directory |
| 16:22.43 | brlcad | so that's something cmake could never find on its own, you have to tell it |
| 16:22.57 | brlcad | did you read http://qt-project.org/quarterly/view/using_cmake_to_build_qt_projects ? |
| 16:23.12 | brlcad | and http://www.kdab.com/using-cmake-with-qt-5/ |
| 16:23.35 | vladbogo | yes this are exactly the pages I used |
| 16:23.56 | brlcad | okay great |
| 16:24.56 | brlcad | so then try just setting the prefix path |
| 16:25.08 | brlcad | CMAKE_PREFIX_PATH=~/path/to/Qt cmake .. |
| 16:25.32 | brlcad | or cmake -DCMAKE_PREFIX_PATH=~/path/to/Qt .. |
| 16:25.40 | vladbogo | like this it works |
| 16:26.17 | brlcad | then you just need to use the right variables to enable/disable your files |
| 16:27.40 | brlcad | follow the logic for BRLCAD_ENABLE_X11 as I expect you'll need to add similar lines for BRLCAD_ENABLE_QT |
| 16:27.57 | brlcad | in the top-level CMakeLists.txt file and src/libdm/CMakeLists.txt file |
| 16:29.14 | vladbogo | i will look then there. Now (in the qt-dm patch) the BRLCAD_ENABLE_QT is always set |
| 16:29.56 | vladbogo | this was planned for today |
| 16:30.15 | brlcad | k |
| 16:30.38 | brlcad | vladbogo: curious, looking over your dm-txt patch -- why do you export all of the functions? |
| 16:32.39 | vladbogo | that was a misunderstanding |
| 16:32.50 | vladbogo | the txt dm patch needs some reviews |
| 16:33.49 | vladbogo | i focused on solving the problems on the qt-dm |
| 16:35.10 | vladbogo | should I fix the dm-txt patch? |
| 16:54.21 | brlcad | yes please |
| 16:54.43 | brlcad | probably end up not even needing that new header |
| 16:54.52 | vladbogo | yes |
| 16:55.17 | vladbogo | i did all the changes in the qt dm which at the moment is basically the same |
| 16:56.13 | brlcad | nods |
| 17:01.09 | vladbogo | i will start working to the txt dm |
| 17:07.03 | vladbogo | also I want to ask you how should I approach the existence of the txt dm? Is it ok if it's the same as the null dm and the macro is defined in dm.h? |
| 17:09.15 | harman | brlcad: Hi, I was working for making a patch to add feature requested at: http://sourceforge.net/p/brlcad/feature-requests/130/. I read your comment on this link to get some idea, but I am not getting; from which to which file I am suppose to move? |
| 17:10.26 | brlcad | vladbogo: what macro? |
| 17:10.52 | brlcad | if it's got a macro that has to be published, that would be a reason for it to have a header |
| 17:11.29 | brlcad | harman: sourceforge is apparently having problems today .. site is really slow |
| 17:13.09 | vladbogo | brlcad: dm.h (line 53) (#define DM_NULL (struct dm *)NULL) I used the same approach to determine that the txt dm exists and defined it there. Being a debug dm I suppose it is ok because it has to be present anytime |
| 17:13.47 | brlcad | vladbogo: DM_NULL is just a typecast NULL |
| 17:13.57 | brlcad | for older compilers |
| 17:14.16 | brlcad | that could/should basically be NULL nowadays |
| 17:14.32 | brlcad | i don't see what that has to do with your txt dm though.. |
| 17:16.04 | brlcad | harman: okay, 130 finally displayed -- the task involves the journal command in mged, yes? |
| 17:16.15 | harman | yes.. |
| 17:16.28 | brlcad | harman: so where is the journal command sources? |
| 17:16.58 | brlcad | aside from asking, how might you go about finding it? |
| 17:18.00 | harman | actually.. I read your comment and was trying to follow what you said. |
| 17:18.25 | brlcad | okay |
| 17:18.38 | harman | i searched for bu_log_add_hook |
| 17:18.46 | vladbogo | brlcad: nevermind. I was thinking at something wrong |
| 17:18.51 | harman | and I found it on log.c |
| 17:18.53 | harman | ok |
| 17:19.23 | brlcad | okay, that's where that particular function is implemented, and? |
| 17:21.21 | harman | means.. I found this in log.c |
| 17:32.34 | brlcad | heh |
| 17:34.10 | brlcad | harman: if I'm trying to help you with something, you have to actually ask a question or you'll have to follow down a line of reasoning to help you understand what you need to do next |
| 17:35.26 | brlcad | you wrote "from which to which file I am suppose to move?" which I started to help you with, and you redirected onto my comment about bu_log_add_hook, so my response followed "and?" and so what? you found the sources for that log function. now what? |
| 17:37.10 | brlcad | glad to help, but I'm not just going to try and guess or be a professor on a white board telling you all there is to know about bu logging or the journal command or mged's command infrastructure and hope that something I say is something you were needing to hear |
| 17:37.17 | brlcad | that'd be inefficient, right? |
| 17:37.32 | brlcad | so I'll help you get to where you're going, but I'm not going to drive the car :) |
| 17:39.12 | brlcad | you have the right idea, obviously you should try to understand my reply to the feature request since I basically say how to do it |
| 17:39.30 | brlcad | but you must first understand and reproduce the problem so you know what it is you're trying to change |
| 17:39.40 | brlcad | have you run the journal command? |
| 17:39.56 | harman | oh.. I was away from system.. |
| 17:40.04 | brlcad | you're allowed to do that |
| 17:40.08 | brlcad | :) |
| 17:40.09 | harman | yes. |
| 17:40.20 | harman | i run it |
| 17:40.28 | brlcad | do you understand the problem as tom stated it? |
| 17:40.32 | harman | yes |
| 17:40.43 | brlcad | do you know where/how the journal command is implemented? |
| 17:41.01 | harman | no |
| 17:41.18 | brlcad | so there's your first step before trying to understand my reply since that's part of the problem statement scope |
| 17:41.31 | harman | okay.. |
| 17:41.34 | brlcad | do you know how to go about finding it? |
| 17:41.56 | brlcad | variety of ways |
| 17:44.34 | harman | I basically do file search |
| 17:46.16 | brlcad | okay, that's a fine starting point, so what does that tell you? |
| 17:46.22 | harman | but that does not give produce any result.. |
| 17:47.32 | brlcad | how are you searching? |
| 17:47.54 | brlcad | you're clearly able to run the journal command so SOMEWHERE in the source tree there should be at least one reference to the word journal |
| 17:48.56 | harman | history.c? |
| 17:49.32 | brlcad | I assume you more specifically mean src/mged/history.c |
| 17:50.03 | harman | yes yes |
| 17:50.45 | brlcad | that sounds like the place, and if you followed a different approach for finding the command, it would be confirmed |
| 17:51.20 | harman | i used grep command |
| 17:51.29 | brlcad | good |
| 17:51.43 | brlcad | if you looked in src/mged, you would have found a reference to "journal" and and f_journal function |
| 17:52.21 | brlcad | that piece of code should look very much like a command table, and would have been strong evidences that you "found" where the command is hooked in |
| 17:52.35 | brlcad | that f_journal function becomes the starting point |
| 17:52.48 | brlcad | from there, you find the implementation in history.c |
| 17:53.24 | brlcad | okay, so now you should try to follow the logic in that file, starting with f_journal(), to see if you have a basic understanding of what it's doing |
| 17:53.39 | harman | okay.. |
| 17:53.40 | brlcad | then re-read my response about how to possibly go about fixing it |
| 17:53.51 | harman | ok |
| 17:55.37 | harman | i will do it |
| 17:55.53 | brlcad | once you have a basic understanding of the command, that should really help with figuring out what you can do to fix it |
| 17:56.09 | brlcad | at which point my comments may help or you may even end up with a better idea |
| 17:56.24 | brlcad | that command was very quickly implemented, terrible code, so there's lots of room for improvement |
| 17:56.33 | brlcad | you could simply start by making a patch that cleans up the code |
| 17:56.49 | harman | okay.. |
| 17:56.55 | brlcad | refactoring and improving code while you read it is a great way to learn the code too |
| 17:57.11 | harman | thanks for the tip |
| 17:57.32 | brlcad | just make sure any "cleanup" changes you make are not mixed with any feature request changes |
| 17:57.40 | brlcad | (a patch should do just one thing, not many things) |
| 17:58.21 | harman | i will keep it in mind |
| 17:58.30 | brlcad | same thing with commits |
| 17:58.54 | harman | okay.. |
| 18:00.40 | *** join/#brlcad caen23_ (~caen23@92.81.220.39) |
| 18:00.45 | harman | you were talking about ideas you and other developers have idea to improve project scope |
| 18:00.45 | brlcad | vladbogo: your patches are looking great, daniel was happy too |
| 18:01.01 | brlcad | vladbogo: you now have commit access, test commit some small change now if you would please |
| 18:01.20 | vladbogo | brlcad: thanks |
| 18:01.28 | brlcad | vladbogo: and (re)read the HACKING section on dev responsibilities |
| 18:02.01 | vladbogo | brlcad: i have also submitted the txt dm with fixes |
| 18:02.22 | brlcad | harman: yeah, actually it was from another dev who really frowned on the proposed interface approach, but liked the idea of a web interface overall |
| 18:02.24 | vladbogo | brlcad: i will read the HACKING again |
| 18:02.38 | brlcad | vladbogo: excellent |
| 18:04.13 | brlcad | vladbogo: so patch 179 is curious... |
| 18:04.38 | zero_level | brlcad: i am posting few issues from the mail her |
| 18:04.42 | zero_level | *here |
| 18:05.09 | zero_level | brlcad #Proposal Time Line Modifications |
| 18:05.35 | zero_level | I wish to remove group 10-11 from my proposal. I believe this will help in more time for the import/export tools and increases feasibility of the project. |
| 18:05.48 | zero_level | My Update proposal time line is here http://brlcad.org/wiki/User:Level_zero/GSOC13/timeline |
| 18:07.13 | vladbogo | brlcad: i think that approach should be discussed in order to make the best decision. That is just an idea I had in order to reduce the #ifdefs |
| 18:07.39 | brlcad | vladbogo: it seems like an incomplete patch? you leave dm_open() and add a new function and a new MY_*() macro (bad name) |
| 18:08.47 | brlcad | zero_level: what were groups 10-11? |
| 18:08.57 | vladbogo | I know it's a bad name. My idea would be to modify DM_OPEN as MY_DM_OPEN but as I only did the refactoring for the X dm that was not possible |
| 18:09.34 | brlcad | I think that's the "incomplete" I'm seeing |
| 18:09.39 | zero_level | http://brlcad.org/wiki/User:Level_zero/GSOC13/Refinements#Merge_or_Split_.28GROUP.2310.29 |
| 18:10.23 | vladbogo | brlcad: adding a comment for the first commit it's ok? |
| 18:11.58 | vladbogo | brlcad: I didn't knew if my idea for the patch it's better than the actual implementation so I submitted the patch and if you think that it is useful to finish it I will work on refactoring all the dm's |
| 18:12.06 | zero_level | brlcad u will find information regarding that on the web link |
| 18:12.08 | brlcad | vladbogo: as long as it's a useful comment or improving a comment, sure |
| 18:14.08 | brlcad | vladbogo: now that you have commit, you can think about it from a different approach and incrementally get there |
| 18:15.54 | brlcad | for example, one commit could add the new dm_open callback to the struct, and NULL entries for all of the DM's (with nothing using them) |
| 18:16.32 | brlcad | zero_level: brevity instead of links is nice ;) but that's a good question to ask your reviewing mentor |
| 18:16.52 | zero_level | is he around today ? |
| 18:17.05 | brlcad | zero_level: technically speaking, I'm much more concerned that you end up with a solid API design, framework for growth, and completely migrated commands -- not works in progress |
| 18:17.24 | brlcad | so most of your groups are secondary towards design |
| 18:17.29 | zero_level | ok |
| 18:17.48 | brlcad | already told you during evals that you were being way too ambitious/presumptuous :) |
| 18:18.19 | brlcad | your schedule should reflect where all your time is still going though regardless |
| 18:18.51 | harman | brlcad: okay... you mentioned in the message that focusing on NURBS instead of reinventing the wheel with basic shapes would improve scope. Can you please tell how can I invlove NURBS in my project? |
| 18:19.14 | zero_level | brlcad yesterday i submitted a patch regarding icv_structures. patch num = 192. link = http://sourceforge.net/p/brlcad/patches/192/ |
| 18:20.42 | vladbogo | brlcad: yes I know what you mean but I don't know if the select_dm function is the best approach because it still has ifdefs. |
| 18:22.02 | brlcad | harman: yeah, and that is probably an involved discussion |
| 18:22.37 | brlcad | but the basic notion is that we still don't think you fully get what you're proposing with editing representations on the front-end and boolean operations .... :) |
| 18:23.05 | brlcad | and we really don't want to end up with a idea that is never put into production use or just ends up being a neat demo |
| 18:23.25 | brlcad | or that duplicates existing functionality unnecessarily! so many concerns. ;) |
| 18:24.03 | brlcad | which leaves us introspecting what sort of interface WOULD be useful that we do not readily have that might make sense in a browser |
| 18:24.22 | brlcad | and still fits within scope |
| 18:24.53 | brlcad | zero_level: I saw it |
| 18:25.01 | zero_level | brlcad : ok |
| 18:25.17 | brlcad | vladbogo: that is true, twas another critique |
| 18:25.25 | zero_level | am i going right there ? |
| 18:25.30 | brlcad | the whole point of those structure callback tables is to avoid the ifdefs |
| 18:26.11 | brlcad | vladbogo: perhaps another approach would be a callback that returns the type ... depends on how it's used, right? |
| 18:26.23 | zero_level | brlcad: today i am making test functions for my convert patches |
| 18:26.53 | zero_level | also working on group 1 (Croping) test compiles. |
| 18:27.00 | brlcad | zero_level: you just submitted that, there are some others ahead of it... :) |
| 18:27.11 | zero_level | ok |
| 18:27.16 | vladbogo | brlcad: I know but there still has to be a way to select the dm. A new callback that returns the type sounds like a good idea. |
| 18:27.30 | brlcad | if your old patches aren't perfect, i'd suggest giving them a look over once again (and make them perfect) |
| 18:27.52 | brlcad | vladbogo: maybe .. it just depends what that type is used for |
| 18:28.01 | brlcad | ideally we'd fully hide the type, it shouldn't matter |
| 18:28.58 | brlcad | at most, callers really only need a few things like whether OpenGL is available, whether there are events, maybe whether it's current,e tc |
| 18:29.10 | zero_level | also brlcad: i have created an index page on wiki which contains all the info. I hope u have seen that. the link is here http://brlcad.org/wiki/User:Level_zero/ |
| 18:29.31 | vladbogo | brlcad: i will consider this and think about a better solution |
| 18:30.51 | brlcad | zero_level: no I hadn't seen that because that trailing slash isn't the convention for user dirs |
| 18:30.55 | brlcad | http://brlcad.org/wiki/User:Level_zero |
| 18:31.05 | brlcad | should move the page |
| 18:31.53 | Notify | 03BRL-CAD Wiki:Level zero * 0 /wiki/User:Level_zero/: trailing slash is not the convention |
| 18:32.19 | zero_level | brlcad : here it is http://brlcad.org/wiki/User:Level_zero/index |
| 18:33.33 | harman | brlcad: ok.. if it is an invloved discussion then I can start discussion over mailing list and in the mean time I should work on patches. Is it OK? |
| 18:34.39 | zero_level | brlcad : our bwhisteq uses the same method as histeq. But the mapping is done as such it avoids the closed form function to find the new map. |
| 18:37.17 | brlcad | harman: it's more an extension of your proposal discussion |
| 18:37.34 | brlcad | on http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harman052/15001#c46001 |
| 18:38.36 | brlcad | zero_level: closed form... avoids what? statement doesn't say anything to me as worded other than our bwhisteq tool matches matlabs histeq function |
| 18:39.26 | brlcad | "But the mapping is done as such it avoids the closed form function to find the new map." ... which mapping? what is it? new map from what? how is closed form relevant? :) |
| 18:40.04 | harman | brlcad: sorry, i didn't get you. |
| 18:40.50 | brlcad | harman: i'm saying that you probably don't have enough to start a discussion... :) |
| 18:41.02 | brlcad | and just asking for people to talk isn't likely going to start a discussion |
| 18:41.39 | harman | then what next? |
| 18:43.00 | brlcad | so I've got a little time now, lets discuss where we left off |
| 18:43.19 | *** join/#brlcad kesha (~kesha@49.202.239.196) |
| 18:43.20 | brlcad | I get how you're planning on displaying projected rpps in four views |
| 18:44.12 | brlcad | but then what? you used that in response to my concerns about how that applies to the general case that you are reportedly aiming for |
| 18:44.23 | brlcad | but your description doesn't generalize |
| 18:44.49 | brlcad | it only works for rpps because an un-rotated projected rpp is just a rectangle and the web tech deals with drawing rectangles fine |
| 18:45.39 | brlcad | even with rpps, I don't think your description deals with the visualization aspect |
| 18:46.12 | brlcad | if I move an rpp in just one view and subtract it, what does that mean? how is the subtraction performed? |
| 18:46.22 | brlcad | the result is not an rpp any longer |
| 18:49.03 | brlcad | I think to make progress on a different direction, you're going to need to understand what this problem is about geometry representation types, what data you actually have to work with, and what it is exactly that is being accomplished |
| 18:49.38 | brlcad | and this is very much not feeling like a discussion. hello? |
| 18:50.01 | harman | i am reading and thinking |
| 18:51.55 | brlcad | taking a step back, the overarching goal was stated as a web interface to BRL-CAD |
| 18:52.12 | harman | yes.. |
| 18:52.27 | brlcad | that's obviously very open-ended, with a lot of room for doing something really interesting and useful and not held back by our current usability limitations |
| 18:52.32 | brlcad | that part I think we all get :) |
| 18:53.53 | brlcad | however to "shift all features and functionality of desktop software to browser" is a very big statement from your proposal that begs for understanding why this is a problem now |
| 18:54.41 | brlcad | why does BRL-CAD currently not have OpenGL shaded display visualizations of geometry? |
| 18:55.28 | harman | "shift all features and functionality of desktop software to browser is the ultimate goal. |
| 18:55.47 | brlcad | yes, I realize this is meant as a small stepping stone, just a start |
| 18:55.58 | harman | yes |
| 18:56.10 | vladbogo | brlcad: I am trying to make my first commit but I don't know how to specify my sourceforge username(I am trying svn commit --username). Can you give me a hint? |
| 18:56.24 | brlcad | but there still seems to be a fundamental realization that is yet to be attained... :) |
| 18:56.51 | brlcad | vladbogo: just run svn commit, it'll prompt a password, hit enter, it should prompt a username |
| 18:57.42 | brlcad | harman: so to my question -- why don't we already have pretty opengl shaded views? |
| 18:58.52 | harman | please explain.. |
| 18:59.18 | brlcad | your proposal addresses a fundamental issue in BRL-CAD |
| 18:59.41 | brlcad | it's hard to use, the interface is not "modern" or pretty or shaded ( you get wireframes ) |
| 18:59.45 | brlcad | why do we display wireframes |
| 18:59.50 | brlcad | why not something else? |
| 19:00.00 | harman | you said.. wireframes |
| 19:00.03 | vladbogo | brlcad: i tried that and it does not prompt neither password or username: simply opens the editor and after writing the comment prompts svn: Authorization failed |
| 19:00.20 | harman | has mathematical reason behind their implementation |
| 19:01.16 | brlcad | vladbogo: it'll depend what method you used to check out -- go to the sf.net page and get a read/write checkout url |
| 19:01.35 | vladbogo | brlcad: thanks |
| 19:01.44 | brlcad | harman: wireframes don't have mathematical reasoning behind them |
| 19:01.52 | brlcad | wireframes are just a bunch of 3d line segments |
| 19:02.10 | harman | okay |
| 19:02.26 | brlcad | if I open up the editor, create a sphere, create a cylinder that runs into the sphere, create another sphere on the other end, and union the shape together (like a barbell) ... what's the problem displaying that? |
| 19:02.30 | brlcad | o-o |
| 19:02.41 | brlcad | or better: O=O |
| 19:03.27 | brlcad | is there a problem? |
| 19:03.33 | harman | with wireframes? |
| 19:03.51 | brlcad | no, we obviously already show the wireframe |
| 19:03.58 | brlcad | but why the wireframe |
| 19:04.02 | brlcad | why not show the geometry shaded |
| 19:04.13 | harman | yes.. I too wanted to know |
| 19:04.14 | brlcad | like games or blender or any other 3D |
| 19:04.14 | harman | as |
| 19:04.22 | harman | there are so many CAd softwares |
| 19:04.24 | brlcad | this is what you're missing :) |
| 19:04.28 | harman | like FreeCAD |
| 19:04.37 | brlcad | mhmm, so why? |
| 19:04.42 | harman | :-) |
| 19:05.02 | harman | you can explain better.. ;-) |
| 19:05.16 | brlcad | "you're going to need to understand what this problem is about geometry representation types" |
| 19:05.28 | brlcad | geometry representation |
| 19:05.56 | brlcad | what does it mean to be a representation of geometry .. what is your data .. what is your representation type |
| 19:06.07 | brlcad | take a simple sphere |
| 19:06.18 | brlcad | a point (0,0,0) and a radius (10) |
| 19:06.25 | harman | hmm |
| 19:06.25 | brlcad | now display it |
| 19:06.38 | brlcad | what do you do? |
| 19:07.33 | brlcad | for sake of relevance, say we're using your web interface even, nice snazzy html5 canvas or webgl, doesn't matter |
| 19:08.06 | harman | 1. user select primitive (sphere). |
| 19:08.24 | harman | 2. fill radius and name of object. |
| 19:08.51 | harman | in input boxes (that appear after selection) |
| 19:08.58 | brlcad | that's what the user does, sure fine |
| 19:09.02 | brlcad | now what do YOU do |
| 19:09.15 | brlcad | you being the code you wrote to ultimately display the sphere |
| 19:09.25 | harman | wait.. |
| 19:10.03 | brlcad | user does #1, does #2 (specifies radius 10), now how is it actually displayed? |
| 19:10.03 | harman | 3. this will draw a circular shape in the windows.. |
| 19:10.03 | brlcad | how? |
| 19:10.30 | harman | now at this time.. only circular shape made in html5 or js is drawn |
| 19:10.47 | brlcad | and for clarity, we're not drawing a 2d circle and pretending it's a sphere, we want a 3d shaded sphere |
| 19:10.54 | harman | that represent sphere (it's 2D view) |
| 19:11.51 | brlcad | we can have this exact same explanation in 2D if you'd like, but the goal was not 2D |
| 19:12.17 | harman | that's why we provide 4 windows to see 2D different views of 3D object |
| 19:13.42 | brlcad | which is why you're not understanding the problem :) |
| 19:13.51 | brlcad | okay, so lets simplify this to 2D |
| 19:13.52 | harman | ?? |
| 19:14.23 | brlcad | the 4 views doesn't have anything to do with representation |
| 19:14.36 | brlcad | they're just views |
| 19:14.48 | harman | yes |
| 19:14.56 | harman | they are just views |
| 19:14.57 | brlcad | so lets say we have a view that is 100x100 |
| 19:15.05 | harman | ok |
| 19:15.30 | brlcad | and the view is centered at 0,0 |
| 19:15.37 | brlcad | so -50,-50 to 50,50 |
| 19:15.52 | brlcad | and we're now working with 2D geometry |
| 19:16.04 | harman | hmm |
| 19:16.08 | brlcad | your geometry is a 2D circle defined with origin (0,0) and radius (10) |
| 19:16.24 | brlcad | you want to visualize it, what do you do? |
| 19:16.59 | brlcad | i don't mean what does the user do |
| 19:17.07 | brlcad | what do YOU make the code do to display it? |
| 19:17.29 | harman | Oh I see.. |
| 19:18.18 | harman | you mean how we will visualize it in 3D world? |
| 19:18.44 | brlcad | we're sticking with 2D at the moment |
| 19:18.55 | brlcad | pretending BRL-CAD is a fully 2D CAD system |
| 19:19.10 | Notify | 03BRL-CAD:vladbogo * 55800 brlcad/trunk/src/conv/g-voxel.c: Added comment to src/conv/g-voxel.c to highlight the optional parameters section. |
| 19:19.21 | brlcad | we show an outline of a circle, outlines of boxes, etc. .. wireframes only, and we're trying to figure out why |
| 19:19.54 | brlcad | you're making a new fancy web interface to show off this 2D system but don't want to just display wireframes |
| 19:20.02 | harman | yes.. in that case we will have outlines |
| 19:20.23 | brlcad | so user specifies a circle, how do you display it? |
| 19:20.24 | harman | filled with colour |
| 19:20.34 | brlcad | HOW |
| 19:20.51 | harman | html5 is capable to make such shapes |
| 19:20.55 | brlcad | c'mon man, you're a dev, talk code to me :) |
| 19:21.23 | brlcad | better, okay so you plan to use html5 to display such a shape (2d circle) |
| 19:22.05 | harman | yes |
| 19:22.11 | brlcad | now the user creates another circle half offset from the first |
| 19:22.27 | brlcad | you again draw the second with html5 |
| 19:23.27 | brlcad | that's all fine, yes? |
| 19:23.37 | harman | yes |
| 19:23.39 | brlcad | now the user requests an intersection boolean operation |
| 19:23.43 | brlcad | what do you do? |
| 19:23.43 | harman | ok |
| 19:25.17 | harman | i mentioned in the proposal that |
| 19:25.30 | brlcad | forget the proposal, we're talking here and now :) |
| 19:25.56 | brlcad | i have two circles defined and an intersection, what do you do? |
| 19:26.01 | brlcad | how do you visualize that? |
| 19:26.12 | harman | order of selction will matter |
| 19:26.27 | brlcad | for an intersection order does not matter |
| 19:26.38 | harman | suppose circle A and circle B.. |
| 19:26.39 | brlcad | a ^ b |
| 19:27.23 | harman | we will be keeping a function behind the scene that holds the command of intersection |
| 19:27.43 | harman | in which we just need to fill the names of objects |
| 19:27.50 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5444 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 19:28.12 | brlcad | okay, so "comb intersection a + b" in BRL-CAD parlance ... we still need to visualize this |
| 19:28.29 | harman | means? |
| 19:29.34 | brlcad | i've asked how you visualize that shape |
| 19:29.44 | harman | the resulted shape? |
| 19:30.00 | brlcad | whatever you want to display |
| 19:30.23 | brlcad | user created two spheres and asked for an intersection, what do you do to show them that? |
| 19:30.49 | brlcad | you've told me you have a function that holds a command .. that obviously doesn't show them that |
| 19:30.53 | brlcad | what do you do to show them that? |
| 19:31.20 | brlcad | sorry, two circles |
| 19:34.17 | harman | we have event handlers in javascript that can be used to show result on the browser |
| 19:34.33 | harman | after user finishes |
| 19:34.36 | brlcad | you're goin to again make me ask HOW aren't you :) |
| 19:35.30 | brlcad | how is the result of that action displayed? |
| 19:36.15 | brlcad | hums a song |
| 19:39.16 | brlcad | harman: this is entirely about data and algorithm, not toolkits or user interface |
| 19:40.14 | brlcad | your inability to answer is getting at the heart of the problem |
| 19:42.20 | harman | yes.. algorithm and all that to be faced at later stage not now. i know it is possible but and can be done using above mentioned tools. |
| 19:42.37 | brlcad | i'm going to have to go soon, but think about it for a while -- how do you actually show the result of an intersection of two circles? how is the evaluation performed? what is the resulting data? |
| 19:42.50 | brlcad | no you don't know that |
| 19:43.11 | brlcad | because it's not possible with just the mentioned tools ... without you implementing everything that's missing |
| 19:43.34 | brlcad | the algorithm is not to be sorted out later, it's central to the ENTIRE problem |
| 19:44.13 | *** join/#brlcad caen23 (~caen23@92.81.220.39) |
| 19:44.15 | harman | that flow i already explained, the function holds intersection command |
| 19:44.16 | brlcad | you don't yet understand why and that was fine during the proposal review |
| 19:44.21 | brlcad | but now it's critical |
| 19:44.29 | brlcad | okay, it holds a command |
| 19:44.48 | brlcad | and then what? |
| 19:45.06 | brlcad | that doesn't show anything |
| 19:45.22 | brlcad | that doesn't even calculate anything from an algorithmic perspective as described |
| 19:46.09 | harman | user's selection picks the names of objects and supply to function that fills into command. |
| 19:46.32 | harman | that command is written into file. |
| 19:47.41 | brlcad | we could have this same discussion with pen and paper .. draw a circle on a piece of paper then draw another overlapping circle ... now I ask for you to draw me the intersection |
| 19:47.55 | brlcad | here's your piece of paper, what do you do? |
| 19:50.14 | harman | it is already drawn when both circles overlapped. :-) |
| 19:50.27 | brlcad | no, that's the union |
| 19:50.44 | harman | omg |
| 19:51.01 | harman | sorry |
| 19:51.05 | brlcad | http://mathworld.wolfram.com/Circle-CircleIntersection.html |
| 19:51.13 | brlcad | see image under (16) |
| 19:52.16 | harman | i know intersection.. actually your questions.. |
| 19:52.19 | harman | :-) |
| 19:52.34 | brlcad | hm? |
| 19:52.50 | brlcad | not following |
| 19:52.51 | harman | erase the non overlapping part |
| 19:53.00 | harman | we got intersection |
| 19:53.02 | brlcad | i gave you a new sheet of paper |
| 19:53.12 | brlcad | how do you draw just the intersection? |
| 19:54.27 | brlcad | you're on the right track, but technically insufficient |
| 19:58.16 | brlcad | harman: alright, times up, gotta run |
| 19:58.20 | brlcad | please do continue to this about this |
| 19:58.31 | brlcad | think about how it pertains to 2D circles |
| 19:58.51 | brlcad | think about how it extends to arbitrary shapes (non-circles) |
| 19:59.24 | brlcad | where/how the evaluation is performed, how you're actually showing a result, where that data comes from ... and then how that all extends into 3D! |
| 19:59.44 | brlcad | we can talk more later, but this is THE central issue |
| 19:59.49 | harman | okay |
| 20:00.16 | brlcad | s/please do continue to this about this/please do continue to THINK about this/ |
| 20:00.45 | brlcad | I'll be waiting to hear what you've understood the next time we talk |
| 20:00.58 | harman | sure |
| 20:01.03 | brlcad | in the meantime, work on a good patch or three ;) |
| 20:01.40 | harman | hmmm |
| 20:09.02 | Notify | 03BRL-CAD:brlcad * 55801 (brlcad/trunk/include/dm.h brlcad/trunk/src/libdm/CMakeLists.txt and 3 others): accept sf patch 163 (Added a text DM) by Vlad Bogolin which implements a non-graphical text debugging interface to libdm. |
| 20:13.48 | brlcad | vladbogo: so I'd call 55800 an unuseful comment as that's pretty much exactly what the code says too. comments should say what the code does not. (and there's probably not much to be said about a getopt block) |
| 20:14.18 | brlcad | might as well say /* do some stuff */ :) |
| 20:25.30 | vladbogo | brlcad: sorry about that. I will be more careful in the future and I will remove when I change the txt_open_dm() |
| 20:29.38 | Notify | 03BRL-CAD:starseeker * 55802 brlcad/trunk/src/librt/primitives/bot/bot_wireframe.cpp: Start trying to figure out how to speed up the sparse bot wireframe drawing |
| 20:30.36 | *** join/#brlcad mpictor (~mark@2601:d:b280:9:d63d:7eff:fe2d:2505) |
| 20:34.31 | Notify | 03BRL-CAD:starseeker * 55803 brlcad/trunk/src/librt/primitives/bot/bot_wireframe.cpp: memset instead of loop here |
| 21:04.37 | Notify | 03BRL-CAD:vladbogo * 55804 (brlcad/trunk/src/conv/g-voxel.c brlcad/trunk/src/libdm/dm-generic.c brlcad/trunk/src/libdm/dm-txt.c): Renamed txt_open_dm to txt_open to maintain consistency. Also removed unuseful comment from g-voxel.c |
| 21:14.17 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5445 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 1 */ |
| 21:23.50 | *** join/#brlcad Ch3ck (295cd318@gateway/web/freenode/ip.41.92.211.24) |
| 22:16.27 | *** join/#brlcad zero_level (~zero_leve@117.205.16.131) |
| 22:51.06 | ``Erik | zero_level: I think your submitted icv struct patch tries to add too much at one whack... there are some parts that I like and some that I'm not sure I agree with, but the lumping turns it into an "all-or-nothing" decision... |
| 22:51.47 | zero_level | ``Erik ok |
| 22:52.15 | zero_level | what is lumping turns it into an "all-or-nothing" decision ? |
| 22:52.22 | ``Erik | zero_level: I'm ok with the operations enum, I don't think having structs for geometry and position add any value |
| 22:53.15 | ``Erik | ICV_SIZE_NULL seems redundant, just use NULL |
| 22:53.17 | zero_level | ``Erik point will be required in few functions |
| 22:53.28 | zero_level | like icv_rect |
| 22:53.39 | ``Erik | icv_kernel is poorly named/commented, I don't understand what it's for |
| 22:53.56 | zero_level | icv_kernel stores the kernel information for filtering |
| 22:54.02 | zero_level | i will add the comments there |
| 22:55.11 | zero_level | ``Erik geometry ? |
| 22:55.12 | ``Erik | generally, a patch should be the same as a commit... it should be very focused in what it does and the 'one brief line' comment should instantly let the casual reader understand the purpose, extent and change |
| 22:55.16 | ``Erik | width/height |
| 22:55.33 | zero_level | u mean size ? |
| 22:55.36 | ``Erik | yes |
| 22:55.53 | ``Erik | what's wrong with passing in width, height, X and Y as seperate arguments? |
| 22:56.12 | zero_level | ok. what we could do is define a macro |
| 22:56.19 | zero_level | for size |
| 22:56.28 | zero_level | and keep points alive |
| 22:56.45 | ``Erik | "struct icv_size { int width, height; }" kinda makes me go "ugh, someone has been looking at too much bad c++" |
| 22:57.04 | zero_level | #define icv_size icv_point |
| 22:57.24 | ``Erik | vmath even provides 2d arrays that could be used with all the goodies, if you really wanted |
| 22:58.24 | ``Erik | one thing I would like to see some attention to is the intermediate memory format of the pixel data |
| 22:59.05 | ``Erik | perhaps stored with the rgb values in normalized floats, so we can do high precision manipulations, etc |
| 22:59.40 | ``Erik | high dynamic range images, etc |
| 23:00.31 | zero_level | i am afraid if we have a format for that ? |
| 23:00.43 | zero_level | our raw formats like bw and pix use |
| 23:01.04 | zero_level | 8bits pixel and 24bit rgb pixel |
| 23:01.26 | ``Erik | format for which? pix and bw are inadequate... one of the big reasons icv started was to improve output from raytracing tools... |
| 23:02.04 | ``Erik | the ray tracer has the capability to generate some very precise results, but we throw away a lot of data to produce a 24 bit image |
| 23:02.19 | ``Erik | we want to do better that what is already there! :D |
| 23:02.41 | zero_level | so how do u suggest we do this? |
| 23:03.22 | zero_level | do we create two image structures one with uchar and other with float ? |
| 23:04.15 | zero_level | also conversion to float will have an impact on the api functions of brlcad utilities |
| 23:05.18 | ``Erik | the internal representation would be float, so in reading a pix file, it'd be for(i=0;i<pixels;i++){ buf.pix[i].red = ((double)*bp)/255.0; bp++; buf.pix[i].green=((double)*bp)/255.0; bp++; buf.pix[i].blue=((double)*bp)/255.0; } |
| 23:05.44 | ``Erik | yes, the utilites have to be taught to use the interface instead of directly mucking with data |
| 23:06.44 | zero_level | since it is raw format the current versions directly reads the bytes into the buffer using read etc. |
| 23:06.57 | ``Erik | I started that process a while back, you'll see some utilities using icv_save_writepixel() and icv_save_writescanline() instead of directly accessing data... for the purpose of abstracting internal representation |
| 23:08.34 | ``Erik | src/rt/view.c and src/rt/viewedge.c use the new api... they're also two of the very few rt's that can save as png out of the box, due to the data abstraction |
| 23:09.35 | ``Erik | (I feel it's important to address internal representation first, as that will directly impact how all manipulation functions will be written) |
| 23:10.10 | zero_level | also we could do store a variable for data_type |
| 23:10.18 | ``Erik | updating existing tools to use an api right now will give us some freedome in how we deal with the representation |
| 23:10.54 | zero_level | and make the data variable a void* type |
| 23:11.28 | zero_level | i was focussing on the utilities from src/util folder |
| 23:11.41 | ``Erik | once the internal representation is encapsulated, it can be changed |
| 23:11.58 | zero_level | internal representation of icv_image ? |
| 23:12.11 | ``Erik | yeah... maybe the first couple efforts could be redoing conversion utilities to use the api? |
| 23:12.26 | ``Erik | pix-png, pix-bw, bw-pix, etc? |
| 23:14.54 | zero_level | this will hamper the performance of these utilities |
| 23:15.18 | zero_level | my plan was to implement them as functions in the libicv. ? |
| 23:15.32 | zero_level | and rather other utilities also as functions of libicv |
| 23:15.55 | ``Erik | the performance is a non-issue... |
| 23:16.00 | zero_level | i have designed an api call for them as well http://brlcad.org/wiki/User:Level_zero/GSOC13/api |
| 23:17.13 | ``Erik | when I was started with bu_image, I envisioned all the image conversion utilities being basically 2 function calls... something of the nature of "icv_image img; read_image(&img, argv[1]); write_image(&image, ICV_PNG, argv[2]);" |
| 23:18.14 | zero_level | yes. for the conversion tools even i think of doing it this way |
| 23:19.00 | ``Erik | I actually managed to unsettle starseeker in describing an approach where all converters would be hard links to the same executable and the logic of the executable parsing argv[0] for what mode to operate in :) |
| 23:19.02 | zero_level | u see icv_convert function in 188 patch |
| 23:19.53 | ``Erik | I've only had a chance to look at the bwhisteq patch and the icv structures one... let me load it up (but I have to leave soon) |
| 23:22.10 | *** join/#brlcad kesha (~kesha@49.202.239.196) |
| 23:22.13 | ``Erik | hm, that patch definitely has some good stuff to it, I'll review it further tomorrow |
| 23:22.55 | zero_level | although untested |
| 23:23.01 | ``Erik | sorry about having to run so quick... I'll try to look it over before oh, 14:00 GMT? and I'll be on irc at that time |
| 23:23.01 | zero_level | i am testing it today |
| 23:23.31 | ``Erik | have a good evening :) *wanders off* |
| 23:26.48 | zero_level | ``Erik : same to u, i will try to be around at that time. |
| 23:26.52 | zero_level | thanks |
| 23:27.51 | zero_level | ``Erik Also all my information are on this page http://brlcad.org/wiki/User:Level_zero/index |