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 04:53:00 GMT
by the way, *JNR*(Java native runtime) *is Apache 2.0 Licensed ( see
https://github.com/jnr/jnr-ffi/blob/master/LICENSE
<https://github.com/jnr/jnr-ffi/blob/master/LICENSE> )*
I mentioned this - because this may be a point of consideration as groovy
is now part of Apache. So, "license wise" the  inclusion of JNR in
groovy-gdk should not pose any reconsideration.

Thanks
zax

On Mon, Jul 6, 2015 at 10:12 AM, Zaxebo Yaxebo <zaxebo1@gmail.com> wrote:

> I can see your logic.
> but, I have already *"modified my proposal*" as Proposal Version 2.0:
>
> Now, *I do not request for chdir()* implementation,as mandatory
> requirement.
> *I proposed that JNR (or JNA) is quite useful to be included in groovy-gdk
> *, This will extend the reach to all the native functionality in groovy
> in a single shot, even without providing the implementation for each
> individual functionality.
> Even if chdir() functionality is not provided, but still inclusion of JNR
> or JNA into groovy-gdk will lead to easy individual implementation and lots
> of other native functionality in a single shot.
>
> *RATIONALE:*
>  a) Groovy allows us to to acess all the funcionality of *JDK* (java
> development kit) in easy way
>  b) groovy provides its own convenience methods in* GDK* (groovy
> development kit)
>  c) but whole lot of native OS functionalities or other functionalities in
> .so/.dll still require JNI implementation. If JNR is included as inbuilt
> into GDK , then if somebody wants to roll out his own chdir() he can do
> easily, if somebody wants to access POSIX/win32 API extended
> functionalities, XFS etc extended functionalities , Device programming
> through a native dll - then that end-user can implement his own methods
> using this JNR in one shot. Groovy will not implement these functionalities
> on its own, it will just provide base functionality to access native
> functionality - by inclusion of JNR. So a single inclusion of a .jar of JNR
> will enable the groovy programmers to access all the native platform
> functionalities in extended way.  *We can think of JNR as NDK (native
> development kit).*
>
>                   This will bring NDK (native functionalities , ie JNR),
> GDK functionalities, JDK functionalities on one par.
>
>
>
>
> *Spring,grails etc are just one type of users of groovy - which is
> Enterprise usage. But, We another type of users - who are using groovy to
> script native platform (device programming, file system programming with
> extended attributes etc) are also a user domain of groovy. *
>
> *Even if chdir() is not implement , no problem. But whether the inclusion
> of JNR , in form of thinking it as NDK(native development kit) , in groovy
> - so that end-user can just write his own small script with native
> functionalities - does this Proposal version 2.0 make it to you.*
>
> Again,
>
> * saying my Proposal Version 2.0 is that:           if chdir() via JNR is
> implemented ..well and good.*
>
> *          but, even   If chdir() is not implemented, but still JNR
> becomes part of groovy-jdk , then that still will be a heaven's boon for
> all of us scripters. *
>
> Thanks
>  zax
>
> On Mon, Jul 6, 2015 at 9:37 AM, Owen Rubel <orubel@gmail.com> wrote:
>
>> >> " 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