Itches, Glitches & Anything Else...

[OrbWeaver]

Yes, it won't be a Scons/GCC issue but an operating system shell issue. This is why you often see ./configure scripts on Linux say "Determining maximum command line size...32767 characters" or something similar.

[greebo]

What can we do about it? Even if we change the intermediate build path as temporary workaround, we will run into troubles soon enough, when new files are added.

 

Can we reconfigure scons to send the linker arguments from an input file (à la g ++

[OrbWeaver]

Good question, there are a few options I guess:

 

1. Increase modularisation of the codebase to reduce command line sizes. This would be a labour-intensive solution which would probably only delay the problem, rather than eliminating it.

2. Use an alternative command-line, maybe the Bash version included with MSYS would allow Scons to run with larger command-lines?

3. Abandon the MinGW/Scons build system on Windows and go with MSVC++ only (but I think you said there were still outstanding problems with using MSVC++ with DarkRadiant, unless they have been fixed).

[greebo]

Nevermind, I could apply this fix here: http://www.scons.org/wiki/LongCmdLinesOnWin32

 

It requires the win32 extensions for python but apart from that, it compiles fine (must add this to the wiki once it's up again). The limit is now 32768 bytes, which is four times our current limit.

 

Good question, there are a few options I guess:

 

1. Increase modularisation of the codebase to reduce command line sizes. This would be a labour-intensive solution which would probably only delay the problem, rather than eliminating it.

2. Use an alternative command-line, maybe the Bash version included with MSYS would allow Scons to run with larger command-lines?

3. Abandon the MinGW/Scons build system on Windows and go with MSVC++ only (but I think you said there were still outstanding problems with using MSVC++ with DarkRadiant, unless they have been fixed).

As for #3: My VC++ build has the GraphTreeModel disabled because the MSVC STL implementation is different to MinGW's (that's the abominable problem with the iterator size we talked about some time ago). I only use it for debugging and when I need a quick compiler (and a superior auto-completion, but I rarely need that ), otherwise I stick to Eclipse.

[greebo]

I was trying to perform a profile run in Linux, but I don't get a gmon.out file after fully recompiling a BUILD="profile". Also, DarkRadiant always segfaults after shutdown - could it be that the gmon.out is only created when DR cleanly shuts down?

 

Does DR segfault on your end? Just opening and closing it is enough to crash it on my system.

[greebo]

Nevermind, I could narrow the crash down - it's happening somewhere in the ~XMLRegistry destructor. Can't say where exactly, but I'll find it.

[OrbWeaver]

There's a couple of GUI interactivity issues I've noticed in the latest build.

 

1. Displaying the Entity Inspector properties takes about 4 seconds when I click on a new object. I believe this is because of the ClassnamePropertyEditor which has to populate the list of classnames and sort them. When I wrote this I originally wanted the list to remain unpopulated until the dropdown was clicked, but I never found a way to implement this.

2. When I select an AI, add a skin property and display the skin browser, I get about a second's delay between clicking in the skins treeview and the selection changing. I have no idea what could cause this, but it doesn't happen with a simple crate.

 

EDIT: There's also a GUI issue with the "shortcut help text" that appears in the status bar expanding the window past the edge of my screen, meaning that I can't click on the close/minimise/maximise buttons any more:

 

[greebo]

1. Displaying the Entity Inspector properties takes about 4 seconds when I click on a new object. I believe this is because of the ClassnamePropertyEditor which has to populate the list of classnames and sort them. When I wrote this I originally wanted the list to remain unpopulated until the dropdown was clicked, but I never found a way to implement this.

Yes, that's probably the reason. How about storing the Classname in some kind of singleton?

 

2. When I select an AI, add a skin property and display the skin browser, I get about a second's delay between clicking in the skins treeview and the selection changing. I have no idea what could cause this, but it doesn't happen with a simple crate.

The AI mesh loader takes so long, I suspect. Both the mesh and the textures take a bit of time loading (there are no editor images of the textures, that's why it is more taxing than regular models).

[greebo]

EDIT: There's also a GUI issue with the "shortcut help text" that appears in the status bar expanding the window past the edge of my screen, meaning that I can't click on the close/minimise/maximise buttons any more:

Ok, so it looks like the help text is stretching the window. Hm. What can we do about this, apart from trimming the text (which is probably the last resort - this depends heavily on the screen resolution).

[Tels]

Ok, so it looks like the help text is stretching the window. Hm. What can we do about this, apart from trimming the text (which is probably the last resort - this depends heavily on the screen resolution).

 

It also happens on my 1600x1200 screen (because I have a bigger font-size to actually read stuff), and it happens for as long as I can remember.

 

Do we really need all the stuff in the status bar? Can't say I ever looked at it really.

[greebo]

I thought it was helping people, but if it's an annoyance for users with large fonts or lower horizontal screen resolution, I can also disable it. Or make it an option.

 

Generally, I like all the status bar info, although I don't need the modifier button help.

[Komag]

HA! I never noticed this issue. It doesn't do it for me when DR is maximized, even when I have a shader name in the clipboard (which can get pretty long). I press Shift and the status bar gets thrown out to the right partially offscreen, but the whole DR window is unaffected.

 

But when I'm NOT maximized, it bumps the window out. But if I have the un-maximized window stretched large to nearly fill the screen and there is a shader name, it DOES bump it out past the edge of my desktop resolution, but as soon as I let go of Shift it pops back some but not quite all the way back.

 

Is it possible to move some of the info the top bar, next to "Rotate func_* Entities around origin" button? I have plenty of space up there! And trimming the text couldn't hurt I think, such as "Brsh, Ptch, Ent" and "Shader" (But those actually kinda suck)

 

I really like the modifier help and would be sad to see it go. If this problem only shows up when DR is not maximized, then for those of us who always use it maximized it would be good to at least have a toggle to turn on the modifier help text.

[greebo]

I can make it an option, if that helps. I was meaning to refactor the status bar handling anyway, so that plugins can use it through a proper UI manager interface, but that's future stuff.

[Tels]

And trimming the text couldn't hurt I think, such as "Brsh, Ptch, Ent" and "Shader" (But those actually kinda suck)

 

I don't think trimming is a good idea - it just makes people go "huh?". Anyway, do we need these information all the time in the status bar, as you can get the same info via "Map -> Info"?

[OrbWeaver]

Yes, that's probably the reason. How about storing the Classname in some kind of singleton?

 

I could solve the delay problem by using a GTK idle callback to populate the list, so that the PropertyEditor will be displayed immediately but populate itself in a few seconds, rather than blocking the GUI until the population is completed.

 

However, there is a problem with typing text into the combo box, because it seems to update the entity property with each keystroke which is (1) very slow and (2) stops the autocompletion from working. There used to be a ClassnamePropertyEditor complete with an Apply button, but it doesn't seem to be there any more -- did I delete it at some point?

 

EDIT: Yes, I removed it in revision 544 it would seem. That's a pity, but I guess it wasn't a huge amount of work to re-implement.

[greebo]

I could solve the delay problem by using a GTK idle callback to populate the list, so that the PropertyEditor will be displayed immediately but populate itself in a few seconds, rather than blocking the GUI until the population is completed.

I was thinking about a GtkTreeStore structure which gets populated the first time and is then re-used - similar to the ModelSelector.

EDIT: Yes, I removed it in revision 544 it would seem. That's a pity, but I guess it wasn't a huge amount of work to re-implement.

Why did you remove it - was it broken? Maybe it was working better than my version, so feel free to ditch mine if yours works better.

[OrbWeaver]

I was thinking about a GtkTreeStore structure which gets populated the first time and is then re-used - similar to the ModelSelector.

 

That might be a good next step, since the idle callback improves the initial display of the PropertyEditor but still produces a delay if you try to click on anything else during the few seconds it is populating the list. Some kind of cache ought to help this, although care would be needed to ensure it was updated if the class tree changed for any reason.

 

Why did you remove it - was it broken? Maybe it was working better than my version, so feel free to ditch mine if yours works better.

 

It was out of action for a while due to the performance problems, so I guess I must have just abandoned it. I have already added an Apply button to the existing EClassPropertyEditor, so there is nothing to choose between them at this point.

[SneaksieDave]

I was going to grab the latest DR just now and found a couple of problems:

 

-Newest version is Nov10, is that right? I thought there was one in early Dec but I could be looking at the wrong file, because I'm looking right at the FTP, not sourceforge (see next)

-I can't get the file from the link on sourceforge at all, because of a possible file problem and apparent bug in the script (I guess?) - each time I click the link, it simply adds "/files" to the URL and reloads the page.

 

I noticed this when my address bar read:

http://darkradiant.sourceforge.net/snapsho..._latest_SVN.zip

 

 

Edit: okay the board is shortcutting my link. Well anyway, it is:".../snapshot.php/files/files/files/..."

[greebo]

I was going to grab the latest DR just now and found a couple of problems:

 

-Newest version is Nov10, is that right? I thought there was one in early Dec but I could be looking at the wrong file, because I'm looking right at the FTP, not sourceforge (see next)

I'm currently uploading a new version to the FTP. I also pointed the link from the sourceforge page back to the FTP. I only put the file on sourceforge, because the FTP was down the last time I wanted to upload a file.

 

-I can't get the file from the link on sourceforge at all, because of a possible file problem and apparent bug in the script (I guess?) - each time I click the link, it simply adds "/files" to the URL and reloads the page.

I just checked, the link works for me. Anyways, I replaced the link now with one to TDM FTP, so in a couple of minutes the new snapshot is available (latest SVN).

[SneaksieDave]

Thanks, it's coming now. Very bizarre, whatever was going on at sourceforge before. I wasn't getting proper formatting, no black background (just white with black text), just in general like something was badly busted. Even with forced refreshes. Now it's okay.

[greebo]

@OrbWeaver: I've updated the GTK+ headers to 2.12.3 and updated the sconscript to automatically setup the install folder with all the necessary GTK+ binaries. The SVN repository is pretty self-consistent now (in Win32, that is).

 

I remember that you weren't too fond of including dependencies in the repository (unlike me) - what would your proposed solution be to split dependencies from code? Should we move these into a different branch/repository or should we go the GtkRadiant way of providing a ZIP package with all the binaries for Win32?

 

Btw: I also plan to upgrade the boost headers to 1.34.1 in the near future to be up to date.

[OrbWeaver]

I'm quite happy to have the dependencies in the repository, but I would prefer a different area (possibly a top-level directory) to contain them, rather than having them in the main source tree. This would make the working copy much smaller on Linux, and might get the Eclipse indexer to work better because there would be fewer source files.

 

I don't know what happens though if an SVN working copy contains a subdirectory which is a working copy of another remote URL. We'd need to make sure there would be no errors when trying to make commits.

[greebo]

You mean something like this?

 

URL/svnroot/darkradiant/trunk/darkradiant/

URL/svnroot/darkradiant/trunk/dependencies/

[OrbWeaver]

Yes, exactly like that. Windows users could check out the additional dependencies directory into their working copy, whereas the Linux users could ignore it. The SVN externals feature might streamline this process a bit.

[greebo]

Yes, exactly like that. Windows users could check out the additional dependencies directory into their working copy, whereas the Linux users could ignore it. The SVN externals feature might streamline this process a bit.

Ah, yes, this sounds handy. I'll try to set it up like this. I'd also like to incorporate the other w32/ binaries into that folder then.

 

I wonder - when I define this external reference, how can Linux users suppress checking out the Win32 dependencies? If this is not possible, everything would be checked out to a Linux working copy too.

 

edit: It might be this: --ignore-externals, this should be tested in Linux once we have externals.