| 00:16.57 | starseeker | winces - I'd forgotton how intimidating the ogl framebuffer code is |
| 00:17.26 | starseeker | wonders how much of this is still relevant... |
| 00:19.57 | starseeker | low level color map stuff, manual cursor drawing (???) |
| 00:21.40 | starseeker | X event handling... |
| 00:28.47 | *** join/#brlcad marien (~marien@91.207.117.8) | |
| 00:58.23 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) | |
| 02:03.44 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 02:08.00 | *** join/#brlcad TCD (~TheCommie@152.78.235.20) | |
| 03:09.59 | *** join/#brlcad klvlad (~klvlad@193.106.31.176) | |
| 03:12.35 | *** join/#brlcad hoiji (~hoiji@117.201.180.164) | |
| 05:00.36 | brlcad | starseeker: colormap management goes hand-in-hand with window management |
| 05:27.14 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 06:25.59 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) | |
| 06:30.46 | *** join/#brlcad maths22 (~gcimaths@66-118-151-70.static.sagonet.net) | |
| 07:24.49 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) | |
| 07:52.44 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) | |
| 07:52.45 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 07:52.45 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) | |
| 07:52.45 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-fiqqgwbiwdbiohan) | |
| 07:52.45 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 07:52.45 | *** join/#brlcad harmanpreet (~harman@198.199.108.236) | |
| 07:52.45 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 08:52.59 | Notify | 03BRL-CAD Wiki:Anuragapk1 * 0 /wiki/User:Anuragapk1: |
| 09:19.36 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 11:36.07 | *** join/#brlcad teepee_ (bc5c2134@gateway/web/freenode/ip.188.92.33.52) | |
| 11:54.44 | starseeker | brlcad: I guess this gets back to "what is the job of the framebuffer" |
| 11:55.50 | starseeker | suspects his notion of its job is rather different from what's currently there... |
| 12:02.36 | starseeker | if color maps are controlled by the windowing system, any requirement that colormap (or, for that matter, window) managment be done in the framebuffer would seem to preclude the notion of a portable framebuffer, barring a cross-platform (or cross windowing-system I guess) wrapper library to hide all details |
| 12:12.56 | starseeker | will expore what Tk offers... If I can get one dm+fb to work with OSG + Tk for multiple platforms that's probably "good enough" for a first step |
| 13:11.14 | *** join/#brlcad ries (~ries@190.9.171.121) | |
| 13:49.37 | Notify | 03BRL-CAD Wiki:Eric.Weissmann * 0 /wiki/User:Eric.Weissmann: |
| 14:10.11 | brlcad | starseeker: yep |
| 14:10.40 | brlcad | rather, whether colormaps are in use is defined by the graphics system |
| 14:11.08 | brlcad | opengl supports with and without, but I'm not sure what happens if you run opengl in RGBA mode on a colormapped display |
| 14:11.17 | brlcad | probably up to the driver |
| 14:17.01 | *** join/#brlcad cwstirk (~charlie@c-71-56-216-45.hsd1.co.comcast.net) | |
| 14:17.23 | *** join/#brlcad ishwerdas (~inderplus@117.199.101.72) | |
| 14:20.36 | *** join/#brlcad TCD (~TheCommie@152.78.235.20) | |
| 15:20.27 | brlcad | TCD: welcome back |
| 15:27.29 | TCD | Hey. :p |
| 16:04.35 | maths22 | brlcad: remind me when the server is going down |
| 16:05.17 | maths22 | never mind. I found the email |
| 16:17.44 | Notify | 03BRL-CAD Wiki:Sahil Gulania * 0 /wiki/User:Sahil_Gulania: |
| 17:32.39 | brlcad | maths22: any possibility of getting a temporary mirror up based on your new site? |
| 17:33.16 | brlcad | I can copy the database to another host, mostly a matter of having something I can check out and ensure is set up |
| 17:44.44 | *** join/#brlcad javampire (~ncsaba@p4FF732EF.dip0.t-ipconnect.de) | |
| 17:53.46 | Notify | 03BRL-CAD:indianlarry * 60094 brlcad/trunk/src/conv/step/step-g/ProductDefinition.cpp: Need to cast to more generalized ProductDefinitionFormation here... |
| 17:55.09 | javampire | brlcad: it was indeed easy to wrap libged, at least most of the basic commands which only need a CL style argv argument ! |
| 17:56.04 | javampire | I was able to mimic mged's interactive parameter input and update of command line history with the full command at the end |
| 17:56.42 | Notify | 03BRL-CAD:indianlarry * 60095 brlcad/trunk/src/conv/step/STEPWrapper.cpp: Changed so BREP region named with product name and the BREP solid suffixed with ".s". |
| 17:56.52 | javampire | there's however much more work needed to make it real comfortable from python, and to wrap all the commands |
| 17:57.44 | javampire | brlcad: one thing would be very useful though, namely to be able to get the command help/manual pages via the library itself |
| 17:58.12 | javampire | then I can set up the python doc string to match that, and the online help will be available auto.magically |
| 17:59.15 | javampire | or perhaps put the xml (or similar) formatted help in a standard place ? |
| 17:59.29 | javampire | I'm not sure a formatted man page can be used for this purpose from python |
| 18:04.21 | Notify | 03BRL-CAD:indianlarry * 60096 brlcad/trunk/src/conv/step/BRLCADWrapper.cpp: Fixed counter variable in GetBRLCADName() by making static. Used with incoming name template to find unused name in the database. |
| 18:04.45 | brlcad | javampire: yes, help getting moved to the libs is definitely under way |
| 18:05.04 | brlcad | only one or two commands are currently restructured, but the idea is for each command to be self-contained |
| 18:05.09 | javampire | in what form ? |
| 18:05.38 | brlcad | each command will register itself with libged via an initialization function |
| 18:06.19 | javampire | ok, and then I can get a list of commands using a library call ? |
| 18:06.31 | brlcad | at that point, calling each ged_command() becomes unnecessary though you'll still be able to |
| 18:06.38 | Notify | 03BRL-CAD:starseeker * 60097 brlcad/trunk/misc/CMake/BRLCAD_CMakeFiles.cmake: Add MODULE to the keywords to check for. |
| 18:06.54 | brlcad | you'll be able to invoke through something like ged_run() |
| 18:07.02 | javampire | aha |
| 18:07.08 | javampire | with command name as first parameter ? |
| 18:07.17 | brlcad | right |
| 18:07.23 | brlcad | basically the command line as it is now |
| 18:07.40 | brlcad | becomes a prompt api |
| 18:07.42 | javampire | ok, the problem in python is that everything is a function |
| 18:08.00 | brlcad | how's that a problem? |
| 18:08.35 | javampire | so right now it looks like: |
| 18:08.36 | javampire | >>> ged_in("test.s", "sph", "0", "0", "0", "3") |
| 18:09.00 | javampire | I got this in the history after executing ged_in() and answering the questions |
| 18:09.26 | javampire | so that part is OK, but for interactive use python is not exactly the easiest |
| 18:10.05 | javampire | for scripting it is cool, but it's more verbose than mged/tcl |
| 18:10.16 | brlcad | right, which would be bad |
| 18:10.31 | brlcad | except for what can be built on top of it |
| 18:10.38 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 18:10.39 | javampire | well I'm not sure if that's really that bad - I was aiming for scripting anyway |
| 18:11.27 | javampire | Currently it's definitely more to type if you want to create a primitive directly from python prompt via libged |
| 18:11.33 | brlcad | the only change I was suggesting is that instead of needing to wrap 400+ ged_cmd() functions, you'd wrap about 6 |
| 18:11.42 | brlcad | the limitations of the ac/av interface are unchanged |
| 18:11.51 | javampire | well it's not such a big deal, I wrap them automatically anyway |
| 18:12.12 | javampire | about 2-300 of them works out of the box |
| 18:12.13 | brlcad | the ged_cmd() functions also aren't going away, so doesn't really matter |
| 18:12.26 | brlcad | it's more what has to be documented/explained and what's easiest |
| 18:12.53 | javampire | I see the most value by documenting the commands and let them output the help on demand |
| 18:13.08 | brlcad | ged_exec("in", "test.s", "sph", "0", "0", "0", "3") == ged_in("test.s", "sph", "0", "0", "0", "3") |
| 18:13.36 | brlcad | nods |
| 18:13.48 | brlcad | that's why I said about 6 functions |
| 18:14.36 | brlcad | one of the registered commands is help/usage |
| 18:14.46 | javampire | well I would like: ged_in("--help") return me a help string which I can then place in the __doc__ of the function |
| 18:14.52 | brlcad | basically, they define a command object |
| 18:15.09 | javampire | then help("ged_in") will give me that string |
| 18:15.27 | brlcad | that object has a brief description, short name(s), loading/unloading functions, help/usage, and the command that actually does work |
| 18:15.49 | javampire | ok, that would be good then |
| 18:16.18 | brlcad | I'm thinking there might be a way to translate/wrap those structure definitions into python objects |
| 18:16.19 | javampire | I guess a list of registered commands could be obtained by a library call ? |
| 18:16.24 | brlcad | right |
| 18:16.39 | javampire | sure, it's no big deal |
| 18:17.02 | javampire | right now I already have a ged_command decorator which does similar work |
| 18:17.07 | brlcad | so you'd have something like ged = ged_init() |
| 18:17.23 | brlcad | ged.in("test.s", "sph", "0", "0", "0", "3") |
| 18:17.33 | brlcad | ged.help("in") |
| 18:17.36 | javampire | well it's very similar already |
| 18:17.48 | brlcad | ged.index() |
| 18:17.54 | javampire | only the "in" is a keyword in python and can't be used directly ;-) |
| 18:18.03 | javampire | help(ged) is better |
| 18:18.19 | javampire | python users are used to that I guess |
| 18:18.46 | javampire | and there's already a dir(ge) which will show all members of the ged structure |
| 18:18.52 | javampire | dir(ged) |
| 18:19.08 | brlcad | so I presume you've gone through enough examples now to know the wdb example and some mged commands, right? |
| 18:19.11 | javampire | that works for the libged library too, so I can list all available functions |
| 18:19.57 | javampire | the wdb example is easiest done using libwdb |
| 18:20.16 | javampire | and the really basic mged commands are likely working, I only tested ls and in |
| 18:20.20 | brlcad | sure, that's not my question ;) |
| 18:20.50 | javampire | I can paste a sample session if interested... |
| 18:20.57 | brlcad | i'm asking whether you're familiar with them both well enough now |
| 18:21.30 | brlcad | (it's a yes/no) :) |
| 18:21.56 | javampire | well it still depends on the perspective :-) |
| 18:22.06 | brlcad | your perspective :) |
| 18:22.19 | brlcad | the reason I ask |
| 18:22.23 | javampire | wdb is quite familiar as I wrapped most of the mk_... commands |
| 18:23.05 | javampire | mged is also familiar, but much less, I don't have an overview of all it's miriad of commands... |
| 18:23.14 | brlcad | if you're comfortable with them and get the gist of opening a database and creating geometry via libwdb C-style in python and now familiar with creating geometry via libged mged-style in python |
| 18:23.43 | javampire | that is a yes, I can compare if that's the question |
| 18:24.06 | brlcad | then that makes you the best person to ignore both and write a (non-functioning) python program that might be how an IDEAL python interface would look like |
| 18:24.25 | javampire | so: if I would do it interactively, meaning just create a few objects ad-hoc, I would use the mged style |
| 18:24.28 | brlcad | like just how short/simple could it possibly look like |
| 18:24.35 | javampire | for scripting the wdb is easier right now |
| 18:24.48 | javampire | well the current wdb interface is quite ok |
| 18:25.01 | brlcad | except the mged-style for interface is a fluckton of typing, no? |
| 18:25.16 | javampire | yes, but it's ok |
| 18:25.30 | javampire | I would still use it instead of mged |
| 18:25.34 | brlcad | well, that's my question -- what would it look like if it were perfect? |
| 18:25.36 | javampire | because it is easier to explore things |
| 18:25.39 | brlcad | or at least substantially better? |
| 18:25.51 | javampire | getting help is easier in python |
| 18:26.06 | javampire | you can look into your objects in all detail |
| 18:26.11 | brlcad | sure sure |
| 18:26.17 | brlcad | this isn't about the merits of python :) |
| 18:26.31 | javampire | well but that's the most important missing point in brlcad |
| 18:26.46 | javampire | you have a miriad of commands and don't know what they do |
| 18:26.57 | javampire | and even if you do, not exactly how |
| 18:27.07 | brlcad | sure, and that's all being fixed |
| 18:27.13 | brlcad | and should be language agnostic |
| 18:27.33 | brlcad | so we can present a consistent command api in python later |
| 18:27.35 | brlcad | or tcl |
| 18:27.39 | brlcad | or posix shell even |
| 18:27.44 | javampire | well in python I can programatically search for the command I want, based on it's parameters for example or whatever else |
| 18:27.55 | brlcad | or lisp for the autocad folks |
| 18:28.45 | javampire | well providing real good on-line help is the most useful step - wrapping libged was easy enough |
| 18:28.45 | brlcad | not that it's relevant, but you actually can do all that in tcl too |
| 18:29.00 | brlcad | programmatically search, introspect commands, even rewrite aspects on the fly |
| 18:29.17 | javampire | yes, but tcl is so cryptic that I don't understand what I wrote yesterday |
| 18:29.27 | brlcad | because you don't write tcl ;) |
| 18:29.34 | javampire | <PROTECTED> |
| 18:29.42 | javampire | forced by BRL-CAD :-) |
| 18:29.45 | brlcad | don't get me wrong, i'm not defending tcl .. it is what it is |
| 18:30.02 | javampire | python is more verbose but also forcing you to write mostly readable code |
| 18:30.13 | javampire | I love the possibility to name the parameters |
| 18:30.20 | javampire | even in the method calls ! |
| 18:30.32 | javampire | then I always know what I actually do with a call |
| 18:31.04 | javampire | and that's what I will do with the libged calls too - set them up with named parameters |
| 18:31.15 | brlcad | that's great |
| 18:31.24 | javampire | I mean from python |
| 18:31.26 | brlcad | and the more easier to use we can make it, the better it will be |
| 18:31.35 | brlcad | which obviously includes integrating help and usage |
| 18:31.41 | brlcad | and having better names for things |
| 18:31.47 | brlcad | "in" is a terrible name for example |
| 18:31.59 | javampire | but it's short ;-) |
| 18:32.05 | brlcad | (comes from "type in an object") |
| 18:32.22 | javampire | and that's probably the reason why it is as it is - it's short |
| 18:32.32 | brlcad | typing two more characters for "make" or some other word wouldn't be the end of the world ;) |
| 18:32.36 | javampire | for typing in geometry it's the best |
| 18:33.03 | javampire | but it's hard to learn and it's real bad for scripting |
| 18:33.04 | brlcad | yeah, we have a lot of really short names that come from a time when every keystroke mattered |
| 18:33.22 | javampire | so there are different use cases, all legitimate |
| 18:33.24 | brlcad | and we ended up with things like 'e' to Draw objects and 'd' to Erase objects... |
| 18:33.51 | javampire | and when I use mged, I use them and I don't care :-) |
| 18:34.17 | javampire | it's all about having a good reference to easily look it up when you need it |
| 18:34.26 | brlcad | unintuitive and makes it all the more cumbersome to learn/remember |
| 18:34.40 | javampire | yes, but first step is to find it at all |
| 18:34.41 | brlcad | yeah, easy to introspect .. self-documenting |
| 18:34.49 | brlcad | tab completion ftw |
| 18:35.02 | javampire | if you have 400 commands, it doesn't matter if it's E or D or make |
| 18:35.28 | javampire | oh yes, tab completion works well in my python shell |
| 18:36.13 | javampire | ok, I have to run, it's already late, I have an appointment |
| 18:36.18 | javampire | see you ! |
| 18:43.55 | Notify | 03BRL-CAD:starseeker * 60098 (brlcad/trunk/src/conv/step/g-step/AP203.h brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp brlcad/trunk/src/conv/step/g-step/g-step.cpp): Based on what Keith is seeing for imported geometry, we had the matrix ordering reversed in the item transform for export. |
| 18:53.33 | maths22 | I'm working on commiting now |
| 18:54.00 | maths22 | brlcad: I'll make a tar of the dir and db dumps, and can send you a link |
| 18:54.04 | maths22 | How does that sound? |
| 19:02.54 | starseeker | brlcad: is the linux system "librt" library no longer current? |
| 19:05.10 | brlcad | maths22: sure |
| 19:05.24 | brlcad | starseeker: define current |
| 19:06.54 | starseeker | something that current standards specify as a POSIX system library |
| 19:07.44 | starseeker | is looking, and it seems like at least some POSIX functionality is still kept in librt, at least by the GNU crowd.. |
| 19:09.43 | brlcad | glibc still includes librt, but I believe it is or at least was deprecated at one point in time |
| 19:10.52 | starseeker | was hoping so, but so far can't turn up evidence of that :-( |
| 19:12.02 | brlcad | might have been undeprecated |
| 19:12.53 | brlcad | closest I can find seems to be https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/librt.html |
| 19:14.29 | starseeker | libc manual seems to indicate it's still alive and kicking, at least for some things: http://www.gnu.org/software/libc/manual/html_node/Asynchronous-I_002fO.html |
| 19:14.43 | brlcad | yeah, I'm not seeing any reference that it's deprecated any more |
| 19:14.55 | starseeker | crud |
| 19:15.17 | brlcad | meh, doesn't change much |
| 19:15.51 | brlcad | same reason daniel mentioned about not being polite to dump hundreds of binaries into /usr/bin, similarly not polite to dump dozens of libs into /usr/lib |
| 19:16.25 | starseeker | nods - was mainly hoping the warning we get on linking would eventually go away |
| 19:16.40 | maths22 | brlcad: I will do that when my commit finishes |
| 19:16.47 | brlcad | maths22: cool, okay |
| 19:16.48 | maths22 | I think I may finally have mediawiki redady to go |
| 19:17.10 | brlcad | maths22: if I can get it up and running easily enough, I'll switch DNS to a different IP temporarily |
| 19:17.17 | maths22 | it is "transmitting file data," but I think I added mime types to all of them |
| 19:17.29 | brlcad | heh |
| 19:17.39 | brlcad | still didn't set up your file yet? |
| 19:17.45 | maths22 | if you want, you could do an svn pull when it finishes and I can send you the images |
| 19:18.04 | brlcad | okay |
| 19:18.28 | maths22 | i did, but it did not cover some of the stranger file names, including "LICENCE" and files without extensions |
| 19:21.11 | maths22 | it might be easier if you just pull the mediawiki db dump |
| 19:22.50 | maths22 | in the mirror, you should use http://www.mediawiki.org/wiki/Manual:$wgReadOnly |
| 19:23.25 | brlcad | maths22: http://brlcad.org/~sean/subversion.config |
| 19:23.42 | brlcad | that's one I usually use that covers CAPS files and more |
| 19:24.37 | maths22 | I used that one, but I disabled the caps check because it was matching files that made no sense |
| 19:24.43 | maths22 | I should be able to re-enable it now |
| 19:25.28 | brlcad | ah, interesting .. like what? |
| 19:25.56 | brlcad | odd to encounter a non text file in caps |
| 19:25.57 | maths22 | I don't remember anymore |
| 19:26.16 | maths22 | it was matching some image file I think (maybe in wordpress) |
| 19:26.17 | brlcad | k |
| 19:26.41 | maths22 | to see all the ones it missed: http://paste.ubuntu.com/7051714/ |
| 19:27.21 | brlcad | the .files I'd expect |
| 19:27.30 | brlcad | ahh, ruby files |
| 19:27.45 | brlcad | and php files with the old numbered suffix |
| 19:30.07 | maths22 | also scss |
| 19:44.44 | Notify | 03BRL-CAD:starseeker * 60099 brlcad/trunk/CMakeLists.txt: Break out directory path and rpath handling aspects of the toplevel CMakeLists.txt file into modules. This logic ends up getting re-used a lot, so package it up nicely. |
| 19:54.17 | Notify | 03BRL-CAD:maths22 * 60100 (web/trunk/htdocs/.htaccess =================================================================== and 11 others): added mediawiki w/o images |
| 20:03.46 | *** join/#brlcad caen23 (~caen23@92.81.213.198) | |
| 20:14.37 | brlcad | hi caen23! |
| 20:14.39 | brlcad | ltns |
| 20:45.36 | caen23 | hi brlcad. yeah, i haven't been on irc lately, how's it going? |
| 20:45.53 | brlcad | BUSY |
| 20:45.55 | brlcad | but good ;) |
| 20:46.07 | brlcad | you kinda disappeared there for a while |
| 20:46.16 | brlcad | off the list, off irc .. all okay? |
| 20:47.36 | caen23 | yes, things are fine, i've been busy these days too, school stuff... can't wait for it to be over, heh :-) |
| 20:48.02 | brlcad | i know how that feels |
| 20:48.39 | brlcad | I still always tell people to stay in school as long as possible :) |
| 20:49.12 | brlcad | life after academics is a different world |
| 20:51.46 | caen23 | so i've heard. there are some good parts about being in school, some bad stuff too... gotta learn to deal with it, i guess |
| 21:05.48 | brlcad | yep, stress, homework, exams, tuition, ... but I believe with hindsight that the good FAR outweighs the bad, especially compared with the good and bad ratio once you're "out" |
| 21:06.02 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 21:06.28 | brlcad | even the best circumstances are usually dwarfed by ones school experience and the years quickly accellerate |
| 21:06.43 | brlcad | caen23: are you applying to gsoc? |
| 21:16.58 | caen23 | well, i was just now thinking about it. the problem is that they want me to be enrolled by april, and the admissions here don't take place until july |
| 21:17.14 | caen23 | but i really wanted to do something this summer, so i think i'll try to find a way around it |
| 21:17.42 | caen23 | even if i can't apply to gsoc, i think i will try to take on a project anyway |
| 21:35.14 | TCD | Oh, I remember what I was going to say. |
| 21:35.32 | TCD | Is there any specific point you'd recommend that would be easiest to dig into the codebase from? |
| 21:57.52 | brlcad | caen23: ahhh |
| 21:58.39 | brlcad | caen23: they do require "proof of enrollment" so it basically comes down to whether the university considers you a student as of the specific start date in the FAQ (and they're willing to provide some document proving that) |
| 21:59.10 | brlcad | TCD: what do you mean? ... entirely depends what you're interested in doing |
| 21:59.57 | brlcad | you should not just wander without a guide (i.e., talking here) because BRL-CAD is really big (over a million lines, thousands of files, hundreds of apps, dozens of libs) |
| 22:00.16 | brlcad | think of it like a really big city |
| 22:01.11 | brlcad | you wouldn't judge a city by any particular block and certainly wouldn't just start walking the streets hoping to get familiarized with all of it ... you'd only be looking at a small microcosm |
| 22:01.18 | TCD | brlcad: Yeah, maybe I'm just odd but I find if I can find some feature X that's easy enough to follow, it gives a decent idea of the architecture of the rest...but I see what you mean |
| 22:01.28 | TCD | brb focus. |
| 22:02.50 | brlcad | TCD: sure, but we have many "architectures" .. several layers .. some trivial to follow but it's complicated to get a big picture without a guide |
| 22:03.10 | TCD | understood |
| 22:03.28 | brlcad | and again it depends whether you're talking about app infrastructure, commands, geometry, ray tracing, conversion, image processing, .... |
| 22:03.46 | brlcad | TCD: sounds like we need to talk more specifically about your interests ;) |
| 22:04.17 | TCD | Hah |
| 22:04.35 | TCD | Yeah, I figured I should organise that myself before bringing other people into the discussion :) |
| 22:05.06 | brlcad | okay :) |
| 22:05.16 | brlcad | well please do ask questions |
| 22:05.50 | brlcad | you might get some "big picture" perspective out of the src/README file |
| 22:06.18 | TCD | I should take notes |
| 22:07.25 | brlcad | do you have any background in parallel processing, multithreading? |
| 22:08.16 | TCD | Uh...we're doing multithreaded-ness in lectures at the moment, but I've never done it outside that |
| 22:08.25 | brlcad | with your skills and interests, something in our infrastructure or rendering/science categories are probably a good fit |
| 22:08.43 | brlcad | that at least cuts the ideas by a third ;) |
| 22:09.15 | TCD | Heh; I'd definitely scientific or similar as my primary interest |
| 22:12.52 | brlcad | if you had to grade your C/C++ coding ability on a scale of 0 to 100 with 0 being "C-who?", 25 being "I can write some simple programs, but just getting started", 50 being "pretty familiar but still learning lots about the language every day", 75 being "I rarely have trouble writing code, but wouldn't say I'm proficient just yet", and 100 as "I'm a coding god, fear me." ... where would you rate yourself? :) |
| 22:14.23 | TCD | Uh...I'd guess somewhere around 65-70 for C++ (if I had a week to get reacquainted with it) and given I've got no working experience with a C mindset, probably somewhere around 50 for straight C |
| 22:14.38 | TCD | though I could be vastly underestimating or overestimating my abilities |
| 22:23.54 | brlcad | TCD: okay, fair enough, let me think about that a bit, you can look over the projects, and we can maybe discuss options later today/tomorrow |
| 22:24.26 | brlcad | note that we have a website outage that will begin in about 30 hours from now (for about 12 hours) so cache a copy of the wiki page ;) |
| 22:26.39 | TCD | will do! |
| 22:32.28 | Notify | 03BRL-CAD:starseeker * 60101 NIL: Create a branch for more radical testing with openscenegraph. |
| 23:07.33 | Notify | 03BRL-CAD:starseeker * 60102 (brlcad/branches/openscenegraph/src/other/openscenegraph/AUTHORS.txt =================================================================== and 520 others): Add a 'minimal subset' build of OpenSceneGraph 3.2.0. The build system has been extensively reworked as a prelude to making it 'play nice' with BRL-CAD's more advanced build system features. |
| 23:10.55 | Notify | 03BRL-CAD:starseeker * 60103 (brlcad/branches/openscenegraph/src/other/openscenegraph/src/osgviewerapp/CMakeLists.txt =================================================================== and 11 others): Whoops - add the viewer app |
| 23:12.17 | Notify | 03BRL-CAD:starseeker * 60104 brlcad/branches/openscenegraph/src/other/openscenegraph/src/osgDB/FileUtils.cpp: Fudge a way to run the viewer from at least one of the build directories. The right way to do this is probably to have the application pass the appropriate path to filepath at runtime, if the hooks for that exist. (If not, then the right way is to create the hooks.) |
| 23:17.08 | *** join/#brlcad inscriber (~inscriber@82.146.41.84) | |
| 23:23.05 | ``Erik | grades himself... 110! BWAHHHH BOW DOWN AND FEAR ME! er, n/m, imagine there're still a few tricks to learn O:-) |
| 23:35.04 | TCD | I wonder if there's some kind of mathematical proof to show that there is always something extra to learn. |