On Mon, 27 Apr 2009 11:42:56 +0900, "Benjamin L. Russell" <[email protected]> wrote:
>On Fri, 24 Apr 2009 12:07:39 +0200, Yves Jaradin ><[email protected]> wrote: > >>I shouldn't have sent code without first testing it. Here is a corrected >>(and tested) version: > >No problem; thanks for the update. > >>File1.oz: >>local S P in >> thread >> S={New Open.socket server(port:P)} >> end >> {Wait P} >> {Show P} >> {Show {S read(list:$)}} >> {S close()} >> {Show ok} >> {Delay 5000} >>end >> >>File2.oz: >>local S P in >> P=1234 %Replace with port number given by running File1.oz >> S={New Open.socket client(port:P)} >> {S write(vs:"\n")} >> {S close()} >> {Show ok} >> {Delay 5000} >>end > >Here is the output: > >>benja...@200706-05 /cygdrive/c/Documents and Settings/Benjamin/My >>Documents/Programming Practice/Mozart-Oz/Functions/Bug Test-related Files >>$ ozc --include ./BaseEnv.oz File1.oz >>1289 >> >>benja...@200706-05 /cygdrive/c/Documents and Settings/Benjamin/My >>Documents/Programming Practice/Mozart-Oz/Functions/Bug Test-related Files >>$ ozc --include ./BaseEnv.oz File2.oz >>ok > >This seems to be an Emacs-related error. > >What do you think would be best to do now? 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 -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
