Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

Hi Al,
rest assured that this should not be sarcasm! Do not think that I'm 
joking here!
And of course the source is correct, and yes i know this sounds 
impossible!!!


Hundreds of lines looks this weird, alsowith vala-compiled .c files.
To check how my command looks like I do string.joinv(" ", spawn_args)+"\n"
The first command still running with Process.spawn_sync and working 
glib-compile-resources 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\resources.xml 
--target=C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\resources.c 
--sourcedir=C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\resources 
--generate-source


The "Subprocess" with errors looks like this:( Tried also-X 
-DGETTEXT_PACKAGE=\"valaDevelop\" -X -DVERSION=\"0.42\" )
valac -g 
--output=C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\bin\valaDevelop 
--define=WINDOWS -X -DGETTEXT_PACKAGE="valaDevelop" -X -DVERSION="0..42" 
--pkg=gdk-3.0 --pkg=gee-0.8 --pkg=gio-2.0 --pkg=gio-windows-2.0 
--pkg=glib-2.0 --pkg=gmodule-2.0 --pkg=gtk+-3.0 --pkg=gtksourceview-3.0 
--pkg=json-glib-1.0 --pkg=libvala-0.42 --pkg=libxml-2.0 
--pkg=webkit2gtk-4.0 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionDialogs\package_options_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionDialogs\project_options_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionDialogs\rename_folder_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionDialogs\resource_create_file_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionDialogs\solution_create_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionDialogs\source_create_file_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionWidgets\IOptionWidget.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionWidgets\item_options.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionWidgets\project_options.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\OptionWidgets\solution_options.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\SearchAndReplace\replace_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\SearchAndReplace\search_and_replace.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\SearchAndReplace\search_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\SearchAndReplace\search_replace_dialog.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\SymbolFinder\reporter.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\SymbolFinder\symbol_finder.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\application_window.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\breakpoint_bookmarks.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\breakpoint_hit.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\completion_provider..vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\config.vapi 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\context_menu.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\debugger.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\debugger_symbols.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\globals.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\import_options.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\item_buildtype.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\item_type.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\main.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\main_paned.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\new_folder.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\new_solution_file.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\overview_tree_columns.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\overview_tree_store..vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\source_gutter_renderer_breakpoint.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\stats.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\status_list.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\switch_open_files.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\tab_header.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\wrong_location.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\xml_configuration.vala 
C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\resources.c 
--gresources=C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\resources.xml 
--gresourcesdir=C:\msys64\home\Wolfgang\Projekte\vDevelop\valaDevelop\resources 




Am 14.03.19 um 19:56 schrieb Al Thomas via vala-list:

> On Wednesday, 13 March 2019, 00:10:30 GMT, Wolfgang Mauer 
 wrote:  > Tried this, run perfect on linux, runs 
"better" on win

Are you being sarcastic here? I've read through the rest of 

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

  > On Thursday, 14 March 2019, 05:59:16 GMT, Wolfgang Mauer 
 wrote: > So please give me a hand.. Is this a 
vala or GLib problem?
> >As far as the bug goes it 
>is:https://gitlab.gnome.org/GNOME/vala/issues/664 > 
>https://gitlab.gnome.org/GNOME/glib/issues/1512

Looking over the report again I think the callback from g_child_watch_add () 
wasn'tbeing called so the process exited by the output kept being piped in. 
That's why itwas null.
Given the GLib API is a higher level API to abstract away platform 
implementationsthen the first place to look is GLib. I have made a quick note 
onhttps://gitlab.gnome.org/GNOME/glib/issues/1512that this is occurring on both 
Windows and macOS.
One thing you could try is to find an alternative way of tidying up after the 
output hasfinished. The GLib documentation for g_spawn_async_with_pipes () ( 
https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-async-with-pipes
 )is detailed, with notes on cross platform support.
So the answer to your question is neither. The problem needs further 
investigation beforethe direct cause can be identified and fixed.


  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

   > On Wednesday, 13 March 2019, 00:10:30 GMT, Wolfgang Mauer 
 wrote:  > Tried this, run perfect on linux, runs 
"better" on win

Are you being sarcastic here? I've read through the rest of your mail and you 
aregetting a cc exited error. You're not running the program, the program fails 
to compile:
> C:msys64homeWolfgangProjekte
>     Develop
> alaDevelopml_configuration.vala:40:10: error: \x used with no following 
> hex digits
> : warning: missing terminating " character
> : warning: missing terminating " character
> error: cc exited with status 1

This probably has something to do with the Windows file path separatorbeing a 
backslash.

  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

So please give me a hand.. Is this a vala or GLib problem?

>As far as the bug goes it 
is:https://gitlab.gnome.org/GNOME/vala/issues/664 
https://gitlab.gnome.org/GNOME/glib/issues/1512


If a vala problem i will replace it by C-Code an make valaDevelop 
available for win and mac?!



Thanks


Am 12.03.19 um 23:03 schrieb Wolfgang Mauer:

Maybe some "valac" developers around here
Well i found the "problem", it wasn't my code but i tried the example 
from the valadoc 
"https://valadoc.org/glib-2.0/GLib.Process.spawn_async_with_pipes.html";


Just let it compile himself
    string[] spawn_args = {"valac", "--pkg", "glib-2.0", 
"GLib.Process.spawn_async_with_pipes.vala"};



and "voilà" on win and mac the output is like this, never ending.


stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NU




Am 12.03.19 um 18:04 schrieb Rico Tzschichholz:

Imho, a suggestion to join #vala on IRC to target a wider audience for
problem solving, is help.

In case of a platform-specific toolkit issues, #gtk on GIMPnet will
likely be even more beneficial.

Cheers,
Rico

Am 12.03.19 um 17:20 schrieb Wolfgang Mauer:

I already find out that "closed-source" is not wanted.
I think this list is for helping each other, so i ask for. If i can 
help

someone else, just let me know i will do

Greetings
Wolfgang


Am 12.03.19 um 17:04 schrieb Corentin Noël:

Hi Wolfgang,

Debugging your software using this mailing list is going to be very
painful, especially for closed-source software. Feel free to pop in
#vala on IRC GIMPnet (irc.gimp.org) which is a better tailored
communication system for this kind of tasks.

Herzliche Grüße,
Corentin Noël


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

Tried this, run perfect on linux, runs "better" on win

                try

                {
                    var mainloop = new MainLoop();
                    SourceFunc quit = ()=>
                    {
                    mainloop.quit ();
                    return Source.REMOVE;
                    };
                    read_piped_commands.begin(spawn_args, quit, 
projectName);

                    mainloop.run();
                }
                catch (SpawnError e)
                {
                    print ("Error: %s\n", e.message);
                }
            }
        }

        async void read_piped_commands(string[] spawn_args, SourceFunc 
quit, string projectName)

        {
            var subprocess = new Subprocess.newv(spawn_args, 
(SubprocessFlags.STDOUT_PIPE|SubprocessFlags.STDERR_MERGE));
            var output = new DataInputStream 
(subprocess.get_stdout_pipe());

            try
            {
            string? line = null;
            do
            {
                    line = yield output.read_line_async ();
                    if (line != null)
                    {
buildTextView.buffer.insert_at_cursor(line+"\n", -1);
                        var mark = buildTextView.buffer.get_insert();
                        buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
                        statusList.AddOutput(projectName, line);
                    }
        }while (line != null);
            }
            catch (Error error)
            {
            print (@"Error: $(error.message)\n");
            }
            quit ();
        }


