ladsoft / ocide Goto Github PK

I've needed some time to find the reason for the following message:

---------------------------
Debugger
---------------------------
Could not execute "C:\dev\gnucobol-merge-in\build_windows\ocide\WIN32\Debug\cobcrun.exe" ISAMTEST. 267
---------------------------
OK   
---------------------------

The reason: the working directory was wrong.
Therefore I suggest to change the message to

---------------------------
Debugger
---------------------------
Could not execute "C:\dev\gnucobol-merge-in\build_windows\ocide\WIN32\Debug\cobcrun.exe" ISAMTEST. 267 in "X:\notthere\nothere"
---------------------------
OK   
---------------------------

More minimal: the message

Should have an error type and likely the OCIDE icon.

Scenario: error (likely wrong, but this would be another issue) issued by the resource compiler, double click on it does not open the requested version_cobcrun.rc but a cobcrun.rc which is then not found and opened "empty" (without any error message).

We currently have "make" and "rebuild" in project context menu and Build menu, but clean (=remove all possible intermediate and resulting files) is missing.

using find/replace in OCIDE changes the cursor position, often enough to change the view.

As these are plain xml files an import of at least all configurations + source files and project structure + include path + lib path + libs should be possible.

Maybe add a warning "only xyz imported, please adjust compiler/linker settings".
Later on more options can be set during import.

created a line with a space followed by a curly brace, then inserted a new line. The cursor moved to after the curly brace.

Saved and opened:

<OCCWORKAREA>
	<VERSION ID="8"/>
	<PROJECTS SELECTED="cobcrun">
		<FILE NAME="cobc.exe" CLEAN="0">
			<DEPENDENCY NAME="libcob.dll" />
		</FILE>
		<FILE NAME="cobcrun.exe" CLEAN="0">
			<DEPENDENCY NAME="libcob.dll" />
		</FILE>
		<FILE NAME="libcob.dll" CLEAN="0">
			<DEPENDENCY NAME="libsupport.l" />
		</FILE>
		<FILE NAME="libsupport.l" CLEAN="0"/>
	</PROJECTS>
</OCCWORKAREA>

after closing OCIDE again the file is changed:

<OCCWORKAREA>
	<VERSION ID="8"/>
	<PROJECTS SELECTED="cobcrun">
		<FILE NAME="..\ocide\cobc.exe" CLEAN="0">
			<DEPENDENCY NAME="..\ocide\libcob.dll" />
		</FILE>
		<FILE NAME="..\ocide\cobcrun.exe" CLEAN="0">
			<DEPENDENCY NAME="..\ocide\libcob.dll" />
		</FILE>
		<FILE NAME="..\ocide\libcob.dll" CLEAN="0">
			<DEPENDENCY NAME="..\ocide\libsupport.l" />
		</FILE>
		<FILE NAME="..\ocide\libsupport.l" CLEAN="0"/>
	</PROJECTS>
</OCCWORKAREA>

