Re: toDebugString as a Groovy core concept

[mg]

PS: I sent my reply from my son's gmail dev account, sorry for any  potentialy 
confusion :-)
 Ursprüngliche Nachricht Von: Guillaume Laforge 
 Datum: 03.01.18  22:41  (GMT+01:00) An: 
d...@groovy.apache.org Cc: users@groovy.apache.org Betreff: Re: toDebugString 
as a Groovy core concept 
Out of curiosity, you know about the dump() method on Object?How close / 
different is it from your proposal of toDebugString()?(dump() had that same 
purpose initially)
Guillaume

On Wed, Jan 3, 2018 at 6:39 PM, MG  wrote:
Hi all,



I have created a jira for my proposed toDebugString Groovy feature:

https://issues.apache.org/jira/browse/GROOVY-8431



Cheers,

mg










-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-PresidentDeveloper Advocate @ Google Cloud 
Platform

Blog: http://glaforge.appspot.com/Social: @glaforge / Google+

Re: toDebugString as a Groovy core concept

[Ahm Avoby]

Hi Guillaume,

thanks for that question.

I always felt GDK Object#dump() was meant to be used "as is", not to be
overridden (overriding not mentioned in the Object doc, although there is
of course nothing prohibiting one technically to do so). I also think that
the name (while concise) is easy to misinterpret, while not being easy to
discover through Intellisense.

The idea behind toDebugString is that it is easy to discover, overriding it
to generate a string that represents the object in an easy to grasp,
concise format is encouraged (the concept gets stronger, the more
human-implemented toDebugString you have), and that the default
implementation is only a stopgap fallback.

In addition, toDebugString is intended to become more powerful with the
variety that takes additional parameters, detailing e.g. indentation.

I feel if toDebugString is something Groovy devs routinely implement, it
could become a powerful debugging feature, in log output, but also in
debuggers, giving a better human readable representation than is currently
available.

Also in certain scenarios it could potentially make sense for GString to
call toDebugString instead of toString on embedded objects in its own
toString method.

Cheers,
mg


Guillaume Laforge  schrieb am Mi., 3. Jän. 2018, 22:42:

> Out of curiosity, you know about the dump() method on Object?
> How close / different is it from your proposal of toDebugString()?
> (dump() had that same purpose initially)
>
> Guillaume
>
>
> On Wed, Jan 3, 2018 at 6:39 PM, MG  wrote:
>
>> Hi all,
>>
>> I have created a jira for my proposed toDebugString Groovy feature:
>> https://issues.apache.org/jira/browse/GROOVY-8431
>>
>> Cheers,
>> mg
>>
>>
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: toDebugString as a Groovy core concept

[Guillaume Laforge]

Out of curiosity, you know about the dump() method on Object?
How close / different is it from your proposal of toDebugString()?
(dump() had that same purpose initially)

Guillaume


On Wed, Jan 3, 2018 at 6:39 PM, MG  wrote:

> Hi all,
>
> I have created a jira for my proposed toDebugString Groovy feature:
> https://issues.apache.org/jira/browse/GROOVY-8431
>
> Cheers,
> mg
>
>
>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

re: GPars 2 Stuff

[James NORTHROP]

Would second the motion to reduce redundancy where possible, as it reduces 
duplication of effort in testing, docs, etc. where, maybe, we can get GPars 
down to a core minimum of functionality, above and beyond what java provides; 
essentially as the (b)leading edge of concurrency.

 

We may reach a point where Java 1.9+ includes everything we could possibly 
provide in GPars 2.0+ thus making GPars redundant. Isn't that the best we could 
hope for ? To make the JVM realm the premier choice for parallel/concurrent 
solutions ? Just a thought.

Thx

Jim

 

 

 

 

> Message du 03/01/18 19:51
> De : "Russel Winder" 
> A : "GPars Users" 
> Copie à : "Groovy_Users" 
> Objet : GPars 2 Stuff
> 
> In GPars 1.X it was possible to do things such as:
> 
> [1, 2, 3, 4, 5].parallel.reduce{a, b -> Math.min(a, b)}
> 
> Without GPars it is possible using Groovy to achieve the exact same
> functionality on JDK8+ with:
> 
> [1, 2, 3, 4, 5].parallelStream().reduce{a, b -> Math.min(a, b)}.get()
> 
> The question is therefore whether to remove the GPars 1.X behaviour
> from GPars 2.X since the functionality is available using nigh on the
> same just using JDK8+ features, or to mock it up using the JDK8+
> features.
> 
> Personally I am all for removing the GPars 1.X stuff from GPars 2.X,
> Ockham's Razor etc., so this will be the default action unless people
> get vocal and contribute. 
> 
> -- 
> Russel.
> ==
> Dr Russel Winder t: +44 20 7585 2200
> 41 Buckmaster Road m: +44 7770 465 077
> London SW11 1EN, UK w: www.russel.org.uk
> 
>
> [ signature.asc (0.8 Ko) ]

