>
>Not sure what you mean here. Could you provide more info or a patch
>and some example code?
Sure, the code from fileUtil is below. I believe this was necessary for running
under NT:
static File
getNewFileObj(
Interp interp, // Current interpreter.
String fileName) // File to create object for.
throws
TclException
{
final boolean debug = false;
fileName = translateFileName(interp, fileName);^M
*/
static File
getNewFileObj(
Interp interp, // Current interpreter.
String fileName) // File to create object for.
throws
TclException
{
final boolean debug = false;
fileName = translateFileName(interp, fileName);^M
/* ^M
* EP:05/02/1999: Added this to 1.2, copied from 1.0 code.^M
* EP:05/20/1998: Added code to handle PATH_VOLUME_RELATIVE^M
* EP:05/20/1998: This involves changing the path type detection and^M
* EP:05/20/1998: ensuing conditional expression from if to ^M
* EP:05/20/1998: a switch.^M
*/^M
int pathType = getPathType(fileName);^M
File f=null;^M
switch (pathType) {^M
case PATH_VOLUME_RELATIVE:^M
f = new File(fileName);^M
break;^M
case PATH_ABSOLUTE:^M
f = new File(fileName);^M
break;^M
// In this case we just get the current working^M
// drive letter.^M
// String path_prepend = interp.getWorkingDir().toString().substring(0,
3);^M
// f = new File(path_prepend, fileName);^M
// break;^M
case PATH_RELATIVE:^M
// Here we need to get the current working directory.^M
f = new File(interp.getWorkingDir(), fileName); ^M
break;^M
}^M
return (f);^M
/* if (debug) {
System.out.println("File name is \"" + fileName + "\"");
}
if (getPathType(fileName) == PATH_ABSOLUTE) {
if (debug) {
System.out.println("File name is PATH_ABSOLUTE");
}
return new File(fileName);
} else {
if (debug) {
System.out.println("File name is relative");
}
return new File(interp.getWorkingDir(), fileName);
}^M
*/
}
>
>> 1. add support to handle PATH_VOLUME_RELATIVE in FileUtil
>
>I added support for passing 64 bit numbers around to Java methods
>back in version 1.2.2 but there is no support for doing expr's on
>64 bit numbers. The C version of Tcl does not support this either.
This little code change within Utils.java in StroulResult allows the usage of >
32 bit integers. It may not be C-Tcl compatible, but it allows the usage of
longs, which is really handy if you are trying to manipulate the result of java
return values within the native jacl expr.
// EP 05/02/1999: Carried over from 1.0 to 1.2.
// EP: 4/24/98: Increased to __ bits from 32.
// New line below:
long max = (((long) ((long) 1 << 62)) / ((long) base));
// Old line commented out.
// long max = (((long) ((long) 1 << 32)) / ((long) base));
>
>> 2. set the max integer size in Utils.StroulResult greater than 32 in order to
>> handle integer strings that are the result of long java return values (e.g.
>> currentTimeMillis).
>
>I have no idea what you mean by this. All string that are run through eval
>could run into subst issues. Could you provide more info about what you
>mean?
Sure, perhaps I'm not clear on the concept myself, but I'll try. Perhaps I
described the wrong solution to the problem, on too little sleep. The problem
is that if you substitute arbitrary text into a string and then subst that
string you can run into problems -- because the arbitrary text may include $ or
". This can arise if you are building a template and subsituting user input into
it, and then subst'ing the template. This is a classic tcl technique that I
don't really use very much, because it is so dangerous with arbitrary text.
Nevermind on this one... The solution I was thinking of was a way of protecting
a string variable from x levels of evaluation, or a structure or a command mode
which would block evaluation of the arguments.
>> These are enhancement requests:
>> 3. I think it would be great to be able to set a string as non-executable.
When
>> handling arbitrary text within the tcl/jacl it can be quite troublesome
dealing
>> with the accidental evaluation of text which normally works but sometimes
(when
>> the text happens to have the usual suspects $ " and common friends []{})
fails.
>> Being able to set the attribute of a jacl string to non-executable would
really
>> help.
>
>Well, Jacl should work with more than one interp (one in each thread). I
>have not tested it that much but it should work. Of course, interthread
>communications would be a great.
I use it like this all the time, one per thread. But creating threads within
jacl is what I'm wondering about, and interthread communication, say through the
parent interpreter.
>
>> 4. My next ambition for jacl would be multithreading -- interpreters which
can
>> spin off indpendent interpreter threads and interthread communications, etc.
In
>> my application I'd like to run a master interpreter which spins off "chron"
>> interpreters, interpreters to handle http connections, interpreters to handle
>> other background tasks, and so on. Right now each thread needs its own
>> independent interpreter and any inter-interpreter state information is
retained
>> by the master java application.
>
>The next release will fully support namespaces. In fact, you can try out
>a prerelease which includes these features right now if you like.
>
>> Namespace support is certainly a start. Are
>> there plans for this?
>
>later
>mo
>
>
>> >
>> >There is a new prerelease of Jacl ready for downloading at
>> >http://www.cs.umn.edu/~dejong/tcl/tcljava/pre. A precompiled
>> >binary and a source dist are provided. Anyone using an earlier
>> >prerelease should try this version out ASAP. This prerelease
>> >includes a "namespace aware" version of the info command and
>> >supports importing and exporting of commands from namespaces.
>> >This prerelease also includes unicode string support in the
>> >parser and an update to the package command.
>> >
>> >By the way, the 1.2.4 versions of Jacl and Tcl Blend should
>> >be done real soon now. If anyone has any changes that they
>> >want to get into the tree please make them known now. New
>> >development on the 1.2 tree may come to an end after the
>> >1.2.4 release so now is the time to get any changes in.
>> >After that a new tree (named 1.3 or perhaps 1.4) will
>> >be started for development and the 1.2 tree will become the
>> >"stable" release.
>> >
>> >Mo DeJong
>> >[EMAIL PROTECTED]
>> >
>> >----------------------------------------------------------------
>> >The TclJava mailing list is sponsored by WebNet Technologies.
>> >To subscribe: send mail to [EMAIL PROTECTED]
>> > with the word SUBSCRIBE as the subject.
>> >To unsubscribe: send mail to [EMAIL PROTECTED]
>> > with the word UNSUBSCRIBE as the subject.
>> >To send to the list, send email to '[EMAIL PROTECTED]'.
>> >A list archive is at: http://www.findmail.com/listsaver/tcldallas/
>> >
>>
>> +-------------------------------------------------------------------+
>> | Erik Pearson [EMAIL PROTECTED] |
>> | WWW Engineer http://www.adaptations.com |
>> | Adaptations 510-527-5437 |
>> +-------------------------------------------------------------------+
>>
>
+-------------------------------------------------------------------+
| Erik Pearson [EMAIL PROTECTED] |
| WWW Engineer http://www.adaptations.com |
| Adaptations 510-527-5437 |
+-------------------------------------------------------------------+
----------------------------------------------------------------
The TclJava mailing list is sponsored by WebNet Technologies.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
A list archive is at: http://www.findmail.com/listsaver/tcldallas/