But on win it looks like the error still goes to terminal and still 
looks weird :-(


No stderr in "buildTextView.buffer", stdout are ok

..

C:msys64homeWolfgangProjekte
    Develop
alaDevelopml_configuration.vala:40:10: warning: unknown escape sequence: 
'\m'

C:msys64homeWolfgangProjekte
    Develop
alaDevelopml_configuration.vala:40:10: warning: unknown escape sequence: 
'\h'

C:msys64homeWolfgangProjekte
    Develop
alaDevelopml_configuration.vala:40:10: warning: unknown escape sequence: 
'\W'

C:msys64homeWolfgangProjekte
    Develop
alaDevelopml_configuration.vala:40:10: warning: unknown escape sequence: 
'\P'

C:msys64homeWolfgangProjekte
    Develop
alaDevelopml_configuration.vala:40:10: error: \x used with no following 
hex digits

: warning: missing terminating " character
: warning: missing terminating " character
error: cc exited with status 1



Am 12.03.19 um 23:51 schrieb Wolfgang Mauer:

Thank you very much


Am 12.03.19 um 23:46 schrieb Al Thomas via vala-list:
  > On Tuesday, 12 March 2019, 22:40:17 GMT, Wolfgang Mauer 
 wrote:

Are there any sample using "GLib.Subprocess" with async
stdin/stdout/stderr ?

See https://stackoverflow.com/a/54391519
That one splices the output from one command to the input of another. 
So a bit more than you probablyneed, but a good start.


Al
   ___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

Thank you very much


Am 12.03.19 um 23:46 schrieb Al Thomas via vala-list:

  > On Tuesday, 12 March 2019, 22:40:17 GMT, Wolfgang Mauer 
 wrote:

Are there any sample using "GLib.Subprocess" with async
stdin/stdout/stderr ?

See https://stackoverflow.com/a/54391519
That one splices the output from one command to the input of another. So a bit 
more than you probablyneed, but a good start.

Al
   
___

vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

 > On Tuesday, 12 March 2019, 22:40:17 GMT, Wolfgang Mauer 
 >  wrote: 
> Are there any sample using "GLib.Subprocess" with async 
> stdin/stdout/stderr ?
See https://stackoverflow.com/a/54391519
That one splices the output from one command to the input of another. So a bit 
more than you probablyneed, but a good start.

Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

I will try, but can't find any vala example...

Are there any sample using "GLib.Subprocess" with async 
stdin/stdout/stderr ?



Am 12.03.19 um 23:22 schrieb Al Thomas via vala-list:
  
> On Tuesday, 12 March 2019, 22:03:28 GMT, Wolfgang Mauer  wrote:

  > Well i found the "problem", it wasn't my code but i tried the example

from the valadoc
"https://valadoc.org/glib-2.0/GLib.Process.spawn_async_with_pipes.html";
Just let it compile himself
     string[] spawn_args = {"valac", "--pkg", "glib-2..0",
"GLib.Process.spawn_async_with_pipes.vala"};
and "voilà" on win and mac the output is like this, never ending.
  

stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr:

Firstly, use GLib.Subprocess. It is a newer and easier API.
As far as the bug goes it 
is:https://gitlab.gnome.org/GNOME/vala/issues/664https://gitlab.gnome.org/GNOME/glib/issues/1512
Really that needs someone with access to Mac and Windows
to write a relevant test case in C for g_spawn_async_with_pipesAll I can find 
is https://gitlab.gnome.org/GNOME/glib/blob/master/tests/spawn-test.c






  
___

vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

 
   > On Tuesday, 12 March 2019, 22:03:28 GMT, Wolfgang Mauer 
 wrote:  
 > Well i found the "problem", it wasn't my code but i tried the example 
> from the valadoc 
> "https://valadoc.org/glib-2.0/GLib.Process.spawn_async_with_pipes.html";

> Just let it compile himself
>    string[] spawn_args = {"valac", "--pkg", "glib-2.0", 
> "GLib.Process.spawn_async_with_pipes.vala"};
> and "voilà" on win and mac the output is like this, never ending
 
> stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 

Firstly, use GLib.Subprocess. It is a newer and easier API.
As far as the bug goes it 
is:https://gitlab.gnome.org/GNOME/vala/issues/664https://gitlab.gnome.org/GNOME/glib/issues/1512
Really that needs someone with access to Mac and Windows 
to write a relevant test case in C for g_spawn_async_with_pipesAll I can find 
is https://gitlab.gnome.org/GNOME/glib/blob/master/tests/spawn-test.c






 
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

Maybe some "valac" developers around here
Well i found the "problem", it wasn't my code but i tried the example 
from the valadoc 
"https://valadoc.org/glib-2.0/GLib.Process.spawn_async_with_pipes.html";


Just let it compile himself
    string[] spawn_args = {"valac", "--pkg", "glib-2.0", 
"GLib.Process.spawn_async_with_pipes.vala"};



and "voilà" on win and mac the output is like this, never ending


stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 
(NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: 
(NULL)stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: (NU




Am 12.03.19 um 18:04 schrieb Rico Tzschichholz:

Imho, a suggestion to join #vala on IRC to target a wider audience for
problem solving, is help.

In case of a platform-specific toolkit issues, #gtk on GIMPnet will
likely be even more beneficial.

Cheers,
Rico

Am 12.03.19 um 17:20 schrieb Wolfgang Mauer:

I already find out that "closed-source" is not wanted.
I think this list is for helping each other, so i ask for. If i can help
someone else, just let me know i will do

Greetings
Wolfgang


Am 12.03.19 um 17:04 schrieb Corentin Noël:

Hi Wolfgang,

Debugging your software using this mailing list is going to be very
painful, especially for closed-source software. Feel free to pop in
#vala on IRC GIMPnet (irc.gimp.org) which is a better tailored
communication system for this kind of tasks.

Herzliche Grüße,
Corentin Noël


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

Thank you very much!

I found my problem, was a "self-made thinking error"(threading and scope)

>One thing to try is compiling with debug information and then use 
G_DEBUG=fatal-criticals and a debugger.
I use valaDevelop to debug valaDevelop, and i have an option "Break on 
critical" ;-)


Wolfgang

Am 12.03.19 um 19:21 schrieb Al Thomas via vala-list:
  


> On Tuesday, 12 March 2019, 15:48:59 GMT, Wolfgang Mauer 
 wrote:

With Linux everything works like expected with no errors/warnings but on
Windows(10/MSYS64) and macOS it get lots of errors.
(valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460:
gtk_text_view_get_buffer: assertion 'GTK_IS_TEXT_VIEW (text_view)' failed

These are type checks for the GType system. 
Seehttps://gitlab.gnome.org/GNOME/gtk/blob/master/gtk/gtktextview.h#L42https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-TYPE-CHECK-INSTANCE-TYPE:CAPS
Probably text_view is null, so you may have some kind of scoping problem. You 
are usingclosures that should encapsulate the enclosing scope.
One thing to try is compiling with debug information and then use 
G_DEBUG=fatal-criticals and a debugger.
For example see 
https://wiki.gnome.org/Projects/Vala/DeveloperDocumentation#Debugging

You are then in to checking versions of libraries on macOS and Windows and to 
see if
they are up to date as possible or comparable with what was used on Linux.

You also need to be checking the version of Vala used and the C code generated 
to make sure
there is nothing unusual.


Any idea ?

Nothing specific, but the above might give you some things to try.


                         // Timeout with 0 goes to "UI-Thread" ?! >                
        GLib.Timeout.add(0, () =>

The 0 specifies the delay before the timeout source is called, nothing to do with a 
thread.GLib.Timeout.add() is a convenience method: 
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-addIt 
adds the timeout to the global GMainContext and the docs advise "the callback will 
be invoked in whichever thread is running that maincontext"To specify the 
GMainContext you would need to use https://valadoc.org/glib-2.0/GLib.TimeoutSource.html 
and then attach() it to the relevantGMainContext.

Al




   
___

vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

 

   > On Tuesday, 12 March 2019, 15:48:59 GMT, Wolfgang Mauer 
 wrote:  
> With Linux everything works like expected with no errors/warnings but on 
> Windows(10/MSYS64) and macOS it get lots of errors.

> (valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
> gtk_text_view_get_buffer: assertion 'GTK_IS_TEXT_VIEW (text_view)' failed
These are type checks for the GType system. 
Seehttps://gitlab.gnome.org/GNOME/gtk/blob/master/gtk/gtktextview.h#L42https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-TYPE-CHECK-INSTANCE-TYPE:CAPS
Probably text_view is null, so you may have some kind of scoping problem. You 
are usingclosures that should encapsulate the enclosing scope.
One thing to try is compiling with debug information and then use 
G_DEBUG=fatal-criticals and a debugger.
For example see 
https://wiki.gnome.org/Projects/Vala/DeveloperDocumentation#Debugging

You are then in to checking versions of libraries on macOS and Windows and to 
see if 
they are up to date as possible or comparable with what was used on Linux.

You also need to be checking the version of Vala used and the C code generated 
to make sure
there is nothing unusual.

> Any idea ?
Nothing specific, but the above might give you some things to try.

>                        // Timeout with 0 goes to "UI-Thread" ?! >             
>           GLib.Timeout.add(0, () =>

The 0 specifies the delay before the timeout source is called, nothing to do 
with a thread.GLib.Timeout.add() is a convenience method: 
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-addIt
 adds the timeout to the global GMainContext and the docs advise "the callback 
will be invoked in whichever thread is running that maincontext"To specify the 
GMainContext you would need to use 
https://valadoc.org/glib-2.0/GLib.TimeoutSource.html and then attach() it to 
the relevantGMainContext.

Al




  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Rico Tzschichholz]

Imho, a suggestion to join #vala on IRC to target a wider audience for
problem solving, is help.

In case of a platform-specific toolkit issues, #gtk on GIMPnet will
likely be even more beneficial.

Cheers,
Rico

Am 12.03.19 um 17:20 schrieb Wolfgang Mauer:
> I already find out that "closed-source" is not wanted.
> I think this list is for helping each other, so i ask for. If i can help
> someone else, just let me know i will do
> 
> Greetings
> Wolfgang
> 
> 
> Am 12.03.19 um 17:04 schrieb Corentin Noël:
>> Hi Wolfgang,
>>
>> Debugging your software using this mailing list is going to be very
>> painful, especially for closed-source software. Feel free to pop in
>> #vala on IRC GIMPnet (irc.gimp.org) which is a better tailored
>> communication system for this kind of tasks.
>>
>> Herzliche Grüße,
>> Corentin Noël



signature.asc
Description: OpenPGP digital signature
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

I already find out that "closed-source" is not wanted.
I think this list is for helping each other, so i ask for. If i can help 
someone else, just let me know i will do


Greetings
Wolfgang


Am 12.03.19 um 17:04 schrieb Corentin Noël:

Hi Wolfgang,

Debugging your software using this mailing list is going to be very
painful, especially for closed-source software. Feel free to pop in
#vala on IRC GIMPnet (irc.gimp.org) which is a better tailored
communication system for this kind of tasks.

Herzliche Grüße,
Corentin Noël

Le mardi 12 mars 2019 à 16:51 +0100, Wolfgang Mauer a écrit :

Of course there is a "return false;" at the end of

GLib.Timeout.add(0, () =>
{
  buildTextView.buffer.insert_at_cursor(line, -1);
  var mark = buildTextView.buffer.get_insert();
  buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
  return false;
}


Am 12.03.19 um 16:48 schrieb Wolfgang Mauer:

GLib.Timeout.add(0, () =>
 {
buildTextView.buffer.insert_at_cursor(line, -1);
 var mark =
buildTextView.buffer.get_insert();
buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
 }

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list



___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Corentin Noël]

Hi Wolfgang,

Debugging your software using this mailing list is going to be very
painful, especially for closed-source software. Feel free to pop in
#vala on IRC GIMPnet (irc.gimp.org) which is a better tailored
communication system for this kind of tasks.

Herzliche Grüße,
Corentin Noël

Le mardi 12 mars 2019 à 16:51 +0100, Wolfgang Mauer a écrit :
> Of course there is a "return false;" at the end of
> 
> GLib.Timeout.add(0, () =>
> {
>  buildTextView.buffer.insert_at_cursor(line, -1);
>  var mark = buildTextView.buffer.get_insert();
>  buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
>  return false;
> }
> 
> 
> Am 12.03.19 um 16:48 schrieb Wolfgang Mauer:
> > GLib.Timeout.add(0, () =>
> > {
> > buildTextView.buffer.insert_at_cursor(line, -1);
> > var mark =
> > buildTextView.buffer.get_insert();
> > buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
> > }
> 
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list



___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

Of course there is a "return false;" at the end of

GLib.Timeout.add(0, () =>
{
    buildTextView.buffer.insert_at_cursor(line, -1);
    var mark = buildTextView.buffer.get_insert();
    buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
    return false;
}


Am 12.03.19 um 16:48 schrieb Wolfgang Mauer:

GLib.Timeout.add(0, () =>
                        {
buildTextView.buffer.insert_at_cursor(line, -1);
                            var mark = buildTextView.buffer.get_insert();
buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
                        }

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] multithreading -> weird behaviour on win(msys) and macOS

[Wolfgang Mauer]

I have a strange behavior between Ubuntu/MSYS and macOS
I have a output window (buildTextView) and i like to put all output from 
"spawn_async_with_pipes" to the end of the buffer.


With Linux everything works like expected with no errors/warnings but on 
Windows(10/MSYS64) and macOS it get lots of errors.


(valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
gtk_text_view_get_buffer: assertion 'GTK_IS_TEXT_VIEW (text_view)' failed
(valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
gtk_text_buffer_get_insert: assertion 'GTK_IS_TEXT_BUFFER (buffer)' failed
(valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
gtk_text_view_scroll_to_mark: assertion 'GTK_IS_TEXT_VIEW (text_view)' 
failed
(valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
gtk_text_view_get_buffer: assertion 'GTK_IS_TEXT_VIEW (text_view)' failed
(valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
gtk_text_buffer_insert_at_cursor: assertion 'GTK_IS_TEXT_BUFFER 
(buffer)' failed


Any idea ?


                Process.spawn_async_with_pipes (".",
                 spawn_args,
                 spawn_env,
                 SpawnFlags.SEARCH_PATH | 
SpawnFlags.DO_NOT_REAP_CHILD,

                 null,
                 out compiler_pid,
                 out compiler_input,
                 out compiler_output,
                 out compiler_error);

                // stdout:
                IOChannel compilerOutput = new IOChannel.unix_new 
(compiler_output);
                compilerOutput.add_watch (IOCondition.IN | 
IOCondition.HUP, (channel, condition) =>

                {
                    if (condition  == IOCondition.HUP)
                        return false;
                    try
                    {
                        string line;
                        channel.read_line (out line, null, null);
                        // Timeout with 0 goes to "UI-Thread" ?!
                        GLib.Timeout.add(0, () =>
                        {
buildTextView.buffer.insert_at_cursor(line, -1);
                            var mark = buildTextView.buffer.get_insert();
buildTextView.scroll_to_mark(mark, 0, true, 1, 1);
                        }
                    }
                    catch (IOChannelError e)
                    {
                        log (null, LogLevelFlags.LEVEL_ERROR, "%s", 
e.message);

                        return false;
                    }
                    catch (ConvertError e)
                    {
                        log (null, LogLevelFlags.LEVEL_ERROR, "%s", 
e.message);

                        return false;
                    }
                    catch (Error e)
                    {
                        log (null, LogLevelFlags.LEVEL_ERROR, "%s", 
e.message);

                        return true;
                    }
                    return true;
                });

Thanks for help
Wolfgang
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list