U++ Forum - RDF feed
type: channel
description: Main place for discussions about U++ cross platform development framework.
items: U++ 2017 beta
items: Re: U++ 2017 beta

U++ 2017 beta
type: item
description: 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
creator: mirek
date: 2016-12-22T08:25:46-00:00

Re: U++ 2017 beta
type: item
description: Hello Mirek, mirek wrote on Thu, 22 December 2016 09:25 Consider 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....
creator: MrSarup
date: 2016-12-22T19:25:36-00:00

Re: U++ 2017 beta
type: item
description: MrSarup wrote on Thu, 22 December 2016 20:25 Hello Mirek, mirek wrote on Thu, 22 December 2016 09:25 Consider 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
creator: mirek
date: 2016-12-22T22:00:53-00:00

Re: U++ 2017 beta
type: item
description: Sounds great. All of it.
creator: mr_ped
date: 2016-12-23T03:02:07-00:00

Re: U++ 2017 beta
type: item
description: Thank you Mirek.
creator: koldo
date: 2016-12-23T09:28:14-00:00

Re: U++ 2017 beta
type: item
description: 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,…
creator: MrSarup
date: 2016-12-25T07:02:44-00:00

Re: U++ 2017 beta
type: item
description: 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/p…
creator: MrSarup
date: 2016-12-25T08:23:54-00:00

Re: U++ 2017 beta
type: item
description: Hello Mirek, Regarding the above errors and message, I found following post here: http://www.ultimatepp.org/forums/index.php?t=msg&goto=44 946&#msg_44946 Under Centos 7 64bits, I do not have X11 (except dev package) or KDE installed. It is a simple CLI Linux server that has some basic LAMP functions. From the post above, it does not look like that theIDE is ready to be build on a basic Centos server, or? It would be better to provide installers for Linux versions in shell scripts that does the job. Until this is done, one could get into hundreds of problems. The install shell scripts could be either http://xxx.../linux-upp-stable.sh or http://xxx.../linux-upp-nightly.sh. Then, it will download the right tar ball, check the prequisite dependencies based on the plattform/architecture and install it.
creator: MrSarup
date: 2016-12-25T08:52:45-00:00

Re: U++ 2017 beta
type: item
description: I guess this might be related to this: http://www.ultimatepp.org/forums/index.php?t=msg&th=9818 &start=0& 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
creator: mirek
date: 2016-12-25T08:52:50-00:00

Re: U++ 2017 beta
type: item
description: MrSarup wrote on Sun, 25 December 2016 09:52 Hello Mirek, Regarding the above errors and message, I found following post here: http://www.ultimatepp.org/forums/index.php?t=msg&goto=44 946&#msg_44946 Looks like we have posted at the same moment Quote: From the post above, it does not look like that theIDE is ready to be build on a basic Centos server, or? Well, theide is GUI app - needs X11/GTK. Anyway, maybe there is a bit of misunderstanding about what 'building U++' means. It really just compiles theide and umk. U++ does not create any 'permantent' libraries. Mirek
creator: mirek
date: 2016-12-25T09:02:22-00:00

Re: U++ 2017 beta
type: item
description: 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!
creator: MrSarup
date: 2016-12-25T10:24:13-00:00

Re: U++ 2017 beta
type: item
description: 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! 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 mor…
creator: cbpporter
date: 2016-12-25T11:18:21-00:00

Re: U++ 2017 beta
type: item
description: MrSarup wrote on Sun, 25 December 2016 08:02 Hello 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
creator: Klugier
date: 2016-12-25T20:29:44-00:00

Re: U++ 2017 beta
type: item
description: Hi, Quote: GCC debugged crashed as soon as I hit F5 I think the debugger crash is a gdb bug. I replaced gdb.exe with version 7.12 downloaded from http://www.equation.com/servlet/equation.cmd?fa=gdb, and it works without crash.
creator: omari
date: 2016-12-26T12:36:21-00:00

