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 » U++ 2017 beta
Re: U++ 2017 beta [message #47206 is a reply to message #47203] Wed, 28 December 2016 23:15 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 478
Registered: September 2012
Location: Poland, Kraków
Senior Member
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


Ultimate++ - one framework to rule them all.

[Updated on: Wed, 28 December 2016 23:18]

Report message to a moderator

Re: U++ 2017 beta [message #47208 is a reply to message #47203] Thu, 29 December 2016 08:44 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 198
Registered: August 2008
Location: France
Experienced Member
Hi MrSarup

We are trying to help you as you can see. Please keep posting into your first thread only. It becomes difficult to follow your issue if you keep posting in every thread.

http:// www.ultimatepp.org/forums/index.php?t=msg&goto=47167& ;#msg_47167

As I said elsewhere, you can compile stable upp source on Centos 7 without error. It's only the last snapshots that won't compile.
Re: U++ 2017 beta [message #47254 is a reply to message #47176] Sun, 01 January 2017 21:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
cbpporter wrote on Sun, 25 December 2016 12:18
mirek wrote on Thu, 22 December 2016 10:25
It 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! Laughing Laughing Laughing


Please, file here or into RM detailed description of the problem (esp. how to reproduce it).
Re: U++ 2017 beta [message #47255 is a reply to message #47194] Sun, 01 January 2017 21:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 28 December 2016 13:01
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.


Please, can you list them so that I can fix it? (It did not miss these last time I have checked).

Quote:

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.


Will gladly look into this after current release... RM issue with perhaps some testing code would help.

Mirek
Re: U++ 2017 beta [message #47257 is a reply to message #47255] Sun, 01 January 2017 22:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
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)

Re: U++ 2017 beta [message #47261 is a reply to message #47257] Mon, 02 January 2017 06:09 Go to previous messageGo to next message
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:03
OK, 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:12
MrSarup wrote on Wed, 28 December 2016 22:53
The 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 #47280 is a reply to message #47257] Mon, 02 January 2017 21:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
mirek wrote on Sun, 01 January 2017 22:03

- rename MSC15 to MSC14

- return to registry check of MSC. If not found, suggest full directory scan (with prompt first, to avoid long scans).


Done in 10625 revision (except for now, it is only registry check).

Mirek
Re: U++ 2017 beta [message #47281 is a reply to message #47261] Mon, 02 January 2017 22:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
MrSarup wrote on Mon, 02 January 2017 06:09

Make distribution available that works on all platforms!


OK, going to garage to fetch my old CP/M machine.

I hope I will be able to make C++11 work on it somehow, maybe if I hack those old tape drives and punching cards to it?
Re: U++ 2017 beta [message #47292 is a reply to message #47257] Tue, 03 January 2017 11:21 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1282
Registered: September 2007
Senior Veteran
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! Smile

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 #47308 is a reply to message #47257] Tue, 03 January 2017 14:22 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 198
Registered: August 2008
Location: France
Experienced Member
Hi mirek

Here is how you could use gcc version in a script:

gcc_version=$(gcc -dumpversion | sed -e 's/\.\([0-9][0-9]\)/\1/g' -e 's/\.\([0-9]\)/0\1/g' -e 's/^[0-9]\{3,4\}$/&00/')

if [ $gcc_version -gt 40900 ]
then
  echo "gcc version $(gcc -dumpversion) is greater than 4.9.0"
else
  echo "gcc version $(gcc -dumpversion) is lower than 4.9.0"
fi


Why should you still dump upp-devel.spec? At present it works out of the box in last snapshots.
Re: U++ 2017 beta [message #47309 is a reply to message #47308] Tue, 03 January 2017 14:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
amrein wrote on Tue, 03 January 2017 14:22

Why should you still dump upp-devel.spec? At present it works out of the box in last snapshots.


That is the catch. It works now, but I am unable/unwilling to maintain it. So once it gets broken (and it will), it will be unnoticed.

I really think that tarball is one thing (one that I am able to maintain) and packages another step...

Mirek
Re: U++ 2017 beta [message #47311 is a reply to message #47309] Wed, 04 January 2017 01:04 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 198
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 Go to previous messageGo to next message
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 #47313 is a reply to message #47312] Wed, 04 January 2017 07:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
MrSarup wrote on Wed, 04 January 2017 07: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:


I believe that you are misguided about this. E.g. by your theory, you should see .rpm packages here:

ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-6.3.0 /

Where are they?

Mirek
Re: U++ 2017 beta [message #47314 is a reply to message #47313] Wed, 04 January 2017 08:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
Mingw64 in Win32 installation updated to the latest version (6.1.0), seems to have fixed gdb issue. Please test!

Mirek
Re: U++ 2017 beta [message #47315 is a reply to message #47312] Wed, 04 January 2017 08:08 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1282
Registered: September 2007
Senior Veteran
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 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1282
Registered: September 2007
Senior Veteran
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

Re: U++ 2017 beta [message #47320 is a reply to message #47319] Wed, 04 January 2017 10:28 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 11167
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 04 January 2017 10:06

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.


Perhaps it is time to do that... I mean, with .icpp problem gone, somebody could try again... Regroup sources to classic .libs should be easy now.

(The only trouble is layout/icon designers, but you can use theide for it, it works with commandline parameters - perhaps even rename the executable to 'upp_designer' or something).
Previous Topic: upp-10502-winxp32-compiled
Next Topic: On-line meeting before 2017 release
Goto Forum:
  


Current Time: Sat Nov 18 11:16:12 CET 2017

Total time taken to generate the page: 0.00976 seconds