<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 27 Mar 2011, at 09:24, Michael Turner wrote:</div><br><blockquote type="cite"><div><div>However, the Erlang shell, wx's rather slavish mimicking of the wxWidgets C++ API, and the process architecture of wx as an "application" have all hindered me somewhat, for the "build simple GUIs mostly from the command line" goal.</div>
<div><br></div><div>For example, there's no way to define macros in the Erlang shell, much less a way to read macro definitions from a header file; and wx relies heavily on macro definitions. Making the reader look up the macro values in the headers and supply them as "magic numbers" in the Erlang shell feels distinctly sub-optimal.</div>
</div></blockquote><br></div><div>This gives me an excuse to mention my old shell extension hack,</div><div><br></div><div><a href="http://ulf.wiger.net/weblog/2007/11/21/extending-the-erlang-shell-part-2/">http://ulf.wiger.net/weblog/2007/11/21/extending-the-erlang-shell-part-2/</a></div><div><br></div><div>which allowed for a way to define modules from the shell, support alternative parsers, and also import macros in the same way as the current shell imports record definitions.</div><div><br></div><div>The code would need to be ported to R14B, and included an extension to eep.erl, among other things.</div><div><br></div><div>BR,</div><div>Ulf W</div><br><div>
<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div><br class="Apple-interchange-newline">
</div>
<br></body></html>