Re: U++ 2017 beta
type: item
description: 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 Mir…
creator: cbpporter
date: 2016-12-28T12:01:46-00:00

Re: U++ 2017 beta
type: item
description: 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 co…
creator: MrSarup
date: 2016-12-28T12:31:21-00:00

Re: U++ 2017 beta
type: item
description: Quote: - 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
creator: mirek
date: 2016-12-28T15:53:20-00:00

Re: U++ 2017 beta
type: item
description: 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:53 Quote: - 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 i…
creator: cbpporter
date: 2016-12-28T18:40:02-00:00

Re: U++ 2017 beta
type: item
description: 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 cons…
creator: MrSarup
date: 2016-12-28T19:53:37-00:00

Re: U++ 2017 beta
type: item
description: 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?
creator: Mindtraveller
date: 2016-12-28T22:12:44-00:00

Re: U++ 2017 beta
type: item
description: 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 m…
creator: Klugier
date: 2016-12-28T22:15:27-00:00

Re: U++ 2017 beta
type: item
description: 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&amp ;#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.
creator: amrein
date: 2016-12-29T07:44:28-00:00

Re: U++ 2017 beta
type: item
description: 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! Please, file here or into RM detailed description of the problem (esp. how to reproduce it).
creator: mirek
date: 2017-01-01T20:51:00-00:00

Re: U++ 2017 beta
type: item
description: 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
creator: mirek
date: 2017-01-01T20:54:47-00:00

Re: U++ 2017 beta
type: item
description: 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)
creator: mirek
date: 2017-01-01T21:03:05-00:00

Re: U++ 2017 beta
type: item
description: 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 tha…
creator: MrSarup
date: 2017-01-02T05:09:20-00:00

Re: U++ 2017 beta
type: item
description: 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
creator: mirek
date: 2017-01-02T20:42:33-00:00

Re: U++ 2017 beta
type: item
description: 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?
creator: mirek
date: 2017-01-02T21:31:43-00:00

Re: U++ 2017 beta
type: item
description: 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 …
creator: cbpporter
date: 2017-01-03T10:21:46-00:00

Re: U++ 2017 beta
type: item
description: 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.
creator: amrein
date: 2017-01-03T13:22:57-00:00

Re: U++ 2017 beta
type: item
description: 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
creator: mirek
date: 2017-01-03T13:59:31-00:00

Re: U++ 2017 beta
type: item
description: 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...
creator: amrein
date: 2017-01-04T00:04:23-00:00

Re: U++ 2017 beta
type: item
description: 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 …
creator: MrSarup
date: 2017-01-04T06:28:39-00:00

Re: U++ 2017 beta
type: item
description: 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
creator: mirek
date: 2017-01-04T06:59:58-00:00

Re: U++ 2017 beta
type: item
description: Mingw64 in Win32 installation updated to the latest version (6.1.0), seems to have fixed gdb issue. Please test! Mirek
creator: mirek
date: 2017-01-04T07:03:54-00:00

Re: U++ 2017 beta
type: item
description: 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…
creator: cbpporter
date: 2017-01-04T07:08:09-00:00

Re: U++ 2017 beta
type: item
description: 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 m…
creator: MrSarup
date: 2017-01-04T07:47:51-00:00

Re: U++ 2017 beta
type: item
description: 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++.
creator: MrSarup
date: 2017-01-04T08:00:39-00:00

Re: U++ 2017 beta
type: item
description: 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 …
creator: cbpporter
date: 2017-01-04T09:06:05-00:00

Re: U++ 2017 beta
type: item
description: 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).
creator: mirek
date: 2017-01-04T09:28:28-00:00

