8000 println messes up strings with a<b for many a and many b · Issue #284 · processing-js/processing-js · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Dec 5, 2018. It is now read-only.

println messes up strings with a<b for many a and many b #284

Open
lgto4 opened this issue May 5, 2017 · 9 comments
Open

println messes up strings with a<b for many a and many b #284

lgto4 opened this issue May 5, 2017 · 9 comments

Comments

@lgto4
Copy link
Contributor
lgto4 commented May 5, 2017

In Processing.js versions 1.4.7, 1.4.8, and 1.6.6 (but not version 1.4.1) println of a string with a < without white space around it may fail.

See https://jsfiddle.net/blyon/on7a5f9s/ for a simple demo which contains this code :
var a=function(){ return a<a; }; println(a);

A simpler example is println("Strings with a<b don't work.");

@Pomax
Copy link
Member
Pomax commented May 5, 2017

those are very old versions; the current version is 1.6.6, does it still happen in that?

@lgto4
Copy link
Contributor Author
lgto4 commented May 6, 2017

I do not know about 1.6.6. When I go to https://github.com/processing-js/processing-js the README.md file says "Simply grab the processing.js or processing.min.js files, include them as script on your webpage, and you're all set." Neither of those files contain valid Javascript when viewed by either of my browsers, Chrome or Firefox. For example, processing.js ends mid block-comment at line 14192.

@GoToLoop
Copy link
Contributor
GoToLoop commented May 6, 2017

@lgto4
Copy link
Contributor Author
lgto4 commented May 7, 2017

Yes, the problem persists in 1.6.6.

@Pomax
Copy link
Member
Pomax commented May 10, 2017

@GoToLoop for future reference, https://www.npmjs.com/package/processing-js is a better link to provide (since it always points specifically to the latest version)

@Pomax
Copy link
Member
Pomax commented May 10, 2017

@lgto4 it looks like it's your spacing. With "proper" spacing (always up for debate of course but most linters insist on this style) the code runs fine: http://jsbin.com/juwivosaga/edit?html,js,output

Also note that with(...) { ... } is considered extremely bad (for many reasons that people like Crockford et al. can explain much better than I can) and is in fact flagged as an error when you use strict mode (which is typically a good idea). The function that you pass into the new Processing(canvas, handler) already gets the instance as its call argument, so there is no real need to use with, just give the instance a short name like p and then namespace the calls to that (see jsbin)

< 8000 /form>
@lgto4
Copy link
Contributor Author
lgto4 commented May 10, 2017

Got it. All we have to do to work around the bug is to convince all coders (including the robotic ones) to conform to our notions of good hygiene. So in the Pomax example if I replace processing.js with processing.min.js and try p.println(p.constrain); we can see how daunting the work around can be.

Similarly, p.println("Warning: don't do this: a<b cause Mike says so."); still fails.

Updating the bug report...

@lgto4 lgto4 changed the title println messes up functions with less than operators println messes up strings with a<b for many a and many b May 10, 2017
@GoToLoop
Copy link
Contributor
GoToLoop commented May 10, 2017

... https://NpmJs.com/package/processing-js is a better link to provide ...

That link is extremely cluttered for someone to pinpoint what's the latest version there.
Even worse, there's apparently no link to directly download it but only instructions to get it via Node.js' NPM

There's absolutely no fair comparison to the logical & cleanliness organization at https://GitHub.com/processing-js/processing-js/releases

... since it always points specifically to the latest version.

Given everything ends up merged here in GitHub, I bet in no short time this repo gets a tagged version ready to download here.

@Pomax
Copy link
Member
Pomax commented May 12, 2017

The recommended installation is through npm, which is the de-facto installer for both serverside and clientside libraries these days. NPM always points to the latest version, you don't "pick one", you run npm install processing-js and it installs whatever is the latest version. If you have an older version, then npm will update it as a semver-safe update.

The version on npm is always based on the git tag pointed to by package.json when the update is pushed to npm, which is done every time a new version is rolled out because npm is used for this project to manage dependencies, do the build, do version tagging, and push releases. The fact that github itself has a releases bin is not something this project makes intentional use of.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0