"FR:" leave the cwa-file as is (don't add unnecessary relative paths)

Expected result: Project opened, possibly the referenced cwa opened, too (ideally all projects "closed/unloaded" if this option exists).

Result: default workspace is opened, cpj is additionally opened as file.

Just rechecking...

OCIDE needs work to run as a 64-bit application

I compiled ocide successfully with both VS2017 1nd VS2019, but when I run it and click on the Tools/Properties menu item, I get an nulptr exception on line 1463.

        for (i = 0; i < pd->protocount; i++)
        {
            SETTING* set = GetSettings(pd->prototype[i]);
            PopulateTree(hwndTree, TVI_ROOT, set->children, &first);
        }

when the line that calls PopulateTree is executed, "set" is null.

Given the Workspace of two projects: "library.dll" and "executable.exe" and executable.exe linked to library.l and the calls

• exe main -> exe func1
• exe func1 -> dll func2

Doing "step into" for all entries steps into func1 but not into func2.

This currently doesn't work (nothing happens)

The currently used chm doesn't even render in Windows 10 and cannot be read online.
I don't know where exactly the sources for the chm are - if I knew I could check for a possible conversation.

This may applies to more toolbars/menus, I've at least seen this for debugging: The debug menu is incomplete - some of the functions are only available in the toolbar.
As far as my (maybe incomplete) understanding of classic toolbars is they only show often used functions normally only found in the menu (with more clicks).
The menu on the other hand always shows possible function-keys that could be used to call the functions ("modern" toolbars do this in the tooltip of their buttons often, too).

I really was shocked by "no step into/step over options in ocide ?!?", then read the PDF manual, then found out that these are only available in the toolbar, not the menu.

To reproduce:

• create a workspace area with two projects
• project a: set working directory for debugging to existing project
• project b: set working directory for debugging to not-existing project
• project b: context-menu: "set as active project"
• project a: context-menu: "run/continue"

result: error message of wrong working directory
So either the wrong project would run (the one active, not the one the context menu was used on) or the directory check uses the active-project only.

As noted in LADSoft/OrangeC#79 the current working directory for the compiler is the project's folder.
It would be nice to be able to change this setting in the project's (or even file) property window.

To be more portable I've removed the paths from the cwa file (just directly specified the project files).

Opening this file in ocide worked fine, but on saving I've got "../myfolder/procect_file.dll" back.
(this actually raised a "project file not found" error for me when transferring the project files from one computer to another, using a different name for "myfolder").

coverity scan on OCIDE

Before doing the scan, fix the various compile-time warnings

The current debug properties are:

It seems that an "Environment" option is missing. Often it is reasonable to test with different environment options, the only workaround I see so far is to start ocide.exe either from cmd.exe or batch file and adjust the environment before.

move the coverity scan for ocide into its own separate project.

Rested with CI build 1.0.424 (and some older version)

I can reproduce this issue in ocide.exe when trying to debug in an environment where one of the dependency dll's are missing (which is the reason that the executable to debug can not start and the debugger obvious has nothing to attach to):

---------------------------
Access Violation
---------------------------

Access Violation:(C:\dev\orangec\bin\ocide.exe)
CS:EIP 0023:00455055  SS:ESP 002B:0019F61C
EAX: 00000000  EBX: 00454D46  ECX: 00000033  EDX: 00000000  flags: 00010246
EBP: 0019F70C  ESI: 00000000  EDI: 00595B94
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

---------------------------
OK   
---------------------------

output of the module loader:

Doing ocide my.cwa opens ocide and inside my.cwa as text file. Expected behavior: ocide is open and has my.cwa as workspace loaded

the ide crashed when opening a binary file. The file had been renamed to have a .txt extension.

It seems to always trigger a rebuild when the project file was saved.
The solution seems to save the debug options (all but "Debug Program") into another file like projectfile.user which doesn't trigger recompilation.

---------------------------
Debugger
---------------------------
Project needs to be rebuilt before debugging,  Do you want to rebuild?
---------------------------

If "no" is chosen:

---------------------------
File Error
---------------------------
File "C:\dev\gnucobol\build_windows\ocide\WIN32\Debug\cobc.exe" "C:\dev\gnucobol\_build_occ\tests\testsuite.dir\202\prog.cob" was not found
---------------------------
OK   
---------------------------

Using the latest CI build (MINGW64) I've opened an existing cwa. It gets opened as workspace, the contained projects are load, all last-opened windows are opened, code is analyzed, ocide gets unresponsive and exits without any message.
After this happens there's still one process hogging on the generated .ods: occpr.exe with complete invocation:
"C:\dev\OrangeC\bin\occpr.exe" /c /C+? /Wd /9 /E100 -! "-oC:\dev\gnucobol\build_windows\ocide\GnuCOBOL.ods" /P94219640 "/I;C:\dev\gnucobol\build_windows\ocide\..\..;C:\dev\gnucobol\build_windows\ocide\..;" "C:\dev\gnucobol\libcob\common.c"

I assume there is a log file which I just couldn't find that tells me why OCIDE chrashed, is it?

At least VisualStudio has this option and it is quite useful from time to time (allows a file like a skeleton to be shown and changed in the IDE but not being compiled).

Yay, thank you for the separate IDE package - this way it won't go away too easy while still providing room for OrangeC to go forward.

Please do a first release which is compatible to the current OrangeC release and include a short note how to "install" / use it (I guess it comes down just copy everything into the OrangeC root folder).

Maybe handle the documentation part, mentioned in LADSoft/OrangeC#439 (comment), too.

As soon as the release is done http://ladsoft.tripod.com/orange_c_compiler.html will likely get its first update outside of an OrangeC compiler release :-)

As per work on LADSoft/OrangeC#168 it might be useful to have a 'modules' window in OCIDE, to show loaded DLLs.

Dear OCC creators.
Debug->Watch is absolutely disabled on my Windows-7-64 comp for any projects and any variables (global and locals) for both recent OCC versions : 6.0. 41.1 & 6.0.37.1
I have some pause in programming, and when i started new project, i revealed that Watcher of debugger is absolutely Inoperative. Look at attached on-screen. When i am truing insert ANY variable (global or local) in ANY watcher-window - i always get error message :"Undefined symbol". Such situation i have now for ALL right projects for Orange C: for sample-projects , involved in OCC Installation Pack as far as all my own projects.
Also i attach one my own frame-project.
I will be glad and grateful for any your help.

Some projects use file extensions that are unknown to OCIDE but should be usable with C/C++ editor component.

Currently they are opened as text files, it would be nice to be able to create own mappings for the editor (specifying custom build steps is a separate issue [I think custom build steps aren't possible yet, but I haven't checked the documentation]).

A partially related issue is that it is likely reasonable to set the extensions "y" and "l" (yacc/bison and lex/flex) to the C/C++ editor component (if there's only a single for both, like it is the case with Visual Studio) as both file types in a project that is loaded via OCIDE will result in a C or C++ file (and therefore contains C / C++ parts).

Opened OCIDE from current Appveyor MSVC artifact --> all fine.
Opening an existing workspace --> all edit windows are opened, then for some/all files "scanning for dependencies for source.file" is shown, then OCIDE hangs.

I've removed the entries in <EDITWINDOWS> and <FILEBROWSE>, results: those aren't opened so the "hang" is earlier...

What can I do to work around this issue / make it more easy for you to check?

This is especially useful for non-static linking to RTS where "Run" leads to "System error, cannot found LSCRT.DLL".

Workaround: start cmd.exe, setup PATH, run ocide.exe, re-load workspace, run again. But I'd argue that this shouldn't be necessary...

---------------------------
Fatal RC File error
---------------------------
Error   C:\dev\gnucobol\build_windows\config.h(534):  Identifier expected
---------------------------
OK   
---------------------------

Which is

/* Version number of package */
#define VERSION "3.0-dev"

See version_cobc.rc including config.h.

Checked CI build of 44d04798 - result: error message

invalid resource id

for a rc file that is ANSI encoded and includes a header that is (for whatever strange reason) encoded with UCS-2 LE BOM.

Interesting side notes:

• it does not happen in places where C files include this header
• OCIDE cannot display this header file (shows the BOM instead)

It may be reasonable to split this issue into "resource compiler" and "ocide" (ideally they use the same internal functions to read the file though),

When dragging a file (C header / cwa) I'd like ocide to open the file / load the workspace (possibly after question if workspace should be loaded).

I suggest to add the License to the repo as documented in https://help.github.com/articles/adding-a-license-to-a-repository/ which would be "GitHub standard" and includes the license in this repo's metadata, too.
As soon as this is done https://github.com/LADSoft/OCIDE/tree/master/license can be removed.

data in thead local storage isn't available to the debugger. add debug info and support.

The project definition has additional include paths as $(PROJECTDIR)\..\..;$(PROJECTDIR)\..,

The D:\dev\test\build\my,rc file has:

#include "sub/versions.h"

The layout is:

D:\dev\test\build\ocide\stuff.exe.cpj
D:\dev\test\sub\versions.h

OCIDE says on editing that file:

---------------------------
Fatal RC File error
---------------------------
Error   D:\dev\test\build\ocide\my.rc(3):  Cannot open file "sub/versionsn.h" for read access
---------------------------
OK   
---------------------------

Multiple options are only mentioned in the docs so far. It would be nice if all options could be set in the GUI other than using "additional switches".

original value:
$(OUTPUTDIR)\$(OUTPUTNAME)$(OUTPUTEXT)

changed value to:
$(PROJECTDIR)\..\$(CURRENTPROFILE)\$(CURRENTRELEASETYPE)\$(OUTPUTNAME)$(OUTPUTEXT)

pressing [accept], then closing and reopening - output file is reset

there is a brief help file saying how to use ocide to the command line, but it is in the Orange C repository. Move it here.

The following check is is done by configure scripts to verify the C++ compiler and currently fails with occ:

namespace foo { }
using namespace foo;

int main (void) { return 0; }

result:

$ occ --nologo  -g conftest.cc
Warning(482)  conftest.cc(1):  Missing type specifier for identifier 'namespace'
Error( 11)    conftest.cc(1):  Syntax error: ; expected
1 Errors

Currently all ".l" files added to the project seem to be recognized as linker files, which is understandable but inconvenient as ".l" is used for (f)lex source files, too.

Error: invalid object file in line 15686 in library X:\gnucobol\cobc\scanner.l
Error: invalid object file in line 15686 in library X:\gnucobol\cobc\pplex.l

[Note: the line number seems to be strange...]

Workaround (as no "exclude from compilation" LADSoft/OrangeC#107 is available): remove these files from the project.

Started OCIDE, "reopen workarea".
Result: work area opened, status bar shows "Scanning for dependencies for x". It stands there until I use [ALT] or click somewhere in the IDE (I've actually waited until it was cleaned ;-)

Shown in the caller (defined as static char *, only pointer value shown)::

not shown in the function (defined as char *, only pointer value shown):

I've downloaded occe.zip from https://ci.appveyor.com/project/LADSoft/orangec/builds/20190245/job/ldy9naub674obd8w/artifacts

Also happens with older artifacts, for example https://ci.appveyor.com/project/LADSoft/orangec/builds/19837495/job/cjro5stn9jv6mpiu/artifacts (15 days ago).

The other executables can be started but ocide cannot be started, error 0xc000007b.
Rechecked: Only MS builds work, I'm quite sure the MinGW build did work before, too.

Within LADSoft/OrangeC#168 there are many sources in the project "libcob" which have variables defined in the function header. The same variable name is also defined in the file cobc/cobc.h which even belongs to a completely other project "cobc" - and this is used as current target for browse definition.

Example: libcob/fileio.c, cob_fd_file_open():

static int
cob_fd_file_open (cob_file *f, char *filename, const int mode, const int sharing)    // line 1252
{
        /// some stuff here

	if (access (filename, F_OK) && errno == ENOENT) {    // line 1272

browse to definition on filename in line 1272 should obviously jump to line 1252, but it jumps to the definition of the struct filename in cobc/cobc.h.

It would be nice to be able to close all files currently open in the editor (not the cwa/project files).
Especially when searching for something or investigate definitions (which will work again LADSoft/OrangeC#108) one may open many editor windows. I currently found no other way to close all than pressing [ALT]+[F]+[C] multiple times (as this workaround exists I'd consider this as very low priority, although I guess the implementation, maybe with a popup window asking if this really should be done [only if more than one file is open] would be easy to implement).