| 01:20.46 | CIA-62 | BRL-CAD: 03brlcad * r45109 10/brlcad/trunk/include/bu.h: prefix all doxygen file markers with the library they belong to in order to avoid conflicts with same-named files in other directories being processed simultaneously. |
| 02:10.22 | CIA-62 | BRL-CAD: 03brlcad * r45110 10/brlcad/trunk/include/bu.h: this file isn't in the libbu dir |
| 02:11.22 | CIA-62 | BRL-CAD: 03brlcad * r45111 10/brlcad/trunk/src/libbn/ (22 files): prefix all of the doxygen file commands with libbn so we don't conflict with same-named files in other directories |
| 02:22.22 | CIA-62 | BRL-CAD: 03brlcad * r45112 10/brlcad/trunk/src/ (425 files in 15 dirs): prefix all of the library @file doxygen commands with the library dir/name in order to avoid conflicts with same-named files in other directories. was causing processing woes. |
| 02:26.07 | CIA-62 | BRL-CAD: 03brlcad * r45113 10/brlcad/trunk/src/ (168 files in 5 dirs): more @file prefixing in order to deconfuse doxygen bulk processing where file names are non-unique. |
| 02:40.31 | CIA-62 | BRL-CAD: 03brlcad * r45114 10/brlcad/trunk/src/ (469 files in 10 dirs): more @file directive clarification for doxygen to avoid naming conflicts with other same-named files in other directories. |
| 02:43.38 | CIA-62 | BRL-CAD: 03brlcad * r45115 10/brlcad/trunk/src/ (59 files in 3 dirs): few more @file doxygen conflict cases |
| 02:44.14 | CIA-62 | BRL-CAD: 03brlcad * r45116 10/brlcad/trunk/src/proc-db/brep_cube.cpp: proper header |
| 03:13.07 | CIA-62 | BRL-CAD: 03brlcad * r45117 10/brlcad/trunk/src/proc-db/ (brep_cube.cpp brep_simple.cpp csgbrep.cpp): header cleanup, refer to the proper filename |
| 03:17.22 | CIA-62 | BRL-CAD: 03brlcad * r45118 10/brlcad/trunk/src/vfont/vfont.h: filename is vfont |
| 03:21.09 | CIA-62 | BRL-CAD: 03brlcad * r45119 10/brlcad/trunk/include/vector_fpu.h: add missing common.h include for UNUSED() definition. |
| 03:25.55 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 07:02.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 08:16.14 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 09:05.10 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) |
| 09:05.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 10:56.20 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2924 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ |
| 10:57.57 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2925 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ updated timeline |
| 14:28.53 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 14:37.35 | *** join/#brlcad Stattrav (~Stattrav@117.192.151.196) |
| 14:37.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 14:50.11 | CIA-62 | BRL-CAD: 03erikgreenwald * r45120 10/brlcad/trunk/include/raytrace.h: Some parsers freak out when they see */*stp*/, thinking it's an end of comment. Adding a space seems to make them happy. |
| 15:11.48 | brlcad | wb |
| 15:12.31 | ``Erik | yargh |
| 15:12.43 | ``Erik | vacations never last long enough. :/ |
| 15:22.20 | CIA-62 | BRL-CAD: 03brlcad * r45121 10/brlcad/trunk/src/ (52 files in 7 dirs): (log message trimmed) |
| 15:22.20 | CIA-62 | BRL-CAD: remove the SCLLOG/SCLBOOL wrappers on the SCL Boolean and Logical enums. they |
| 15:22.20 | CIA-62 | BRL-CAD: were being conditionally put into a namespace in order to be protected in case |
| 15:22.20 | CIA-62 | BRL-CAD: they're used within a 3rd party context (like CORBA) that might also define |
| 15:22.20 | CIA-62 | BRL-CAD: same-named enums, but the macrofied protection just adds complexity. iff a |
| 15:22.21 | CIA-62 | BRL-CAD: conflict is encountered, the types can be put into an SCL or P23 or SDAI |
| 15:22.22 | CIA-62 | BRL-CAD: namespace. 'Boolean' would be prime for outright removal/replacement with |
| 15:22.36 | brlcad | kunigami: make sure all files you add have a proper header and footer, e.g.: sh/header.sh lgpl src/liboptical/osl-renderer.cpp |
| 15:23.30 | brlcad | sh/header.sh, sh/footer.sh, or sh/template.sh (to apply both header and footer) |
| 15:23.58 | brlcad | sh/ws.sh and sh/indent.sh will clean up the formatting so it's consistent with the rest of the source code |
| 15:24.50 | brlcad | just make sure any cleanup commits aren't mixed with actual code/logic changes |
| 15:40.15 | CIA-62 | BRL-CAD: 03kunigami * r45122 10/brlcad/trunk/src/liboptical/osl-renderer.cpp: Cleaning up formatting of osl-renderer.cpp |
| 15:50.21 | CIA-62 | BRL-CAD: 03erikgreenwald * r45123 10/brlcad/trunk/src/other/m4/lib/ohash.h: include sys/types.h for u_int32_t |
| 16:28.43 | CIA-62 | BRL-CAD: 03starseeker * r45124 10/brlcad/trunk/src/other/m4/ (eval.c gnum4.c main.c misc.c): Try the BRL-CAD wrapper for unistd.h here... |
| 16:31.10 | kunigami | when I run indent with osl-renderer.h it changes spacing to 2 while in osl-renderer.cpp it keeps 4. it that the default? |
| 16:34.11 | kunigami | hmm, actually I'd rather ask why footer.sh does not add "c-basic-offset: 4" line? |
| 16:48.32 | CIA-62 | BRL-CAD: 03starseeker * r45125 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: Hmm - MSVC doesn't like __P for some reason. |
| 16:49.32 | CIA-62 | BRL-CAD: 03kunigami * r45126 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h osl_rt.cpp osl_rt2.c): formatting changes for several files |
| 16:50.21 | CIA-62 | BRL-CAD: 03starseeker * r45127 10/brlcad/trunk/src/other/m4/generated/tokenizer.c: one more unistd.h case |
| 16:52.44 | CIA-62 | BRL-CAD: 03kunigami * r45128 10/brlcad/trunk/src/liboptical/osl-renderer.cpp: typo on osl-renderer.cpp local variables |
| 16:53.23 | brlcad | starseeker: egads man |
| 16:53.56 | brlcad | if you had to paste it just twice .. should've been a hint to refactor :) |
| 16:54.21 | brlcad | put that mess into a header and just #include it... |
| 16:57.27 | brlcad | I know you're just trying to "get it to work" .. but egads .. that's passing the buck and really making more work for later |
| 16:59.35 | CIA-62 | BRL-CAD: 03starseeker * r45129 10/brlcad/trunk/src/other/m4/ (eval.c extern.h gnum4.c main.c mdef.h): Remove the doesyscmd option from the m4 logic. May have to revisit this if it turns out later we need it, but this will be problematic on Win32. |
| 17:00.45 | brlcad | also, fwiw, __P is undoubtedly defined like BU_ARGS() used to be .. it makes the parameter list conditional |
| 17:01.17 | brlcad | the __P protection belongs where it's defined, not where it was used in libyywrap.c |
| 17:04.43 | CIA-62 | BRL-CAD: 03starseeker * r45130 10/brlcad/trunk/src/other/m4/ (14 files in 2 dirs): |
| 17:04.43 | CIA-62 | BRL-CAD: Hack, slash and burn approach to MSVC building - this has lots of unresolved |
| 17:04.43 | CIA-62 | BRL-CAD: external symbols and may not function at all anywhere, but it should indicate |
| 17:04.43 | CIA-62 | BRL-CAD: what further changes are needed. Will also need regex linked in, need to take |
| 17:04.43 | CIA-62 | BRL-CAD: care of that. |
| 17:05.02 | brlcad | kunigami: c-file-style: "Stroustrup" sets 4-char indents |
| 17:06.27 | starseeker | brlcad: oh, I know - I've got a lot of refactoring to do - I'm just trying to get a feel for the scope of what's needed |
| 17:06.37 | kunigami | that's strange. even with that line indent.sh used 2 spaces. When I added c-basic-offset:4 it correclty used 4 |
| 17:07.00 | starseeker | brlcad: it wasn't immediately clear how deep into "unixy" coding this m4 was |
| 17:10.02 | CIA-62 | BRL-CAD: 03brlcad * r45131 10/brlcad/trunk/src/liboptical/osl-renderer.h: restructure around a WITH_OSL keyword instead of __cplusplus since it should always be possible to compile the sh_osl C interface. |
| 17:11.07 | brlcad | starseeker: http://gnuwin32.sourceforge.net/packages/m4.htm |
| 17:11.50 | brlcad | enough to warrant someone making a fork instead of trying to make it portable |
| 17:11.57 | brlcad | but then that could have just been laziness or simplicity |
| 17:12.14 | starseeker | nods - yeah, saw that - but this isn't GNU m4 |
| 17:12.25 | starseeker | it's the netbsd port of the openbsd m4 |
| 17:12.41 | starseeker | was going for the smallest m4 that looked like it might have a hope of working with flex |
| 17:12.55 | starseeker | both for build simplicity/porting simplicity and to keep the size of src/other smaller :-P |
| 17:13.25 | starseeker | so far this feels a lot like working with the find code for the search command |
| 17:13.54 | kunigami | brlcad: I didn't understand your changes to osl-renderer.h. It was already possible to compile with sh_osl C interface. |
| 17:14.34 | brlcad | if we really wanted simplicity and a small src/other, we'd just generate the files, add them to svn, and compile those on windows :) |
| 17:14.39 | CIA-62 | BRL-CAD: 03starseeker * r45132 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: Ah, that's why cdefs was included here. Win32 doesn't have cdefs, so be more direct... |
| 17:15.02 | brlcad | way more simple than these 3-4 new dependencies, build system mods, maintenance woes |
| 17:15.20 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) |
| 17:15.21 | kunigami | the reason for __cplusplus was that C++ code would see a different interface than C code |
| 17:16.31 | brlcad | kunigami: which C++ code? |
| 17:16.56 | kunigami | brlcad: osl-renderer.cpp which is an interface to osl system |
| 17:17.25 | kunigami | both osl-renderer.cpp and sh_osl.c share the interface osl-renderer.h |
| 17:18.05 | brlcad | iirc, technically doesn' sh_osl.c only "share" the inteface via the C callbacks declared at the bottom of osl-renderer.h? |
| 17:18.26 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) |
| 17:18.26 | brlcad | it's "declare class" or "declare typedefs and C funcs" |
| 17:18.31 | yukonbob | hello, #brlcad |
| 17:18.41 | brlcad | rather, it was |
| 17:18.46 | brlcad | hello yukonbob |
| 17:19.26 | brlcad | kunigami: something to consider, sh_osl doesn't have to be C -- it can be a C++ file |
| 17:19.55 | brlcad | so you can call right into osl-renderer.h classes |
| 17:20.17 | brlcad | the only protection really necessary is whether we have OSL or not |
| 17:21.18 | brlcad | that was the motivation, move towards blocking based on the build feature, since the compilation of the interface file is already built-in |
| 17:22.35 | kunigami | I'm not sure if I understood what you meant, but when OSL is not enabled, osl-renderer.h is not even compiled. |
| 17:23.42 | brlcad | right, it's either on and OSL is available or it's off |
| 17:23.51 | brlcad | sh_osl.c doesn't get compiled if it's off, right? |
| 17:23.56 | kunigami | yup |
| 17:24.10 | kunigami | I added a conditional on CMakeLists.txt |
| 17:24.28 | brlcad | so then if it's only on when osl is compiled, and osl is c++, then sh_osl can be c++ |
| 17:24.41 | brlcad | and the c wrapping isn't needed |
| 17:25.07 | brlcad | just adds complexity and code that won't ever get executed/used |
| 17:25.22 | brlcad | make sense? |
| 17:25.32 | kunigami | brlcad: right. I didn't know that sh_osl could be c++. |
| 17:26.01 | brlcad | yep, you could svn mv sh_osl.c sh_osl.cpp if you really wanted |
| 17:26.18 | brlcad | the only important part is that C++ types aren't publicly exposed by liboptical |
| 17:26.56 | brlcad | so if you find yourself needing to add a C++ class / typedef into a header file in the top-level include/ directory, then it might be an issue and require some rethought |
| 17:27.24 | kunigami | but if sh_osl is C++ then I'll have to export functions using "extern C" anyway, because AFAIK C++ exports mangled functions names |
| 17:27.52 | brlcad | sure, if you call C functions |
| 17:28.11 | brlcad | and call them outside that compilation unit |
| 17:28.43 | brlcad | the c functions you had looked like logic that wouldn't need to live in osl-renderer, they'd just be part of the logic in sh_osl.c |
| 17:28.47 | brlcad | er sh_osl.cpp |
| 17:29.24 | brlcad | i.e., you don't need wrappers, you'd just create OSL_Renderer objects and use them |
| 17:29.44 | kunigami | perfect |
| 17:29.50 | kunigami | I'll give it a try |
| 17:30.32 | brlcad | at most, you'd maybe have to stash an OSL_Renderer* object into a struct so you could pass it around as a void* through the various liboptical callback functions |
| 17:30.42 | brlcad | (the 'dpp' parameter) |
| 17:30.56 | brlcad | that's a user data pointer |
| 17:31.22 | brlcad | and that's only because c++ forbids casting objects through void*, have to stash in struct and cast the struct through void* |
| 17:32.00 | brlcad | make sure you quell all warnings ;) |
| 17:32.44 | kunigami | right |
| 17:34.35 | brlcad | starseeker: those big repeated code blocks are more a mentality issue, not letting yourself create extra work in the first place |
| 17:35.14 | *** join/#brlcad crazy_imp (~mj@a89-182-170-199.net-htp.de) |
| 17:35.56 | brlcad | plus, i've heard you say something to the effect of "I've got a lot of refactoring to do" |
| 17:35.59 | brlcad | with plans to clean some bit of code up "later" on at least three other occasions now :D |
| 17:36.24 | brlcad | and that "later" never manifested itself |
| 17:36.54 | brlcad | code complete, deep not wide |
| 17:45.04 | brlcad | kunigami: not sure about the 2 vs 4 indents -- maybe something in your .emacs file? if I move mine out of the way, I get 4char indents |
| 17:45.10 | CIA-62 | BRL-CAD: 03starseeker * r45133 10/brlcad/trunk/src/other/m4/ (common.h eval.c gnum4.c main.c misc.c pstdint.h): move unistd.h wrapper to common file, add portability guarantee with pstdint.h |
| 17:52.33 | CIA-62 | BRL-CAD: 03starseeker * r45134 10/brlcad/trunk/src/other/m4/ (expr.c look.c trace.c): Replace a few direct calls to stdint.h |
| 17:53.40 | CIA-62 | BRL-CAD: 03brlcad * r45135 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: even simpler, it's a preansiism |
| 17:59.14 | CIA-62 | BRL-CAD: 03starseeker * r45136 10/brlcad/trunk/src/other/m4/ (generated/tokenizer.c parser.y tokenizer.l): Ah, hiding in the tokenizer. Should get us down to the regex header. |
| 18:00.44 | CIA-62 | BRL-CAD: 03starseeker * r45137 10/brlcad/trunk/src/other/m4/lib/ohash_int.h: Nope, one more - ohash |
| 18:05.46 | CIA-62 | BRL-CAD: 03erikgreenwald * r45138 10/brlcad/trunk/src/other/m4/generated/parser.c: remove stdint.h in favor of common.h/pstdint.h |
| 18:06.49 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) |
| 18:09.59 | CIA-62 | BRL-CAD: 03starseeker * r45139 10/brlcad/trunk/src/other/m4/ (CMake/ CMake/FindREGEX.cmake CMakeLists.txt): Add logic to locate and link in regex library. |
| 18:14.20 | brlcad | starseeker: so how's the prognosis looking ... have a thought that might make the effort somewhat moot |
| 18:14.32 | starseeker | brlcad: not bad, actually |
| 18:14.36 | starseeker | at least, not so far |
| 18:14.41 | starseeker | what's the though? |
| 18:15.10 | brlcad | ditch lex/yacc for antlr |
| 18:15.10 | CIA-62 | BRL-CAD: 03starseeker * r45140 10/brlcad/trunk/src/other/m4/CMakeLists.txt: Dur - try linking the library, not compiling it. |
| 18:15.26 | brlcad | it's half the code side and supports windows |
| 18:15.42 | starseeker | huh, never heard of it before |
| 18:15.43 | brlcad | but would require rewriting our few existing lex/yacc files in their syntax (which is nearly identical) |
| 18:15.50 | starseeker | reads... |
| 18:17.03 | starseeker | brlcad: it's java based? |
| 18:18.24 | starseeker | or are you looking at the C runtime distributions? |
| 18:19.01 | brlcad | http://www.antlr.org/wiki/display/ANTLR3/Five+minute+introduction+to+ANTLR+3 |
| 18:23.03 | brlcad | another tutorial: http://supportweb.cs.bham.ac.uk/docs/tutorials/docsystem/build/tutorials/antlr/antlr.html |
| 18:23.53 | starseeker | don't we need java to run antlr and generate the code though? |
| 18:26.13 | brlcad | either hook in the java binary (which we could probably bundle precompiled if it's small enough), or compile them via the C runtime (which is about 25k lines of code, about the size of flex) |
| 18:27.03 | brlcad | if I'm understanding their setup correctly, that would even be more ideal than the lex/yacc approach for things like libgcv where we just want the parsing functions, not a main() |
| 18:28.06 | brlcad | of course, the java app may still be required to compile the functions and then the C runtime to use them, not 100% sure on that detail |
| 18:28.13 | starseeker | I'm trying to figure out if the runtime can eat the grammer and execute code, or if you still need the java tools to generate the code |
| 18:28.17 | starseeker | er, yeah :-) |
| 18:29.51 | starseeker | I'm thinking you need java to compile the grammar - I just built libantlr3c and there's no tool I can see to generate C code... |
| 18:30.34 | starseeker | I did a survey a while back looking for lex/yacc alternatives that were in C and I remember coming up rather short... |
| 18:33.12 | starseeker | hmm... |
| 18:33.26 | starseeker | brlcad: maybe http://www.hwaci.com/sw/lemon/ ? |
| 18:35.06 | starseeker | if we're willing to rewrite our definitions, that might be a way to go |
| 18:35.54 | *** join/#brlcad crazy_imp (~mj@a89-182-141-171.net-htp.de) |
| 18:36.25 | kunigami | I didn't know in C it's allowed to set a function like "void foo(int x)" to a function pointer "void (*fp)()". In C++ it seems it is not allowed. Any suggestions? |
| 18:36.55 | brlcad | starseeker: it'd be worth giving it a try, maybe start with the simple parser in src/mged/points |
| 18:37.42 | brlcad | that's a prime simple test case for conversion, if it works, that'd probably be good enough proof of concept to run forward with it |
| 18:39.09 | brlcad | not nearly as complicated as the others |
| 18:39.23 | starseeker | nods - sounds good |
| 18:39.24 | brlcad | kunigami: I'm working on fixing that right now |
| 18:39.39 | brlcad | kunigami: that's an old carry-over from k&r days of C |
| 18:39.57 | kunigami | brlcad: ok, thanks! |
| 18:42.11 | brlcad | c++ has the same behavior as the concept of "calling a function" in either is as simple as jumping to a pointer address |
| 18:42.39 | brlcad | it just adds type safety during compilation so it can enforce only jumping to a "compatible" address |
| 18:44.07 | yukonbob | starseeker: what are you looking for lex/yacc alternatives for? |
| 18:44.34 | brlcad | C will happily jump to whatever you ask, compiler won't even warn by default unless you ask it to |
| 18:44.47 | kunigami | hmm interesting |
| 18:45.08 | starseeker | yukonbob: we need to be able to handle a (potentially large) number of grammar definitions for geometry format conversion (and other uses, like MGED's point abilities) |
| 18:45.35 | starseeker | we also need to be portable, and (right now) recent flex versions aren't working on Windows |
| 18:45.46 | yukonbob | starseeker: and lex/yacc are unsuitable for some reason? |
| 18:45.48 | starseeker | we also need something that's LGPL-or-freer |
| 18:45.51 | yukonbob | ah |
| 18:46.07 | yukonbob | checks. |
| 18:46.14 | starseeker | The best combination I had come up with so far was the netbsd m4 + byacc + flex |
| 18:46.21 | brlcad | license compatible and portable to windows .. good luck ;) |
| 18:46.21 | starseeker | but that'll have to be ported to Windows |
| 18:46.47 | yukonbob | heh -- that's what I was just looking up. |
| 18:47.04 | yukonbob | NetBSD runs everything, even if it's not. |
| 18:47.13 | yukonbob | ;) |
| 18:47.29 | starseeker | the commits you saw earlier were me and ``Erik getting NetBSD's m4 compiling on MSVC |
| 18:47.59 | starseeker | as long as we don't have to run system commands, it doesn't look too bad - mostly just need to swat all the uses of err, warnx, etc. |
| 18:48.45 | starseeker | flex will be a bit trickier, since it wants to run m4 from within it's own source code (ick) |
| 18:49.09 | yukonbob | starseeker: like exec("m4"...");? |
| 18:49.10 | starseeker | fortunately we just need to run 'em during build, and don't have to install them |
| 18:49.23 | starseeker | pretty much |
| 18:49.27 | yukonbob | sweet. |
| 18:50.38 | starseeker | byacc I'm more hopeful about - the dev was very helpful and added a couple Bison features to get our libobj examples working |
| 18:50.55 | starseeker | but of course that too is untried on Windows |
| 18:51.16 | starseeker | yukonbob: if you know of something less gnarly we'd LOVE to hear about it :-P |
| 18:51.16 | yukonbob | starseeker: I haven't worked w/ flex/yacc in ages, but aren't their artifacts just .c and .h? Considered just generating those on a *nix and shipping those artifacts as part of the repo? |
| 18:51.47 | starseeker | yukonbob: the problem with that is the grammar definitions are what you edit during the development process |
| 18:52.17 | starseeker | we want potential developers to edit the source, type "make" (or do the MSVC thing on Windows) and have it Just Work |
| 18:52.50 | yukonbob | ya -- my suggestion is certainly non-elegant in that regard. |
| 18:52.51 | starseeker | the temptation when you have generated source files is to tweak those files and not the original grammar definitions, which very quickly divorces the code (and fixes) from what should be the canonical source code |
| 18:53.28 | yukonbob | inlucde a comment "Edit this code under threat of death as punishment"... |
| 18:53.34 | starseeker | a geometry conversion library may potentially grow to have dozens of grammars that need to be handled, and that will be quite a job even if we AREN'T having to worry about syncing back and forth |
| 18:53.46 | starseeker | heh |
| 18:54.10 | starseeker | that's a great way to encourage contributions :-P |
| 18:54.35 | yukonbob | starseeker: anybody who's able to contribute to a lexer/parser will know what it means. |
| 18:55.12 | yukonbob | but meh... best case is a truly portable lex/yacc |
| 18:55.25 | starseeker | yukonbob: if we're building just the sources though, new devs may head straight for the sources to fix a problem |
| 18:55.37 | starseeker | would probably do that, without knowing better |
| 18:55.56 | starseeker | and would probably run screaming :-P |
| 18:57.45 | yukonbob | starseeker: is your list of candidates posted anywhere?| |
| 18:57.49 | starseeker | because the lex/yacc or whatever files are the "user editable" form of the logic, we also want to make sure they continue to work and don't "bit rot" - if the C files work, but no one has done the generation in a few years, who knows what may have gone wrong next time we NEED to do the generation? |
| 18:57.59 | starseeker | yukonbob: uh - src/other? :-P |
| 18:58.12 | starseeker | will make a wiki page quick... |
| 19:05.59 | yukonbob | starseeker: re: bit rot -- build is automated for producing various binaries, no? |
| 19:07.22 | starseeker | er, huh? |
| 19:07.56 | yukonbob | on major releases, you have a system that generates binaries, no? |
| 19:08.15 | starseeker | Oh, you mean binary releases? yeah |
| 19:09.21 | yukonbob | so for case of ppl tweaking lex/yacc artifacts and not being able to actually produce them canonically, that'd be tested periodically w/ testing for formal releases... |
| 19:09.58 | yukonbob | should stop worrying about project-wide builds and see if his NetBSD build still stands up to latests sources... |
| 19:10.01 | starseeker | yukonbob: but if it's not integrated into our build, it becomes an extra overhead/step that consumes developer time (a lot of it, over the long pull) |
| 19:18.34 | yukonbob | ! -- this has bumped 2 minor versions since I last checked... |
| 19:21.07 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2926 10/wiki/Lexer_Parser: Stub in a page for discussing lexers/parsers |
| 19:21.48 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2927 10/wiki/Lexer_Parser: |
| 19:26.08 | starseeker | hmm - re2c actually might be interesting |
| 19:28.20 | starseeker | http://lekernel.net/blog/2009/02/re2c-and-lemon-an-elegant-alternative-to-flex-and-bison/ |
| 19:31.20 | starseeker | O.o apparently someone is building re2c on MSVC? |
| 19:31.52 | yukonbob | familiar w/ lemon, but not re2c |
| 19:32.11 | starseeker | yukonbob: what do you think of lemon? |
| 19:35.16 | yukonbob | likes things that come from drh |
| 19:35.24 | starseeker | yukonbob: know anything about styx? http://speculate.de/ |
| 19:35.58 | yukonbob | like I said, I haven't played in that domain for a while, but conceptually, lemon is nice, and is thoroughly tested via sqlite |
| 19:36.20 | starseeker | huh - styx has Express (from STEP) as an example grammar |
| 19:36.26 | yukonbob | likes this "non statement" in the re2c: |
| 19:36.33 | yukonbob | "...equal to hand-written code in terms of size, speed and quality." |
| 19:36.43 | yukonbob | *re2c site.. |
| 19:37.25 | yukonbob | my understanding w/ parser code is that rolling your own is often error-prone, difficult, often inefficient, etc., etc. |
| 19:38.09 | starseeker | heh - if I read that right, it dates back to when people were hand-tuning code due to machine speed constraints |
| 19:38.35 | yukonbob | ya -- /me just getting into site, so may be pulling out of context, but still made me chuckle. |
| 19:39.24 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2928 10/wiki/Lexer_Parser: Add a few more notes |
| 19:39.37 | yukonbob | heh -- oh, and holding up PHP as a flagship project... |
| 19:42.50 | starseeker | still - if it doesn't need m4 and already builds on Windows... |
| 19:46.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 19:46.44 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2929 10/wiki/Lexer_Parser: not links |
| 19:53.59 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2930 10/wiki/Lexer_Parser: Few more comments on re2c, link to example using lemon |
| 20:30.13 | CIA-62 | BRL-CAD: 03erikgreenwald * r45141 10/brlcad/trunk/src/other/m4/ (14 files in 3 dirs): rename common.h to commonm4.h, as our regex.h requires include/common.h |
| 20:30.30 | starseeker | nods - good catch |
| 20:38.08 | CIA-62 | BRL-CAD: 03erikgreenwald * r45142 10/brlcad/trunk/src/other/m4/ (gnum4.c main.c misc.c): errx->m4errx |
| 20:40.06 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2931 10/wiki/Lexer_Parser: Add notes on Antlr |
| 20:48.17 | CIA-62 | BRL-CAD: 03erikgreenwald * r45143 10/brlcad/trunk/src/other/m4/misc.c: add some windows portability functions. Includes getopt from libbu, LGPL pollution. |
| 20:51.09 | CIA-62 | BRL-CAD: 03starseeker * r45144 10/brlcad/trunk/src/other/byacc/main.c: Looks like this is the only use byacc makes of unistd, so just wrap it here. |
| 20:51.32 | kunigami | When I finish porting sh_osl.c to sh_osl.cpp, OSLRenderer object will need to be declared at a global scope. In which place do you think it's better to keep it? I though of putting it on "struct application", but this struct is not passed as parameter to osl_setup. |
| 20:59.49 | kunigami | hmm the problem of letting OSLRenderer global is that we will need a opaque pointer because it will be visible for C code. |
| 21:01.22 | kunigami | Is it possible to declare it in such a way that it is visible to all sh_osl instances as a global object, while not exposing it to C code? |
| 21:02.54 | brlcad | you mean like static? :) |
| 21:06.52 | kunigami | probably is that what I want |
| 21:08.31 | brlcad | definitely don't want something globally visible |
| 21:09.09 | brlcad | a static global will limit scope to that file, a static variable inside a callback will limit scope even further to callers of an accessor function |
| 21:09.32 | CIA-62 | BRL-CAD: 03starseeker * r45145 10/brlcad/trunk/src/other/flex/ (CMake/ CMake/FindREGEX.cmake CMakeLists.txt): flex will need the regex lib too (and a good deal more, but start with this.) |
| 21:09.49 | brlcad | what else does flex need? |
| 21:10.03 | starseeker | er, sorry - phrased that wrong |
| 21:10.16 | starseeker | needs tests (limit.h, sys/wait.h, etc.) |
| 21:10.24 | brlcad | ah |
| 21:16.48 | kunigami | I was thinking about a possible problem: I only managed to make OSLRenderer work when I grouped all osl shaders in a single class (I've tried using a OSLRenderer for each osl shader, but it didn't work). It's probably the case that some information must be stored in a global context and shared among the shaders. If this is true, it won't be possible to mix brl-cad and osl shaders :( I've to investigate it further... |
| 21:26.51 | CIA-62 | BRL-CAD: 03starseeker * r45146 10/brlcad/trunk/src/other/flex/CMakeLists.txt: No doubt a fair number of these tests need to be more sophisticated, but this gives us a first cut at supporting most of conf.in's variables. |
| 21:57.29 | CIA-62 | BRL-CAD: 03starseeker * r45147 10/brlcad/trunk/src/other/flex/CMakeLists.txt: Whoops - add in the REGEX include dir too. |
| 21:58.57 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 22:01.02 | CIA-62 | BRL-CAD: 03brlcad * r45148 10/brlcad/trunk/include/optical.h: document optical_shader_init() |
| 22:04.54 | CIA-62 | BRL-CAD: 03starseeker * r45149 10/brlcad/trunk/src/other/flex/scan.c: wrap unistd.h in scan.c - will need to fix the generation in some fashion for this, probably add the wrapper to the skeleton... |
| 22:07.35 | CIA-62 | BRL-CAD: 03starseeker * r45150 10/brlcad/trunk/src/other/flex/scan.c: Hmm... need something a bit different here, apparently... - try going minimal... |
| 22:07.37 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) |
| 22:10.12 | CIA-62 | BRL-CAD: 03starseeker * r45151 10/brlcad/trunk/src/other/flex/parse.c: Hmm. Possibly a stray semicolon, could also be an error in the if/else logic... |
| 23:06.52 | brlcad | kunigami: if it's hooked through our shader system, there really is no limitation on mixing shader types because the mixing is per-pixel and happening on our end |
| 23:07.19 | brlcad | you might not be able to get neat blending effects, like a caustic on a non-osl shader, but that's okay |
| 23:07.58 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 23:08.39 | brlcad | it's really a question of whether osl can shade a single pixel without shooting the ray itself -- if it can, then it should be entirely possible |
| 23:09.06 | brlcad | finally finishes an exhaustive day refactoring liboptical .. now to make sure it still works! |
| 23:09.15 | *** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 23:35.52 | CIA-62 | BRL-CAD: 03bhinesley * r45152 10/brlcad/trunk/src/libged/translate.c: adding 'f_tr_obj' functionality to 'translate' |