SketchUp 2014 correct syntax using upto?

tomot

Which of the 3 following upto statements is supposed to be API and SU 2014 compliant?
I'm specially referring to the correct location of do.

0.upto(@co34nx-1) do|i| API flags no Syntax error!

0.upto(@co34nx-1)do |i| API flags no Syntax error!

0.upto(@co34nx-1) do |i| API flags a Syntax error!

Jim

The 3rd is best, but all are functional. Your error is in the code you are not showing.

tomot

@jim said:

The 3rd is best, but all are functional. Your error is in the code you are not showing.

OUCH!..... after spending all this time to find API SU 2014 errors I don't want to, revisit finding the non API version again just to find the rest of the error statement.

But I will submit an API SU 2014 error list, for one of my Rubies:
90% of which are not actual errors as noted by line numbers as noted my ^
I know the char (UTF-8) reference is the only one that appears to be valid.

SU API Error.txt

TIG

That error shows the file is NOT 'encoded' as the now mandatory UTF8-without-BOM format.
Most authors have been using that format for years... BUT...
If you use[d] Notepad.exe it makes a file it will be encoded as ANSI, which is not compatible now with Ruby2.0 - although earlier Ruby versions tolerated it when really they too desired the proper encoding !
If you have/get the 'free' Notepad++.exe then, as well as having lots of helpful syntax highlighting for different file types like RB and so on, you can then save a file encoded as UTF8-without-BOM, and set the editor's preferences to make all new files in that encoding too...

When you change an existing file's encoding in Notepad++ remember to read through the file, just in case you have any non-ASCII Unicode characters in it - like say a - if so it needs reentering as the UTF8 equivalent [simple type-in/Character-Map] - which then avoids further issues... These rogue characters [if any] will show up as white-on-black text blocks, rather than the expected character itself...

tomot

Before SU 2014! One would never see loading errors in Ruby scripts.
My attached error text file, is simply a Copy and Paste into Notepad for illustration purposes of errors produced by SU 2014 while trying to load scripts.

Are you saying If I Cut and Paste the errors into Notepad ++ I would get a better idea of what are errors and what are not errors?

TIG

NO.

What I am saying is that trying to run an old script that is incompatible with Ruby2.0 will produce those kinds of errors.
Although Ruby has always preferred UTF8-without-BOM encoded files [just stuff to do with the newline characters and how characters are encoded/read/displayed] if you gave the previous Ruby version an ANSI file it would begrudgingly digest it - BUT the latest Ruby version insists on the correct encoding.

So what I was suggesting was that you use Notepad++ to change your current Plugins' encoding to UTF8-without-BOM and see if they then work in v2014.
Many Plugins are already encoded acceptably and work under both Ruby versions.
Some need their encoding fixing and will then work fine too.
A few that get their encoding changed have issues with 'special characters like which might have been typed as Unicode in ANSI and these need changing to the UTF8 equivalent - you just need to type/copy-paste the replacement character in and it is auto-encoded suitably.
A few other scripts that might be encoded properly can display errors in syntax...
There are a few changes to the way Ruby does some things - like turn an array into a string - rare though...
Also the new Ruby is less 'forgiving' - so previously when you included a space between an argument and the opening '(' enclosing its arguments Ruby, would put up a warning in the Console but let it pass, now it just won't work !
The error messages the newer Ruby gives are longer and more detailed - which help track down the issues more easily... They give the file and line number where the error occurs, so you should be able to resolve the problem easily...
Once your RB files are properly encoded and you have corrected any obvious issues, please come back with specific errors if you need more advice...

You should always freshly install the latest versions of 3rd-party Plugins into v2014 - many have already been updated to be cross-version compatible. Do NOT copy Plugins between versions wherever possible.

tomot

Tig , thanks again for your detailed explanation, As I stated above I'm aware of how to fix the UTF8 issue. I would like go back to my original question, which Jim responded to, regarding upto. (see attached pic)

I agree its vast improvement of the old method. It was a bit tedious to constantly start SU, open ruby console, start ruby script, take note of errors, quit SU.

TIG

