groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zaxebo Yaxebo <zaxe...@gmail.com>
Subject Re: chdir() implementation requested in groovy, just like jruby
Date Mon, 06 Jul 2015 02:15:14 GMT
owen>> " From my understanding of implementations of the chdir() method,
this stores a common path to be used by other methods in determining path."

my feedback>> no. thats^ the methodology followed by jython. That is the
old approach.

Nowadays, the  new approach of JNA/JNR implementation of chdir(),getcwd()
accesses the "native OS functionality" itself, in a very cross platform way
- but still without needing to be recompiled for each native platform .

zax

On Mon, Jul 6, 2015 at 7:26 AM, Owen Rubel <orubel@gmail.com> wrote:

> 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