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

[Lex Trotman]

On 16 October 2013 04:05, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:

> On Tue, 15 Oct 2013 11:29:17 +1100
> Lex Trotman <elextr 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.
>
> There is a delay when scrolling the messages down, and the scroll bar
> gets updated - seems that GtkTreeView does not handle all lines until
> you come to them (depending on some options). Pretty reasonable.
>
> 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.


> [...]
> tools.c does replace the selection without checking if the document
> is still valid and whether the selection has been changed. Working
> with a closed document may cause a crash, so it looks intentional.
>

Sounds like it should use a synchronous spawn.


> [...]
>
> The last time FiF-ed, glib did not contain any calls to PeekNamedPipe
> or SetNamedPipeHandleState. I am not aware of any way to implement
> async anonymous pipe I/O under Windows without these, and see no
> reason to check the various glib functions one by one. (Don't be
> fooled by "Named", these work for anonymous pipes, and in fact the
> win~1 named pipes don't need them as they support event based I/O).
>

Ok, and Thomas supports you there.


> [...]
> >
> > Basically the whole spawning thing needs to be looked at critically,
> > especially those uses that do i/o to the child process.  A working
> version
> > of each permutation sync/async, reads/writes/both needs to be put in
> utils
> > and all of Geany should then use that implementation and the callbacks
> use
> > known good idioms.
>
> Blocking the GTK+ message loop (aka Geany) to avoid document changes
> and using blocking pipe I/O are two different things, and we don't
> need the later AFAIK.
>

Agree, by sync (synchronous) we tend to mean blocking Geany until finished.
 By async we mean not doing so.  As you say it would be better to achieve
it without blocking i/o because of the deadlock risks.  Anything that is
going to modify the buffer should be synchronous, things like build should
be asynchronous.



>
> A good blocking without rewriting the current code is by displaying a
> small modal dialog "Running FOO..." with a Cancel button. The keyboard
> and mouse events are redirected to it, keeping the documents fair, and
> there's a way to stop a slow process which intentionally blocks Geany.
>
>
Thats a possibility, though some people would find them annoying.  But
having their output work correctly is more important :)



> 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). :)

@Thomas,

Sounds like a useful patch, definitely pass it to glib, I'm sure the
windows support guy(s?) will be glad of help.  In the mean time is it
licensed suitably for Dimitar to steal?

Cheers
Lex


>
> --
> E-gards: Jimmy
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131016/e70828d8/attachment-0001.html>