On Wed, Jun 15, 2011 at 2:35 PM, Robert Virding <span dir="ltr"><<a href="mailto:robert.virding@erlang-solutions.com">robert.virding@erlang-solutions.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The wx application binding of wxWidgets seems to be cause crashes on many systems, including MacOSX. After pondering on it I have a number of questions:<br>
<br>
Is it the wxWidget implementation itself which is buggy?<br>
             OR<br>
Is the use of them directly in the BEAM which causes the crashes? Either through some inherent match problem, or version mismatch, or ...?<br>
<br>
If it is the second, would implementing a completely separate wx process solve the problem? I.e. would it be possible to implement such a process which would make linking with wxWidgets "safe"?<br>
<br>
If so, wouldn't it be better to do just that? Run wxWidgets in a separate OS process and use a (non-linked in driver) port to access it? Yes, it would be slower but it would work and be more robust.<br>
<br>
If this has already been discussed and my questions answered please point me in the right direction.<br><br></blockquote><div><br></div><div>In most cases it is a bug in the erlang program, then in my driver code, and a few times it's in wxWidgets.</div>
<div><br></div><div>So mostly it's about testing your application extensively on every platform. </div><div>They all behave slightly different, if you program by the book it works everywhere, but that is hard since both wxWidgets</div>
<div>(and especially wx) lacks good documentation, so it is always a little trial and error.</div><div><br></div><div>In my experience the main problem is deleting objects, add the same object twice to a window somewhere and delete the window, wxWidgets will cleanup and destroy the object twice and erlang will crash. </div>
<div>Or you delete the object yourself but wx has a reference to it somewhere which also deletes it.</div><div><br></div><div>My opinion is that if you have a mission critical application you don't run the gui on that node, distributed programming is easy</div>
<div>in erlang so use a separate node to connect your gui to the mission critical system.</div><div><br></div><div>Then if the gui crashes it still is a bug whether you have an erlang prompt with a non descriptive  'EXIT' message from the port or not. Which is why I chose to write it as a driver in the first place.</div>
<div><br></div><div>I think extending gs and writing a backend for wx is a good idea, where can hopefully safe guard the programmer from </div><div>some errors.</div><div><br></div><div>If you want to have it as a port program as an option, it is doable but a lot of work, </div>
<div>though we accept patches :-) </div><div><br></div><div>/Dan </div><div>PS: I still haven't had time to look at your reltool crash, sorry about that.</div><div><br></div></div>