|
|
|
Home » Community » U++ community news and announcements » U++ 2017 beta
| Re: U++ 2017 beta [message #47206 is a reply to message #47203] |
Wed, 28 December 2016 23:15   |
 |
Klugier
Messages: 1099
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello,
Dear MrSarup, I would like to thank you for your comments. They mean a lot for us.
To build console application outside TheIDE you need to use utilities called UMK (Ultimate make) that builds ultimate package from terminal. More information about that tool can be found on the following documentation http://www.ultimatepp.org/app$ide$umk$en-us.html. The you can code everything from your vi or emacs. And you cannot build upp packages with plain g++ command right now.
Backing to Fedora and Cent OS - we can have there some problems. Personally, I didn't use that kinds of distribution so bugs can be presented there. Probably, we need there good maintainer, but as you said community is tiny. So, thus ensuring support is hard.
Someone says that finding visual studio from registry was good idea. I agree with that and think that this should be recovered fast. I don't know why we drooped it - it works nice on my configuration. I remembered that Mirek tall something that it doesn't work in some cases. But, as cpborder said we can where user accepts the paths found from registry. However this decision belongs to Mirek.
The next problem I found here is that many persons post that U++ has got bugs with MinGW and gdb. I am aware that at the moment we cannot fixed everything. We do not have many resources - the main developer is Mirek. Sometimes I commit new code for TheIDE - but this is rather hobby than my regular work. So, the code is done when i want to. So, if somebody want to help with development of u++ - we can create more svn account to make thinks faster and give more accounts on redmine. In a word, we need more word class developers to make thinks works better.
The last, but not least is of course money. We cannot work full time on that project. We need to find better ways of financing this project. Maybe I don't know 48 hours e-mail support for fee, advertisements in TheIDE, more aggressive donation campaigning etc. I know that some users may don't like it, but money is important for the further development. We can make discussion about this in another topic.
I relay believe ++ has strong potential - that we should better use. In my opinion the two most important factor is lack of new active developers and money to make current developers more productive. However, even with that problems it is fantastic framework - that is used by many happy users. Mirek dose fantastic job here - at some point of my life he was a relay good mentor for me. At the end I would like to wish you dear U++ all the best in 2017.
Sincerely,
Klugier
U++ - one framework to rule them all.
[Updated on: Wed, 28 December 2016 23:18] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47261 is a reply to message #47257] |
Mon, 02 January 2017 06:09 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Mirek,
HAPPY NEW YEAR TO MIREK AND THE COMMUNITY OF U++.
mirek wrote on Sun, 01 January 2017 22:03OK, so here is the plan for 2017:
Windows:
Here is my wishlist for 2017:
1) INSTALL AND COMPILE SCRIPTS ON CONSOLE
From Linux, we know that there are shell script-installers available. It guides the whole process by choosing numbers. It also detects if certain dependencies are installed and, if not, does the needful. Release an installer that does all the work on console with bash scripts stable.
For e.g. ./umk.sh could offer a menu to choose, if one wants to install or compile. If one chooses compile, it could offer assemblies as choices after reading the local directories. Choosing one of them, it could offer packages to be compiled.
2) DEVELOPING U++ FOR OTHER PLATFORMS
Change the status of U++ to beta UNTIL IT WORKS ON ALL PLATFORM (and do not laugh on this...). Make distribution available that works on all platforms!
3) MAKE COMPLEX EXAMPLES AVAILABLE
It would be helpful to provide examples related to workflows and multiple windows.
In examples, I have not seen (on windows GUI) that multiple windows could be easily created and attached to workflows. However, I could be - as a new comer - wrong.
After server, cloud hosting, virtual machines, etc. technology became popular and stable, so many people use c++ for their applications. U++ can provide an alternative in this area too.
Here, more examples, complex ones, are needed to show this and help an user to begin with. This could include examples of console applications on client and servers, how they could interact with each other with different methods, like SSH, Web sockets, Proxy services, etc.
4) DISTRIBUTION PACKAGES
Amrein-Marie has compiled one rpm and tested on Fedora and Centos. In the spec file, I found that he did several years ago, and thereafter not. Well, now its there, it could be made available on Sourceforge.
Cross-platform packages needs to be used, like FPM or any other such technologies that detects dependencies and does the needful.
I do not agree with Mirek on his idea that the responsibility of a developer ends by providing a tarball. For an overloaded single developer, he is - in fact - right to say this. But no developer group would say this, if they are working as a developers community.
5) EXTENSIVE DOCUMENTATION FOR CROSS-PLATFORM
From the other thread, you could see that there was no documentation on building umk on console. Everything is based on building theIDE on GUI. Thus umk remained under-developed.
-----------------------------
Hello Mindtraveller ,
Mindtraveller wrote on Wed, 28 December 2016 23:12MrSarup wrote on Wed, 28 December 2016 22:53The fact that it is extremely powerful and has not progressed so much shows that there needs to be a change somewhere, strategically speaking.
What exactly do you suggest?
BAN MIREK FROM PARTICIPATING IN THIS FORM! In particular Mirek should not participate in normal postings and spend his time here at the cost of development of U++. Other community members should take this responsibility instead .
Beyond that, my suggestions are above.
One should create an ACTION GROUP to achieve cross-platform quality, where everyone contributes a little so that the sole developer Mirek is not left alone.
Without this, the Usability of U++, on the international platform, is limited. With this understanding of how incompatible U++ on cross-platform is, I question if the time spent on further development is in proportion to its usability.
[Updated on: Mon, 02 January 2017 06:18] Report message to a moderator |
|
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47292 is a reply to message #47257] |
Tue, 03 January 2017 11:21 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
mirek wrote on Sun, 01 January 2017 23:03
- fix include paths issue (if cbpporter will be kind enough to provide info)
I would gladly help, but now, on the first official work day on my main dev machine with 10625 the paths are detected and the build method labeled as MSC14. But this machine worked before, so it should work now.
And if memory serves me correctly, the same paths are detected. I'm starting to suspect that it depends from machine to machine and/or number of MSC versions you have installed and Windows versions. It looks like U++ detected the correct include paths, but the MSC installer did not add all the ucrt or um files there, only some.
Anyway, I'll check the computer I used for the beta review to see the paths.
As for 10625, MSC14 is detected and labelled and works. A fresh install will wait a bit after you click "Accept" until theIDE pops up, just enough to think that it crashed. A simple popup with an oscillating progress bar and "preparing for first launch" would alleviate these problems, but it is not necessary.
Quote:OK, so here is the plan for 2017:
Windows:
- rename MSC15 to MSC14
- return to registry check of MSC. If not found, suggest full directory scan (with prompt first, to avoid long scans).
- update MINGW to the point that debugger works.
- fix include paths issue (if cbpporter will be kind enough to provide info)
Tarballs:
- provide separate 'umk only' make option
- info on using umk to compile
- ? remove .spec ?
- if possible, option to use clang instead of gcc (for distros using buggy 4.8.* GCC)
Looks like a solid plan! U++ code is great right now and except for new features I doubt it has much room to improve (maybe even more move inside the lib?), but do feel free to prove me wrong! 
So the focus should be on usability. Nothing too fancy, but the package should work out of the box in 99% of the cases on Windows. It is a bit of a self defeating process to have a bit site (this is a pretty big site for a project "nobody" uses) that claims up and down the merits and productivity gains with U++ and then you spend 30 minutes getting it to work. Or 1 minute in my case since I know what is wrong since I had to fix it so many times before. I believe you on the site claims, but newcomers will not.
Anyway, as I said before, part of this is my fault. I have little free time and when I have some, once I track down a bug and report it once, the time is all gone and don't have time to keep checking back, making sure it is fixed.
I'll try my best to improve upon this in 2017. I have at least 6 bugs, 2 minor enhancements and one major one that I have to port into each new U++ version, so I hate updating to a new nightly.
Must use a lot of Redmine...
|
|
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47311 is a reply to message #47309] |
Wed, 04 January 2017 01:04 |
 |
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
The previous version has never broke in years! When a snapshot didn't compile, is was because of unmatched gcc or library version or because of source code errors.
To be clear, running 'make' gave the same error.
The difficult part for most people was to run the long rpmbuild command with its parameters. Now it's really easy to use: on all rpm based linux distributions yuu just run 'rpmbuild -ta snapshot.tar.gz'.
On Fedora rpmbuild will automatically use g++ and on other linux distributions it will use clang++ (to prevent the use of gcc < 4.9.0).
I modified the POSIX/X11 installation guide with topic++ so now most people will have their answer without asking in the forum.
In the future, I guess that I will have to revert back to gcc according to new linux distribution versions.
If you still want to remove upp-devel.spec than, well, does it really matter? If it's broken, at least rpm packagers will have something to start from. If you remove it, most people will use the standard 'make' procedure.
Is there a team responsible for U++ packaging? I would like to discuss automatic building on debian and other linux/bsd based distributions.
For example, the 'debian' file in root need to be renamed. Something like 'buildrequires.debian'. This 'debian' file prevents me from building a standard debian package because those packages need to have a debian directory with several files within...
[Updated on: Wed, 04 January 2017 01:12] Report message to a moderator |
|
|
|
| Re: U++ 2017 beta [message #47312 is a reply to message #47311] |
Wed, 04 January 2017 07:28 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Amrein -Marie,
amrein wrote on Wed, 04 January 2017 01:04
If you still want to remove upp-devel.spec than, well, does it really matter? If it's broken, at least rpm packagers will have something to start from. If you remove it, most people will use the standard 'make' procedure.
I must add and support you on your objection to the idea of removing the spec file. Even if Mirek populated the idea of removing the spec file, I dare say so blatantly that this idea is a garbage idea. Perhaps Mirek has not done a lot of activity on different platforms or is less informed about trouble-shooting on other platforms other than the damn Bill's platforms.
For this, I would like to share my experience during build. At the time I started to work on my Centos Server with U++, i.e. to compile it, I could not easily with make.
The dependencies you have listed in the other thread on discussion on my problem, were not sufficient. There was a binary still missing on my server. It did not get identified from the list you mentioned.
Thereafter, I used the spec file. Only then yum package manager could identify all dependencies and compiled it.
Later, you took the daunting challenge to make rpm and provide both, *src.rpm and *rpm. With either of these, I could work with umk.
Without your help, i.e. in the absence of rpms, I had to invest a lot of time and energy. This could be saved in case of all new comers.
The Linux world stopped working with a "tar ball only" approach several decades ago, when the idea of package managers got popular. It appears that this is not understood here. Let's say, will the Linux community announce the following for Centos:
yum -y install upp
No! If not, that idea is garbage!!! As simple. Period.
This is a classic example of the restrictive development process of U++ that centers around Mirek's taste, time, approaches, etc.
The reason is that he is alone, or predominantly working on this project and there are not many active developers available.
Thus, as I suggested above, an action group is necessary to share this work, instead of leaving to his shoulders.
[Updated on: Wed, 04 January 2017 07:39] Report message to a moderator |
|
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47315 is a reply to message #47312] |
Wed, 04 January 2017 08:08 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
MrSarup wrote on Wed, 04 January 2017 08:28
The Linux world stopped working with a "tar ball only" approach several decades ago, when the idea of package managers got popular. It appears that this is not understood here. Let's say, will the Linux community announce the following for Centos:
yum -y install upp
No! If not, that idea is garbage!!! As simple. Period.
This is a classic example of the restrictive development process of U++ that centers around Mirek's taste, time, approaches, etc.
The reason is that he is alone, or predominantly working on this project and there are not many active developers available.
Sorry there, but the must be the most wrong thing I heard all year.
Linux has moved on decades ago but hasn't really made any progress.
Software distribution on Linux is the worst out of all OSes and has always been so. It is baby level super primitive stuff. It is so bad that you CAN NOT do software distribution for Linux as an entire platform. You can't. Nobody can. Not a single developer. It is just that hard.
So people have adapted (instead of fixing Linux) and moved part of responsibility downstream. The developer provides buildable sources for one environment, often using automake and friends to maximize compatibility and completely different people not affiliated with the developer will choose when/if/how to package for their distribution. And if the developer updates, he can't push an update. The external packager chooses to update if he wishes.
Sure, there are exceptions, but in general this is the work-flow. Otherwise, even a hello world application would take you literally months to package. There are over a dozen very popular Linux distros. And over another 50 in somewhat wide use. And hundreds more that are stable. And hundreds more. There are many package formats. For each version even the most common .so can change, so everything needs to built. And even if you packaged for all, some people still expect a tarball or they will call you out for not being OSS enough.
Even if you manage to create a package that works for multiple Linux versions, half of them won't accept it into their repo. You need to set up your custom third party repo or go back to tarballs. So you have to set up an maintain a dozen or more servers. Users need to add the custom repo.
So yeah, software distribution on Linux in near impossible as a developer and this stupid situation happens only on Linux.
The only mistake that U++ does in its distribution of tarballs is not using standard tools and automake. The auto* tools work, but ideologically, they are the worst thing ever. They rely on decades worths of tips and tricks, clever ways to detect Linux differences and do a million things for even the simplest ./configure. And this is bad because you shouldn't have to have such a mammoth of an architecture just to build. Something that needs such effort to build is bad.
Period.
The build system I'm working on right now knows this. It is designed to build arbitrarily complex projects with a short list of folders and a couple compilation options. The entirety of autoconf and friends' wisdom is discarded, not because it is bad, but because it shouldn't be needed. There is configure, make and make install. There is just on command and it works.
I think that maybe umk tried to do something similar.
Oh, and if you think I'm wrong, I dare you to prove it. Spend month trying to find a good method for Linux for my own needs and there is none.
But if you think there is, please show me the link to the standardized no-hassle tool that allows you to package a piece of software once and it will produce one or multiple binary packages capable of working out of the box (and install dependencies) on all of Linux.
|
|
|
|
| Re: U++ 2017 beta [message #47316 is a reply to message #47315] |
Wed, 04 January 2017 08:47 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello cbpporter,
cbpporter wrote on Wed, 04 January 2017 08:08
Oh, and if you think I'm wrong, I dare you to prove it. Spend month trying to find a good method for Linux for my own needs and there is none.
But if you think there is, please show me the link to the standardized no-hassle tool that allows you to package a piece of software once and it will produce one or multiple binary packages capable of working out of the box (and install dependencies) on all of Linux.
Sure, here is the link:
http://http://www.wxwidgets.org/
On the main page it declares the following:
"wxWidgets is a C++ library that lets developers create applications for Windows, Mac OS X, Linux and other platforms with a single code base."
The end product counts! The end result counts!!!
Using wxWidgets with CodeBlocks, I have an instant integration of all c++ features.
I see no reason why I should work on research of what and how U++ distribution needs to be done. There are reasons why U++ did not become popular. Difficulties to install and compile, apart of other things, is one of the many.
As a new comer, I see no reason why I should convince you, or any one else in this community, of what is good and what is bad. I came here to use this excellent source code.
The fact remains unchanged: I could not easily work with it. I am more than sure that I will have hundreds of difficulties later on.
Working now with wxWidgets, I have a support of a normal c++ community everywhere.
Consequently, the problem starts with U++ on every other level. This is a bottleneck, which is embedded within the system of U++, where many things are required by its special quality that needs to be made easy.
And that's not the case. But that's my problem. I need to choose the right open source coding that provides me a good start. After spending many hours, the only thing I could do is compile the theIDE!
What could be more ridiculous that this? My choice was wrong...
I strongly think that we all are wasting our time in making such discussions. If you think everything is right here, then please remain happy and work with it. I think this did not apply to me. The associated factors are just so gigantic that it becomes not worth working further. These factors comes along with, along with the U++ source code, that are not separable.
I should go, even though I loved the approach of U++, a very intelligent one, and find something else to work with.
|
|
|
|
| Re: U++ 2017 beta [message #47317 is a reply to message #47316] |
Wed, 04 January 2017 09:00 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Everyone,
I have unsubscribed from all the threads, including this one. So, you need not continue posting addressing to me, even if you have a reason to do so.
I do not plan to visit this forum anymore or use U++.
|
|
|
|
| Re: U++ 2017 beta [message #47319 is a reply to message #47316] |
Wed, 04 January 2017 10:06 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
MrSarup wrote on Wed, 04 January 2017 09:47
Sure, here is the link:
http://http://www.wxwidgets.org/
What I meant is a tool that takes out the hassle out of building packages for each platform, not an individual package that may or may not have managed to achieve high Linux distribution penetration.
Quote:
On the main page it declares the following:
"wxWidgets is a C++ library that lets developers create applications for Windows, Mac OS X, Linux and other platforms with a single code base."
This is 100% the same for U++. One code base that works out of the box on some platforms (some temporary problems not withstanding), works with minor hassle on a lot more and can be made to work on anything with a C++11x (or normal C++ if you revert to old versions) with a couple of hours of tweaking. At the end of the day, all you need is a C++ compiler and at msot a dozen of dependencies, most of these related to X.
That's all you need.
And yes, this should be improved. U++ is very well supported for *.deb based distros, but even that fails often. Then, you need to take the tarball and run make. And completely necessary and off-putting fact, but after you do this, you have a fully working U++.
Quote:
I see no reason why I should work on research of what and how U++ distribution needs to be done.
I see where you are coming from, but I'm afraid you can't avoid all the hassle since CentOS is not listed on the download page as a supported platform. I'm sure I could get it to work anywhere from 10 minutes to at most 1h if I ever install CentOS, but end users should have to do this.
Quote:
As a new comer, I see no reason why I should convince you, or any one else in this community, of what is good and what is bad. I came here to use this excellent source code.
The fact remains unchanged: I could not easily work with it. I am more than sure that I will have hundreds of difficulties later on.
As said, there are problems. But they are mostly related to the install, building and library location process. After this is done, you are very unlikely to encounter difficulties later, except for:
- GDB integration is not that great, so debugging works but is not the best you have ever seen
- some more rarely used methods from rarely used classes might have minor bugs. These usually get fixed if reported here, or even better on Redmine.
- nightly downloads are very stable, but still not as stable as some releases
Quote:
Consequently, the problem starts with U++ on every other level. This is a bottleneck, which is embedded within the system of U++, where many things are required by its special quality that needs to be made easy.
The only real problem I see is TheIDE. With U++ it is TheIDE or the highway. Or umk. I never wanted or liked using TheIDE, but you kind of have to and I have gotten used to it. Trying to not use it is a major hassle that eventually leads everybody to give up on this endeavor. I'm sure that a lot of the user base, if U++ worked out of the box with Visual Studio, would never boot up TheIDE again.
But at the end of the day, it works. Been using it for who knows how many years now (7+) and it works. I view it as a tax: you want Core and the widgets? Well TheIDE is your tax!
I remember in my old job, we got some senior on one of the U++ projects. Very talented guy and great coder. Didn't want to use use TheIDE, but said he'll use it for a day or two to see what's the deal with the packages and learn the code and the move over to Visual Studio. Soon, he became very angry, cursing TheIDE. I asked what's wrong. He way very explicitly cursing it, saying what kind of an IDE does not have an "Open file" option. He just wanted to open a file to edit it and couldn't do it. I showed him that the option was "Edit file", not "Open file". He never touched TheIDE again, nor U++ or the project.
Quote:
And that's not the case. But that's my problem. I need to choose the right open source coding that provides me a good start. After spending many hours, the only thing I could do is compile the theIDE!
I'm afraid that's on you. Getting TheIDE to compile and work, is the one major obstacle and blocking point. After you can compile that and are willing to use TheIDE, compiling anything becomes trivial. All you need to do is provide it with some include paths and lib references and 99% of the code out there should work.
[Updated on: Wed, 04 January 2017 10:06] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 29 09:26:08 CEST 2025
Total time taken to generate the page: 0.06489 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
