quil.core.fill & stroke cast single integer arguments to float breaking tests

[nfletton]

I'm running a local build of Quil based on master which uses Processing 4 beta 8. Commit 1f214e7, which is not yet in a released version of Quil, casts the argument of the single argument definition of fill and stroke to a float. Although this commit does make those functions conform to their documentation, it does break the common usage of those functions including in the Quil example snippets and hence tests fail.
As an example, the usage pattern below is now broken by the commit as the integer returned by (color) gets cast to a float before being passed to the underlying Processing method which interprets a single argument of type float as a gray scale.

(let [blue (q/color 156 255 70)]  
  (q/fill blue)  
  ...
  )

I suggest the single argument definition of fill and stroke should not cast to a float if the argument is of type integer.

[dgtized]

I've started looking at this, but unfortunately it's a little more complicated than expected. Specifically because in Processing/clj q/color returns an unchecked int representing the current color, but in p5js/cljs q/color returns a color object. For p5js it also accepts a string, either as a hex or hsl/rgb css string (see fill, and color).

It's also not clear if q/color should always return a color mode translated RGB values, such that using an integer as an argument to fill, stroke, background should always assume RGB regardless of the color mode translation? If we don't translate it in fill, but only in color then it won't double translate it, if the argument is from q/color. However, that also means there is an escape hatch to force RGB color even if the mode is set to HSB/HSL or some other range of RGB.

Finally, if we call (q/background 128) or (q/stroke 255) in RGB, or HSL with integer range, should that be interpreted as grey scale or whatever int packed color that represents?

I'll try and make a table to summarize all the input modes to expected values, as I think that might help determine the best approach. I think your intuition on checking for int is correct, I just think we have a few more cases to cover for it to handle all the expected inputs in a sane way.