Re: U++ 2017 beta
type: item
description: mirek wrote on Wed, 04 January 2017 11:28 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). Maybe. A bit too late for that. I think at this stage it is better to improve the debugger. I'm very strapped on time, but I did boot up some 2009 debugger code and it still compiles in TheIDE, so I will do some tests with improving String debugging. Currently, 75% of my debugging time is spent with looking at strings. And in 90% of those times, I need to DUMP that string because the debugger shows me a really long line of useless information, yet it cuts off often the actual string part of the String. The tooltip clips of screen, it has no multiline support and is generally not good. But I'll focus on strings first. Won't have probably time for anything more. Here is a mockup of what I'm thinking: The top one is the current solution: ugly, bad, information overload. I have full trust in U++. I don't need to debug your string implementation. I need to debug my strings. Their content! The bottom one is my mockup. first line, full string, with far greater clipping size. Followed by length. Second line is the rest of the bullshit I don't care about. When debugging bigger classes with multiple fields, the second line should be either put at the end of the first or dropped all together. Oh, and in the case of these classes, if the have few fields, like let's say less then 10, each field should be on its own line. This is just a simple mock-up. I bet if I boot up an old C# project in Visual studio or an old Java project in Eclipse and copy rand…
creator: cbpporter
date: 2017-01-04T10:19:02-00:00

Re: U++ 2017 beta
type: item
description: Hi, Not sure how recent behavior this is, but for some reason: Format("%.2f",1.23); results in 1,23 (with comma) instead of expected 1.23 (with decimal point) when using "GUI MT" in Linux. If I select "GUI MT X11", the result is correctly 1.23 (with decimal point). Can this be fixed before release? If the separators (or date/time formats for that matter) automatically change depending on regional settings used on each computer, reading and writing of various ASCII file formats gets completely out of control. Best regards, Tom
creator: Tom1
date: 2017-01-04T11:32:17-00:00

Re: U++ 2017 beta
type: item
description: Tom1 wrote on Wed, 04 January 2017 12:32 Hi, Not sure how recent behavior this is, but for some reason: Format("%.2f",1.23); results in 1,23 (with comma) instead of expected 1.23 (with decimal point) when using "GUI MT" in Linux. If I select "GUI MT X11", the result is correctly 1.23 (with decimal point). Can this be fixed before release? If the separators (or date/time formats for that matter) automatically change depending on regional settings used on each computer, reading and writing of various ASCII file formats gets completely out of control. Best regards, Tom ".2f" is actually using C lib (see FloatFormatter). Can you check the same with 'printf' or 'sprintf' ? (That said, I can certainly recplace ',' with '.' in FloatFormatter, just to be sure...). Mirek
creator: mirek
date: 2017-01-04T11:38:25-00:00

Re: U++ 2017 beta
type: item
description: Hi, Both Format("%.2f",1.23); and sprintf(text,"%.2f",1.23); use comma as decimal separator when under "GUI MT" in Linux. With "GUI MT X11" both are clean decimal points. In Windows both used decimal points. I never imagined GTK could affect text formatting! Thanks and best regards, Tom
creator: Tom1
date: 2017-01-04T12:20:58-00:00

Re: U++ 2017 beta
type: item
description: Then GTK must be changing your locale with (non-)portable means of setting this in the std c lib.
creator: cbpporter
date: 2017-01-04T13:02:51-00:00

Re: U++ 2017 beta
type: item
description: Tom1 wrote on Wed, 04 January 2017 13:20 Hi, Both Format("%.2f",1.23); and sprintf(text,"%.2f",1.23); use comma as decimal separator when under "GUI MT" in Linux. With "GUI MT X11" both are clean decimal points. In Windows both used decimal points. I never imagined GTK could affect text formatting! Thanks and best regards, Tom OK, so what is the correct resolution here? Mirek
creator: mirek
date: 2017-01-04T13:39:35-00:00

Re: U++ 2017 beta
type: item
description: cbpporter wrote on Wed, 04 January 2017 11:19 But I'll focus on strings first. Won't have probably time for anything more. Here is a mockup of what I'm thinking: Trouble with that is that it requires "special treatment" for String - debugger needs to be aware that you are at String. Frankly, the ideal solution would be calling 'AsString' for values somehow, but that aint so easy unfortunately...
creator: mirek
date: 2017-01-04T13:49:03-00:00

