Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

[Brandon Donnelson]

I'm not sure whats going on yet, but I've got some recompile issue coming up when trying to start dev mode. (This isn't using in browser recompile button)

After moving to Java 1.7 because of a Java 1.6 error I got stuck with this error. Not sure whats going on yet, but I thought I'd post it for those who are interested. I've heard turning on and off dev mode fixes it. I'll test more later. 

Runing CodeServer with parameters: [-noprecompile, -port, 9876, -sourceLevel, 1.7, -bindAddress, 127.0.0.1, -logLevel, INFO, com.sencha.gxt.test.TestRunner]

Super Dev Mode starting up

   workDir: /var/folders/x8/9wz7qtw96t7grkdyjw1l61p40000gn/T/gwt-codeserver-362446698832754749.tmp

   Loading Java files in com.sencha.gxt.test.TestRunner.

   Ignored 90 units with compilation errors in first pass.

Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.

To compile the module 'testrunner' , visit:

 http://127.0.0.1:9876/recompile/testrunner?user.agent=safari

   Module setup completed in 5256 ms

The code server is ready.

Next, visit: http://127.0.0.1:9876/

GET /recompile/testrunner

   Job com.sencha.gxt.test.TestRunner_1_0

      starting job: com.sencha.gxt.test.TestRunner_1_0

      binding: user.agent=safari

      Compiling module com.sencha.gxt.test.TestRunner

         [ERROR] Current binding properties are expanding to more than one permutation but per-file compilation requires that each compile operate on only one permutation.

      [WARN] recompile failed

      [WARN] continuing to serve previous version

[John Stalcup]

I can explain what's going here I think.

Incremental compile is made possible by storing and reusing data in a new object called a MinimalRebuildCache. Since some of the analysis that incremental compilation is much simpler when there is only one permutation being compiled and since the contents of a MinimalRebuildCache instance are specific to a single permutation we decided to put in a requirement that when compiling incrementally the compiler be invoked with a binding property set that restricts permutations to just 1.

To make sure this worked out fine for everyone we also turn on the -noPrecompile option so that all compiles are triggered from the browser, which ensures that the binding property set is specific to a single permutation.

I'm not completely aware of your configuration but... it appears that you're using incremental compiles from a test runner, and this test runner isn't restricting the permutations to just 1. And that is being caught by an assertion.

You can fix this by adding some <set-property> tags to your test .gwt.xml files.

I hadn't thought of this use case, so I'm not sure if it's fair to tell people to restrict their permutation or if we need to find a better way. Thoughts?

John

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/90b99fa9-e7f2-4908-ad36-28b775f24edb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Alworth]

The 'test runner' in this case is just the name of a regular module file, which happens to be used for running lots of tests, most of which look like EntryPoints. Nothing too magic going on here, and I've gotten this error by running modules for more 'normal' gwt apps as well, typically when I stop SDM, restart it, and then refresh the browser or click Compile without first using the SDM off bookmarklet.

I'm not completely aware of your configuration but... it appears that you're using incremental compiles from a test runner, and this test runner isn't restricting the permutations to just 1. And that is being caught by an assertion.

You can fix this by adding some <set-property> tags to your test .gwt.xml files.

I hadn't thought of this use case, so I'm not sure if it's fair to tell people to restrict their permutation or if we need to find a better way. Thoughts?

Does this mean that we expect all projects to already be confined to one permutation, either via set-property or collapse-all-permutations? Is there no way to achieve that synthetically?

Further, does this mean that one cannot test in multiple browsers simultaneously, for example re-compiling in FF until some behavior is satisfactory, then moving to Chrome (at least without stopping and restarting SDM)?

[Julien Dramaix]

I confirm, I just add GXT to one of my test project and I'm not able to use sdm anymore:

         [ERROR] Current binding properties are expanding to more than one permutation but per-file compilation requires that each compile operate on only one permutation.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cdf99604-44c9-41b5-9cca-4f45227a3c89%40googlegroups.com.

[John Stalcup]

We have a short list of issues that have to be addressed before 2.7 RC, and this is on the list.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6fovE52iouAswSHFpQ8dp1sLZYDTUmqBD--bhtvC0akg%40mail.gmail.com.

[Alexander Tarasov]

