jamesladd / stc Goto Github PK

Redline Smalltalk needs to create a Maven Repository JAR when mvn deploy is run.

This will enable anyone wanting to use Redline Smalltalk to include the necessary JAR by including the Maven dependency into their Maven project.

Of course only core commiters should be able to run mvn deploy and have the result pushed to the Maven repository.

The import code in RedlineSmalltalk appears to use the wrong classname. If I am reading it correctly the import structure is as follows:

package of importing class -> class doing the import -> short name of the imported class -> full name of imported class

To properly support this I think the addImport method needs to have a 4 arg signature like:

public void addImport(String packageName, String importingClassName, String className, String fullClassName)

rather than the current:

public void addImport(String packageName, String className, String fullClassName)

Which leads to

package of importing class -> imported class (short) name -> imported class (short) name -> full name of imported class

and hence the resolution of the import cannot find the imported class.

I've been playing with the concept of the JVM receiver a little
JVMReceiver-Example.zip

You might not want to look at the code files, they are a bit hacky and woefully incomplete, but the smalltalk file might give you an idea of what I am thinking.

| tempVar |
tempVar := 3.
JVM invoke: 'println' on: 'java.lang.System.out' with: 'TestingJVM'.
JVM invoke: 'print' on: 'java.lang.System.out' with: 1.
JVM invoke: 'println' on: 'java.lang.System.out'.
JVM invoke: 'println' on: 'java.lang.System.out' with: 2 ofType: 'int'.
JVM invoke: 'println' on: 'java.lang.System.out' with: tempVar ofType: 'int'.

The core of it is to the JVM pseudo variable a suite of 'methods' like

invoke:on:
invoke:on:with:
invoke:on:with:ofType:

that can be used in different situations and have varying degrees of inference depending on whether the values given are literals or variables. That sort of thing.

Basically, I think if we can give the JVM reciever a nicer interface and some smarts, we can make it a little more natural to mix adaptor code with Smalltalk code. For example, we could perform calculations, call other methods, etc. using standard Smalltalk and use the result in the code output by the JVM receiver. I think your original one was much more limited, unless I am mistaken, and basically required you to write methods as if you were writing the byte code directly?

The other thing about giving it some smarts is that you can potentially detect some issues at (smalltalk) compile time, not when the code is executed, which I think was a bit of a problem before?

What do you think?

Matt

Branch to commit work to: jcl/emit-class

The ByteCodeEmitter is currently empty.

The ByteCodeEmitter class needs to emit bytecode for a Java Class which when constructed you can call sendMessages() on.

sendMessages(Smalltalk smalltalk) will invoke all the message sends contained within the generated class to carry out the instructions contained in the generated class. The message sends within the class may be a script (not create a new subclass) or messages to create a new subclass and add the associated methods to it.

An example Smalltalk class that does create a class is below:

Object subclass: #Test.

• instanceMethod
  ^ self.

• classMethod
  ^ self.

This is the same file after pre-processing (Note the instance and class method declarations have been
expanded into the corresponding message sends:

Object subclass: #Test.

Test basicAddSelector: #instanceMethod withMethod: [
^ self.
]. Test class basicAddSelector: #classMethod withMethod: [
^ self.
].

branch: jcl/add-more-trace-information

The visit trace statements are helpful but they need to output the line and column and some additional information. This will help people tracing the compiler and the compiler writer.

Trace now includes the line and column of the source and information on the current token being processed.

I noticed you mentioned that the current stuff can only be run using the IDE.
You could set up an execution target in Maven so that you can run it easily without the IDE. If you want to that is. The code I use is below ;-)

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.6.0</version>
    <configuration>
        <executable>java></executable>
        <mainClass>st.redline.Stic</mainClass>
        <arguments>
            <argument>st.redline.example.Test</argument>
        </arguments>
    </configuration>
</plugin>

The only problem with this, is you need to make your classpath handling more robust since Maven modifies the classpath at runtime, rather than specifying java.class.path variable.

Here's my hacky change to Stic's classPaths() method:

public String[] classPaths() {
    String[] classPaths = classPath().split(File.pathSeparator);

    ArrayList<String> urlClassPaths = new ArrayList<>(java.util.Arrays.asList(classPaths));
    URLClassLoader cl = (URLClassLoader) (Thread.currentThread().getContextClassLoader());
    for (URL url : cl.getURLs()) {
        if ("file".equals(url.getProtocol())) {
            urlClassPaths.add(url.getFile());
        }
    }

    classPaths = urlClassPaths.toArray(classPaths);

    return classPaths;
}

Cheers,

Matt

Branch: jcl/cache-sources

When finding a Smalltalk source file we look along the classpath and inside JAR's.
To remove the need to do this on every request for a Smalltalk source file we need
to introduce a source cache.

When we search a classpath or inside JAR's based on the package of the requested Smalltalk source
we cache the result. This will be especially useful when we "import packages" like 'st.redline.kernel'.

We only cache those sources found in the requested package so as not to load the every single source file. We are assuming loading those in the same package is appropriate as it is likely they will be used by the requested class who's package we are loading.