You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Zaxebo Yaxebo <za...@gmail.com> on 2015/07/05 20:26:08 UTC
chdir() implementation requested in groovy, just like jruby
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
Re: chdir() implementation requested in groovy, just like jruby
Posted by Zaxebo Yaxebo <za...@gmail.com>.
also additionally note that this "new approach" of JNR (library being used
by jruby for native access) *is already a JEP 191*.
see this url ==> http://openjdk.java.net/jeps/191
https://github.com/jnr/jnr-ffi
https://github.com/jnr
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 of
chdir() and lots of other native functionality in a single shot.
Those who needed to use JNI for this and carry .so/.dll of their own
library for each platform, is now thing of past with new approach of JNR/
JNA.
If groovy allows us to access all the functionality of JDK in easy way, in
the same way it inbuilt allowed all the native functionality of OS in easy
way (by inclusion of JNR/JNA), then that will be really a dream come true
for us.
Thanks.
zax
On Mon, Jul 6, 2015 at 7:45 AM, Zaxebo Yaxebo <za...@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 <or...@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 <za...@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 <or...@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 <za...@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
>>>>>
>>>>
>>>>
>>>
>>
>
Re: chdir() implementation requested in groovy, just like jruby
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 06.07.2015 06:07, schrieb Owen Rubel:
[...]
> 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.
if you think of using Groovy as a bash-script replacement, then it might
be very good to have something like that.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: chdir() implementation requested in groovy, just like jruby
Posted by Zaxebo Yaxebo <za...@gmail.com>.
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 <or...@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 <za...@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 <or...@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 <za...@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 <or...@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 <za...@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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: chdir() implementation requested in groovy, just like jruby
Posted by Owen Rubel <or...@gmail.com>.
>> " 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 <za...@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 <or...@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 <za...@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 <or...@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 <za...@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
>>>>>
>>>>
>>>>
>>>
>>
>
Re: chdir() implementation requested in groovy, just like jruby
Posted by Zaxebo Yaxebo <za...@gmail.com>.
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 <or...@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 <za...@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 <or...@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 <za...@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
>>>>
>>>
>>>
>>
>
Re: chdir() implementation requested in groovy, just like jruby
Posted by Owen Rubel <or...@gmail.com>.
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 <za...@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 <or...@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 <za...@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
>>>
>>
>>
>
Re: chdir() implementation requested in groovy, just like jruby
Posted by Zaxebo Yaxebo <za...@gmail.com>.
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 <or...@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 <za...@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
>>
>
>
Re: chdir() implementation requested in groovy, just like jruby
Posted by Owen Rubel <or...@gmail.com>.
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 <za...@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
>