| 01:55.37 | *** join/#brlcad Zhao_Anqing (~clouddrif@180.155.75.92) | |
| 02:48.16 | *** join/#brlcad Zhao_Anqing (~clouddrif@218.79.166.196) | |
| 03:15.02 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 03:15.02 | *** 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. | |
| 04:35.41 | *** join/#brlcad Darshpreet (~Darsh@202.164.53.117) | |
| 04:51.14 | Notify | 03BRL-CAD:brlcad * 61615 brlcad/trunk/sh/enumerate.sh: automatically figure out the number of exported functions/symbols in our public API by keying off their common _EXPORT declarations. four are way too big... should try to break up, eliminate/reduce, and/or otherwise get each API under 300 functions for starters. |
| 04:56.45 | Notify | 03BRL-CAD:brlcad * 61616 brlcad/trunk/sh/enumerate.sh: tabulate the total exported API. currently at 2489 symbols. |
| 05:01.48 | *** join/#brlcad Darshpreet (~Darsh@202.164.53.117) | |
| 05:13.22 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) | |
| 05:36.01 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) | |
| 05:46.57 | *** join/#brlcad Darshpreet (~Darsh@202.164.53.117) | |
| 05:48.50 | *** join/#brlcad Zhao_Anqing (~clouddrif@218.79.166.196) | |
| 06:16.25 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-fguowxknrtdsflhu) | |
| 06:29.35 | *** join/#brlcad ishwerdas (~ishwerdas@117.220.174.68) | |
| 06:58.02 | *** join/#brlcad Zhao_Anqing (~clouddrif@218.79.166.196) | |
| 07:07.25 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 09:11.57 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 09:28.11 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 09:49.40 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) | |
| 09:49.49 | *** join/#brlcad pandrei (~pandrei@5-12-221-177.residential.rdsnet.ro) | |
| 10:12.45 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 10:15.12 | *** join/#brlcad mihaineacsu (~mihaineac@92.81.149.0) | |
| 10:34.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 10:39.45 | *** join/#brlcad Zhao_Anqing (~clouddrif@218.79.166.196) | |
| 11:18.24 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 11:32.09 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 11:34.42 | *** join/#brlcad albertcoder (~albertcod@101.208.104.138) | |
| 11:44.36 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:35.09 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:22.40 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 13:29.17 | *** part/#brlcad ishwerdas (~ishwerdas@117.220.174.68) | |
| 13:34.07 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 13:46.19 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 13:47.22 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 13:50.27 | *** join/#brlcad ries_nicked (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 14:10.04 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 14:13.57 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 14:27.22 | *** join/#brlcad albertcoder (~albertcod@49.138.204.202) | |
| 14:33.38 | *** join/#brlcad pandrei (~pandrei@188.26.59.172) | |
| 15:37.23 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:48.14 | Notify | 03BRL-CAD:carlmoore * 61617 brlcad/trunk/doc/docbook/system/man1/en/pix-ps.xml: touch up pix-ps manpage; -W was incorrectly appearing in a sample where -S should have been used |
| 15:58.32 | *** join/#brlcad Izakey (~Isaac@195.24.220.134) | |
| 16:03.20 | ankesh11 | A question regarding API for file uploads: How do we authenticate API requests? |
| 16:05.02 | ankesh11 | Since we would automate the submission of benchmark logs after each run, it would not be right to assume every user has an account. |
| 16:06.22 | ankesh11 | So the normal route to authenticate via a username and API passkey would not work. |
| 16:06.29 | ankesh11 | Any suggestions? |
| 16:19.13 | *** join/#brlcad ishwerdas (~ishwerdas@117.199.100.152) | |
| 16:34.27 | *** join/#brlcad gagan (~gagan@124.253.231.48) | |
| 16:36.28 | Izakey | Not from me ankesh11 |
| 16:42.07 | Notify | 03BRL-CAD Wiki:14.98.212.130 * 7485 /wiki/User:Shainasabarwal/GSoC14/logs: /* Week 6 */ |
| 16:47.04 | ``Erik | why is authenticating necessary? |
| 16:53.47 | Izakey | Probably because not every benchmark result would be needed I think |
| 16:56.34 | ankesh11 | ``Erik: Security issues. A bot could be clogging our server with file-uploads if not aauthenticated. |
| 16:59.33 | mihaineacsu | this reminds me of geekbench bit.ly/1pXnTYQ , a benchmark utility. after running it, the results would be saved online, but you could keep track of them if you'd register. |
| 16:59.53 | *** join/#brlcad hsrai (~hsrai@202.164.53.122) | |
| 17:03.36 | ankesh11 | mihaineacsu: Thanks for the link! |
| 17:14.32 | *** join/#brlcad gagan (~gagan@124.253.231.48) | |
| 17:21.50 | hsrai | ankesh11: Can we upload same file again and again at http://202.164.53.122:3000/ |
| 17:23.21 | ankesh11 | hsrai: No, that's an issue. Duplicated files are not allowed at the moment. I have it noted it down in TODO. |
| 17:23.43 | ankesh11 | Were you able to see the benchmark result? |
| 17:24.16 | hsrai | ankesh11: I am unable to upload file. Check https://m.ak.fbcdn.net/sphotos-f.ak/hphotos-ak-xap1/t1.0-9/10487591_10203600257662562_6738052000579266546_n.jpg Is this issue of duplicate file? |
| 17:25.06 | hsrai | What is the logic to check duplicate file? |
| 17:25.54 | ankesh11 | hsrai: I think it's a different issue. I just came across it while some debugging. The CSRF token was not being set. |
| 17:26.11 | ankesh11 | I have found a fix, will apply and see. |
| 17:27.29 | ankesh11 | I am taking the deployment down for a couple of minutes. |
| 17:28.34 | hsrai | ankesh11: If duplicate file is an issue, can database refresh solve the problem? |
| 17:30.00 | ankesh11 | hsrai: I have made some changes, can you retry http://202.164.53.122:3000 |
| 17:30.36 | hsrai | ankesh11: Two more screenshots: https://m.ak.fbcdn.net/scontent-a.xx/hphotos-xpa1/t1.0-9/10516818_10203600257702563_1849280853250849911_n.jpg https://m.ak.fbcdn.net/scontent-a.xx/hphotos-xfa1/l/t1.0-9/10523731_10203600266822791_8641074458855955741_n.jpg |
| 17:31.25 | hsrai | I gave you three screenshots; two using Google Chrome and one using FireFox. |
| 17:31.51 | ankesh11 | Okay, are these after I made the changes? |
| 17:32.56 | brlcad | ankesh11: hi and what mihaineacsu said ;) |
| 17:33.28 | hsrai | ankesh11: Now it worked. http://202.164.53.122:3000/result/40972ea98bc14f7f99647134e3cbbcf2/ |
| 17:33.34 | brlcad | I don't think there's any issue with anonymous submissions, but abuse then does become an obvious concern -- so should take measure to prevent abuse |
| 17:34.09 | brlcad | like throttling the number of uploads to just one per IP per minute, for example, |
| 17:35.11 | ankesh11 | hsrai: That was an issue with CSRF tokens then. Glad that it worked finally. |
| 17:35.16 | brlcad | limiting the size of allowed upload data -- php has built-in limits, but you should have your own limit that drops the connection for anything chattering more than xMB of data |
| 17:36.02 | ankesh11 | brlcad: Yes, the abuse is the only issue. I have a file-upload limit of 5MB at the moment. |
| 17:36.20 | ankesh11 | I will check if I can have an IP specifc limit. |
| 17:36.52 | brlcad | definitely implement some form of configurable submission throttling |
| 17:37.27 | brlcad | if you're currently using the filename, that's no good -- that's a simple random number :) |
| 17:37.59 | ankesh11 | Didn't get the filename part |
| 17:38.00 | brlcad | generate a uuid for the connection or md5 sum of the file contents to get a unique key |
| 17:38.27 | brlcad | you said -- 13:23 < ankesh11> hsrai: No, that's an issue. Duplicated files are not allowed at the moment. I have it noted it down in TODO. |
| 17:39.04 | brlcad | the system should have no awareness of duplication other than perhaps exact file content (md5sum) |
| 17:39.23 | brlcad | if it's storing records based on the filename uploaded, that'll need to change |
| 17:39.38 | ankesh11 | brlcad: That's fine. The duplication mechanism checks for MD5 sum. |
| 17:39.42 | brlcad | the filename is meaningless (and in fact you could override the filename when you store them) |
| 17:40.01 | brlcad | ah, thats great then |
| 17:40.57 | brlcad | so then just need to let a subsequent upload "succeed" (i.e., do nothing) when it finds a matching md5 and let the user know |
| 17:41.23 | ankesh11 | Okay, that makes sense. Will do that. |
| 17:41.48 | brlcad | the files contain a date stamp so there shouldn't be identical content counting towards a tally |
| 17:42.44 | brlcad | (they also contain a user and hostname stamp too, so if the content is identical, it is the same "record" for all practical purposes) |
| 17:43.44 | hsrai | ankesh11: How software behave, if it duplicate log file is detected? |
| 17:44.40 | hsrai | ankesh11: What is the logic to check duplicacy of log file? |
| 17:45.36 | ankesh11 | hsrai: Right now, the backend does checks for duplicate files and raises an error. This subsequently makes the file-upload fail. I would ensure instead of failing the upload, an alert message is generated for the user and the upload succeeds. |
| 17:46.04 | ankesh11 | hsrai: By matching the MD5 of the file with the files already in the database. |
| 17:46.14 | ankesh11 | s/MD5/MD5 sum |
| 17:49.14 | ``Erik | if the md5's match, do you then do an explicit compare of the entire file, or do you assume that an md5 collision would be so rare and the data not valuable enough to drop? |
| 17:50.59 | ankesh11 | ``Erik: the latter. |
| 17:52.07 | ankesh11 | Any feedback on the front-end? http://202.164.53.122:3000/result/9ff41f77d2fd4c04b40b53ff9605ee55/ |
| 17:52.41 | brlcad | would call 1/2^128 pretty f'n rare |
| 17:54.16 | ``Erik | :D |
| 17:54.18 | mihaineacsu | http://www.wolframalpha.com/input/?i=2%5E128 |
| 17:54.52 | brlcad | one over that ;) |
| 17:55.41 | ``Erik | that'd be assuming every bit has the same randomness... |
| 17:55.49 | brlcad | more likely to win every lottery on the planet every year until you die (and you never bought a ticket!) |
| 17:56.04 | ankesh11 | Also, the benchmark script doesn't detect the system's architecture (32/64 bit), so I passed on that. |
| 17:56.55 | brlcad | ankesh11: it indirectly reports it in the system information that follows |
| 17:57.21 | ankesh11 | Physical and Virtual Address sizes? |
| 18:00.50 | ankesh11 | The clflush size and cache_alignment report the value 64. Are these the ones that indirectly point to it? |
| 18:04.22 | brlcad | ankesh11: they don't sound like it |
| 18:04.37 | brlcad | the architecture type is a key indicator |
| 18:04.45 | brlcad | "x86_64" |
| 18:05.35 | mihaineacsu | clflush stands for cache line flush, don't use it to pinpoint architecture, it might trick you in some cases. |
| 18:05.48 | ankesh11 | Ah, I see. That does not get parsed at the moment. Will try to added a parser method for that. |
| 18:06.11 | ankesh11 | mihaineacsu: Okay. |
| 18:07.11 | Izakey | What type of curvature does a primitive's rt_???_curve() function compute ? mean curvature or Gaussian curvature |
| 18:10.04 | brlcad | ankesh11: there's a wealth of platform-specific information that will get dumped into the log after our results that you'll want to be able to index at some point |
| 18:10.14 | brlcad | and it's going to be rather platform-specific |
| 18:10.25 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 18:10.49 | brlcad | for example, if it's a log from a FreeBSD system, the only decent indicator you'll have of whether it's 32-bit or 64-bit is going to be the name of the CPU and whether the kernel is i386 or amd64 |
| 18:11.06 | brlcad | on linux, it's a different set of indicators, on mac even more different |
| 18:11.44 | brlcad | so you'll have to be prepared to just know "what" you're looking for and we can work on enhancing the various value parsers as new systems are encountered |
| 18:12.37 | brlcad | i.e., make one parser that tries to determine one value like how many cores |
| 18:12.56 | brlcad | another separate parser for a second value, e.g., cpu L1 cache line sizes |
| 18:13.16 | brlcad | and so on |
| 18:14.06 | brlcad | wonders how much of the config.guess logic might be worth turning into API |
| 18:15.50 | ankesh11 | brlcad: Okay. Going that route would be time-consuming though, and I had not thought of extending the current parser design. There is limited time, I don't know if all that can be encompassed in that period. |
| 18:17.00 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 18:17.43 | brlcad | ankesh11: it's important to have the parser framework set up, not have lots of parsers implemented |
| 18:18.00 | brlcad | so when gsoc is over, others can go in and add more parsers or expand existing ones |
| 18:18.08 | brlcad | not try to understand one monster parser ;) |
| 18:18.52 | brlcad | can have one monster parser for the portion of the log file that is ours, but separate parsers for the data that follows from other tools |
| 18:19.30 | brlcad | if that's not feasible, what's left on your todo blocking you? |
| 18:19.37 | ankesh11 | Right, it is there actually. The current design by Suryajith is very neat. Each info from the file is extracted via a method, and it's easy to add new methods. |
| 18:20.09 | ankesh11 | brlcad: I have to do the Comparisons View, Email Logs, Web API, deployment. |
| 18:22.19 | ankesh11 | The clean-up would take some time as well, there have been not many revisions after the first and second draft. Before this thing goes live, we need to take care of it. There are several small things when taken together could amount to a significant amount of time. |
| 18:22.38 | ankesh11 | I don't want to rush it all in the end. |
| 18:39.45 | ankesh11 | Maybe I would give it a go - as I understand the Parser Framework has to be another layer of abstractions over the actual parsers. |
| 18:40.50 | ankesh11 | The actual parsers would then have to only extract the info using suitable RegEX, and the parent Framework would do the rest. |
| 18:48.27 | brlcad | ankesh11: okay, sounds good -- of those four on your to-do, email logs are probably the lowest priority -- lets take them off the table |
| 18:48.54 | ankesh11 | Alright. |
| 18:48.58 | brlcad | if you make the web api drop the log into a folder for processing, it'll be easy to later set up a procmail that dumps e-mail logs into that same folder |
| 18:50.14 | ankesh11 | It can be done, sure. |
| 18:51.26 | ``Erik | bu_machine_report(bu_vls *target); ? |
| 18:52.06 | ankesh11 | Another thing in the todo is User Accounts. It was an issue the last time we discussed, I am still unsure how we are going to handle it. |
| 19:04.11 | brlcad | ``Erik: sort of, but probably in some sysctl style key=value form |
| 19:04.36 | brlcad | maybe return an avs with some predefined system attributes |
| 19:05.46 | brlcad | right now, it completely punts and just runs "uname -a" "cat /proc/cpuinfo" "sysctl -a hw" and variety of other tools to try and get as much info as possible |
| 19:12.00 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 19:38.14 | ``Erik | yeh, I think something like 82% of the downloads are for windows, so the current approach is .. not optimal :) |
| 19:40.45 | mihaineacsu | wow |
| 19:42.23 | *** join/#brlcad albertcoder (~albertcod@101.208.11.35) | |
| 19:48.34 | Notify | 03BRL-CAD:carlmoore * 61618 brlcad/trunk/src/util/pix-ps.c: yes, I got different viewings when I used non-default sizing with this new version and with the previous version |
| 19:48.45 | ``Erik | hm, this last week it was only 67.5% windows, linux seems way up O.o |
| 19:56.43 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 20:16.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 20:30.36 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 20:33.01 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 20:55.11 | Notify | 03BRL-CAD Wiki:Albertcoder * 7486 /wiki/User:Albertcoder/GSoC2014/logs: /* Development Period */ |
| 21:43.13 | Notify | 03BRL-CAD:carlmoore * 61619 brlcad/trunk/doc/docbook/system/man1/en/rle-fb.xml: touch up rle-fb man page |
| 22:03.36 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7487 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 7 */ |
| 22:40.51 | kanzure | a c wrapper around opennurbs would be really useful to python-brlcad :\ |
| 22:47.41 | pandrei | brlcad: in the bot header that daniel modified, he added a |
| 22:47.53 | pandrei | bool ApendThickness(void) const throw() |
| 22:47.57 | pandrei | for a face |
| 22:49.16 | pandrei | I know it's related to RT_BOT_SOLID and RT_BOT_SURFACE (thickness is null for the following) |
| 22:49.52 | pandrei | but why would it be append? is it something i'm missing? |
| 22:50.00 | pandrei | why would it be named append- |
| 23:19.55 | ``Erik | huh, emacs 23 has "M-x proced" (top-like buffer) |
| 23:26.16 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7488 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 8 */ |
| 23:42.03 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
