Hello Mirek

What will be the improvements and where do you expect the compatibility problems may appear?

koldo wrote on Wed, 04 May 2016 09:38

Hello Mirek

What will be the improvements and where do you expect the compatibility problems may appear?

I will detail changes soon (but mostly it is about C++11 and multithreading).

So far, apart for one or two minor changes, suprisingly the most compatibility problems are caused by new Core detecting subtle bugs.

It took me 5 minutes to fix those is my largest app.

Mirek

Today I've spent like 5 minutes trying to find the function that copies text to clipboard, only to find that in CtrlCore.h there are things like ClearClipboard and WriteClipboardUnicodeText. Things like this should really be Clipboard::Clear and Clipboard::Write.

Hi Mirek,

I have updated the packaging to use C++11, but TheIDE build still fail. The error says DeepClone is not declared, you can see it in the build logs, e.g. for Debian Wheezy. Could you have a look at it, please?

Honza

Most likely it is missing MT in main package config.

mirek wrote on Sun, 08 May 2016 06:31

Most likely it is missing MT in main package config.

Oh, right, I missed that it is necessary now.

So the situation is much better now. There is just few problems left:

Ubuntu 12.4 and ScientificLinux 6 both fail, because their compiler (GCC 4.6 and 4.7, respectively) is so old it doesn't even support the option -std=c++11. Also the compiler in Debian Wheezy (GCC 4.7) doesn't work. This one already knows c++11, but thread_local keyword is not implemented, so the compilation fails.

And the last problem is in ArchLinux packages where the compilation fails on conflicting declaration of abs(int64), which is already present in stdlib in C++11.

Is it safe to drop support for the old distros, even though they are still supported? Ubuntu 12.4 has end-of-life scheduled for April 2017, Debian Wheezy has LTS until May 2018 and ScientificLinux 6 even has full support until Q2 2017 (and then maintenance updates until November 2020).

Honza

I tried to compile last version (upp-x11-src-9809.tar.gz) from source but it failed with lack of std=c++11.
Where it should be added?
src/Makefile?
src/Makefile.in?
src/UMakefile?

dolik.rce wrote on Sun, 08 May 2016 15:37

Is it safe to drop support for the old distros, even though they are still supported? Ubuntu 12.4 has end-of-life scheduled for April 2017, Debian Wheezy has LTS until May 2018 and ScientificLinux 6 even has full support until Q2 2017 (and then maintenance updates until November 2020).

Perhaps we can switch it to 'classic'?

mirek wrote on Mon, 09 May 2016 11:23

dolik.rce wrote on Sun, 08 May 2016 15:37

Is it safe to drop support for the old distros, even though they are still supported? Ubuntu 12.4 has end-of-life scheduled for April 2017, Debian Wheezy has LTS until May 2018 and ScientificLinux 6 even has full support until Q2 2017 (and then maintenance updates until November 2020).

Perhaps we can switch it to 'classic'?

It could be done, if you package the 'classic' uppsrc into the nigthly tarball.

dolik.rce wrote on Mon, 09 May 2016 16:32

mirek wrote on Mon, 09 May 2016 11:23

dolik.rce wrote on Sun, 08 May 2016 15:37

Is it safe to drop support for the old distros, even though they are still supported? Ubuntu 12.4 has end-of-life scheduled for April 2017, Debian Wheezy has LTS until May 2018 and ScientificLinux 6 even has full support until Q2 2017 (and then maintenance updates until November 2020).

Perhaps we can switch it to 'classic'?

It could be done, if you package the 'classic' uppsrc into the nigthly tarball.

Well, I do not. 'classic' is basically branch for systems not supporting C++11.

I perhaps could generate complete 'classic' tarball.

Maybe the package should be left as is, and upp2 can be introduced? (like kde4 vs kde5 during transition period)
Or that's too complicated to maintain either?

mirek wrote on Mon, 09 May 2016 17:25

dolik.rce wrote on Mon, 09 May 2016 16:32

mirek wrote on Mon, 09 May 2016 11:23

dolik.rce wrote on Sun, 08 May 2016 15:37

Is it safe to drop support for the old distros, even though they are still supported? Ubuntu 12.4 has end-of-life scheduled for April 2017, Debian Wheezy has LTS until May 2018 and ScientificLinux 6 even has full support until Q2 2017 (and then maintenance updates until November 2020).

Perhaps we can switch it to 'classic'?

It could be done, if you package the 'classic' uppsrc into the nigthly tarball.

Well, I do not. 'classic' is basically branch for systems not supporting C++11.

I perhaps could generate complete 'classic' tarball.

I understand that it is a branch, but I think it could still be present in the tarball as a "fallback" for older systems. It would also be simpler for the users, because having two tarballs requires explaining them in great detail which one they should use...
Honza

Hello Mirek

What will be the improvements and where do you expect the compatibility problems may appear?

Web was planned to be removed. It was DEPRECATED years ago.

Is there anything in Web that you need? I guess I can still fix it...

mirek wrote on Wed, 11 May 2016 11:33

Web was planned to be removed. It was DEPRECATED years ago.

Is there anything in Web that you need? I guess I can still fix it...

Oh, sorry I wasn't aware of deprecated status of Web package.
After looking into code, it looks like HttpQuery is the only dependant class from Web package I still use.

Mindtraveller wrote on Wed, 11 May 2016 16:30

mirek wrote on Wed, 11 May 2016 11:33

Web was planned to be removed. It was DEPRECATED years ago.

