User forums > Nightly builds
The 12 October 2014 build (9958) is out.
stahta01:
--- Quote from: Alpha on October 21, 2014, 05:43:14 pm ---
--- Quote from: Alpha on October 21, 2014, 05:11:48 pm ---ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated. Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
--- End quote ---
On second thought, magic numbers fix everything, right?
--- End quote ---
Or, it at least makes most people afraid to make changes to the code.
I fixed one CB bug with a magic number in it; but, I would NOT likely fix a second one.
Tim S.
Alpha:
--- Quote from: stahta01 on October 21, 2014, 06:19:19 pm ---Or, it at least makes most people afraid to make changes to the code.
--- End quote ---
Yes... I was being a bit sarcastic when I posted :P . The magic number is what I will be using on my personal C::B build, since I can deal with "mostly working" (and I do like that it shows me more exactly which lines have changed). However, I plan to be committing the prior fix (unless there are objections) of removing not-so-smart smartness from text insertion, with a comment to come back if ever I (or someone else) has a bright idea of how to make it work.
eckard_klotz:
Hello Ollydbg.
Thanks for your detailed post and please excuse my late reply.
First of all, after doing the change you and Morten proposed the shown namespaces in the symbol browser main-level are only the top-level ones. Thus you are right, if you say that the reason of my initial problem was my code even I still wonder why MinGW was still able to compile it. But this may be an other problem between my ears you don't have to care about. While implementing the namespace-using in the way of
--- Code: ---#ifndef DOXYGEN
namespace A {
namespace B {
namespace C {
#endif //DOXYGEN
...
...
#ifndef DOXYGEN
#define USING_NAMESPACE using namespace
};};}; USING_NAMESPACE A::B::C;
#endif //DOXYGEN
#undef USING_NAMESPACE
--- End code ---
I recognized that the symbol browser showed an empty and unnamed namespace symbol as child node of A. This occurred not if namespace A contains child namespaces which contain no own child namespaces I face no empty braces. But if the child namespaces of A contain other child namespaces like C by them self than the effect occurred.
Thus I changed the implementation:
--- Code: ---#ifndef DOXYGEN
namespace A {
namespace B {
namespace C {
#endif //DOXYGEN
...
...
#ifndef DOXYGEN
#define USING_NAMESPACE using namespace
}; USING_NAMESPACE C;
}; USING_NAMESPACE B;
}; USING_NAMESPACE A;
#endif //DOXYGEN
#undef USING_NAMESPACE
--- End code ---
Now it looks like in the old nightlies. It may be, that I failed again while implementing your solution. Thus from my point of view there is no need for further investigations. But I thought you may be interested in.
--- Quote ---I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling.
...
...
--- Quote ---Please don't use the "misuse" any more, since our parser works correctly now.
--- End quote ---
--- End quote ---
No, sorry misuse is still the right word to use here. But I don't write about a wrong display inside the symbol browser. What I mean is that I use hammer where normally a screwdriver should be used. If you take a look to my sources you will see that my namespace structure redefines the structure of the classes. In an object-orientated design you are modeling your structure by derivation of a child-class from a parent-class. But this deviation is not used by the symbol browser to filter out the child to show them only as child-nodes of their parents. Thus I decided to choose namespaces to redefine this derivation structure, since the nesting structure of namespaces is used to show the structure in the symbol browser as I like. But as we learned, this works only if it will be done in the right way. Furthermore maintaining nested namespaces is a tough task and I would nobody recommend to do so without a really good reason.
However my current issue caused by my self is solved now, so thank you very much for you support.
--- Quote ---The source code of C::B is not that hard to understand, so if you have any problems reading the source code, just ask here, I think you can get help from other ones(including me).
--- End quote ---
I hope that I will find some time in the next days, to note down some details what I'm thinking about if I'm writing about having a package model in the symbol browser (or in an own browser?). And I will post it here. If you agree that the idea may have some potential, I would propose to have further discussions in the development forum. I agree, that the code of the symbol browser itself looks understandable. But there are some other sources which are hard to understand. Some time ago I posted a problem I have with the folding-feature. Furthermore I took a look into the C::B sources but I failed to get an idea how to solve this issue by my self. But I think in the case of my browser solution I already have an idea how to do it and need more somebody who reviews my thoughts to ensure that my solution does not create new issues.
Best regards,
Eckard.
teto:
Hi,
I just need some help using the nightly on linux ubuntu 14.10. I use Jens packages flawlessly with a similar software configuration (Ubuntu 14.10 etc...) on one of my computers but it does not start on this one. I am pretty sure it has to deal with wxWidget (both jens and I use 2.8 I believe but the ubuntu version must differ from Debian's). Apparently it is caused when a software uses a static wxWidget timer in his code cf https://forums.wxwidgets.org/viewtopic.php?p=113193 (from this thread, it looks like a bad idea).
Here is the output of "codeblocks -v" (I could not find how to display the version number but this should be the latest nightly).
--- Code: ---Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading menubar...
ToolsPlus: loaded
ProjectsImporter: loaded
../src/common/timercmn.cpp(62): assert "Assert failure" failed in Init(): No timer implementation for this platform
../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
--- End code ---
Here is my wxwidget version:
--- Code: ---$ wx-config --list
Default config is base-unicode-release-2.8
Default config will be used for output
--- End code ---
oBFusCATed:
Hm, can you post a backtrace?
Also wx-config is the bad tool to ask about your wxgtk, try with apt-get or apt-cache search or something similar that works on your ubuntu.
The wx-config will list only the dev-file you have for a particular version of wxgtk.
I guess you have both wx2.8 and 3.0 and cb is using the 3.0.
ldd /usr/bin/codeblocks will help you see if this is the case.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version