|
|
|
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   |
JeyCi
Messages: 67
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 #55120 is a reply to message #55119] |
Mon, 12 October 2020 20:10 |
Novo
Messages: 1430
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 #55127 is a reply to message #55123] |
Tue, 13 October 2020 00:21 |
Novo
Messages: 1430
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 #55131 is a reply to message #55126] |
Tue, 13 October 2020 02:22 |
Novo
Messages: 1430
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 #55139 is a reply to message #55089] |
Wed, 14 October 2020 00:26 |
 |
Klugier
Messages: 1099
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:
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 #55154 is a reply to message #55142] |
Wed, 14 October 2020 20:52 |
|
Klugier
Messages: 1099
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 
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:
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 |
jimlef
Messages: 90
Registered: September 2020
Location: US
|
Member |
|
|
Thank you Klugier - will be on the lookout
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 #55178 is a reply to message #55175] |
Thu, 15 October 2020 22:18 |
|
Klugier
Messages: 1099
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 #55180 is a reply to message #55179] |
Fri, 16 October 2020 00:30 |
|
Klugier
Messages: 1099
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
The idea is that someday we become mainstream 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
U++ - one framework to rule them all.
[Updated on: Fri, 16 October 2020 00:30] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Sun May 11 06:56:05 CEST 2025
Total time taken to generate the page: 0.01110 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