As I can see in gwt 2.7.0 release it was not fixed. <collapse-all-properties> doesn't help :(

[Константин Милютин]

Hello John,

could you please clarify if the issue was fixed or not? I have have the same error in 2.7. Is it related to gxt or not?



среда, 1 октября 2014 г., 23:08:31 UTC+2 пользователь John Stalcup написал:

We have a short list of issues that have to be addressed before 2.7 RC, and this is on the list.

On Wed, Oct 1, 2014 at 1:13 AM, Julien Dramaix <julien....@gmail.com> wrote:

I confirm, I just add GXT to one of my test project and I'm not able to use sdm anymore:

         [ERROR] Current binding properties are expanding to more than one permutation but per-file compilation requires that each compile operate on only one permutation.

On Wed, Oct 1, 2014 at 2:34 AM, Colin Alworth <nilo...@gmail.com> wrote:

The 'test runner' in this case is just the name of a regular module file, which happens to be used for running lots of tests, most of which look like EntryPoints. Nothing too magic going on here, and I've gotten this error by running modules for more 'normal' gwt apps as well, typically when I stop SDM, restart it, and then refresh the browser or click Compile without first using the SDM off bookmarklet.

I'm not completely aware of your configuration but... it appears that you're using incremental compiles from a test runner, and this test runner isn't restricting the permutations to just 1. And that is being caught by an assertion.

You can fix this by adding some <set-property> tags to your test .gwt.xml files.

I hadn't thought of this use case, so I'm not sure if it's fair to tell people to restrict their permutation or if we need to find a better way. Thoughts?

Does this mean that we expect all projects to already be confined to one permutation, either via set-property or collapse-all-permutations? Is there no way to achieve that synthetically?

Further, does this mean that one cannot test in multiple browsers simultaneously, for example re-compiling in FF until some behavior is satisfactory, then moving to Chrome (at least without stopping and restarting SDM)?

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cdf99604-44c9-41b5-9cca-4f45227a3c89%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Rob Walker]

Also just hit the same issue in 2.7.0

Using the -noincremental SDM option seems to get around it, I'd presume though at the expense of recompile speed.

[Robert Hoffmann]

Hi, 

Is there a way to see which properties cause the permutations?

(I'm using GWT 2.7.0) 

best, Robert

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Thomas Broyer]

On Thursday, December 4, 2014 10:15:36 AM UTC+1, Robert Hoffmann wrote:

Hi, 

Is there a way to see which properties cause the permutations?

(I'm using GWT 2.7.0) 

When compiling your project, you should have a compilation-mappings.txt file generated next to the *.nocache.js.

[Alexander Tarasov]

Is it ok?

9E2D25ADAB9D44AFEFC3E887DE3E3116.cache.js

gxt.user.agent chrome

user.agent safari

user.agent.os linux

9E2D25ADAB9D44AFEFC3E887DE3E3116.cache.js

gxt.user.agent chrome

user.agent safari

user.agent.os mac

9E2D25ADAB9D44AFEFC3E887DE3E3116.cache.js

gxt.user.agent chrome

user.agent safari

user.agent.os unknown

9E2D25ADAB9D44AFEFC3E887DE3E3116.cache.js

gxt.user.agent chrome

user.agent safari

user.agent.os windows

Devmode:devmode.js

[Robert Hoffmann]

@thomas

thank you, that helped me to reduce the permutations to one.

For the record, compilation-mappings.txt contained multiple cache.js file entries, now it only contains one
>>
FC8BCE744D2BA8E0C463CE0D2F389DB7.cache.js

Devmode:devmode.js
<<
...and now sdm works.

And it's fast :-)

[Rob Walker]

I'm seeing this file in the artefacts generated by the SDM compile in the temp dir. Isn't editing this file only going to apply to the current invocation though?

Presumably next time around it's going to get a different temp dir, and this fill will get recreated again.

Have to confess - I don't fully follow what this file does though, and why we need to manually edit it

[Robert Hoffmann]

The mappings file only reports what was going on in the compile phase, so modifying it has no effect.

You have to set specific values for your properties in the module.xml files:
e.g.
>>
    <set-property name="user.agent" value="safari"/>
<<

SDM picks this change up I believe without restart. However to see the change in the mappings file too, you have to clean and recompile (i.e. start your devserver).

[Rob Walker]

OK - I know I'm being exceptionally dumb here, but won't that also limit a production build to that 1 permutation?

[Daniel Kurka]

I am really curious why this is not working for you in the first place.

Since the code we added to SDM should always scope you down to one permutation. Are you still using bookmarklets? (These do not deal with this properly and should not be used anymore).

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c32c04e2-0ea0-45fc-9e54-c86098d48d85%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

[Rob Walker]

I see others note the Dev Mode On / Off cause this - what's the new approach then to enter Super Dev Mode?

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c32c04e2-0ea0-45fc-9e54-c86098d48d85%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rob Walker]

