Replies: 43 comments 59 replies
-
|
The v2 branch has been created. We'll be using the git-flow model to bring v1.x work into v2 on a periodic basis as progress is made. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: If not already, have a look at Turbo Vision - a very comprehensive and popular Terminal GUI framework developed by Borland over 30 years ago. You may get some good ideas from there. |
Beta Was this translation helpful? Give feedback.
-
Tenets for v2 (Unless you know better ones)
Please feel free to suggest other tenets or modifications to those above. I'll keep this post updated with the latest input. |
Beta Was this translation helpful? Give feedback.
-
Themes for v2
These are my (tig's) interpretation of what people want to see in v2. I'm putting these here to cause debate and discussion. So please share your thoughts! I'll keep this post updated as the discussion progresses... |
Beta Was this translation helpful? Give feedback.
-
|
Added to "Themes for v2"
|
Beta Was this translation helpful? Give feedback.
-
|
Team (esp @BDisp, @tznind , and @migueldeicaza ): I have a thought. It may not be well formed, but i'd like to express it and get your input: We have several new, compelling, features currently targetting pre-v2:
In building ComfiguraitonManager, several times I wanted to leverage new C# and dotnet features (e.g. NRT, c# v9 features, etc...). But I couldn't because they would cause breaking changes to the existing API. @BDisp really wants to add NRT support for CheckBox, but that will be a breaking API change. My idea is this:
Why? Because one of the challenges with moving to a v2 with breaking API cahnges is getting people to adopt it and "move on". By ensuring v2.x has new, exciting functionality that is not in v1.x, we can encourage app developers to move to v2.x. The argument against, this idea, of course, is these new features (except maybe TrueColor) really need breaking API changes, so why not put them in v1.x and then move them to v2? My counter to this is: we have limited resources and energy. What do you all think? |
Beta Was this translation helpful? Give feedback.
-
I completely agree with you. Maintaining the v1.x and v2 is very effort if some fix in the v2 aren't compatible with the v1.x and have to make workarounds to fix it. Personally I won't fixed any to the v1.x. Represents a lot of effort and wasted time that can be used for new features and improvements for future versions. |
Beta Was this translation helpful? Give feedback.
-
|
I'm on board with this approach. What are the breaking changes so far? I think the secret to success in major version updates is avoiding unessesary breaking changes, being very transparent about the nature and number of them (and rationale). And provide clear docs on how to change your code so it is compatible with the new version. |
Beta Was this translation helpful? Give feedback.
-
|
RE: Breaking changes - see how just a simple nullable change like @BDisp did with #2313 requires changes pretty much everywhere. I am skeptical we can do v2 and support nullable deeply without requiring almost all code that uses Terminal.Gui to be impacted. Am I wrong? |
Beta Was this translation helpful? Give feedback.
-
If the changelog is clear about the reason for the change and the codefix is clearly described and easy to implement then big changes are ok. I am happy to collate these and format them like the following example (see below). And it is a good sanity check that breaking changes are actually delivering value and not just for the sake of it. For example: Breaking Changes in 2.0Checked now nullableTo support Indeterminate check states, the - bool something = myCheckBox.Checked;
+ bool something = myCheckBox.Checked ?? false;The Additionally any event handlers for the - private void MyCheckBox_Toggled (bool oldState)
+ private void MyCheckBox_Toggled (bool? oldState) |
Beta Was this translation helpful? Give feedback.
-
|
We can try to get this time them separated with the v1.x and v2 (here with the changelog with the necessary information about how to handle with the new changes). If that doesn't work well then we pass to work only with the v2. What do you think? |
Beta Was this translation helpful? Give feedback.
-
One question. Having them separated with the v1.x and v2 imply that will exist two nuget packages but with the same project name, right? If is this the case I choose this option. If there are fixes for the v2 that are compatible with the v1.x, they are merged to both, otherwise only the v2 is merged with change log that isn't compatible with the v1.x. Thus, everyone who wants to improve their app with bug fixes, improvements and new features, have to switch to the v2. |
Beta Was this translation helpful? Give feedback.
-
@tznind What do you think is the best way for us to collate and document all the v2 breaking changes?
|
Beta Was this translation helpful? Give feedback.
-
|
I think a Discussion page is probably best. We can post each significant breaking change as an answer along with an example of how to update existing code. The discussion format doesn't require any access permissions changes and it allows other GitHub users to reply if they don't understand the fixes. |
Beta Was this translation helpful? Give feedback.
-
|
In terms of maintaining the v1 library, I think there are several choices:
I wonder if 3) is realistic. It certainly is interesting. I wonder if just a new |
Beta Was this translation helpful? Give feedback.
-
As @tznind said, for sure will require a new nuget package because the project name is different. Also users know more the Terminal.Gui as the project name and they may be confused. I think
Personally I think this is more maintainable, because only the fixes, improvements and new features that are compatible with v1 are merged into it. So the possibility to have the same project name but only with different version, is better I think. For sure that may arrive the day that will be impossible to improve the v1 and thus it must be unchangeable or ended.
Well only about thinking about the possibility of changing |
Beta Was this translation helpful? Give feedback.
-
|
Here is a practical proposal for moving forward with v1 (that may feel painful). See this for context: tig#10 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
@tig I agree with all you said but not about revert to 1.9 tag. I thing it's more accurate you publish the current develop branch as is and merge to main, maybe 1.91 tag. Create the new v1_develop branch based on the 1.91 to target the v1.10 and all the pendents PR to the develop will be closed to being creating new PR's to submit to the v1_develop. After all this then the v2_develop must always be merged with the v1_develop, if compatible, until the v2 is declared as finished. |
Beta Was this translation helpful? Give feedback.
-
The next Why do you think we should not revert to v1.9 and then cherry pick key fixes for v1.10? What Issues have been fixed in |
Beta Was this translation helpful? Give feedback.
-
I disagree with this. I do not think it will be possible because v2 is going to (has already) significantly diverge from v1 and merging will be very, very hard. I also don't think it's the right thing to do because the whole point of v2 is to move forward with new things, leaving v1 behind. I think the rule should be:
|
Beta Was this translation helpful? Give feedback.
-
Ah ok, my bad, otherwise it will be 3 versions, sorry.
Sorry, I now understand this, you mean the v1_develop will have the 1.9 only forward and none backward, being cleaning, great. There is nothing very important that can go for the v1, so go ahead please. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to try using Github's Project capabilities to manage what and when we work on for v2. See here: https://github.com/orgs/gui-cs/projects/1/views/1 Take a look and let me know what you think of what's in there so far. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder what .Net version will be the main target of v2. Sorry if I missed it. I personally feel like it's time to say goodbye to NetFW. Especially when modern .Net has so much stuff, both quality of life and performance. If v2 is going to have solid breaking changes that will hake transition hard then it might be a good thing to move on with .Net too and target current lts (.Net 6) On the other hand if majority of users are .NetFW users then there is nothing to be done I guess. As a side note for nrt - technically only annotating reference types to be Nullable or not Nullable is not a breaking change. People can opt in to NRT or just disable it altogether. Making struct Nullable is another thing because it's a binary breaking change: there was some type of T, now it's Nullable of T. So as long as you have compiler recognized attributes you can even target ns2, netfw4.8, etc. Same goes with other compiler features that use attributes as a mean of adding context One thing I can wish for in goals is to simplify creation of custom views/components. To me it feels quite hard especially when comparing to modern html/css where you just splat some attributes and handlers and voila - you have a custom component. I wonder if something can be done here to make this kind of stuff easier. |
Beta Was this translation helpful? Give feedback.
-
I went with the min version that supported the feature I wanted to use (I don't recall what that was). But you are correct, I think it us wanting to match.
Check out the new |
Beta Was this translation helpful? Give feedback.
-
To see what Line Canvas can do, check out the snake scenario 🐍: I also agree this primative drawing stuff needs to be as accessible as possible to new programmers. One of the reasons I kept as much of
|
Beta Was this translation helpful? Give feedback.
-
|
I would like to use this project for my PowerShell TUI applications however it would be nice if it targeted In my projects I usually target |
Beta Was this translation helpful? Give feedback.
-
|
Even with the DefaultsThe compiler determines a default based on these rules:
|
Beta Was this translation helpful? Give feedback.
-
|
@BDisp are you sure that is accurate? The table and document you reference is the default language version if none is specified. You can override that value by using |
Beta Was this translation helpful? Give feedback.
-
|
Tracking to this discussion these comments because they are interesting #2385 (comment). |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I'm wrong, but I already faced before conflicts with c# language versions and API versions. The best way to test this isn't by using single target project, but by using multi targeting project. But I would like to know the correct response. |
Beta Was this translation helpful? Give feedback.
-
|
@tig if a border has a thickness of two and the user set the border style to none automatically decrease one thickness for the border frame or the two? Or we need to decrease manually after? I'm asking this because a user may want to have a border without a border frame. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
No, in the new design the var top = new LineView () { LineStyle = LineStyle.Single, X = 0, Y = 0, Width = Dim.Fill() };
var left = new LineView () { LineStyle = LineStyle.Single, X = 0, Y = 0, Height = Dim.Fill () };
var right = new LineView () { LineStyle = LineStyle.Single, X = Pos.AnchorEnd(1), Y = 0, Height = Dim.Fill() };
var bottom = new LineView () { LineStyle = LineStyle.Single, X = 0, Y = Pos.AnchoEnd(1), Width = Dim.Fill() };
var title = new Label () { Text = $" {text} ", X = 2, Y = 0 };
Border.Add (top, left, right, bottom, title);There's some magic yet to be fully invented that will cause the 4 |
Beta Was this translation helpful? Give feedback.
-
|
Note that with this design, devs can host ANY View in ANY of the |
Beta Was this translation helpful? Give feedback.
-
|
This is how the margin is working in the
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I have started updating TerminalGuiDesigner to be compatible with 2.0 when it ships. I am using a git submodule to target I thought I would keep a note of the breaking changes that are not already included in #2448
|
Beta Was this translation helpful? Give feedback.
-
|
Getting there slowly but surely! Failed: 14, Passed: 254, Skipped: 0, Total: 268, Duration: 16 s |
Beta Was this translation helpful? Give feedback.
-
|
Courage you are almost getting there. I understand you :-) |
Beta Was this translation helpful? Give feedback.
-
|
Passing! And working with manual testing. Just need to do some comprehensive testing now. And a net reduction in code due to removing a bunch of hacks/workarounds for v1 behaviours. 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
I'm realizing another problem with the goal to have only one constructor per type, that is pretty much necessary to make an exception for: Cooperative cancellation. If the consumer (or even the library itself) wants to use a linked cancellation token source, you typically should provide a constructor that accepts a CancellationToken or a params array of them and then creates a linked token source from it/them. This is a liiiiittle bit less relevant on Views themselves, though is still a good idea. Where it's basically required is in types used for cancellable operations, such as EventArgs-derived types. Since those types typically represent and are associated with a single event, which may span any number of method calls, the type itself needs to own the token source, and that needs to be set up at initialization. |
Beta Was this translation helpful? Give feedback.
-
|
Why it's still relevant to View types is because, if the View owns a CancellationTokenSource, that source is then able to provide a token to any non-visible (and visible) methods that support cancellation, and can also be linked at construction time, if slaving it to another object is desired. That's got some nice benefits as well. Consider the case where some view is disposed, but it or perhaps one or more subviews it contains, at any arbitrary depth, OR any other views or other types that have subscribed to events published by that view are currently processing some cancelable operation. The Dispose method's first action can be to cancel itself, which would then also cancel anything down the hierarchy implicitly, making sure no weird problems occur such as race conditions or unexpected ObjectDisposedExceptions and whatnot. |
Beta Was this translation helpful? Give feedback.
-
|
This can still be handled by having a single constructor, but just with it having the token be an optional parameter, to reduce total lines of code somewhat. |
Beta Was this translation helpful? Give feedback.
-
|
Neat trick I picked up recently for those cases where you have a boolean expression (such as in an Here's an example from Application.cs (as it currently exists): if (frame?.Thickness.Contains (frame.FrameToScreen (), a.MouseEvent.X, a.MouseEvent.Y) ?? false)
{
//... Do stuff that depends on the above evaluating to true
}Note the null-conditional access operator on That's fine, and does what is intended, but... That whole coalescing with false thing feels kinda like a kludge, doesn't it? Especially since the But how else can you do it without an explicit check for null, first, making the whole thing more verbose or requiring extra lines? Like so: if (frame?.Thickness.Contains (frame.FrameToScreen (), a.MouseEvent.X, a.MouseEvent.Y) is true)
{
//... Do stuff that depends on the above evaluating to true
}Yep. That's all you gotta do! That keeps the logic positive, requires no other changes, and combines the null check and the test for truth, since the This usage applies to any check using the Once you see it and realize it's just a less verbose way of writing something like You've potentially been doing it forever without even realizing it, in switch statements and expressions.
I've been using that coalesce with true or false as needed method like the first code sample above for ages, too. For the cases where the left operand evaluates to null or bool, but you want to execute that branch when the expression is both not null and false, it's an even bigger cleanup. Typically, doing that the old way means coalescing with But you also have to realize that Just wanted to share since I came across this example in our code and it reminded me of it. :) |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys. So... Quick idea... We've been transitioning to using And now we actually have a fair amount of stuff at least enabled, even if not fully annotated yet. I think we're at the point we can just turn it on project-wide. Yes, it will initially result in an uptick in warnings. But, it'll also both make it easier to make the appropriate annotations and changes where needed, as well as reduce the likelihood of getting it only partially right in a given file because dependent or consuming code isn't marked with it yet. In any case, nullable enabled contexts cover a pretty significant percentage of lines of code, already, and the code that is covered is dependent on or is a dependency of every other code file in the project, already, meaning it's all relevant, now. Therefore, I think it's time to go ahead and turn it on all the way, now. Those warnings it will generate mean something, and not having them currently provides a false sense of security even in code that is currently explicitly inside a Plus, it doesn't change runtime behavior in any way (null context is literally ONLY for static analysis and does not affect compiled output beyond metadata), so it wouldn't break anything. 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
Well, someone liked that idea 😅. How would a PR sound, consisting solely of that addition to the csproj files in one commit and the removal of all |
Beta Was this translation helpful? Give feedback.
-
|
Can we hold on this for a bit. At least until @BDisp and I get #2994 finished? |
Beta Was this translation helpful? Give feedback.
-
|
Certainly. That's an easily postponed sort of thing that can likely be merged conflict-free at pretty much any time after the branch point, anyway. I'm also in the middle of some pretty big work, which is making some of the bad analysis suggestions resulting from improper annotations quite apparent in some places before fixes usually consisting of a single So just a heads up on that fun little potential gremlin. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed some use of the CombinatorialData stuff in some tests. Awesome! However, there is one specific part of it that shouldn't be used in tests that are expected to be run by CI or other default non-filtered runs of the test project, even though it initially looks like a pretty nifty thing: Why not? Because it isn't repeatable. You'll even see that in Visual Studio, manifested as a number of tests that pass when run, but which stay in the indeterminate/not-run/unevaluated state, looking like maybe they didn't run. Like so:
Those 400 tests (which that tree is filtered down to) do, in fact, pass when run. But tests are named implicitly according to their parameters as called, so tests with non-deterministic values, such as random data or DateTime.Now can never be repeated and will always show in that state after the fact. They're occasionally useful for tests marked explicit or otherwise filtered out from default runs, to provide proof of proper function on values not known to the test-writer ahead of time. But the naming issue is an unfortunate limitation that exists in every major test framework, with that feature. Sucks, I know... :( I suggest that one perhaps use that while working on something, but do not commit to source control with it. Instead, switch to an explicit list of values, a range, or, for situations that call for it, a generator method or property. A general note about all of the CombinatorialData attributes is that, if you have more than one parameter, every combination of the set created by the attribute applied to each parameter will be generated. The ones to use, for parameters, are:
With XUnit and the CombinatorialData extension, these two attributes should be the ones used for auto-generated test cases. No matter what you use, just be sure they are deterministically repeatable. There are ways, with some frameworks and some extensions, to make random data be repeatable, too. I'm not sure off the top of my head if this library has that capability. If it does, that can also be an acceptable way to use random data. |
Beta Was this translation helpful? Give feedback.
-
|
Just a general thought I had about interaction with the console, in general, which could habe meaningful impacts on memory and performance for multiple reasons: The screen buffer is only up to short.MaxValue in either dimension, meaning we could use shorts all over the place instead of ints. Where this matters big-time is the fact that a lot of operations can be explicitly vectorized in code or are likely to be implicitly vectorized by the compiler or the JITer. Using int or uint has two important impacts on that:
Of course it also means that memory use can be less, on the heap, and is likely to be less, on the stack, as well. Just something to think about. |
Beta Was this translation helpful? Give feedback.
-
|
Oh hey @BDisp R# 2024 was release a couple weeks ago and has fixes for at least one of the bugs you mentioned at some point. It also has a fix for the way it was previously breaking formatting on some (but not all) raw string literals. As well as whatever else the new version has of course. A worthwhile update for sure, if you haven't already grabbed it. |
Beta Was this translation helpful? Give feedback.
-
|
I have version 2024.1.1 of 2024-04-15 of ReSharper and I think it's the last one because my laptop got a new SSD and I had to reinstall everything. I will keep an eye on these corrections and make sure they no longer occur. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Yep that's the current release. 👌 |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys. Check this out... https://github.com/microsoft/terminal/tree/main/samples/ConPTY/GUIConsole |
Beta Was this translation helpful? Give feedback.
-
|
Hey @tig So, our whole PR thing about naming and whatnot, which is kinda unnecessarily cumbersome and verbose... Projects actually enable that kind of linking, but in a stronger, more formal, and easier-to-enforce way, without having to make cumbersome or inaccurate names. Take a look at my project I've used for various Terminal.Gui work. If you click on any of the issues, you'll see some extra data over on the right, under the project. In particular, I added fields for priority, Terminal.Gui Issue# and Terminal.Gui PR#. I also opted to have the TG Issue# displayed on the item cards, for top-level visibility without having to click on one to see it. And the default behavior of items like that is you click it and then it shows you everything else that has that property with that value. Really nice. For me, since it's a fork and the main fork isn't configured to allow it, I can't make a whole lot more than informational usage of them (but that's valuable to me anyway). If we had a project, over here, instead of a milestone, you could add properties like that, too. Those properties are available for use in issues and PRs. Those properties are then available to github actions/workflows, and those actions can get OR set them, for any purpose you can dream up. A few simple examples of where that's useful and a QoL improvement:
Plus of course all the other organizational goodies like boards and timelines and stuff that just come along with projects. Then you can also use the Milestones for what they're really meant for, which is milestones of a given project's development (can also see that in use in my project, where I have a milestone for my source gen work). That enables strong grouping of things by what they relate to, and also gives a little progress bar for each milestone, which just displays percentage of issues in that milestone that are finished/closed vs open. Plus, projects have another nice feature: Draft items. Users with write access to the project can put up cards for issues/ideas/whatever that are just a title and it doesn't actually make an issue until you tell it to convert it to an issue. That really helps de-clutter things when people have ideas or things to do but aren't ready to write up a formal issue. I'd have my project link to this repository, but you can only link a project to a repository you are a member of, with I forget what specific permission. |
Beta Was this translation helpful? Give feedback.
-
|
Oops. Didn't link it at first. Linked now. |
Beta Was this translation helpful? Give feedback.
-
|
Another couple of common properties you might see in projects is something for tracking versions affected by a bug or issue, or one to indicate what version or tag it will be/has been released in. Like "Affects Versions" as a select element that pulls from tags/releases. And an "Included in Release" also as a select element pulling from Releases. |
Beta Was this translation helpful? Give feedback.
-
|
Another important note: Permissions for a project are separate from repository permissions. So you can assign collaborators or any github user, regardless of membership in the Terminal.Gui repository or the gui-cs organization, write permissions to a project so they can interact with it, without exposing additional access to the repository itself. I sent you an invite to that project so you can play around if you want. |
Beta Was this translation helpful? Give feedback.
-
|
We have a project. You just didn't have access to it! https://github.com/orgs/gui-cs/projects/1 I made you admin. I'm MORE than happy for you to take what's there and make it sing. I spent just enough time setting it up to realize I was probably not doing it optimally ;-) |
Beta Was this translation helpful? Give feedback.
-
|
I tossed up a "draft" item in the project only visible there with some ideas and proposals. Dropped it at the top of the "New" column in the Backlog view. |
Beta Was this translation helpful? Give feedback.
-
|
Ha OK cool. Happy to lend a hand with that. Will have a look this weekend most likely. Been kind of a busy week.
|
Beta Was this translation helpful? Give feedback.
-
.net 8.0 SDK automatic version metadata enhancementIf you are building with the .net 8.0 SDK, regardless of what target framework is specified in the project file, commit information can now be automatically included in the version, if it is defined for the build. It is appended to the InformationalVersion attribute of the assembly, which is what you get when you access Assembly.ProductVersion, and is what users see. What does "specified in the project file" mean? MSBuild has a new property/element you can use:
|
Beta Was this translation helpful? Give feedback.
-
|
You can also put other arbitrary custom attributes on an assembly, if you like. The EnumExtensionMethodsGenerator actually does that, right now, to provide a nice manifest of extended types in fewer and quicker calls, for use by itself or other generators down the road. I didn't use AssemblyMetadataAttribute because I wanted to store actual |
Beta Was this translation helpful? Give feedback.
-
|
A note to myself for something to do with that as the PowerShell modules grow up: Store final values of variables defined by the modules (those relevant to the build anyway) and the version of the modules, as part of any Build-XXXX functions exported by the modules. |
Beta Was this translation helpful? Give feedback.
-
V2 Beta Release Criterion(Draft for feedback and debate.) These are the criteria we will use to decide whether V2 Beta can be released. Once we agree on these criteria, we will use them to classify all existing and future Issues. We will not accept any PR into v2_develop that does not meet these criteria. By taking this approach we can get all contributors focused on a release and get it out as quickly as possible. V2 Beta Goals
Priority definitions for Issues
Beta Exit Criteria
If we focus as a team on meeting these criteria, we can get the Beta out the door quickly and continue to innovate on top of it for years to come! I will be the Release Owner. I will take responsibly for driving the team to release. I will do the structural work required to keep us organized and focused. I have final say on Issue priority and the final call on release readiness. Next steps:
This is all posted in the spirit of driving focused debate. I have 30+ years experience driving releases at scale. I still have a ton to learn, and my experience doing it as an OSS maintainer is limited. I need your help! Let's get 'er done and ship it! |
Beta Was this translation helpful? Give feedback.
-
|
Quick scan of it seems to hit most of the things I'd say. I'm going through a large backlog right now from here and work-related, so I'll sit down and think about this soon. Just an ack :) |
Beta Was this translation helpful? Give feedback.
-
|
Oh hey. While I was dealing with a thread-safety issue with some old internal code, it made me think of something that was part of a conversation here where the same issue exists if it hasn't been changed since then. I don't remember specifically which type it was, but there was a type that is written such that it requires properties to be set in a specific order in an initializer or it can throw an exception. Does that ring a bell for anyone? I don't remember where it was... In any case, that's not even safe on single-threaded applications, because Roslyn, RyuJIT, AND your CPU are all allowed to reorder reads and writes to memory and the ECMA spec for the CLR does not restrict that. You cannot ever expect simple assignment or read operations like that to execute in the order you wrote them, except for most of the time in debug builds, and places where there are a bunch of consecutive simple operations like that or a loop with similar results are ripe for that kind of optimization, so the system can save some round trips to memory. To ensure at least partial restriction of that reordering, but still only within a single logical CPU, you can declare fields volatile. But nobody has just one logical CPU, anymore, so that's pointless and just costs performance without actually fixing the problem (the biggest underlying reasons why use of And this is even a problem for values that normally would be atomic, if they are members of a struct that isn't native-word aligned (so 4 bytes on 32-bit and 8 bytes on 64-bit). That's what you get if you make a struct with explicit layout, like might be done for interop with some native libraries. The cause of that is un-aligned reads and writes, so it may be theoretically possible in other situations, but I'm not aware of how to force that elsewhere. This issue is always a heisenbug, unless Roslyn, which is the least likely to do that optimization, is the one to do it, in which case it'll still be a heisenbug, but just happen more frequently. The issue with that old code that I fixed was ultimately because of reordering, and wasn't in a struct. It was just in a plain ol' innocent class. The bug has been an annoying heisenbug for a very long time and the stack traces were never helpful because it pretty much never caused the crash right there or even near there in the program. I finally found it by tracing, line by line, from the first method call in Main(), til I found SOMETHING that was capable of causing bad values, while assuming essentially infinite threads to be extra-cautious. That's when I eventually came to the problem spot. It was the same thing: order-dependent fields being set by property accessors in an initializer. I wrote up a test hardness to run that small part of code a bunch of times, in a bunch of processes, each with a bunch of threads, to try to hit it, now that I had a narrow spot that could actually feasibly be performed on. Sure enough, the bug was triggered after about 20 minutes of that running, by the 45108'th process that was launched. Suspicious of that issue, I went looking for documentation backing it up and, sure enough, there's more than one document mentioning it. So, first I did an explicit process-wide memory barrier there and re-ran the test harness, just to verify it actually did behave as expected. After two hours, it had still not occurred, so I called that a good enough confirmation that that was, indeed, the problem. Because of the cost of that, though, I took that back out and just made them not dependent on specific ordering, so barriers would not be needed. Ran the tests again, and left it running overnight on two VMs with lots of cores assigned to them. Checked in on them in the morning and none had hit the issue. So, whether it was Roslyn, RyuJIT, or the CPU is unknown. But it's also unimportant, because it doesn't matter who reorders things - the problem can still happen. It just also might not. So, the takeaway is just don't do that, because there's always another way. |
Beta Was this translation helpful? Give feedback.
-
|
Also note that the compiler isn't stupid. This isn't possible for operations that are clearly dependent on each other in a fundamental way, like writing a value and then reading it later on in the same method, on the same thread. Though that's still a thread safety problem anyway, if we're talking about post-construction access to type members and not just locals. The problem both in the code I'm talking about as well as in the code here is vulnerable to it because the dependency is out of scope that can't be or at least isn't exhaustively checked for potential problems like that. Also, this is one of MANY reasons a constructor, initializer, or type initializer (static constructor) need to avoid side effects. |
Beta Was this translation helpful? Give feedback.
-
|
It was related to AutoSize. Which is now gone. |
Beta Was this translation helpful? Give feedback.
-
|
We now have 3 Projects, listed in order of priority: |
Beta Was this translation helpful? Give feedback.
-
Terminal.Gui v2.x is in development. This thread is for discussing and debating the design and implementation and plan.
Tenets for v2 (Unless you know better ones)
Please feel free to suggest other tenets or modifications to those above. I'll keep this post updated with the latest input.
Themes for v2
ConsoleDriverarchitecture and implementation, especially w.r.t. Linux/curses has deep flaws and poor performance relative toWindowsDriveron Windows.ConsoleDrivers yet we continually get regressions and complex bugs in them.Buttonand other views #2144.TextView,TextFormatter, etc... But we made some errors and things like word wrapping are still not as good as they need to be for a text-based library.gui.csdesign decisions, combined with subsequent upgrades have led to areas of the API that just don't make sense to new devs. One example is how weirdWindow'sBorderandPaddingwork (and whyFrameViewexists at all). Another is the clunkiness of usingScrollView.System.Runevs.Nstack, and MAUI.These are here to cause debate and discussion. So please share your thoughts! I'll keep this post updated as the discussion progresses...
Plan for maintaining v1
v2_develop- DONEdevelopsince v1.9. Any that we determine were REGRESSIONS from v1.8 or earlier that significantly impact devs, we target at a v1.10 release. The rest we PUNT to v2.0.developso all of the work that's gone into it since v1.9 is available for reference.Beta Was this translation helpful? Give feedback.
All reactions