| 00:31.43 | CIA-23 | BRL-CAD: 03crdueck * r51673 10/brlcad/trunk/src/libged/analyze.c: removed lots of duplications from analyze.c by making an analyze_general() function for primitives that can be analyzed using callbacks from the rt_functab |
| 00:56.22 | brlcad | starseeker: shouldn't that be NEAR_EQUAL()? |
| 00:56.52 | brlcad | and some of them are even more simple >tol |
| 01:07.05 | CIA-23 | BRL-CAD: 03brlcad * r51674 10/brlcad/trunk/src/libbn/tri_tri.c: should be some equivalent simplifications |
| 01:09.33 | CIA-23 | BRL-CAD: 03brlcad * r51675 10/brlcad/trunk/src/libbn/tri_tri.c: ws |
| 01:11.09 | CIA-23 | BRL-CAD: 03brlcad * r51676 10/brlcad/trunk/src/libbn/tri_tri.c: missing header and footer (should be a distcheck or even commit failure) |
| 01:17.31 | CIA-23 | BRL-CAD: 03brlcad * r51677 10/brlcad/trunk/src/libbn/tri_tri.c: style, indent update |
| 01:25.02 | CIA-23 | BRL-CAD: 03brlcad * r51678 10/brlcad/trunk/src/ (12 files in 3 dirs): ws |
| 02:21.58 | crdueck | brlcad: how does mged draw wireframes for primitives? or where is it implemented? does it use rt_db_internal objects or something else? for example, given a rt_rhc_internal object, how would it determine the unique shape of the hyperbola? |
| 02:23.14 | brlcad | crdueck: rt_*_plot() (e.g., rt_rhc_plot() in src/librt/primitives/rhc/rhc.c) |
| 02:28.42 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 02:29.34 | starseeker | brlcad: I didn't see any point in sticking LGPL on that particular file - it started as public domain, and most of my changes were fairly minor |
| 02:50.06 | brlcad | then it should be a pd header |
| 02:50.22 | brlcad | still should have our header/footer regardless |
| 02:52.07 | brlcad | otherwise, the default could be assumed to be copyright (as that would otherwise be the default) |
| 02:52.46 | brlcad | copyright without copyleft permission is restrictive |
| 02:55.24 | CIA-23 | BRL-CAD: 03brlcad * r51679 10/brlcad/trunk/src/libbn/tri_tri.c: pd header, not lgpl |
| 02:59.47 | CIA-23 | BRL-CAD: 03brlcad * r51680 10/brlcad/trunk/sh/header.sh: need a trailing newline so wrapping quotes are indented properly |
| 03:00.23 | *** join/#brlcad elf11 (~elf11@p5.eregie.pub.ro) |
| 03:01.02 | brlcad | hi elf11 |
| 03:02.00 | brlcad | you could definitely give one of the simulation projects "a shot" ;) |
| 03:04.53 | brlcad | andrei: note that fork() is not portable to windows |
| 03:05.08 | brlcad | and you shouldn't really ever call system() |
| 03:06.15 | brlcad | elf11: I strongly suggest getting your project submission in sooner rather than later, so you don't miss the deadline - regardless of manual testing or digging around our source code |
| 03:06.40 | brlcad | socis runs on a very tight schedule with very little time to ramp up familiarity, so do be sure to just ask lots and lots of questions |
| 03:15.24 | elf11 | Hello :), I am not sure if the deadline is today or the 27th is still an accepted day for submitting? It says 27th but I want to be sure |
| 03:15.41 | elf11 | I did some more digging around through the sources |
| 03:37.48 | *** join/#brlcad xth1 (~thiago@187-40-88-226.user.veloxzone.com.br) |
| 04:00.55 | *** join/#brlcad thiago (~thiago@187-40-85-115.user.veloxzone.com.br) |
| 04:05.04 | brlcad | elf11: yes, tomorrow is the deadline, but I wouldn't wait until the last minute |
| 04:05.41 | brlcad | you can keep editing your proposal after the deadline, so you should just submit whatever you can quickly come up with first and then expand it with details |
| 04:05.51 | brlcad | er sorry, that's wrong |
| 04:06.12 | brlcad | you can keep editing your proposal after SUBMITTING IT .. but only up UNTIL the deadline |
| 04:10.25 | elf11 | I know, I am not sure though how far is the fluid dynamics implemented, like objects falling into water do they take in consideration when simulating it, the object density, the material type? |
| 04:38.50 | brlcad | elf11: are you asking if the work from last year got that far? absolutely not... |
| 04:39.26 | brlcad | the student started on very basic infrastructure -- like trying to just detect when a collision occurs and a force needs to be applied |
| 04:39.41 | brlcad | that wasn't even completed for arbitrary objects and arbitrary collisions |
| 04:40.59 | brlcad | a natural continuation point for the project would be to get arbitrary collision detection working along with maybe a standard interface for specifying world parameters (like ground planes, gravity) |
| 04:41.29 | elf11 | I saw he got to use the bullet primitives btBoxShape and SphereShape and that he did some box2box collisions also some sphere2sphere and sphere2box |
| 04:43.57 | elf11 | so I think also integrating the bullet btCylinderShape and yes, arbitrary collision detection |
| 04:44.45 | elf11 | concave-conves collision didn't get to be implemented, right? |
| 04:45.42 | elf11 | And what did you have in mind for the standard interface? |
| 04:46.05 | elf11 | caoncave-caoncave* sorry for my spelling :) |
| 04:51.21 | brlcad | that sounds like the general gist he mentions on the wiki page |
| 04:51.30 | brlcad | even sphere-sphere collisions weren't yet complete |
| 04:52.14 | brlcad | the bulk of the work was simply integrating with bullet (at all) and getting the simulation to call it |
| 04:53.17 | brlcad | there's no need (or time) to get into the standard interface right now -- that can be discussed at length if your proposal were selected |
| 04:53.56 | brlcad | if you want to mention it in your proposal, we'd rather hear your thoughts before you taint you with ours anyways |
| 05:04.50 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 07:00.45 | *** join/#brlcad stas (~stas@82.208.133.12) |
| 09:34.16 | *** join/#brlcad reuben (~reuben@93-97-69-251.zone5.bethere.co.uk) |
| 09:38.55 | *** join/#brlcad flash_ (~flash@adsl-ull-21-38.49-151.net24.it) |
| 10:02.59 | CIA-23 | BRL-CAD: 03Phoenix 07http://brlcad.org * r4231 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 10 */ |
| 10:16.41 | CIA-23 | BRL-CAD: 03Phoenix 07http://brlcad.org * r4232 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 10 */ |
| 10:46.10 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 10:46.41 | CIA-23 | BRL-CAD: 03phoenixyjll * r51681 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Do not copy the node as its child - just pass it to the next iteration |
| 11:44.58 | *** join/#brlcad praveen__ (75c1c5fb@gateway/web/freenode/ip.117.193.197.251) |
| 11:45.46 | *** part/#brlcad praveen__ (75c1c5fb@gateway/web/freenode/ip.117.193.197.251) |
| 12:18.15 | *** join/#brlcad xth1 (~thiago@187-79-14-142.user.veloxzone.com.br) |
| 12:26.48 | andrei | brlcad : I uploaded some of the test units ( two ) on sourceforge, before looking into them, could you please check the test_rbtree, it should require minimal or zero additional work. |
| 12:26.59 | andrei | Going to update the logs now |
| 12:29.47 | brlcad | andrei: will do |
| 12:29.55 | brlcad | hopefully zero, that is the goal :) |
| 12:30.13 | brlcad | (goal / expectation) |
| 12:30.33 | andrei | pkg is a bit difficult to understand because some function lack comments |
| 12:31.12 | andrei | oh, I also have one/some questions |
| 12:32.33 | andrei | I was thinking to write a unit test for pkg_stream (), I actually started doing that. Is it a suitable function to unit test? |
| 12:33.29 | andrei | If so, I don't know what kind of unit test to perform on it, since the function return value is less relevant ( returns the number of written characters ) |
| 12:34.49 | brlcad | andrei: any function is suitable for unit testing |
| 12:35.08 | brlcad | ideally, there would be a test for all public API functions |
| 12:35.55 | andrei | I have issues developing unit tests for " over network " functions, such as send or suckin |
| 12:36.13 | andrei | I ve been searching quite some topics on stackoverflow, but I didn't find something that would really open my mind |
| 12:38.52 | brlcad | even for network functions, basic unit testing would dictate testing the functions as-is first |
| 12:39.48 | brlcad | it's not hard to make up a whole variety of valid/dummy parameters and call a function |
| 12:40.06 | brlcad | then one-by-one, you retest the function with valid parameters |
| 12:40.47 | brlcad | you're looking to find if any of them crash or abort that could handle the data more gracefully |
| 12:40.51 | CIA-23 | BRL-CAD: 03Popescu.andrei1991 07http://brlcad.org * r4233 10/wiki/User:Popescu.andrei1991: /* Week 8 */ |
| 12:43.18 | andrei | For example there is this function : pkg_getclient() which is a blocking call |
| 12:43.45 | andrei | The only way I managed to bypass it is to use an alarm trigger and goto function |
| 12:44.56 | andrei | but since goto is " evil " that s probably not the best approach, how should I solve this issue ? |
| 12:53.16 | brlcad | there are plenty of perfectly valid use-cases for goto, it's usually evil when it's being used as a crutch for avoiding other logic contructs |
| 12:53.31 | brlcad | using alarm() doesn't sound like a portable/good thing to do, though |
| 12:54.38 | brlcad | for that specific example, you can probably pass invalid file descriptors to pkg_getclient() to get it to run but exit |
| 12:54.44 | brlcad | without blocking |
| 12:55.44 | andrei | the problem is that it's blocking the " valid" case |
| 12:55.49 | brlcad | you can also probably play with the default descriptors for stdin/stderr/stdout to test an operation |
| 12:56.12 | brlcad | sure, but you can and should also test the invalid cases -- test those first |
| 12:56.43 | andrei | yeah, that would probably do it :) |
| 12:56.57 | brlcad | unit testing isn't very useful to just test the expected/usual cases that one will usually use |
| 12:57.09 | brlcad | you WANT to test invalid cases, edge cases, and everything else in beteween |
| 12:57.23 | brlcad | since that's usually what will crash a program |
| 12:57.47 | brlcad | if your tests don't cause a crash or find bad behavior, you're probably doing something wrong |
| 12:58.57 | andrei | I will check again those that I submitted, but generally I think I covered a wide(if not complete ) range of parameters. |
| 13:09.55 | CIA-23 | BRL-CAD: 03Popescu.andrei1991 07http://brlcad.org * r4234 10/wiki/User:Popescu.andrei1991: /* Week 9 */ |
| 13:10.53 | CIA-23 | BRL-CAD: 03Popescu.andrei1991 07http://brlcad.org * r4235 10/wiki/User:Popescu.andrei1991: /* Week 9 */ |
| 13:11.19 | CIA-23 | BRL-CAD: 03Popescu.andrei1991 07http://brlcad.org * r4236 10/wiki/User:Popescu.andrei1991: /* Week 10 */ |
| 13:17.04 | *** join/#brlcad andrei (andrei@188.25.161.217) |
| 13:17.54 | *** join/#brlcad elf11 (~elf11@p5.eregie.pub.ro) |
| 13:31.05 | brlcad | welcome back elf11, how's the write-up coming along? :) |
| 14:00.18 | elf11 | Hey, it's going well I will post it today and I hope we can discuss it |
| 14:08.41 | *** join/#brlcad crdueck (~cdk@d173-238-127-19.home4.cgocable.net) |
| 15:32.47 | starseeker | huh - wonder if we could integrate the libraries from this to procedurally generate plants... http://ngplant.sourceforge.net/ (libraries are BSD) |
| 15:32.56 | CIA-23 | BRL-CAD: 03phoenixyjll * r51682 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Fix the memory leak introduced by r51681. |
| 15:42.04 | CIA-23 | BRL-CAD: 03phoenixyjll * r51683 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Change the variable name to avoid shadow warning. |
| 15:44.22 | CIA-23 | BRL-CAD: 03Phoenix 07http://brlcad.org * r4237 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 10 */ |
| 16:51.49 | *** join/#brlcad Andy_G (~chatzilla@77-254-90-217.adsl.inetia.pl) |
| 17:25.18 | CIA-23 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r4238 10/wiki/User:Ksuzee/Reports: |
| 17:25.24 | *** join/#brlcad merzo (~merzo@3-192-133-95.pool.ukrtel.net) |
| 17:51.42 | *** join/#brlcad andrei_ (andrei@188.25.161.217) |
| 18:09.26 | *** join/#brlcad elf11 (~elf11@p5.eregie.pub.ro) |
| 18:15.03 | CIA-23 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r4239 10/wiki/User:Ksuzee/Reports: |
| 18:27.12 | elf11 | I've submitted my application for SOCIS, the link is here http://sophia.estec.esa.int/socis2012/?q=node/11/submission/247 |
| 18:41.57 | CIA-23 | BRL-CAD: 03crdueck * r51684 10/brlcad/trunk/src/libged/analyze.c: begin cleaning up the primitive specific structs in analyze.c by combining bot_face and arbn_face into poly_face. replace arbn_point with a global variable |
| 19:05.04 | *** join/#brlcad Andy_G_ (~chatzilla@77-254-90-217.adsl.inetia.pl) |
| 19:05.32 | CIA-23 | BRL-CAD: 03starseeker * r51685 10/brlcad/trunk/src/other/openNURBS/ (opennurbs_nurbssurface.cpp opennurbs_xform.cpp): Apply a couple of fixes from PCL's openNURBS - r6510 |
| 19:29.54 | *** join/#brlcad stas (~stas@188.24.50.251) |
| 21:34.01 | *** join/#brlcad Andy_G (~chatzilla@77-254-90-217.adsl.inetia.pl) |
| 21:51.57 | CIA-23 | BRL-CAD: 03r_weiss * r51686 10/brlcad/trunk/src/librt/primitives/bot/tie.c: Updated file "tie.c" fixing a problem where, under certain conditions, raytracing a BOT reports the warning "rt_boolweave: Defective ID_BOT segment" and holes result in the BOT. |