OK - this is very confusing, I went back to the Release Notes to see if I missed a breaking change in this area, but the 2.7.0RC1 release notes still reference the bookmarklets:

The Dev Mode On bookmarklet dialog shows whether Super Dev Mode is turned on for each module on the page.

And they don't suggest a different approacH is needed - or maybe I'm just not seeing it in the Docs

-- Rob

[Rob Walker]

I'm really not surprise people are hitting this issue. It's not clear (or wasn't to me) from the Release Notes that you no longer run Super Dev Mode from the standalone program in 2.7 as was done in 2.6, but that running via Dev Mode enables it.

Reading the docs on Debugging, they do kind of explain this - but there are places where they reference what appears to be the original way of running Super Dev Mode using bookmarklets, As above, those of us using these are not finding they work.

Also, for us, we don't run the embedded Jetty so need to run standalone server. Falling back to our old Dev Mode launch script, it does try to launch Super Dev Mode but aborts with an error:

Super Dev Mode starting up

   workDir: C:\Temp\gwt-codeserver-8197845274977519094.tmp
   Loading Java files in GwtApiTas.
   Ignored 308 units with compilation errors in first pass.

Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.

   Module setup completed in 4878 ms
   Loading Java files in VtWebUi.
   Ignored 310 units with compilation errors in first pass.

Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.

   Resolving com.ascert.tas.gwtapi.client.driverlib.DriverlibService
      Found type 'com.ascert.tas.gwtapi.client.driverlib.DriverlibService'
         Resolving method getDriverDescriptor
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
         Resolving method getPackagedEnvironments
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
         Resolving method getRepositories
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckReturn
         Resolving method refreshRepository
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
         Resolving method deletePackages
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
         Resolving method downloadPackages
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
         Resolving method pinPackage
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
         Resolving method unpinPackages
            [WARN] Ignoring unresolvable annotation type com.ascert.tas.gwtapi.c
lient.security.VtasSecurityCheckMethod
   Finding entry point classes
      [ERROR] Hint: Check the inheritance chain from your module; it may not be
inheriting a required module or a module may not be adding its source path entri
es properly

We don't have 600 sources with errors, since it clean compiles and runs fine. So I'm guessing it has something to do with source paths, given the number of modules skipped with errors. But at this stage I'm still lost.

Overall this was not a well documented or explained transition! I am really not surprised the average users are battling with it

[Thomas Broyer]

On Friday, December 5, 2014 10:00:59 AM UTC+1, Rob Walker wrote:

I'm really not surprise people are hitting this issue. It's not clear (or wasn't to me) from the Release Notes that you no longer run Super Dev Mode from the standalone program in 2.7 as was done in 2.6, but that running via Dev Mode enables it.

…or you can keep your launcher with CodeServer but add a -launcherDir argument pointing to the folder your standalone server is serving. CodeServer will then generate a .nocache.js in there that enables "compile on load".

And yes the docs need an update (and I wasn't even aware of the issue with the bookmarklets; good to know, and I believe we should try to fix it because it can be really handy)

[Rob Walker]

OK, so after a bit of a battle, I can get Dev Mode to run under 2.7, which now of course launches Super Dev Mode

I needed to change some things though. Our original launch command looked like this:

ava -cp "%TAS_HOME%/proj/webui/src/com/ascert/webui/vt;%TAS_HOME%/proj/tas/gwtapi/src/com/ascert/tas/gwtapi;%TAS_HOME%/proj/tas/gwtapi/src;%TAS_HOME%/proj/webui/src;%TAS_HOME%/build/ext/gwt-user.jar;%TAS_HOME%/proj/webui/lib/gwt-servlet-deps.jar;%TAS_HOME%/build/ext/gwt-dev.jar;%TAS_HOME%/build/ext/validation-api-1.0.0.GA-sources.jar;%TAS_HOME%/build/ext/gwtext.jar;%TAS_HOME%/build/ext/gwtextux.jar;%TAS_HOME%/build/ext/highcharts.jar;%TAS_HOME%/build/ext/gxt.jar;%TAS_HOME%/build/ext/gxt-chart.jar;%TAS_HOME%/build/ext/gxt-legacy.jar" com.google.gwt.dev.DevMode -noserver -startupUrl http://localhost:8084/VtWebUi/VtWebUi.html GwtApiTas VtWebUi

I forget why, but we needed paths to both the GWT XML and the sources separately. SDM under 2.7 does not like this, instead we needed to fully qualify our GWT XML with package names, and remove the path entry to them. In fact one module wasn't even on our original command which Dev Modes did not complain about (presumably because it was in same source path as main module)

java -cp "%TAS_HOME%/proj/tas/gwtapi/src;%TAS_HOME%/proj/webui/src;%TAS_HOME%/build/ext/gwt-user.jar;%TAS_HOME%/proj/webui/lib/gwt-servlet-deps.jar;%TAS_HOME%/build/ext/gwt-dev.jar;%TAS_HOME%/build/ext/validation-api-1.0.0.GA-sources.jar;%TAS_HOME%/build/ext/gwtext.jar;%TAS_HOME%/build/ext/gwtextux.jar;%TAS_HOME%/build/ext/highcharts.jar;%TAS_HOME%/build/ext/gxt.jar;%TAS_HOME%/build/ext/gxt-chart.jar;%TAS_HOME%/build/ext/gxt-legacy.jar" com.google.gwt.dev.DevMode -nostartServer -logLevel TRACE -startupUrl http://localhost:8084/VtWebUi/VtWebUi.html com.ascert.tas.gwtapi.GwtApiTas com.ascert.webui.core.GwtComponents com.ascert.webui.vt.VtWebUi

This removed the 600+ sources with errors, but we still hit an error with one of our sub-module missing an inhertis:

When we compile GWT normally, we don't see this error - presumably because that module is inherited by our main module.

Not sure yet if this is fully working, but it is at least launching into Super Dev Mode via the Dev Mode command line

[Rob Walker]

Sadly the -launcherDir won't work for us I don't think - we're running an embedded Felix/OSGi server which serves up our application from bundle JARS. So there is no dir we can point them at.

As per thread below, I think I am making progress with Dev Mode launch though - at least it is actually launching now anyhow. Seemed to need quite a few command line mods from our original BAT file to launch Dev Mode

[Rob Walker]

Nope - even though Dev Mode runs now and goes into Super Dev Mode, our application is not actually loading in SDM when we visit the web page.

Our web serving and resources are bundled into JARs, so I suspect the idea of overwriting the .nocache.js is just flawed or not working for this mode. There is no .nocache.js existing in the file system which overwriting will change our application behaviour.

SDM does still work for us if run explicitly, but we have to add a -noincremental flag, which I think defeats any speed gains

[David]

Hi Rob,

I'm using Jboss Fuse which uses Felix and it works fine in SuperDevMode. But did I read it right that you start the osgi container embedded with superdevmode ? I would love to know how I can achieve that as well because then I don't need to use the -noserver parameter anymore.

I am using the bookmarklets to force a compile and enforce superdevmode with the remote server. That works just fine for me.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/1d9b9b6e-07f1-4c35-96d6-bdc3aa471267%40googlegroups.com.

[Rob Walker]

In fact - it does seem to work in both models, but only with the following:

• I have to use the Dev Mod On bookmarklet to trigger a recompile. If I just reload, it doesn't seem to detect and recompile on it's own. I have a feeling running SDM directly did do a recompile on reload on one occasion, but can't be sure.
• I have to use a -noincremental command option. Without this I get the too many permutations error still
  

[Balázs Mészáros]

Hi,

I also have the same issue:

I have run the code server with -noprecompile flag. When I compile my project at the first time everything is fine:
[INFO] GET /recompile/showcase
[INFO]    Job my.Showcase_1_0
[INFO]       starting job: my.Showcase_1_0
[INFO]       binding: my.platform=desktop
[INFO]       binding: locale=en
[INFO]       binding: user.agent=safari
[INFO]       Compiling module my.Showcase

For the second time, I get the following result:
[INFO] GET /recompile/showcase
[INFO]    Job my.Showcase_1_1
[INFO]       starting job: my.Showcase_1_1
[INFO]       binding: locale=en
[INFO]       binding: user.agent=safari
[INFO]       Compiling module my.Showcase
[INFO]          [ERROR] Current binding properties are expanding to more than one permutation but per-file compilation requires that each compile operate on only one permutation.

The difference is that the [INFO]       binding: my.platform=desktop line is missing for the second try. It seems that SDM simply forgets that property. The property definition is the following:

<define-property name="my.platform" values="android, desktop, ios" />
<property-provider name="my.platform"><![CDATA[
    return getPlatform();
]]>
</property-provider>

Have you got any ideas?

[Thomas Broyer]

Are you using the -launcherDir too to get "compile on load"?

I don't think bookmarklets will ever be fixed.

[Kishore Palakollu]

Hi Robert,

         i m facing the same issue. can you please tell me what has fixed your issue.

My compilation-mappings.txt contains 

B5079040E7FF0E555046C1AD8B647A66.cache.js

locale en_EN

user.agent gecko1_8

B5079040E7FF0E555046C1AD8B647A66.cache.js

locale en_EN

user.agent ie10

B5079040E7FF0E555046C1AD8B647A66.cache.js

locale en_EN

user.agent ie9

B5079040E7FF0E555046C1AD8B647A66.cache.js

locale en_EN

user.agent safari

Devmode:devmode.js

Thanks & Regards,

kishore.

[Roberto Lublinerman]

Balázs, the js.embedded.properties configuration property might help here.

Try adding

<extend-configuration-property name="js.embedded.properties" value="my.platform" />

to your gwt.xml file

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/bcf4a9ce-75f7-40af-a8c0-05273db066ee%40googlegroups.com.

[Robert Hoffmann]

Limit your permutations by being more stringent, e.g. <set-property name="user.agent" value="safari" />

_________________________________

Robert Hoffmann, Ph.D.
_________________________________


+43 (0) 660 348 6095
robert.ho...@gmail.com
_________________________________

[Kishore Palakollu]

But i cannot limit this in the production rite.. i can limit it during my development.I have used <collapse-all-properties/> which had resolved my issue and there is only one permutation happening.But i want to know will there be any disadvantages or any side effects by using it.

[Robert Hoffmann]

Right, for production you should not do this, but then in production mode you will not need superdev.

(Once the extend superdev to deal with this situation you can use superdev for both compilations)

It helps if you use different gwt.xml files for production and dev (they could share a common inheritance.gwt.xml)

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/5lgtM77-1tM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f64f8070-728a-4165-883d-4ccb87d0b765%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[afarrar]

Rob,

   I've recently switched to using a MacBook and have run into what seems to be the same issue with SDM.  I'm using the normal web server and Eclipse. Your comments above helped get rid of the error when Dev Mode On button is used, but I still can't get Eclipse to stop at any breakpoint.  The app seems to run fine, just no debugging capabilities.   Any suggestions?

Many thanks. 

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f64f8070-728a-4165-883d-4ccb87d0b765%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Sunday, July 10, 2016 at 11:59:11 PM UTC+2, afarrar wrote:

Rob,

   I've recently switched to using a MacBook and have run into what seems to be the same issue with SDM.  I'm using the normal web server and Eclipse. Your comments above helped get rid of the error when Dev Mode On button is used, but I still can't get Eclipse to stop at any breakpoint.  The app seems to run fine, just no debugging capabilities.   Any suggestions?

I have trouble understanding your setup: first, which version are you using? what do you mean by "normal web server"? and is there any reason you use SDM with bookmarklets as opposed to "recompile on load" that was introduced in 2.7? (with the Eclipse plugin providing a backport for 2.6, and possibly even 2.5)