Re: U++ 2017 beta
type: item
description: Hi, @cbpporter: My locale on both Windows and Linux (Mint 18.1) computers is "Language: English, Region: Finland". Numeric formats are under Region, which is Finnish, and surely use comma as decimal separator, but that has never affected my programs on WIN or X11. I do not know how GTK changes the sprintf and Format behavior, but that certainly is annoying and can have severe consequences since the calls to these functions are scattered all around my code in 'million' places. @Mirek: I bet this will divide opinions: My opinion is that I should be able to trust on Format to use decimal point regardless the region. I.e. the way it has always been with WIN and X11. If region compatible Formatting output is desired, that should be addressed through e.g. some "FormatRegional()" API or some optional formatter flags which are disabled by default. For some users it might be nice to have numeric values in dialogs shown with regional separators and display formats, but for writing e.g. CSV files (comma separated values), the regional separators will just introduce a catastrophy. (1,23,2,34,3,45 ...) Even, if list separators were different, the international file transfer would be a disastrous mess with tens of file layouts. -- Is it possible to make U++ on GTK to behave consistently like WIN and X11 do? Best regards, Tom
creator: Tom1
date: 2017-01-04T14:29:57-00:00

Re: U++ 2017 beta
type: item
description: mirek wrote on Wed, 04 January 2017 15:49 cbpporter wrote on Wed, 04 January 2017 11:19 But I'll focus on strings first. Won't have probably time for anything more. Here is a mockup of what I'm thinking: Trouble with that is that it requires "special treatment" for String - debugger needs to be aware that you are at String. Frankly, the ideal solution would be calling 'AsString' for values somehow, but that aint so easy unfortunately... Yeah, that's exactly what I'm doing. Added special logic based on type name. Small price to pay I think for the added benefits. And not just String. A few Core classes should be handled like this too, like Vector, which has abysmal debugging. This isn't 1995 anymore, we can't have it like it is. Plus, the debugger should be aware of a few more other things, like Moveable. Remove all unnecessary information. Think of the most fancy and elegant scripting language possible. Something people love to use and once they start to use it, become extremely loyal to it, like Python or Ruby. Now imagine how streamlined and useful debugging can look in those (there is support for full time run-time reflection and eval). That's what I want in U++. A String shouldn't have len, ptr, s, wptr, w, q and what not. What are even those? I know what they are, but I don't want to. Nobody does! The debug output should be readable for a String by a baby. We can't do stuff like in the scripting languages, but we can hard code the debugger to pretty print a couple of hand picked types if in debug mode and if they have the proper layout. I tested a very early and hack version of this for U++ in 2009, but there was no interest for it. Now I must do it because I can't stand to debug another string where 1/3 of it is cut off so I can have a clear look at the blasted wptr value. Or to debug a vector where I can only look at the first element. Things like this worked in Delphi like 10 years ago. They work perfectly in C#. I don't have C# installed right now on this c…
creator: cbpporter
date: 2017-01-04T14:38:40-00:00

