SKX Project? Win32::API ?

thomthom

@dan rathbun said:

You cannot ignore the other major clause that you do not interfer with a user running a standard version (which would be installed in the correct place, which is one of the Ruby Library folders.)

What would interfere?

Dan Rathbun

@thomthom said:

@dan rathbun said:

You cannot ignore the other major clause that you do not interfer with a user running a standard version (which would be installed in the correct place, which is one of the Ruby Library folders.)

What would interfere?

I explained it above in this post: http://forums.sketchucation.com/viewtopic.php?f=180&t=34124&p=300656#p300629

thomthom

@dan rathbun said:

Step 2, compile editions for, at least

minGW* mswin32(MSVCRT6)
Or perhaps MSVCRT 7 if you feel all XP should be up to 7 by now.

You can change the so file name after compilation, like api-mswin-60.so (to follow Dan Berger's convention.) That way you can put them all in one subfolder of YOUR plugins lib subfolder:

Ah - I missed this when I was reading your replied the first time.
Compiling it into my own namespace. That's be a safe way of doing it.
Only thing is that I'm not too up to grips with compiling.

Dan Rathbun

@thomthom said:

Compiling it into my own namespace. That's be a safe way of doing it.
Only thing is that I'm not too up to grips with compiling.

Me either.. Ruby is confusing.

The minGW dev kit is supposed to make compiling under that easier.
Some where I thought Dan Berger has instructions for compiling using MS VC/C++

A possible Pure Ruby alternative, is to "steal" the Win32 module INTO your namespace, then remove the temporary toplevel one.

if Win32 has not yet been loaded, load an edition from your TT_Lib subfolder
from within your TT_Lib namespace, call (depending on Ruby ver)

[v1.8.0] Win32 = Object.const_get(:Win32).clone* ['newer'] Win32 = ::Win32.clone

remove the top_level Win32 module, via:
Object.instance_eval('remove_const(:Win32)')
run GC.start

Note that the newset ver of win32-api is now 1.4.7 (but you must get it from the RubyGems site. The RubyForge site only has 1.4.5 available.)

thomthom

What I'm stuck with is compiling it. all tutorials refer to a make command...

thomthom

w00t!
Got it compiled and running!
TT::Win32::API

thomthom

Now, how does the license work for distributing this binary?

thomthom

301 Moved Permanently

(www.opensource.org)

@unknownuser said:

Distribution of Compiled Forms of the Standard Version or Modified Versions without the Source
(6) You may Distribute a Modified Version in Compiled form without the Source, provided that you comply with Section 4 with respect to the Source of the Modified Version.

@unknownuser said:

Distribution of Modified Versions of the Package as Source
(4) You may Distribute your Modified Version as Source (either gratis or for a Distributor Fee, and with or without a Compiled form of the Modified Version) provided that you clearly document how it differs from the Standard Version, including, but not limited to, documenting any non-standard features, executables, or modules, and provided that you do at least ONE of the following:

(a) make the Modified Version available to the Copyright Holder of the Standard Version, under the Original License, so that the Copyright Holder may include your modifications in the Standard Version.
(b) ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version. In addition, the Modified Version must bear a name that is different from the name of the Standard Version.
(c) allow anyone who receives a copy of the Modified Version to make the Source form of the Modified Version available to others under
(i) the Original License or
(ii) a license that permits the licensee to freely copy, modify and redistribute the Modified Version using the same licensing terms that apply to the copy that the licensee received, and requires that the Source form of the Modified Version, and of any works derived from it, be made freely available in that license fees are prohibited but Distributor Fees are allowed.

So, does that mean that when I've changed it to be under my own namespace I can just distribute the .so binary? Simple as that?

Dan Rathbun

@thomthom said:

w00t!
Got it compiled and running!
TT::Win32::API

excellent!

and ya' didn't want to use TNT ? (AC/DC tune running thru my head.)

thomthom

@dan rathbun said:

and ya' didn't want to use TNT ? (AC/DC tune running thru my head.)

Well, I have already been using TT for a while now and all my recent plugins are under that. Trying to void creating more root namespaces.
Though I do like your explosive suggestion.

Thanks for pointing out that it would be re-wrapped like that.

Dan Rathbun

@thomthom said:

So, does that mean that when I've changed it to be under my own namespace I can just distribute the .so binary? Simple as that?

Your compliance: (if you wish, you can ask Dan Berger, what he thinks...)

(4) ... clearly document how it differs from the Standard Version, including, but not limited to, documenting any non-standard features, executables, or modules, ...

Add a README.TXT file that explains:
the TT edition is FUNCTIONALLY still the Standard Version, but namespace wrapped to comply with 4(b)
(4)(b)In addition, the Modified Version must bear a name that is different from the name of the Standard Version.
the Win32 module is loaded as TT::Win32 and the API class is loaded as TT::Win32::API; so as to comply with 4(b)* .. and that the executables are renamed as api_mingw_TT.so and api_mswin_TT.so (or whatever you named them,) in order to comply with 4(b)* you are not marketing or advertising the name "win32-api", and to most endusers, the package's use of this will be transparent.

(4)(b) ... ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version.

Done - because you are loading it into your namespace, AND that namespace will separate your edition from the standard edition, which is loaded into the TOPLEVEL namespace (ie: Object).

(5) You may Distribute Compiled forms of the Standard Version without the Source, provided that you include complete instructions on how to get the Source of the Standard Version. ...etc...

Add to the README.TXT file the links to the RubyForge and RubyGems sites where a user could get the source, and* the instructions as I gave you (above,) on how to module wrap the Standard Version within THEIR OWN namespace.

Add Permission info to the README.TXT:

Because the MODIFIED VERSION only differs from the Standard Version by:

being defined in the TT namespace,

which is for the protection of a normal unmodified Standard installation, * that the TT namespace is for the sole use of Thomas Thomassen,

and that the further modification of the modified version is not feasible, and has no value to any other enduser, unless that user creates a modified version for their OWN namespace from the Standard source code. * and is FUNCTIONALLY still the Standard Version, ... the TT edition is to be considered as a "portability change" under (3) of the License, and that:
"The resulting Package will still be considered the Standard Version, and as such will be subject to the Original License."

So, they have right to use under (1) of the License, viz:

(1) You are permitted to use the Standard Version and create and use Modified Versions for any purpose without restriction, provided that you do not Distribute the Modified Version.
And... include a copy of Artistic License 2.0

thomthom

If the api.so is named differently it doesn't load.
4 said one only had to comply with at least on of the bullets it mentioned - so it'd be ok not to rename the binary then?

Dan Rathbun

@thomthom said:

If the api.so is named differently it doesn't load.

What?

If you have the binary named: plugins/TT/api_mswin_TT.soand you call (from within one of the TT lib files):

require "TT/api_mswin_TT.so"

it doesn't load ??

what is the error message ??

Dan Rathbun

@thomthom said:

(4) said one only had to comply with at least one of the bullets it mentioned - so it'd be ok not to rename the binary then?

problem is you are using (4)(b) which has two provisions listed...

I think it unwise to have your binaries bear the same names as the standard api.so

(You know... there will be people who will copy your binaries some place else.. and then they be crying why doesn't it work? Why doesn't my TT plugins work anymore.. etc. And you'll spend time telling them to put the files back where they belong.. it always happens.)

You want to prevent a similar situation we have with Win32API.so (multiple copies of numerous versions, some compiled as mswin, some as minGW.)

Dan Rathbun

If you must, then before compiling...

rename your modified source file api_mswin_TT.c
.. or perhaps api_mswin_TT_1_4_5.c to include the version (may allow you to distro newer so files without re-releasing the TT.rb file, if you write a "smart" loader that finds the latest version in your plugins subfolder.)

edit the make file if need be and compile.

Do the same for the minGW compilation (name it api_mingw_TT_1_4_5.c )

You understand this whole way.. needs that conditional load ruby snippet I posted at:
http://forums.sketchucation.com/viewtopic.php?f=180&t=34124&start=0#p300530
feel free to:

clean it up* wrap the conditionals into boolean methods* modify the way the so filenames are found by looking for the newest version* etc.

thomthom

I found that the init method in the binary needed to match the name of the binary's filename.
So that is easily taken care of.

But I'm confused about this multiple compiling thing. I didn't have to do that for Vertex Tools. I only compiled once for Windows and once for OSX. No other plugin ship multiple binaries for the same platform.

Dan Rathbun

@thomthom said:

But I'm confused about this multiple compiling thing. I didn't have to do that for Vertex Tools. I only compiled once for Windows and once for OSX. No other plugin ship multiple binaries for the same platform.

OK.. internally, inside api.c Dan Berger has made RECENT changes that allows for certain calls to work when the Ruby interpreter binary that is loaded, was compiled with minGW.

I also posted a link to a forum, where Dan Berger posted his intent, to begin releasing both minGW and mswin compiled binaries. (He actually already has begun doing so and the RubyGems site.)

In the early days, he began that project long before minGW existed, and he was compiling api.so with MS Visual C 6. Windows Ruby, the interpreter and the library so files were all compiled with MSVC some version, and so the RUBY_PLATFORM == "i386-mswin32".
This includes the early "Windows One-Click Ruby Installer"

The old installer was abandoned, rewritten and renamed "RubyInstaller for Windows" but uses the minGW compiler. It returns RUBY_PLATFORM == "i386-mingw".

The safe thing to do is use so files that are compiled with the compiler that compiled the Ruby interpreter DLL that IS LOADED.

If a user wants mswin compiled Ruby, they can download precompiled binaries from ftp.ruby-lang.org (they can also get source there as well.)

Sketchup comes with a mswin binary... but a user can syncronize Sketchup and his full Ruby install by replacing the SU folder DLL, with copy of the minGW compiled DLL from his "system" installation, if he used the newer "RubyInstaller for Windows" ...

.. otherwise the user should use mswin compiled DLL and so files.

NOW your asking if it's ok to mix and match. Maybe under certain conditions... maybe if you dont use sockets or pipes.. I don't know what the "do and donts" are.. so I do not mix on my system, and would not lead any user to.. unless I know there will be no harm.

This may be a good question to ask Luis Lavana over at the Ruby Installer forum.

thomthom

So, the thing about compiling with different compilers is if a user where to replace the Ruby interpreter of SketchUp?

Dan Rathbun

if they were to.. yes

are they likely to... if they poke about and learn a bit, and end up using the Installer, they will have minGW compiled Ruby, and should use a copy of the minGW interpreter DLL with Sketchup.

... but if they go with what ever Google gives them .. a large percent of the users, they'll have th mswin32 compiled DLL.