Check euslisp format for jsk_apc2016_common

[knorth55]

• mv euslint to jsk_apc2016_common
• check euslisp format in jsk_apc2016_common/samples
• fix file format in jsk_apc2016_common/samples

[wkentaro]

It seems that it is good timing to move euslint to jsk_tools, roseus, or euslisp.
Or pure python package hosted on pypi. What is your idea?

[knorth55]

I already make a PR to euslisp. euslisp/EusLisp#209
The easiest way is pypi or jsk_tools.

[wkentaro]

You may need to try harder at the PR, it seems ignored.
For me jsk_tools seems easiest way, and enough for us (lab-members).
Please consider of using a little time for this.

[k-okada]

I think other euslisp users do not even think of using lint tool for their scripts, so keep it within Apc package and carefully listening what other people talking about. if someone have trouble on not using lint tools, the promote lint tools. But please be careful not to waist others time for lint discussion. We should make more priority for research outcome, generalized software design ....

[knorth55]

I make this lint program for APC program, so keeping this program in this repo doesn't matter for me.
But I can merge this program in jsk_tools, and everyone in Lab members can easily use it.

[wkentaro]

I think other euslisp users do not even think of using lint tool for their scripts, so keep it within Apc package and carefully listening what other people talking about. if someone have trouble on not using lint tools, the promote lint tools. But please be careful not to waist others time for lint discussion. We should make more priority for research outcome, generalized software design ....

@k-okada
I'm commenting because you may think linters are not so useful for research and development.
I think "Linter is useful if we use it correctly".

In my thought, there are 2 kinds of roles for linter: syntax check and style one.
Former is exactly same role as the catkin-build in travis, and this is useful for almost all projects because the program does not work without changes. (ex. () check in euslint)
Latter is a similar thing as the documentation and directory construction, and this is useful for mature projects because it helps keep software design and code readable. (ex. tab check in euslint)

[k-okada]

I understand lint is useful, Like all tools are useful if one can use them correctly, So using euslint within APC is fine. I know every in this team is so motivated and skills. Of course putting the into jsk_tools or releasing within pypi is good thing, but I think preparing for good presentation for his first conference or write 6-pages journal paper for bachelor thesis are more important than promoting euslint at this moment. In addition to that "why not use tools? that is useful", seems Naive to me. We have to think, Can people handle these tools correctly? Do they enough time to learn how to use tools? how long can we maintain that? And so on. For example, I like CMake macro, bloom release and others, but I do not ask everyone to use them. I always try to hide such useful tools behind easy frontend such as catkin or apt-get command, because I'm afraid introducing such tools will confusing many people and take long time/effort/conversations. Of cause, some time I forget these issues and I asked others to use them, and mostly I failed. Here is my (failed) attempt to ask others to use tools which I like and think so useful. - Use cmake macro instead of changing source code every time we had change in upstream start-jsk/rtmros_common#999 - rosinstall is basic tools for apc people, but I need long time conversation to convince other lab member to use them. It takes more than a year and I had to explain many times jsk-ros-pkg/trans_system#660 jsk-ros-pkg/trans_system#656 jsk-ros-pkg/jsk-ros-pkg-unreleased#92 (comment) start-jsk/rtmros_tutorials#504 2017年5月9日(火) 0:33 Kentaro Wada <[email protected]>:

I think other euslisp users do not even think of using lint tool for their scripts, so keep it within Apc package and carefully listening what other people talking about. if someone have trouble on not using lint tools, the promote lint tools. But please be careful not to waist others time for lint discussion. We should make more priority for research outcome, generalized software design .... @k-okada <https://github.com/k-okada> I'm commenting because you may thing linter is not so useful for research and development. What I'd like to say is "Linter is useful if we use it correctly". In my thought, there are 2 kinds of roles for linter: *syntax* check and *style* one. Former is exactly same role as the catkin-build in travis, and this is *useful in almost all projects* because the program does not work without changes. (ex. () check in euslint) Latter is a similar thing as the documentation and software design, and this is *useful for mature projects* because it helps keeping software design and code readable. (ex. tab check in euslint) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2077 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeG3IYpJgz72kaZw_ueXYupssNVZ39Uks5r3zW3gaJpZM4NUAD_> .

-- -- ◉ Kei Okada

[wkentaro]

@k-okada I see. I think you're right. I thought just putting euslint into jsk_tools won't cause any effect to standard euslisp users, because they're not so neophilia as me.