| 02:07.23 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 02:07.23 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014 selections are announced! Thank you to all we got to work with. Remember that SOCIS is coming up right around the corner and you don't need a summer of code to get involved with open source. |
| 02:13.55 | starseeker | GuMiner: are you experienced with Windows development? |
| 02:16.35 | GuMiner | starseeker: Not really. I've just graduated college, so my experience is limited to my own projects, internships, and class projects. |
| 02:36.40 | starseeker | (finally) reaches the "build it" stage |
| 02:43.38 | Notify | 03BRL-CAD:starseeker * 60779 brlcad/trunk/CMakeLists.txt: add a folder for multiconfig_path |
| 02:55.16 | *** join/#brlcad maths22_ (~maths22@66-118-151-70.static.sagonet.net) |
| 02:55.49 | *** join/#brlcad GuMiner2 (~gus.gran@ppp-70-226-162-233.dsl.mdsnwi.ameritech.net) |
| 02:57.36 | *** join/#brlcad GuMiner2 (~gus.gran@ppp-70-226-162-233.dsl.mdsnwi.ameritech.net) |
| 03:03.22 | *** join/#brlcad Zhao_Anqing (~clouddrif@210.32.186.181) |
| 03:04.26 | starseeker | interesting. |
| 03:04.36 | *** join/#brlcad stirk (~charlie@c-71-56-216-45.hsd1.co.comcast.net) |
| 03:05.00 | starseeker | with threading turned on in Windows, the prep seems to take longer but the raytrace is quicker |
| 03:26.21 | hcurtis | Great. Heap corruption in Visual Studio 2010. This must be a rite of passage. * rolls eyes |
| 03:33.34 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 03:50.48 | mihaineacsu | hcurtis: you're a freshman, right? |
| 04:20.14 | hcurtis | mihaineacsu: Sophomore. But actually, I'm what we call in the U.S. a "non-traditional student." I earned a business degree right after high school, worked in advertising for 11 years, got laid off, and then decided to go back to school for computer science. |
| 04:22.26 | *** join/#brlcad piyushparkash (~piyushpar@202.164.53.117) |
| 04:27.45 | mihaineacsu | hcurtis: that's...impressive. That doesn't happen at all here. Good for you! |
| 04:57.34 | *** join/#brlcad raj12lnm (31cd6b50@gateway/web/freenode/ip.49.205.107.80) |
| 05:16.03 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 05:43.00 | *** join/#brlcad ishwerdas (~ishwerdas@117.199.109.187) |
| 05:56.26 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 06:02.57 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-bkwcyweezldymerf) |
| 06:27.46 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 06:44.01 | *** join/#brlcad luca79 (~luca@host222-17-dynamic.4-87-r.retail.telecomitalia.it) |
| 06:44.18 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 06:54.10 | *** join/#brlcad oana_ (~elf11@p5.eregie.pub.ro) |
| 06:59.47 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 07:01.23 | *** join/#brlcad oana_ (~elf11@p5.eregie.pub.ro) |
| 07:16.17 | hcurtis | My dynamic allocation program that uses malloc() will compile, but it crashes at runtime. I've been trying to figure out why and come up with a solution. |
| 07:25.23 | raj12lnm | hcurtis : send me the code |
| 07:25.26 | raj12lnm | i can see |
| 07:25.39 | raj12lnm | also u can use gdb |
| 07:25.53 | raj12lnm | http://www.cs.cmu.edu/~gilpin/tutorial/ |
| 07:26.54 | hcurtis | Hi, raj12lnm. Thank you. Let me put the code in a pastebin link. |
| 07:27.13 | raj12lnm | hcurtis : thanks |
| 07:27.28 | raj12lnm | is not needed |
| 07:27.31 | raj12lnm | :) |
| 07:28.05 | hcurtis | The pastebin link or the thanks? |
| 07:30.03 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 07:33.11 | raj12lnm | hcurtis : ofcourse 'thanks' ;) |
| 07:34.30 | hcurtis | raj12lnm: :) |
| 07:35.34 | hcurtis | raj12lnm: Here is the program. http://paste.lisp.org/+322G |
| 07:36.05 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 07:36.22 | raj12lnm | this is wrong |
| 07:36.24 | raj12lnm | <PROTECTED> |
| 07:36.36 | raj12lnm | instead u shld write sizeof(int)*numberOfIntegers |
| 07:36.54 | raj12lnm | rest seems alright |
| 07:37.01 | raj12lnm | hcurtis : have fun :) |
| 07:38.49 | hcurtis | raj12lnm: You told me not to thank you, but I must. Thank you for helping me. |
| 07:39.09 | raj12lnm | hcurtis : are u a gsoc student ? |
| 07:39.15 | hcurtis | Yes |
| 07:41.02 | hcurtis | Are you? |
| 07:41.48 | raj12lnm | yes |
| 07:44.51 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 07:49.16 | *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro) |
| 08:10.43 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 08:14.27 | hcurtis | Sean (and whoever else that might be interested), I got the malloc() program to work. Raj12lnm was kind enough to tell me what I was doing wrong. http://paste.lisp.org/+322H |
| 08:18.52 | hcurtis | mihaineacsu: [00:27] <mihaineacsu> hcurtis: that's...impressive. That doesn't happen at all here. Good for you! ... Thank you. |
| 08:31.42 | mihaineacsu | hcurtis: you should be aware that in C++ in order to allocate dynamic memory you have to use the new keyword instead of malloc. More here: http://stackoverflow.com/questions/184537/in-what-cases-do-i-use-malloc-vs-new |
| 08:34.42 | hcurtis | mihaineacsu: Thank you. |
| 08:43.51 | *** join/#brlcad luca79 (~luca@host169-111-dynamic.4-87-r.retail.telecomitalia.it) |
| 09:00.02 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 09:12.35 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 09:28.19 | *** join/#brlcad piyushparkash (~piyushpar@202.164.53.117) |
| 09:44.18 | *** join/#brlcad arno (~luca@host97-19-dynamic.4-87-r.retail.telecomitalia.it) |
| 09:53.20 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:00.29 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:01.16 | *** join/#brlcad libero (~luca@host248-29-dynamic.4-87-r.retail.telecomitalia.it) |
| 10:42.45 | *** join/#brlcad Zhao_Anqing (~clouddrif@218.81.9.244) |
| 11:01.51 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 11:48.06 | *** join/#brlcad teepee_ (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 12:19.01 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 12:20.48 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 12:28.09 | *** join/#brlcad imaleaf (~smuxi@c-71-202-235-128.hsd1.ca.comcast.net) |
| 12:44.12 | *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro) |
| 12:50.05 | *** join/#brlcad GuMiner (~gus.gran@ppp-70-226-162-233.dsl.mdsnwi.ameritech.net) |
| 13:08.35 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 13:09.11 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 13:18.57 | *** join/#brlcad ejno (~ejno@66-118-151-70.static.sagonet.net) |
| 13:19.08 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 14:01.11 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 14:01.51 | Notify | 03BRL-CAD:starseeker * 60780 (brlcad/trunk/CMakeLists.txt brlcad/trunk/src/libbu/parallel.c): Apply patch #274 from Gustave Granroth improving the Windows threading support. This is closer, but something is still off somewhere - raytracing havoc.g's havoc object with 'rt -P1' results in an immediate image, while just 'rt' caused some part of the process to take a very long time before raytracing starts. |
| 14:02.56 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7099 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 1 */ |
| 14:02.58 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7100 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 1 */ |
| 14:02.59 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7101 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 1 */ |
| 14:03.02 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7102 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 1 */ |
| 14:03.11 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7103 /wiki/User:Hcurtis0010/: |
| 14:03.16 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7104 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 1 */ |
| 14:03.25 | Notify | 03BRL-CAD Wiki:14.98.92.162 * 7105 /wiki/User:Shainasabarwal/GSoC14/logs: /* Development Logs */ |
| 14:03.38 | Notify | 03BRL-CAD:zhaoanqing * 60781 (brlcad/branches/nmgreorg/src/librt/db_diff.c brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c): change nmg_mm() to nmg_ms(), then remove nmg_mmr() and nmg_mrsv(..).After removing model and nmgregion struct, they are redundant. |
| 14:03.44 | Notify | 03BRL-CAD:tbrowder2 * 60782 brlcad/branches/d-binding/misc/d-bindings/D.pm: correct var names; playing with conversion routines (WIP) |
| 14:03.46 | Notify | 03BRL-CAD:zhaoanqing * 60783 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: Change routine nmg_mvu() and nmg_mvvu()'s last parameter from model to shell.Then the nmg_msv() should call nmg_ms() to create new shell for consistency. |
| 14:03.49 | Notify | 03BRL-CAD:tbrowder2 * 60784 brlcad/branches/d-binding/misc/d-bindings/convert-h2d.pl: make a new test option for ease of development |
| 14:03.51 | Notify | 03BRL-CAD:tbrowder2 * 60785 brlcad/branches/d-binding/misc/d-bindings/demo_Cgrammar_v2.pl: make prog a usable one |
| 14:03.53 | Notify | 03BRL-CAD:tbrowder2 * 60786 (brlcad/branches/d-binding/misc/d-bindings/recdecent-example.pl =================================================================== and 63 others): add another example of Parse-RecDescent use |
| 14:03.55 | Notify | 03BRL-CAD:zhaoanqing * 60787 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: correct the wrong comment of nmg_msv(). There is no nmgregion struct any more. |
| 14:03.58 | Notify | 03BRL-CAD:tbrowder2 * 60788 (brlcad/branches/d-binding/misc/d-bindings/ParseCChunk.pm =================================================================== and 328 others): add a new module to encapsulate a C parser |
| 14:04.00 | Notify | 03BRL-CAD:tbrowder2 * 60789 NIL: add dir for example Parse-RecDescent programs |
| 14:04.02 | Notify | 03BRL-CAD:tbrowder2 * 60790 (brlcad/branches/d-binding/misc/d-bindings/demo_Cgrammar_v2.pl =================================================================== and 329 others): move RD examples to won sub-dir |
| 14:04.08 | Notify | 03BRL-CAD:zhaoanqing * 60791 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: change nmg_mf(), nmg_mlv(), nmg_me(), nmg_meonvu() to fit new nmg structure. |
| 14:04.10 | Notify | 03BRL-CAD:zhaoanqing * 60792 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: fix type bug in nmg_meonvu() |
| 14:04.13 | Notify | 03BRL-CAD:zhaoanqing * 60793 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: remove nmg_km() and nmg_kr() to fit new nmg structure. |
| 14:04.15 | Notify | 03BRL-CAD:starseeker * 60794 brlcad/trunk/src/librt/tests/CMakeLists.txt: Grr. No seeing the problem I was seeing yesterday. Commit this simple test anyway so it's handy if the issue comes up again. |
| 14:04.19 | Notify | 03BRL-CAD:carlmoore * 60795 brlcad/trunk/src/libbu/parallel.c: remove trailing blanks/tabs |
| 14:06.50 | brlcad | Zhao_Anqing: that's looking like some great progress |
| 14:09.34 | brlcad | Zhao_Anqing: I have a challenge for you, though -- to keep your branch compiling every single commit along the way while still breaking the problem down into hundreds of small commits |
| 14:10.30 | brlcad | it requires a different way of thinking through your changes, how to make changes from the bottom up (unrolling backwards) instead from the top down (forwards) |
| 14:13.09 | brlcad | e.g., instead of removing a given struct (commit #1) and then fixing the N places (commits 2 through N+1) that used that struct, you'd fix the N places (commits 1 through N) and then finally remove the struct (commit N+1) |
| 14:16.29 | Zhao_Anqing | brlcad: OK. Thanks, Sean. I understand your suggestion. but I have a question. besides removing two struct, I also need to change shell struct. when should I do this step? at first? |
| 14:18.41 | brlcad | Zhao_Anqing: it depends how exactly it needs to change |
| 14:18.56 | brlcad | if the name is changing, that's easily one regex search and replace, and one commit |
| 14:20.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:21.03 | brlcad | also note in my prior example that you certainly could first remove the struct to help identify the N fixes .. you just wouldn't commit that until they very end, so that way everything always keeps compiling |
| 14:22.18 | brlcad | it's a principle you might have read about called "coding complete" .. a different way of working, but a very powerful skill to learn when working with teams of other developers |
| 14:22.46 | Zhao_Anqing | So I should try my best to keep the branch can be compiled every time? |
| 14:23.28 | *** join/#brlcad albertcoder (~albert@117.234.54.117) |
| 14:23.57 | GuMiner | starseeker: I can reproduce that bug -- my debug build lists the GETTREE step taking ~4x as longer with parallel ray-tracing. Investigating... |
| 14:25.28 | Zhao_Anqing | about the new shell struct, I remove two members: l and r_p, then add three new members: magic, manifolds and maxindex. |
| 14:25.34 | ``Erik | hm, "operating system is the control panel" http://arrakis.cs.washington.edu/ (looks like each process gets a mini-vm) |
| 14:26.30 | Zhao_Anqing | I think I must do such change at first even if I don't remove model and nmgregion struct. Then hundreds compiling errors appear. |
| 14:27.02 | *** join/#brlcad cwstirk (~charlie@c-71-56-216-45.hsd1.co.comcast.net) |
| 14:27.55 | starseeker | Zhao_Anqing: if you need to remove them up front, the way to do it is to remove them, fix the compilation issues that it introduces, then commit both |
| 14:28.42 | starseeker | likewise with other struct changes - if each commit still builds, they make far more effective "checkpoints" to use if you have to backtrack |
| 14:30.29 | starseeker | the last-ditch bug hunting technique for finding introduced bugs is called "bisecting" the tree: http://en.wikipedia.org/wiki/Bisection_%28software_engineering%29 |
| 14:30.48 | starseeker | this works *way* better if each commit is in a compiling state |
| 14:31.35 | brlcad | Zhao_Anqing: also, your change to src/librt/db_diff.c doesn't look right at a glance .. you possibly removed the ability to correctly compare NMG geometry |
| 14:32.09 | d_rossberg | "fixing" one place breaks the functions using this part of the code; the build would be break anyway |
| 14:33.17 | d_rossberg | the top down process shows you all the places to handle |
| 14:36.40 | Zhao_Anqing | brlcad: thank you for review, maybe I should change the 'model' to 'shell' here. |
| 14:36.48 | brlcad | for this task, it certainly makes sense to make the changes top-down as it gives you your work queue ( a couple #if 0's would be great for this ), but then one can commit bottom up with fairly reasonable certainty that everything keeps building |
| 14:37.19 | brlcad | Zhao_Anqing: yeah, probably |
| 14:37.50 | starseeker | brlcad: wonder if the Phoronix test suite would be a logical place to add BRL-CAD's benchmark as a stand-alone performance testing component: http://www.phoronix-test-suite.com/ |
| 14:39.06 | Zhao_Anqing | brlcad: OK, then I will revert these changes, then try the other method to keep the build being always compiling? |
| 14:39.58 | d_rossberg | Zhao_Anqing: no; as brlcad wrote: "for this task, it certainly makes sense to make the changes top-down" |
| 14:40.24 | d_rossberg | bottom up would be an option for the migration to the trunk |
| 14:42.28 | Zhao_Anqing | d_rossberg: eh~ Sorry for my mistaken. So, you mean I can continue my current process to fix all compiling errors. Then when I do the migration, I should keep each commit won't break the build? Am I understand right? |
| 14:42.57 | *** join/#brlcad oana_ (~elf11@p5.eregie.pub.ro) |
| 14:43.41 | d_rossberg | Zhao_Anqing: yes |
| 14:43.48 | Zhao_Anqing | By the way, is my frequency of commit OK? |
| 14:44.16 | d_rossberg | it's very frequent, so yes |
| 14:44.27 | brlcad | Zhao_Anqing: yeah, you don't need to revert |
| 14:45.31 | brlcad | you should try to stabilize the build so it can be made to compile sooner rather than later |
| 14:45.47 | brlcad | e.g., I wouldn't start mixing in other/new changes until you get through this batch at least |
| 14:47.14 | Zhao_Anqing | OK. I will finish them ASAP and keep this coaching in my heard. |
| 14:47.30 | d_rossberg | cut some loose ends (by commenting out broken functions) and fix them one ater the other |
| 14:47.57 | brlcad | you could keep a notepad of what to come back to next and work towards getting it to a compiling state |
| 14:48.34 | brlcad | there's going to be too many little issues, so do write them down somewhere (maybe put a section in the TODO file for you to know what you need to come back to) |
| 14:50.12 | brlcad | taking little measures to get the code into a state you can test priodically is probably a good idea |
| 14:50.15 | brlcad | it'll be a miracle if NMG still works when you're all said and done ... :) |
| 14:50.28 | Zhao_Anqing | So you mean when I make it be able to compiled, it's OK even if some bugs or functional errors mixed in the codes? |
| 14:50.47 | brlcad | as long as you're keeping track of them |
| 14:51.17 | Zhao_Anqing | OK. I get it. |
| 14:51.36 | brlcad | another technique you can use would be turning off code with the preprocessor |
| 14:52.30 | Zhao_Anqing | Sounds good. I will try it. ^-^ |
| 14:54.26 | Notify | 03BRL-CAD:starseeker * 60796 brlcad/trunk/src/librt/db_diff.c: Type is a valid basis to declare a difference, but not sufficient to declare unchanged. Fix db_compare3 type checking. |
| 14:56.14 | brlcad | if you really try to practice code complete hard, you end up chasing down a rabbit hole before you commit, and you then commit in a depth-first search manner instead of breadth-first |
| 14:58.27 | brlcad | so, just for example, you could have commented out the model struct, encountered all broken functions, and fixing each of them (committing them if their signature didn't change), but if their signature changed jumping to the functions that then call them next (commiting those if their signature didn't change) and so on all the way down a call hiearchy |
| 14:58.54 | brlcad | keeping track of the functions whose signature changed that you have to come back to in a stack order (and committing them after you get all their callers updated) |
| 14:59.14 | brlcad | until you've finally popped all the way back to the top of the stack, then the #ifdef and struct get removed |
| 15:00.26 | brlcad | like I said, it's a bit "upside down" and not always easily attainable without increasing the time, but they do minimize risk in a number of ways |
| 15:06.49 | Zhao_Anqing | brlcad: It's amazing, really new but benificial to me. |
| 15:08.31 | Zhao_Anqing | Let me think this idea seriously for a moment to understand it better. :) |
| 15:12.18 | Notify | 03BRL-CAD:zhaoanqing * 60797 brlcad/branches/nmgreorg/src/librt/db_diff.c: I am wrong to remove ID_NMG tag before, now I restore it and change struct model to shell. That's the right way to fit the routine to new nmg. |
| 15:13.07 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 15:25.07 | hsrai | sd |
| 15:34.00 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 15:35.17 | *** join/#brlcad albertcoder (~albert@117.225.70.153) |
| 15:36.21 | *** join/#brlcad albertcoder (~albert@117.225.70.153) |
| 15:39.43 | *** join/#brlcad albert_ (~albert@117.219.21.173) |
| 15:44.40 | Notify | 03BRL-CAD:starseeker * 60798 brlcad/trunk/src/librt/db_diff.c: more work on diff3 |
| 15:46.31 | *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro) |
| 15:57.17 | ``Erik | hm, stolen ebay account info is already for sale (change your passwords, yo) |
| 16:04.27 | teepee | right, good point |
| 16:17.51 | teepee | good, they limit the password to 20 chars |
| 16:22.55 | Notify | 03BRL-CAD:zhaoanqing * 60799 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: change geometry and attribute routines to fit new nmg structure. |
| 16:25.43 | Notify | 03BRL-CAD:zhaoanqing * 60800 brlcad/branches/nmgreorg/src/librt/primitives/nmg/nmg_mk.c: change modify routines to fit new nmg sturcture. |
| 16:25.55 | *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro) |
| 16:34.05 | *** join/#brlcad albertcoder (~albert@117.236.113.242) |
| 16:52.22 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 17:26.50 | *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro) |
| 17:34.56 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 17:41.32 | *** join/#brlcad ishwerdas (~ishwerdas@117.199.98.110) |
| 17:45.12 | n_reed | ``Erik: changed mine last night. at this point, with so many breaches in so many sites, many of which aren't reported for weeks or months, i'm thinking i should just change my passwords at every website once a week. |
| 17:55.45 | *** join/#brlcad hoiji (3b5916ae@gateway/web/cgi-irc/kiwiirc.com/ip.59.89.22.174) |
| 18:03.24 | *** join/#brlcad hoiji (75c953b3@gateway/web/cgi-irc/kiwiirc.com/ip.117.201.83.179) |
| 18:12.02 | GuMiner | One clarification questions: |
| 18:12.05 | GuMiner | > Is semaphore.c (libbu) supposed to implement semaphores instead of mutexes? The pthread code and current Windows code are currently mutex implementations. I'm wondering if this is just a naming mixup. |
| 18:16.53 | ``Erik | n_reed: I generate a unique password (pwgen -s) for every different site and stash them all in an encypted text file to mitigate a services oops, but it's still a bit irritating :) at least ebays are not stored plaintext (as far as we know), but things like full name and address were still in the mix |
| 18:18.29 | teepee | does that with an encrypted file image ;) |
| 18:18.45 | teepee | but it is quite annoying |
| 18:19.56 | ``Erik | GuMiner: the posix stuff is all mutex as well, I think the code may've started before the modern definitions were really embraced... (early versions ran on a modified vax 11/780, they actually wired in a second processor unit and modified the bsd kernel running on it to handle simultanious multiprocessing... it's old!) |
| 18:20.01 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 18:22.07 | Notify | 03BRL-CAD:starseeker * 60801 (brlcad/trunk/src/gtools/gdiff2/gdiff2.c brlcad/trunk/src/gtools/gdiff2/gdiff2.h): Clear the material_head before each db_dirbuild, so we don't get warnings about overwritten properties. We're not actually using material_head in diffing, so its contents don't matter. (Thanks Sean for the assist.) |
| 18:24.25 | GuMiner | ``Erik: Wow. I hadn't realized the terminology had changed. |
| 18:25.07 | Notify | 03BRL-CAD Wiki:Albertcoder * 7106 /wiki/User:Albertcoder/GSoC2014/logs: /* Development Logs */ |
| 18:27.16 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 18:27.28 | ``Erik | GuMiner: I think the strict definitions have not really changed, but the engineer understanding of what they mean may have? (I'm totally guessing) |
| 18:31.42 | ``Erik | hm, the words semaphore and mutex come from dijkstra in '65, threads were called "processes" in that paper and didn't take on their modern name until "the late 70's or early 80's" |
| 18:37.36 | brlcad | ``Erik: .bz dns is no longer responding to external queries .. do you know anything that changed recently? |
| 18:37.50 | brlcad | (hosts that it's authoritative for) |
| 18:39.24 | brlcad | apparently happened earlier today |
| 18:47.43 | *** join/#brlcad Zhao_Anqing (~clouddrif@218.81.9.244) |
| 18:48.38 | ``Erik | no, I don't know of anything... |
| 18:49.19 | ``Erik | looks like named was restarted at 14:41 |
| 18:50.04 | ``Erik | looks like named is only listening on localhost, not * |
| 18:51.52 | ``Erik | someone did something with named.conf may6 17:03 |
| 18:52.02 | brlcad | I've restarted it many times |
| 18:52.20 | ``Erik | <PROTECTED> |
| 18:52.27 | ``Erik | in named.conf |
| 18:52.50 | brlcad | it first seemed to be refusing localhost connections, restarting fixed that |
| 18:53.18 | brlcad | I can't get a response on port 53 tcp |
| 18:53.31 | brlcad | (except on localhost) |
| 18:53.38 | brlcad | wonder if the ISP is doing something |
| 18:53.42 | ``Erik | yeah, that'd be that listen rule |
| 18:54.18 | brlcad | hrm, so does it need to listen on the public IP too? |
| 18:54.27 | ``Erik | weird that it'd show issues today instead of a couple weeks ago |
| 18:54.47 | ``Erik | how else would a non-localhost client get to it? O.o |
| 18:54.58 | brlcad | maybe it got stuck and it's only now been restarted |
| 18:55.16 | brlcad | you know what the may6 change was? a diff? |
| 18:56.03 | ``Erik | ummm, heh, was that the system upgrade? |
| 18:56.32 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7107 /wiki/User:Ankeshanand/GSoC14/logs: /* Update today's logs */ |
| 18:56.43 | ``Erik | no, that seemed to have happened april 9th |
| 18:57.07 | brlcad | there we go |
| 18:57.33 | brlcad | yeah, I think the system upgrade might had added / uncommented that listen line |
| 18:57.51 | brlcad | just removed it and it's responding |
| 18:59.21 | ``Erik | hm, there're more differences |
| 18:59.31 | ``Erik | was timr mucking in there recently? |
| 19:00.01 | Notify | 03BRL-CAD:carlmoore * 60802 brlcad/trunk/src/util/bwrect.c: make fixes in the Usage statement in bwrect |
| 19:01.29 | brlcad | maybe only to test this, but I don't think so |
| 19:01.33 | brlcad | talking to him now |
| 19:02.05 | ``Erik | 'k, a good chunk of /etc is in git, but things have changed without getting committed... you can do a diff to see the changes |
| 19:02.53 | GuMiner | starseeker: I switched Windows APIs -- from what I could see, there was a bit too much overhead with the previous versions API. Update posted on sourceforge. |
| 19:02.54 | brlcad | aha, something removed the recursion rule |
| 19:03.00 | brlcad | thanks for the git tip |
| 19:06.22 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 19:08.33 | brlcad | got it |
| 19:08.56 | brlcad | all of tim's zones weren't getting loaded, looks like the update wiped out the changes |
| 19:18.12 | brlcad | GuMiner: semaphore.c is a misnomer in the posix sense of the terms, but isn't really a mixup -- the file implements a semaphore API (using a mutex construct on some platforms) |
| 19:18.52 | brlcad | and to make it even more confusing, the semaphore API is almost exclusively used as a mutex even if it does generalize |
| 19:22.33 | Notify | 03BRL-CAD:brlcad * 60803 brlcad/branches/RELEASE/regress/CMakeLists.txt: turn off the repository check for this release. issues reported in the latest version of the file are not current with these sources. |
| 19:26.28 | brlcad | I see you already committed the updated named.conf |
| 19:28.37 | GuMiner | brlcad: That's where I'm confused -- the pthread API isn't created with PTHREAD_MUTEX_RECURSIVE, and the Win32 API isn't using CreateSemaphore -- so any attempt to use the API on windows or unix as a semaphore instead of a mutex will fail. Plus, there's no way to initialize each semaphore with a count > 1 (so the structure of using the 'semaphores' seems a lot like that of mutexes to me). |
| 19:31.38 | GuMiner | (actually, PTHREAD_MUTEX_RECURSIVE is for recursive locking, not for a semaphore -- regardless, pthread_mutex isn't behaving like a semaphore). |
| 19:45.19 | ``Erik | @ndm_haskell: People who want to program in C++ are exactly the people who should not be allowed to. |
| 19:45.22 | ``Erik | hehehe :) |
| 19:52.44 | brlcad | GuMiner: yeah, best not to think about that one too hard because it is a mix of terminology (that predate standard use) with some subtleties |
| 19:53.01 | brlcad | by generalize, I didn't mean that it's a counting semaphore (which is probably what you're most familiar with?) |
| 19:54.17 | GuMiner | brlcad: Yup, that's what I think of when I hear of semaphores. |
| 19:55.19 | brlcad | the generalized notion of a semaphore is merely a variable that controls access by multiple processes |
| 19:55.46 | brlcad | so a mutex is one type of semaphore (a binary semaphore) |
| 19:55.54 | brlcad | but there are some other subtle differences |
| 19:56.52 | brlcad | like some say you're supposed to be able to release a semaphore from any proces ... and I don't think that's a trait our API supports across all platforms |
| 19:57.51 | brlcad | best to just mentally tell yourself it's a mutex and treat it as such ;) |
| 19:58.54 | Notify | 03BRL-CAD:carlmoore * 60804 brlcad/trunk/doc/docbook/system/man1/en/bwmod.xml: fix man page to match the Usage statement more closely; there is, however, still the matter of stuff referred to by '...' |
| 20:05.32 | Notify | 03BRL-CAD:starseeker * 60805 brlcad/trunk/include/rt/db_diff.h: Start thinking about ways to handle results other than large numbers of pointer tables... |
| 20:21.56 | Notify | 03BRL-CAD:starseeker * 60806 brlcad/trunk/include/rt/db_diff.h: Let's try something that should (in priniple) be less cumbersome - encode the diff state in a return integer using bit flags, which should also be useful as a simple way to categorize individual results - may avoid the need for lots of individual pointer tables for each results category. |
| 20:25.27 | starseeker | wonders if a "modernize BRL-CAD's parallelism terminology" is a worthwhile TODO, or whether it'd be too much trouble |
| 20:35.28 | Notify | 03BRL-CAD:starseeker * 60807 brlcad/trunk/include/rt/db_diff.h: If it works for diff3, it should work for diff as well. May be able to convert db_compare* functions to visitor pattern as well, so checkpoint before ripping the guts out of everything. |
| 20:42.01 | ``Erik | glad I wouldn't be the one interfacing with the dependant projects to make that change... (I'm guessing 80% of the effort would be political in nature) |
| 20:42.12 | brlcad | starseeker: it's technically accurate, just misleading to how it's taught |
| 20:42.16 | Notify | 03BRL-CAD:carlmoore * 60808 brlcad/trunk/doc/docbook/system/man1/en/coil.xml: fix the coil manpage to match the Usage (rearrange the order); also shorten a few messages |
| 20:43.02 | ``Erik | what's the futurama line? "you are technically correct, the best kind of correct!" |
| 20:48.45 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 21:06.20 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 21:29.57 | *** join/#brlcad mihaineacsu (~mihaineac@92.81.50.203) |
| 21:32.47 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 21:38.58 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 22:06.40 | *** join/#brlcad oops (~smuxi@c-71-202-235-128.hsd1.ca.comcast.net) |
| 22:14.34 | *** join/#brlcad oops (~smuxi@c-71-202-235-128.hsd1.ca.comcast.net) |
| 22:20.38 | *** join/#brlcad ries_nicked (~ries@190.9.171.121) |
| 22:41.27 | *** part/#brlcad imaleaf (~smuxi@c-71-202-235-128.hsd1.ca.comcast.net) |
| 22:44.46 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:14.12 | *** join/#brlcad hcurtis (b82d2fe4@gateway/web/freenode/ip.184.45.47.228) |
| 23:17.00 | hcurtis | Here is an activity update. I re-read the acceptance requirements at http://brlcad.org/wiki/Summer_of_Code/Acceptance. Afterward, I published my acceptance of those requirements on Melange. |
| 23:17.33 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 23:29.55 | hcurtis | The information at http://brlcad.org/wiki/Summer_of_Code/Acceptance says we are to regularly submit progress reports of daily activity. Are those reports in addition to the development log entries and activity updates in the IRC channel, or do the dev log entries and channel updates serve as the progress reports? |
| 23:30.36 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 23:54.29 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |