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 04:07:46 GMT
>> " From my understanding of implementations of the chdir() method, this
stores a common path to be used
>>by other methods in determining path."

> 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 .

You seem to be missing the point.  I'm not talking about 'native OS
functionality'. I'm still talking env.

And chdir() in Ruby IS only for 'working directory' (read documentation).
It does not affect changing directory for other contexts. And thus this
variable IS stored so that the applicaton is aware of 'current working
directory'

In Java/Groovy applications such as Spring/Grails, you will have a variety
of paths(ie jar,war,catalina, application path, plugin path, etc). The list
goes on and on. chdir() is a VERY LIMITED method and IMHO, not worth the
time and effort for what little it provides.

Owen Rubel
415-971-0976
orubel@gmail.com

On Sun, Jul 5, 2015 at 7:15 PM, Zaxebo Yaxebo <zaxebo1@gmail.com> wrote:

> 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