Re: Start a forum - continued

[Nathan Harvey]

I personally use Nabble. It does not compare to a real forum system. The
formatting constantly breaks, you can't mention users, embed media, embed
code... the list goes on and on. 



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: Start a forum - continued

[Nathan Harvey]

Hi Jochen, I would like to once again stress the flow you can expect with
Discourse. You sign up one time, and check a box that you want to receive
emails. You will receive emails for every new post, and you can reply
straight from email. In this it is exactly like a mailing list and would
integrate with your workflow perfectly, while offering the option to use a
feature rich forum for those who want it. Conversations can take place
entirely within emails. Remember, this forum software was developed by
people who are used to mailing lists, and they take this behavior into
account.

Having the forum send something to the mailing list would just help promote
the forum, it is not meant for users to be able to interact with. I think
actually a weekly digest sent to the mailing list would be better.

You can read more about Discourse's policies on free hosting for open source
projects here:
https://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

GPars 2 Stuff

[Russel Winder]

In GPars 1.X it was possible to do things such as:

[1, 2, 3, 4, 5].parallel.reduce{a, b -> Math.min(a, b)}

Without GPars it is possible using Groovy to achieve the exact same
functionality on JDK8+ with:

[1, 2, 3, 4, 5].parallelStream().reduce{a, b -> Math.min(a, b)}.get()

The question is therefore whether to remove the GPars 1.X behaviour
from GPars 2.X since the functionality is available using nigh on the
same just using JDK8+ features, or to mock it up using the JDK8+
features.

Personally I am all for removing the GPars 1.X stuff from GPars 2.X,
Ockham's Razor etc., so this will be the default action unless people
get vocal and contribute. 

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: Start a forum - continued

[Guillaume Laforge]

By the way, let's not forget we already have a forum that works with our
mailing-lists: ie. the Nabble forum!
See at the bottom of the page the integration:
http://www.groovy-lang.org/mailing-lists.html

On Wed, Jan 3, 2018 at 2:35 PM, Jochen Theodorou  wrote:

> On 02.01.2018 04:45, Nathan Harvey wrote:
>
>> Once again I would like to bring up the idea of starting a forum using
>> Discourse. In particular, I would like to highlight some of the features
>> Discourse offers that are relevant to the mailing list, for those concerned
>> about making the switch:
>>
>> - Supports replying to conversations and PMs via email out of the box
>> - Can be configured to allow starting conversations and private messages
>> via email
>> - Support SSO via numerous providers, so no need to create a separate
>> account
>>
>> Discourse inherits all of the functionality of the mailing list (some
>> assembly required), and on top of that offers all the modern features you
>> would expect from a forum. It's free and it's open source. The Discourse
>> team will even offer free hosting and setup for open source projects like
>> Groovy. Many other projects like Kotlin utilize this system.
>>
>
> Being at apache with have the requirement to document all of the
> development relevant decisions and their discussions. The only accepted way
> for this I do know right now is the developers mailing list.
>
> I don´t think it would be a hard requirement to be able to actually post
> to groovy-dev, but since notifications are posts, there is not much point
> in making a difference here imho. But to be able to really work as an
> archive we require the message id logic working, to allow the apache
> archive to see the whole thread.
>
> And then there is the cost factor. You talk of free hosting and setup.
> Does such a setup enable the features we require? Finally there is the
> hosting problem. It is unclear to me if hosting the forum outside apache
> lands is ok. At least the domain must be under apache control.
>
> For me that is the minimum requirement that has to be met to work with
> apache.
>
> Then let us talk about groovy-user, because in case of groovy-user we do
> not really have these restriction. So I do see the possibility for
> groovy-user.
>
> My personal experience though is not speaking for a forum. If I have a
> waiting time of 5 minutes I can very well read through same mails and mark
> important ones I my want to reply later to, once I have more time.
> Filtering and sorting by my mail client really helps me here. Plus,even if
> I have no internet I can read my mails, write answers and then send them
> once I have internet again. The later one can be done only with a client of
> course. But even ignoring that and only looking at sorting and marking I do
> not know of any forum with that capability to the extend that I need.
> Obviously a forum requires a different approach.
>
> But frankly... If I take that old groovy forum, or SO or any other
> approach I have seen so far... I never became an active participant for
> long. Either it was so low volume, that I did not want to spend time there
> just to find nothing or it was so high volume, that I had trouble finding
> the posts of interest. The gradle forum is an example for this. And that
> forum is not bad... you just need to approach things different and with
> more time.
>
> On the other hand I am on more than a dozen mailing lists and it does not
> matter to me if they are low or high volume. Sure I am not reading all of
> the messages and to some I should probably unsubscribe as well, but it is
> not bothering me at all. Without a proper email client for this kind of
> stuff I can of course very well understand that they cannot handle mailing
> lists.
>
> As for the problem of having "too many channels to manage" it would be
>> feasible to set up the forums to alert mailing list users that a new topic
>> has been started.
>>
>
> Just for you to maybe understand the extend... I get a mail for every pull
> request, every comment on github, every jira entry for groovy. Which means
> my mail client is the entry point to jira, to github, to our normal mailing
> lists and many other things. Sure, if I want to reply to a github comment I
> do so by going to github, but still I am getting informed about them at a
> single point. And now have that for 3 more projects and you get a real
> feeling of what "one channel to manage" means for me. Even if you did bring
> all that to discourse I would still use my mail client widely for other
> projects and mailing lists.
>
> This would help bridge the gap between the two platforms.
>>
>
> just informing about a new topic is not enough, but already helps for low
> volume lists. The problem is you will not get informed about followup mails
> though. And if people need days for a reply, you may never read it.
>
> My conclusion is that even if we had a forum my first entry point would
> still have to be mail, or 

