Welcome Sergei!
On Mon, Dec 12, 2016 at 1:54 AM, Roman Shaposhnik wrote:
> Welcome Sergei -- great to have you part of the Apache Groovy club!
>
> Thanks,
> Roman.
>
> On Sat, Dec 10, 2016 at 1:55 AM, Sergei Egorov wrote:
>> Hi, the Apache Groovy people!
>>
>> I'm excited to join the team! Big t
Nice work but my suspicion is that enhancements like this are best not
bundled into parrot but just made a separate PR. There is no reason
this can't be evaluated for inclusion into 2.5 independent of when
parrot is merged. WDYT?
Cheers, Paul.
On Wed, Dec 14, 2016 at 10:06 PM, wrote:
> Reposito
Hi all,
SimpleHTTPServer has been implemented(http://bit.ly/2hsKm0V), it
supports serving files not only under directory but also in the zip file.
Here is the usage: "-lh listen on a port and
provide http service", e.g.
*serve files under current directory*: groovy -lh 8000
*serve
Hi Daniel,
To be honest, I don't like it, -1 from me.
Why? Because we already put more and more stuff into the groovy itself,
but, i.e. in a case of python, SimpleHTTPServer it's just a module after
all.
I would rather see something like:
groovy -m com.sparkjava:spark-groovy -c "serve(port: 808
Hi Paul,
I agree with you, but in my fork(danielsun1106/groovy) contains many
exprimental commits and some failing build commits... I'm afraid these
commits will "pollute" apache/groovy if I create PR and the PR merged. Any
advice?
Cheers,
Daniel.Sun
--
View this message in context:
htt
> groovy -m com.sparkjava:spark-groovy -c "serve(port: 8080, path:
'd:\\temp')"
How many characters will we type... to be frank, I am not that patient to
type such a long command.
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy
-1 from me as well, fells more like a lib feature than a language feature.
I agree with other folks that it is bloating the language for quite a
narrow usecase.
On Wed, 14 Dec 2016 at 12:39, Sergei Egorov wrote:
> Hi Daniel,
>
> To be honest, I don't like it, -1 from me.
>
> Why? Because we alr
Hello there,
perhaps it's just me, but I keep bumping into code like
foo.bar.bax!=null?foo.bar.bax:whatever
Note that it cannot be replaced by an Elvis, for it would eat up falses (like
numeric zeroes, empty strings etc.)
In my personal opinion it would be nice to have a null-based Elvis for t
-1 as well.
While it is a cool feature, I have to agree that it feels more like a lib than
something that belongs in the language itself.
> On Dec 14, 2016, at 7:55 AM, Daniel Sun wrote:
>
>> groovy -m com.sparkjava:spark-groovy -c "serve(port: 8080, path:
> 'd:\\temp')"
> How many character
Actually you can think of -lh as an extention of existing -l, the latter
launches socket server and the former launches http server. We should have
hooked http server function to the existing socket server, but maintaining a
http server need much time and HR, so I implement it based on JDK
Maybe we can use -m to specify the module instead of the convenient way -lh,
e.g. groovy -m SimpleHTTPServer [base dir] [context root].
Thanks for your feedback.
Cheers,
Daniel.Sun
在 2016年12月15日 上午6:37，"Suderman Keith-3 [via Groovy]"
写道：
> wrote:
groovy -m com.sparkjava:spark-groovy -c "ser
Agreed. "parrot" should be kept about the gramma and not adding new features.
Cheers
On Wed, Dec 14, 2016 at 1:49 PM, Daniel Sun wrote:
> Hi Paul,
>
> I agree with you, but in my fork(danielsun1106/groovy) contains many
> exprimental commits and some failing build commits... I'm afraid the
With all the grammar improvements happening, one that has always
bothered me is having to do this:
@IgnoreIf( { System.getenv('TRAVIS') } )
def foo() {}
Instead of
@IgnoreIf { System.getenv('TRAVIS') }
def foo() {}
Could this be improved with the new grammar? Or are there still
ambiguity issues
13 matches
Mail list logo
