Author Topic: The 27 July 2009 build (5716) is out.  (Read 104774 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 27 July 2009 build (5716) is out.
« Reply #45 on: August 05, 2009, 07:11:14 am »
Code:Blocks is an IDE & IMO we should try not to transform it to a Text Editor or a Browser.
Amen. In addition what worries me: Most users don't even understand what "encoding" means and why detection has to fail using a wrong setup. For those it'll always be hard to find the right setup even with the option we have or the options Biplab is proposing. So we will always be claimed "somehow" as long as encoding exists. ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 July 2009 build (5716) is out.
« Reply #46 on: August 05, 2009, 11:27:03 am »
In almost all my projects there are many files and I need check project's tree visually to find required file.
C::B has menu item for this task - "Finf file...", but it requires full file name and I, for example, remember only it's part. May be I make a mistake thinking that required a full file name? If so tell me, please, how need to do.
If not, I think it will be better to use regular expression to find first matching file in tree after current, because current "Find file..." is not usable for me.

witton

  • Guest
Re: The 27 July 2009 build (5716) is out.
« Reply #47 on: August 05, 2009, 12:21:28 pm »
-- removed non english content --
Jens
« Last Edit: August 05, 2009, 12:57:00 pm by jens »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 July 2009 build (5716) is out.
« Reply #48 on: August 05, 2009, 01:25:32 pm »
critic: have you tried the alt+g key combination, in that dialog you can type part of the filename
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 July 2009 build (5716) is out.
« Reply #49 on: August 05, 2009, 01:34:19 pm »
Thanks, oBFusCATed
It very handy!  :D

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 27 July 2009 build (5716) is out.
« Reply #50 on: August 05, 2009, 02:01:56 pm »
If I understood, the encoding is not saved into the file, so C::B tries to guess the right one when the file is opened. So when you add the latin-2 encoding, some latin-1 files are seen as latin-2, so some characters are displayed in a wrong way.
So I change the option Settings >> Editor >> General Settings >> Use This Encoding to "As default encoding", so the C::B's auto-detectionis bypassed, and this solved my problem.

If this is the situation, I think that your idea of the configuration-option is the easiest one: I'm afraid that detecting latin-1 from latin-2 is not easy...


A file encoding is never saved to a file. At least I'm unaware of any widely popular method of storing file encoding data to a file. Reason is pretty simple. One need to strip that data (encoding detection data) before feeding it to another program. Or the other program should be aware of how to strip that data.

Most of the known software performs encoding detection by sampling data from file. There are BOM for UTF encoded file. But for other encoding sampling and measuring frequency of encoded characters is the only way to detect an encoding. Mozilla's encoding detection is an example of this.

For a large project with files encoded with a less popular encoding scheme will surely degrade Code:Blocks' performance. Precisely this was the reason Yiannis objected (long ago) to the inclusion of Mozilla's encoding detection code to trunk. IMHO it should be turned on as an Option only.

IMHO the solution should be to give user two option.
1) Use a simple encoding detection scheme (to detect most of the popular encodings).
2) Use Mozilla's code to detect encoding (we should make it very clear that this option may affect performance in some cases).
3) Don't detect encoding.

And to each of the above options Fallback Encoding options shall be-
a) Use System encoding.
b) Use User-provided encoding.

Code:Blocks is an IDE & IMO we should try not to transform it to a Text Editor or a Browser.

You are right, C::B is not a browser, but C::B is an IDE, so the editor is an important part, otherwise it would be not much more than a build-system like makefiles.

I did not answer yesterday, because I wanted to make some speed tests.
I did not have a project, where he new encoding detection is noticeable slower than the old one.

This might be different for some less popular (rare?) encoding schemes,as you wrote.
But in my opinion it is better to have a somewhat slower encoding-detection that works, than a fast detection, where the user has to force something to make it work.

