[erlang-questions] Re: wxErlang, Mac OS X and Input Methods (was Re: [erlang-questions] Does Wx need smp??)
John Webb
jwebb@REDACTED
Thu Sep 24 06:38:49 CEST 2009
I have just compiled and installed Erlang/OTP R13B02 on Mac OS 10.6.1
and am happy to report that the issue described below is resolved.
(Both wxWidgets 2.8.8 included in the OS distribution and a hand built
2.8.10 were fine.)
As I no longer have Mac OS 10.5 installed I can't tell whether the new
wxErlang init code or the OS upgrade (or both) fixed the problem but
it is nice to have everything working.
Many Thanks!
John Webb
On Jun 3, 2009, at 3:57 PM, Dan Gudmundsson wrote:
>
> 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: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
>>>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
More information about the erlang-questions
mailing list