davidpcaldwell / slime Goto Github PK

Blocking issue #27

Should search for [whitespace]Packages, as well as [whitespace]java, [whitespace]org, and whatever other top-level packages are used in Rhino (com?).

Currently, the documentation is decent but there are no tests at all.

Blocked on issue #59

Currently the jsh.shell.shell method has hooks to make it easier to run on Cygwin; as we disentangle Cygwin, we could delegate the call directly from jsh.shell.shell to rhino/shell run().

Functions cannot have evaluate() called upon them and their properties are not available via the normal verify() mechanisms.

Currently, the -source and -target are hard-coded to be 1.6 in the build script, and there is no cross-compilation. This regime should be more flexible; it should allow the version to be specified, and boot classpath to be specified also.

Blocking issue #146

Currently, Cygwin is treated as a first-class case within the package. It should be factored out and isolated as much as possible.

The documentation was written before some of the styling features existed, and thus the documentation has a different appearance than the other modules.

Currently, these must be written as something like:

try {
  doIt();
  test(false);
} catch (e) {
  test(true);
}

This is far too verbose for a concept that occurs so often.

Right now, inonit.script.runtime.shell.Environment supports JDK 1.4, but the launcher's implementation of searching for environment variables in api.rhino.js supports JDK 1.5.

In any case, no testing is being done with anything below 1.6 currently.

