build fails for ubuntu 18.04 at eval-table.cc for commit ce62ccbd1
mjsduncan opened this issue · comments
ce62ccb Merge pull request #74 from linas/cm
singnet/cogutils is current: master f194b3300
[ 52%] Building CXX object moses/comboreduct/main/CMakeFiles/eval-table.dir/eval-table.cc.o
/home/mozi/oc/moses/moses/comboreduct/main/eval-table.cc: In function ‘void eval_output_results(const evalTableParameters&, const opencog::combo::Table&, const std::vector<opencog::tree<boost::variant<double, opencog::combo::enum_t, opencog::combo::id::builtin, opencog::combo::id::wild_card, opencog::combo::argument, opencog::combo::id::action, const opencog::combo::builtin_action_base*, const opencog::combo::perception_base*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, const opencog::combo::indefinite_object_base*, opencog::combo::message, const opencog::combo::procedure_call_base*, const opencog::combo::action_symbol_base*, opencog::combo::ann_type> > >&)’:
/home/mozi/oc/moses/moses/comboreduct/main/eval-table.cc:105:39: error: call of overloaded ‘ndigits(std::vector<opencog::tree<boost::variant<double, opencog::combo::enum_t, opencog::combo::id::builtin, opencog::combo::id::wild_card, opencog::combo::argument, opencog::combo::id::action, const opencog::combo::builtin_action_base*, const opencog::combo::perception_base*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, const opencog::combo::indefinite_object_base*, opencog::combo::message, const opencog::combo::procedure_call_base*, const opencog::combo::action_symbol_base*, opencog::combo::ann_type> > >::size_type)’ is ambiguous
unsigned npad = ndigits(trs.size());
^
/home/mozi/oc/moses/moses/comboreduct/main/eval-table.cc:95:28: note: candidate: Int ndigits(Int) [with Int = long unsigned int]
template<typename Int> Int ndigits(Int x)
^~~~~~~
In file included from /home/mozi/oc/moses/moses/comboreduct/main/eval-table.cc:29:0:
/usr/local/include/opencog/util/numeric.h:266:28: note: candidate: Int opencog::ndigits(Int, Int) [with Int = long unsigned int]
template<typename Int> Int ndigits(Int x, Int base = 10) {
^~~~~~~
moses/comboreduct/main/CMakeFiles/eval-table.dir/build.make:62: recipe for target 'moses/comboreduct/main/CMakeFiles/eval-table.dir/eval-table.cc.o' failed
make[2]: *** [moses/comboreduct/main/CMakeFiles/eval-table.dir/eval-table.cc.o] Error 1
CMakeFiles/Makefile2:1022: recipe for target 'moses/comboreduct/main/CMakeFiles/eval-table.dir/all' failed
make[1]: *** [moses/comboreduct/main/CMakeFiles/eval-table.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2
You need to git pull moses. It seems you already git pulled cogutils, which removed ndigits, but not moses, which patches moses to work with it.
my pull is current, did you forget to push your fix?
or are sngnet and opencog forks of cogutils different?
Yeah, that's probably the problem, opencog/cogutil and singnet/cogutil are out of sync. I wanted to sync them but then I realized that it would implies to sync opencog/opencog with singnet/opencog as well (given that the changes in cogutil affect opencog) which is a pain because opencog/opencog and singnet/opencog have diverged, thus I'm reluctant to do it. I'm actually increasingly reluctant to work on the singnet repos for that reason.
To be clear, I'll sync opencog and singnet, it's just that I'm waiting to complete my current tasks, as this is a task into itself. However as a general rule, which ever policy we're following or will follow in the future regarding syncing, you should always use repos together from the same organization, that is either you build and install both cogutil and moses from opencog, or both from singnet.
OK, Look, Singnet is supposed to be "stable". One can't just go around syncing things whenever, however; you cannot get stability that way. I really really really want to get across the point that the current process, of having whomever checkin whatever code into whichever random repository at any time, is well-known to the entire industry to promote anti-stability. Its ripe for breakdown and confusion, and you are seeing this first-hand, right here, right now.
That standard answer is "don't do that." There's a pre-historic joke in the computer industry, it starts like this: "Doctor, Doctor, it hurts when I do this!"
The correct method for obtaining stability is to tag a certain version of all repos, then try to build them and get all tests to pass. If tests don't pass, then patch whatever needs patching, in a distinct branch. Then tag the result as the "stable branch.". Done.
Two or three days ago, such a stable branch-point existed: all tests for cogutils, atomspace, opencog, moses, as-moses, agi-bio and benchmark all passed on the same day, in the same afternoon. That's seven repos. If someone broke something after that -- well hey.
Seriously. This is not rocket science. This is doable, but it requires an understanding of the process, and some discipline and some self-control.
I agree. The guys developing opencog-based snet services should be in charge of "syncing" opencog->singnet whichever way and whenever they want, and opencog development should take place upstream.
How should I change my behavior? I started hearing complaints in the last 3 months, but I'm unclear on what that means, where they are coming from, or what I did to provoke them. I don't know what behavior pattern I would need to change.
Urr, yes, I get frustrated and angry and lash out. Is that 100% of it, or is it something else? I feel powerless and unable to control the situation; it seems like everything always goes in the exact opposite direction of where I want it to go, and I haven't been able to figure out how to reverse that.
Or is this an organizational issue, because the git repos are insufficiently modularized? I'm thinking, for example, that the opencog repo should be split into at least six repos: one for language, one for ghost, one for the space-time infrastructure, one for the cogserver, one for pattern mining, and one for everything else. There are pros and cons to this. It might alleviate social friction. But I'm not sure where friction is coming from, as pretty much everyone is working on their own stuff, anyway, and no one is interfering with anyone else's work, from what I can tell. So I thought things were going smoothly, except for singnet, and I flat out don't understand what the heck happened there.
it's your [Linus] infantile behavior that is the primary driver of the growing divergence between the opencog and snet repos
Well, yes @linas tends to swear a lot and close pull requests prematurely, on the other hand maybe the pull request that triggered that whole thing a few months ago wasn't up the standard we want to expect (I don't know cause I didn't review it).
Ideally that PR can be reworked, then merged to opencog/opencog, that would be a good start. Personally I thing we'd be better off putting up with Linas behavior with its pros (lots of accumulated wisdom, knowledge about the inners of opencog, powerhorse coder) and cons (harsh, stringent, treats opencog as its property) and do the bulk of the opencog developement on opencog, and only have the singnet bits on singnet. It just seems easier that way, at least for me...
harsh
I'm trying to be kinder and gentler. But I often work 12 hours, 7 days and at 10 pm if I'm looking at some diff that is imperfect, its like "why am I wasting my time reading this when I could be having fun?" A lot of what I do tends to be janitorial, and just like real-life janitoring its really mostly not fun. Like teenagers. You know. you're looking at it and thinking: "How did this lamp get turned upside-down?"
stringent
Different components have wildly-different needs for stringency. For some components, anyone should be able to check in anything at all, wild-experimentation, see how things work. This is one very good way to learn how to do something. Other components become mature, dependable, reliable, and those need to be treated with care, rectitude, professionalism.
The solution is probably to have more modular github repos, with different maintenance and checkin and access and control policies. Junior programmers in particular need a place to experiment and try out and learn; its vital for growth. So, like if you're in someone-else's living room, it might be a bad idea to try out the brand-new quadri-copter.
treats opencog as its property
I wrote maybe most of it, and it took me ten years to do it. I'm protective. When someone comes in and just la-di-dah carelessly mangles something, without forethought or responsibility... Ugh. It's like vandalism. I can just see the big janitorial cleanup unfolding in the future. When it takes me more time to clean up the mess than it took someone else to make it, that is just plain wrong. So if you're feeling rambunctious, go play, but go play outside, not inside the house. Get some adults in the house; I welcome the company. I would not feel so put-upon to do everything single-handedly. It would be a relief.
You work too much @linas. I've been through that phase 10 years ago, to realize it would destroy me. When it's not working time I completely disconnect. I even have to police myself. But it pays off, usually on Sundays, work related thoughts start to creep in, I gently push them away, like a meditator trying to empty his/her mind. But by Sunday evening I'm usually impatient to resume work for the next day. Sometimes I solve problems outside of working hours, but it's almost outside of my control and for the better, if a beautiful insight comes in, I take it and enjoy it.
BTW, the cons I enumerated don't reflect my personal views that much, I also tried to capture what people seem to think. My main complain to you is that you tend to close PRs too prematurely. No big deal, I reopen if I have too, and often you're right. However I'm afraid that in the manner that it is closed it turns contributors off. For the rest, I don't even mind the cursing. I usually have no problem with people cursing, in fact in a way I like it, they speak their minds. What I despise is dishonesty, which you have null (well, in all fairness, we're all a bit dishonest, starting with ourselves, but that's another topic).
listen to nils, @linas. if you're feeling overwhelmed, take a break and ask for help. if you find yourself typing disparaging comments about your colleagues, do what i did and step away from the keyboard. reread your original comment: despite your later admissions, you blame everything on the incompetency of everyone else. your tone is habitually condescending, and especially coming from a senior developer, it creates a toxic working environment.
snet is the best chance for opencog to get widespread exposure and it's gotten too big for you to dictate every bit of white space in the code base. you have to start working in good faith with other people so they can adapt it for use cases besides your own pet projects. if you disagree with something, make your case without the abusive language. if you can't convince people of your point of view, don't be obstructive; respect group process and let it go. if you were ultimately correct it will become apparent and people will be more likely to consider your opinion going forward. we're using git, it's always fixable, it just takes extra time. this an inevitable part of group decision making.
opencog is your baby, but it takes a village to raise a child ;) time to cut the apron strings and let your baby grow up or you will smother it in its crib.