Re: Start a forum - continued

[Jochen Theodorou]

On 02.01.2018 04:45, Nathan Harvey wrote:
Once again I would like to bring up the idea of starting a forum using 
Discourse. In particular, I would like to highlight some of the features 
Discourse offers that are relevant to the mailing list, for those 
concerned about making the switch:


- Supports replying to conversations and PMs via email out of the box
- Can be configured to allow starting conversations and private messages 
via email
- Support SSO via numerous providers, so no need to create a separate 
account


Discourse inherits all of the functionality of the mailing list (some 
assembly required), and on top of that offers all the modern features 
you would expect from a forum. It's free and it's open source. The 
Discourse team will even offer free hosting and setup for open source 
projects like Groovy. Many other projects like Kotlin utilize this system.


Being at apache with have the requirement to document all of the 
development relevant decisions and their discussions. The only accepted 
way for this I do know right now is the developers mailing list.


I don´t think it would be a hard requirement to be able to actually post 
to groovy-dev, but since notifications are posts, there is not much 
point in making a difference here imho. But to be able to really work as 
an archive we require the message id logic working, to allow the apache 
archive to see the whole thread.


And then there is the cost factor. You talk of free hosting and setup. 
Does such a setup enable the features we require? Finally there is the 
hosting problem. It is unclear to me if hosting the forum outside apache 
lands is ok. At least the domain must be under apache control.


For me that is the minimum requirement that has to be met to work with 
apache.


Then let us talk about groovy-user, because in case of groovy-user we do 
not really have these restriction. So I do see the possibility for 
groovy-user.


My personal experience though is not speaking for a forum. If I have a 
waiting time of 5 minutes I can very well read through same mails and 
mark important ones I my want to reply later to, once I have more time. 
Filtering and sorting by my mail client really helps me here. Plus,even 
if I have no internet I can read my mails, write answers and then send 
them once I have internet again. The later one can be done only with a 
client of course. But even ignoring that and only looking at sorting and 
marking I do not know of any forum with that capability to the extend 
that I need. Obviously a forum requires a different approach.


But frankly... If I take that old groovy forum, or SO or any other 
approach I have seen so far... I never became an active participant for 
long. Either it was so low volume, that I did not want to spend time 
there just to find nothing or it was so high volume, that I had trouble 
finding the posts of interest. The gradle forum is an example for this. 
And that forum is not bad... you just need to approach things different 
and with more time.


On the other hand I am on more than a dozen mailing lists and it does 
not matter to me if they are low or high volume. Sure I am not reading 
all of the messages and to some I should probably unsubscribe as well, 
but it is not bothering me at all. Without a proper email client for 
this kind of stuff I can of course very well understand that they cannot 
handle mailing lists.


As for the problem of having "too many channels to manage" it would be 
feasible to set up the forums to alert mailing list users that a new 
topic has been started.


Just for you to maybe understand the extend... I get a mail for every 
pull request, every comment on github, every jira entry for groovy. 
Which means my mail client is the entry point to jira, to github, to our 
normal mailing lists and many other things. Sure, if I want to reply to 
a github comment I do so by going to github, but still I am getting 
informed about them at a single point. And now have that for 3 more 
projects and you get a real feeling of what "one channel to manage" 
means for me. Even if you did bring all that to discourse I would still 
use my mail client widely for other projects and mailing lists.


This would help bridge the gap between the two 
platforms.


just informing about a new topic is not enough, but already helps for 
low volume lists. The problem is you will not get informed about 
followup mails though. And if people need days for a reply, you may 
never read it.


My conclusion is that even if we had a forum my first entry point would 
still have to be mail, or I would automatically reduce my reading time 
in Groovy and thus reducing my answering time, because now answering 
time will have to be reading time as well. Not on purpose of course. 
Maybe it works for groovy-user better. But then it would still mean I 
would be less on groovy-user.


bye Jochen