error parsing

[also]

Hallo

Is it possible to parse the contents of a file for errors, which is written as a result by the build process?
We have to output the results with tee into a file cause of different SDK's, controllers, hardware and for security reasons.

Thank you for help

[hs2]

You could try to cat/type the file contents as a user build command (see Project>Props).
If error parsing is not triggered automatically you can try 'set-error-markers' on SE cmdline.
Hope it works for you, HS2

[also]

You could try to cat/type the file contents as a user build command (see Project>Props).
If error parsing is not triggered automatically you can try 'set-error-markers' on SE cmdline.
Hope it works for you, HS2

Thx
No,this is not working. The rsh_socket to the ARM target platform closes the connection before cat supplies.
The errormechanism has to parse a file after build, there is no way out.
We are using codewright for many years now, but it's time to make a change for a couple of reasons.
I think slickedit is the best solution, but I am new to this environment.
Using codewright I would program a dll to parse a file after build.
Before I start to learn Slick-C, I would like to know if it's possible to solve this problem with a slick-c macro.
Perhaps slickedit is not this open as codewright and I'm knocking on closed doors with slick-c.

[Graeme]

Have a look in the slick help at the topic "error regular expressions dialog".  You can write a regular expression to parse the file.  What does the output file look like?  If regular expression parsing isn't viable, you can either translate the output externally (e.g. write a program in C or python or whatever) and pass the translated output to slick or you can write Slick C to parse the file.  The slick C "parse" statement is quite useful for that.  If you have a post-build command of "type somefile.txt" the content of somefile.txt should get dumped into the build window.  So you could have two post build commands  1. translate somefile1.txt  2.type somefile2.txt

Graeme

[hs2]

@also: Is it possible to add some details about your build command/env. ? Sounds like you're doing remote builds, but that's not a problem with SE. If you 'tee' the build output into a file it's also streamed to stdout and visible in the (remote) shell, right ? Given that it's maybe not even necessary to parse the file as a kind of post-build step. However, if the build output is finally visible in the SE 'Build' window it can be parsed by the built-in, configurable error parser.
Alternatively you could add a user build command to explicitely 'cat' the build output file remotely, but again with the captured output displayed in the SE Build window.
HS2

[also]

@also: Is it possible to add some details about your build command/env. ? ....

of course. All programming is done under win with slickedit for different hardware platforms.
An example for a command looks like this:
rsh servername -l username -n bin/arm-tools kernel_v6.xx AT91SAM9-M10 arm-angstrom-linux-gnueabi makeall

rsh is the win_remote_shell_client
It connects to rsh on servername, which may run on win, linux or the target itself, dependently on desired target platform.
then execute bourne_script arm-tool within desired ~/home defined with the username
and some arguments to the script arm-tools like workspacename, used controller, preferred compiler, toolchain_infos, etc.
We use controllers based on arm,cris,microchip, etc. but also PLD's must fit into this environment.
In the example above it simply executes a make all for desired hardware with the choosen compiler_tools
The result is written into a file with 'tee' and can be written into a database later.
Slickedit with the workspace->project configuration possibilities and tools unify all this things.

In the meantime errorparsing works well. The problem was the rsh_server on the windows platform and mingw.
Now the build results are written into a file AND send to the slickedit_shell from all platforms.
However, this can only be a temporary solution, but it works for now.
Tomorrow the programmers will have to use slickedit in place of codewright.
If something is not like they are used to, this guys pull my skin off.

Thank you very much for help!
also

[hs2]

If something is not like they are used to, this guys pull my skin off.

Hey - no fear And if your guys are real developers, they should be flexible enough to adapt to slightly different conditions.
However, as far as I know there is no better cross plattform/technology platform as SlickEdit even out of the box.
They gonna love it - hopefully...
HS2

PS: Please add a keep-alive posting after day 1 that we all know you're still in good shape.

[also]

After the build_process has written an outputfile, I read this file from the server into the build_buffer and try to parse for errors:
fout is the file written on the remote_host by build

Code: [Select]

   if(file_exists(fout))
   {
   clear_pbuffer();
   activate_window(_utActivateBuildOrProcessWindow());
   int stat=load_files("+d ":+fout);
  next_error('R');
   }

The contents of the file are read into the window 'build', but the parser does not work !
I think it has to, even if the contents of the build_buffer is not read/written over pipe or delivered by shell.

also

[hs2]

Have a look at this (legacy) example. I think an explicit call to 'set_error_markers' is missing at least.
Good luck, HS2

[Graeme]

Some other thoughts...   - maybe see toggle_process_tab_output.  I think you need to ensure that def_process_tab_output is false before calling _utActivateBuildOrProcessWindow, otherwise _find_tile(".process") will return 0.  Also, load_files will load the file into a new buffer - you should probably use get() to read the file into the .process buffer, but maybe next_error can be used with any buffer at all - I don't know.

Graeme

Edit - I might be wrong about the find_tile thing.

[also]

@Graeme
Read any data or files with get(), load_files(), etc. into the build buffer does not work.
The parser does not see the text inserted. Slickedit needs to read_in the data over a pipe by the shell,
it means, you have to execute a program like 'type filename' to fill the build buffer.
As I wrote above, this is not really sufficient, cause what you see in the build buffer
is not what the parser is parsing.

also

[Graeme]

@Graeme
Read any data or files with get(), load_files(), etc. into the build buffer does not work.
The parser does not see the text inserted. Slickedit needs to read_in the data over a pipe by the shell,
it means, you have to execute a program like 'type filename' to fill the build buffer.
As I wrote above, this is not really sufficient, cause what you see in the build buffer
is not what the parser is parsing.

I was basing my comments on the fact that you can paste error messages into the build window, double click on them and slick will go to that file/line.  When I get time I'll see if I can make this work programmatically.

Graeme

[hs2]

AFAIK the Build window is associated with the '.process' system buffer and e.g. the error parser relies on that. Although it might be possible to manipulate this buffer directly I'd propose to use the project build tool interface.
Simply by using a dedicated 'show error' command (executing an appr. rsh script) or by using 'project_usertool' in a macro.
HS2

[also]

I was basing my comments on the fact that you can paste error messages into the build window, double click on them and slick will go to that file/line.  When I get time I'll see if I can make this work programmatically.

Graeme

you are right, pasting an error message into the build window can be parsed.
It maybe means, a load with get(), load_files() and friends can be seen in the build_window, but it is not the correct buffer behind.
HS2 wrote about a '.process' system buffer the error parser relies on.
A grep in all existing macros did not give any informations, also the help did not really help.
If you could give me just an idea how to manipulate this .process' system buffer, it would be a big help
Thank you

also

[Graeme]

On my machine, as well as double click, the next-error and prev-error commands work after pasting text into the build window.  If you right click in the build window, one of the menu options is "send compile output to editor window".  When this option is checked (enabled), an editor window with the buffer name .process is opened in the main slickedit window.  This buffer also "appears" in the build tool window.  Hence I suspect you can use the buffer name ".process" to do the paste even when the "send compile output to editor window" setting is turned off.  If a shell is running in the build window I think you have to get rid of it using exit or something.  Slick also uses (optionally hidden) buffers named .search1 .search2 etc to hold search results and displays those buffers in the search toolbar.  I'll have another look later when I have time.

Also I'm not sure why the "type filename" mechanism wouldn't work.  You probably ought to be able to add another tool to the list in project properties called "show errors" that does a "type filename" but that would be one extra step.

Graeme