SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: dunkers on August 24, 2008, 09:25:51 PM
-
I'm trying to get SE to recognise the errors from one of my compilers. I've managed to get as far as being able to click on the error message and then being taken to the correct line, but the little red tags in the source window are missing, and the message list doesn't display anything.
A sample error is:
RC51 COMPILER V03.03.43 Lite (32 Kb code limited)
Copyright (c) Raisonance S.A.S. 1987-2007. All rights reserved
*** ERROR C162 IN LINE 19 OF 17-612.c : Syntax error near '{'
*** ERROR C074 IN LINE 12 OF 17-612.c : Invalid declaration syntax
RC51 COMPILATION COMPLETE. 0 WARNING, 2 ERRORS
And the regex I'm using is:
^\*\*\* ERROR :a+ IN LINE {#1:i} OF {#0:p} \: {#3?+}$
Is there something else I should be doing?
-
Does 'set-error-markers' work for you when invoked manually (on cmdline) ? If so, it's maybe just not triggered by your build command... There were some problems with it (trigger) in the past, but chances are that it's working properly in v13.0.2.
HS2
-
Ah! Yes, set-error-markers pops them up :)
Er... but the only difference between this one that doesn't display and a Linux project that does is the regex. The build on both uses an external makefile (user maintained).
13.0.2? I seem to be a bit behind the times...
-
Uh... just in case a passing SE person things this is solved, it isn't. The set-error-markers things gets the markers to be displayed, but there's no way I'm going to type that in after every build (or assign to a key).
-
set_error_markers is called via _post_build(s).
In an answer from SE I got "The postbuild callbacks only work when are using vsbuild to handle the build commands, we cannot track the commands executed directly in the Build process buffer".
So if your compilation is not done via vsbuild.exe then you might have a batch file to start your compilation and at the end call slickedit with "vs.exe -#set_error_markers". Didn't tried, hope it helps.
Br,
Daniel
-
@dunkers: What version of SE are you using? You said "13.0.2? I seem to be a bit behind the times" -- how far behind the times? v13.0.1 included a fix for error markers not showing up, so I would expect that if you upgrade to 13.0.2 (or at least 13.0.1) then error markers should start working for you. Upgrading to 13.0.1 fixed error markers for me.
-
@at5dapa1: Thanks for that info. That would explain everything, except why I get the markers in my Cygwin projects where the compiler line is simply to call make!
at5dapa1: The SE version is <mumble>13.0.0.0</mumble> which I realise is a bit behind the times - I just don't want to face an upgrade and associated furkling with directories/setups at the moment. If the tags didn't show up with my Cygwin projects I'd just consider it a bug and a penalty for trailing the bleeding edge.
-
A bit more of the old furkling reveals that ticking 'verbose output' in the build tools window causes the markers to be displayed. This uses vsbuild to run the build command (even though that command is just another make tool) and, as Daniel notes, running vsbuild pops up the markers. Of course, on the already working projects 'verbose output' is unticked...
Thanks for your help, people.
-
Hi All.
I am also having problems with this. I am building a visual studio project. I have verbose checked (and the beep on completion for the pervious workaround to this problem). The markers are not set. vsbulid is being run:
C:\Data\Projects\windows.sna.Private_GBarron_SNA_v2_3_0_3\sna>"C:\Program Files\SlickEdit 2008\win\vsbuild" build -b .process -v -beep C:\Data\Projects\windows.sna.Private_GBarron_SNA_v2_3_0_3\sna\Sna.sln C:\Data\Projects\windows.sna.Private_GBarron_SNA_v2_3_0_3\sna\Sna.vpj -signal 9009
If I manually call set-error-markers() it works.
@SE Team: I am running 13.0.2. The error markers seems to be broken. I've done a grep of the macros directory and set_error_markers() is only called from _postbuild_build_set_error_markers(), which is not called by anybody? Allthough there is a fancy call to call_list("_postbuild_", args) in _vsbuild_socket_recv(), but _vsbuild_socket_recv never seems to be hit?
Is there any debug I can turn on to send you more info?
Cheers,
--
Greg.
-
Hi All.
I've looked into this a bit more and think I have found the problem. netstat -an on my machine was reporting that two processes were listening on socket 9009, which is the socket SE appears to use to receive the results from vsbuild. I had a look and it seemed there were zombie processes hanging around.
After killing SE and all these processes it all started working the next time around. There must be something in my workflow which causes this to happen.
Next time I get the problem I'll set def_vsbuild_signal_port to another number.
These seems to be a bug here though? Why is SE listening on 9009 twice? Shouldn't it realise the second time that 9009 is in use and then try a different port?
Cheers,
--
Greg.
-
Hi Again.
I can reproduce it like this:
1) Do a build.
2) Cancel it before it finishes.
3) Reload compile.e
4) Do a build.
There will now be more than one listener on port 9009. I'm not sure how this is possible to tell the truth.
Cheers,
--
Greg.
-
I don't think that's the main problem, lambertia - I never interrupt builds (they complete either successfully or with errors). In fact, I don't offhand know how to interrupt a build! :)
-
Reloading a macro file will empty any static variables. A new socket got created because it thinks it's not initialized, and the previous socket was never shutdown (which is normally done at program exit). It's also possible that you had another vs process running that may have interfered with the interprocess communication. Stopping a build shouldn't cause what you describe, it should recover from that. Are you normally re-loading compile.e as part of your workflow?
-
Hi Lee.
Yes I agree aborting the build is not the issue. That was just the quickest way to reproduce the problem.
I don't normally do this, but there was a bug in compile.e which I "fixed" and of course then I reloaded it ;).
There was only on vs.exe. But perhaps you may considering some form of dynamic port listening so that mulitple vs.exes can build and also to get around this issue.
Cheers,
--
Greg.