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?