Is there anything in Web that you need? I guess I can still fix it...

Oh, sorry I wasn't aware of deprecated status of Web package.
After looking into code, it looks like HttpQuery is the only dependant class from Web package I still use.

Really? I had no idea .

What are we supposed to use instead?

dolik.rce wrote on Mon, 09 May 2016 20:51

mirek wrote on Mon, 09 May 2016 17:25

I perhaps could generate complete 'classic' tarball.

I understand that it is a branch, but I think it could still be present in the tarball as a "fallback" for older systems. It would also be simpler for the users, because having two tarballs requires explaining them in great detail which one they should use...
Honza

Not sure. For starters, it will complicate the tarball. Either I will have to include both source trees, or invent some patching.

I really would like to keep 'classic' as separate thing. Like gtk2-gtk3, KDE4/5 etc.. Those are not coming in single tarball, right?

I'm still getting crashes with the new core and mingw x64 (tdm-gcc 5.1). My app is crashing in Optimal and Size configurations. It is crashing with and without SSE2 flag. BLITZ is disabled, precompiled headers are enabled. x86 configuration seems to be fine.

Interestingly, cc1plus.exe is crashing when I'm trying to compile Optimal with debug info

Update: I've checked mingw 5.3.0 x64 Optimal with debug info. I can get a call stack. It is crashing in Upp::Rect_<int>::Rect_, which is inside of Upp::Ctrl::CtrlPaint.

Thanks.

For years, there is a superior alternative in Core, HttpRequest. It can handle much more of http and is (if needed) async.

		while (!shutdown)
		{
			if (server->IsError())
			{
				server.Clear();
				server.Create().Listen(answerPort,100);
				Sleep(200);
			}
			TcpSocket socket;
			socket.Timeout(2000);
			if (!socket.Accept(*server))
			{
				Sleep(50);
				continue;
			}
			
			HttpHeader http;
			http.Read(socket);
			int len = static_cast<int>(http.GetContentLength());
			if (len > 0)
				socket.GetAll(len);
			
			HttpQuery query(http.GetURI());
			
			String rq = query.GetString("RQ"); // this is where HttpQuery is actually used
		
			if (rq == "REQ1")
			{
			}
			else if (rq == "REQ2")
			{
			}
			else if (rq == "REQ3")
			{
			}
...

Weird. That is the place it was always crashing, before I have fixed it with 'finetuning' -O options.

Are you using "Instant setup" default options?

Mirek

I've been slightly reluctant with the changes since I'm suing an older compiler.

And while I'm not sure I'll switch over to the new core, I'm done with the old compiler. In some micro benchmarks with VS2010, my code runs 4 times slower than with MINGW with 100000 iterations.

So I'm done with VS2010 .

And a question: I can fully understand the 16 bit alignment for allocation and I've used a lot in the past SSE, so this is a good move.

But why make the smallest allocation size 32, not 16?

mirek wrote on Thu, 12 May 2016 03:09

Weird. That is the place it was always crashing, before I have fixed it with 'finetuning' -O options.

Are you using "Instant setup" default options?

Mirek

No, I was using old -O3 and -Os options.
Replacing -Os with -O2 fixed crashes with Optimal and Size configuration.
I didn't change -O3 to -O2 for the Speed configuration.
I do not understand where you are taking options for the Optimal configuration from. They are not declared explicitly anywhere.

BTW: What about the issue with Arch Linux, did you look at it? I'm totally swamped lately, so I didn't have time to investigate it at all

Honza

Update: if I use WIN32 flag along with GUI and MT, then I get a problem with rc-files. If I just add a -DflagWIN32 common option, then everything compiles, but TheIDE is still linking against Linux libs ...

mirek wrote on Wed, 11 May 2016 19:40

For years, there is a superior alternative in Core, HttpRequest. It can handle much more of http and is (if needed) async.

Yes, I was aware of the HttpRequest alternative. But HttpQuery represented slightly different functionality. It gave a number of useful routines for URL parsing. I used it in http server code to parse URL variables of incoming http request.

		while (!shutdown)
		{
			if (server->IsError())
			{
				server.Clear();
				server.Create().Listen(answerPort,100);
				Sleep(200);
			}
			TcpSocket socket;
			socket.Timeout(2000);
			if (!socket.Accept(*server))
			{
				Sleep(50);
				continue;
			}
			
			HttpHeader http;
			http.Read(socket);
			int len = static_cast<int>(http.GetContentLength());
			if (len > 0)
				socket.GetAll(len);
			
			HttpQuery query(http.GetURI());
			
			String rq = query.GetString("RQ"); // this is where HttpQuery is actually used
		
			if (rq == "REQ1")
			{
			}
			else if (rq == "REQ2")
			{
			}
			else if (rq == "REQ3")
			{
			}
...

void Http::ParseRequest(const char *p)
{
	while(*p) {
		const char *last = p;
		while(*p && *p != '=' && *p != '&')
			p++;
		String key = UrlDecode(last, p);
		if(*p == '=')
			p++;
		last = p;
		while(*p && *p != '&')
			p++;
		if(*key != '.' && *key != '@') {
			if(key.EndsWith("[]")) {
				Value &v = var.GetAdd(key);
				if(v.IsNull())
					v = ValueArray();
				(ValueArray &)v << UrlDecode(last, p);
			}
			else
				var.GetAdd(key) = UrlDecode(last, p);
		}
		if(*p)
			p++;
	}
}

I see.

Well, looks like we need to move this piece of code from Skylark to Core, right?