startupstack.cpp

[mwieder]

Just curious about this...

it appears to be a representation of a compressed stack used to bootstrap the IDE (only used by mode_development.cpp).

[monte]

It's probably the login/license stack. That's not in the tools folder so it's got to be embedded in the engine.

[mwieder]

That's my guess as well.

[monte]

well I wonder what happens if you just set it to:

Code: Select all

unsigned char MCstartupstack[] =
{};
unsigned int MCstartupstack_length = 0;

[mwieder]

Moving the discussion of the login process here.

Before I submit a pull request with my engine changes I need to test them (yeah, I'm weird that way).
I'm now at the point of having compiled the engine code and I'm faced with the login screen.

I don't like the idea of the forced login screen. I do like the idea of *encouraging* new users to register for some obvious reasons: there are advantages to the user in that they can register to receive update notices, optionally get notices from runrev about third-party add-ons, etc; and there are advantages for runrev in that they get an idea of the userbase, they can easily notify users of upcoming changes, new listservs and forums, etc. But I don't think it should be manadatory. It's very anti-FOSS.

So... if I log in once I never have to do that again, I'll never see the login screen (I think), and the issue will never be in my face. I'm likely to forget all about it, it won't be a burning issue for me, it's not going to be something I am going to have to care about that much.

I also don't really want to fork the engine code just to bypass this. It seems like a sleazy thing to do.

I'd like runrev to make the login optional and allow continuing without logging in. But in any event I'd like to get an official word from the mothership about a direction on this issue: either "yes, we've listened to the clamor and we're changing the login process" or "it's our ball and our game and you don't have to play if you don't want to". But I'd like some official response before I move on.

[monte]

I agree with you. I also don't like it but I also don't want to fork because of it. The way I think about it is if we don't like it (long time supporters of LiveCode and RunRev as we are) then what are other potential contributors going to think? It's going to go one way or the other but it's just a matter of how it goes and if that means that lots of contributors end up contributing to a GPL only fork that's outside RunRev's contributor agreement. Once that starts it would be near impossible to merge those changes back in even if RunRev change the login because they would need to get all contributors to the fork to agree. So RunRev could end up with a situation where all their work is pulled into the fork but none of the contributor work is going the other way. That would be bad for the commercial platform.

[mwieder]

Yeah, that's where Oracle is now with Hudson/Jenkins. Not that I think Oracle really cares about it, but the open-source Jenkins fork is where the action is and users are leaving Hudson in droves.

[monte]

Right, and if we are slightly annoyed by it now then wait until there's features commercial developers want in the GPL fork but can't use and RunRev don't have the resources to implement. If there were some extremely active contributor there it could happen.

[monte]

I was intrigued by this so took a look at the startup method for development mode. It seems that this stack sets the result to the name of the stack to load. If the result is empty it quits. It looks quite simple to skip all that...

[LCMark]

The startupstack.cpp is generated from Environment.rev which is the stack the IDE engine uses on startup to activate, license and configure the engine. The Community version doesn't do a great deal; the Commercial version does a fair bit more.

[mwieder]

Kevin has confirmed that the login procedure will be changed in "the next major release", so I'm good with this. As far as I'm concerned, that's the end of the story. I made a dummy account, got my license file, it was stored in the usual place, and as long as it doesn't phone home I'm not wasting my time on the startup stack any more.

Thank you, Kevin.