|
|
|
Home » Community » U++ community news and announcements » U++ 2017 beta
|
|
| Re: U++ 2017 beta [message #47154 is a reply to message #47151] |
Thu, 22 December 2016 20:25   |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Mirek,
mirek wrote on Thu, 22 December 2016 09:25Consider the current nightly build a beta. Only serious bugs will be fixed until the release (planned Jan 2).
Mirek
Thanks for your wonderful hard work, as well as contribution by others.
Somehow I do not see any point to distribute buggy codes in examples or Bazaar.
While you want to declare the nightly as beta, I would suggest to remove or deactivate all example source codes that does not get build. If they do not work, why have them in there? It can appear again if they are fixed by the authors.
As a new comer, I found it disappointing to see on one side that some of the examples provided in the nightly build did not get far enough to compile and on the other side so many complex examples are just missing. (I know that such expectations on an open source unpaid plattform are wrong...)
One of the brilliant aspect of U++ is to have a super fast and comfortable start. However, when a new comer like myself tries to work with the entire different basics of a language put "upside down", then it becomes difficult to catch up in the absence of some complex examples.
After learning to play a bit with Callbacks, I found that that just got depreciated! Grrrr... And then some examples did not get build. Grrrr.
And not many participates in the forum postings. Grrrr....
|
|
|
|
| Re: U++ 2017 beta [message #47155 is a reply to message #47154] |
Thu, 22 December 2016 23:00 |
 |
mirek
Messages: 14175
Registered: November 2005
|
Ultimate Member |
|
|
MrSarup wrote on Thu, 22 December 2016 20:25Hello Mirek,
mirek wrote on Thu, 22 December 2016 09:25Consider the current nightly build a beta. Only serious bugs will be fixed until the release (planned Jan 2).
Mirek
Thanks for your wonderful hard work, as well as contribution by others.
Somehow I do not see any point to distribute buggy codes in examples or Bazaar.
While you want to declare the nightly as beta, I would suggest to remove or deactivate all example source codes that does not get build. If they do not work, why have them in there? It can appear again if they are fixed by the authors.
All examples are test-build each night (I mean stuff from 'example' and 'reference' folders/nests) and current test-suite does not show any problems. If there are any of them that do not build, please let me know, it must be some interesting quirk or platform incompatibility. (Please report your platform).
Bazaar is community submitted content, bar is lower. I am unhappy about status of many things there too, but not brave enought to start deleting things...
Quote:
After learning to play a bit with Callbacks, I found that that just got depreciated! Grrrr... And then some examples did not get build. Grrrr.
Yeah, but replacement is not that different in use. It was more C++11 compatibility issue than concept change. You came at the point when many things had to change, sorry about that.
Mirek
|
|
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47166 is a reply to message #47155] |
Sun, 25 December 2016 08:02 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Mirek,
Thanks for your answer.
mirek wrote on Thu, 22 December 2016 23:00
All examples are test-build each night (I mean stuff from 'example' and 'reference' folders/nests) and current test-suite does not show any problems. If there are any of them that do not build, please let me know, it must be some interesting quirk or platform incompatibility. (Please report your platform).
Mirek
I am working with U++ on Windows 7 Ultimate 64bits and Centos 7 64bits. Until now, I have build many on my windows workstation and found that some did not complete the build. Most likely they were not under 'example' but one or more under 'reference', however I cannot exactly remember. If this helps, I would be more than happy to execute these one again on my platform and report it here.
mirek wrote on Thu, 22 December 2016 23:00
Bazaar is community submitted content, bar is lower. I am unhappy about status of many things there too, but not brave enough to start deleting things...
Mirek
That is true. How about creating "beta-xxx" in the assembly, or any other connotation in the event if one package fails to be built. If the report is confirmed, then one could - instead of deleting it completely - move it under a beta assembly. For e.g. there is under the assembly:
Bazaar-Stable
Bazaar-Beta-Windows
Bazaar-Beta-Linux
Upon confirmation, that package gets moved under the beta assembly. Upon enhancement, one could bring it back again. Here, one knows exactly what is under beta under a platform and the author needs to work on it.
mirek wrote on Thu, 22 December 2016 23:00
It was more C++11 compatibility issue than concept change.
Mirek
In my other thread, I had problems to build theIDE under Centos 7. This I managed to build somehow.
After built, I found that certain dir and files did not get created under the upp dir but got spread out. For e.g. /root/MyApp/, /root/upp.out/, /root/theide, /root/umk got built/copied/created under /root whereas all other dir/files under /root/upp.
Then, I needed to bring them back all under ---> /root/upp. Thereafter, I have changed the path in all *var files from /root/.upp/theide/*.var for e.g.:
OUTPUT = "/root/upp.out";
to
OUTPUT = "/root/upp/upp.out";
Is this a bug somewhere that it creates some files and dirs outside of /upp installation?
The second thing:
In the GCC.bm and CLANG.bm created, the parameter shows the following:
COMMON_CPP_OPTIONS = "-std=c++0x";
Should it not be focusing on c++11?
|
|
|
|
| Re: U++ 2017 beta [message #47168 is a reply to message #47151] |
Sun, 25 December 2016 09:23 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Mirek,
In my post above, you notice description of errors during compilation. This resulted becaused I made a mistake from the following link here:
http://www.ultimatepp.org/www$uppweb$download$en-us.html
Here, I downloaded 5431 because there is rpm in there! My mistake was not to see the date.
Anyway, the correct URL for Stable release should be the following, which the redirection needs to take in there:
https://sourceforge.net/projects/upp/files/upp/2015.2/
As I use Cento 7, I obviously downloaded from the link given there under "Fedora" and "Stable releases"! Consequently, I have installed "successfully" a version build 5431 prepared in middle ages. After starting to work with gcc, I immediately found this out!
Now I downloaded the nightly build 10577M.
Inside the upp-x11-src-10577M.tar.gz, the upp.spec has a wrong rpmbuild command. This should be as follows:
rpmbuild -tb --define 'version 10577M' --define "date $(LC_TIME=En date '+%a %b %d %Y')" upp-x11-src-10577M.tar.gz
...
#define version 10577M
Do correct this. I do find a lot of relative use of path, which is just a headache. The best is to use absolute path that could be substituted. Define once and generate with absolute parameters, instead of relative path.
After this, i.e. executing the above command for rpmbuild in bold, I could not build or compile theIDE with the above command. This is obviously the equivalent of a sequence of entering in the untarred dir and executing make from there.
On Centos 7 64bits, the version 10577M may not get build (or on any linux for that matter) because it is not ready yet. Or there is something that I am still missing or not doing the right thing. Following are the errors:
mkdir -p /root/rpmbuild/BUILD/upp-x11-src-10577M/out/plugin/bmp//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Mt-Posix-Shared/
mkdir -p /root/rpmbuild/BUILD/upp-x11-src-10577M/out/RichText//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Mt-Posix-Shared/
mkdir -p /root/rpmbuild/BUILD/upp-x11-src-10577M/out/plugin/png//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Mt-Posix-Shared/
c++ -c -x c++ -O3 -ffunction-sections -fdata-sections -std=c++0x -I. -pthread -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/harfbuzz -DflagGUI -DflagMT -DflagGCC -DflagSHARED -DflagLINUX -DflagPOSIX -DflagMAIN ide/BaseDlg.cpp -o /root/rpmbuild/BUILD/upp-x11-src-10577M/out/ide//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Main-Mt-Posix-Shared/BaseDlg.o
In file included from ./Core/Core.h:329:0,
from ./Esc/Esc.h:4,
from ./ide/Core/Core.h:4,
from ./ide/Common/Common.h:4,
from ide/ide.h:4,
from ide/BaseDlg.cpp:1:
./Core/Map.hpp: In member function 'void Upp::Index<T>::Sweep()':
./Core/Map.hpp:268:8: error: call of overloaded 'Sort(Upp::Vector<int>&)' is ambiguous
Sort(b);
^
./Core/Map.hpp:268:8: note: candidates are:
In file included from ./Core/Core.h:269:0,
from ./Esc/Esc.h:4,
from ./ide/Core/Core.h:4,
from ./ide/Common/Common.h:4,
from ide/ide.h:4,
from ide/BaseDlg.cpp:1:
./Core/Sort.h:119:6: note: void Upp::Sort(Range&) [with Range = Upp::Vector<int>]
void Sort(Range& c)
^
./Core/Sort.h:125:6: note: void Upp::Sort(Range&&) [with Range = Upp::Vector<int>&]
void Sort(Range&& c) { Sort(c); }
^
In file included from ./Core/Core.h:329:0,
from ./Esc/Esc.h:4,
from ./ide/Core/Core.h:4,
from ./ide/Common/Common.h:4,
from ide/ide.h:4,
from ide/BaseDlg.cpp:1:
./Core/Map.hpp: In member function 'void Upp::AMap<K, T, V>::Sweep()':
./Core/Map.hpp:590:8: error: call of overloaded 'Sort(Upp::Vector<int>&)' is ambiguous
Sort(b);
^
./Core/Map.hpp:590:8: note: candidates are:
In file included from ./Core/Core.h:269:0,
from ./Esc/Esc.h:4,
from ./ide/Core/Core.h:4,
from ./ide/Common/Common.h:4,
from ide/ide.h:4,
from ide/BaseDlg.cpp:1:
./Core/Sort.h:119:6: note: void Upp::Sort(Range&) [with Range = Upp::Vector<int>]
void Sort(Range& c)
^
./Core/Sort.h:125:6: note: void Upp::Sort(Range&&) [with Range = Upp::Vector<int>&]
void Sort(Range&& c) { Sort(c); }
^
make: *** [/root/rpmbuild/BUILD/upp-x11-src-10577M/out/ide//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Main-Mt-Posix-Shared/BaseDlg.o] Error 1
make: Leaving directory `/root/rpmbuild/BUILD/upp-x11-src-10577M/uppsrc'
error: Bad exit status from /root/rpmbuild/tmp/rpm-tmp.Bwwh4d (%build)
RPM build errors:
Bad exit status from /root/rpmbuild/tmp/rpm-tmp.Bwwh4d (%build)
[Updated on: Sun, 25 December 2016 09:35] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47175 is a reply to message #47171] |
Sun, 25 December 2016 11:24 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hi Mirek,
mirek wrote on Sun, 25 December 2016 09:52
Personally, I would prefer removing .spec file altogether.
.rpm based distros are Spanish village for me. IMO, our responsibility for nightly builds / releases should stop at producing tarball with makefile which builds (perhaps after some package installs) on any most targets. Platform specific packages should be out of ultimatepp.org responsibility...
There are too many target platforms to maintain directly...
Mirek
May be you did not see different possibility of using cross-platform FPM packages for distribution of source code.
Thus, I - as I disagree with you - have opened a seperate thread here and created a poll:
http://www.ultimatepp.org/forums/index.php?t=msg&goto=47 174&#msg_47174
I am now curious if you give a vote to my idea!
|
|
|
|
| Re: U++ 2017 beta [message #47176 is a reply to message #47151] |
Sun, 25 December 2016 12:18 |
cbpporter
Messages: 1425
Registered: September 2007
|
Ultimate Contributor |
|
|
mirek wrote on Thu, 22 December 2016 10:25It is that time again... Took longer than expected as this ended as the most radical change to U++ in years.
http://www.ultimatepp.org/www$uppweb$Roadmap$en-us.html
Consider the current nightly build a beta. Only serious bugs will be fixed until the release (planned Jan 2).
Mirek
Hi!
And Merry Christmas to you all!
I'm almost back from my hiatus with U++ projects (other urgent tasks came up) and I'm ready for another year of using U++.
But I swear, I won't touch TheIDE ever again if that blasted scroll wheel/loose focus/gain focus bug is not fixed! 
Been complaining about if for at least 5 years. I know, I know, shame on me for not fixing it myself.
Other that that, I gave the beta a whirl on a fresh system. First, I tested without MSC to see if the toolchain package is any good. There is still the issue of 5-10 minute wait for TheIDE to finish search for compilers, only to return with nothing but GCC. I don't know why the registry approach was abandoned. I know it can be finicky and it never worked for some users, but 5 minute wait is too much. But I'm having no problems using registry in my own IDE. I even have the problem that it picked up the ancient MSC8 and naturally nothing won't compile on that.
UWord compiled just fine, but GCC debugged crashed as soon as I hit F5. It works well though for command line apps.
Output mode/target file override is still stored locally in the upp folder and applied to new packages. This makes creating a new package a guaranteed error because it will overwrite a binary from another package. Plus it makes it fiddly to move packages between machines because the path must be set up on each one. This option should be stored in the package and kept isolated form other packages.
Other than that, and the fact that at least 6 classes are forked by me, 2 with bugfixes, the entire project suite compiled and works without a hitch.
Our plan is to use 2017.1 and nighlys exclusively for 2017, so no more backwards compatibility and C++1x issues.
|
|
|
|
| Re: U++ 2017 beta [message #47186 is a reply to message #47166] |
Sun, 25 December 2016 21:29 |
 |
Klugier
Messages: 1088
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
MrSarup wrote on Sun, 25 December 2016 08:02Hello Mirek,
The second thing:
In the GCC.bm and CLANG.bm created, the parameter shows the following:
COMMON_CPP_OPTIONS = "-std=c++0x";
Should it not be focusing on c++11?
Hello MrSarup,
I pushed patch for this issue - can you check tomorrow with nightly builds (It should be package overnight).
Sincerely and thanks for reporting,
Klugier
U++ - one framework to rule them all.
[Updated on: Sun, 25 December 2016 21:32] Report message to a moderator |
|
|
|
|
|
| Re: U++ 2017 beta [message #47194 is a reply to message #47151] |
Wed, 28 December 2016 13:01 |
cbpporter
Messages: 1425
Registered: September 2007
|
Ultimate Contributor |
|
|
My review of the beta continues...
So one of the test cases (we use UT a lot) crashes with MINGW. MINGW is more clunky than MSC, but tends to be correct, so I have faith that it is something on our side that can be fixed.
But in the meantime, I installed MSC to see how it fares, since while MINGW compiles well, there is case of GDB crashing and one of a testcase crashing.
I have no idea what MSC you use for the "new" Core, the site is weirdly scarce on info on this (no new comer shall ever find it), but I have used Visual Studio 2015 since I first tried the new C++1x port and it works well. The official build method setup also picks it up (after 5 minutes) and mislabels it MSC15 (it is 14, reported this in the past). Visual Studio 2016/MSC15 has been moved back to 2017 and even if it is released in 2017, with bureaucracy an inertia, you can't expect a lot of people to upgrade to it before 2020. So MSC14 should be properly detected. And it is not, because it misses some include paths.
After I fix it by hand, everything works, including the testcases.
After playing around with it for a day or so, it looks good and stable.
On a sidenote, not related to the beta, Xmlize can be ridiculously slow. Here is are some outputs:
Compilation finished in 0.256 seconds. 0.072 seconds (28.162%) spent on update.
Compilation finished in 0.093 seconds. 0.077 seconds (81.781%) spent on update.
That is 0.160 used on up a single line:
for (int i = 0; i < sources.GetCount(); i++) {
ZPackage& pak = *sources[i].Package;
StoreAsXMLFile(pak, "cache", pak.OutPath + "\\cache.xml");
}
The StoreAsXMLFile saves a whooping 36.2 KiB of XML on disk in 0.160 seconds. Anything above 0.010 I find unacceptable, so I think it is time to say goodbye to Xmlize.
So In conclusion:
- The quality of the code in the packages is at its usual high standards and U++ is a great library
- installing and ease of getting started is at the same all time low it has been for a year now
- MINGW will never be good until Mirek switches over to it fully for at least 2 months, not touching MSC in this period.
|
|
|
|
| Re: U++ 2017 beta [message #47195 is a reply to message #47194] |
Wed, 28 December 2016 13:31 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello cbpporter,
cbpporter wrote on Wed, 28 December 2016 13:01
My review of the beta continues...
...
So In conclusion:
- The quality of the code in the packages is at its usual high standards and U++ is a great library
- installing and ease of getting started is at the same all time low it has been for a year now
- MINGW will never be good until Mirek switches over to it fully for at least 2 months, not touching MSC in this period.
My review of the community of U++ continues...
I concluded the U++ community is in beta. Thus, I received little support from the community.
Whatever the little support I have received, I would like to draw your attention to my postings here because it related to the compatibility issue you have addressed in your above post:
http://www.ultimatepp.org/forums/index.php?t=msg&th=9820 &start=0&
Of course, it relates to Linux with Centos and Fedora flavor. So, our conclusion - as a new comer - about the U++ is:
- DO NOT USE U++ UNTIL IT IS FULLY COMPATIBLE WITH GCC ON LINUX!
Hello Mirek,
I have failed to grasp the intention of developers on launching and maintaining this beautiful project while leaving a very fundamental issue of installation and ease of working with it aside.
It appears to me that developers have really not paid much attention on other platform other than windows + android.
While it works like charm on windows, it does not work as easy on other platform. The Era of Bill's Monopoly is gone. We live in a cross-platform world today. My suggestion to developers for further development:
- Maintain the beta status further until the cross-platform compatibility is achieved!
- Freeze everything of what is there TODAY!
- Work on CROSS PLATFORM CONCEPT FIRST. By making compatible on every platform, provide a much better installer for other platforms, line Centos, Fedora and assure that users could very easily install, compile and re-use examples.
- Assure that a user has - from install to compile - least headache, at least for new comers.
- Learn on how to make packages in an efficient matter and provide binary distribution with technologies like FPM.
Have nice holidays ....
|
|
|
|
|
|
| Re: U++ 2017 beta [message #47202 is a reply to message #47197] |
Wed, 28 December 2016 19:40 |
cbpporter
Messages: 1425
Registered: September 2007
|
Ultimate Contributor |
|
|
Here are numbers on a very stable release we have with a very stable reference test case:
Compilation finished in 0.034 seconds. 0.029 seconds (85.010%) spent on update.
This is without any serialization.
Compilation finished in 0.043 seconds. 0.030 seconds (66.361%) spent on update.
This is with serialization.
Compilation finished in 0.052 seconds. 0.031 seconds (59.647%) spent on update.
This is with Xmlize.
Even Serialize adds 10ms for writing out 3.7 KiB of data. I need to do a very comprehensive benchmark on all this.
mirek wrote on Wed, 28 December 2016 17:53Quote:
- Work on CROSS PLATFORM CONCEPT FIRST. By making compatible on every platform, provide a much better installer for other platforms, line Centos, Fedora and assure that users could very easily install, compile and re-use examples.
What do you mean by 'every platform'?
There are thousands of distros, with small differences in packaging everywhere.
I believe that the original status where we provide compilable tarball was OK. It should not be our 'release' responsibility to provide binary packages for 'every platform' for the release.
I guess that if you would have originally downloaded nightly tarball, ignored .spec file, just did make and fixed dependencies (install missing packages), your experience would have been much better.
Mirek
I think MrSarup is a bit harsh.
I tried to release software under Linux recently and I think it is near impossible. The Linux world has taken every single sound software distribution principle (except for OSS, which I like and agree with) and has thrown it out of the window. You literally can't develop for Linux. Period. You need to OSS it and pass on the responsibility to platform specific packagers.
And even then the solution is sub par. I have a 64bit Linux. You have a 64bit Linux. I compiled for a 64bit Linux a simple unambitious program 5 years ago. It does not work today. Somebody needs to fix Linux. Part of the far future of our project is fixing Linux, at it involves inventing a new .so format with JIT compilation and version control.
But how about Windows? I compiled 10 years ago some programs. They still run fine.
U++ used to work out of the box.
Now it is very hard to get to work. This needs to be fixed ASAP. You can obviously make it run, so share with us your secret.
MSC14 + some hand picked MINGW should work out of the box.
MSC14 is the only non beta platform that can compile U++. It should be detected instantly and without fault. GDB should not crash on UWord.
There should be clear installation instruction on the site. With a section for common GOTCHAS!
U++ has always had excellent quality in its main components but it was always a hard sell. A bit small. Now widely used. A bit weird. Suffering from a lot of NotInventedHere TM. But the U++ fans like me and all the people on the forum stuck around because of the quality, despite some of the cons. But it was easy to get into. No hassle, no installers. Just drop a ZIP somewhere and it worked. Configurable and hackable. You had the security that you can get it to work.
The new package just doesn't work. When the C++1x rewrite first came, for like 3 months I couldn't use it. I had to use the old versions. Not that I mind, but still. Back then the main site pointed you to a download for a MSC that installed version 6.0 of the libraries. Fully not C++1x compatible of course, since I've been using 8.0 for years now.
Like I detailed in my two posts, all you get is a clunky MINGW version with crashes and a "good luck, but it won't work unless you know exactly which version of MSC installs what where and you create your custom build methods" version.
Nobody will wait around 5 minutes for a setup more than once if the setup quits with no result or it detects something and it doesn't work. Like the beta today. The 5 minute search needs to be optional. Registry instant detection needs to come back. Wizards must be added. "Oh, it looks like you have MSC14 installed. Here are the paths. Do you agree?"
Back in the day, with all of its small problems, you had the security that U++ will be around and will work fine for years to come. Now I have a 2 year plan that can be used to phase out U++ if needed if it will ever feel like it is dyeing. Which it certainly felt like when the C++11x period began.
But I want U++ to live and prosper. I want a bigger user base and for it to receive the acclaim it deserves.
And as a first step, little Timmy who can't code hello world, but has a working MSC, should be able to take a 50 MiB package from u++.org, unpack, double click and have access to the entire package, working perfectly. Like it did form 2007? to 2015.
|
|
|
|
| Re: U++ 2017 beta [message #47203 is a reply to message #47202] |
Wed, 28 December 2016 20:53 |
MrSarup
Messages: 30
Registered: December 2016
|
Member |
|
|
Hello Mirek and cbpporter,
Both of you have NOT REALLY CAPTURED the crux of the story, although you understand what I have been talking about. I have used both methods, rpm and make. The question of using either of these methods only relates to building theIDE. But if I do not want to build it, I could simply compile a console application.
No one have told me how to compile a simple console application and which commands I need to use it to compile it UNTIL TODAY! In the other thread of FPM, I requested to the poster to let me know what modules i.e. additional cpp files I need to compile with GCC to make a simple console application of SocketServer from reference.
There are no docs. There is no mention anywhere on the website that gives me this information.
What is then this U++ ideal for, to mislead users like me and let them stand alone? I could not work and cannot work until today. So I give up and move forward. This is a classic example of a new comer, who is either not getting help from docs or community or things does not work fundamentally.
I DO NOT WANT TO USE theIDE on Centos 7 but want to code only console applications. Nothing more. So I do not even need to compile with make or rpm, right? Had I known, that this does not work on Centos 7 at all, then I would have saved 20 hours. I needed to read the website, docs, forums, setups, installs, etc.
-----------------------
Where does it say on the website that the U++ is not working with Centos 7 and Fedora?
Was it tested before at all by someone?
-----------------------
I wasted hours and hours to find out this as a new comer trying to compile a little ServerSocket.cpp on Centos! On windows it worked perfect. Lets see what in ServerSocket.cpp console application: Does U++ have many core modules or functions that A MINI CONSOLE APPLICATION FAILS TO COMPILE or run on Centos/Fedora?
Most likely this IS NOT THE CASE! I suspect that there are functions in the core that may not be needed in there to run a mini console application.
Developers should make some testing on platforms and declare on which platform/version it has been tested. Did the developers know that it is not possible to make a tiny console application on Centos or Fedora?
Currently, I am coding on Laravel PHP Framework. U++ is in principle in the same direction of Laravel Framework on php. They both have similar philosophy. In Laravel, there is composer which works on Mac, windows and Linux. Then, after installing, it does all the work beautifully, like make, make install for php and configure the application or project. It does not have the usual coding techniques and uses its own convention, just like U++ does. This is the reason why Laravel became the best framework. It installs, configures, coding like charm.
However, here I appreciate U++ very much, as I immediately could recognize its quality, and find that U++ will take a long time to increase its user base or grow its community. This will never work, or at least it will take many years of delay.
To solve this, one - as developers - HAS to make sure to release applications that are stable and easy to handle. If this does not work, the sorry is over before it began.
And that's the sad future of U++ I see. I am sorry to take a distance with U++ because the docs are terrible, there are not many examples to handle some complex situations, there is less cross-platform compatibility and the community is tiny.
I remember of making an exe in 2010 on windows. I had intended to make it on Mac too. That did not work. After release, I had heard tons of complains from Mac users.
Cross-platform means that most users should be able to use it on variety of platform. Why would I restrict myself with U++, when I can achieve a users group three times bigger by coding on C++. Here, the story ends if U++ restricts me by imposing Handcuffs of coding techniques.
Then I need to say goodbye to U++. And that's the crux of this story.
So, it is certainly not the question of being harsh. It is the question of usability of a software. If one cannot use it or if the use is difficult, then one cannot use it. As simple.
Apart from that, you will not find many honest ones, who are criticizing so openly like myself, take their time and offer a feedback. I merely take the opportunity to discuss here as I do think that people have not understood certain things and live in their little world surrounded by a tiny community.
I also think that the philosophy of U++ coding is more powerful to have a huge community that what it has achieved until today. The fact that it is extremely powerful and has not progressed so much shows that there needs to be a change somewhere, strategically speaking.
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Dec 21 15:22:04 CET 2024
Total time taken to generate the page: 0.02070 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
