What about just creating something like "portable" U++, simple .zip which, when unpacked, would run TheIDE from any folder, autoconfiguring everything in the process.

Is it a good idea?

Ah, maybe I should clarify the question...

Is it OK not to have "installer" version? Would save a lot of time...

Mirek

Well, current installer is deeply "illegal" - using .exe to install things was OK 10 years ago, but today .msi is required.

Anyway, before doing that, I have got an idea that perhaps we could try something different. What about just creating something like "portable" U++, simple .zip which, when unpacked, would run TheIDE from any folder, autoconfiguring everything in the process.

mingw would probably now be part of release, otherwise autoconfig would try to setup MSC15 build method. Nothing would be written to the registry, to unistall, all you need to do is to delete the folder.

Is it a good idea?

Mirek

Hi Mirek,

I'm having trouble getting started with this new portable version:

First, unpacking the 7z file takes quite a long time because of mingw is there. (How about a non-mingw variant of Upp? I think I will never use mingw anyway.)

Second, U++ can not find my installed MSC9 and MSC10 SDK compilers (32 nor 64 bit variants). Selecting Setup>Instant setup.. does not help.

Third, I tried compiling UWord with both MINGW32 and MINGW64. Both work in DEBUG mode, but when compiled in Optimal mode, both UWord executables crash on start.

Can you help with these? Edit: I mean especially with getting MSC9 and MSC10 back to work. Dropping MINGW would be a nice option extra...

Best regards,

Tom

Instant setup indeed ignores pre MSC15 compilers. The primary reason is simple: VS 2015 is the first real Win32 C++11 compiler. As we would eventually like to move to C++11, I have decided to force this upon poor users a bit

However, current U++ still supports MSC9 etc, including autosetup: It is hidden behind "Verbose" flag. Activate Verbose you will get legacy autosetup in Setup menu.

Thanks for archive size comment. I seemed OK to me, but this is perhaps the sign that more work is needed there... I guess I can significantly reduce the size, there is a lot of unused stuff there.

Mirek

Hi,

mirek wrote on Mon, 26 October 2015 13:23

Instant setup indeed ignores pre MSC15 compilers. The primary reason is simple: VS 2015 is the first real Win32 C++11 compiler. As we would eventually like to move to C++11, I have decided to force this upon poor users a bit

However, current U++ still supports MSC9 etc, including autosetup: It is hidden behind "Verbose" flag. Activate Verbose you will get legacy autosetup in Setup menu.

Thanks for archive size comment. I seemed OK to me, but this is perhaps the sign that more work is needed there... I guess I can significantly reduce the size, there is a lot of unused stuff there.

Mirek

While on the subject of 'force this upon poor users a bit' could you take a look at Bazaar/Protect from Max? I really need this type of solution and MSC9 is the last compiler to support the current implementation. (Right?) If there is an alternative solution for this task that works on MSC15 compilers, I'd be just happy to upgrade, but meanwhile I will need to stick with the old MSC9.

Best regards,

Tom

Hi Mirek,

Thanks for the tip! Helped a lot.

Even though the MSC9/MSC10 Build method does not have 'Use BLITZ' selected for release mode, I see that there seems to be a considerable amount of BLITZ used in release mode too. While radically boosting compilation times on MSC10, MSC10x64 and MSC9x64, it also results in an internal compiler error on 32 bit MSC9 somewhere in RichText/TxtOp.cpp. The code seems same as before, but disabling BLITZ for RichText in Package organizer allows successful compilation.

Shouldn't the 'Use BLITZ' selection for the build method be obeyed as the default?

Thanks,

Tom

Tom1 wrote on Mon, 26 October 2015 15:34

Hi,

mirek wrote on Mon, 26 October 2015 13:23

Instant setup indeed ignores pre MSC15 compilers. The primary reason is simple: VS 2015 is the first real Win32 C++11 compiler. As we would eventually like to move to C++11, I have decided to force this upon poor users a bit

However, current U++ still supports MSC9 etc, including autosetup: It is hidden behind "Verbose" flag. Activate Verbose you will get legacy autosetup in Setup menu.

