| 02:00.51 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 05:06.18 | CIA-65 | BRL-CAD: 03phoenixyjll * r50628 10/brlcad/trunk/src/librt/primitives/pipe/pipe_brep.cpp: Add some control to deal with special cases and add a few comments. |
| 05:07.14 | CIA-65 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3705 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 1 */ |
| 06:29.32 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 07:04.01 | *** join/#brlcad kane_ (~kane@g226123023.adsl.alicedsl.de) | |
| 07:45.00 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:57.53 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 07:58.11 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 08:14.19 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 09:35.19 | *** join/#brlcad nFFF (~nf@host86-150-84-175.range86-150.btcentralplus.com) | |
| 09:35.37 | nFFF | Is this about cad or speciifcally brl cad? :D |
| 09:37.30 | *** part/#brlcad nFFF (~nf@host86-150-84-175.range86-150.btcentralplus.com) | |
| 09:46.47 | *** part/#brlcad kane_ (~kane@g226123023.adsl.alicedsl.de) | |
| 09:51.01 | *** join/#brlcad kane_ (~kane@g226123023.adsl.alicedsl.de) | |
| 11:29.10 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 11:56.56 | kane_ | Is there a name convention for class names? |
| 12:33.46 | d_rossberg | looking at HACKING i would say: mixed case starting with uppercase letter, e.g. DmQtWidget (?) |
| 12:48.46 | ``Erik | there really hasn't been any primary c++ development in BRL-CAD itself, so I don't think there really IS a convention... the two big c++ parts are integration of OpenNURBS (so follow the OpenNURBS convention) and the STEP stuff (so follow the STEP convention)... 'normal' c++ is packed camel case |
| 12:57.12 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 13:18.48 | *** join/#brlcad npcdoom (~npcdoom@gugve/developer/npcdoom) | |
| 13:32.14 | *** join/#brlcad kane_ (~kane@e182048235.adsl.alicedsl.de) | |
| 13:42.38 | *** part/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 13:43.22 | *** join/#brlcad kane_ (~kane@e181163223.adsl.alicedsl.de) | |
| 13:44.56 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) | |
| 13:59.10 | ksuzee | hello |
| 14:00.29 | ksuzee | I need somebody's help |
| 14:06.32 | Stattrav | what kind ? |
| 14:07.45 | ksuzee | connected with my project) |
| 14:07.57 | Stattrav | me out then ;) |
| 14:08.34 | ksuzee | yes, I know) But thanks anywhere)) |
| 14:13.29 | *** join/#brlcad Stattrav_ (~Stattrav@61.12.114.82) | |
| 14:23.58 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 14:53.09 | brlcad | ksuzee: you have to be more specific than that (and you don't have to wait for a reply on irc) |
| 14:54.14 | ksuzee | ok) I will) |
| 14:54.17 | ksuzee | So |
| 14:55.33 | ksuzee | such question: if duplicated functions are situated in different files in one directory and I want to reduct it |
| 14:56.10 | ksuzee | what should I do with them |
| 14:56.21 | ksuzee | To put in other NEW file |
| 14:56.38 | brlcad | depends on whether the directory is a library or application and depends whether the duplicated function is public or private, and how significant the function is |
| 14:57.14 | brlcad | in general, you can often/usually break the function out into a new file |
| 14:58.12 | ksuzee | Most of all I've found are in libraries |
| 14:58.14 | brlcad | the only time you shouldn't do that is when it's a really tiny function (maybe less than 10 lines) or when there's already a collection of related functions that it belongs with |
| 14:58.58 | brlcad | so talk about a specific example |
| 15:00.13 | ksuzee | ok, I'll write in 5 minutes |
| 15:00.17 | *** part/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 15:04.25 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) | |
| 15:06.31 | ksuzee | I'm here |
| 15:06.38 | ksuzee | here's good example |
| 15:07.07 | ksuzee | libged/track.c and wdb_track.c |
| 15:08.05 | ksuzee | Both of them сontain function crdummy |
| 15:08.42 | ksuzee | but this function's static |
| 15:09.47 | ksuzee | so what's better to do with it |
| 15:10.30 | ksuzee | and similar examples are in different libraries |
| 15:27.07 | *** join/#brlcad Stattrav (u3131@gateway/web/irccloud.com/x-izuzucmpgjnckpro) | |
| 15:36.46 | CIA-65 | BRL-CAD: 03bob1961 * r50629 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Change bu_vls_printf format strings use of %llu to %zu. This fixes a recent breakage on Windows. |
| 15:51.57 | brlcad | ksuzee: okay, so in that particular example, ignore all of the duplication coming from wdb*.c files |
| 15:52.08 | brlcad | that wdb interface is going away soon |
| 15:52.41 | brlcad | you'll find a LOT of duplication in those files, but they can all be ignored |
| 15:56.56 | ksuzee | aaaa, okay |
| 15:57.42 | ksuzee | as soon as I remember in some other libraries there're wdb* too |
| 15:57.57 | ksuzee | so ignore them everywhere |
| 15:58.07 | ksuzee | ? |
| 15:58.17 | brlcad | no, just the libged ones |
| 15:58.33 | brlcad | there's an entire libwdb .. don't ignore that ;) |
| 15:59.07 | brlcad | just the src/libged/wdb* files |
| 15:59.32 | brlcad | or don't ignore them and eliminate them .. even better |
| 15:59.42 | brlcad | wdb_track would be a good one to eliminate |
| 16:00.11 | brlcad | but that is a considerably harder task, though, forewarning |
| 16:02.49 | ksuzee | ok, at first I'll ignore them and will eliminate it later, when I'm more familiar |
| 16:02.59 | ksuzee | But as an example |
| 16:03.32 | ksuzee | would it be normal to make new file for such functions |
| 16:03.35 | ksuzee | ? |
| 16:09.11 | brlcad | andrei: I'm sending out an announcement today, so please update your wiki pages as soon as you can (e-mail with more info) |
| 16:10.12 | *** part/#brlcad kane_ (~kane@e181163223.adsl.alicedsl.de) | |
| 16:10.33 | brlcad | anyone else needing to clean up their wiki page, now's the time to do it |
| 16:12.37 | CIA-65 | BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3706 10/wiki/Google_Summer_of_Code/2012: /* Non-Vacuum Gravity Simulator */ |
| 16:58.50 | *** join/#brlcad Stattrav_ (~Stattrav@61.12.114.82) | |
| 17:21.29 | *** join/#brlcad jbschw (4355ee10@gateway/web/freenode/ip.67.85.238.16) | |
| 17:27.48 | *** join/#brlcad ksuzee (~ksu@193.151.105.83) | |
| 17:34.54 | Stattrav | brlcad: Have you got a chance to look at the patch ? |
| 17:41.23 | brlcad | Stattrav: I plan to later today |
| 17:42.00 | brlcad | at least, I plan to look at patches, and will be looking at them in to the order they were submitted providing review and feedback for those outstanding |
| 17:42.05 | Stattrav | brlcad: cool thanks. I have a query which I shall be posting on the ML |
| 17:42.23 | Stattrav | that is with respect to the code organization etc |
| 17:42.32 | brlcad | okay |
| 17:42.44 | brlcad | worth discussing here? |
| 17:43.02 | Stattrav | sure |
| 17:43.45 | Stattrav | so currently I am writing these scripts etc and where should this code go ? |
| 17:43.52 | Stattrav | where should I create the directories ? |
| 17:45.00 | brlcad | we have a web module in svn |
| 17:45.09 | brlcad | you can put everything there |
| 17:45.32 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/web/trunk/ |
| 17:45.34 | Stattrav | the root folder you mean |
| 17:45.42 | brlcad | probably in htdocs/benchmark |
| 17:45.43 | Stattrav | ohh that one |
| 17:46.49 | Stattrav | sure thanks |
| 17:52.46 | brlcad | Stattrav: so that's a good example of the type of question that doesn't really need to go to the mailing list -- it's not an item warranting deep thought or discussion, just an answer |
| 17:53.20 | Stattrav | aah #TIL :) |
| 17:54.08 | brlcad | can always ask here when in doubt and on the mailing list if you don't get an answer or if it's useful for others to know |
| 17:54.46 | brlcad | e.g., your mentor isn't on irc, so if it's something he should know -- then definitely post (or repost summary if discussed here) to the mailing list |
| 17:54.46 | Stattrav | thanks. |
| 17:55.21 | Stattrav | I am creating a folder called sql to keep the schema files in that folder and plan to commit as well. |
| 17:55.56 | Stattrav | which shall be such as htdocs/benchmark/sql |
| 17:56.00 | brlcad | nods |
| 17:56.18 | brlcad | you can run "svn add" now even without commit |
| 17:56.22 | brlcad | for dirs and files |
| 17:56.44 | Stattrav | yeah did that |
| 17:58.54 | CIA-65 | BRL-CAD: 03n_reed * r50630 10/brlcad/trunk/src/other/step/src/fedex_plus/ (classes.c classes.h selects.c): apply more changes from SCL git 290850a: cleanup some multiple inheritance code - passing around attribute list to print routines instead of rebuilding it |
| 18:02.03 | *** join/#brlcad cristina (~cristina@188.24.79.30) | |
| 18:04.31 | brlcad | hi cristina |
| 18:05.20 | cristina | hello brlcad |
| 18:05.53 | brlcad | good morning! |
| 18:06.28 | cristina | good morning as well! (here is night) :) |
| 18:06.37 | brlcad | ~ugt |
| 18:06.37 | ibot | ugt is probably Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html |
| 18:06.50 | brlcad | :) |
| 18:07.19 | cristina | ah, yes |
| 18:07.29 | cristina | good morning then:D |
| 18:09.41 | Stattrav | good morning to you all then :) |
| 18:11.15 | *** join/#brlcad jbschw (~JBS103@ool-4355ee10.dyn.optonline.net) | |
| 18:11.15 | cristina | brlcad, I am at the step where I should access the geometry hierarchy for a certain database in use. Where should I put this implementation? in src/mged? |
| 18:12.45 | brlcad | cristina: well it depends, what's the goal? |
| 18:13.03 | brlcad | ideally, you should implement as much as possible as generalized library functionality |
| 18:14.20 | brlcad | so it'd become either a command in src/libged with a tiny binding in src/mged (and possibly src/libtclcad) .. or it's even lower hierarchy traversing functionality that belongs in src/librt .. or it completely general utility functionality that belongs in src/libbu .. etc |
| 18:15.09 | brlcad | generally speaking, very little new code should go into src/mged |
| 18:15.17 | brlcad | literally bare minimum |
| 18:16.51 | cristina | well, the purpose is to get this geometry hierarchy and use it further in feeding it to GOBLIN or Adaptagrams |
| 18:22.49 | cristina | but accessing the geometry hierarchy shouldn't be a command, should it? I will create a command called, let's say, 'igl' (Interactive Graph Layout) and access the data there |
| 18:24.45 | brlcad | cristina: generally speaking, it's powerful to make everything in the GUI built on top of command-line functionality |
| 18:24.56 | brlcad | so most if not everything you do in the GUI can be scripted |
| 18:25.20 | brlcad | you don't have to do things that way, but it is how much of mged and archer are composed |
| 18:26.58 | brlcad | the geometry browser in src/tclscripts/geometree is a simple example of this MVC (model, view, controller) paradigm in action |
| 18:27.46 | brlcad | there's a geometree command that kicks off the gui, the gui is necessarily build in tcl/tk but then calls several libged commands as part of the implementation |
| 18:28.42 | brlcad | that creates a series of reusable layers that all have distinct features being added |
| 18:29.33 | brlcad | for your project, I could see there being an 'igl' or whatever command that kicks off a gui, but then that gui is build on one or more commands/subcommands that do the actual processing |
| 18:29.50 | brlcad | s/build/built/ |
| 18:30.32 | cristina | I understand now. So there should be useful commands that are called behind the gui (like accessing the hierarchy for example) |
| 18:30.40 | brlcad | your mentor may have some other or better ideas as well |
| 18:31.05 | cristina | ok, I will ask him as well |
| 18:31.15 | brlcad | yeah, that would be my inclination, just because that is the most reusable -- but you'd have to be more specific than "accessing the hierarchy" |
| 18:31.35 | brlcad | accessing the hierarchy is performed by a hundred other commands and doesn't mean much at all by itself ;) |
| 18:32.16 | cristina | hm, yes, I looked through the source code and found a bunch of functions that access the tree in different ways and for different purposes |
| 18:33.09 | brlcad | for example, 'search' walks the hierarchy looking for objects matching specified criteria; the 'tree' command walks the hierarchy and prints it in text form; the 'reid' command walks a hierarchy and updates numeric identifiers on objects sequentially; the 'clone' command walks a hierarchy and creates a copy; etc.... |
| 18:33.35 | brlcad | there are literally about 100 of those ;) |
| 18:35.25 | brlcad | I could see you adding a 'graph' or 'dag' command, for example, that somehow returns the data for the directed graph that your graph layout GUI would call |
| 18:36.00 | brlcad | or modifying the tree command with a -g graph option, or some other existing command |
| 18:36.24 | brlcad | (best to not introduce new commands if we don't need to) |
| 18:37.34 | cristina | the tree command with an additional option is a good idea |
| 18:38.12 | cristina | it shouldn't print it but instead return a data structure with the directed graph, right? |
| 18:38.42 | brlcad | in tcl, those concepts are nearly identical |
| 18:38.55 | brlcad | in C, they're definitely different concepts |
| 18:39.03 | brlcad | so it depends who is calling it |
| 18:39.52 | cristina | I understand. so if I'm using the command for the GUI then it would be a similar concept |
| 18:40.08 | cristina | I was referring to C |
| 18:43.35 | brlcad | if you're accessing from C, then you already have direct access to the hierarchy information via existing librt hierarchy traversal functions |
| 18:44.01 | brlcad | at some point, you're presenting to the user -- that's the code in question, whether it's C or Tcl/Tk |
| 18:46.38 | cristina | ok, so if I need it for the GUI, I create a command and return the data corresponding to the DAG and if I need it in C, I reuse the already implemented functions. I found one here src/librt/db_tree.c |
| 18:51.50 | brlcad | you'll be using the implemented functions regardless |
| 18:52.07 | brlcad | which you use depends on what you need and what you're doing with it |
| 18:52.19 | cristina | n_reed: can I have your opinion on this one? I talked to brlcad about what commands should be implemented for the Interactive Graph Layout and one got this idea, that several commands could be created that can be called when the GUI is built. For example, a command for accessing the directed acyclic graph 'dag' and feeding it to the GUI. What is your opinion on this approach? |
| 18:52.20 | brlcad | there are about a half-dozen ways to walk the tree |
| 18:52.36 | CIA-65 | BRL-CAD: 03n_reed * r50631 10/brlcad/trunk/src/other/step/src/fedex_plus/ (5 files): apply rest of SCL git 290850a: change output suffix of aggregate select types from 's' to '_agg' |
| 18:53.51 | cristina | brlcad: you are right, I was just pointing out that I shouldn't create a new command if I need to use in C some already existent functions |
| 18:59.50 | CIA-65 | BRL-CAD: 03Sean 07http://brlcad.org * r3707 10/wiki/Google_Summer_of_Code/2012: |
| 19:00.42 | CIA-65 | BRL-CAD: 03Sean 07http://brlcad.org * r3708 10/wiki/Google_Summer_of_Code: past tense |
| 19:01.40 | CIA-65 | BRL-CAD: 03Sean 07http://brlcad.org * r3709 10/wiki/Google_Summer_of_Code/2012: |
| 19:03.45 | cristina | brlcad: here http://brlcad.org/d/node/97 it says that GSoC is in its sixth year but in fact it is in its eight |
| 19:05.56 | cristina | thank you for telling me about the commands |
| 19:07.17 | brlcad | cristina: that's for the catch on 97 |
| 19:07.21 | brlcad | er, thanks |
| 19:07.54 | brlcad | I think it was originally worded as OUR sixth year participating (two passively) |
| 19:08.11 | cristina | brlcad: you're welcome |
| 19:08.34 | cristina | I thought about that and questioned myself if I should tell you or not |
| 19:12.23 | CIA-65 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r3710 10/wiki/User:Ksuzee: |
| 19:20.27 | *** join/#brlcad merzo (~merzo@248-173-133-95.pool.ukrtel.net) | |
| 19:20.53 | brlcad | cristina: why question yourself on that? |
| 19:28.02 | cristina | brlcad: because it might have referred to BRL-CAD's participation in GSoC |
| 19:28.38 | cristina | but it participated 4 years and not 6 |
| 19:29.54 | cristina | nevermind, this was just a hypothesis inside my head |
| 19:53.38 | CIA-65 | BRL-CAD: 03n_reed * r50632 10/brlcad/trunk/src/other/step/src/cleditor/SdaiHeaderSchemaClasses.h: apply header guard symbol change from SCL git d1cd32b |
| 20:07.23 | brlcad | actively participated 4 times, passively 6 times |
| 20:09.17 | brlcad | I was involved in gsoc prior to brl-cad getting accepted, which led to our first official involvement in 2008 |
| 20:15.12 | ``Erik | with bzflag? |
| 20:28.39 | CIA-65 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3711 10/wiki/User:Stattrav/GSoC2012_log: Updation of logs for day 22 |
| 21:27.41 | crdueck | brlcad: on sf you commented on my ell surface area patch, saying it had been accepted in r50615, but r50615 added the volume function. which one is correct? |
| 21:28.25 | brlcad | crdueck: which sounds correct? :) |
| 21:29.34 | crdueck | well then i assume the volume function. there was just a little confusion |
| 21:33.05 | brlcad | you don't need to assume, there's only one possibility |
| 21:54.57 | CIA-65 | BRL-CAD: 03tbrowder2 * r50633 10/brlcad/trunk/doc/README.Linux: add more info on required packages for Debian-based systems |
| 22:03.23 | CIA-65 | BRL-CAD: 03brlcad * r50634 10/brlcad/trunk/TODO: made edits to skt_ed.tcl without testing, make sure it still works -- particularly for the user-reported failure case: circles |
| 22:13.16 | crdueck | which header do primitive callback functions belong in? |
| 22:13.29 | *** join/#brlcad jbschw_ (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 22:14.04 | crdueck | *definitions for primitive callback functions |
| 22:19.42 | brlcad | crdueck: they don't |
| 22:19.59 | brlcad | they're not public API |
| 22:20.21 | brlcad | they're declared in src/librt/primitives/table.c manually for the callback table, but that's about it |
| 22:20.28 | brlcad | everything goes through the table api |
| 22:21.02 | brlcad | or the newer newly being developed object API also in src/librt/primitives |
| 22:21.35 | crdueck | okay, i want to modify libged/analyze to use the callback functions. how should i go about that? |
| 22:31.21 | brlcad | ah, very good |
| 22:40.13 | brlcad | crdueck: well that will involve adding two callbacks to the rt_functab table |
| 22:41.19 | brlcad | its definition is in include/raytrace.h, add the callbacks then you'll have to add NULL for all of them in table.c (except for the few you've now implemented) |
| 22:42.20 | brlcad | crdueck: save that work for after you have commit access -- you probably are eligible already, but your patches need a quick reviewing |
| 22:59.49 | crdueck | brlcad: okay, i'll take a look at those files. thanks |
| 23:18.42 | CIA-65 | BRL-CAD: 03Cprecup 07http://brlcad.org * r3712 10/wiki/User:Cprecup/GSoC2012_progress: 21/05/2012, 22/05/2012 progress logs |
| 23:29.09 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |