groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: chdir() implementation requested in groovy, just like jruby
Date Mon, 06 Jul 2015 15:00:20 GMT
Treating JNR/JNA as a separate issue, what would you want to see Groovy do
to implement?  Are you proposing adding a JNR/JNA DSL?  If not, why
wouldn't it work to just pull in JNR or JNA with @Grab?  Sorry if that's a
dumb question, I've not used either.

-Keegan

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

> 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