Thanks for archive size comment. I seemed OK to me, but this is perhaps the sign that more work is needed there... I guess I can significantly reduce the size, there is a lot of unused stuff there.

Mirek

While on the subject of 'force this upon poor users a bit' could you take a look at Bazaar/Protect from Max? I really need this type of solution and MSC9 is the last compiler to support the current implementation. (Right?) If there is an alternative solution for this task that works on MSC15 compilers, I'd be just happy to upgrade, but meanwhile I will need to stick with the old MSC9.

Best regards,

Tom

What are symptoms? (I have compiled packages fine, after some minor C++11 fixing).

Mirek

C:\Users\tom\Desktop\upp-win32-9081\upp\bazaar\ProtectTest\main.cpp(19) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture

Tom1 wrote on Mon, 26 October 2015 15:01

Hi Mirek,

Thanks for the tip! Helped a lot.

Even though the MSC9/MSC10 Build method does not have 'Use BLITZ' selected for release mode, I see that there seems to be a considerable amount of BLITZ used in release mode too. While radically boosting compilation times on MSC10, MSC10x64 and MSC9x64, it also results in an internal compiler error on 32 bit MSC9 somewhere in RichText/TxtOp.cpp. The code seems same as before, but disabling BLITZ for RichText in Package organizer allows successful compilation.

Shouldn't the 'Use BLITZ' selection for the build method be obeyed as the default?

Thanks,

Tom

This is really strange. Can you post a copy of console log?

Mirek

So I tried updating to the new scheme.

Installation took forever from the 7z file and eats up 1 GB.

Automatic setup took again a while and did not find any of my MSC versions.

Running any GUI program and closing it still leaves TheIDE thinking that the application is running and I need to force close it.

This new system does not look production ready at the moment.

Additionally, things like nullptr and

VectorMap<String, Vector<String>> classpath;

are not recognized out of the box when using MinGW.

No need for log, I found the cause: While in 'Build methods' Use BLITZ is not active by default for MSC9 or MSC10, in 'Output mode' dialog it is active by default for release mode. By switching it of in 'Output mode' cures the symptoms.

Best regards,

Tom

Last version in official use is 8230.

I'm working on merging things so we can switch to a more mainstream version.

Need to figure out what to do with the CodeEditor fork...

Tom1 wrote on Tue, 27 October 2015 09:20

No need for log, I found the cause: While in 'Build methods' Use BLITZ is not active by default for MSC9 or MSC10, in 'Output mode' dialog it is active by default for release mode. By switching it of in 'Output mode' cures the symptoms.

Best regards,

Tom

Well, but that is weird too, it should not be active... (unless you have activated it accidentally).

Thank for the answers Mirek!

I tried with upp-win32-9087.7z.

After this step is done, maybe it is time to consider a more modern update mechanic? Big downloads and installs take away the old advantage of U++ of getting it up and running and updated using nightly builds.

I missed the VS2015 explanation. Does that mean that U++ now needs C++11? Our official compiler in 2010 .

And what about MINGW not recognizing nullptr and other things? I think that the switch to MINGW will result in a lot of compatibility patches in user's code since MSC does take its fair share of liberties.

mirek wrote on Tue, 27 October 2015 12:00

Tom1 wrote on Tue, 27 October 2015 09:20

No need for log, I found the cause: While in 'Build methods' Use BLITZ is not active by default for MSC9 or MSC10, in 'Output mode' dialog it is active by default for release mode. By switching it of in 'Output mode' cures the symptoms.

Best regards,

Tom

Well, but that is weird too, it should not be active... (unless you have activated it accidentally).

