| 00:38.15 | brlcad | hello stas |
| 00:38.47 | stas | brlcad, if only you are not a bot, hello |
| 00:40.17 | CIA-128 | BRL-CAD: 03starseeker * r49739 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Summary.cmake): move the rest of the summary logic to BRLCAD_Summary.cmake, organize, clean-up, header and footer, etc. |
| 00:40.45 | starseeker | he works like a machine, but he's not a bot ;-) |
| 00:41.15 | stas | whoa, sorry for that :) |
| 00:42.04 | stas | actually guys if you have a minute, I wanted to ask about gsoc |
| 00:42.34 | starseeker | ask away - we read scroll-back, so even if we aren't around better to ask and wait |
| 00:42.55 | stas | nice, thanks. |
| 00:43.21 | stas | I read on wiki you are looking for a mainter for brlcad web stuff |
| 00:44.05 | starseeker | most of the gsoc web related stuff is about new abilities, not so much maintaining |
| 00:44.22 | stas | the only question I have about this, is how hard is to make you guys change your position about what should be the technologies |
| 00:44.38 | starseeker | points at brlcad - question for him |
| 00:44.47 | brlcad | stas: "it entirely depends" :) |
| 00:45.14 | brlcad | we're not married to any technology, but would need a compelling reason to move to something else given the short timeframe gsoc affords |
| 00:45.23 | stas | i mean, i know python and php, but tbh, i will never get back to those if it were to write web stuff |
| 00:45.50 | brlcad | so, a RoR fan? |
| 00:46.00 | stas | ruby to be fair |
| 00:46.05 | stas | ror is kinda bloated |
| 00:46.12 | brlcad | nods |
| 00:46.18 | brlcad | so what's the idea? |
| 00:46.36 | brlcad | migrate it all to custom ruby code? :) |
| 00:47.15 | brlcad | (yes is a valid answer, smilie notwithstanding) |
| 00:47.17 | stas | not much, write all the stuff you need with a mvc framework, automatize some continous integration (be that travis-ci or a jenkins instance on our own) with a 80-90% coverage |
| 00:47.40 | starseeker | waits for ``Erik to vote for uncommonweb and lisp... |
| 00:47.43 | stas | from that point stuff should be a snap to maintain |
| 00:48.08 | stas | i think lisp would be an overhead :) |
| 00:49.13 | stas | btw, I saw docbook has a nice lib in ruby |
| 00:49.23 | starseeker | stas: sorry, inside joke |
| 00:49.26 | stas | tries to buy you guys :) |
| 00:49.30 | brlcad | stas: so let me caveat by saying that sounds like a perfectly valid and good proposal to submit regardless and it'd probably get considerable discussion |
| 00:49.53 | brlcad | but now you're talking in terms that matter |
| 00:50.20 | brlcad | rewriting to a different CMS or language or platform by itself isn't very compelling on its own |
| 00:50.31 | brlcad | there should be some compelling tangible benefit |
| 00:50.41 | brlcad | like imminent or demonstrated docbook integration |
| 00:51.37 | stas | the benefit will be that we have some tested and good looking tools |
| 00:52.05 | brlcad | or showing here are the XYZ steps you have to take now, here's the MN steps you have to take later that will save X minutes/hours/days of your life a year from now |
| 00:52.40 | stas | come again :) |
| 00:52.42 | brlcad | drupal is arguably tested too, no? :) |
| 00:52.53 | brlcad | whether it's good looking depends on css fu |
| 00:52.54 | stas | drupal is hardly maintainable |
| 00:52.56 | stas | :) |
| 00:53.12 | brlcad | it's being maintained now (at whatever cost) |
| 00:53.52 | stas | well lets go wordpress than. the point of getting a new tool like ruby in your stack would also be the quality of the code and result |
| 00:54.38 | brlcad | so again, what I just said basically amounts to "prove it" |
| 00:54.44 | brlcad | not by example, but by description |
| 00:55.03 | CIA-128 | BRL-CAD: 03starseeker * r49740 10/brlcad/trunk/misc/CMake/BRLCAD_Summary.cmake: extra line return |
| 00:55.11 | brlcad | the docbook angle is a great one, for example, because that's a high-priority topic |
| 00:55.25 | brlcad | it IS a pain in the ass to integrate docbook with just about everything I know of right now |
| 00:55.32 | brlcad | at least bi-directionally |
| 00:55.54 | stas | you have media wiki right now, right? |
| 00:56.01 | brlcad | so if you could describe a system that provided bidirectional docbook editing, no matter if it was perl scripts and ML code, it'd be very interesting :) |
| 00:56.34 | brlcad | drupal+mediawiki+gallery2 is the current bulk of infrastructure, plus sourceforge services for the development side of things |
| 00:56.58 | stas | yep, thats some php stuff in there |
| 00:57.30 | stas | mediawiki data is plain text basically, that can be converted into docbook |
| 00:57.51 | stas | drupal now, can be integrated through an API |
| 00:58.24 | stas | be that some restful json or xml, and simple editing support can be added |
| 00:58.45 | stas | i think we can even parse html into docbook |
| 00:59.11 | stas | from that point we can have a repository where our tool will commit docbook format |
| 00:59.51 | stas | and a cron job that converts all that stuff in pdf/html or *tex |
| 01:00.21 | stas | sure this is not enough argument to move to ruby, but I saw the other tasks |
| 01:00.33 | stas | and it probably makes more sense |
| 01:02.02 | stas | mostly becase we will need database schema that will likely to change, or some fast prototyping tool for generating all kind of graphs and output formats |
| 01:11.35 | stas | brlcad, if what I wrote makes any sense, I could prepare a more in details list of what and how we can use, some draft proposal |
| 01:15.28 | stas | !ping |
| 01:25.12 | brlcad | sorry, phone call |
| 01:26.10 | brlcad | stas: what you wrote makes sense, but keep in mind that the holy grail is bi-directional editing, which I don't think anyone has working |
| 01:26.54 | brlcad | that's best served as a mediawiki or drupal or whatever plugin that renders the docbook to something, allows editing, but then ALSO unrenders back to docbook for backend review/commit |
| 01:34.45 | brlcad | if you have an idea for that, I'm all ears regardless of language |
| 01:35.27 | stas | brlcad, thanks, I'll do some research. Though so far it still looks like the best option would be to fix drupal and mediawiki |
| 01:36.00 | brlcad | look forward to reading the application(s) ;) |
| 01:36.10 | brlcad | good chances this year for well-developed apps |
| 01:39.08 | stas | not sure yet if i will apply, with php this is pretty straigh, find a format that both media wiki and drupal speaks (probably mediawiki markup +/- html) -> docbook |
| 01:41.26 | stas | mediawiki has an api, that can be used to update content from docbook, and from there its drupal, with the same code as mediawiki to render and edit it |
| 01:43.39 | stas | all that might need tweaking is the cron worker that would need to convert diff into wiki format |
| 01:51.00 | brlcad | stas: it doesn't need to speak to both mw and drupal, just one or the other |
| 01:51.31 | brlcad | the feature we need a bidirectional web editing interface for docbook, the back-end could really be anything |
| 01:52.13 | stas | hmm, sounds more like some sort of wysiwyg in javascript |
| 01:52.17 | brlcad | if you write a solid proposal that involved some language other than php, chances would be very high |
| 01:52.34 | brlcad | s/would/would still/ |
| 01:53.15 | brlcad | it just seems like it'd be an easier task (again to get bidirectionally) using an existing plugin API to something else so it's integrated |
| 01:53.20 | brlcad | not necessary though |
| 01:53.22 | stas | true, but I'm trying to be pragmatic, the tools will end up playing better with php, as those are mediawiki |
| 01:53.47 | brlcad | developer ability is another consideration |
| 01:54.08 | brlcad | we're not invested in php presently, at least not substantially |
| 01:54.30 | brlcad | we're only invested in mediawiki and drupal as a container for data -- user perspective, not development |
| 01:55.06 | brlcad | the only php we have is a plugin I wrote a few years ago that publishes mediawiki changes to CIA and another GSoC project that built a model repository as a set of drupal plugins |
| 01:55.19 | brlcad | neither of which is critical to our core website infrastructure |
| 01:55.27 | brlcad | and easily translated to something else |
| 01:55.30 | stas | so to reformulate, if I could bring a solution for easy editing of docbook files (wysiwyg, preview, review) you would be happy? |
| 01:56.21 | stas | in the end, you wont even need wiki, since static html can be generated |
| 01:56.22 | brlcad | if it was well thought-through, probably very happy |
| 01:56.35 | brlcad | static html can't be edited |
| 01:56.46 | stas | i mean, the tool will produce |
| 01:57.15 | stas | sort of a mediawiki, but with docbook behind |
| 01:57.18 | brlcad | editing can happy directly to the docbook files or ALSO through a web interface, that's part of the bidirectionality desired |
| 01:58.22 | brlcad | keep in mind that there's been docbookwiki ( http://freecode.com/projects/docbookwiki ) around for years but it's insufficient |
| 01:58.30 | brlcad | the editing interface plainly sucks |
| 01:58.47 | brlcad | and is only a subset of docbook iirc |
| 02:00.03 | brlcad | basically a usability fail |
| 02:00.31 | brlcad | the interesting aspect of mediawiki is that you might be able to preserve mw-syntax (which is far better than db) |
| 02:00.43 | brlcad | you don't *really* want your editors to have to care that it's docbook on the backend unless it's strictly necessary (mw syntax dominates usability here, simple) |
| 02:01.43 | brlcad | granted, even showing db tags in a text box is better than nothing ;) |
| 02:07.49 | stas | actually you can preserve mw as the basic format, since both formats speak html, which is more or less "standard" or should be for the compilers/renderers |
| 02:08.31 | starseeker | bear in mind the "canonical" form of our documentation is DocBook, and DocBook->HTML->DocBook is lossy |
| 02:08.41 | stas | also reviving docbookwiki is more like to be a failure, since mw is greatly maintained |
| 02:09.12 | stas | starseeker, true, was just throwing ideas |
| 02:09.35 | stas | we would need a tool that speaks for both formats |
| 02:11.01 | brlcad | if mediawiki were used, you'd want to translate something like http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/docbook/articles/en/about.xml?revision=49740&content-type=text%2Fplain to mw-syntax with docbook properties preserved but hidden |
| 02:11.14 | brlcad | so then you could allow edits but then go back to db without loosing any structure |
| 02:12.28 | brlcad | that's why part why the language is mostly irrelevant -- it's far from being the hardest part of this problem |
| 02:12.44 | brlcad | if a plan is solid, it'll get traction |
| 02:13.13 | starseeker | fwiw - there is an old editor project called qemacs that claimed some WYSIWYG DocBook abilities based on a XML/CSS2 renderer - perhaps that approach would have some useful hints? |
| 02:13.41 | starseeker | http://brlcad.org/~starseeker/qemacs-docbook-mode.png |
| 02:13.50 | starseeker | http://brlcad.org/~starseeker/qemacs-text-mode.png |
| 02:14.04 | starseeker | http://savannah.nongnu.org/projects/qemacs |
| 02:14.10 | stas | starseeker, yep, that approach is probably the only one we should consider, since the tools will end up web anyway |
| 02:14.31 | stas | i'm seriously thinking about a possible javascript library |
| 02:15.19 | stas | unlikely to have full db format support, but with basic and most used attributes |
| 02:15.37 | brlcad | starseeker: any thoughts on which of https://github.com/mpictor/StepClassLibrary/wiki/Gsocideasforstudents we might be interested in? |
| 02:15.59 | brlcad | pulling over the viewer, that's a decent fit |
| 02:17.32 | starseeker | probably don't want to go directly from STEP to Collada - that needs to be staged through an intermediate step, maybe something like the json-based ideas we discussed a while back |
| 02:17.44 | starseeker | doubts that can be scoped for GSoC... |
| 02:19.27 | starseeker | don't really care about python... |
| 02:21.59 | starseeker | even our current clean-up item is a bit tricky because we need to do the merge first... |
| 02:24.38 | stas | ok guys, thanks a lot for chat, i'm gonna get some sleep. |
| 02:36.12 | brlcad | stas: you're welcome -- will look forward to talking/reading more |
| 03:03.22 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3325 10/wiki/Google_Summer_of_Code/Project_Ideas: stub in a STEP viewer from SCL project ideas |
| 03:15.25 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3326 10/wiki/STEP_Viewer: fill in initial details for a step viewer |
| 03:17.10 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3327 10/wiki/Google_Summer_of_Code/Project_Ideas: ws |
| 06:54.59 | *** join/#brlcad Georgiy (4e8bd6a9@gateway/web/freenode/ip.78.139.214.169) | |
| 08:40.09 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:45.03 | brlcad | moin |
| 08:49.20 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 08:49.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:22.59 | CIA-128 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r3328 10/wiki/Talk:Google_Summer_of_Code/Project_Ideas: New page: test |
| 09:23.11 | CIA-128 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r3329 10/wiki/Talk:Google_Summer_of_Code/Project_Ideas: Removing all content from page |
| 09:36.29 | *** join/#brlcad JanC_ (daba13f5@gateway/web/freenode/ip.218.186.19.245) | |
| 09:39.13 | *** join/#brlcad Georgiy (4e8bd6a9@gateway/web/freenode/ip.78.139.214.169) | |
| 09:41.14 | *** join/#brlcad Jan_C (daba13f5@gateway/web/freenode/ip.218.186.19.245) | |
| 09:47.36 | Jan_C | hi is anyone here? im wondering if i should introduce myself here for your gsoc projects? |
| 09:56.11 | d_rossberg | Jan_C: i suspect most people here are still asleep, but they will read your messages as soon as they come back to this forum |
| 09:56.29 | d_rossberg | so don't worre to introduce yourself here |
| 09:58.36 | Jan_C | hehe, you mean don't worry (about) introducing myself? |
| 10:01.26 | d_rossberg | yes |
| 10:02.36 | d_rossberg | another possibility would be the developer mailing list |
| 10:08.50 | Jan_C | well, just as a short intro: im an undergrad, currently persuing two degrees in math and computer science, with some background in modern physics (ie Einstein and after) |
| 10:10.53 | Jan_C | i was kinda surprised that there is actually such a science oriented project in gsoc (the one on bending light), im pretty interested in working on it |
| 10:14.21 | Jan_C | in fact i feel tempted to solve all the gravity problems by writing a library to deal with object in fields, and maybe it can be extended somewhat to electromagnetism |
| 10:21.17 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 10:21.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:26.31 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 10:44.00 | *** join/#brlcad novoman (6d6fb916@gateway/web/freenode/ip.109.111.185.22) | |
| 10:44.48 | *** part/#brlcad novoman (6d6fb916@gateway/web/freenode/ip.109.111.185.22) | |
| 11:28.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:50.46 | brlcad | hello Jan_C |
| 11:51.29 | brlcad | glad to hear that you're interested in our science projects, they are pretty interesting overall |
| 11:52.08 | brlcad | the gravity/physics integration is actually an effort that was started with the european space agency's summer of code in space last year |
| 11:52.33 | brlcad | still some work needed there, but some of the basic infrastructure is in place |
| 11:53.19 | brlcad | our dev that worked on it can probably go into more/better detail on where that effort stands |
| 12:41.54 | Jan_C | hi, regarding the project on simulating celestial gravity, you meant multilevel problems like sun-planets together with planets-moons? |
| 12:50.10 | Jan_C | i had also taken a brief look at the european space agency summer of code submission, correct me on this, but what was done was a new calculation for the next frame was being made each time from the previous frame? |
| 12:54.06 | Jan_C | if that is the case, it might not be possible to apply it for celestial gravity because the gravitational field is not constant as the objects moves within each unit of time in the calculation |
| 13:35.20 | *** join/#brlcad witness123 (~witness@gateway/tor-sasl/witness123) | |
| 13:49.54 | CIA-128 | BRL-CAD: 03brlcad * r49741 10/brlcad/trunk/ (BUGS TODO): report of a bug in the idents command output where the first column region counter is printing wrong. |
| 14:02.27 | brlcad | Jan_C: the field might not be constant, but then it doesn't have to be -- you'd apply a different gravity force each frame (to each object) |
| 14:02.43 | brlcad | but then that's why they're separate projects, rather different dynamics obviously |
| 14:04.02 | brlcad | the issue is mostly usability and integration -- you want a system that users can just turn on/off and have it "do the right thing" regardless of the forces involved |
| 14:04.38 | brlcad | the socis project was just a first step, getting a physics engine actually calculating basic newtonian interactions |
| 14:05.00 | brlcad | excellent progress (some videos available), but still another summer's worth of work to go probably ;) |
| 14:29.48 | ``Erik | one of these days, I'll look over the current bullet integration and try to get it working on my machines O.o :) |
| 14:31.37 | ``Erik | starseeker: ucw/lithp might not be right for that project, it might even be better as perl or tcl O.o ruby is a nice language, though, always liked it more than python |
| 14:32.52 | ``Erik | stas: you said "ruby" and "not rails", do you consider rails to be a 'necessary evil' to gain ruby, or do you use another framework (sinatra, your own)? |
| 14:33.18 | brlcad | ``Erik: the VM image should have everything set up and ready to go |
| 14:34.03 | stas | ``Erik, the only reason I wont use rails in a project that is not very dynamically developed, is that maintainence tasks would require more time than development itself |
| 14:34.30 | ``Erik | brlcad: with bullet integration? I haven't actually been following the effort... I have a few boxes with bullet, but BRL-CAD's cmake doesn't find it, and I haven't tried tweaking anything |
| 14:35.31 | brlcad | ``Erik: yeah, that was one of the pieces I asked tom to install so it would be just ready to go |
| 14:36.29 | stas | in fact, all you would need for, lets say, db storage app, is an orm and rack based framework, but not necessary rails, I would suggest ramaze (plain mvc with rack as only dependency and twice at least less resource consumption) |
| 14:36.48 | ``Erik | stas: yeah, any dynamic sites tend to require extra work to make static versions if they take much traffic... (hitting even a basic rails page with ab is concerning, not sure if big sites like github and groupon throw loads of machines at it or have done 'clever' things) |
| 14:37.25 | stas | well, they pay nice fees to amazon, and have clusters of redis/memcache servers |
| 14:40.03 | ``Erik | I've been programming more functional style than oo (describe with verbs, not nouns), which is at odds with rails... toooo many migration targets, so I kinda moved my focus to ucw :D |
| 14:42.00 | ``Erik | brlcad: cool beans, gives us a place to go to if we can't walk someone through setting up their machine correctly (or have an issue with the cmake files on a different platform that we haven't run into) |
| 14:44.32 | stas | brlcad, I found that http://code.google.com/p/callimachus added some basic docbook editing to wymeditor http://i.imgur.com/BXGGA.png |
| 14:45.35 | ``Erik | (I'll note that the new server already has ruby19, rails, devise, thin, etc. in place, plus the apache proxy module to expose the rails/ruby app as a vhost or dir, with ssh support) |
| 14:45.42 | stas | so, I think we should do a tool like this but for docbook http://showdown.im/ |
| 14:46.11 | stas | ``Erik, what server? |
| 14:46.52 | ``Erik | the machine that brlcad.org will eventually move to |
| 14:50.17 | stas | thats nice, though that woulda been my least problem to solve :) |
| 14:51.38 | ``Erik | heh, yeah, we can install pretty much anything needed on the new machine, the old one is kinda stuck at the moment |
| 15:05.32 | brlcad | stas: that's pretty interesting (bxgga) |
| 15:05.49 | brlcad | looks like it got a few things wrong, but I like the para identification |
| 15:26.45 | starseeker | stas: you were thinking the best way to approach DocBook<->web would be a separate library that could be integrated into multiple frameworks? |
| 15:27.02 | stas | starseeker, exactly, a javascript tool |
| 15:27.12 | stas | since its best suitable for web |
| 15:27.42 | stas | back to backend there can be any language or library that speaks docbook |
| 15:28.07 | starseeker | in principle I like the sound of that - could switch frameworks without having to redo anything except the framework<->javascript integration |
| 15:30.40 | stas | i will do some more research, especially i need to take a look at docbook xml schema, but I'm glad we could find a common-ish point |
| 15:31.51 | brlcad | except you end up coding itn the worst of all available languages ;) |
| 15:34.41 | brlcad | just half-kidding ;) |
| 15:47.00 | stas | brlcad, actually I can't agree more |
| 15:47.01 | stas | :D |
| 15:49.57 | brlcad | so you came complaining about javascript and end up convincing yourself and others that javascript is the way to go, good job! :) |
| 15:50.30 | brlcad | bah, s/about javascript/about php/ |
| 15:50.50 | stas | above all, be that javascript, or php, those are just tools, the final result is what actually matters |
| 15:51.06 | stas | but I can consider flash too :) |
| 15:53.56 | brlcad | clearly you'll need to implement a flash engine in javascript first because adobe's is so unstable |
| 15:55.31 | stas | may I withdraw the flash part I mentioned :) |
| 15:56.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:18.36 | CIA-128 | BRL-CAD: 03starseeker * r49742 10/brlcad/branches/STABLE/ (. src/libtclcad/tclcad_obj.c): Apply 49150 |
| 17:07.59 | Stattrav | There is no -Werror in the makefile but why does it treat warnings as errors ? |
| 17:08.51 | Stattrav | I am using r43163 though |
| 17:09.52 | Stattrav | pulls in the latest from the svn. |
| 17:10.08 | Stattrav | nevermind. |
| 17:18.31 | brlcad | heh |
| 17:22.25 | ``Erik | javascript isn't all that bad, and you can always use something like parenscript or coffeescript to generate it :D |
| 17:34.10 | CIA-128 | BRL-CAD: 03starseeker * r49743 10/brlcad/trunk/CMakeLists.txt: Don't want to change the configure script generated just because we're doing a multi-configuration build... |
| 17:35.44 | starseeker | nothing 6000+ commits couldn't fix... |
| 18:02.28 | stas | :) |
| 19:02.09 | *** join/#brlcad ksuzee (~ksuzee91@46.149.82.166) | |
| 19:10.15 | *** join/#brlcad merzo (~merzo@192-153-201-46.pool.ukrtel.net) | |
| 19:24.55 | *** join/#brlcad andrei (~andrei@188.25.160.226) | |
| 19:28.17 | andrei | Hello , my name is Popescu Andrei and I am a second year undergraduate at Polytechnic University of Bucharest |
| 19:29.07 | andrei | May I ask a few questions about some of the Graphical User Interface projects and Code refactoring projects regarding GsoC and how would that benefit the organisation? |
| 19:29.35 | brlcad | andrei: absolutely |
| 19:30.29 | andrei | Well that might sound really wierd |
| 19:30.31 | brlcad | note that IRC responses are sometimes interactive/instantaneous and sometimes will take a while (maybe a couple hours) before someone responds, but someone does if you're still in the channel |
| 19:30.53 | andrei | but I would be interested in a project that prolonges more than the GsoC period |
| 19:31.31 | brlcad | what's weird about that? :) |
| 19:31.32 | andrei | As the project I choose at GsoC is the first real-deal project I ever attempt |
| 19:31.45 | andrei | I want to be a starting point and also a point to which I could reffer to |
| 19:31.50 | andrei | as doing a good job |
| 19:32.18 | andrei | I noticed the "Impact" Section |
| 19:32.22 | andrei | on your idea's list |
| 19:32.41 | andrei | But which of those projects is of greater importance to you |
| 19:32.52 | brlcad | impact is merely a notion of how many users may be directly affected, not at all a measure of importance or value |
| 19:33.20 | brlcad | if it's an interesting project to you, then it's important |
| 19:34.00 | andrei | Well there are several |
| 19:34.06 | andrei | but I have some limitations unfortunately |
| 19:34.12 | andrei | I only have knowledge of C and Java |
| 19:34.16 | brlcad | the topics up there are actually but a tiny subset of things one would work on |
| 19:34.31 | brlcad | they're up there because they're all very desirable |
| 19:34.53 | brlcad | several to you, perhaps, but not to us ;) |
| 19:35.11 | brlcad | see our TODO file and you'll find a couple hundred more ideas |
| 19:35.15 | andrei | For example |
| 19:35.26 | andrei | The Visualizing Constructuive Solid Geometry |
| 19:35.38 | brlcad | probably another hundred or two here: http://brlcad.org/~sean/ideas.html |
| 19:36.08 | *** join/#brlcad ksuzee_ (2e9552a6@gateway/web/freenode/ip.46.149.82.166) | |
| 19:36.31 | andrei | I curently work on a smaller scale project, that was assigned to us by university, which is the Google Ai challange replica |
| 19:36.39 | brlcad | at the bottom of that last one are projects that each would take anywhere from 6 months to 6 years to complete ;) |
| 19:37.07 | brlcad | okay, neat -- is it open source? |
| 19:37.38 | andrei | Well , not really , but it s a larger project |
| 19:37.46 | andrei | that familiarizes us with tools such as git hub |
| 19:39.08 | andrei | hmm :) |
| 19:39.46 | brlcad | if it's on github, it's probably open source... |
| 19:39.58 | andrei | well |
| 19:39.59 | brlcad | doesn't matter |
| 19:40.11 | andrei | I didn't say it's open source because it doesn't really serve a purpose |
| 19:40.17 | andrei | aside of educational purposes that is |
| 19:40.25 | brlcad | purpose has nothing to do with it |
| 19:40.48 | brlcad | if it's code, it's under some form of rights management, license, or contract |
| 19:41.07 | andrei | I am familiar with the open source project |
| 19:41.11 | andrei | I mean |
| 19:41.14 | andrei | philosophy |
| 19:42.19 | brlcad | so then you should know if the code was published or not no? :) |
| 19:42.32 | brlcad | is it available online somewhere? |
| 19:43.09 | andrei | The code is entirely written by me and three teammates , I will post it on github in two or three days |
| 19:43.40 | andrei | Anyway |
| 19:43.47 | andrei | resuming to Visualizing Constructive Solid Geometry (CSG) |
| 19:44.13 | brlcad | drastically different from the refactoring projects .. what draws you to that idea? |
| 19:44.27 | andrei | Well |
| 19:44.36 | andrei | In highschool I used to help my physics teacher |
| 19:44.45 | andrei | develop small E-learning lessons |
| 19:45.09 | andrei | Using Macromedia Flash |
| 19:46.42 | brlcad | so you see this as similarly helping users learn and visualize their data |
| 19:46.50 | andrei | Indeed |
| 19:47.23 | brlcad | so what did you have in mind? |
| 19:48.26 | andrei | Well |
| 19:48.43 | andrei | I have used a few days ago the NS tool to review how a small network is working |
| 19:48.45 | andrei | and transfering data |
| 19:51.37 | andrei | I am trying to get familiarized with Tcl / Tk |
| 19:52.01 | andrei | and probably I don't really have a good enough vision |
| 19:52.04 | andrei | about what should I do |
| 19:53.01 | brlcad | fair enough |
| 19:53.31 | andrei | Actually I m looking over Graphviz |
| 19:53.36 | brlcad | we certainly have plenty of ideas on the topic, of course, and can discuss it in-depth but it is a tricky project to cut one's teeth on it |
| 19:53.57 | brlcad | have you used our graphiz exporter yet? |
| 19:54.49 | andrei | I haven't done it so far , unfortunately |
| 19:54.57 | andrei | I m trying to do that now |
| 19:55.19 | brlcad | It's a simple little program, limited options, but does the trick and will show you a hierarchy |
| 19:55.45 | brlcad | doesn't have a GUI though or any means of editing the graph (other than cracking out a text editor to change the dot file) |
| 19:58.41 | andrei | I have Ubuntu 11.10 at the moment |
| 19:59.01 | andrei | I might be wrong but , is the program available for this distribution? |
| 19:59.15 | andrei | I have ran sudo apt-get install graphviz and it seemed to have been installed |
| 20:02.58 | andrei | I'm going to have a closer look to the documentation |
| 20:03.01 | andrei | as I m a bit confused |
| 20:05.22 | brlcad | is what program available? |
| 20:06.51 | andrei | <PROTECTED> |
| 20:06.54 | andrei | the brlcad toolkit |
| 20:07.36 | brlcad | brl-cad is not a program (or a toolkit) .. it's a suite of applications (hundreds) |
| 20:08.37 | brlcad | one thing that might help you |
| 20:08.52 | brlcad | this year we've put together a virtual machine already fully pre-configured |
| 20:09.49 | brlcad | if you download/install VirtualBox, you'll be able to load and run this disk image: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Virtual%20Machines/ |
| 20:09.59 | brlcad | you'll need about 6GB of disk space free |
| 20:10.07 | brlcad | but everything you need is in there |
| 20:10.15 | andrei | Thank you :) I really appreciate it |
| 20:10.20 | andrei | I'm sorry for seeming a bit lost |
| 20:10.47 | brlcad | understandable, it's a lot to take in |
| 20:11.37 | brlcad | given the complexity, you may end up being more interested in one of the refactoring tasks regardless |
| 20:11.47 | brlcad | that's one of the best ways to become familiarized with code |
| 20:11.54 | brlcad | for any project |
| 20:12.22 | andrei | Hmm |
| 20:14.08 | andrei | I appologise beforehand if I will be or seem to be annoying, it is certainly not my intention |
| 20:14.45 | brlcad | not annoying :) |
| 20:14.50 | andrei | the reason I have set eyes on a "bit harder" project is from 8th of June( When I finish my exam session) until 1st of October |
| 20:14.57 | andrei | I have absolutely no comitments at all |
| 20:15.19 | brlcad | our code base is more than a million lines of code |
| 20:15.27 | brlcad | you could spend years refactoring and still have years to go |
| 20:15.31 | andrei | indeed |
| 20:15.45 | brlcad | and refactoring doesn't imply easy |
| 20:15.53 | brlcad | it's just a good way to get introduced to code |
| 20:16.19 | brlcad | some refactoring is exceptionally hard, especially to do bug-free and without introducing bad API |
| 20:16.39 | andrei | so what you mean is that's a good way to start working with your organisation |
| 20:17.01 | brlcad | gotta run, but there aer other folks in there that can answer other questions too (and the mailing list of course, for more thought-through questions or introductions) |
| 20:17.14 | brlcad | good way to start working with any org ;) |
| 20:17.44 | andrei | Goodbye ! Then I will probably have a better look |
| 20:17.48 | andrei | at the code refactoring projects |
| 20:18.00 | andrei | Thank you for the really helpful advice |
| 20:46.32 | Jan_C | hi, regarding the idea of solving for motion through space by getting a different force acting on the object, in practice it would be problematic because there is no guarentee that the planet would stay in orbit |
| 20:48.19 | Jan_C | if done mathematically with frames close to each other, then that would draw out a more accurate orbit, however thats only with arbituary precision values, if done with float, that would only compound the problem |
| 20:52.57 | Jan_C | i would propose a whole different approach to the problem from physics equations but that would involve tracing out predefined paths, of course theres no reason why we cant have both and compare the difference |
| 20:56.07 | *** join/#brlcad stas (~stas@188.24.46.106) | |
| 21:01.19 | andrei | Goodnight everyone, will look better into the Virtual machine in the morning |
| 21:01.21 | andrei | :) |
| 21:23.51 | CIA-128 | BRL-CAD: 03starseeker * r49744 10/brlcad/trunk/ (3 files in 3 dirs): Hrm. CMAKE_CFG_INTDIR doesn't work for the install command, apparently - http://www.cmake.org/Bug/view.php?id=5747 - start experimenting... |
| 21:45.41 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 21:46.43 | stas | do you guys usually are popular around romanian students? :) |
| 21:52.12 | *** join/#brlcad witness123 (~witness@14.139.228.210) | |
| 22:34.54 | CIA-128 | BRL-CAD: 03starseeker * r49745 10/brlcad/trunk/ (misc/CMakeLists.txt src/other/libtermlib/CMakeLists.txt): |
| 22:34.54 | CIA-128 | BRL-CAD: Stray changes needed for Multi-configuration build tool installation rules. |
| 22:34.54 | CIA-128 | BRL-CAD: Xcode now successfully installs a build of BRL-CAD. Still doesn't run from that |
| 22:34.54 | CIA-128 | BRL-CAD: installed directory, looks like something wrong with Tcl index file |
| 22:34.54 | CIA-128 | BRL-CAD: generation... |
| 22:53.57 | *** part/#brlcad ksuzee (~ksuzee91@46.149.82.166) | |
| 22:56.43 | *** join/#brlcad witness123 (~witness@14.139.228.210) | |
| 22:59.40 | CIA-128 | BRL-CAD: 03starseeker * r49746 10/brlcad/trunk/misc/CMake/TCL_PKGINDEX.cmake: Fix TCL_PKGINDEX in multi-config cases. Gets archer working from install - mged still can't read 'version' variable. |
