Auto format in Processing 2.0 Beta 9

asimes

Auto format in Processing 2.0 Beta 9

in Integration and Hardware • 4 months ago

I just downloaded the new Processing and auto format has changed. It now takes a bunch of one line conditionals like this:

if (in[i] == 1) out += (i%4) + (i>>2);
else if (in[i] == 2) out += abs((i%4)-1) + (i>>2);
else if (in[i] == 3) out += abs((i%4)-2) + (i>>2);
else if (in[i] == 4) out += abs((i%4)-3) + (i>>2);
else if (in[i] == 5) out += (i%4) + abs((i>>2)-1);
else if (in[i] == 6) out += abs((i%4)-1) + abs((i>>2)-1);
else if (in[i] == 7) out += abs((i%4)-2) + abs((i>>2)-1);
else if (in[i] == 8) out += abs((i%4)-3) + abs((i>>2)-1);
else if (in[i] == 9) out += (i%4) + abs((i>>2)-2);
else if (in[i] == 10) out += abs((i%4)-1) + abs((i>>2)-2);
else if (in[i] == 11) out += abs((i%4)-2) + abs((i>>2)-2);
else if (in[i] == 12) out += abs((i%4)-3) + abs((i>>2)-2);
else if (in[i] == 13) out += (i%4) + abs((i>>2)-3);
else if (in[i] == 14) out += abs((i%4)-1) + abs((i>>2)-3);
else if (in[i] == 15) out += abs((i%4)-2) + abs((i>>2)-3);
else if (in[i] == 0) continue;

And turns it into this (all one line):

if (in[i] == 1) out += (i%4) + (i>>2); else if (in[i] == 2) out += abs((i%4)-1) + (i>>2); else if (in[i] == 3) out += abs((i%4)-2) + (i>>2); else if (in[i] == 4) out += abs((i%4)-3) + (i>>2); else if (in[i] == 5) out += (i%4) + abs((i>>2)-1); else if (in[i] == 6) out += abs((i%4)-1) + abs((i>>2)-1); else if (in[i] == 7) out += abs((i%4)-2) + abs((i>>2)-1); else if (in[i] == 8) out += abs((i%4)-3) + abs((i>>2)-1); else if (in[i] == 9) out += (i%4) + abs((i>>2)-2); else if (in[i] == 10) out += abs((i%4)-1) + abs((i>>2)-2); else if (in[i] == 11) out += abs((i%4)-2) + abs((i>>2)-2); else if (in[i] == 12) out += abs((i%4)-3) + abs((i>>2)-2); else if (in[i] == 13) out += (i%4) + abs((i>>2)-3); else if (in[i] == 14) out += abs((i%4)-1) + abs((i>>2)-3); else if (in[i] == 15) out += abs((i%4)-2) + abs((i>>2)-3); else if (in[i] == 0) continue;

This is really quite annoying, can it be set to the old way again somehow?

Replies(11)

GoToLoop

Re: Auto format in Processing 2.0 Beta 9

4 months ago

How about old v1.5.1 way?

asimes

Re: Auto format in Processing 2.0 Beta 9

4 months ago

That is an option, but I was kinda hoping that the new version would be able to do this. In my opinion, this is a bad change as it was a useful shorthand.

GoToLoop

Re: Auto format in Processing 2.0 Beta 9

4 months ago

I was kinda joking when I said that! It's just that I've always been using v1.5.1 yet.

I was seriously considering downloading next beta version to check that out.

Now that it's arrived, I've only seen bug reports from every1!

Even serious bugs in Linux! Since I'm using 1 now, beta 9 isn't an option at all!

Maybe next time?

Processing's IDE is too simplistic already. And now w/ bugged auto-format, it's just useless!

I'm really disgruntled about Processing 2+ frenetically axing out

so many features which is present in current stable.

At least, it should allow some old useful behavior & features through preferences.txt.

But current policy is towards aggressive standardization/canonization!

I've really had hoped that Processing would pursue to convert

yet more Java extras into JavaScript mode in the future.

But now I realize it's not gonna happen ever!

caseyreas

Re: Auto format in Processing 2.0 Beta 9

4 months ago

asimes, if you want this to be addressed, make an Issue request on GitHub: https://github.com/processing/processing

