wxErlang, Mac OS X and Input Methods (was Re: [erlang-questions] Does Wx need smp??)
John Webb
jwebb@REDACTED
Wed Jun 3 02:42:45 CEST 2009
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:dgud@REDACTED]
>>> Enviado el: vie 29/05/2009 10:52
>>> Para: clist
>>> CC: erlang-questions@REDACTED
>>> 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