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 » 2022(?).2 beta
2022(?).2 beta [message #59249] Sat, 03 December 2022 15:47 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I am running out of issues with Asisst/libclang and the end of year is rapidly closing.

Therefore: Let us designate current nightly as the first beta!

Please report any problems here.

Note: For this release, I have decided to drop MacOS version (too little time to fix everything). I will fix U++ for MacOS in 2023 (including ARM support - that is probably the most significant issue now).

Mirek
Re: 2022(?).2 beta [message #59251 is a reply to message #59249] Sun, 04 December 2022 17:48 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
Edited.
Sorry, I missed a part about MacOS.

./umk uppsrc ide CLANG -bus +GUI,X11 won't compile.


Regards,
Novo

[Updated on: Sun, 04 December 2022 18:41]

Report message to a moderator

Re: 2022(?).2 beta [message #59263 is a reply to message #59249] Thu, 08 December 2022 00:54 Go to previous messageGo to next message
mr_ped is currently offline  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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mr_ped wrote on Thu, 08 December 2022 00:54
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


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 Smile

Mirek
Re: 2022(?).2 beta [message #59273 is a reply to message #59268] Sat, 10 December 2022 19:17 Go to previous messageGo to next message
Tom1
Messages: 1212
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 #59274 is a reply to message #59273] Sat, 10 December 2022 23:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Sat, 10 December 2022 19:17
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


Thanks, hopefully fixed.
Re: 2022(?).2 beta [message #59276 is a reply to message #59274] Sun, 11 December 2022 19:03 Go to previous messageGo to next message
Tom1
Messages: 1212
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 #59277 is a reply to message #59276] Sun, 11 December 2022 19:45 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
Code formatting is not working (properly). Just formatting <CtrlCore/CtrlCore.h> for a demonstration. All bitfield's are formatted in a strange, unpleasant way. And there are more problems than that. After all, the code is quite old.

In the same spirit that U++ embraces libclang, it
's desirable to move code formatting to utilize LibFormat (part of the llvm-project). It should be quite easy for Mirek with his experience integrating libclang.
Re: 2022(?).2 beta [message #59278 is a reply to message #59277] Sun, 11 December 2022 20:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Lance wrote on Sun, 11 December 2022 19:45
Code formatting is not working (properly). Just formatting <CtrlCore/CtrlCore.h> for a demonstration. All bitfield's are formatted in a strange, unpleasant way. And there are more problems than that. After all, the code is quite old.

In the same spirit that U++ embraces libclang, it
's desirable to move code formatting to utilize LibFormat (part of the llvm-project). It should be quite easy for Mirek with his experience integrating libclang.


Do you mean AStyle formattig?

Well, that one I think is broken for years. Code formatting seems to be a simple discipline, probably much easier to do it myself.

LibFormat is probably too hard pill to swallow right now.
Re: 2022(?).2 beta [message #59279 is a reply to message #59278] Sun, 11 December 2022 21:13 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken Sad
Re: 2022(?).2 beta [message #59280 is a reply to message #59279] Sun, 11 December 2022 22:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Lance wrote on Sun, 11 December 2022 21:13
ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken Sad


I can remove it completely for 2022.2, but not replace...
Re: 2022(?).2 beta [message #59281 is a reply to message #59280] Sun, 11 December 2022 23:08 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
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 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
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

Re: 2022(?).2 beta [message #59284 is a reply to message #59280] Mon, 12 December 2022 00:52 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
mirek wrote on Sun, 11 December 2022 16:54
Lance wrote on Sun, 11 December 2022 21:13
ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken Sad


I can remove it completely for 2022.2, but not replace...


Yes, time is too tight. It should be removed as it serves no practical purposes in its current state, other than messing up code.
Re: 2022(?).2 beta [message #59286 is a reply to message #59281] Mon, 12 December 2022 10:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Sun, 11 December 2022 23:08
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.


Quick check: I do not see it in toolchain we are using in Win32.... Sad
Re: 2022(?).2 beta [message #59287 is a reply to message #59249] Mon, 12 December 2022 12:42 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
I have found an interesting bug.
The new assist complained about a lot of weird bugs in my code.
I'm using some external libraries, so I created a new .bm file and used it for compiling.
But it seemed to me, that Assist isn't working based on that .bm file, so I removed all the other .bm files, and renamed my custom one to CLANG.bm.
Everything seems to be working well now.
Re: 2022(?).2 beta [message #59288 is a reply to message #59287] Mon, 12 December 2022 12:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
zsolt wrote on Mon, 12 December 2022 12:42
I have found an interesting bug.
The new assist complained about a lot of weird bugs in my code.
I'm using some external libraries, so I created a new .bm file and used it for compiling.
But it seemed to me, that Assist isn't working based on that .bm file, so I removed all the other .bm files, and renamed my custom one to CLANG.bm.
Everything seems to be working well now.


Currently it is always using include paths from CLANG.bm method. There does not seem an easy solution unfortunately as other includes can be incompatible. But I guess adding include paths from current build method at the end of the list should work (will do ASAP).
Re: 2022(?).2 beta [message #59291 is a reply to message #59288] Mon, 12 December 2022 13:24 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
mirek wrote on Mon, 12 December 2022 12:59

Currently it is always using include paths from CLANG.bm method. There does not seem an easy solution unfortunately as other includes can be incompatible. But I guess adding include paths from current build method at the end of the list should work (will do ASAP).


This seems to me a good idea.
I can not imagine any reason to use an other compiler, than CLANG. I already converted my projects to use that one. Much better toolchain than anything other. Btw, I use MSYS2 and it's Clang toolchain on Windows. The same feeling, as coding on Linux.
And thanks for the tooltips in IDE, showing when holding the mouse pointer over a symbol while editing the source. Extremely useful.
Re: 2022(?).2 beta [message #59298 is a reply to message #59287] Mon, 12 December 2022 22:17 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
zsolt wrote on Mon, 12 December 2022 12:42
I have found an interesting bug.
The new assist complained about a lot of weird bugs in my code.
I'm using some external libraries, so I created a new .bm file and used it for compiling.
But it seemed to me, that Assist isn't working based on that .bm file, so I removed all the other .bm files, and renamed my custom one to CLANG.bm.
Everything seems to be working well now.


I am now adding "real" build method's include paths after CLANG's ones. Hopefully this might fix this issue...
Re: 2022(?).2 beta [message #59299 is a reply to message #59284] Mon, 12 December 2022 22:18 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Lance wrote on Mon, 12 December 2022 00:52
mirek wrote on Sun, 11 December 2022 16:54
Lance wrote on Sun, 11 December 2022 21:13
ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken Sad


I can remove it completely for 2022.2, but not replace...


Yes, time is too tight. It should be removed as it serves no practical purposes in its current state, other than messing up code.


AStyle removed.
Previous Topic: New Assist features
Next Topic: 2022.3rc3
Goto Forum:
  


Current Time: Thu Mar 28 13:44:26 CET 2024

Total time taken to generate the page: 0.01816 seconds