Benjamin L. Russell wrote:
On Mon, 27 Apr 2009 11:42:56 +0900, "Benjamin L. Russell"
<[email protected]> wrote:
[...]
What's very strange about this error is that installing the version of
Emacs that is listed on the "Mozart 1.4.0 for Windows" page (see
http://www.mozart-oz.org/download/view.cgi?action=windows&version=1.4.0)
under "Additional Packages" (i.e., GNU Emacs 20.7) and then setting
the OZEMACS environmental path variable to match the new path using
"Start Menu -> Control Panel -> System" does not resolve this problem;
neither does even installing XEmacs 21.4.21 and setting OZEMACS
appropriately, either; neither does renaming both .emacs and _emacs to
.emacs.bak and _emacs.bak, respectively. If Emacs were indeed the
source of the bug, such steps should resolve it.
Uninstalling and reinstalling either Mozart 1.4.0 or 1.3.2 does not
help, either, so it does not seem to be caused by a faulty
installation. Since Mozart ran successfully earlier, the installation
files are not corrupted.
The results of the diagnostic tests that you submitted indicate that
this bug does not seem to be a network permissions-related error.
Since the bug occurs even with the Windows Firewall turned off, this
does not seem to be a firewall-related bug.
The only significant changes that have happened between last August,
when Mozart/Oz still functioned correctly, and now are that I upgraded
GNU Emacs from 22.1.1 to 22.3.1, installed Meadow (an Emacs clone,
based on GNU Emacs 22.1.1) and set up my .emacs to switch between
.emacs.nt.el and .emacs.meadow.el to have different startup files for
the two editors, and that some important security updates were
installed by the IT department across all computers on the LAN.
However, the security updates don't seem to affect any of the other
programming language IDE's that I also run, which include Alice 1.4,
DrScheme, Squeak!, Etoys, WinHugs, and WinGhci.
Unless ozengine.exe does some kind of very unusual inter-process
communication that could set off a security alert and that none of the
other IDE's do, this should not be a problem.
-- Benjamin L. Russell
So as to definitely confirm that this is an emacs error, and as a more
reasonable workaround, you can try the following:
1. Create a file BasicOPI.oz with the following content:
functor
import
Open
Application
define
P={Application.getArgs record(port(single type:int))}.port
S={New class from Open.socket Open.text end client(port:P)}
I={New class from Open.file Open.text end init(name:stdin)}
O={New class from Open.file Open.text end init(name:stdout)}
thread
for X from fun{$}{S getS($)}end do
case X
of false then
{Application.exit 0}
else
{O putS(X)}
end
end
end
Todo={NewCell nil}
proc{DoIt}
for X in {Reverse @Todo} do
{S putS(X)}
end
{S putS([4])}
end
for X from fun{$}{I getS($)}end do
case X
of false then {Application.exit 0}
[] "!" then {DoIt}
[] "!\r" then {DoIt}
[] "/" then Todo:=nil
[] "/\r" then Todo:=nil
else Todo:=X|@Todo
end
end
end
2. Compile it to an executable by issuing the command "ozc -x BasicOPI.oz"
3. Open two terminals/command lines.
4. In the first one, type "ozengine x-oz://system/OPI". This will gives
you a banner message and a line of the form "'oz-socket xxxx yyyy'" with
xxxx and yyyy being integers (actually port numbers).
5. In the second one, run "BasicOPI --port xxxx" with the xxxx from the
previous step. (You may have to prefix the line with "./").
6.You can then type Oz code in the second terminal. Output that would go
to the "*Oz Compiler*" buffer in the emacs-based OPI (such as compiler
errors) will also get there. The first terminal corresponds to the "*Oz
Emulator*" buffer and will display program output, execution errors,
etc. and will also be the stdin of your program.
Since many lines of Oz code might need to be fed at once, the code is
not send for interpretation line-by-line but buffered until you type (in
the second terminal) a line with just a single bang (!) which will feed
the buffered line to the emulator or a single slash(/) which will drop
the buffered lines (useful if you spot an error in a previous line).
Since this uses the exact same code as the emacs-based OPI, it will only
works if the problem is on the emacs side.
Yves
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
