| 00:12.30 | *** join/#brlcad caen23 (~caen23@79.112.95.83) | |
| 01:47.32 | *** join/#brlcad ahqlbzztpoibkcxf (~armin@dslb-088-064-043-249.088.064.pools.vodafone-ip.de) | |
| 02:02.48 | Notify | 03BRL-CAD:brlcad * 69221 brlcad/trunk/doc/BRL-CAD.bib: document cliff's tcl/tk-to-cmake paper which heavily references BRL-CAD's conversion to cmake. |
| 03:39.55 | Notify | 03BRL-CAD Wiki:Sean * 9842 /wiki/Google_Code_In/Checklis: |
| 05:44.57 | *** join/#brlcad KimK (~Kim__@2600:8803:7a85:6d00:71f7:ac66:3bbc:1977) | |
| 06:15.59 | *** join/#brlcad amarjeet (~amarjeet@202.164.53.117) | |
| 06:53.53 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 07:06.12 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) | |
| 07:06.22 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 07:24.56 | *** join/#brlcad merzo (~merzo@91.217.179.122) | |
| 07:44.49 | *** join/#brlcad caen23 (~caen23@79.112.95.83) | |
| 08:00.03 | *** join/#brlcad merzo (~merzo@91.217.179.122) | |
| 08:17.49 | *** join/#brlcad teepee] (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 09:33.09 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) | |
| 11:08.46 | *** join/#brlcad yorik (~yorik@2804:431:f721:47e1:290:f5ff:fedc:3bb2) | |
| 13:09.26 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 13:54.40 | *** join/#brlcad Lord_of_Codes (~Lord_of_C@209.58.183.35) | |
| 14:13.17 | *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145) | |
| 14:34.31 | *** join/#brlcad Lord_of_Codes (~Lord_of_C@209.58.183.35) | |
| 14:46.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 14:56.36 | *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145) | |
| 15:12.08 | starseeker | brlcad: regarding the lz4 compression - were you planning to use the HC variation with slow compression and fast decompression? I can see an argument for that since the compression could be done in the background theoretically (in order to have the cache data to be written to disk in the first place the in memory version has to already be generated and is thus available for immediate use) |
| 15:19.24 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 15:22.17 | Notify | 03BRL-CAD:starseeker * 69222 brlcad/trunk/doc/docbook/system/mann/CMakeLists.txt: rename find.xml |
| 15:24.12 | Notify | 03BRL-CAD:starseeker * 69223 (brlcad/trunk/NEWS brlcad/trunk/doc/docbook/system/mann/dbfind.xml): Update name of db 'find' command to dbfind in man page. |
| 15:29.24 | Notify | 03BRL-CAD:starseeker * 69224 brlcad/trunk/CHANGES: List the lowest hanging fruit from the command review for deprecation. There will be quite a few more as consolidation strategies are worked out - this is just the first set. |
| 15:30.22 | starseeker | brlcad: should we bother to list the _mged prefixed but otherwise undocumented MGED commands in changes? It's possible for a few of them (like 35,25 for example) that docs I'm not familiar with reference them |
| 15:53.10 | Notify | 03BRL-CAD:starseeker * 69225 brlcad/trunk/src/librt/cache.c: C++ comment in C file |
| 16:02.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:02.30 | *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145) | |
| 16:05.36 | Notify | 03BRL-CAD:starseeker * 69226 (brlcad/trunk/include/rt/comb.h brlcad/trunk/src/librt/comb/db_comb.c brlcad/trunk/src/librt/db5_size.cpp): Redo db_comb_children to allow for the possibility of an externally allocated array. |
| 16:23.28 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:24.08 | *** join/#brlcad caen23 (~caen23@79.112.95.83) | |
| 16:25.35 | *** join/#brlcad Lord_of_Code (~Lord_of_C@122.163.244.145) | |
| 16:31.15 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 16:36.23 | brlcad | starseeker: I don't think it's necessary, but worth making sure for each one via: grep -R "cmd" doc |
| 16:36.54 | brlcad | the old html docs used to the the source of knowledge, so many might be documented there |
| 16:40.12 | brlcad | cannot find the "fixed" volII tutorials pdf anywhere *sigh* |
| 16:40.12 | *** join/#brlcad amarjeet (~amarjeet@169.149.182.93) | |
| 16:40.25 | brlcad | hi amarjeet! ready? :) |
| 16:40.45 | amarjeet | yes |
| 16:40.52 | brlcad | great :) |
| 16:41.13 | brlcad | any GCI students here already? |
| 16:43.39 | amarjeet | but have some queries like I think I am able to see only list of task where I was added how could I see all of the tasks that are published |
| 16:49.54 | brlcad | do you see a little slider that says "My Tasks" on the bottom left? |
| 16:50.12 | amarjeet | yes |
| 16:50.20 | brlcad | starseeker: any suggestions on how someone can prove they actually did all the mged tutorials? |
| 16:50.33 | brlcad | amarjeet: is it on or off? try turning it off |
| 16:51.59 | amarjeet | okay thanks |
| 17:05.06 | brlcad | amarjeet: if you want, you can subscribe to all of them by turning off My Tasks, selecting all of them (box at the top), and adding yourself |
| 17:05.11 | brlcad | or I can do it for you |
| 17:09.48 | amarjeet | okay, I selected all by no option to add myself to selected task at once |
| 17:13.54 | caen23 | you can click on the triangle thingy at the top, and put yourself in "Add mentors" i believe |
| 17:17.17 | amarjeet | thats for filter |
| 17:19.10 | brlcad | woot, we have 3 students already |
| 17:19.46 | brlcad | amarjeet: do you want me to add you to all? |
| 17:21.09 | brlcad | sorry can't be more specific .. don't have a mentor-only account set up yet |
| 17:21.23 | brlcad | but I can easily add you, assuming the server doesn't catch on fire |
| 17:22.00 | amarjeet | okay |
| 17:22.35 | amarjeet | but just little confuse If I am not able to give proper time |
| 17:22.56 | brlcad | is that a "yes"? want to be clear because it's a lot more work to remove mentors than it is to add them ;) |
| 17:23.14 | brlcad | are you assigned to any of the beginner tasks? |
| 17:23.38 | amarjeet | yes, 2 |
| 17:23.41 | brlcad | if you're worried about time, then I suggest just leaving things as they are for now |
| 17:23.51 | brlcad | yeah, that'll be plenty of work then |
| 17:24.34 | amarjeet | yes, that would be okay. I will add myself to the selected tasks only |
| 17:27.10 | amarjeet | As their are some task related to modelling in openscad. Would I assume that we could add more task apart from that related to openscad? Although openscad in not participatinng. |
| 17:27.26 | amarjeet | could* |
| 17:50.18 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 17:54.44 | brlcad | gah |
| 17:54.47 | *** join/#brlcad amarjeet (~amarjeet@169.149.182.93) | |
| 17:54.53 | brlcad | amarjeet: in general, sure -- depends on the nature of the task. ideally since there aren't dedicated mentors, any openscad tasks should have a purpose and comparative counterpart |
| 17:55.27 | amarjeet | okay |
| 17:55.34 | brlcad | the ones there are to help set up some openscad test data that is representable in brl-cad, so we can test import/export |
| 17:56.06 | brlcad | and to see syntactically whether we have any incompatibilities to sort out |
| 17:56.32 | brlcad | but sure, add more ideas if you have them along with the task write-ups and I'll review+publish them |
| 18:19.14 | *** join/#brlcad vasc (~vasc@bl13-101-67.dsl.telepac.pt) | |
| 18:21.46 | *** join/#brlcad manjaroi3 (~manjaro-i@43.224.130.153) | |
| 18:29.18 | *** join/#brlcad boquete___ (~Piotr@91.232.62.60.studiowik.net.pl) | |
| 18:34.36 | starseeker | brlcad: I can build PDFs of the tutorials once I get to a setup with FOP |
| 18:34.51 | brlcad | but the images are still all screwy, no? |
| 18:34.57 | starseeker | unfortunately |
| 18:35.19 | starseeker | has been holding off on that on the theory we'd have to redo all of them anyhow for Archer... |
| 18:35.59 | starseeker | not sure how to "prove" tutorials are complete offhand... |
| 18:36.24 | starseeker | would almost need some sort of modeling "test" to administer |
| 18:37.26 | starseeker | another option would be to produce custom versions of the tutorials that have custom "tweaked" numbers for each unique task |
| 18:37.43 | starseeker | then check the supplied .g against the specific version of the tutorial supplied with the task |
| 18:38.43 | starseeker | brlcad: did you want me to add the lz4 stuff as a src/other build, or just integrate it straight into librt? |
| 18:40.44 | brlcad | right now, that's the only place lz4 is used, so could be shoved under librt wholesale as an implementation detail for now |
| 18:41.11 | brlcad | that said, it's pretty much superior to zlib all around .. anything we have using zlib should probably get changed over |
| 18:41.14 | starseeker | nods - pretty easy - two files if you don't want the high compression option, four otherwise |
| 18:41.18 | brlcad | fortunately the api maps very closely |
| 18:41.29 | starseeker | doesn't think PNG can dispense with zlib... |
| 18:41.42 | vasc | the google codein interface is kinda slow and doesn't auto-update itself... |
| 18:41.43 | starseeker | could probably add it to the png build directly though |
| 18:41.53 | brlcad | no, you're right -- it needs it because of the spec |
| 18:42.04 | brlcad | opennurbs too probably |
| 18:42.13 | starseeker | nods - yeah, forgot about opennurbs |
| 18:42.22 | brlcad | vasc: yeah, it's getting heaviyl hammered by thousands right now |
| 18:42.54 | starseeker | brlcad: no particular difficulty either way - if it's a src/other I was going to go ahead and get it integrated and checked out on Windows |
| 18:44.53 | brlcad | don't do anything just yet |
| 18:45.03 | brlcad | I need to see if it can be wrapped under libbu |
| 18:45.44 | brlcad | s/can/needs to/ |
| 18:45.45 | starseeker | raises eyebrow - did you want to hide the use of lz4 specifically? |
| 18:46.17 | brlcad | right, maybe not convinced we need to, but hadn't thought things through |
| 18:46.53 | starseeker | hmm... interesting idea. We would need to encode what type of compression was used in each cache object though, so newer BRL-CAD versions could be backwards compatible |
| 18:46.53 | brlcad | (probably not the more I think about it now, but not clear headed atm) |
| 18:47.07 | starseeker | nod |
| 18:47.11 | brlcad | yeap, that's the point |
| 18:47.29 | starseeker | no worries - I'll wait 'til you decide |
| 18:48.16 | starseeker | goes back to fixing API mistake... |
| 18:48.21 | brlcad | the original arch was caching filedir structure managed by libbu and the data contained therein by the caller |
| 18:48.21 | ignacio | Hello ;D |
| 18:48.45 | brlcad | which would mean librt is conceivably responsible for compression |
| 18:49.00 | starseeker | hrm |
| 18:49.36 | brlcad | guess I thought things through -- so yeah, you can shove it under librt/lz4 if you like, or src/other if that's easier |
| 18:50.00 | brlcad | guess question is how much work to invest into trying to use a system version |
| 18:50.04 | brlcad | hi ignacio :) |
| 18:50.14 | starseeker | kinda a wash - don't have to tell distcheck to ignore it in src/other, but need to get the DLL foo working |
| 18:50.47 | starseeker | how common are system installs of lz4? |
| 18:51.02 | brlcad | alternatively, sad distros if someone lets it slip that lz4 is tucked in there ;) |
| 18:51.51 | starseeker | <snort> yeah, given the static we still get over that I'll go ahead and do the src/other thing |
| 18:52.10 | brlcad | it's pretty wildly popular, just about anything that was seriously using zlib now doesn't |
| 18:52.16 | starseeker | O.o |
| 18:52.42 | starseeker | cool |
| 18:53.57 | vasc | only problem with lz4 last time i saw it was that it didn't scale on multicore. |
| 19:01.04 | Stragus | It didn't scale with independent streams?... Due to shared memory bus saturation? |
| 19:02.33 | vasc | well independent streams should be fine. the thing is the LZW algorithm is highly sequential. |
| 19:04.36 | vasc | you can do the compression in blocks, but the compression becomes worse the smaller the blocks you use. |
| 19:04.53 | brlcad | someone implemented a blocking method a few years ago for parallel, but it was supposedly highly non-portable and didn't get integrated |
| 19:05.47 | brlcad | the original author was busy with other work and claimed that lz4 is typically constrained by memory bus saturation |
| 19:06.25 | vasc | its not worth the bother to consider i think. as long as its only used for file I/O it's prolly ok. i was trying to use it for a compressed in-memory database though :-) |
| 19:08.31 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 19:08.42 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 19:13.53 | brlcad | hm, manual page seems to disagree: "lz4 offers compression speeds of 400 MB/s per core, linearly scalable with multi-core CPUs." |
| 19:14.17 | brlcad | "It features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limit on multi-core systems." |
| 19:14.38 | brlcad | ah, though that's the userland app |
| 19:15.01 | brlcad | perhaps it's threading things out |
| 19:18.27 | vasc | yeah that was what i thought when i read the docs |
| 19:18.38 | vasc | but in practice |
| 19:18.51 | vasc | it works best with multiple streams |
| 19:19.26 | vasc | all compression algorithms are kinda problematic on many core systems |
| 19:19.44 | vasc | especially these which are stream oriented |
| 19:25.03 | Notify | 03BRL-CAD:starseeker * 69227 (brlcad/trunk/include/rt/directory.h brlcad/trunk/src/librt/db5_size.cpp brlcad/trunk/src/librt/db_alloc.c): Rather than introduce lots of additional info into the directory struct, see if we can get away with just a u_data pointer on which to hang our hat. This is a double edged sword - we don't save information from earlier work on the .g to speed up subsequent actions, but we also |
| 19:25.05 | Notify | don't encode state into the directory pointer that can be (potentially) invalidated by edits to other objects. See if this can be made 'fast enough.' |
| 19:25.07 | Notify | ... |
| 19:29.50 | vasc | brlcad, https://codein.withgoogle.com/dashboard/task-instances/6314184358756352/ |
| 19:30.24 | vasc | his screenshot doesn't have the rt window, i'm guessing he closed it. but he ran it. |
| 19:30.51 | vasc | its in the mged shell |
| 19:30.59 | vasc | rt output |
| 19:31.09 | vasc | do we ask for another screenshot or accept like this? |
| 19:31.30 | brlcad | I let one slide earlier just like that |
| 19:31.47 | brlcad | left him a message and asked, but console showed the rt output |
| 19:31.58 | vasc | yes, it shows output here as well |
| 19:32.01 | vasc | ok i'll accept |
| 19:32.16 | brlcad | these are beginner tasks .. as long as it doesn't smell fishy |
| 19:37.07 | vasc | i guess its normal that people do easy tasks first so they can meet the quota |
| 19:37.42 | brlcad | they only get to do 2 beginner tasks, so makes sense to do 2 |
| 19:37.53 | brlcad | 3 gets them a t-shirt |
| 19:39.09 | *** join/#brlcad ickby (~stefan@x5d844f63.dyn.telefonica.de) | |
| 19:56.50 | vasc | someone's having problems running mged, i think it's on a mac os x system. maybe they need X11 installed? don't have a mac so i can't understand the error message he got. |
| 19:56.57 | vasc | https://codein.withgoogle.com/dashboard/task-instances/4574436451680256/ |
| 19:57.16 | *** join/#brlcad merzo (~merzo@93-195-113-92.pool.ukrtel.net) | |
| 19:58.46 | ignacio | Can I try to bring gcibot here? |
| 19:58.53 | ries | vasc: only some log can tell⦠usually on OS/X it would show some message that it needs X11 |
| 19:59.49 | ries | I havenât run anything X11 for a long time though |
| 20:01.36 | sniok | he probably needs XQuartz https://www.xquartz.org/ |
| 20:02.27 | *** join/#brlcad ignacio (bip@unaffiliated/ignacio) | |
| 20:03.38 | ries | checks |
| 20:11.31 | ries | Installing quarts solved that issue, |
| 20:11.38 | ries | this was the message the user lickly got : http://pastebin.com/QR1as1q4 |
| 20:15.18 | vasc | i asked him which os version he's using |
| 20:21.10 | Notify | 03BRL-CAD:starseeker * 69228 brlcad/trunk/src/librt/db5_size.cpp: fix typos |
| 20:44.12 | *** join/#brlcad sniok (~sniok@pc-212-191-78-204.p.lodz.pl) | |
| 20:52.17 | Notify | 03BRL-CAD:starseeker * 69229 (brlcad/trunk/src/librt/db5_size.cpp brlcad/trunk/src/librt/tests/CMakeLists.txt): Go with a vector instead of a set for collecting, since we're using flags in the structs to tell if we've already counted a given node. |
| 21:12.13 | brlcad | ignacio: sure |
| 21:13.30 | brlcad | vasc: yeah, they need X11 -- it's no longer included standard and we've not pushed out an aqua release |
| 21:13.41 | brlcad | needs tcl/tk 8.6, which we've not migrated to yet |
| 21:14.12 | brlcad | should have given a dialog instead of dumping like that, but probably because of the app bundle |
| 21:14.31 | Notify | 03BRL-CAD:starseeker * 69230 brlcad/trunk/src/librt/tests/CMakeLists.txt: don't build temporary testing src file |
| 21:15.51 | Notify | 03BRL-CAD:starseeker * 69231 brlcad/trunk/src/librt/db5_size.cpp: don't need a separate array for this - just use the local data pointer. |
| 21:18.36 | *** join/#brlcad ickby_ (~stefan@x5d844f63.dyn.telefonica.de) | |
| 22:20.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:22.51 | *** join/#brlcad skat00sh (uid103741@gateway/web/irccloud.com/x-doqzkezpfockpjhz) | |
| 22:33.37 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:40.20 | Notify | 03BRL-CAD:starseeker * 69232 brlcad/trunk/src/librt/db5_size.cpp: Attempt a specialized cracking of the comb for the sole purpose of getting the children names for db_lookup. Causes a difference in reported size (larger), so need to compare to existing db_comb_children output and see what the difference is. |
| 23:00.01 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) | |
| 23:06.02 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 23:26.58 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |