| 02:47.57 | *** join/#asterisk-scf-dev dms (~dms@user-24-214-131-55.knology.net) |
| 02:52.43 | *** part/#asterisk-scf-dev wesphillips (~wphillips@72-254-150-8.client.stsn.net) |
| 12:35.18 | *** join/#asterisk-scf-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:37.58 | *** join/#asterisk-scf-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:32.46 | *** join/#asterisk-scf-dev dms (~dms@user-24-214-131-55.knology.net) |
| 14:16.57 | *** join/#asterisk-scf-dev leedm777 (~dlee@nat/digium/x-mvyetbdgfdzpdznx) |
| 14:21.57 | *** join/#asterisk-scf-dev dms (~dms@nat/digium/x-rzvbbdriiqqmngyp) |
| 14:23.04 | *** join/#asterisk-scf-dev leedm777 (~dlee@nat/digium/x-gvlsyqskeaumcaoa) |
| 15:02.20 | *** join/#asterisk-scf-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:08.36 | *** join/#asterisk-scf-dev leedm777 (~dlee@nat/digium/x-ppvdxbldyuaiigio) |
| 16:28.33 | *** join/#asterisk-scf-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:43.59 | kenhunt | leedm777 and I were discussing the task that involves include files being located under and AsteriskSCF directory structure, and he made a related recommendation that I agree with. Right now in the slice organizational hierarchy, we have Core/Discovery/ServiceLocatorIf.ice, Core/Endpoint/EndpointIf.ice, Core/Routing/RoutingIf.ice. The file name adds it's own organization, so we could bump all of those up a level to Core. (ServiceLo |
| 17:44.02 | kenhunt | Thoughts? |
| 17:44.58 | beagles | I am cool with that |
| 17:45.02 | kpfleming | what if we have mutliple interface files in Core/Discovery? |
| 17:45.39 | kpfleming | System/Component is already that way, for example |
| 17:48.08 | leedm777 | if there are multiple files, then it either a) makes sense to keep the directory or b) makes sense to merge the files |
| 17:48.15 | leedm777 | that would be a case-by-case basis |
| 17:48.36 | kpfleming | what advantage does this process bring then? |
| 17:48.54 | kpfleming | right now it's pretty easy |
| 17:49.09 | kpfleming | you just create a file and put it in the appropriate directory, and people know where to find it |
| 17:49.40 | kenhunt | it simply removes a bit of redundancy... #include <AsteriskSCF/Core/Endpoint/EndpointIf.h> |
| 17:49.56 | kpfleming | ok, so today we have System/Logger/LoggerIf.ice, and we decide to move it to System/LoggerIf.ice |
| 17:50.13 | kpfleming | then in three months we have a need for a new Logger related Slice file that logically shouldn't be merged with LoggerIf.ice. what do we do? |
| 17:50.43 | leedm777 | well, what would we do in the current system? |
| 17:50.55 | kpfleming | we would leave the System/Logger directory, and add the new file to it |
| 17:50.56 | leedm777 | probably System/Logger/NewLoggerIf.ice, right? |
| 17:51.05 | kpfleming | yes |
| 17:51.13 | leedm777 | In the new system, it would be System/NewLoggerIf.ice |
| 17:51.20 | kpfleming | but it might not have Logger in the name |
| 17:51.33 | kpfleming | System/Component/ReplicaIf.ice does not have Component in its name |
| 17:51.47 | leedm777 | and that's a case where keeping the directory probably makes sense |
| 17:51.59 | kpfleming | but once you have removed the directory, you can't go back |
| 17:52.04 | leedm777 | why not? |
| 17:52.10 | kpfleming | because it will break all existing users |
| 17:52.28 | leedm777 | you can have System/Logger.ice _and_ System/Logger/NewThing.ice |
| 17:52.37 | kpfleming | that's awful, in my opinion |
| 17:52.50 | leedm777 | Foo/FooIf.ice is awful in my opinion |
| 17:53.03 | kpfleming | then call EndpointIf.ice something else |
| 17:53.22 | kenhunt | we had discussed that boost often uses an idiom where for a particular collection of functionality where there is a "top level" include that may pull in a lot of related includes in a subdirectory. For example, you might include "boost/thread.hpp" to get all the boost thread headers... or you might include "boost/thread/mutex.hpp" |
| 17:53.40 | kpfleming | what i don't want to see is the words that used to be directory names forced to be in the file names because we've eliminated the directories |
| 17:53.58 | kpfleming | sure, you could certainly do that as well |
| 17:54.18 | kenhunt | so that's how I was thinking we'd handle the Component case... |
| 17:54.52 | kpfleming | then it makes sense to do that across the board, and not have two different methods of organization |
| 17:54.54 | kenhunt | there could be a ComponentIf.ice that includes Component/ComponentServiceIf.ice and Component/ReplicaIf.ice |
| 17:55.34 | kpfleming | well, if you were going to do that, i'd suggest the upper level file would just be Component.ice. it won't actually generate any output files. |
| 17:56.18 | leedm777 | And Time.ice that include Time/TimeIf.ice, Logger.ice that includes Logger/LoggerIf.ice, Routing.ice that includes Routing/RoutingIf.ice, etc. |
| 17:56.24 | leedm777 | I could go for that |
| 17:56.26 | kpfleming | yes |
| 17:56.33 | kpfleming | that is easily extensible and is understandable |
| 17:56.47 | kpfleming | s/understandable/documentable/ |
| 17:57.16 | leedm777 | And it follows the pattern for boost, and i figure those guys know what they're doing |
| 17:57.18 | leedm777 | :-D |
| 17:57.36 | kpfleming | yep |
| 17:58.17 | kpfleming | i was incorrect before... for C++, these include files would generate .h files, but that's all |
| 17:58.44 | kpfleming | does this help Java and C# at all? it doesn't seem like it. |
| 17:58.50 | leedm777 | no |
| 17:59.01 | leedm777 | Java structure is entirely based on the module structure |
| 17:59.07 | leedm777 | .ice files don't matter |
| 17:59.21 | kpfleming | but in those languages, you can mass reference package subspaces with wildcards though, right? |
| 18:00.14 | leedm777 | well, in Java you usually don't care. the IDE handles the imports for you :-) |
| 18:00.16 | kpfleming | ok |
| 18:00.38 | kpfleming | i was thinking more of C++ 'using namespace', for flattening the namespace |
| 18:00.43 | leedm777 | but, yes, it does have wildcard imports. |
| 18:00.47 | kpfleming | ok |
| 18:00.52 | kpfleming | so that achieves the same end, sort of |
| 18:00.58 | leedm777 | pretty much |
| 18:11.34 | beagles | That presumes you are using an IDE for Java development :) |
| 18:28.55 | beagles | I wasn't really following the conversation as it was happening but at the risk of seeming overly agreeable: I'm also cool with that :) |
| 18:30.31 | leedm777 | file and putnopvut: any thoughts ^^^ |
| 18:30.48 | putnopvut | gahh, must catch up |
| 18:33.49 | putnopvut | I really really don't care. |
| 18:45.34 | kpfleming | I really care that putnopvut doesn't care. |
| 19:49.23 | kpfleming | leedm777: should i drop you from CR-ASTSCF-36? the remaining areas of work are pretty far outside your interests, i suspect |
| 19:50.00 | leedm777 | kpfleming: yeah; most I can do at this point is notice glaring errors. |
| 19:50.04 | leedm777 | thanks! |
| 19:50.10 | kpfleming | will do |
| 19:53.44 | *** join/#asterisk-scf-dev wesphillips (~wphillips@192.160.117.155) |
| 19:59.47 | *** join/#asterisk-scf-dev wesphillips (~wphillips@192.160.117.155) |
| 20:04.44 | *** join/#asterisk-scf-dev dms (~dms@nat/digium/x-emxebbqbxeproaua) |
| 20:18.12 | file | reads |
| 20:18.44 | *** join/#asterisk-scf-dev wesphillips1 (~wphillips@192.160.117.155) |
| 20:19.36 | file | I am with putnopvut |
| 20:31.55 | dms | anyone built on Windows recently? |
| 20:32.09 | file | I built yesterday |
| 20:32.15 | dms | hmm |
| 20:32.29 | dms | I'm getting a compiler error from a fresh clone |
| 20:32.46 | dms | here I come msdn |
| 20:33.10 | kpfleming | what is the error? |
| 20:33.17 | dms | 0xc0150002 |
| 20:33.23 | kpfleming | oh, you mean an internal error |
| 20:34.18 | dms | yes . . on slice2cpp |
| 20:34.51 | kpfleming | why oh why does C# require you to indicate that you are overriding a virtual method in one of your base classes? if the base class didn't want it to be overridable without explicit action, they wouldn't have made it virtual |
| 20:34.58 | file | are you attempting to use MSVC++ 2010? |
| 20:35.03 | dms | yes |
| 20:35.10 | dms | (express) |
| 20:35.20 | beagles | ar all of the required DLLs available for slice2cpp |
| 20:35.39 | file | 1. I strongly suggest using 2008 until I get to my task to explore 2010, because I don't think stuff will work as it is right now |
| 20:35.48 | kpfleming | yeah, post the last few lines of output before that message |
| 20:35.59 | file | 2. I remember having to modify the Ice config when building it to turn on 2010 support or I got a weird error with slice2cpp |
| 20:36.25 | dms | gotcha |
| 20:37.20 | file | # Specify your C++ compiler. Supported values are: |
| 20:37.21 | file | # VC60, VC90, VC90_EXPRESS, VC100, VC100_EXPRESS, BCC2010 |
| 20:37.21 | file | # |
| 20:37.21 | file | !if "$(CPP_COMPILER)" == "" |
| 20:37.21 | file | CPP_COMPILER= VC100_EXPRESS |
| 20:37.21 | file | !endif |
| 20:37.40 | file | that is what I changed in Make.rules.mak |
| 20:38.01 | kpfleming | you could just set CPP_COMPILER in the config file |
| 20:38.02 | dms | "making all in Ice" |
| 20:38.02 | dms | <PROTECTED> |
| 20:38.02 | dms | Could Not Find C:\ascf\ice\cpp\include\Ice\BuiltinSequences.h |
| 20:38.02 | dms | Could Not Find C:\ascf\ice\cpp\src\Ice\BuiltinSequences.cpp |
| 20:38.02 | dms | <PROTECTED> |
| 20:38.03 | dms | ..\..\..\slice" --stream ..\..\..\slice\Ice\BuiltinSequences.ice |
| 20:38.03 | dms | NMAKE : fatal error U1077: '..\..\bin\slice2cpp.exe' : return code '0xc0150002' |
| 20:38.10 | file | yes. |
| 20:38.14 | file | that is exactly what I encountered |
| 20:38.20 | kpfleming | thats not a compiler error, it's an error running slice2cpp |
| 20:39.32 | beagles | if the compilation flags are the culprit, you need to rebuild slice2cpp |
| 20:40.01 | beagles | and the libraries it depends on (Slice, etc) |
| 20:53.39 | dms | set CPP_COMPILER=VC100_EXPRESS seems to have done the trick |
| 20:54.46 | kpfleming | and for some reason they do care whether it is EXPRESS or not |
| 20:54.57 | dms | would appear that way |
| 20:59.32 | kenhunt | kpflemging: I actually adore that C# requires the override keyword. It gives the user of the class explicit information about what's happening (without having to visit all the classes being derived from), and it allows the compiler to insure that you didn't accidentally change some parameter, thus creating an accidental overload as opposed to the override that you intended. Java has added the @Override tag for the same reason, albe |
| 20:59.35 | kenhunt | (imo) |
| 20:59.55 | kpfleming | hmm |
| 21:00.02 | kpfleming | well, i guess it does have its uses then |
| 21:00.20 | kpfleming | i've worked out the requirement and slice2cs now supports plugin generators, so i'm happy :-) |
| 21:30.36 | dms | well, ice built like a champ |
| 21:30.39 | dms | :) |
| 21:31.01 | file | there is method to my madness |
| 21:33.22 | kpfleming | sometimes |
| 22:00.55 | *** part/#asterisk-scf-dev wesphillips1 (~wphillips@192.160.117.155) |
| 22:38.00 | kpfleming | okey-dokey... the slice translator plugin stuff now works for C++, Java, C# and Python, including dynamic code generation for Python |
| 22:38.30 | kpfleming | now i need to test it winders to ensure i didn't break anything |
| 22:38.36 | kpfleming | s/it/it on/ |
| 22:41.09 | kenhunt | s/infobot/nagging_wife_substitute/ |
| 22:41.51 | leedm777 | hey, don't hate on the infobot |
| 22:42.07 | kenhunt | well, I don't hate my wife... |
| 22:42.20 | leedm777 | infobot, botsnack |
| 22:42.20 | infobot | leedm777: thanks |
| 22:42.23 | kenhunt | but infobot seems to have a lot in common with her |
| 22:42.36 | dms | heh |
| 22:43.00 | leedm777 | always correcting you... |
| 22:43.17 | kenhunt | someone has to |
| 22:43.21 | dms | I now have a machine with a working dvd/cd burner!! w00t!! |
| 22:43.24 | dms | it's the little things |
| 22:47.09 | dms | msbuild had less than stellar build results with AsteriskSCF . . although, it's not near as bad as the first time I tried building Asterisk SCF |
| 22:47.16 | dms | 5 warnings, 28 errors |
| 22:47.26 | dms | most of them boost related |