Author Topic: The 27 February 2010 build (6181) is out.  (Read 130218 times)

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 February 2010 build (6181) is out.
« Reply #90 on: April 12, 2010, 10:38:20 am »
I have a question: What codepage used by `Build log` text edit component?
I have a problem with it - when I start pre/postbuild step I can't recognize output of executed binary (output is in cyrilliс codepage). I can convert output by executing `chcp` command and then execute binary in windows batch file with the same name as binary's. But to do so I need to know codepage of C::B component.


[attachment deleted by admin]
« Last Edit: April 12, 2010, 10:40:34 am by critic »

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 February 2010 build (6181) is out.
« Reply #91 on: April 12, 2010, 02:23:02 pm »
I must report that after `global variables` dialog is closed config remains unsaved for unknown reason. And when C::B crashes all changes are loast. That's why I need after each modification of C::B config restart it.
I think it will be better to save config when dialog is closed.

The same can be made for projects and workspaces - I need save project manually every time I made changes in it (added file, removed file, changed project's config and so on).

C::B makes a show that all saved and IDE initialized after successful saving, but really it isn't.

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 February 2010 build (6181) is out.
« Reply #92 on: April 12, 2010, 02:35:27 pm »
But if I run more than 1 instance of IDE and changed config in one of them it can be replaced by older one after closing them if it wasn't the lastest closed IDE.
To prevent this IDE can check date of last modification of config file when I select another instance of IDE and advice to apply new config or no (just the same way as for source files).

Good luck!

Offline Zini

  • Multiple posting newcomer
  • *
  • Posts: 64
Re: The 27 February 2010 build (6181) is out.
« Reply #93 on: April 12, 2010, 02:43:15 pm »
Actually the easiest solution would be to drop saving settings on application shutdown entirely and save them instead immediately when they are changed. This solves the problem of losing settings by a crash as well as any mess created by running two instances in parallel. Honestly, who came up with the idea of saving setting at shutdown time? (bet it was Microsoft ;) )

Regarding automatic saving of projects: This was already discussed before. See here:

http://forums.codeblocks.org/index.php/topic,10653.0.html

Unfortunately it didn't lead to anything.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13083
    • Travis build status
Re: The 27 February 2010 build (6181) is out.
« Reply #94 on: April 12, 2010, 06:46:25 pm »
... And when C::B crashes all changes are loast....
C::B must not crash... Have you isolated and reported the crashes you experience?
(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 February 2010 build (6181) is out.
« Reply #95 on: April 13, 2010, 05:57:16 am »
oBFusCATed, you are not right - I use nightly build (even the stable version) and it will probably crash. So the better solution in this case is to save settings when I press OK and then (if successful) to initialize IDE. In this case we can report not only stack trace, but configuration of IDE (it can be useful for developers, I think)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5302
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 February 2010 build (6181) is out.
« Reply #96 on: April 13, 2010, 06:39:25 am »
I have a question: What codepage used by `Build log` text edit component?
I have a problem with it - when I start pre/postbuild step I can't recognize output of executed binary (output is in cyrilliс codepage). I can convert output by executing `chcp` command and then execute binary in windows batch file with the same name as binary's. But to do so I need to know codepage of C::B component.

I also experience this kind of problem.
When I use a mingw gcc version which has Chinese language support. There are always unknown characters in the build log. The only thin I can do is : Delete the Chinese language files under C:\MinGW\share\locale
 :D
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13083
    • Travis build status
Re: The 27 February 2010 build (6181) is out.
« Reply #97 on: April 13, 2010, 09:27:15 am »
oBFusCATed, you are not right - I use nightly build (even the stable version) and it will probably crash. So the better solution in this case is to save settings when I press OK and then (if successful) to initialize IDE. In this case we can report not only stack trace, but configuration of IDE (it can be useful for developers, I think)
No, I'm right, you have not reported why it crashes.  :lol: 8)
Developers don't need config files, most of the time, they need "steps to reproduce" (Saying "it will probably crash" doesn't help at all!)
Please start a thread, where you explain what you do to crash C::B!

