Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Considering different approach to Win32 release
Re: Considering different approach to Win32 release [message #45282 is a reply to message #45281] Tue, 27 October 2015 10:55 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
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.

Maybe TheIDE, after initial install, could check once in while to see if new mingw versions are available? Or new upp version? I doubt MINGW changes that often, so an option to only update uppsrc would be great.

Since you said that using exe is not that modern, neither is .msc. Modern things update themselves.

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

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.
Re: Considering different approach to Win32 release [message #45283 is a reply to message #45280] Tue, 27 October 2015 10:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 27 October 2015 10:39
Additionally, things like nullptr and

VectorMap<String, Vector<String>> classpath;

are not recognized out of the box when using MinGW.


Thanks, fixed.

Mirek
Re: Considering different approach to Win32 release [message #45284 is a reply to message #45278] Tue, 27 October 2015 11:00 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
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).
Re: Considering different approach to Win32 release [message #45285 is a reply to message #45284] Tue, 27 October 2015 11:26 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
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...
Re: Considering different approach to Win32 release [message #45286 is a reply to message #45285] Tue, 27 October 2015 12:25 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
cbpporter wrote on Tue, 27 October 2015 12:26
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...

Actually, it is 8627. That was our last official version which worked just fine with MSC.
Re: Considering different approach to Win32 release [message #45287 is a reply to message #45284] Tue, 27 October 2015 12:48 Go to previous messageGo to next message
Tom1
Messages: 956
Registered: March 2007
Experienced Contributor
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
Re: Considering different approach to Win32 release [message #45288 is a reply to message #45282] Wed, 28 October 2015 07:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 27 October 2015 10:55
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.


Agreed, but perhaps not for this release. (It will take significant time to develop).

Quote:

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


No, not yet. That said, we would like like to move there eventually.

Anyway, it is true that with C++11, transfer semantics issues were changed, so some minimal changes to the code, backward compatible with C++98, are needed. It took about 5 minutes to fix theide, so no big deal.

Quote:

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.


(fixed)
Re: Considering different approach to Win32 release [message #45289 is a reply to message #45287] Wed, 28 October 2015 07:58 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
Tom1 wrote on Tue, 27 October 2015 12:48
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



Thanks, I believe I have figured it out (mingw had it active for release, and so it got there on first run).

Mirek
Re: Considering different approach to Win32 release [message #45290 is a reply to message #45287] Wed, 28 October 2015 08:06 Go to previous messageGo to next message
Tom1
Messages: 956
Registered: March 2007
Experienced Contributor
Hi,

Thanks Mirek. Now BLITZ is not active any more by default. After using the new menu for legacy compilers, all MSC9, MSC9x64, MSC10 and MSC10x64 variants work without BLITZ right from the start.

A side note for MINGW: When compiling the UWord example, both 32 and 64 bit variants produce executables that crash on start. (Running on Windows 8.1 Professional x64.) Don't know what's the actual problem but it seems to be cured after switching all optimizations off (flag O0).

Best regards,

Tom
Re: Considering different approach to Win32 release [message #45291 is a reply to message #45290] Wed, 28 October 2015 10:53 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
OK, the C++11x issues are gone and now I'm left with 144 other errors. Most of them all in my code, but there is also an AssertMoveable issue:

C:\dev\upp/uppsrc/Core/Topt.h:212:70: error: specialization of 'template<class T> void Upp::AssertMoveable(T*)' in different namespace [-fpermissive]
  #define NTL_MOVEABLE(T) template<> inline void AssertMoveable<T>(T *) {}


My offending code is:

class Class;

class Source {
public:
	String Path;
	String data;
	ZParser parser;
	int index;
	bool IsScaned;
	
	Vector<Class*> Classes;
};

NTL_MOVEABLE(Source);

Re: Considering different approach to Win32 release [message #45292 is a reply to message #45291] Wed, 28 October 2015 11:10 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
Yeah, I am left with 56 C++11x related errors (move, copy constructors and implicitly deleted constructors for whatever reasons) that I have never encountered before.

This is the price you pay for using MSC 2010 Smile.
Re: Considering different approach to Win32 release [message #45294 is a reply to message #45292] Wed, 28 October 2015 11:32 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
When using something like:

AST ast = AST(ass);


I get an error related to an implicitly deleted copy constructor AST::AST(const AST&). It is probably deleted since I have a constructor that takes parameters and no default one. Up to this moment I have lived with the impression that such a statement, since it is a variable declaration, both officially and unofficially optimizes away and does not involve the use of a copy constructor.
Re: Considering different approach to Win32 release [message #45295 is a reply to message #45294] Wed, 28 October 2015 16:39 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Actually there's simple way to correct it. You just need to 'say' what you want explicitly:
AST ast = pick ( ass );
Re: Considering different approach to Win32 release [message #45296 is a reply to message #45295] Wed, 28 October 2015 16:48 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
Mindtraveller wrote on Wed, 28 October 2015 17:39
Actually there's simple way to correct it. You just need to 'say' what you want explicitly:
AST ast = pick ( ass );

It is a constructor, not a copy constructor. ast and ass do not have the same types.

The solution is:
AST ast(ass);

I write it as:

AST ast = AST(ass);

for uniformity.

I am expecting both to generate the same code and not involve a copy constructor, ass in AST(ass) being built and the the compiler complaining that there is no copy constructor.
Re: Considering different approach to Win32 release [message #45297 is a reply to message #45291] Wed, 28 October 2015 19:20 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
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).
Re: Considering different approach to Win32 release [message #45299 is a reply to message #45297] Thu, 29 October 2015 09:30 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
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".

Supposing I wanted to use Pop or any method with copy construction, which is the proper way to fix this to maximize compatibility with MSC2010 with its 1% C++11x compatibility, MSC15 and MINGW? Should I just write a copy constructor?

Anyway, main project now compiles under MINGW and all the changes to Core (only TimeStop precision issues) are now moved to my code base. I have no real interest in MINGW, but for the foreseeable future I shall be using MINGW just for testing purposes so I can report issues.
Re: Considering different approach to Win32 release [message #45300 is a reply to message #45297] Thu, 29 October 2015 09:42 Go to previous messageGo to next message
Tom1
Messages: 956
Registered: March 2007
Experienced Contributor
Hi Mirek,

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

1. From my point of view MSC9 and MSC10 both work perfectly OK now.

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

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
Re: Considering different approach to Win32 release [message #45303 is a reply to message #45299] Thu, 29 October 2015 13:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
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.
Re: Considering different approach to Win32 release [message #45304 is a reply to message #45300] Thu, 29 October 2015 13:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 29 October 2015 09:42
Hi Mirek,

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


Thanks for testing! Definitely helpful.

Quote:

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


That is definitely unexpected and "wrong".

Well, instead of long and detailed request for investigation, could you please just look into ide/InstantSetup.cpp and put on line 180





		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);


and then run "Instant setup.." and look into .log?

(Explanation: Instead looking into registry (which proved error-prone with MSC12), theide now scans Program files directories and attempts to find appropriate directories.)

Quote:

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


Unfortunately, investigation revealed apparent bug in GCC optimizer (you can compile in release mode with full debug info and run in debug - bug in assembly is quite apparent).

I will try to downgrade gcc version. If that does not help (it should, in Linux it works fine), I will change -O levels...

Mirek
Re: Considering different approach to Win32 release [message #45305 is a reply to message #45303] Thu, 29 October 2015 13:43 Go to previous messageGo to previous message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Ultimate Contributor
mirek wrote on Thu, 29 October 2015 14:13
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.


Thank you!

I also needed to add a default constructor, but it works now.
Previous Topic: mingw/gdb troubles
Next Topic: Ideas on U++ as library
Goto Forum:
  


Current Time: Sun Sep 26 23:07:59 CEST 2021

Total time taken to generate the page: 0.01525 seconds