groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Rubel <oru...@gmail.com>
Subject Re: chdir() implementation requested in groovy, just like jruby
Date Mon, 06 Jul 2015 01:56:45 GMT
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
orubel@gmail.com

On Sun, Jul 5, 2015 at 5:47 PM, Zaxebo Yaxebo <zaxebo1@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 <orubel@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
>> orubel@gmail.com
>>
>> On Sun, Jul 5, 2015 at 11:26 AM, Zaxebo Yaxebo <zaxebo1@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
>>>
>>
>>
>

Mime
View raw message