The image you attached seems to show a space between the method and the opening ( which is enclosing its arguments.

It should NEVER be like this:
entities.add_line (pt1, pt2)
Which WILL surely break Ruby2.0...
The ( should always be immediately after the method like this:
entities.add_line(pt1, pt2)

The older syntax without any () - like this:
entities.add_line pt1, pt2
WOULD still work... BUT properly parenthesized arguments are recommended, as the old 'loose' method may be deprecated in future updates...

This space in front of the ( was one of the potential pitfalls I outlined earlier.

Changing a script-file's encoding is not necessarily the only fix you need to think about - especially if your code contains old 'latent' errors, which previous versions tolerated and only warned against, but the new version cannot abide and so it crashes out !

tomot

This extra space issue is a HUGE problem! I picked up that habit from looking at code posted by other members over the years
Are you saying 0.upto(@co34nx-1)do|i| would be Ruby 2.0 compliant?

Interestingly I have documented that SU 2014 is also derelict and inconsistent in picking up "spaces" in Rubies.

The example below passed without Ruby 2.0 detection

%(#BF0000)[if ($sl404 < 2)
UI.messagebox( "Less than 2 risers is not allowed")
return nil
end

    if ($sl404 >$sl303-2)
       UI.messagebox( "Less than 2 risers after Landing is not allowed")
    return nil
    end]

I see Ruby 2.0 does not even like spaces in # comments (see attachment)

TIG

Spaces AFTER a ) are usually OK...
But there should be NO spaces between a method and its argument's (
BUT a 'test' like 'if' can be like :
if aaa == bbb
The if expects a space after the [pp=]if[/pp] !
Spaces to either side of comparators or assigners, like ==, >, <, = etc are "optional", used for clarity only...
0.upto(@co34nx-1)do|i|
will probbaly work, but the nrmal form is:
0.upto(@co34nx-1) do |i|
BUT
0.upto (@co34nx-1) do |i|
WILL fail because in Ruby2.0 the method [ upto] needs the opening ( which is enclosing its argument immediately after it !

tomot

If I make the statement at my blog "My scripts are SU 2014 compliant" is that really true?
It appears, as illustrated in (my attachment), that Ruby 2.0 is inconsistent in flagging spaces in scripts. That being said, how can I trust scripts which appear to be Ruby 2.0 compliant, on my computer, are compliant on my customers computer?

I'm still of the opinion that, Ruby was a poor choice to begin with, as an API scripting language for SketchUp. Now 10 years later they tightening up on defining Ruby scripting errors, using Ruby 2.0. I can think of no other scripting language, Lisp, GDL, Python, Mel, that would want to introduce this kind of havoc with its customer base. The Main reason Software become bloatware is because of bad past decisions. Cardinal rule, never drop support for past failures, or you will alienate your customers. Even major SketchUp add on Makers, don't look very capable when it comes to writing Ruby Code capable of passing the Ruby 2.0. I feel sorry for Vray this might set them back another 4 years. LOL!

I don't think Python developers would ever dream of going down this road of misadventure, considering the large amount of major 3d Programs which use Python as a Scripting Language.

In addition, is it even possible to find a Script Editor that will pick up all Ruby " spaces " and delete them in a Script.

TIG

@Tomot

You are over thinking this.
You will need some spaces in any language's code, so that the 'parts' can be differentiated by the interpreter.
The only errant spaces you have flagged up so far are the ones I had previously warned against, and had been advised against in the earlier versions of Ruby too - because although they were 'tolerated' they could be deprecated and become unacceptable... and now they have been!

To reiterate...
A ' method' can sometimes take an argument or arguments [ .upto(666), .add_line(pt1, pt2), etc] - these arguments are always best passed inside parenthesizes ()... The opening ( should come immediately after the last character of the method, with no space between them.
So all you need to do is search for ' (' and then decide it you make it into a simple ' (' when it occurs immediately after a method.

Some spaces in code are 'optional' and using them simply helps 'readability' when editing - just like consistent indenting of code-blocks will - but again that was ever so:
e.g.
xx=12.3
v.
xx = 12.3

From what I've seen of your screen-grab images, you have sometimes included other () in parts of your code - sometimes they are not necessary at all.
if xxx && yyy
is fine.
if (xxx && yyy)
is too, but the () are NOT needed at all, unless you are nesting tests like this:
if xxx && (yyy || zzz)
when you need them...

All v2014 Ruby2.0 has done is to stop accepting some syntax that was already advised against in earlier versions too.
It has not 'moved the goalposts' - rather it has 'set them in firmer foundations'...
The advantages of v2.0 far outweigh the inconvenience of tidying up old poorly drafted code.
The few other minor changes in its methods, like 'array_to_string', actually bring it to be more aligned with other similar languages like Perl... These changes are unlikely to affect the vast majority of scripts anyway, and if they do they do then it is easily spotted and resolved anyway...

Be assured that if you scripts are updated and they work properly for you in v2014, then they should work for anyone else using the same version [and OS and Pro/Make***].
***If in the unlikely event that one of your scripts contain some OS specific or Pro [v.Make] methods/code then of course, without testing your script on the alternative OS/Pro compatibility cannot be ensured - but that was ever thus...