| 02:02.36 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 03:02.20 | *** join/#brlcad maths22 (~gcimaths@66-118-151-70.static.sagonet.net) |
| 05:10.11 | Notify | 03BRL-CAD:brlcad * 55017 brlcad/trunk/src/libbu/parallel.c: only need to set affinity once, but record our cpu number before doing anything |
| 05:12.08 | Notify | 03BRL-CAD:brlcad * 55018 (brlcad/trunk/src/libbu/affinity.c brlcad/trunk/src/libbu/parallel.h): pass our cpu number to parallel_set_affinity() since there's no reason to incur a lookup cost here (we know the number) and it keeps open the possibility of reassignment later. |
| 05:14.51 | Notify | 03BRL-CAD:brlcad * 55019 brlcad/trunk/src/adrt/librender/camera.c: plan is to turn thread affinity on for all bu_parallel()-invoked threads, so no need to request it explicitly |
| 05:27.39 | Notify | 03BRL-CAD:brlcad * 55020 brlcad/trunk/src/libbu/thread.cpp: add initial support for getting/setting the cpu number via thread local storage (TLS) for pthreads |
| 05:36.33 | Notify | 03BRL-CAD:brlcad * 55021 brlcad/trunk/src/libbu/thread.cpp: if we can rely on __declspec(thread), then the ThreadLocal template won't need to be conditionalized to anything else anytime soon |
| 05:54.27 | Notify | 03BRL-CAD:brlcad * 55022 brlcad/trunk/src/libbu/thread.cpp: use cmake-set type names |
| 06:04.34 | Notify | 03BRL-CAD:brlcad * 55023 brlcad/trunk/CMakeLists.txt: initial attempt at testing for TLS type specifiers |
| 06:09.12 | *** join/#brlcad merzo (~merzo@37-152-133-95.pool.ukrtel.net) |
| 06:24.37 | Notify | 03BRL-CAD:brlcad * 55024 brlcad/trunk/CMakeLists.txt: BRLCAD_TYPE_SIZE() and the built-in CMAKE_CHECK_TYPE() macros are no good for this purpose since they try to sizeof(). instead, just try compiling a small custom snippet. |
| 06:25.04 | Notify | 03BRL-CAD:brlcad * 55025 brlcad/trunk/src/libbu/thread.cpp: use the better new names for detected TLS support |
| 06:43.06 | Notify | 03BRL-CAD:brlcad * 55026 brlcad/trunk/src/libbu/thread.cpp: pthread shouldn't take priority over the intrinsic methods, let it be a fallback |
| 10:48.51 | *** join/#brlcad Skriptkid (~Skriptkid@117.208.167.54) |
| 11:01.46 | *** join/#brlcad Skriptkid (~Skriptkid@117.208.167.54) |
| 11:03.31 | *** part/#brlcad Skriptkid (~Skriptkid@117.208.167.54) |
| 11:41.53 | Notify | 03BRL-CAD:bob1961 * 55027 brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Modify ArcherCore::cp to draw and select the new object. |
| 12:46.43 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 13:42.42 | *** join/#brlcad caen23 (~cezar@109.97.111.14) |
| 14:02.36 | Notify | 03BRL-CAD:carlmoore * 55028 (brlcad/trunk/src/anim/chan_add.c brlcad/trunk/src/anim/chan_mult.c): stdio.h removed because of bio.h |
| 15:00.57 | brlcad | starseeker: nice work pushing the merge |
| 15:20.44 | Notify | 03BRL-CAD:brlcad * 55029 brlcad/trunk/src/libbu/thread.cpp: need to be careful to not dereference the specific value for single-threaded contexts. initialize to cpu 0 so we can always return asane. valueue in bu_parallel_id(). |
| 15:34.13 | Notify | 03BRL-CAD:starseeker * 55030 (brlcad/trunk/NEWS brlcad/trunk/src/other/CMakeLists.txt and 1453 others): Revert Tcl/Tk upgrade - causing problems on 32 bit Windows. |
| 15:53.15 | ``Erik | brlcad: is bu_parallel() going to have a way to disable the affinity process binding stuff? |
| 16:06.26 | *** join/#brlcad caen23 (~cezar@92.81.187.0) |
| 16:16.11 | *** join/#brlcad ncsaba (~ncsaba@p54982FFC.dip.t-dialin.net) |
| 16:16.43 | ncsaba | Hi all |
| 16:17.25 | ncsaba | I'm back with my development environment questions :-) |
| 16:18.18 | ncsaba | for Java I was using Netbeans, which BTW also works for C/C++ |
| 16:19.25 | ncsaba | but it has the bad habit of reparsing 100+ files on any change on pipe.c, and generally being a big resource hog for big projects... |
| 16:23.00 | ncsaba | in turn it has very good code navigation features, for which I couldn't find yet a good match in the lighter editors I tried |
| 16:24.01 | ncsaba | so I was wondering, what kind of editor/code navigation/debugging setup are you using ? |
| 16:25.40 | ncsaba | of course vi/grep/find/cscope/ddd work just fine, but an integrated one like netbeans/eclipse (or intellij for just java) is a big help |
| 16:26.13 | ncsaba | is there anything in the C world which matches netbeans/eclipse ? |
| 16:46.13 | caen23 | why don't you google around for c ides and try out a few? i've used codeblocks in the past and it seemed pretty basic, but i don't know if it suits your needs |
| 16:46.23 | ``Erik | vim and emacs seem to be the biggies for BRL-CAD devs |
| 16:46.34 | *** join/#brlcad luca79 (~luca@net-188-216-230-48.cust.dsl.vodafone.it) |
| 16:51.26 | ncsaba | well that's what I'm doing (google and try), but I haven't find anything really satisfactory yet, and I'm inpatient as you know |
| 16:52.01 | ncsaba | the problem is that I got used to what a real nice integrated IDE has to offer |
| 16:52.17 | ncsaba | it is just breaking down when the project gets big... |
| 16:52.21 | ``Erik | I started writing an ide back in the lateish 90's because I couldn't find a good linux IDE that compared to borland or msvc... then I realized that *nix IS the ide... |
| 16:53.03 | ncsaba | Erik: you're right on that, but have you ever tried IntelliJ for java ? |
| 16:53.06 | ``Erik | ctags/etags can help if you're exploring a project, though I kinda like cscope |
| 16:53.11 | ``Erik | yes, and netbeans, and eclipse |
| 16:53.33 | caen23 | there's a nice series of articles on unix as ide here http://blog.sanctum.geek.nz/series/unix-as-ide/ |
| 16:54.16 | ncsaba | I prefer netbeans over eclipse - but it it gets at it's limits with brl-cad on the 2G of RAM I have on my VM |
| 16:54.59 | ncsaba | caen23: thanks for the link, I'll have a look |
| 16:55.33 | ``Erik | I only use them for java stuff, eclipse for android and netbeans for dealing with an ugly thing that happens to use the netbeans framework (wired in with multiple maven poms and other horrors, just to provide a thin gui on a C library via bridj) |
| 16:57.07 | ``Erik | when I'm doing BRL-CAD work with msvc, I set up the source on an smb exported share on linux, use vim to edit, then go to the windows box and hit 'compile', cuz I'm just that lame O.o |
| 16:58.36 | caen23 | ncsaba: taking the time to learn how to use vim or emacs is really worth it, so maybe this is a good opportunity to start looking deeper into them? :-) |
| 16:59.51 | ncsaba | :) |
| 17:00.26 | ncsaba | well I'm just giving one more try to "codelite" |
| 17:01.07 | ncsaba | it seems to have OK navigation, syntax highlight and fast enough with the resources I have |
| 17:01.49 | ncsaba | emacs I tried some time ago - too many things to remember when you want to use it well :-) |
| 17:02.26 | ncsaba | vim I'm using at it's basic capabilities - anything more makes too emacs-like |
| 17:02.56 | ``Erik | both emacs and vim have a fairly steep learning curve, but once you become familiar with the basics, they're insanely powerful tools |
| 17:03.25 | ncsaba | Erik: I know, and that's exactly the problem for an inpatient type like me |
| 17:03.30 | ncsaba | I want it to work _now_ |
| 17:03.43 | Notify | 03BRL-CAD Wiki:Modyannuamy * 0 /wiki/User:Modyannuamy: |
| 17:04.05 | caen23 | well it works _now_. only not for you :P |
| 17:04.07 | ``Erik | iirc, someone tried to make netbeans input mappings to emulate vim and emacs |
| 17:04.15 | ncsaba | yes, right :-) |
| 17:05.16 | ncsaba | well a good IDE has the advantage that the basic things work visually - then later you can learn the shortcuts |
| 17:06.31 | ``Erik | http://www.tuxfiles.org/linuxhelp/vimcheat.html |
| 17:06.34 | ``Erik | http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html |
| 17:06.39 | ncsaba | but if you have to learn some shortcuts to get editing work - that works for me only when all visual editors die out ;-) |
| 17:07.07 | ``Erik | http://refcards.com/docs/gildeas/gnu-emacs/emacs-refcard-a4.pdf |
| 17:07.36 | ``Erik | there's your visual |
| 17:07.40 | ncsaba | well no, that won't work |
| 17:08.08 | ncsaba | it's the same thing why I won't ever learn 10-finger typing |
| 17:08.45 | ncsaba | but this got too off of what I wanted :-) |
| 17:09.24 | caen23 | ncsaba: first time i got a hang of vim while going through vimtutor (type that at the prompt). there's also a game i found out about recently, but i don't know how effective it is in teaching vim. it's a fun idea nonetheless http://vim-adventures.com |
| 17:09.29 | ncsaba | I took notice that you use vim, emacs, and MS stuff for brlcad :-) |
| 17:09.41 | Notify | 03BRL-CAD Wiki:Gsauerborn * 0 /wiki/User:Gsauerborn: |
| 17:10.24 | ``Erik | ncsaba: is this what you're looking for? http://myeslfriends.com/wordpress/wp-content/uploads/2010/11/computer-easy-button.jpg |
| 17:10.27 | brlcad | ncsaba: you could always turn that feature of netbeans off |
| 17:11.32 | ncsaba | Erik: :-)) not exactly, but close :-) |
| 17:11.51 | brlcad | I use eclipse from time to time, but usually spending most of my productively in emacs |
| 17:12.02 | brlcad | it should work just fine if your machine isn't too slow |
| 17:13.39 | brlcad | vim and emacs are going to be frustrating if you're impatient, both have respectable learning curves |
| 17:13.44 | ncsaba | brlcad: codelite seems to work OK so far, so I'll settle for it for now - if it turns to be too slow again, I promise I will give a go to emacs :-) |
| 17:14.00 | brlcad | but general rule of thumb holds pretty true, the steeper the curve, the more productive in the *long* run |
| 17:15.54 | ncsaba | now about compiling: a "make" after a single character change in pipe.c takes a few minutes for me, is that normal ? |
| 17:16.29 | ``Erik | pipe.c is part of librt, which is used by a lot of other components, so lots of relinking |
| 17:16.57 | ``Erik | you could just do 'make librt' if the interface isn't changing |
| 17:17.24 | ncsaba | ok |
| 17:18.26 | ncsaba | I tried "make mged", that's definitely faster than the whole thing, but then "make install" will still compile everything :-) |
| 17:19.59 | ncsaba | now if I only "make librt" and have the "build/bin" on my PATH, will mged pick up the right library if I also have it installed system-wide ? |
| 17:20.25 | ``Erik | d'no, hit it with ldd to see which one it finds |
| 17:20.41 | ``Erik | (or otool -L on mac) |
| 17:20.41 | ncsaba | ok |
| 17:20.55 | ncsaba | ubuntu here :-) |
| 17:23.20 | ncsaba | "make librt" vs "make" is 10s vs 4min on my box... |
| 17:24.52 | ncsaba | and the "build/bin" version takes the "build/lib/..." libraries, as confirmed by ldd |
| 17:25.37 | ncsaba | so I have now my fast change/compile/test path :-) |
| 17:26.40 | ncsaba | apropos testing, is there some logging built in to brl-cad ? I haven't look for it closer, but I also don't see anything obvious |
| 17:28.07 | ncsaba | the problem is that I managed to build an infinite loop into rt_pipe_bbox and logging would be the easiest way to debug that |
| 17:28.08 | brlcad | ncsaba: if you know what you've modified, you can just run "make [target]" |
| 17:28.15 | ncsaba | ok |
| 17:28.50 | brlcad | if you want want to relink everything after changing a source file, you can also run "make [target]/fast" |
| 17:28.55 | brlcad | e.g., make librt/fast |
| 17:29.40 | brlcad | that will just recompile pipe.c and relink librt, but not relink anything that uses librt (if it happened to have static linkage anywhere) |
| 17:30.22 | brlcad | also, you don't need to run "make install" -- your build directory is effectively an install path and you can test from there |
| 17:30.27 | brlcad | e.g., make rt && bin/rt |
| 17:30.28 | ncsaba | "make librt/fast": 4 sec |
| 17:30.58 | brlcad | if you have multiple cores, make will almost always run faster with make -j# too |
| 17:31.15 | ncsaba | not sure about the cores, I have a VM |
| 17:31.36 | brlcad | even if you do, probably doesn't matter :) |
| 17:31.56 | brlcad | vm IO is a killer |
| 17:32.11 | ncsaba | yes, but that's what I'm stuck with for the moment |
| 17:32.17 | brlcad | nods |
| 17:32.34 | ``Erik | for logging, bu_log() (but it's pretty basic, no levels or directors or anything) |
| 17:32.47 | brlcad | cat /proc/cpuinfo |
| 17:33.24 | ncsaba | Erik: thanks for the logging hint ! |
| 17:33.45 | brlcad | ``Erik: it has levels... |
| 17:34.31 | brlcad | not syslog-style levels, but does do stateful indentation levels (automatic) |
| 17:34.46 | ncsaba | brlcad: I have only 1 CPU emulated, the host has 4 - not sure what that means in terms of optimal threading |
| 17:34.48 | ``Erik | O.o ah, I meant the syslog/log4j style levels, yeh |
| 17:35.09 | brlcad | ncsaba: it means it doesn't matter, -j isn't useful to you |
| 17:35.48 | brlcad | IF it emulated multiple CPUS and IF the VM bound those to separate cores, you'd potentially see a (tiny) gain |
| 17:35.55 | ncsaba | well I only need a printf level for debugging :-) |
| 17:36.07 | ncsaba | but just a simple printf was not working for mew |
| 17:36.18 | ncsaba | not sure where that gets intercepted ? |
| 17:36.19 | brlcad | bu_log() is basically a wrapper around fprintf(stderr, ...) |
| 17:36.37 | ``Erik | I'd imagine the tower of file io abstractions going on would dominate the compile time |
| 17:36.43 | brlcad | we intercept I/O all over the place for a variety of reasons |
| 17:37.22 | brlcad | mged intercepts I/O for example so it can print to the text console it displays (even when running a separate command not internal to mged) |
| 17:37.24 | ncsaba | ok, so where is actually bu_log printing at the end ? |
| 17:38.03 | ``Erik | could try putting an fflush() after your printf? (might be that it printed right, but was sitting in a buffer that wasn't getting filled up) |
| 17:38.45 | ncsaba | Erik: that might be the case... |
| 17:38.46 | brlcad | yeah, my bet would have been on not flushing your buffer if you used printf |
| 17:39.27 | brlcad | bu_log() will work in that case (auto-flushes) |
| 17:40.51 | ncsaba | but: the code is sitting in an infinite loop, so any buffers would fill in if I print in the inner loop... |
| 17:41.06 | ncsaba | ok, I will try bu_log |
| 17:41.26 | ``Erik | depends on how fast the loop is, how big the buffer is, and how impatient you are |
| 17:41.40 | ncsaba | :-) |
| 17:43.28 | starseeker | ncsaba: did anyone suggest trying kdevelop or qt creator? |
| 17:45.20 | ncsaba | starseeker: not yet |
| 17:45.34 | ncsaba | but for the moment I 'm happy with codelite |
| 17:45.44 | ncsaba | just discovered it |
| 17:45.45 | starseeker | ncsaba: you may also find the ninja build tool of interest, as an alternative to make |
| 17:47.35 | ncsaba | starseeker: I will have a look at ninja |
| 17:47.45 | ncsaba | looks interesting |
| 17:53.06 | ncsaba | ok, bu_log works - now I have the next problem :-) |
| 17:54.11 | ncsaba | not sure how to explain: the logs come so fast I can't see them, and if I interrupt the process, the mged terminal goes away |
| 17:54.45 | ncsaba | id there a way to actually save the logs somewhere, or interrupt mged so that the current command is terminated but the terminal stays ? |
| 18:00.34 | ncsaba | ok, I found bu_flog, will try that |
| 18:25.58 | *** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 18:36.13 | brlcad | ncsaba: how are you interrupting the process? |
| 18:36.20 | brlcad | and which process? |
| 19:20.34 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 19:20.34 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Thanks to all of our GCI participants for their fantastic work! Join brlcad-news to see when your changes get rolled out... |
| 19:59.54 | brlcad | ncsaba: curious that you'd actually need a circular list for something... |
| 20:00.10 | ncsaba | I don't need it circular |
| 20:00.24 | brlcad | the list head must be properly initialized for a circular list to work |
| 20:00.25 | ncsaba | is there some simply linked ? |
| 20:00.36 | ncsaba | it is properly initialized |
| 20:00.46 | brlcad | if it's infinite-looping, it's not ;) |
| 20:01.09 | ncsaba | ok, what is properly initialized ? |
| 20:01.11 | ncsaba | I use: |
| 20:01.26 | ncsaba | BU_LIST_INIT(head); |
| 20:01.32 | ncsaba | and then: |
| 20:01.43 | ncsaba | BU_LIST_APPEND(crt_l, &(new_elem->l)); |
| 20:01.47 | ``Erik | hm, hearing rumor that disney killed lucasarts this morning O.o |
| 20:03.22 | ncsaba | brlcad: is what I do not good enough for initing the list ? |
| 20:04.11 | brlcad | ncsaba: I'd have to see the whole block in question |
| 20:04.15 | brlcad | but if you don't need circ, it's moot |
| 20:04.32 | brlcad | try following the example in include/bu.h:788 |
| 20:04.43 | ncsaba | OK, I'll have a look |
| 20:05.08 | brlcad | it shows how to set up a list and iterate over it with a while loop |
| 20:05.33 | brlcad | set up that way, BU_LIST_FOR() will work as well for a for loop iteration |
| 20:05.44 | ``Erik | huh, motif went lgpl in 2012 |
| 20:05.57 | brlcad | and if you're in a .cpp file, you can use an STL container |
| 20:06.15 | ``Erik | we can finally go for that 80's look in a pure open source solution! w00t! |
| 20:06.23 | brlcad | heh, great |
| 20:07.32 | ``Erik | http://sourceforge.net/projects/motif/ |
| 20:09.13 | ncsaba | brlcad: but I don't want to dequeue the list - I want to be able to re-use it |
| 20:09.46 | ``Erik | BU_LIST_FOR() doesn't dequeue, it just iterates |
| 20:09.52 | ncsaba | as a first iteration dequeue would also work actually |
| 20:10.37 | ncsaba | also the head of my list has no data - I wonder if the while/for is skipping the head ? |
| 20:11.46 | ``Erik | heh... git commit -m "I don't know why this changed and it scares me" MainView.xib |
| 20:22.18 | ncsaba | brlcad: replacing BU_LIST_FOR_CIRC with BU_LIST_FOR fixes my infinite loop... |
| 20:22.46 | ncsaba | so probably I simply didn't understand what the 2 mean |
| 20:22.54 | ncsaba | the list is built OK |
| 20:30.55 | ncsaba | brlcad: I have now code that works - it is the refactoring of the pipe element calculation so it can be easily reused |
| 20:37.55 | ncsaba | I will submit the patch tomorrow I guess |
| 20:38.06 | ncsaba | thanks for your help today ! |
| 20:38.13 | ncsaba | bye |
| 21:03.11 | *** join/#brlcad crdueck (~cdk@24.212.219.10) |
| 21:10.37 | *** join/#brlcad merzo (~merzo@205-115-132-95.pool.ukrtel.net) |
| 22:26.48 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
