wxErlang, Mac OS X and Input Methods (was Re: [erlang-questions] Does Wx need smp??)
Dan Gudmundsson
dgud@REDACTED
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: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