Problem with GEM_HOME and special character in path

I have a problem with Gem packages. My packages installed by Gem.install are not visible from my extensions:

For example:
Error: #<LoadError: cannot load such file -- rubyXL>

I am pretty sure that reason for that is that I have special character in GEM_HOME path and that character is evaluated in sketchup incorrect.

I cannot paste how path looks like from Ruby console in sketchup because special character is not printable in that editor. But instead of polish character ‘ó’ in ruby console there is non-printable character (represented by square).

I believe this is the reason why I cannot see Gem packages in sketchup. I checked it on different accounts where there are no special characters in GEM_HOME path and everything works just fine.

Is there way to change GEM_HOME in flight? I tried to set ENV[‘GEM_HOME’] from extension script (and ensure that under that path there are installed gem packages) but that doesn’t work.

Any ideas?

Have you read the page on the Ruby Encoding class ?

… and therefore encoded your codefiles as UTF-8, and inserted a “magic comment” as the first line of all your code files ? ie …

# encoding: UTF-8

What do you get on the machine with the Unicode character in the path, when you do this from a script (not the console as it’s bugged,) …

puts "ENV['GEM_HOME'] is #{ENV['GEM_HOME'].inpsect}"
puts "ENV['GEM_HOME'] encoding is: #{gemhome.encoding}"

There is a regression encoding bug in the SketchUp 2018 Ruby console …

But you can paste them here in the forums.

Here is my output:

ENV['GEM_HOME'] is "C:/Users/MariuszG\xF3rski/AppData/Roaming/SketchUp/SketchUp 2018/SketchUp/Gems64" ENV['GEM_HOME'] encoding is: Windows-1250

However still I don’t understand how I can use that to require gem installed library. I found out that I’ve got additional message in console

Unable to find AppData directory.

and I believe this is related to that path problem. However this is not problem of encoding of my source files but default GEM_HOME path. Is there way to load Gem bundles from another directory?

Then you also have the same issue with …

ENV["APPDATA"]

When I do this in SU2016’s console …

puts "\xF3"
#=> ó

… I get the correct Unicode character.

So,… the path to your plugin’s directory is also likely “broken”
It is probably the last path in the $: (aka $LOAD_PATH) array.

@jelcynek

As you probably know, encoding has always been an issue with Windows. Also, being American, I don’t run into encoding issues that often. Have you tried setting an ENV variable before you start SketchUp?

What does Encoding.default_internal return?

You might try

set RUBYOPT=-Ewindows-1250:windows-1250 & "<SU exe folder>\SketchUp.exe"

Greg

SketchUp does not set this despite my bitchin’ about it since 2013 !

(I usually set it myself to "UTF-8" so that String#encode() will work without parameters.)

Then you also have the same issue with …

ENV["APPDATA"]

Yes, exactly.
ENV['APPDATA'] is "C:\\Users\\MariuszG\xF3rski\\AppData\\Roaming"
ENV['APPDATA'] encoding is: Windows-1250

So,… the path to your plugin’s directory is also likely "broken"
It is probably the last path in the $: (aka $LOAD_PATH) array.

Yes.
... , "C:/Users/MariuszG\xF3rski"]

When I do this in SU2016’s console … […]

For me that doesn’t work. I use SU2018.
puts "\xF3" ( there is no output, so probably non-printable character)