GoToLoop, of course there are bugs in the 2.0 releases -- that's the point of alpha and beta software. 1.5.1 is still the "stable" release while bugs are being worked out. I recommending trying the new software.

GoToLoop

Re: Auto format in Processing 2.0 Beta 9

4 months ago

GoToLoop, of course there are bugs in the 2.0 releases

that's the point of alpha and beta software.

Well, I'm aware what an alpha/beta stage is. Although I've seen alpha releases from other programs

better than many stable ones!

However, my point is more about current policy, which is more focused on increasing standardization

in detriment of flexibility, compared to what we already have in v1.5.1!

asimes

Re: Auto format in Processing 2.0 Beta 9

4 months ago

Casey, thank you, I posted it there.

Edit: GoToLoop, I lose track of the differences between versions. Most of the time they do not affect me although the change in alpha for pixels[] sure surprised me whatever version that was.

GoToLoop

Re: Auto format in Processing 2.0 Beta 9

4 months ago

REAS -> This was introduced when code was modified to format if structures according to the Processing style. The formatting is better in 2b9 for multiline blocks. I'm not sure if this case was tested and I'm not sure if the auto format engine can distinguish the different cases. Auto format is intended as a convenience for most users; it will never work 100% for all styles of coding. Adding braces to the above code works better with auto format, but it doesn't maintain the single-line structure.

I was just perusing some issues on Processing's section of GitHub.com,

and found out that reply from your bug report!

That response above reflects my critic on current policy of aggressive standardization quest

of a supposed "Processing's Style"!

I use single-line structures a lot! And at the same time, I press <CTRL+T> all the time!

And I post many corrected codes here. And I can't see myself using an IDE rendering such gibberish!!!

Any C-derived language uses that style too, including even JavaScript!

So, why Processing is pushing to distance itself from both Java & JavaScript style now?

P.S.: although the change in alpha for pixels[] sure surprised me

Change in alpha? Don't tell me that pixels[] doesn't store alpha attributes anymore?!

I hope not! Many fixes I've made depends on that it stores whole ARGB color spectrum!

caseyreas

Re: Re: Auto format in Processing 2.0 Beta 9

4 months ago

GoToLoop, this is entirely false. There was a bug in auto format, so we tried to fix it (we accepted a pull request from someone that took the time and energy to help out). It introduced a new bug. End of story. We'll look at the new bug and we'll figure out what to do.

"Processing style" simply means the way the code is formatted in the examples that come with the software. We're certainly not imposing a coding style.

asimes

Re: Re: Auto format in Processing 2.0 Beta 9

4 months ago

GoToLoop, Actually, the other way around. I never specified alpha when using pixels[] in the older versions and then it became a requirement. Originally I was surprised when all my old OpenCV sketches were not working, but the solution was just to or 0xff000000. All in all, the change was an improvement that time, just confusing at first.

amnon.owed

Re: Auto format in Processing 2.0 Beta 9

4 months ago

GoToLoop. To me it seems you are seriously overreacting (what's with all the exclamation marks?) to a single bug, which I think is unfair to the Processing dev team who have put in a tremendous amount of work to further develop Processing through so many alphas and betas. Just take a look at this list. Hundreds of issues have already been solved, I think they can manage another one. The most important thing is that if there are remaining issues, the way to get them fixed is to file a bug report on GitHub.

PhiLho

Re: Auto format in Processing 2.0 Beta 9

4 months ago

Indeed, GoToLoop doesn't seem to understand what open source is about...

This is clearly a bug, and accepted as such, and it is OK in a beta version. It is annoying, but we still have the old versions, and 1.5.1 is still available for download.
You looked at the bug listing, and you can see there are still lot of bugs opened. There are probably a ton of bugs closed as well. The authors work hard to fix most of these bugs before releasing the final 2.0 version. I can understand they have no time / energy / resources to do thorough tests before releasing a new version, so some bugs can escape.
That's why testing the bleeding edge version and using it is important: it allows many users, using many styles of coding and many features on several platforms, to do a more thorough test.

GoToLoop chose to stick to 1.5.1, which is fine. He doesn't like some changes, and so I am, but that's the case for all softwares: some evolutions are good, others break habits and so make angry, even when they go in the right direction (but can cause confusion, as they also break compatibility).

Top Reply