|
|
Home » Community » U++ community news and announcements » 2022(?).2 beta
|
|
Re: 2022(?).2 beta [message #59263 is a reply to message #59249] |
Thu, 08 December 2022 00:54 |
mr_ped
Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
I'm doing this year Advent of Code with U++ (built from source from github 1.12. so beta-testing it), posting my solutions at github (spoilers alert, if you want to try AoC yourself).
So far everything seems to work for me quite well, I have seen only minor issues.
One very minor issue is strange temporary "freeze" of IDE after closing the terminal with finished run of code in certain situations, the detailed setup:
OS: KDE Neon (KDE5 developer's distribution based on Ubuntu 22.04 LTS with KDE desktop)
IDE config - Console binary: /usr/bin/konsole -e
project: U++ Core CLI, using Cout() to display output.
- when I run the project Ctrl+F5, it opens new terminal, outputs results, the terminal shows "<--- Finished, press [ENTER] to close the window --->"
- then I use mouse to select something from the output, Ctrl+Shift+C to copy it to clipboard, press enter to close the terminal
- the terminal does close (so far all of this is OK), but TheIDE is frozen for 5-10 seconds, not showing cursor, or reacting to clicks, etc..
- then it starts reacting again
If I don't do copy to clipboard, it never happens, when I copy something, it seems to usually freeze, although sometimes it stops doing it for following runs of the code, and does it again after restarting IDE.
It may be also some issue with KDE and clipboard thing, as did notice the OS clipboard sometimes losing content when I close the app from which the content was copied, but in this case it seems the text from Konsole survives, just IDE is stuck on something.
Other minor issue is syntax highlight of C++ numeric literals, I think Mirek did implement the apostrophe digit separator few years back, but now it looks like it does think some char string starts there, see attached image.
I haven't used U++ much in recent years, so my usage is quite "trivial", but so far everything works very well, the new clangd parsing with -std=c++20 works too, I will try to refresh the IDE build few times to not fall behind too much, and try to do a bit more stuff with it and report if I see anything more, so far it looks like solid release ahead.
|
|
|
Re: 2022(?).2 beta [message #59268 is a reply to message #59263] |
Fri, 09 December 2022 09:56 |
|
mirek
Messages: 14059 Registered: November 2005
|
Ultimate Member |
|
|
mr_ped wrote on Thu, 08 December 2022 00:54I'm doing this year Advent of Code with U++ (built from source from github 1.12. so beta-testing it), posting my solutions at github (spoilers alert, if you want to try AoC yourself).
So far everything seems to work for me quite well, I have seen only minor issues.
One very minor issue is strange temporary "freeze" of IDE after closing the terminal with finished run of code in certain situations, the detailed setup:
OS: KDE Neon (KDE5 developer's distribution based on Ubuntu 22.04 LTS with KDE desktop)
IDE config - Console binary: /usr/bin/konsole -e
project: U++ Core CLI, using Cout() to display output.
- when I run the project Ctrl+F5, it opens new terminal, outputs results, the terminal shows "<--- Finished, press [ENTER] to close the window --->"
- then I use mouse to select something from the output, Ctrl+Shift+C to copy it to clipboard, press enter to close the terminal
- the terminal does close (so far all of this is OK), but TheIDE is frozen for 5-10 seconds, not showing cursor, or reacting to clicks, etc..
- then it starts reacting again
This rather feels like gtk / kde interaction error.
X11 clipboard always had problems when the providing application closes before the paste. I guess gtk is trying hard to retrieve data from closed application, then gives up after timeout.
Quote:
It may be also some issue with KDE and clipboard thing, as did notice the OS clipboard sometimes losing content when I close the app from which the content was copied, but in this case it seems the text from Konsole survives, just IDE is stuck on something.
Yep, X11 clipboard....
Quote:
Other minor issue is syntax highlight of C++ numeric literals, I think Mirek did implement the apostrophe digit separator few years back, but now it looks like it does think some char string starts there, see attached image.
Fixed (implemented).
Actually, I did not implemented apostrophe until now. But U++ highlights thousands just fine on its own (try to write 12345678 in theide
Mirek
|
|
|
Re: 2022(?).2 beta [message #59273 is a reply to message #59268] |
Sat, 10 December 2022 19:17 |
Tom1
Messages: 1250 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
Please start typing a floating point constant (e.g. 1.) .. and the code completion starts to look for something to add after the point. Can this behavior be removed?
Best regards,
Tom
|
|
|
|
Re: 2022(?).2 beta [message #59276 is a reply to message #59274] |
Sun, 11 December 2022 19:03 |
Tom1
Messages: 1250 Registered: March 2007
|
Senior Contributor |
|
|
Thanks, Mirek!
Can you fix these warnings for MSBTx64 too:
C:\upp-git\upp.src\uppsrc\Core\Other.h(123): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\Core\Other.h(143): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlLib/DropChoice.h(83): warning C4099: 'Upp::PopUpList::Popup': type name first seen using 'struct' now seen using 'class'
C:\upp-git\upp.src\uppsrc\CtrlLib/DropChoice.h(54): note: see declaration of 'Upp::PopUpList::Popup'
C:\upp-git\upp.src\uppsrc\CtrlCore\ImageWin32.cpp(233): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\ImageWin32.cpp(263): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\ImageWin32.cpp(297): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\ImageWin32.cpp(323): warning C4267: '+=': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\CtrlAttr.cpp(137): warning C4244: 'initializing': conversion from 'Upp::int64' to 'Upp::dword', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\CtrlAttr.cpp(161): warning C4244: 'return': conversion from 'Upp::int64' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\CtrlAttr.cpp(162): warning C4244: 'return': conversion from 'Upp::int64' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\CtrlCore\CtrlDraw.cpp(282): warning C4101: 'q': unreferenced local variable
C:\upp-git\upp.src\uppsrc\CtrlCore\Win32Clip.cpp(412): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data
C:\upp-git\upp.src\uppsrc\Core\Mt.cpp(153): warning C4267: 'argument': conversion from 'size_t' to 'unsigned int', possible loss of data
C:\upp-git\upp.src\uppsrc\Core\Stream.cpp(237): warning C4244: 'initializing': conversion from 'Upp::int64' to 'int', possible loss of data
(BTW: I guess it should be 2022.3 or 2023.1.)
Best regards,
Tom
|
|
|
|
|
|
|
Re: 2022(?).2 beta [message #59281 is a reply to message #59280] |
Sun, 11 December 2022 23:08 |
|
Klugier
Messages: 1083 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek and Lance,
I think we should remove AStyle completely from the TheIDE. The true thing is that there is no true maintainer of that code and it was not updated for years. However, I think we should do it when we will have alternative.
As a replacement to AStyle we should go with clang-format executable. It is bundle with clang tool-chain. So, if you have clang you have clang-format. In the context of utilizing clang-format, we should create our own style basing on the current U++ source files style and make it default. Moreover, user should be able to provide it's own style for the package by adding/defining .clang-format file. So, we will have customization like we currently have. However, it will be moved from UI to text. We could also add some features like reformat code on save etc.
If I will have more time in the next year, I can look at this topic. It's shouldn't be hard to implement.
Klugier
U++ - one framework to rule them all.
[Updated on: Sun, 11 December 2022 23:09] Report message to a moderator
|
|
|
Re: 2022(?).2 beta [message #59283 is a reply to message #59281] |
Mon, 12 December 2022 00:47 |
Lance
Messages: 582 Registered: March 2007
|
Contributor |
|
|
Hello Klugier:
That will be the fastest and safest route (which is taken by many other code editors). I don't see we lose anything, comparing to calling LibFormat directly. I think it's preferable to writing a home-grown formatter as c++ language is changing, albeit slowly. Shifting the duty of keeping up with new standards to a trustworthy, resource-rich third party could save us a lot of effort in the long run.
BR,
Lance
[Updated on: Mon, 12 December 2022 00:49] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sun Oct 13 03:54:43 CEST 2024
Total time taken to generate the page: 0.02951 seconds
|
|
|