TurboCAD Forums

The Ultimate Resource for TurboCAD Knowledge

Register
 
Interested in some really terrific mobile apps? Visit www.turboapps.com for details.

Ruby console fails to load scripts when files come from a network drive
Read 3264 times
* August 13, 2014, 11:13:55 PM
I'm wondering if I can get some help here... I've written a number of Ruby scripts. The profile directory \Home\Documents\TurboCAD Professional 20\Ruby Scripts is on a network drive.

When I start the Ruby Console, I get an error along the lines of:

no such file to load -- <name of ruby-file>.rb

This implies that the console sees the file (otherwise, how would it know its filename?) but, for some reason, fails to load it. Hence, none of the scripts actually work.

Is there any solution to this bug?

Thanks,

Gabriel

Logged


* August 14, 2014, 08:53:34 AM
#1
Hi Gabriel
I moved a few scripts on a network drive. From this place I loaded it and ran. It worked without a problem (TCPro 20). Have you tried using Ruby Console perform
1 Load
2 Execute
3 Use the block name and enter.
Can you post some sample script.
Marek

Logged
Marek

TurboCAD Pro 2016, TurboCAD Pro 2017
Laptop Asus i7 6500U, dual-core 2,50GHz, NVIDIA GeForce GTX 950M, RAM 12 GB, SSD 480GB
Windows 10 64 bit


* August 14, 2014, 09:33:09 PM
#2
Hi Marek,

Thanks for the response.

I tried explicitly loading a script from its location in the network folder, and it loaded into the console.

However, it depends on a number of sub-files (when I developed the scripts, I developed a library of routines that the main script uses), and the script fails on the "require" line.

The problem which I (and my client, who uses these scripts for their workflow, and have all user directories stored on a network server to allow portability of accounts) am encountering is that the console itself cannot seem to "auto load" these scripts when the *user folder* in which the scripts are stored are on the network, not locally on the machine.

The RubyConsole is supposed to auto-load scripts from the RubyScripts directory in the user folder \Home\Documents\TurboCAD Professional 20\ but this is broken - it even fails to load the demo scripts that the application ships with.

Is there any way to re-point TurboCAD to auto-load scripts from somewhere else? Or to "help" it auto-load the scripts when the documents directory is on a network drive?

It isn't really an acceptable solution for my client to have to explicitly "load" the scripts after opening the Ruby console... I would also have to re-engineer all the scripts into one big script file.

Thanks :)

Gabriel

Logged


* August 14, 2014, 10:19:15 PM
#3
The attached Ruby files are sufficient to demonstrate the problem and serve as a minimal representation of the much larger set of code that I have put together.

Logged


* August 15, 2014, 05:28:32 AM
#4
Hi Gabriel
I see that now, that your test copied to a network drive, does not work. It only works, if it is in a place, where TurboCAD loads scripts automatically, from dedicated to this folder. Looking at the activity SDK Corner, it seems to me, you would have to write to support. If they do not come up  with something right away,  problem may be attached to a "Wish List".
Marek

Logged
Marek

TurboCAD Pro 2016, TurboCAD Pro 2017
Laptop Asus i7 6500U, dual-core 2,50GHz, NVIDIA GeForce GTX 950M, RAM 12 GB, SSD 480GB
Windows 10 64 bit


* August 17, 2014, 04:28:27 PM
#5
Thanks for confirming, Marek. Yes, this forum is very quiet. I was hoping someone who works at TurboCAD might be able to give some help here (and thus benefit anyone else who runs across the same problem). I'll try contacting support directly.

Logged


August 19, 2014, 07:10:20 AM
#6
Hi all!
 
It seems, Ruby tries to find relative includes into its default directory (Documents\TurboCAD Professional 21x64\RubyScripts\)
or it needs full path to include file. But...
 
According to Ruby documentation for require() method:
If the filename does not resolve to an absolute path, it will be searched for in the directories listed in $LOAD_PATH ($:).
 
http://www.ruby-doc.org/core-2.0/Kernel.html#method-i-require
 
 
 
So I changed ghauber script to
 
Code: [Select]
$LOAD_PATH << '//network_dir/RubyScripts/'
require 'TestInclude/test_include'
 
UI.menu("Ruby scripts").add_item("Test 1") {
    puts "Hello from test 1"
}
UI.menu("Ruby scripts").add_item("Test 2") {
    test_item_2
}

Then moved TestInclude dir with test_include.rb into //network_dir/RubyScripts/, became //network_dir/RubyScripts/TestInclude/test_include.rb
and it seems test_ruby.rb works from any place I started it.
 
Here is additional info about $LOAD_PATH and different way how to use require(): http://www.databasically.com/2010/10/26/simplifying-library-requires-with-load_path/
 
I hope this will help.
« Last Edit: August 19, 2014, 07:16:22 AM by Igorun »

Logged
SoftDev, Saint-Petersburg.


* August 23, 2014, 10:35:19 AM
#7
Hi Igor
I have tried this,  only on the example of Gabriel, modified by you and it works. I use only  scripts placed in a typical folder, but it's always good to learn something new. Thanks.
Marek

Logged
Marek

TurboCAD Pro 2016, TurboCAD Pro 2017
Laptop Asus i7 6500U, dual-core 2,50GHz, NVIDIA GeForce GTX 950M, RAM 12 GB, SSD 480GB
Windows 10 64 bit


* October 06, 2014, 12:08:45 AM
#8
(Been busy with other projects…)

This has been helpful, and has got me part of the way there.

However, (on my setup at least), there is still a huge show-stopper. Because the *user documents* directory, where TurboCAD looks for scripts on startup of the Ruby Console, is on the network, my initial file is *found* by TurboCAD but fails to load.

If I move it to another location, or explicitly load/execute it, the file loads fine and seems to find the required dependencies just fine (after adding the $LOAD_PATH << line), BUT the line to add a menu command does nothing. Hence, the scripts can't actually be executed.

This *may* be a peculiarity with my own particular setup (running Windows 7 inside a Parallels VM, and the user home directory is mapped as a network drive to my Mac's home directory), so I hope to test soon on the client's computers. But since everything else has behaved identically on their setup as to mine, I'm not overly hopeful of it working.

Logged