groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: Looking for testers & feedback: new Groovy binaries for Windows
Date Tue, 03 Jan 2017 01:39:07 GMT
I was on the right track with the GroovyStarter idea.  The problem is,
Launch4j doesn't do variable expansion in cmdLine (as you can see in head.c
<https://sourceforge.net/p/launch4j/git/ci/master/tree/head_src/head.c>,
and as mentioned here
<https://sourceforge.net/p/launch4j/discussion/332684/thread/b41c22bc/>).
I opened an issue <https://sourceforge.net/p/launch4j/bugs/162/> to request
this, but until the feature is available, it kills the idea of using
Launch4J I think.


On Mon, Oct 17, 2016 at 10:53 PM, Keegan Witt <keeganwitt@gmail.com> wrote:

> Thanks Paco,
> It looks like it's related to @GrabConfig(systemClassLoader=true), I'm
> looking into it.
>
> -Keegan
>
> On Mon, Oct 17, 2016 at 12:20 PM, Paco Zarate <contacto@nazcasistemas.com>
> wrote:
>
>> Hey Keegan,
>> Looks like there is a problem with Grapes and the .exe files:
>> I am attaching the test code (a sqlite example from SO)
>>
>> When i use the groovy.bat i got:
>> c:\Data\Samples\Groovy\sqlite>groovy.bat samplesqlite.groovy
>> id=1, name= leo
>> id=2, name= yui
>>
>> When i use the groovy.exe i got this error:
>> c:\Data\Samples\Groovy\sqlite>groovy.exe samplesqlite.groovy
>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
>> failed:
>> General error during conversion: No suitable ClassLoader found for grab
>>
>> java.lang.RuntimeException: No suitable ClassLoader found for grab
>>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
>> ConstructorAccessorImpl.java:62)
>>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
>> legatingConstructorAccessorImpl.java:45)
>>     at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>     at org.codehaus.groovy.reflection.CachedConstructor.invoke(Cach
>> edConstructor.java:83)
>>     at org.codehaus.groovy.runtime.callsite.ConstructorSite$Constru
>> ctorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>>     at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llConstructor(CallSiteArray.java:60)
>>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:235)
>>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:247)
>>     at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:184)
>>     at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown
>> Source)
>>     at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llCurrent(CallSiteArray.java:52)
>>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCu
>> rrent(AbstractCallSite.java:154)
>>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCu
>> rrent(AbstractCallSite.java:166)
>>     at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:251)
>>     at groovy.grape.Grape.grab(Grape.java:167)
>>     at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotati
>> onTransformation.java:378)
>>     at org.codehaus.groovy.transform.ASTTransformationVisitor$3.cal
>> l(ASTTransformationVisitor.java:321)
>>     at org.codehaus.groovy.control.CompilationUnit.applyToSourceUni
>> ts(CompilationUnit.java:931)
>>     at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation
>> (CompilationUnit.java:593)
>>     at org.codehaus.groovy.control.CompilationUnit.processPhaseOper
>> ations(CompilationUnit.java:569)
>>     at org.codehaus.groovy.control.CompilationUnit.compile(Compilat
>> ionUnit.java:546)
>>     at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader
>> .java:298)
>>     at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.j
>> ava:268)
>>     at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
>>     at groovy.lang.GroovyShell.run(GroovyShell.java:517)
>>     at groovy.lang.GroovyShell.run(GroovyShell.java:507)
>>     at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)
>>     at groovy.ui.GroovyMain.run(GroovyMain.java:384)
>>     at groovy.ui.GroovyMain.process(GroovyMain.java:370)
>>     at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
>>     at groovy.ui.GroovyMain.main(GroovyMain.java:109)
>>
>> 1 error
>>
>> Thanks!
>> Paco.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:50 PM, Keegan Witt <keeganwitt@gmail.com>
>> wrote:
>>
>>> Well there's the bat file in bin.  Might be good to keep it there at
>>> least initially, as a transition though.
>>>
>>> -Keegan
>>>
>>> On Oct 11, 2016 4:58 PM, "Paco Zarate" <contacto@nazcasistemas.com>
>>> wrote:
>>>
>>>> I would suggest to keep the gant.exe, it makes really clear that you
>>>> can execute that one on Windows. Otherwise I would not know that the
>>>> application is there. (as in Linux where you can see the .sh files)
>>>>
>>>> On Tue, Oct 11, 2016 at 2:49 PM, Keegan Witt <keeganwitt@gmail.com>
>>>> wrote:
>>>>
>>>>> Actually question I guess would be whether we even need a gant.exe.
>>>>> Nobody really doubleclicks gant files that I'm aware of.
>>>>>
>>>>> -Keegan
>>>>>
>>>>> On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt <keeganwitt@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Paco,
>>>>>> Thanks again for your help.  Yea, it assumes Gant will be installed
>>>>>> in the lib directory with the rest of the Groovy jars since that's
how it's
>>>>>> installed by the Windows installer.  If you drop the jar in there,
it
>>>>>> should work.
>>>>>>
>>>>>> I'm mostly liking these so far.  The only thing I might be able to
>>>>>> improve on is that all the jars in lib are included in the classpath
>>>>>> currently, whereas the C binaries I think were more explicit in some
cases
>>>>>> (gant I think being one of them).  I want to think through some more
>>>>>> whether there's any issues there.
>>>>>>
>>>>>> -Keegan
>>>>>>
>>>>>> On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate <
>>>>>> contacto@nazcasistemas.com> wrote:
>>>>>>
>>>>>>> Keegan,
>>>>>>> The new .exe files look really good, I will keep using them.
Even
>>>>>>> with a record in the PATH that includes an & (in a non-groovy
related
>>>>>>> folder) it is working fine.
>>>>>>>
>>>>>>> The only error was:
>>>>>>> paco@DEVELOPER2 C:\Users\paco
>>>>>>> > gant
>>>>>>> Error: Could not find or load main class gant.Gant
>>>>>>>
>>>>>>> paco@DEVELOPER2 C:\Users\paco
>>>>>>> > gant.exe
>>>>>>> Error: Could not find or load main class gant.Gant
>>>>>>>
>>>>>>> paco@DEVELOPER2 C:\Users\paco
>>>>>>> > gant.exe -v
>>>>>>> Error: Could not find or load main class gant.Gant
>>>>>>>
>>>>>>> But i think i am missing the gant install, i will read more about
>>>>>>> how to install gant correctly later today and let you know.
>>>>>>>
>>>>>>> Paco.
>>>>>>>
>>>>>>> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt <keeganwitt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I started experimenting with launch4j, and have put that
experiment
>>>>>>>> in this repo: https://github.com/keeganwitt/groovy-launch4j.
 I've