I reinstalled 9081 to be sure and in 'Output mode' dialog BLITZ is enabled for both debug and release modes out of the box. (Of course I had to create build methods for my MSC9 and MSC10 by using the Be verbose + Automatic setup, but that's really all.)

Best regards,

Tom

Actually there's simple way to correct it. You just need to 'say' what you want explicitly:

AST ast = pick ( ass );

use

class Source : Moveable<Source>

That said, sometimes I am thinking that perhaps that "Moveable" thing is unnecessary... (It only serves to remind the programmer that there are rules about things put into Vector).

def.Blocks.Pop();

class Block: Moveable<Block> {
public:
	VectorMap<String, Variable> Vars;
	int Temps;
};

mirek wrote on Wed, 28 October 2015 20:20

use

class Source : Moveable<Source>

That said, sometimes I am thinking that perhaps that "Moveable" thing is unnecessary... (It only serves to remind the programmer that there are rules about things put into Vector).

Thanks! So NTL_MOVEABLE no longer works under this setup?

It is weird tracking things down with all the difference s between compilers and version.

I have one final issue which I know how to solve:

def.Blocks.Pop();

Now, first of all, I shouldn't be using Pop, since I do not care about the value. I should be using Drop.

class Block: Moveable<Block> {
public:
	VectorMap<String, Variable> Vars;
	int Temps;
};

I get the error "use of deleted Block::Bock(const block&)" / "is implicitly deleted because the default definition would be ill-formatted".

Hi Mirek,

I have now tested 9105 on Windows 8.1 Professional x64 with the following results:

2. It still can't find the installed Visual studio 2015 community edition. Is this expected?

		vc = df.ScanForDir("/vc", "", "bin/link.exe;bin/cl.exe;bin/mspdb140.dll", "bin/1033");
		bin = df.ScanForDir(x64 ? "bin/x64" : "bin/x86", "/windows kits/", "makecat.exe;accevent.exe", "");
		inc = df.ScanForDir("", "/windows kits/", "um/adhoc.h", "um;ucrt;shared");
		lib = df.ScanForDir("", "/windows kits/", "um/x86/kernel32.lib", "um;ucrt");

DUMP(vc); DUMP(bin); DUMP(inc); DUMP(lib); // <<==== THIS
		
		if(vc.GetCount() * bin.GetCount() * inc.GetCount() * lib.GetCount()) {
			bins.At(0) = vc + (x64 ? "/bin/amd64" : "/bin");
			bins.At(1) = bin;
			String& sslbin = bins.At(2);

3. MINGW Debug compiles UWord correctly and the resulting executable works.

4. MINGW Size compiles UWord correctly and the resulting executable works.

5. MINGW Optimal compiles UWord but the resulting executable crashes. It requires dropping the speed optimization flag from O3 to O2 in order to make it work.

6. MINGW Speed compiles UWord but the resulting executable crashes. It requires dropping the speed optimization flag from O3 to O2 in order to make it work.

7. MINGWx64 Debug compiles UWord correctly and the resulting executable works.

8. MINGWx64 Size compiles UWord but the resulting executable crashes. (Switching from Os to e.g. O0 in size optimization flags fixes the executable.)

9. MINGWx64 Optimal compiles UWord but the resulting executable crashes. (Switching from Os to O0, O1, O2 or O3 in size optimization flags fixes the executable.)

10. MINGWx64 Speed compiles UWord correctly and the resulting executable works.

Best regards,

Tom

cbpporter wrote on Thu, 29 October 2015 09:30

mirek wrote on Wed, 28 October 2015 20:20

use

class Source : Moveable<Source>

That said, sometimes I am thinking that perhaps that "Moveable" thing is unnecessary... (It only serves to remind the programmer that there are rules about things put into Vector).

Thanks! So NTL_MOVEABLE no longer works under this setup?

It is weird tracking things down with all the difference s between compilers and version.

I have one final issue which I know how to solve:

def.Blocks.Pop();

Now, first of all, I shouldn't be using Pop, since I do not care about the value. I should be using Drop.

class Block: Moveable<Block> {
public:
	VectorMap<String, Variable> Vars;
	int Temps;
};

I get the error "use of deleted Block::Bock(const block&)" / "is implicitly deleted because the default definition would be ill-formatted".

This another small difference. See http://www.ultimatepp.org/srcdoc$Core$pick_$en-us.html, Composition.

You need to add

rval_default(Block);

to the class.