[M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content

[Jay K]

Randy, when you test start /wait on Vista (or XP for that matter), make sure first that there are no instances of iexplore.exe in taskmgr. I bet what is happening is that the new iexplore.exe you ran actually did exit.
Each user should probably have his own web server?
Or, what is wrong with keeping the web server running even after the browser exits?
I will double check BUILD_DIR, but the code is shared with cm3. How about the other variables?
 Vista vs. XP should not matter here.
 
 - Jay



________________________________
> Date: Fri, 31 Jul 2009 12:09:57 -0400
> From: rcoleburn at scires.com
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content
>
>
>
> Jay:
>
>
>
> The test I ran yesterday with cm3ide showed that MxConfig.Get("BUILD_DIR") returned NIL on Windows Vista. I'll try with Windows XP tonight. Perhaps you should check the code to verify it is working correctly.
>
>
>
> I've also noticed a difference between Vista and XP. Try "start /wait iexplore.exe" from a command prompt window. On XP, you don't get the command prompt back until IE is closed (terminates). On Vista, IE is started and you get your command prompt back immediately. So much for the "/wait" option on Vista. This is causing a problem for cm3ide in the start browser function--cm3ide web server shuts down immediately after IE is launched. You can fix this by changing the function definition to "RETURN FALSE" instead of "RETURN TRUE" but then that requres you to kill cm3ide manually, rather than having it stop when the browser shuts down. (On a multi-user server system, you would always use FALSE to keep the web server running all the time, but on a single user system it makes more sense to shut it down with the browser.)
>
>
>
> Let me know if you have any ideas on why Vista is different in this regard.
>
>
>
> Regards,
>
> Randy
>
>>>> Jay K 07/31/09 11:33 AM>>>
>
> MxConfig.Get() is able to retrieve the included part.
> MxConfig.Get() actually on demand compiles all the quake code to an internal code and then interprets it.
> It is exactly the same code as the compiler uses.
> The only wrinkle I messed up was that the compiler defines some things ahead of time like to indicate if you are profiling. That is what tripped up m3tohtml and such the other day.
> Due to missing variables MxConfig would kind of give up and return NULL.
>
>
> I think cminstall provides very little value, you really just need to extract the files and set %PATH%, but prompting the user like this for things that are truly user specific, that does have some value.
>
>
> Maybe we should work this into the .msi??
>
>
> - Jay
>
>
> ________________________________
>> Date: Fri, 31 Jul 2009 11:33:09 -0400
>> From: rcoleburn at scires.com
>> To: jay.krell at cornell.edu; m3devel at elegosoft.com
>> Subject: RE: [M3devel] cm3ide problem report, possibly related to MxConfigor to missing cm3.cfg content
>>
>>
>>
>> Jay:
>>
>>
>>
>> The initial editor and browser are user-specific preferences. cminstall used to ask for these and add them to the cm3.cfg file.
>>
>>
>>
>> I suspect that if you are defining BUILD_DIR in an included file, then MxConfig.Get() isn't able to retrieve the included part, so maybe fixing MxConfig.Get() will solve the problem without having to make cm3.cfg file changes.
>>
>>
>>
>> Regards,
>>
>> Randy Coleburn
>>
>>>>> Jay K 07/31/09 2:51 AM>>>
>>
>> BUILD_DIR is defined.
>> cm3 requires it too.
>> It just isn't necessarily defined in the toplevel file, but in a file that gets included.
>>
>>> PKG_USE
>>
>>
>> I believe that is also defined but I'll check.
>>
>>
>>> DOC_INSTALL
>>
>> I doubt that is defined because I never saw it used. I can add it back.
>>
>>
>>> INSTALL_ROOT
>>
>>
>> That is certainly defined, and very important.
>>
>>
>>> INITIAL_CM3_IDE_BROWSER
>>>
>>> INITIAL_CM3_IDE_EDITOR
>>
>>
>> These are probably also not defined because I never saw them used.
>> I can add them back..but they are actually very user specific.
>> I can add defaults like:
>>
>> BROWSER=iexplore.exe
>> EDITOR=notepad.exe
>>
>> BROWSER=firefox-bin
>> EDITOR=/usr/bin/vi
>>
>>
>> I'll do a little reserach and try to find defaults that work.
>>
>>
>> - Jay
>>
>> ________________________________
>>> Date: Fri, 31 Jul 2009 01:05:45 -0400
>>> From: rcoleburn at scires.com
>>> To: m3devel at elegosoft.com
>>> Subject: [M3devel] cm3ide problem report, possibly related to MxConfig or to missing cm3.cfg content
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Jay et al:
>>>
>>>
>>>
>>> On Windows, cm3ide exits with an error message (it does not crash) because BUILD_DIR is not defined in cm3.cfg.
>>>
>>>
>>>
>>> cm3ide depends on knowing the BUILD_DIR, which for Windows is "NT386".
>>>
>>>
>>>
>>> I know Jay has made a lot of changes to cm3.cfg. Either we need to put back into cm3.cfg the specification of BUILD_DIR, or we will need to re-engineer cm3ide to cope with this situation.
>>>
>>>
>>>
>>> At this stage of the game, if there is an easy way to put BUILD_DIR back into cm3.cfg, I vote for that approach.
>>>
>>>
>>>
>>> In the cm3ide source tree, Default.i3 and Default.m3 are the files that you might want to peruse to see the dependencies cm3ide has on cm3.cfg.
>>>
>>>
>>>
>>> In particular, these are:
>>>
>>> BUILD_DIR
>>>
>>> PKG_USE
>>>
>>> DOC_INSTALL
>>>
>>> INSTALL_ROOT
>>>
>>> INITIAL_CM3_IDE_BROWSER
>>>
>>> INITIAL_CM3_IDE_EDITOR
>>>
>>>
>>>
>>> If the last 2 are missing, cm3ide will prompt the user on the console window for these items. For Windows users, that may be a bit disconcerting. Once these are defined, it won't ask again unless cm3ide's config file gets blown away.
>>>
>>>
>>>
>>> I added some code a while back to construct some of the others if they were missing, but if all of them are missing, there is little one can do except guess or try to infer location based on current directory or path to cm3ide executable.
>>>
>>>
>>>
>>> It now seems that all of these are indeed missing, or at least not available via M3Config.Get. Note that M3Config is really MxConfig since the import statement is "IMPORT MxConfig AS M3Config". Perhaps some of Jay's recent changes to MxConfig are causing an issue here. Not sure.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Randy Coleburn