Oracle's policies are confusing enough that it's difficult to decide what to support, except perhaps 1.4+. See [[http://www.oracle.com/technetwork/java/eol-135779.html|http:~//www.oracle.com/technetwork/java/eol-135779.html]]

This would require a method for testing the software under multiple versions. It would also probably require a way of compiling with a lower -target version (and Rhino with the same?). It would not hurt to have a way of switching the Rhino version for testing as well.

See https://www.jetbrains.com/lp/devecosystem-2020/java/

This issue was created by revision 937970365ac8.

Currently, the API is very minimal, but there are many other features that could be considered: launching JAR files, providing system properties, and so forth. Think them through and improve the method.

Blocked on issue #30

All Java dependencies (other than the Java API and Rhino) should be reviewed and pure JS ports provided, for ease of loading heterogeneously-developed modules, facilitating reload of modules, etc. Java classes should be bundled as optimizations only.

Currently, there are some classes that may be isolated within the bundled modules (loaded from own .slime files). This could be investigated; are these available to scripts? Should they be available only to the modules?

Then there are classes that implement the interpreter embedding; these could be reviewed to ensure they are as minimal as possible.

There are also some utility classes (e.g., for I/O) in the system source root that are used by the launcher, loader, and build process. These should be examined to see whether they can be implemented using pure JS.

Setting it to 'true' for example just does nothing, which is confusing.

Currently there are several node types that are unhandled and will generate exceptions when parsing if they are encountered.

The inside-Tomcat tests in jsh/test/jsh.httpd/httpd.jsh.js wait for a time interval after starting Tomcat to figure out whether they can send requests. This both wastes time if the startup takes less time and potentially causes tests to fail if it takes too long.

It would be better to read the Tomcat console output, perhaps, and use that to determine whether the server has started.

Currently, only a single servlet is supported. The command-line interface will get pretty complicated if multiple servlets are supported, so perhaps it will make sense to do this another way.

Currently browser documentation must use hyperlinks to substitute for the inclusion behavior provided by jsapi:reference.

Currently one needs a source distribution to build a webapp

Currently the rhino/document module uses the js/document service provider interface to build documents from its Java DOM parser. But we should allow other implementations, including one based on the browser DOM. It is also currently impossible to generate XML from scratch using published APIs.

(Affects Windows)

Currently the slime.jsh.js tool looks for the Java subdirectory explicitly using a forward-slash; a comment says this is OK because of the bash dependency, but that dependency no longer exists.

(Affects Cygwin)

WARNING: could not locate Cygwin paths helper; could not find Cygwin native library path.
Use JSH_LIBRARY_NATIVE to specify location of Cygwin native libraries.

Does not make it clear what the consequences really are.

Provisional design: could have a top-level scope (top).

Then scope A (parent: top) would contain the host object, and we would load jsh.js into scope A.

Then we would put the jsh object into scope B (parent: top), and load the script into scope B.

JS 1.6: Array.prototype.lastIndexOf()\JS 1.6: Array.prototype.every()\JS 1.6: Array.prototype.some()\JS 1.8: Array.prototype.reduce()\JS 1.8: Array.prototype.reduceRight()\JS 1.8.5: isArray()\

All deprecation callbacks should be wrapped in try blocks.

Currently running a webapp in the Tomcat plugin does not work, apparently due to a classloader issue; code is at rhino/http/servlet/test/tomcat.jsh.js

Rhino 1.7R5 has been released, and there is one source-level patch (having to do with the negative cache for the Packages object) that would be useful to add.

Should create build-from-source option analogous to that used for ncdbg

(Affects Cygwin)

gcc4 does not accept it, so presumably compilation would fail on gcc4:

[[http://cygwin.com/ml/cygwin/2012-04/msg00504.html|http:~//cygwin.com/ml/cygwin/2012-04/msg00504.html]]

This issue was created by revision c8e6454ccb1c.

Right now, the search only finds files that have lower-case versions of PATHEXT extensions, which is surely incorrect. Should search the entire directory looking and do a case-insensitive comparison on each file to see whether it matches.

When jsapi (and presumably browser) executes an api.html file, an initialize at the same level as a context executes even if it is after the context because there is no easy way using the pseudo-DOM to deal with ordering of these things.

See test case in jsh/test/manual/api

jsh/test/jsh.httpd/httpd.jsh.js relies on /bin/sh to launch Tomcat, so the tests cannot run on Windows, for example.

Currently, the Pathname "constructor" or function specifically sets the constructor property of Pathname objects so that instanceof works as expected. However, Pathnames created by the module (e.g., via getRelativePath()) do not work.

Currently things like stack traces and profiler output are less clear because it does not.

(Involves rhino/http/client)
(Involves rhino/http/servlet)

Many similar concepts are used in multiple places; make them consistent and perhaps interoperable.

(Involves rhino/shell)

(Involves jsh/launcher)

(Involves jsh/loader)

Right now, something like three implementations of a search through the OS environment exist: one in the jsh launcher api.rhino.js file, and one in the rhino/shell inonit.script.runtime.shell.Environment class. Finally, the jsh loader supplies its own version of the environment in Main.java. They should be merged somehow.

Currently, jsh itself is loaded in the debugger and execution pauses before loading it.

Right now, this seems to be a no-op, but that could be wrong; should verify.

Currently, only a built version of jsh can be profiled. Not sure whether loader, launcher or both would be affected.

The Java launcher is now only used for packaged applications, so does not need to take into account the other possibilities.

This would require launching the shell in a ClassLoader rather than via a forked VM, in main.js. So a set of constraints would be placed upon the kinds of applications for which this feature would work and those for which it would not.

Given those limits, it's worth asking whether this should be done at all.

The other possibility would be finding a way for the Java child process to accurately receive the console of the parent process. Perhaps there is a way to do that.

They still largely follow an outdated, difficult-to-use structure from a much earlier version of jsapi.

Currently it assumes the existence of a built shell.

There was a Cygwin launcher but it probably makes little sense at this point; should compile natively for Windows.

With JNI being dropped from the launcher, it should be relatively straightforward to use the same mechanisms being used on UNIX to locate the jsh installation and the Java executable, and launch the Java executable.

Presumably using mingw to compile would make it possible to generate a Windows executable, though the development workflow may be cumbersome to set up (cross-compiling on UNIX, sending executable to Windows for testing).

Blocked on issue #169 (Windows)

Right now, the #! notation necessary for launching on UNIX-like systems is very cumbersome, and the command for launching a shell is similarly verbose. On top of that, for Windows users, there is very little choice for launching natively other than a long java command.

Currently there are several DOM node types that are not implemented.

There is a whole scope created in the unit tests that provides the ability to do things like create temporary directories, etc.

Right now, the preference order of servlet resource mappings is not defined (and works differently for the build and loader scenarios). They should be made consistent, and the best rule is that more specific mappings should override more general ones.

In the instance of identical prefixes, a rule is needed.

Figure out why.

This causes stop() to throw an exception currently.

Feb 19, 2013 2:33:01 PM org.apache.coyote.AbstractProtocol pause  
INFO: Pausing ProtocolHandler ["http-bio-43548"]  
Feb 19, 2013 2:33:01 PM org.apache.catalina.core.StandardService stopInternal  
INFO: Stopping service Tomcat  
Feb 19, 2013 2:33:01 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc  
WARNING: JDBC driver de-registration failed for web application [/]  
java.lang.NullPointerException  
        at org.apache.catalina.loader.WebappClassLoader.clearReferencesJdbc(WebappClassLoader.java:2054)  
        at org.apache.catalina.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:1990)  
        at org.apache.catalina.loader.WebappClassLoader.stop(WebappClassLoader.java:1902)  
        at org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:662)  
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)  
        at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5527)  
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)  
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575)  
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564)  
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)  
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)  
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)  
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)  
        at java.lang.Thread.run(Thread.java:679)

Test case is jsh/test/manual/httpd.lifecycle.jsh.js run -stop 2000