Implementing the "Save on OK" feature has its drawbacks, too...
(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 February 2010 build (6181) is out.
« Reply #98 on: April 13, 2010, 09:42:31 am »
Quote
you have not reported why it crashes.

In my message I'm not focused on some IDE crash, but on loosing of my settings each time crash happens :) and that is very unpleasant.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13083
    • Travis build status
Re: The 27 February 2010 build (6181) is out.
« Reply #99 on: April 13, 2010, 01:01:17 pm »
OK, Live with the crashes... You can't be helped  :lol:
(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 filofel

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: The 27 February 2010 build (6181) is out.
« Reply #100 on: April 13, 2010, 05:15:55 pm »
Quote
OK, Live with the crashes... You can't be helped

PMJI, but that's a problem I've been experiencing too:
When C::B abruptly terminates for any reason (might not even be C::B fault), most of the time, a part of the project is lost. Or at least, the latest modifications are lost (such as files recently appened to the project, etc.).
It would be nice if anything that is saved in the config would be written to disk and flush() committed immediately, to minimize the risk of ending up with an obsolete and/or corrupted config file. I think that this is what Critic meant.

C::B crashes very rarely under me (even though I'm running bleeding edge nigthly builds, 6203 as of today, courtesy of Jens Lody's repositories, mucho thanks Jens).
But in the rare occasions when I had a problem, I ended up with missing items in my project. Even though I have Autosave set to 4 mn on both sources and project, BTW.

I guess this can be simulated quite easily by abruptly ending the C::B process.  :)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9612
Re: The 27 February 2010 build (6181) is out.
« Reply #101 on: April 15, 2010, 07:00:56 am »
It would be nice if anything that is saved in the config would be written to disk and flush() committed immediately, to minimize the risk of ending up with an obsolete and/or corrupted config file. I think that this is what Critic meant.
Look: This would make it impossible to play with project configurations e.g. for optimisations. I personally do that quite often but if this would be saved every time I would always need to revert it back. I don't agree that this makes sense. The same would be that every time you are typing a character in the editor the editor shall be saved. This makes no sense.

The only solution I see is to adapt the autosave plugin to save project files in a certain interval, too. This can be toggled and is convenient.

I guess this can be simulated quite easily by abruptly ending the C::B process.  :)
Same thing here: Did you ever think when I kill a process I want exactly not to save anything?
« Last Edit: April 15, 2010, 07:02:57 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline filofel

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: The 27 February 2010 build (6181) is out.
« Reply #102 on: April 15, 2010, 08:23:07 am »
<shrug>
I've been using *alot* of IDEs, and I've never experienced that kind of behavior before.
IOW, all those I know of do secure config modifications either instantly or at validation time.

Quote
The same would be that every time you are typing a character in the editor the editor shall be saved.
The comparison doesn't hold, IMO. Typical use case doesn't show the same change rate, by several orders of magnitude. And the config changes tend to be more important because they impact the whole project, and update losses are not proofed by a compiler.

Quote
Same thing here: Did you ever think when I kill a process I want exactly not to save anything?
If you consider killing C::B as a "normal" way to exit it (like a "quit without saving" menu item), then you are probably right. But as far as I'm concerned, I've never had to kill C::B (or any other IDE) for such a reason.
It looks to me the motivations you mention are more those of a developer of C::B who needs this behavior for testing C::B more conveniently than those of a vanilla user of C::B using it for developping anything else.

Nevermind...
« Last Edit: April 15, 2010, 08:27:11 am by filofel »

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 27 February 2010 build (6181) is out.
« Reply #103 on: April 15, 2010, 02:10:03 pm »
Please, note that: sometimes at development process I add global variables or change them and when I close `global variables` dialog I expect they will be saved at that moment, but they don't. I think this example shows that behaviour of IDE in such situations is strange.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13083
    • Travis build status
Re: The 27 February 2010 build (6181) is out.
« Reply #104 on: April 15, 2010, 02:29:38 pm »
<shrug>
I've been using *alot* of IDEs, and I've never experienced that kind of behavior before.
Please name some of them? Visual studio isn't doing it (all versions <=2005, don't know for newer ones).
I've not tested other IDEs in years.

If the Save on OK is implemented, what would be the behavior when there are two instances of C::B?
The second instance should detect the configuration change and then what?

To all: please keep in mind that when one software crashes this is a critical bug. It should be reported and fixed.
And developers fix crashes they know about...
(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!]