Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Batch builds currently broken in SVN

<< < (2/3) > >>

MortenMacFly:

--- Quote from: thomas on December 21, 2007, 08:24:34 pm ---Please don't blame the logging system.

--- End quote ---
I don't! I blame compilermessages.cpp. ;-)


--- Quote from: thomas on December 21, 2007, 08:24:34 pm ---Inserting that if(control) may prevent the crash, but it doesn't really fix anything, it's still all screwed up.

--- End quote ---
I agree on that completely. I said it's a workaround for now until a proper fix. My problem is that I didn't write the logger and the modification either.- So I believe for me it's even harder to understand that for you... Hehe... ;-)

MortenMacFly:

--- Quote from: thomas on December 21, 2007, 08:24:34 pm ---You cannot even tell for sure what is added to which window when.

--- End quote ---
I agree here, too. But: For the batch build I wonder if this is really what we want then. We want for sure that the log messages are printed on the screen. So why do we use a logger here at all then?! This makes me ask in general: If we can't rely on the loggers (which is OK for a logger) why do we print important messages to a logger then, even in "non-batch-build-C::B"? What would you suppose to do instead, Thomas?!

thomas:
What I wanted is this:

a) normal startup:
- the application starts, and creates a main frame
- all plugins are loaded, plugins can install whatever loggers they might need later (no GUI available yet)
- the main frame queries the installed loggers for controls
- if a logger has a control, it's added to the info pane (now GUI is available, and output is visible)

b) batch startup:
- the application either does not create a main frame at all (not needed) or, if that is a problem for some reason, creates one but doesn't show it
- only the compiler plugin (and maybe 1-2 other select plugins, such as EnvVar) is loaded, as nothing else is needed
- a simple window is created, just a plain normal window
- the compiler's log is asked for a control, which is added to the window (everything else is just ignored, it doesn't matter)
- batch build runs, finishes, compiler plugin unregisters its logger, the window is closed, the application is closed
- no need to do anything else -- the window will delete the control, and LogManager will delete the Logger
- if we are sure that the compiler does not output anything after the build is finished (a reasonable assumption) then we don't even need to unregister the Logger (that would keep an invalid pointer dangling around for a few milliseconds, but if it is guaranteed not to be accessed, that's ok)
- the compiler plugin (or any other component) ideally does not even know that a batch build is running (well, it still may have to know if no main frame is created, because then no menu entries and toolbar buttons can be added, but that would be trivial to check).

And what we have is this:
a) and b) likewise:
- a main frame is created and listens to messages, and in response adds controls to the info pane which is owned by either the main frame or BatchLogDialog (and, this class does not even seem to exist at all, I could not find it with code completion lookup, nor with global file search ---> how does this compile at all??? I'm clueless...)
- there are a lot of separate branches for either "normal" or "batch" mode in all involved components, although none of those components should actually need to bother
- everything is dynamic and cool, but it does not work, and it's a pain to figure why

This is another example for complexity being not a good thing. If we absolutely have to load/unload plugins at runtime (I personally don't see why we need this), there is still no reason why you have to add/remove loggers dynamically too.
It is perfectly acceptable that a custom logger (or rather, its control) stays visible if you unload a plugin at runtime (the user can still hide the tab if he doesn't want to see it), and it is perfectly acceptable that no custom logger is visible if a plugin was dynamically loaded after startup. For one reason, almost no plugin needs to install a custom logger anyway, and if it is really so utterly important, then the user can relaunch the application quickly, this is really no big burden.
Personally, I don't even think it is asked too much to relaunch the application to load a new plugin or to unload another one, it keeps things simple and failsafe, plus, you don't load/unload plugins 35 times per day anyway. Firefox which I'm using to type this text right now loads its plugins at startup, and there is nothing wrong with it.

Regarding non-Loggers added to the InfoPane, one could argue. Although I don't deem it good to add/remove controls at runtime (and move it between different panes), if this is absolutely wanted... ok then. Again, I would prefer things to be simple, but... there is one difference. Here we're talking about something that is entirely optional and entirely proprietary. What makes it acceptable is that the application does not know anything or give a crap about the pointer it is given. Thus, the complexity doesn't lie in the application or the managers.

killerbot:
my biggest question is, where can we start to fix this ?
Regarding from things good or bad; they have worked, and now it crashes. Why can I crash now, and how to fix this ?

In the example of batch build, we have for sure 2 (new?) issues :

- the compiler output is not visible, where this use to work in the past (why is that windows plain grey now)
- the whole thing crashes

PS: How can I right click on a cbp file and have it build by CB in linux (more specifically OpenSuse 10.3 or 10.2, so I can check if we have similar issues on linux), according to Yiannis it works in linux.

Jenna:

--- Quote from: killerbot on December 22, 2007, 09:42:11 am ---...
In the example of batch build, we have for sure 2 (new?) issues :
...
- the compiler output is not visible, where this use to work in the past (why is that windows plain grey now)

--- End quote ---

The grey window appears since some releases. I don't know exactly when (but I try to investigate), but I thought it was a problem with my virtual w2k.
The crash does not happen for me.

On linux when I execute
--- Code: ---codeblocks -ns --no-batch-window-close --build CodeBlocks-unix.cbp
--- End code ---
it works without problems, and I have two tabs in the window ("Build Log" and "Script Console").
On windows the same commandline does not work.
Another difference is that that on win the dialog seems to run asynchron, that means after running the commandthe prompt immediately returns and then the dialog opens.
On Linux all output also goes to console and the prompt does not reappear before the dialog is closed.

What I want to say is, that there seems to be a difference between this two OSes and even between different installations and/or versions on/of win.

Navigation

[0] Message Index

[#] Next page

[*] Previous page