DSP Robotics Support

Hi All,
Anybody else having trouble with the Win32API Ruby library? I'm finding it really useful for calling the Windows API to add new features to FlowStone - however, it seems to crash whenever you try to 'require' it from an exported EXE or VST.
I have copied the necessary files to the same directory as the export, as directed by the manual, and my testing indicates that the file IS being found. But it seems that Ruby fails without even raising an exception as soon as it tries to import the C-extension 'dl.so' (the interfacing code for the API).

Here's a test schematic - I'd be really grateful if anyone could confirm the problem - particularly on Win7/8, as I'm still on XP, so Malc will want to know if the bug is OS specific.

To run the test, you need to follow these steps.
1) - Export the test module to an EXE in a known directory path.
2) - Go to your Flowstone installation directory, i.e. /Program Files/DSPRobotics/Flowstone (or Program Files(x86) if you use Win7/8).
3) Copy the whole of the 'ruby' sub-folder into the same directory as the export to make the library available.
4) Run the EXE.

In the EXE window, you should see...
1) - A list of directories that were searched for the file.
2) - The current working directory, should be the same as the directory where the EXE is placed.
3) - One or more 'Found' messages to say that Win32API was successfully located.
4) - POSSIBLY - a message to say that Win32PI was 'required' successfully.

If you DON'T see the 'require SUCCESS' message, Ruby has bombed out in the same way that I'm seeing here (two different machines show the same problem). Due to Ruby bombing, I can't get any better diagnostics than that - so remember that you are checking that you DON'T see this last message.

If you see a 'LoadError' message, the file has not been found - check that you copied the 'ruby' folder to the right location.

Thanks for any help with this. I'm working on a test/de-bugging suite for FlowStone at the moment that I think folks will find very useful - and I want this to be able to work with exports so that you can debug plugins while they're actually in use within a host. Not having Win32API in exports really screws this up!!

Best wishes,
Trog.

Win 7 no 'require SUCCESS' message



sorry

Wow, that was fast!
Many thanks, this is exactly what Malc needs to know so that he can get to the source of the bug - I'll pass that info onto him straight away.

Xtinct wrote:sorry

No need to apologise - it's not your fault that Flowstone has a bug!

Hi Trog!

My System:
Win8 64 bit Quad Core

with Admin rights

cheers,
Walter

Brilliant - thanks Walter.
That pretty much wraps it up then - definitely something in Flowstone.

Looking at the reports, I also notice something else...
The User guide states that you must copy the 'ruby' folder OR have FS installed on the machine. However, no-ones $LOAD_PATH includes the 'win32/common' folder from Program Files - just a duplicate of the working directory relative path. This is why I explicitly asked for folks to copy the folder - were the user guide and $LOAD_PATH correct, this shouldn't be necessary for any of us. Seems that this is "universal" to all installations as well.

Time to mail Malc again!

Failing on Windows 8 here, too.

However I think it tries to load the lib, when you copy the ruby folder to the root of your EXE filesystem. eg. when the EXE is on drive C, copy the ruby folder to C:/ruby. Problem there is quite bad, though. It crashs the EXE instantly.

Hi MyCo,
From what I've been able to tell, the problem is with the underlying 'DL' class - 'Win32API' is just a simple wrapper around that to maintain compatibility with older Ruby versions after the original class was deprecated.
'DL' uses an '.so' file - i.e. a compiled 'C' extension - and it seems that this is the sticking point. If you make a 'dummy' Win32API.rb file and put it in the right place, it will require no problem, and I've had no problems requiring my own native Ruby libraries from any folder I care to.
Even adding the proper entry to $LOAD_PATH for the install path version of the file makes no difference.

I've also seen the complete crashing - "Problem encountered, had to close" etc.- but can't quite get a handle on when or why. Your example might give a hint though - some kind of access permission maybe? Allowing items in a folder to execute is a distinct permission from 'read/write' within the OS, IIRC - maybe this applies to the 'dl.so' file because it is a compiled binary?

Just had a mail from Malc about this problem.

It seems it was introduced during the last update. One of the big features was having Ruby statically linked within the exports, to avoid the problems with shared Ruby namespace and make unpacking of the interpreter and .dlls unnecessary.
However, a side effect of this is that Ruby can no longer dynamically link to C-extensions, such as the DL class within Win32API- native Ruby files are fine, but not binary '.so' files.

He's offered to make the old method of embedding Ruby available as an export option, but I'm not too comfortable with giving him extra work to do and slowing down the next release just for little old me - I've yet to see anyone else using Win32API for anything! Much easier for him to just edit the User Guide to make the situation clear.

If anyone else feels that access to Win32API/C-extensions is a "must have" feature, then let me or Malc know. Otherwise it's time for me to roll my sleeves up, fire up Visual Studio, and get to grips with the dreaded C++.