[Geany-Devel] Ping on Bug #943 - windows build command

[Dimitar Zhekov]

On Wed, 16 Oct 2013 10:52:33 +1100
Lex Trotman <elextr at gmail.com> wrote:

> On 16 October 2013 04:05, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> 
> > A good news first: using a bit of Scope code, I was able to pipe
> > 12.3MB of mixed stdout and stderr output into Geany, in async mode,
> > for just a few seconds. [...]
> >
> > Of course, there will be more tests, especially sync, before I post a
> > patch to SF Bug #943.
> >
> 
> That sounds encouraging, maybe post a PR and just refer to it from the bug.

Actually, I finished most of it, what remains is mainly blocking Geany
while the new async tools execution is running.

Sync spawning is not good, because I'm using the Geany message loop for
async I/O (somewhat similar to g_main_context_add_poll), not real Win32
events and threads as GLib does.

Locking the file, as Matthew suggested, will not be sufficient: one can
still close it, reload it, and of course change the selection
(SCI docs assume close/reload are be blocked for background saving).

What remains, without going too deep, is a modal dialog. Annoying, of
course, but with the benefit that you can easily stop a bad process.

> > That being said, I agree we need something better than the current
> > (a bit naive) implementations, and I know where to find it. :) Whether
> > the leading developers will accept such changes is another matter.
> >
> 
> For me, you will be *very* welcome if you can provide a proper set of
> multi-platform spawn with/without stdin/stdout/stderr that can remove the
> #ifdef G_OS_WIN32 stuff from build.c that I have been tiptoeing around for
> years not daring to pass the mouse over it in case it broke (worse). :)

For now, I'll concentrate on working build, tools and search.

Of course, with a proper win~1 blocking I/O, tools deadlocked, even
faster that the sync spawn in build. Another bug in tools is that, when
writing to the process stdin, it counts the remaining bytes, but always
write()-s from the beginning of the selection. :)

As of a rewrite, maybe after we have at least working GPoll in glib,
it would be much easier. That's more about organizing the read-error /
write-error / process-exit events properly than platform compatibility.
For example, currently tools waits for read stderr to return something
other than G_IO_STATUS_NORMAL or G_IO_STATUS_AGAIN fail to decide that
it's time to replace the selection (or skip the replacement, if there
were any error messages). That has some merit, there may be buffered
messages after the process dies, but is not the best thing.

Don't worry about the build SYNC spawn, I'll kill it in any case.

-- 
E-gards: Jimmy