Puts not working - Anyone else?

Dave Wayne from Podium has emailed me stating that they are in the midst of recompiling all their C++ code and will ask the original programmer to look into the nudge problem once they have taken care of their recompile.

BTW - my first email to them was on 6/29/2018

2 Likes

@gkernan

Their delay shows a wilful lack of care [IMHO].
The error seems to arise from a compiled RB script, nothing to do with C++…
It’d only be a few hours work to fix that avoidable Ruby coding error, and then to reissue a new installer with the corrected nudge.RBS file…
:face_with_raised_eyebrow:

1 Like

This has bogged a lot of (mac)users. Though mac users usually keep SU ‘alive’ and just start a new tab instead of file->quit, they would always had to force quit SH when turning of the computer…

I even provided them with a backtrace. If you look at what Hank provided - it’s the exact same line in nudge.rbs

c:/programdata/sketchup/sketchup 2018/sketchup/plugins/podiumextras/nudge.rbs:796:in `puts’

The problem with monkey-patching is that you need to preserve the exact same method signature.

If the original method accepts multiple arguments you must expect someone is using that. But the opposite is also true, if the method accepts 2 arguments and you add a seemingly future-proof catch-all (*args) you will break code that is checking method arity to distinguish different Ruby or SketchUp API versions of that method.

If you target different SketchUp/Ruby versions where the original method signature changed, you need to provide an override for each version of the method signature.

That’s why poorly done overriding is dangerous and bad. I am sure what they were trying to do can be better achieved by not overriding puts but in other places with less impact. And impact of an extension should be kept as minimal as possible so that it is only active while in use (add observers when tool is activated, then remove observers; same for overriding and intercepting console).

2 Likes

I’d go further than @Aerilius and assert that in a shared interpreter setting such as SketchUp, monkey-patching a base class or module is never necessary or acceptable. It is the embedded interpreter equivalent of creating your own version of, for example, the C-runtime library and dropping it in place the system’s library. The match has to be perfectly transparent or you will eventually break someone else’s code. And, even if it is just for you own use, it is lazy programming. For example, if you need some variant behavior of puts for your own code, you can call it my_puts and call that instead of the system puts. You don’t know when or why other people’s code might call puts, so you know what side effects your substitute will have only on your own code.

5 Likes

There are extremely rare cases when monkey patching can be used in SketchUp. Aeriliu’s LaunchUp uses it to interpret menu entries and commands being added by other extensions, to make them searchable, and I’m using a similar approach in my tool memory to get references to custom Ruby tools. However it needs to be stated that these are quite extreme cases, when the API doesn’t allow any other way.

Generally speaking this is a huge no-no.

Edit: For the record, here is the feature request I’ve filed on the topic: Get the active Ruby tool · Issue #10 · SketchUp/api-issue-tracker · GitHub

1 Like

If you want only your own code to call a variant of another method (like puts), you can implement my_puts (and make it optionally forward to any core method).

But there is a use case:

If your code wants to observe when another method is called, you need an observer mechanism which Ruby does not provide (except of super-expensive set_trace_func).
There is for example also the paradigm of Aspect-Oriented Programming which is about extending behavior by attaching customized methods before or after another method (for example by a decorator pattern). It is not natively supported by Ruby, but available as a gem, which is probably realized by some sort of monkey-patching.

  • The original 2012 SketchUp Developer tools overrode Kernel.puts to catch when it is called.
  • Last time I checked, TestUp registered its own subclass of Sketchup::Console in $stdout to make it compatible for Minitest.
  • My Ruby Console registers a forwardable proxy around Sketchup::Console in $stdout only while this extension is actively used. This is to some extent safer than overriding methods because $stdout is assignable and the effect can be reversed by reassigning the original object. A forwardable allows to exactly take over other methods of the base class even if Ruby adds methods in the future. And in a similar kind, Sketchup::Console is a not 100% compatible drop-in replacement for Ruby’s #<IO:<STDOUT>>.
2 Likes

We found it out: What a Podium programmer was trying to do is to control verbosity (for their extension). But instead of setting $VERBOSE = true through the console only during debugging, they were muting puts globally for everyone else.

5 Likes

That’s disconcerting. :frowning:
These things are checked when extensions are uploaded to EW. But for anything not hosted there we have no control.

We will be messaging our new static analysis tool more though: GitHub - SketchUp/rubocop-sketchup: Rubocop cops for SketchUp - test against our Extension Warehouse technical requirements and other pitfalls
Encouraging extension developers to make use of this as they work on their extensions. Catches a large number of common violations and even provide some general advice.

1 Like

Probably lots of clients using the GUI without problems. I’m not sure if the people who responded to you understood the problem.

1 Like

In my experience, a lot of Mac users in General do not exit programs (File->Quit) and put the Mac in sleep mode.
This preventing to notify the ‘not responding’ at all.

Any news on this? Have they acknowledged yet that this is a real problem?

If a coder can redefine puts and there are no routines to find and correct it, I can’t help to worry of about the rest of the code base. Do they use global variables, several root namespaces, attribute names that aren’t prefixed with the extension or author name, redefining more methods, changing base/core classes etc? Of course no user would experience and report an issue in such case, unless another extension contained the same fault, and happened to use the exact same name.

And of course a lot of clients don’t find the puts issue either. You have to be among those that write ruby code yourself to notice there is a problem to begin with, and have a certain level of Ruby experience to know about everything can be redefined at runtime, and how to find where. We are talking of a handful percents of users.

Coding like this is like building a weaker frame than the construction norm demands or leading blackwater sewage to the graywater sewage system. Will the people living in the house notice? Not likely. Is it wrong? Certainly. Does the fact that people don’t notice make it any better? Absolutely not.

3 Likes

I have not heard anything more from Podium
about this issue. They said their programmer would look into it after the got their plugins working with SU 2019.

I know this much - my plugins all worked just fine with SU 2019 without having to change a single line of code.

I am at a loss to understand why any experienced programmer would go through the trouble of redefining basic ruby methods.

Sadly, you must press Podium, and if necessary c/c this thread to show everyone’s disquiet.
If is not a complex thing to resolve - they should do it forthwith !

2 Likes

You are assuming this programmer is experienced. I wouldn’t make that assumption.

I did not make an assumption. The statement was in jest, a double entendre even sardonic.

1 Like

David from Podium has finally emailed me saying he believes that he has a fix. I will ask him to respond to this thread

2 Likes

Is that fix a “#” or a Del of 3 lines?

2 Likes

I have no idea yet what they will provide as a fix