>>>>>>>> uploaded binaries into same place I previous linked.  The
first binaries I
>>>>>>>> uploaded are in batWrapper.zip, and the new launch4j based
binaries are in
>>>>>>>> launch4j.zip if anyone wants to try them out.  At the moment,
I only have
>>>>>>>> binaries that call Java (i.e. not bundled with Java).
>>>>>>>>
>>>>>>>> -Keegan
>>>>>>>>
>>>>>>>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt <keeganwitt@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hmm, maybe the bat files aren't as robust as I assumed
and I
>>>>>>>>> should rethink the approach.
>>>>>>>>>
>>>>>>>>> If we went the GCJ route, we'd still have to implement
our own
>>>>>>>>> logic to locate Java binaries (similar to how C code
does today), right?
>>>>>>>>> That'd be an option, though I'm a little hesitant to
start relying on
>>>>>>>>> something that looks like hasn't been updated in in several
years and only
>>>>>>>>> supports Java 1.4 and some of Java 5.
>>>>>>>>> Another option would be Launch4J, which is what I was
originally
>>>>>>>>> considering.  If we did that, we could even create 2
sets of binaries -- 1
>>>>>>>>> with a bundled JRE, and 1 without.  What kinda drew me
to that approach was
>>>>>>>>> that it already had its own logic for locating Java.
 I'll do some reading