Re: U++ 2017 beta
type: item
description: cbpporter wrote on Wed, 04 January 2017 15:38 mirek wrote on Wed, 04 January 2017 15:49 cbpporter wrote on Wed, 04 January 2017 11:19 But I'll focus on strings first. Won't have probably time for anything more. Here is a mockup of what I'm thinking: Trouble with that is that it requires "special treatment" for String - debugger needs to be aware that you are at String. Frankly, the ideal solution would be calling 'AsString' for values somehow, but that aint so easy unfortunately... Yeah, that's exactly what I'm doing. Added special logic based on type name. Small price to pay I think for the added benefits. And not just String. A few Core classes should be handled like this too, like Vector, which has abysmal debugging. This isn't 1995 anymore, we can't have it like it is. Plus, the debugger should be aware of a few more other things, like Moveable. Remove all unnecessary information. Think of the most fancy and elegant scripting language possible. Something people love to use and once they start to use it, become extremely loyal to it, like Python or Ruby. Now imagine how streamlined and useful debugging can look in those (there is support for full time run-time reflection and eval). That's what I want in U++. A String shouldn't have len, ptr, s, wptr, w, q and what not. What are even those? I know what they are, but I don't want to. Nobody does! The debug output should be readable for a String by a baby. We can't do stuff like in the scripting languages, but we can hard code the debugger to pretty print a couple of hand picked types if in debug mode and if they have the proper layout. Been there - that is what micio with MI2 debugger was trying. For me, it was never really usable. But maybe you will have a better luck
creator: mirek
date: 2017-01-04T14:47:47-00:00

Re: U++ 2017 beta
type: item
description: cbpporter wrote on Wed, 04 January 2017 10:06 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. Hello cbpporter, Good catch - "Edit file" is now called "Open file". Sincerely, Klugier
creator: Klugier
date: 2017-01-04T21:32:37-00:00

Re: U++ 2017 beta
type: item
description: About decimal comma. Well, in Java world you should always provide also the Locale to be used by the formatter. So then you do thing like str = Format(Locale.US, "%.2f", value) when you are exporting data for machine, or you call with other (none=default) to get formatting for human output, which can include also things like thousands separator/etc (and is not suitable for machine export/import). Tom1: BTW, if your OS (GTK) is set to ",", then it sort of does what it should, and I would rather like to see introduction of this Java-like "provide target Locale" logic, than some hardcoded hacks to get "." every time. As when you want to format numbers for your human users, you should follow their OS settings. I do believe that you can set locale to the "C" even in your source even now (maybe at the start of application, if you don't want to format outputs with default OS settings), to get the printf behaviour with dot. Too lazy to google for some example, sorry.
creator: mr_ped
date: 2017-01-05T04:01:37-00:00

Re: U++ 2017 beta
type: item
description: mr_ped wrote on Thu, 05 January 2017 05:01 About decimal comma. Well, in Java world you should always provide also the Locale to be used by the formatter. So then you do thing like str = Format(Locale.US, "%.2f", value) when you are exporting data for machine, or you call with other (none=default) to get formatting for human output, which can include also things like thousands separator/etc (and is not suitable for machine export/import). Actually, that is in U++ for ages: String Format(int language, const char *fmt, __List##I(E__NFValue)); Only you have to use U++ formatters instead of C ones... Mirek
creator: mirek
date: 2017-01-05T07:20:28-00:00

Re: U++ 2017 beta
type: item
description: Klugier wrote on Wed, 04 January 2017 22:32 cbpporter wrote on Wed, 04 January 2017 10:06 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. Hello cbpporter, Good catch - "Edit file" is now called "Open file". Sincerely, Klugier Sorry, but reverted. Creates the wrong impression that we are somehow 'opening/editing/saving/closing' files, which is not true. Mirek
creator: mirek
date: 2017-01-05T07:23:36-00:00

Re: U++ 2017 beta
type: item
description: Tom1 wrote on Wed, 04 January 2017 15:29 @Mirek: I bet this will divide opinions: My opinion is that I should be able to trust on Format to use decimal point regardless the region. I.e. the way it has always been with WIN and X11. If region compatible Formatting output is desired, that should be addressed through e.g. some "FormatRegional()" API or some optional formatter flags which are disabled by default. Commited, please check! Mirek
creator: mirek
date: 2017-01-05T07:38:00-00:00

Re: U++ 2017 beta
type: item
description: Hi Mirek, Now Format() works on GTK like on Windows and X11. (Note to other readers: sprintf and Sprintf still follow the GTK locale for decimal separator, which is not consistent with Windows/X11 behavior.) Thanks and best regards, Tom
creator: Tom1
date: 2017-01-05T08:17:51-00:00