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 » Community » U++ community news and announcements » 2020.2rc1
Re: 2020.2rc1 [message #55118 is a reply to message #55117] Mon, 12 October 2020 10:22 Go to previous messageGo to next message
JeyCi is currently offline  JeyCi
Messages: 50
Registered: July 2020
Member
so, windows 32x is not supported anymore at all - in versions higher than 13664?.. or your answer concerns only v. with mingw compiler?.. (sorry that my question was so concrete about the compiler). and thanks for your reply

Best regards.
Re: 2020.2rc1 [message #55119 is a reply to message #55118] Mon, 12 October 2020 11:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
JeyCi wrote on Mon, 12 October 2020 10:22
so, windows 32x is not supported anymore at all - in versions higher than 13664?.. or your answer concerns only v. with mingw compiler?.. (sorry that my question was so concrete about the compiler). and thanks for your reply


You can produce windows 32-bit applications out of box (in Win64).

You just cannot run development environment on windows 32-bit. I believe that is sooo niche that it is not worth supporting... I do not see any reason why anybody would rather run 32-bit windows instead of 64 on development box.

BTW, chances that your CPU is not 64bit capable are virtually nil and you can upgrade to Win10 64bit for free...

Mirek
Re: 2020.2rc1 [message #55120 is a reply to message #55119] Mon, 12 October 2020 20:10 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
I tried to build Upp in Alpine Linux (the one used by Docker) and got the following error (in Debug):
/home/buildbot/dvlp/cpp/code/upp/git/uppsrc/Core/Util.cpp:49: undefined reference to `backtrace'
/usr/bin/ld: /home/buildbot/dvlp/cpp/code/upp/git/uppsrc/Core/Util.cpp:50: undefined reference to `backtrace_symbols'

The problem can be fixed by adding of
DEBUG_LINK = "-lexecinfo";

to a build method.
But I believe this dependency should be detected automatically.
It would be great to fix that because that will make Upp easier to use with Docker.


Regards,
Novo
Re: 2020.2rc1 [message #55123 is a reply to message #55120] Mon, 12 October 2020 23:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 12 October 2020 20:10
I tried to build Upp in Alpine Linux (the one used by Docker) and got the following error (in Debug):
/home/buildbot/dvlp/cpp/code/upp/git/uppsrc/Core/Util.cpp:49: undefined reference to `backtrace'
/usr/bin/ld: /home/buildbot/dvlp/cpp/code/upp/git/uppsrc/Core/Util.cpp:50: undefined reference to `backtrace_symbols'

The problem can be fixed by adding of
DEBUG_LINK = "-lexecinfo";

to a build method.
But I believe this dependency should be detected automatically.
It would be great to fix that because that will make Upp easier to use with Docker.


Or we can just remove backtrace? I do not rember a single time it helped and this is continuos nuisance on all systems...
Re: 2020.2rc1 [message #55126 is a reply to message #55123] Mon, 12 October 2020 23:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mirek wrote on Mon, 12 October 2020 23:15
Novo wrote on Mon, 12 October 2020 20:10
I tried to build Upp in Alpine Linux (the one used by Docker) and got the following error (in Debug):
/home/buildbot/dvlp/cpp/code/upp/git/uppsrc/Core/Util.cpp:49: undefined reference to `backtrace'
/usr/bin/ld: /home/buildbot/dvlp/cpp/code/upp/git/uppsrc/Core/Util.cpp:50: undefined reference to `backtrace_symbols'

The problem can be fixed by adding of
DEBUG_LINK = "-lexecinfo";

to a build method.
But I believe this dependency should be detected automatically.
It would be great to fix that because that will make Upp easier to use with Docker.


Or we can just remove backtrace? I do not rember a single time it helped and this is continuos nuisance on all systems...


I have put the whole function on #ifdef, so hopefully tomorrow release will be fixed...
Re: 2020.2rc1 [message #55127 is a reply to message #55123] Tue, 13 October 2020 00:21 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
mirek wrote on Mon, 12 October 2020 17:15

Or we can just remove backtrace? I do not rember a single time it helped and this is continuos nuisance on all systems...

I'm personally fine with that.
Your change has fixed the problem.
Thanks!

Ideally it would be great to provide Docker file/files for Upp. People seem to like Docker.


Regards,
Novo
Re: 2020.2rc1 [message #55130 is a reply to message #55127] Tue, 13 October 2020 00:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 13 October 2020 00:21
mirek wrote on Mon, 12 October 2020 17:15

Or we can just remove backtrace? I do not rember a single time it helped and this is continuos nuisance on all systems...

I'm personally fine with that.
Your change has fixed the problem.
Thanks!

Ideally it would be great to provide Docker file/files for Upp. People seem to like Docker.


I am in if you will provide me with some "seed" docker (so that I can automate it later). But not for this release.

Mirek
Re: 2020.2rc1 [message #55131 is a reply to message #55126] Tue, 13 October 2020 02:22 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
mirek wrote on Mon, 12 October 2020 17:46

I have put the whole function on #ifdef, so hopefully tomorrow release will be fixed...

You also need to do the same thing to the code below
#if defined(PLATFORM_POSIX) && defined(COMPILER_GCC) && !defined(PLATFORM_ANDROID)
# include <execinfo.h>
# include <cxxabi.h>
#endif


execinfo.h is not available by default in Alpine Linux.


Regards,
Novo
Re: 2020.2rc1 [message #55133 is a reply to message #55131] Tue, 13 October 2020 09:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 13 October 2020 02:22
mirek wrote on Mon, 12 October 2020 17:46

I have put the whole function on #ifdef, so hopefully tomorrow release will be fixed...

You also need to do the same thing to the code below
#if defined(PLATFORM_POSIX) && defined(COMPILER_GCC) && !defined(PLATFORM_ANDROID)
# include <execinfo.h>
# include <cxxabi.h>
#endif


execinfo.h is not available by default in Alpine Linux.


Done. Sorry for missing that, it was late...
Re: 2020.2rc1 [message #55139 is a reply to message #55089] Wed, 14 October 2020 00:26 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Jim,

I manage to reproduce the issue with wrong "MyApps" folder on mac. What is bad is that our 2020.1 release is affected by this issue. We will work on the fix. One more time thanks for reporting!

When the new version of TheIDE will be available you will need to restart assemblies setup (to restore correct assembly path for MyApps). To do it just execute following line in your terminal:
rm -rf ~/.config/u++


Klugier


U++ - one framework to rule them all.

[Updated on: Wed, 14 October 2020 00:28]

Report message to a moderator

Re: 2020.2rc1 [message #55142 is a reply to message #55139] Wed, 14 October 2020 04:02 Go to previous messageGo to next message
jimlef is currently offline  jimlef
Messages: 90
Registered: September 2020
Location: US
Member
Glad I was able to give a little back Smile Thanks for the tip!
Re: 2020.2rc1 [message #55154 is a reply to message #55142] Wed, 14 October 2020 20:52 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Jim,

macOS issue should be solve toomorow. Just clean cache as I suggest in previous post and everything should work correctly. You could now port your new apps on macOS Smile

I found one more issue. Not critical from the stability point of view, but for the general usability for users. A lot of uppsrc package has lack of description. When you add uppsrc dependency to your project you analyze this short description and on this basis you made the decision whenever package fits to your project/package or not.

Here is the screenshot:
index.php?t=getfile&id=6258&private=0

Mirek, do we need package called plugin/zstd_legacy? Seems like something we do not want to have...

Klugier


U++ - one framework to rule them all.

[Updated on: Wed, 14 October 2020 23:32]

Report message to a moderator

Re: 2020.2rc1 [message #55156 is a reply to message #55154] Wed, 14 October 2020 22:22 Go to previous messageGo to next message
jimlef is currently offline  jimlef
Messages: 90
Registered: September 2020
Location: US
Member
Thank you Klugier - will be on the lookout Smile

Edit: Fresh install of U++ on Catalina (vm), installed command line tools, ran theide - and found out that .config/u++/theide/MyApps.var needed the MyApps path corrected.
Was set to "/Users/james/MyApps;/Users/james/upp/uppsrc"; out of the box... v. 15251.

[Updated on: Thu, 15 October 2020 09:38]

Report message to a moderator

Re: 2020.2rc1 [message #55165 is a reply to message #55154] Thu, 15 October 2020 11:10 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Wed, 14 October 2020 20:52


Mirek, do we need package called plugin/zstd_legacy? Seems like something we do not want to have...

Klugier


That depends on how much do you want to be U++ stable.

The problem here is that zstd changed the format since I have created the first plugin/zstd. Now if any user did use original plugin/zstd, he has created some files that cannot be uncompressed with the new plugin/zstd. That is the role of zstd_legacy, to support the original format.

Now I strongly suspect that I am the only zstd user and it is likely that removing _legacy would be fine, BUT in principle it is right to keep some form of backward compatibility at all times.

Mirek
Re: 2020.2rc1 [message #55166 is a reply to message #55154] Thu, 15 October 2020 11:11 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Wed, 14 October 2020 20:52

I found one more issue. Not critical from the stability point of view, but for the general usability for users. A lot of uppsrc package has lack of description. When you add uppsrc dependency to your project you analyze this short description and on this basis you made the decision whenever package fits to your project/package or not.


I guess the description of most of these should be "Deprecated: do not use in the new code"...

Mirek
Re: 2020.2rc1 [message #55169 is a reply to message #55154] Thu, 15 October 2020 15:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Package description & cleanup & README.md update done...
Re: 2020.2rc1 [message #55175 is a reply to message #55169] Thu, 15 October 2020 18:19 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Mirek,

Thanks for applying all these fixes and adding descrption. I think we are much more closer to 2020.2 release... I hope it will be the best U++ release ever.

Klugier


U++ - one framework to rule them all.
Re: 2020.2rc1 [message #55178 is a reply to message #55175] Thu, 15 October 2020 22:18 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello,

It seems that we have one more problem with template generation. By default in generating CtrlLib and Skylark application there is "using namespace Upp;" clausal in header file, which is wrong for obvious reasons.

Here is app generated with the template:
// ClockApp.h
#ifndef _Clock_Clock_h
#define _Clock_Clock_h

#include <CtrlLib/CtrlLib.h>

using namespace Upp;

#define LAYOUTFILE <Clock/Clock.lay>
#include <CtrlCore/lay.h>

class ClockApp : public WithClockLayout<TopWindow> {
public:
	ClockApp();
};

#endif

// main.cpp
#include "Clock.h"

ClockApp::ClockApp()
{
	CtrlLayout(*this, "Window title");
}

GUI_APP_MAIN
{
	ClockApp().Run();
}


It should be:
// ClockApp.h
#ifndef _Clock_Clock_h
#define _Clock_Clock_h

#include <CtrlLib/CtrlLib.h>

namespace Upp {

#define LAYOUTFILE <Clock/Clock.lay>
#include <CtrlCore/lay.h>

class ClockApp : public WithClockLayout<TopWindow> {
public:
   ClockApp();
};

}

#endif

// main.cpp
#include "ClockApp.h"

using namespace Upp;

ClockApp::ClockApp()
{
	CtrlLayout(*this, "Window title");
}

GUI_APP_MAIN
{
	ClockApp().Run();
}


There is one option I would see there, but this is out of release scope. Upp namespace agnostic template (as option):
// ClockApp.h
#ifndef _Clock_Clock_h
#define _Clock_Clock_h

#include <CtrlLib/CtrlLib.h>

namespace Upp
{
	#define LAYOUTFILE <Clock/Clock.lay>
	#include <CtrlCore/lay.h>
}
	
class ClockApp : public Upp::WithClockLayout<Upp::TopWindow> {
public:
	ClockApp();
};

#endif

// Clock.h
#include "ClockApp.h"

ClockApp::ClockApp()
{
	CtrlLayout(*this, "Window title");
}

GUI_APP_MAIN
{
	ClockApp().Run();
}

This option is the best for advanced users. In almost 90% your app shouldn't belong to Upp namespace. You could mix it easier with other namespaces like std. Only Core elements should belong there, but for simplicity we just put app code there...

In Turtle everything is fine. I think Oblivion fixed it some time ago.


U++ - one framework to rule them all.

[Updated on: Thu, 15 October 2020 22:32]

Report message to a moderator

Re: 2020.2rc1 [message #55179 is a reply to message #55178] Thu, 15 October 2020 22:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Thu, 15 October 2020 22:18
Hello,

It seems that we have one more problem with template generation. By default in generating CtrlLib and Skylark application there is "using namespace Upp;" clausal in header file, which is wrong for obvious reasons.


Which are? If we agreed with everything mainstream, there would be no U++ Smile

Mirek

[Updated on: Fri, 16 October 2020 00:27]

Report message to a moderator

Re: 2020.2rc1 [message #55180 is a reply to message #55179] Fri, 16 October 2020 00:30 Go to previous messageGo to previous message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
The idea is that someday we become mainstream Smile Beside that we could introduce some mainstream things still offering our uniqueness. In such case I do not think this big change in the philosophy or simplicity. I still think that we should keep with the best standards and practices for C/C++ if applicable. So moving in some areas towards mainstream solution is not something that we should afraid of. This will give us broader horizons

Also, we have some mismatch between templates - Tutrlte is using different namespace notaiton to that present in CtrlLib. We should unify this.

In the case of namespace agnostic we should give people choice (by simply checkbox in template). Anyway more and more people people are using this approach. Example is available here.

Anyway, the decision is always yours - you are the boss Smile


U++ - one framework to rule them all.

[Updated on: Fri, 16 October 2020 00:30]

Report message to a moderator

Previous Topic: clang windows -FPIC not supported
Next Topic: 2020.2rc2
Goto Forum:
  


Current Time: Thu Mar 28 23:44:39 CET 2024

Total time taken to generate the page: 0.01152 seconds