<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16850" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>I know you are pro Python and some scripts are in python and some scripts are in .sh and there is cygwin etc etc, but let me list why I think we need CMD on Windows:</DIV>
<DIV> </DIV>
<DIV>1. CMD comes with Windows out-of-the-box. No extra config/install is required.</DIV>
<DIV> </DIV>
<DIV>2. I want to be able to launch a CMD window and use the cm3 command line tools to build Modula-3 packages. I also want to be able to run Modula-3 programs without need of any other tools except what comes with Windows by default. Now the latter isn't exactly possible if you are dependent on the .NET framework, but most systems have .NET anyway because Microsoft has pushed it out through online updates.</DIV>
<DIV> </DIV>
<DIV>3. I continue to experience problems with cygwin, python, etc. because the setup in each is slightly different and there are dependencies that are not obvious. If you succeed in installing cm3 using cygwin, it isn't always possible to build/run packages from CMD. I haven't been able to get the python scripts to work for me, despite installing python.</DIV>
<DIV> </DIV>
<DIV>
<DIV>4. CM3IDE launches the native shell to run the cm3 command line tools. On Windows, this shell is CMD. We need to preserve this functionality.<BR></DIV>5. I have provided various CMD scripts in the repository and I've been keeping these up-to-date. I don't mind continuing to do this.</DIV>
<DIV> </DIV>
<DIV>6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here.</DIV>
<DIV> </DIV>
<DIV>7. Whatever automated test environment we provide on Windows must work in the native shell in order to prove that stuff is working in that shell. If you use cygwin or some other shell, that doesn't mean it will work in CMD.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy Coleburn</DIV>
<DIV><BR>>>> Jay K <jay.krell@cornell.edu> 7/24/2009 7:18 PM >>><BR><BR>[truncated again, one more try then I give up..]<BR><BR>><BR>> ----------------------------------------<BR>>> From: jay.krell@cornell.edu<BR>>> To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>>> Subject: RE: [M3devel] Hudson question<BR>>> Date: Fri, 24 Jul 2009 23:12:30 +0000<BR>>><BR>>><BR>>> It doesn't likely make a difference.<BR>>><BR>>><BR>>> Before you needed Cygwin or Interix.<BR>>> Now you need Cygwin or Interix, and probably Java.<BR>>> Java will probably be a sticking point on various platforms,<BR>>> but the gains are also very nice where it is available.<BR>>> I see there has been work done on an assembly-free Java VM<BR>>> since Sun open sourced their VM, so that promises increased portability.<BR>>> (One wonders some about the Critical Mass VM).<BR>>><BR>>><BR>>> Writing more .cmd isn't going to help anything imho.<BR>>> It's just more hard to maintain code that someone<BR>>> will have to maintain in parallel to Olaf's .sh.<BR>>> Which is why I favor Python -- portable, no duplicated effort.<BR>>><BR>>><BR>>> "Hard to main" as it, sure, it is easy to get started, but<BR>>> what happens when you decide you need an array, or a hash table?<BR>>> Or any of a number of basic programming constructs?<BR>>> Ok, I guess you have while loops, using goto.<BR>>> Local variables. At least that are strings. Everything is a string.<BR>>> cmd has one or two surprisingly powerfuli features, such as for /f<BR>>> and set /a. If you can't do your work with them, you can't do it.<BR>>> sh is a bit more portable than Python, but not by much and<BR>>> imho at too large a cost in maintainability/generality.<BR>>> It still seems to me like a string based language that can't do much,<BR>>> but I admit I'm not practised in it. (I am very practised in .cmd.)<BR>>><BR>>><BR>>> You know, the fact that expression evaluation is in some mix of the "[" command<BR>>> and maybe in sh itself. That people write if xxx true else yyy instead<BR>>> of if not xxx yyy.<BR>>> The fact that Solaris is different.<BR>>> The fact that quoting is needed in various places.<BR>>> Quoting always bothers me. It is hard to predict how many levels<BR>>> of unquoting will be done.<BR>>> I suspect cmd, sh, and Tcl are all in the same overly string based boat.<BR>>> For example in Tcl, { } appear to have the same meaning as in C and C++, good,<BR>>> but in fact they are escape characters, very wierd and bad.<BR>>><BR>>><BR>>> Cygwin and Interix both probably work fine.<BR>>> Someone just has to set them up and run them.<BR>>><BR>>><BR>>> Consider Cygwin and Interix almost the same.<BR>>> Interix is much faster, if you are calling fork a lot.<BR>>> Cygwin is slightly more compatible with Linux/Posix.<BR>>><BR>>><BR>>> Interix has a few ways in which is resembles Linux/Posix more though,<BR>>> such as not using extensions on executables, using ".so", supporting<BR>>> runpath.<BR>>><BR>>><BR>>> I think with Cygwin 1.7, both it and Interix go to extreme<BR>>> of supporting backward slash and colon in paths.<BR>>> Interix actually ors in 0xFF00 to such characters but<BR>>> it is transparent to Interix code. Or maybe that's what<BR>>> Cygwin does. I don't remember. It is completely non<BR>>> transparent and discoverable if you look at the results from Win32.<BR>>><BR>>><BR>>> Interix probably a larger download, because the<BR>>> part that is mostly "built in" is basically nothing,<BR>>> just some infrastructure and very few utilities.<BR>>> I don't think there is even sh or ksh.<BR>>> Everything else is one large download.<BR>>><BR>>><BR>>> On XP nothing is "builtin", there is just one large download.<BR>>> "builtin" is on Server 2003 R2, Vista, Server 2008, etc.<BR>>><BR>>><BR>>> (Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000.<BR>>> But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?)<BR>>><BR>>><BR>>> - Jay<BR>>><BR>>><BR>>> ----------------------------------------<BR>[deliberate snip]<BR><BR></DIV></BODY></HTML>