Author Topic: Error markers  (Read 6529 times)

dunkers

  • Senior Community Member
  • Posts: 578
  • Hero Points: 26
Error markers
« 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:

Code: [Select]
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:

Code: [Select]
^\*\*\* ERROR :a+ IN LINE {#1:i} OF {#0:p} \: {#3?+}$
Is there something else I should be doing?

hs2

  • Senior Community Member
  • Posts: 2727
  • Hero Points: 281
Re: Error markers
« Reply #1 on: August 25, 2008, 10:13:19 am »
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

dunkers

  • Senior Community Member
  • Posts: 578
  • Hero Points: 26
Re: Error markers
« Reply #2 on: August 25, 2008, 01:00:31 pm »
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...

dunkers

  • Senior Community Member
  • Posts: 578
  • Hero Points: 26
Re: Error markers
« Reply #3 on: August 27, 2008, 06:07:55 pm »
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).

at5dapa1

  • Senior Community Member
  • Posts: 131
  • Hero Points: 8
Re: Error markers
« Reply #4 on: August 28, 2008, 08:11:28 am »
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

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: Error markers
« Reply #5 on: August 28, 2008, 05:54:18 pm »
@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.

dunkers

  • Senior Community Member
  • Posts: 578
  • Hero Points: 26
Re: Error markers
« Reply #6 on: August 29, 2008, 11:12:01 am »
@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.


dunkers

  • Senior Community Member
  • Posts: 578
  • Hero Points: 26
Re: Error markers
« Reply #7 on: August 31, 2008, 03:13:54 am »
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.

lambertia

  • Senior Community Member
  • Posts: 382
  • Hero Points: 14
  • I have nothing sufficiently witty to say.
Re: Error markers
« Reply #8 on: August 31, 2008, 10:32:24 pm »
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:

Code: [Select]
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.
« Last Edit: August 31, 2008, 11:12:41 pm by lambertia »

lambertia

  • Senior Community Member
  • Posts: 382
  • Hero Points: 14
  • I have nothing sufficiently witty to say.
Re: Error markers
« Reply #9 on: September 02, 2008, 06:06:12 am »
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.

lambertia

  • Senior Community Member
  • Posts: 382
  • Hero Points: 14
  • I have nothing sufficiently witty to say.
Re: Error markers
« Reply #10 on: September 02, 2008, 07:02:10 am »
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.

dunkers

  • Senior Community Member
  • Posts: 578
  • Hero Points: 26
Re: Error markers
« Reply #11 on: September 02, 2008, 11:49:11 am »
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! :)

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1097
  • Hero Points: 94
Re: Error markers
« Reply #12 on: September 02, 2008, 12:45:02 pm »
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?

lambertia

  • Senior Community Member
  • Posts: 382
  • Hero Points: 14
  • I have nothing sufficiently witty to say.
Re: Error markers
« Reply #13 on: September 02, 2008, 09:29:05 pm »
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.