>>>>>>>>> on both options.
>>>>>>>>>
>>>>>>>>> -Keegan
>>>>>>>>>
>>>>>>>>> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou <
>>>>>>>>> blackdrag@gmx.org> wrote:
>>>>>>>>>
>>>>>>>>>> Maybe a stupid question... but couldn't we write
an exe in Java
>>>>>>>>>> and compile using gcj. The exe would spawn a new
"normal" JVM and do the
>>>>>>>>>> argument handling. Unlike the C variant there would
be more people able to
>>>>>>>>>> handle this.
>>>>>>>>>>
>>>>>>>>>> bye Jochen
>>>>>>>>>>
>>>>>>>>>> On 08.09.2016 11:13, Paul King wrote:
>>>>>>>>>>
>>>>>>>>>>> I think there are numerous problems with the
argument passing in
>>>>>>>>>>> the
>>>>>>>>>>> batch files. That was one of the things that
the exe files aimed
>>>>>>>>>>> to
>>>>>>>>>>> improve on. I must admit to having reservations
about the new
>>>>>>>>>>> approach.
>>>>>>>>>>> Not so much with the concept but more about relying
on the
>>>>>>>>>>> current bat
>>>>>>>>>>> files. That said, I am not sure staying with
the current
>>>>>>>>>>> approach is
>>>>>>>>>>> ideal either.
>>>>>>>>>>>
>>>>>>>>>>> Cheers, Paul.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>>>>>>>>>>> contacto@nazcasistemas.com
>>>>>>>>>>> <mailto:contacto@nazcasistemas.com>>
wrote:
>>>>>>>>>>>
>>>>>>>>>>>     Hello Keegan
>>>>>>>>>>>     groovy and groovyc are working for me now!
thanks!!
>>>>>>>>>>>
>>>>>>>>>>>     The bat file seems to have an issue on Windows
though:
>>>>>>>>>>>
>>>>>>>>>>>     When the JAVA_HOME is not defined, and the
PATH has an
>>>>>>>>>>> element with
>>>>>>>>>>>     & (ampersand), the groovy invocation
seems to try to execute
>>>>>>>>>>> the
>>>>>>>>>>>     code after the & (eg. if mysql is installed
there is a PATH
>>>>>>>>>>> defined to
>>>>>>>>>>>     "c:\Program Files (x86)\MySQL\MySQL Fabric
1.5 & MySQL
>>>>>>>>>>> Utilities 1.5")
>>>>>>>>>>>     This is the output:
>>>>>>>>>>>     C:\WINDOWS\system32>groovy.bat -v
>>>>>>>>>>>     'MySQL' is not recognized as an internal
or external command,
>>>>>>>>>>>     operable program or batch file.
>>>>>>>>>>>     'MySQL' is not recognized as an internal
or external command,
>>>>>>>>>>>     operable program or batch file.
>>>>>>>>>>>     Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor:
Oracle
>>>>>>>>>>> Corporation OS:
>>>>>>>>>>>     Windows 10
>>>>>>>>>>>
>>>>>>>>>>>     I did this another test: I created an empty
folder
>>>>>>>>>>>     "c:\Programs\sample1 & sample2" and added
it to the PATH
>>>>>>>>>>> just before
>>>>>>>>>>>     "%GROOVY_HOME%\bin"
>>>>>>>>>>>
>>>>>>>>>>>     When i run:
>>>>>>>>>>>     C:\WINDOWS\system32> groovy.bat -v
>>>>>>>>>>>     'sample2' is not recognized as an internal
or external
>>>>>>>>>>> command,
>>>>>>>>>>>     operable program or batch file.
>>>>>>>>>>>     Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor:
Oracle
>>>>>>>>>>> Corporation OS:
>>>>>>>>>>>     Windows 10
>>>>>>>>>>>
>>>>>>>>>>>     So it looks like an ampersand in an element
in the PATH can
>>>>>>>>>>> affect
>>>>>>>>>>>     the groovy invocation.
>>>>>>>>>>>
>>>>>>>>>>>     Paco
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     On Wed, Sep 7, 2016 at 8:39 PM, Keegan Witt
<
>>>>>>>>>>> keeganwitt@gmail.com
>>>>>>>>>>>     <mailto:keeganwitt@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>         I've uploaded new executables to fix
the issue with
>>>>>>>>>>> invoking
>>>>>>>>>>>         without .exe suffix.
>>>>>>>>>>>
>>>>>>>>>>>         -Keegan
>>>>>>>>>>>
>>>>>>>>>>>         On Wed, Sep 7, 2016 at 5:21 PM, Keegan
Witt
>>>>>>>>>>>         <keeganwitt@gmail.com <mailto:keeganwitt@gmail.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>             Paco,
>>>>>>>>>>>             Good catch.  I'll correct that.
>>>>>>>>>>>
>>>>>>>>>>>             Raviteja,
>>>>>>>>>>>             That's correct, they are just wrappers.
 The
>>>>>>>>>>> advantage is
>>>>>>>>>>>             that you can set file associations
in Windows to an
>>>>>>>>>>> exe, but
>>>>>>>>>>>             you can't associate a file type with
a bat file.  If
>>>>>>>>>>> you
>>>>>>>>>>>             could, than you'd be right -- there'd
be no reason
>>>>>>>>>>> to have a
>>>>>>>>>>>             wrapper.
>>>>>>>>>>>
>>>>>>>>>>>             -Keegan
>>>>>>>>>>>
>>>>>>>>>>>             On Wed, Sep 7, 2016 at 1:57 PM, Raviteja
Lokineni
>>>>>>>>>>>             <raviteja.lokineni@gmail.com
>>>>>>>>>>>             <mailto:raviteja.lokineni@gmail.com>>
wrote:
>>>>>>>>>>>
>>>>>>>>>>>                 I just glanced over the code
and found that the
>>>>>>>>>>> cpp code
>>>>>>>>>>>                 just seems to be a wrapper on
top of existing
>>>>>>>>>>> bat file.
>>>>>>>>>>>                 Although it is good that you
wanted to
>>>>>>>>>>> contribute, I
>>>>>>>>>>>                 don't see the advantage in using
exe file iff
>>>>>>>>>>> all it
>>>>>>>>>>>                 does is wrap existing bat file.
>>>>>>>>>>>
>>>>>>>>>>>                 Thanks,
>>>>>>>>>>>                 Raviteja
>>>>>>>>>>>
>>>>>>>>>>>                 On Wed, Sep 7, 2016 at 5:45 AM,
Paco Zarate
>>>>>>>>>>>                 <contacto@nazcasistemas.com
>>>>>>>>>>>                 <mailto:contacto@nazcasistemas.com>>
wrote:
>>>>>>>>>>>
>>>>>>>>>>>                     Hello Keegan!
>>>>>>>>>>>
>>>>>>>>>>>                     I was trying the new .exe
files and i
>>>>>>>>>>> receive these
>>>>>>>>>>>                     errors when using the commands
without .exe:
>>>>>>>>>>>
>>>>>>>>>>>                     C:\WINDOWS\system32>groovyc
-v
>>>>>>>>>>>                     'groobat' is not recognized
as an internal or
>>>>>>>>>>>                     external command,
>>>>>>>>>>>                     operable program or batch
file.
>>>>>>>>>>>
>>>>>>>>>>>                     C:\WINDOWS\system32>groovy
-v
>>>>>>>>>>>                     'grobat' is not recognized
as an internal or
>>>>>>>>>>>                     external command,
>>>>>>>>>>>                     operable program or batch
file.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                     Including the .exe seems
 to work fine:
>>>>>>>>>>>
>>>>>>>>>>>                     C:\WINDOWS\system32>groovy.exe
-v
>>>>>>>>>>>                     Groovy Version: 2.4.7 JVM:
1.8.0_101 Vendor:
>>>>>>>>>>> Oracle
>>>>>>>>>>>                     Corporation OS: Windows 10
>>>>>>>>>>>
>>>>>>>>>>>                     C:\WINDOWS\system32>groovyc.exe
-v
>>>>>>>>>>>                     Groovy compiler version 2.4.7
>>>>>>>>>>>                     Copyright 2003-2016 The Apache
Software
>>>>>>>>>>> Foundation.
>>>>>>>>>>>                     http://groovy-lang.org/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                     If i remove the JAVA_HOME
env variable I get
>>>>>>>>>>> these
>>>>>>>>>>>                     responses:
>>>>>>>>>>>                     C:\WINDOWS\system32>groovy.exe
-v
>>>>>>>>>>>                     'MySQL' is not recognized
as an internal or
>>>>>>>>>>> external
>>>>>>>>>>>                     command,
>>>>>>>>>>>                     operable program or batch
file.
>>>>>>>>>>>                     'MySQL' is not recognized
as an internal or
>>>>>>>>>>> external
>>>>>>>>>>>                     command,
>>>>>>>>>>>                     operable program or batch
file.
>>>>>>>>>>>                     Groovy Version: 2.4.7 JVM:
1.8.0_101 Vendor:
>>>>>>>>>>> Oracle
>>>>>>>>>>>                     Corporation OS: Windows 10
>>>>>>>>>>>
>>>>>>>>>>>                     C:\WINDOWS\system32>groovyc.exe
-v
>>>>>>>>>>>                     'MySQL' is not recognized
as an internal or
>>>>>>>>>>> external
>>>>>>>>>>>                     command,
>>>>>>>>>>>                     operable program or batch
file.
>>>>>>>>>>>                     'MySQL' is not recognized
as an internal or
>>>>>>>>>>> external
>>>>>>>>>>>                     command,
>>>>>>>>>>>                     operable program or batch
file.
>>>>>>>>>>>                     Groovy compiler version 2.4.7
>>>>>>>>>>>                     Copyright 2003-2016 The Apache
Software
>>>>>>>>>>> Foundation.
>>>>>>>>>>>                     http://groovy-lang.org/
>>>>>>>>>>>
>>>>>>>>>>>                     Thanks!!
>>>>>>>>>>>
>>>>>>>>>>>                     Paco.
>>>>>>>>>>>
>>>>>>>>>>>                     On Thu, Sep 1, 2016 at 2:05
PM, Keegan Witt
>>>>>>>>>>>                     <keeganwitt@gmail.com
<mailto:
>>>>>>>>>>> keeganwitt@gmail.com>>
>>>>>>>>>>>                     wrote:
>>>>>>>>>>>
>>>>>>>>>>>                         I'm building some new
binaries for
>>>>>>>>>>> Windows
>>>>>>>>>>>                         (groovy.exe, groovyConsole.exe,
etc) and
>>>>>>>>>>> am
>>>>>>>>>>>                         looking for some folks
to test and code
>>>>>>>>>>> review
>>>>>>>>>>>                         it.  Their temporary
home is here:
>>>>>>>>>>>                         https://github.com/keeganwitt/
>>>>>>>>>>> groovy-binaries
>>>>>>>>>>>                         <https://github.com/keeganwitt
>>>>>>>>>>> /groovy-binaries>.  After
>>>>>>>>>>>                         I've incorporated any
feedback I get,
>>>>>>>>>>> I'll
>>>>>>>>>>>                         transfer it to a repo
under the groovy
>>>>>>>>>>> org on
>>>>>>>>>>>                         Github (haven't decided
yet whether that
>>>>>>>>>>> should
>>>>>>>>>>>                         begroovy-windows-installer
>>>>>>>>>>>                         <https://github.com/groovy/gro
>>>>>>>>>>> ovy-windows-installer> orgroovy-native-launcher
>>>>>>>>>>>                         <https://github.com/groovy/gro
>>>>>>>>>>> ovy-native-launcher>).
>>>>>>>>>>>
>>>>>>>>>>>                         To make it easy to test,
you can
>>>>>>>>>>> download the
>>>>>>>>>>>                         compiled binaries from
here
>>>>>>>>>>>                         (https://drive.google.com/fold
>>>>>>>>>>> erview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing
>>>>>>>>>>>                         <https://drive.google.com/fold
>>>>>>>>>>> erview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing>)
>>>>>>>>>>>
>>>>>>>>>>>                         and put them in your
current Groovy
>>>>>>>>>>> installation
>>>>>>>>>>>                         (whether from zip or
installer).
>>>>>>>>>>>
>>>>>>>>>>>                         The overall approach
is to have an exe
>>>>>>>>>>> that
>>>>>>>>>>>                         calls the matching .bat
file.  This
>>>>>>>>>>> approach was
>>>>>>>>>>>                         to avoid a few things
I didn't like
>>>>>>>>>>> about the
>>>>>>>>>>>                         current binaries, namely
>>>>>>>>>>>                         Windows installer determines
32 or 64 bit
>>>>>>>>>>>                         version of Java at install
time and
>>>>>>>>>>> installs the
>>>>>>>>>>>                         appropriate groovy.exe,
but if you
>>>>>>>>>>> change your
>>>>>>>>>>>                         Java version later, exe
won't be able to
>>>>>>>>>>> run
>>>>>>>>>>>                         Groovy because it won't
be able to find
>>>>>>>>>>> right
>>>>>>>>>>>                         Java to invoke.
>>>>>>>>>>>                         Binaries have their own
logic to find
>>>>>>>>>>> Java,
>>>>>>>>>>>                         which adds unnecessary
complexity since
>>>>>>>>>>> the
>>>>>>>>>>>                         batch files maintained
by the Groovy team
>>>>>>>>>>>                         already have this logic.
>>>>>>>>>>>                         Parameters are hard-coded
into the
>>>>>>>>>>> binaries,
>>>>>>>>>>>                         coupling any change in
parameters
>>>>>>>>>>> between Groovy
>>>>>>>>>>>                         versions to that binary.
>>>>>>>>>>>                         I'm not a Windows or
C++ guy, so there
>>>>>>>>>>> are some
>>>>>>>>>>>                         things I'd like somebody's
thoughts on:
>>>>>>>>>>>                         Am I following best practices
in C++
>>>>>>>>>>> source and
>>>>>>>>>>>                         Makefile?
>>>>>>>>>>>                         Would it be better to
have wmain()
>>>>>>>>>>> instead of
>>>>>>>>>>>                         main()?
>>>>>>>>>>>                         Any better way to have
done resource
>>>>>>>>>>> templating
>>>>>>>>>>>                         other than/sed/?
>>>>>>>>>>>                         Would there be a reason
to have chosen C
>>>>>>>>>>> over C++?
>>>>>>>>>>>                         Any non-ASCII character
hangups?
>>>>>>>>>>>                         Runninggroovy.exe 象.groovy
象 seemed to
>>>>>>>>>>> invoke
>>>>>>>>>>>                         and pass argument in
fine, but it
>>>>>>>>>>> printed the
>>>>>>>>>>>                         arg as a question mark.
 Although the
>>>>>>>>>>> current
>>>>>>>>>>>                         binaries binaries do
the same thing,
>>>>>>>>>>>                         so maybe it's a limitation
of/cmd.exe/.
>>>>>>>>>>>                         Does my strategy of passing
args from
>>>>>>>>>>> exe to bat
>>>>>>>>>>>                         have any edge cases to
worry about with
>>>>>>>>>>> the use
>>>>>>>>>>>                         of system() andCreateProcess()?
>>>>>>>>>>>
>>>>>>>>>>>                         -Keegan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 --
>>>>>>>>>>>                 *Raviteja Lokineni* | Business
Intelligence
>>>>>>>>>>> Developer
>>>>>>>>>>>                 TD Ameritrade
>>>>>>>>>>>
>>>>>>>>>>>                 E: raviteja.lokineni@gmail.com
>>>>>>>>>>>                 <mailto:raviteja.lokineni@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>                 View Raviteja Lokineni's profile
on LinkedIn
>>>>>>>>>>>                 <http://in.linkedin.com/in/ravitejalokineni>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

Mime
View raw message