You missed the whole point of wherein I stated 'which environment I am in'.
>From my understanding of implementations of the chdir() method, this stores
a common path to be used by other methods in determining path. Path can not
only be a PROPERTY read from config, but it can be ENV based.
You are actually overthinking the problem in alot of ways.
Owen Rubel
415-971-0976
oru...@gmail.com
On Sun, Jul 5, 2015 at 5:47 PM, Zaxebo Yaxebo <zaxe...@gmail.com> wrote:
> Thanks for the feedback.
>
> Those users like me, who want to use groovy for scripting for Operating
> system domain, and replace shellscript/ruby/python scripts with the one
> "groovy" language script there. We obviously need changeDirectory(chdir())
> function. This is the case of missing of "only one very core filesystem
> manipulation function (chdir) from groovy-gdk".
>
> As you said, why - "it will depend upon env. framework and alot of
> variables that need to be set by a developer creating a required config
> over convention functionality".???
> if JNA method for chdir() is finalised, then it only requires almost the
> following code:
>
> import com.sun.jna.NativeLibrary;
>
> import com.sun.jna.Platform;
> import java.io.*;
>
> /**
>
> - Call native low level Posix functions.
> */
> public class Posix
> {
> private static final int MAX_PATH = 1024;
> private NativeLibrary cLib = null;
> public void chdir(String dirName)
> Unknown macro: { int error =
> getCLib().getFunction(getOsDependentFuntionName("chdir")).invokeInt( new
> Object[] { dirName }); if (error != 0) throw new Error("Could not change
> working directory to}
>
> private NativeLibrary getCLib()
> { if (cLib == null) cLib = NativeLibrary.getInstance(null); // Will
> load libcxxx.so or msvcrt.dll return cLib; }
>
> public String getcwd()
> Unknown macro: { String cwd =
> getCLib().getFunction(getOsDependentFuntionName("getcwd")).invokeString(
> new Object[] { new String(new byte[MAX_PATH]), MAX_PATH }, false); return
> cwd; }
>
> private String getOsDependentFuntionName(String fname)
> { if (Platform.isWindows()) return "_" + fname; return fname; }
>
> }
>
>
> In single threaded environments like shell scripting, it is really very
> stable and rocks solid.
>
> =============
> alternative proposal:
> Though i would pray that this feature of chdir() is implemented.
> But, Just in case, this chdir() function is not implemented , i would
> still suggest/request* that atleast JNA or JNR .jar to be bundled with
> groovy*, so that user can access large native functionality without
> writing JNI code. The entire JNA/JNR end-user's source code will always be
> in java/groovy. It will replace lot of C/C++ coding of JNI. Say,It will
> enable user to access extended file system attributes (say for XFS,/proc
> type file systems) directly from native functions, for those file systems
> for which java driver is not there. It will let us access other Posix API
> or native Win32 API functions etc , directly from java/groovy code without
> writing glue C/C++ JNI code.
> This native accessing functionality without writing glue C/C++ code, will
> let groovy core reach extend to lots of native functionality.
>
> Probably, those who are into Web development etc may not need it. But
> those like us who want to communicate to other native accessing
> functionality without compiling any .so on their own, we want to use
> groovy for scripting these cases also. Groovy can atleast provide JNA/JNR
> functionality out of the box, to enable large native functionality access
> out of the box, for which there is no inbuilt functionality in jdk.
>
> zax
>
>
> On Mon, Jul 6, 2015 at 2:28 AM, Owen Rubel <oru...@gmail.com> wrote:
>
>>
>> Well... The only thing really competing with JRuby is Ruby.
>>
>> Groovy isn't a bridge for another language which is why it's approx 4x
>> faster than JRuby.
>>
>> It's purpose isn't to mock every other language but to implement
>> convention over config concepts, provide a scripting language for Java,
>> simplified functions.
>>
>> The chdir() function really really depends on env, framework and alot of
>> variables that need to be set by a developer creating a required config
>> over convention functionality. You CAN automate it but you lose speed when
>> running over simplicity.
>>
>> I think thats why it won't be implemented IMHO.
>>
>>
>> Owen Rubel
>> 415-971-0976
>> oru...@gmail.com
>>
>> On Sun, Jul 5, 2015 at 11:26 AM, Zaxebo Yaxebo <zaxe...@gmail.com> wrote:
>>
>>> jvm has no chdir() function to change current working directory.
>>>
>>> As groovy positions itself as competitor to jruby and other scripting
>>> language, and jruby implements chdir() using JNR (not using JNI)
>>>
>>> jython also implements chdir() on its own, but its implementation has
>>> some limtation. And jruby's implementation of chdir() function is best and
>>> stable.
>>>
>>> I have filed an enhancement request of adding a chdir() function to
>>> groovy using JNA or JNR.
>>> I have given sample code to achieve this using JNA.
>>>
>>> please give your feedback at
>>> https://issues.apache.org/jira/browse/GROOVY-7493
>>> for this enhancement feature request.
>>>
>>> zaxebo1
>>>
>>
>>
>
