wxErlang, Mac OS X and Input Methods (was Re: [erlang-questions] Does Wx need smp??)

Dan Gudmundsson <>
Wed Jun 3 08:57:54 CEST 2009


Hi and thanks for the bug report.

Getting the driver to connect to the window system on the mac
without actually having a real gui application is a real hack,
that someone (name escapes me) contributed to esdl.

The solution might be a werl for the mac.

But my mac skills (and my time) is rather limited so don't hold
your breath.

/Dan

John Webb wrote:
> Hi Dan,
> 
> I have run into a problem which I think is related to this thread.
> 
> I have compiled and installed Erlang/OTP 13B linked against wxWidgets 
> 2.8.10 on Mac OS X 10.5.7. I also have the OS's Japanese input method 
> enabled.
> 
> The wxErlang examples work fine when direct keyboard input (English) is 
> selected. However when a Japanese input method mode is selected (eg in 
> order to type Japanese characters into  a text widget) the mac's 
> spinning rainbow cursor appears and the GUI app grinds to an 
> unresponsive halt.
> 
> The console repeats a number of error messages until the emulator is 
> interrupted (see below).
> 
> It seems that the application (client) tries to connect to the input 
> method (server) and fails. The second error then indicates some 
> consternation that this didn't happen in the main thread! Apple 
> documentation is sparse in this area but I think that, from the client 
> side, interaction with an input method via text services should be 
> transparent. The wxWidget examples do not exhibit this problem which 
> suggests an implementation problem (on Mac OS X at least).
> 
> Perhaps there is a work around for the driver implementation (I would be 
> interested to know if anyone else has experienced this problem on other 
> platforms or other input methods). On the other hand I would put this as 
> one case for implementing the GUI as a separate os process (a build 
> option perhaps?) communicating with erlang via sockets.
> 
> I like wxWidgets as a GUI for erlang and a lot of work has gone into 
> wxErlang.  If this does prove to be a problem not just  for my machine 
> then it would be a great shame if it were not available on each of the 
> main platforms for each locale.
> 
> Best Regards,
> John Webb
> 
> Console Output:
> +++++++++++++++++
> 2> menu:start().
> 2009-05-27 12:39:03.286 beam.smp[7096:3507] IMKClient: exception caught 
> trying to get the rootProxy for connection ((** NSConnection 0x3fb420 
> receivePort <NSMachPort: 0x3fb160> sendPort <NSMachPort: 0x3fb120> 
> refCount 7 **)): NSPortTimeoutException : connection timeout: did not 
> receive reply
> 
> 2009-05-27 12:39:03.288 beam.smp[7096:3507]         This exception was 
> thrown inside thread: <NSThread: 0x333760>{name = (null), num = 2}.  
> This thread is NOT the main thread.
> 
> 2009-05-27 12:39:08.700 beam.smp[7096:3507] IMKClient: exception caught 
> trying to get the rootProxy for connection ((** NSConnection 0x17003980 
> receivePort <NSMachPort: 0x3f8080> sendPort <NSMachPort: 0x3fb120> 
> refCount 7 **)): NSPortTimeoutException : connection timeout: did not 
> receive reply
> 
> 2009-05-27 12:39:08.701 beam.smp[7096:3507]         This exception was 
> thrown inside thread: <NSThread: 0x333760>{name = (null), num = 2}.  
> This thread is NOT the main thread.
> 
> 2009-05-27 12:39:08.702 beam.smp[7096:3507] ****** Returning nil _server 
> **********
> :
> :
> (repeats 'ad infinitum', well 'ad ^G' )
> +++++++++++++++++
> 
> 
> On Jun 3, 2009, at 1:30 AM, Angel wrote:
> 
>> El Lunes, 1 de Junio de 2009 07:36:45 Dan Gudmundsson escribió:
>>> The reason was speed, as it is an object oriented api I thought there
>>> would be a lot of queries to the driver/port program.
>>>
>>> A GS was bashed a lot previously so I thought that we make it as fast 
>>> as possible
>>> from the beginning.
>>>
>>> Maybe that wasn't the best decision?
>>>
>>> /Dan
>>
>> Well, from the novice point of view,  I have seen many times in this 
>> list that raw speed is a very questionable concept
>> because being fast doesnt mean scale better. Erlang itself is very 
>> devoted to scale causing confusión and horror
>> to people on the first time when you see so much copying to allow nthe 
>> non destructive model and mesage passing.
>>
>> For one scenario (a single nodel) a built-in driver maybe optimal, 
>> maybe not,  Windows seems to be the case here for
>> speed (most stuff in kernel) whereas X in the oposite shows you can 
>> make GUI over a wire protocol and let nasty things
>> (as masive opengl and the like transfers) to pluging or extensions 
>> (XVIDEO...) where tricky things can be done (IPC via
>> shared segments and other things).
>>
>>
>> The whole system often is so much complex to be achieved using only 
>> one paradigm (funtional, process, threads, oop ...)
>>
>> Despite those things wxerlang seems pretty interesting and a very good 
>> stating point for erlang going into the desktop..
>>
>> /Angel
>>>
>>> clist wrote:
>>>> well smp is nearly mainsteam today i know.
>>>>
>>>> yet i still dont know what was the key on becoming a driver from a 
>>>> port program as early
>>>> wxerlang (thesis code) seemed to be standalone
>>>>
>>>> /angel
>>>>
>>>> ________________________________
>>>>
>>>> De: Dan Gudmundsson [mailto:]
>>>> Enviado el: vie 29/05/2009 10:52
>>>> Para: clist
>>>> CC: 
>>>> Asunto: Re: [erlang-questions] Does Wx need smp??
>>>>
>>>>
>>>>
>>>> wxWidgets must run in it's own thread, and the functions used in 
>>>> erlang driver interface
>>>> to communicate with the emulator is only thread safe in an smp 
>>>> emulator.
>>>>
>>>> With some work you could wrap that functionality, send it to the 
>>>> erlang thread first and
>>>> call the functions from the emulator thread on an non smp enabled 
>>>> erlang.
>>>>
>>>> But that is work that I don't have time with and nowadays smp 
>>>> machines are everywhere,
>>>> e.g. my 6 year old PC is hyperthreaded and seen as an smp machine.
>>>>
>>>> /Dan
>>>>
>>>> Angel Alvarez wrote:
>>>>> El Martes, 26 de Mayo de 2009 Steve Davis escribió:
>>>>>> Hello Angel,
>>>>>>
>>>>>> Yep, wx does require SMP, the reason being that the underlying (cpp)
>>>>>> library code is required to run in a separate OS thread.
>>>>>>
>>>>>> The erl flag you want is -smp enable. If running under windows you
>>>>>> must use werl not erl.
>>>>>>
>>>>>> To be fair, after taking a quick look at the official docs (both user
>>>>>> guide and ref manual), this requirement is far from clear.
>>>>>>
>>>>>> /s
>>>>> Sorry, my fault!
>>>>>
>>>>> Niko (the packager whose rpm i picked up ) told me that, i wanted 
>>>>> to just to probe new features
>>>>> so basically i ignored the docs....(like a good newbie  :-)  )
>>>>>
>>>>> IMHO this is not very elegant as the purity of process isolation is 
>>>>> gone.
>>>>>
>>>>> Was performance the key on introducing such a complex driver? im 
>>>>> very new
>>>>> to just make this judgement but for the whole thing (minus opengl 
>>>>> and the like)
>>>>> it seems enough a stdin/pipe interface than making a big driver.
>>>>>
>>>>> Perhaps memory conservation is another issue (well is erlang VM 
>>>>> better at managing
>>>>> memory than a full blow C++ aplication??? ).
>>>>>
>>>>> Just checking
>>>>> http://apps.sourceforge.net/mediawiki/wxerlang/index.php?title=Memory_management 
>>>>>
>>>>>
>>>>> shows a bif efort to catch deleted objects and try to be in sync 
>>>>> with the pure erlang side...
>>>>>
>>>>>
>>>>> its not criticism, but mere curiosity, design questions are very 
>>>>> educative.
>>>>>
>>>>> Regards, Angel
>>>>>
>>>>> PS: Ive just found http://wxerlang.sourceforge.net/docs/Report.pdf 
>>>>> seems very promising for insigths..!
>>>>
>>>>
>>>
>>
>>
>>
>> -- 
>> Este correo no tiene dibujos. Las formas extrañas en la pantalla son 
>> letras.
>> __________________________________________
>>
>> Clist UAH a.k.a Angel
>> __________________________________________
>> Te has metido en un hipoteca de 70M y encima te roban una panda de 
>> Ninjas... Crisis Ninja para Dummies.
>>
>> ________________________________________________________________
>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>> erlang-questions (at) erlang.org
>>
> 
> 


More information about the erlang-questions mailing list