A possible slowdown, is only a problem, if a user opens (very) many files at once.
We had some real bottlenecks, but together with the new detection, more parts of the file-loading code were improved.
Nevertheless it still needs much more time to load the file into the editor (after it's encoding has been detected and it was loaded into a string-variable), than the encoding detection took (at least in the great majority of all cases I have seen).

For my tests I use the same code except for the detection, that means all speed-ups are the same in both test-variants of C::B.

The new encoding detection does the following:
  • check for user-forced-encoding
  • search bom
  • try to detect uft16
  • try to detect uft32
  • try to detect  ascii or extended ascci encoding like HZ-GB-2312, ISO-2022-CN
  • or try to detect singlebyte, multibyte and latin1 charsets

The first four did not change with new encoding detection, the ascii-detection is very fast, the last might take a little longer, but I don't get a difference, even if I use the wxStopWatch and log the time needed to open all files of a project, there is no noticeable or measurable difference.

Bypassing C::B's detection should be faster (but we still have to convert the file-content, what takes "much" time), but that's a thing the user can still do.

If it works fast for the majority of cases and possibly slower for some cases (I did not get one until now) it does not make sense to change anything (except for not probing latin2 encodings by default, because it breaks detecting of some latin1 charsets).

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: The 27 July 2009 build (5716) is out.
« Reply #51 on: August 05, 2009, 03:16:27 pm »
You are right, C::B is not a browser, but C::B is an IDE, so the editor is an important part, otherwise it would be not much more than a build-system like makefiles.

If a Cash-Rich Mozilla Corporation doesn't bother to improve it's detection code I'd also not want to spend much effort on doing so. Anyway it was my personal opinion.

But if we are able to improve the detection code I'd be happy to see that code get merged to trunk.

This might be different for some less popular (rare?) encoding schemes,as you wrote.
But in my opinion it is better to have a somewhat slower encoding-detection that works, than a fast detection, where the user has to force something to make it work.

I'd still prefer to have it as an optional feature; not as a "Default" feature. Personally I also want to support a wide variety of user base. But that shouldn't be done at the cost of other users who don't need that.


The new encoding detection does the following:
  • check for user-forced-encoding
  • search bom
  • try to detect uft16
  • try to detect uft32
  • try to detect  ascii or extended ascci encoding like HZ-GB-2312, ISO-2022-CN
  • or try to detect singlebyte, multibyte and latin1 charsets

The first four did not change with new encoding detection, ...

I disagree with this one. There were couple of changes made-
1. Api was changed.
2. UTF-8 detection code now stands commented out. (as good as deleted)

In fact I was never asked / consulted / explained why the above 2 took place. Sorry, but I couldn't understand the reason.


Anyway I don't want to stretch this any longer in this public forum. But I think we should start a thread separately (in our own space) to clear the air.
Be a part of the solution, not a part of the problem.

Offline Acki

  • Multiple posting newcomer
  • *
  • Posts: 100
Re: The 27 July 2009 build (5716) is out.
« Reply #52 on: August 09, 2009, 04:15:59 am »
Hi,
since the last 2 or 3 nightlies I have a problem with the editor...
If I have multiple files opened and I want to switch to one of these files I use "CTRL-Tab"...
now there pops a window up where I can select the file/tab where to go...
but I want it like in older versions, so if I press CTRL-Tab the next file/tab opens directly without this popup window !!!

I searched the options and I found "Settings->Environment->Notebooks appearance->Use drop-down tab list", but it has no effect if I disable or enable this...

also if I press Shift-CTRL-Tab to go to the previous file/tab it works like before, but it stops at the first editor tab, but I want it to go to the last tab again after the first tab...

I'm using this Nightly with WinXP-pro (sp2)...
« Last Edit: August 09, 2009, 04:18:12 am by Acki »

lesc

  • Guest
Re: The 27 July 2009 build (5716) is out.
« Reply #53 on: August 10, 2009, 09:31:43 pm »
Hi all!

I <3 codeblocks :D ..used the stable version from ubuntu synaptic until two days or so.. had a funny segfault when codeblocks reparsed file after saving it.. well, so I tried this nightly and at least this bug has vanished ;D

..but now all my code with OpenGL/GLUT will not work anymore :(

...seg fault in glutCreateWindow()   :(
..this code worked perfect until now :/ ..I tried to update my GLUT libs but it didn't help :(

code:
Code
void setupGLUT(int *argc, char **argv, int winid[]) {
    glutInit(argc, argv);
    glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);

    winid[0] = glutCreateWindow("OpenSG");
    //winid[1] = glutCreateWindow("OpenSG2");

    glutReshapeFunc(reshape);
    glutDisplayFunc(display);
    glutKeyboardFunc(keyboard);
    glutSpecialFunc(keyboard_special);
    glutIdleFunc(display);
}

call stack :

#0 0x7f959dc9561c   ??() (/usr/X11R6/lib64/libGL.so.1:??)
#1 0x7f959dca44d6   ??() (/usr/X11R6/lib64/libGL.so.1:??)
#2 0x7f959dcaa03a   ??() (/usr/X11R6/lib64/libGL.so.1:??)
#3 0x7f959dc9ea68   glXCreateContext() (/usr/X11R6/lib64/libGL.so.1:??)
#4 0x7f959e0c5afd   fgOpenWindow() (/usr/lib64/libglut.so.3:??)
#5 0x7f959e0c4494   fgCreateWindow() (/usr/lib64/libglut.so.3:??)
#6 0x7f959e0c5591   glutCreateWindow() (/usr/lib64/libglut.so.3:??)
#7 0x41bbfe   setupGLUT(argc=0x7fffa86e63bc, argv=0x7fffa86e6618, winid=0x7fffa86e63c0) (*projectfolder*/src/main.cpp:156)
#8 0x41c46e   main(argc=1, argv=0x7fffa86e6618) (*projectfolder*/src/main.cpp:80)

I am using Glut with OpenSG

I will try to find more things to say on this problem.. I am sorry to post without more informations on this.. (please tell me what information could help)

thanks for any ideas/sugestions/help/time

victor

Edit: humm, it still works fine at home (ubuntu 32 at home vs suse 64 at work..) ..so I don't think it has anything to do with codeblocks.. could be coincidal with my upgrade to nightly.. sry to have wasted your time.. 
« Last Edit: August 10, 2009, 11:10:31 pm by lesc »

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 July 2009 build (5716) is out.
« Reply #54 on: August 11, 2009, 07:02:53 am »
Hello everybody!

Who can say when C::B will have a modern codecompletion? This functionality is very important in everyday work of programmer and I don't know when to expect it: a month, a year or never?

Under 'modern' I mean:
  • work with templates
  • work with defines
  • not list items that are actually is absent in class or structure

Below are examples to show problems

Templates:
Code
   template <class T>
   struct C1
   {
      T obj;
   };

   struct C2
   {
      void func() {}
   };

   C1<C2> obj;
   obj.obj.
And it's all - I expected 'func()', but got nothing (this bug is stable, i.e. repeatable).

Defines:
Code
   #define DECLARE_SINGLE(Class) \
      private:\
         Class() {}\
         ~Class() {}\
         Class(const Class &obj);\
         Class& operator=(const Class &obj);\
      public:\
         Class& inst()\
         {\
            static Class obj;\
            return obj;\
         }

   class SingletonTest
   {
      DECLARE_SINGLE(SingletonTest)
   public:
      void func() {}
   };

   SingletonTest::inst().
And again it's all - I expected 'func()', but got nothing (this bug is stable, i.e. repeatable).

About strange items only a few words:
  • when I switching to another project: if class has the same name as in previous project, but another content, codecompletion shows content from previous project (need IDE restart to go to better work of plugin)
  • while working with project I detect that items (methods and attributes) of classes can mix, that is for some class I can obtain items, that are really absent in this class (and I have to go to sources or documentation again and again or load it in my mind - this is not handy at all)

It is very sad that for such long time this very important feature remains with these bugs.
Other functionality of C::B and that it written using C++ is very friendly for me.

With regards :wink:
« Last Edit: August 11, 2009, 07:05:53 am by critic »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 27 July 2009 build (5716) is out.
« Reply #55 on: August 11, 2009, 08:34:27 am »
Who can say when C::B will have a modern codecompletion?
Nobody.

What you want is really the "hardest" part of CC to do. Remember that professional CC plugins (e.g. for Visual Stuidio) had required years of work by many people that got paid full-time. So most likely the quality you are looking for is a long-term goal.
However - you can try the codecompletion_refactoring branch that has several enhancements (and some more to come) to the current "trunk" version.
Of course (and not to forget): OpenSource projects live by contribution - so you can help and contribute to CC if you like. May others did which resulted really in major enhancements to CC. But surely you can always do better in the end.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 July 2009 build (5716) is out.
« Reply #56 on: August 11, 2009, 01:31:25 pm »
Who can say when C::B will have a modern codecompletion? This functionality is very important in everyday work of programmer and I don't know when to expect it: a month, a year or never?
Hi, critic, I have attempt to improve codecompletion, but for some reasons it is still not as good as I expect.

If you read the sub-forum: http://forums.codeblocks.org/index.php/board,18.0.html, you can learn all the current status of CC.

I hope more people would take part in its improvement.
 
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: The 27 July 2009 build (5716) is out.
« Reply #57 on: August 11, 2009, 02:10:52 pm »
actually it is not a bug. if you read the souce codes, you will know that the two functions you mention is be so
because the code completion ignore it.in current version.it is not possible to implement it.
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?

Offline Acki

  • Multiple posting newcomer
  • *
  • Posts: 100
Re: The 27 July 2009 build (5716) is out.
« Reply #58 on: August 11, 2009, 04:48:18 pm »
another problem when creating a DLL...
let's say I'm compiling a DLL called "Irrlicht.dll", now the lib file is named "libIrrlicht.dll.a"...
but I don't want the ".dll" between "libIrrlicht" and ".a" !!!
now I either need to rename the lib manually or change the project settings for all my projects...  :?

is there a way to disable the ".dll" for the lib name ???

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 27 July 2009 build (5716) is out.
« Reply #59 on: August 11, 2009, 08:35:57 pm »
is there a way to disable the ".dll" for the lib name ???
Search the forums.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