Have you tried setting an ENV variable before you start SketchUp?
Yes. Tried to change GEM_HOME and APPDATA (in case if GEM_HOME is prepared using APP_DATA. APP_DATA could be changed but it doesn’t have effect, however GEM_HOME stays as it was before. Isn’t GEM_HOME set internally in sketchup?

Also I tried to change that paths from extension code. Path are changed, however it still doesn’t work.

You might try
set RUBYOPT=-Ewindows-1250:windows-1250 & "<SU exe folder>\SketchUp.exe"

Unfortunately, that doesn’t help. However it have impact on $LOAD_PATH array. After applying that last directory is displayed properly.

I know, the point is (as I said above) the SU2018 Console is broken.

No. It is just that it is a unicode character, and somehow they’ve broken Unicode support for the console (again, as it’s happened once or twice in the past since SU2014 was released with Ruby 2.x. which came with Unicode character support.)

Interesting. Some progress. I checked in rubygems/rubygems, and the version included with SU was not tested against windows. I hate to ask, would you consider updating rubygems to the current version? Without a command prompt it’s a little tricky. Let me know if it’s a problem…

Also, if you run the following (equivalent to gem env), does the output look correct?

require 'rubygems/commands/environment_command'
Gem::Commands::EnvironmentCommand.new.show_environment.gsub("\n", "\r\n")

Greg

Yes, but you can try to “fix” it before loading your gem …

ENV["GEM_HOME"]= ENV["GEM_HOME"].encode("UTF-8")
ENV["GEM_PATH"]= ENV["GEM_PATH"].encode("UTF-8")

or …

ENV["GEM_HOME"]= ENV["GEM_HOME"].dup.force_encoding("UTF-8")
ENV["GEM_PATH"]= ENV["GEM_PATH"].dup.force_encoding("UTF-8")

Because the v2018 Console is broken, you cannot use it for testing,
… perhaps try using a multiline messagebox …

UI.messagebox(ENV["GEM_HOME"],MB_MULTILINE)

?

Greg, these things are not a solution, as (1) he’s rather a newb at Ruby, (2) he’s writing an extension (3) he cannot ask people using his extension to change SketchUp’s libraries nor set the RUBYOPT environment variable for SketchUp. (4) Perhaps people running his extension may have a differing external (system) encoding other than Windows-1250.


Now this all may show (once again) that Trimble has published another version that has broken Unicode path support. (You’d think think they’d get it correct by now as they’ve had 5 years of recurring “issues”.)

:roll_eyes:

Dan,

@jelcynek mentioned $LOAD_PATH, which isn’t something typically known to a ‘newb’.

There wasn’t any mention of purpose, and I’ve written plenty of code that was just used within the companies I’ve worked at.

Regardless, encoding is messy. In ruby core a windows encoding issue dating back to 2.2 was brought up recently, and it was only fixed in June of last year. On top of that, it was done after a few other commits to core, and, because of those, it appears it can’t be backported to 2.4 and 2.3. So, it’s only fixed from 2.5 forward. It’s similar to the problem here, as it related to loading files.

Re RubyGems, I recently did some work with it, and I found issues with CLI parameters, especially if there are build parameters in a .gemrc file. After some testing tonite, same issues when trying to script gem commands.

As you’ve mentioned, it would certainly be helpful if more testing was done before new SU releases are made available, especially re encoding. They should also update whatever can be in the ruby releases. Appveyor seems to update Bundler, Minitest, Rake, & RubyGems for most Ruby versions (see appveyor-ruby), as that’s what their customers want. Trimble should do the same…

I hope to try and work on an SU gem script that allows one to run env, list, install, uninstall, etc. Also, as you’ve pointed out, it seems that SU 2018 is mangling some of the gem ENV variables, but the ‘user install’ path seems untouched. Installing gems there would also allow people to install the gem once, and all versions of SU using the same ruby major/minor version could share the gem. That may work for @jelcynek. Unfortunately, it also is shared by standalone ruby versions, along with the .gemrc file.

Thanks, Greg

Unfortunately doesn’t work.

I’m not so sure that this is encoding problem. I just downloaded SU2016 and all paths are properly displayed in console. There is no

Unable to find AppData directory.

message, but still I can’t require gem package.
Error: #<LoadError: cannot load such file -- rubyXL>

Any ideas how I could debug it deeper to ensure what is real reason?

@jelcynek

I’ve got rubyXL installed and loading in 2017. Haven’t yet tried to load a spreadsheet, but I’m sure it will.

I need to double check some things, it may be later before I get to it. FYI, I got it to install in the ‘USER INSTALLATION DIRECTORY’, so from any SU version using the same major/minor version of Ruby (ie, 2.2), it’s available…

Greg

If you had bothered to check his profile, you’d see he joined here only 13 days ago.

If you’d checked his activity and read this user’s threads and questions that were asking (about overriding native tools, etc.,) the “newbness” is evident.

It was never seriously implemented in SketchUp. SketchUp does not correctly supply a "config.rb" that actually reflects the SketchUp install. (The path returned by several Gem methods are just “out of the box” paths from the incorrect "config.rb".)

EDIT: Yes I mean "rbconfig.rb" (… was in a hurry, mind on other things.)

I’ve discussed this at length with Thomas and it is clear that SketchUp never did what is explained should have been done in the "rubygem.rb" lib (loader) file, … in comment section:
# == RubyGems Defaults, Packaging

In your other thread …

We talked about it, and it was rejected. Commercial extension developers rely upon SketchUp’s environment to be “clean” and controllable. Many of us did then and still do not want SketchUp placing requirements upon our “system” Ruby installs. So it only made good sense for SketchUp to distribute it’s “own” Ruby implementation.

But it’s rubygems configuration was “quick and dirty” and is still (since SU2014) not reliable.

Adding a multitude of gem possibilities outside of SketchUp’s influence creates problem scenarios and adds to Trimble’s support overhead. It would be a support nightmare for them. They just will not do it. (It’s “beating a dead horse”.)

To me, that simply infers that he/she may not be familiar with SU and the SU Ruby API. Nothing about programming experience. The question was essentially “I can do this in Ruby, but not in SU Ruby?” Also, rubyXL was mentioned, I was unaware of it, and it’s a nice gem allowing access to .xlsx files with no need to load (or have installed) a copy of Excel.

Please see Bug? - RubyGems & ENV['GEM_PATH'] for response on the balance.

Thanks,

Greg

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.