I don't think JRubyScriptEngine needs to call parse methods directly.
evalScriptlet and evalFile methods are enough to execute a given
script and get an output. However, rewriting parseXXX to evalXXXX
methods needs further changes on JRubyScriptEngine, since it uses own
evalNode method to execute a script like this:
private synchronized Object evalNode(Node node, ScriptContext ctx)
throws ScriptException {
GlobalVariables oldGlobals = runtime.getGlobalVariables();
try {
setGlobalVariables(ctx);
return rubyToJava(runtime.eval(node));
} catch (Exception exp) {
throw new ScriptException(exp);
} finally {
if (oldGlobals != null) {
setGlobalVariables(oldGlobals);
}
}
}
This is why I kept parse methods. The supposed problem is that both
evalScriptlet and evalFile methods don't give us the way of setting a
scope, though I don't know how a scope works. If these methods allow
us to set the scope, implementors would not need to use internal
parseXXX methods directly.
-Yoko
On 10/30/07, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
> It looks like a step in the right direction. I need to examine
> compileScript in the impl to see if perhaps we cannot even abstract a
> little bit more. Regardless, I suspect having a parse in
> JavaEmbedUtils is probably right.
>
> -Tom
>
> On 10/29/07, Yoko Harada <[EMAIL PROTECTED]> wrote:
> > According to the message posted to jruby-user by Tom, I created some
> > methods that encapsulate internal parseXXX methods. I attached a diff
> > of JavaEmbedUtils.java, but I'm not sure this works as a patch file
> > because I compared with the original file in .svn directory. Since
> > current version of parseXXX methods don't need RAW data, I didn't wrap
> > Java String Object by JavaEmbedUtils.javaToRuby().
> >
> > New version of JRubyScriptEngine.java that uses new encapsulated
> > methods would be like this:
> >
> > private synchronized Node compileScript(String script, ScriptContext
> > ctx)
> > throws ScriptException {
> > GlobalVariables oldGlobals = runtime.getGlobalVariables();
> > try {
> > setGlobalVariables(ctx);
> > String filename = (String)
> > ctx.getAttribute(ScriptEngine.FILENAME);
> > if (filename == null) {
> > filename = "<unknown>";
> > }
> > return JavaEmbedUtils.parse(runtime, script, filename);
> > } catch (Exception exp) {
> > throw new ScriptException(exp);
> > } finally {
> > if (oldGlobals != null) {
> > setGlobalVariables(oldGlobals);
> > }
> > }
> > }
> >
> > private synchronized Node compileScript(Reader reader,
> > ScriptContext ctx) throws ScriptException {
> > GlobalVariables oldGlobals = runtime.getGlobalVariables();
> > try {
> > setGlobalVariables(ctx);
> > String filename = (String)
> > ctx.getAttribute(ScriptEngine.FILENAME);
> > if (filename == null) {
> > return JavaEmbedUtils.parse(runtime, reader);
> > } else {
> > return JavaEmbedUtils.parse(runtime, reader, filename,
> > runtime.getCurrentContext().getCurrentScope());
> > }
> > } catch (IOException exp) {
> > throw new ScriptException(exp);
> > }
> > }
> >
> > These changes worked correctly as I wanted to do when I tested JSR223
> > API by executing small programs. Are these appropriate?
> >
> > -Yoko
> >
> > On 10/26/07, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
> > > Yes. So combine this with my other message about encapsulating bodies
> > > of those methods into JavaEmbedUtils. This will also help our impl
> > > of BSF.
> > >
> > > -Tom
> > >
> > > On 10/26/07, Yoko Harada <[EMAIL PROTECTED]> wrote:
> > > > It seems that JSR 223 implementation made an unwanted path to parser.
> > > > JSR223's JRubyScriptEngine gives encoded, not RAW string to parser.
> > > > Sounds like a JRubyScriptEngine's problem, again.
> > > >
> > > > -Yoko
> > > >
> > > > On 10/26/07, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
> > > > > Incoming string to parser should be treated as RAW or ISO8859_1 so
> > > > > that every single byte still gets read. The parser will not properly
> > > > > read chars since Ruby only works at a byte level. Did that make
> > > > > sense?
> > > > >
> > > > > -Tom
> > > > >
> > > > > On 10/26/07, Yoko Harada <[EMAIL PROTECTED]> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > While I was testing JSR223 API, I hit JRuby's i18n bug. After fixing
> > > > > > problems in JSR223's JRubyScriptEngine, I tried to print Japanese
> > > > > > characters. This ended up in Mojibake. Supposed bug resides in
> > > > > > org.jruby.astStrNode and org.jruby.util.ByteList, both of them
> > > > > > handle
> > > > > > characters as byte array. ByteList.append(int) method invoked from
> > > > > > StringTerm.parseStringIntoBuffer method casts 16 bits char to 8 bits
> > > > > > byte. As a result, this method drops 8btis and causes Mojibake. Like
> > > > > > other mutibyte languages, Japanese characters needs 16bits to
> > > > > > express
> > > > > > a single character, so byte type, which has only 8bits, is short for
> > > > > > multibyte languages. In terms of i18n, StrNode should have a char
> > > > > > based buffer rather than a ByteList type.
> > > > > >
> > > > > > But, if StrNode needs to keep a byte array, the i18n problem should
> > > > > > be
> > > > > > fixed by converting character correctly to byte array as in this
> > > > > > code.
> > > > > >
> > > > > > import java.io.UnsupportedEncodingException;
> > > > > > import java.nio.ByteBuffer;
> > > > > > import java.nio.CharBuffer;
> > > > > > import java.nio.charset.CharacterCodingException;
> > > > > > import java.nio.charset.Charset;
> > > > > > import java.nio.charset.CharsetEncoder;
> > > > > > import java.util.logging.Level;
> > > > > > import java.util.logging.Logger;
> > > > > >
> > > > > > public class CharacterTest {
> > > > > >
> > > > > > public static void main(String[] args) throws
> > > > > > UnsupportedEncodingException {
> > > > > > char[] hello = {'こ', 'ん', 'に', 'ち', 'は'}; //Japanese
> > > > > > characters are here.
> > > > > > String defaultEncodingName =
> > > > > > System.getProperty("sun.jnu.encoding");
> > > > > > for (char c : hello) {
> > > > > > byte[] bytes = getByteArrayFromChar(c,
> > > > > > defaultEncodingName);
> > > > > > System.out.print(new String(bytes,
> > > > > > defaultEncodingName));
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > private static byte[] getByteArrayFromChar(char c, String
> > > > > > encodingName) {
> > > > > > try {
> > > > > > CharsetEncoder encoder =
> > > > > > Charset.forName(encodingName).newEncoder();
> > > > > > CharBuffer cbuf = CharBuffer.allocate(1);
> > > > > > cbuf.put(c);
> > > > > > cbuf.flip();
> > > > > > ByteBuffer buf = encoder.encode(cbuf);
> > > > > > int nbytes = buf.limit();
> > > > > > byte[] encodedBytes = new byte[nbytes];
> > > > > > buf.get(encodedBytes);
> > > > > > return encodedBytes;
> > > > > > } catch (CharacterCodingException ex) {
> > > > > >
> > > > > > Logger.getLogger(CharacterTest3.class.getName()).log(Level.SEVERE,
> > > > > > null, ex);
> > > > > > }
> > > > > > return null;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > -Yoko
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list please visit:
> > > > > >
> > > > > > http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Blog: http://www.bloglines.com/blog/ThomasEEnebo
> > > > > Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list please visit:
> > > > >
> > > > > http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > > http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > >
> > >
> > > --
> > > Blog: http://www.bloglines.com/blog/ThomasEEnebo
> > > Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Blog: http://www.bloglines.com/blog/ThomasEEnebo
> Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
